RE: Attribute used to store cached certificate chains?

[Alan Lloyd <[e-mail]>]

Operationally I tend to think that the certs for a document will be
archived as an archive record and that record to be signed by the
archiver - as it is the archive which will be trusted by name and by
nature. This means that the archiver keys/certs will have to archived.
But that is a minimal issue as one can store millions of archive records
with one set of archive keys.

just thoughts and regards alan

PS . this issue has to be dealt with simply because the archive record
has o be trusted to indicate the time at which the material was verified
and used. trusted time stamps need to be applied.

> -----Original Message-----
> From:	Andrew Probert 
> Sent:	Monday, February 01, 1999 9:38 AM
> To:	'WHenry'; '[e-mail]'
> Cc:	'[e-mail]'
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> In my opinion a signed document is archived for a purpose i.e. the
> potential
> for it to be retrieved as evidence at some point in time.  If this
> perspective is taken, then one wants to have the document as
> self-sufficient
> as possible.  
> 
> I think a document retrieved 7 years hence, will be more easy to
> validate if
> all of its certificates are embedded.  Otherwise, one could have a
> complex
> task to attempt to retrieve a number of CA certs, possibly expired and
> purged from most systems.
> 
> CRLs are another issue again, but maybe there's a hope that CAs
> archive them
> as a customer service, if not then the customers who care about these
> things, certainly should archive them!
> 
> eCommerce brings with it the eRecordsManagement issue which has yet to
> be
> addressed!
> 
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  [phone]
> Fax [phone]
> 
> 
> 
> > -----Original Message-----
> > From:	WHenry [SMTP:[e-mail]]
> > Sent:	Saturday, January 30, 1999 1:24 AM
> > To:	'[e-mail]'
> > Cc:	'[e-mail]'
> > Subject:	FW: Attribute used to store cached certificate chains?
> > 
> >  Maintaining a copy of a user's certificate chain has implications
> for
> > digitally signed archives, as well. 
> > 
> >  In the case of an archived (and signed) document, should the
> document
> > itself retain a copy of the certificate chain to aid in validation?
> Or
> > will PKI's/Directories support future path validation for archived
> > documents?
> > 
> >  Thoughts/comments? 
> > 
> >  Bill Henry 
> >  Performance Engineering Corporation 
> > 
> > -----Original Message----- 
> > From:   Tammy Carter [SMTP:[e-mail]] 
> > Sent:   Thursday, January 28, 1999 7:09 PM 
> > To:     [e-mail]; [e-mail];
> > [e-mail] 
> > Subject:        RE: Attribute used to store cached certificate
> chains? 
> > 
> > Hi, Alan, 
> > 
> > Thanks for clarifying.  It _is_ incorrect to say that an entire
> directory
> > is off-line. 
> > (Well, unless all the server's holding replicas have all gone down
> at 
> > exactly the same moment.)  
> > 
> > What I was referring to was more the inability of the user to read
> the set
> > of 
> > objects from which a chain can be constructed.  This inability could
> 
> > be caused by network outages (planned or unexpected), a bad 
> > replication scheme, or even the inability of the client to
> communicate 
> > with the necessary servers using the right protocols. 
> > 
> > For example, picture a company's tree that spans the world.  Servers
> 
> > are on every continent.  I have a certificate, stored on my user
> object.  
> > I travel to China for a month of consulting in our branch office. 
> My 
> > administrator, thinking ahead, puts a replica of the partition
> containing 
> > my user object on a server in China so that a copy of my object is 
> > being maintained locally.  Now, I want to send email and I need to 
> > send a certificate chain with my S/MIME message.  My CA has an 
> > object in the tree, but only Utah servers hold replicas of it's 
> > partition.  Unfortunately, due to network problems, I can't get 
> > to my CA's object.  
> > 
> > It would seem reasonable to store a cached copy of the user's 
> > certificate chain on their object rather than forcing the user to 
> > store it on the client's file system, or on a floppy disk.  This 
> > allows a "free seating policy" so that users can go to any 
> > client and perform their job functions without having to carry 
> > around floppy disks. 
> > 
> > My initial question was:  has anyone thought of caching this 
> > information in the directory yet?  If so, what attributes are being 
> > used? 
> > 
> > 
> > Tammy Green Carter 
> > [e-mail] 
> > 
> > 
> > >>> Alan Lloyd <[e-mail]> 1-28-99 3:03:33 PM
> >>> 
> > Some comments 
> > 
> > This debate seems to say that a directory tree is unavailable and 
> > therefore local caching is used. It would strike me that a major
> part of 
> > the system design of an organisation's information system. eg HR, 
> > database or PABX or RADIUS directory,  that replica's are placed at 
> > certain points to avoid service failures. Although there are major 
> > functional distinctions between a database, a file system, a
> directory 
> > service, etc. The system design and operational deployment of all of
> 
> > these things makes sure that service levels are maintained. Saying
> that 
> > "a directory" is off line is like saying a database is off line or
> the 
> > file server is off line. I would expect that a User who is mobile to
> 
> > contain on their local directory/file system all the things that
> support 
> > that environment eg address books, mail boxes and a bunch of keys
> and 
> > certs..which can be replica entries of the CAs system. 
> > 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA00218 for ietf-pkix-bks; Sun, 31 Jan 1999 22:57:36 -0800 (PST)
Received: from uranus.ubs.com (uranus.ubs.com [193.134.254.67]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA00214 for <[e-mail]>; Sun, 31 Jan 1999 22:57:34 -0800 (PST)
Received: by uranus.ubs.com; id HAA02790; Mon, 1 Feb 1999 07:58:54 +0100 (MET)
Received: from svscan(192.168.85.11) by uranus.ubs.com via smap (4.1) id xma002747; Mon, 1 Feb 99 07:58:29 +0100
Received: from localhost by svscan.ubinet.ubs.com (SMI-8.6/SMI-SVR4) id HAA18853; Mon, 1 Feb 1999 07:58:29 +0100
Message-ID: <[e-mail]>
Date: Mon, 01 Feb 1999 07:58:24 +0100
From: Markus Bitterli <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: RE: OCSP and historical data
References: <00ec01be4bbb$065b5910$[e-mail]>
Content-Type: multipart/mixed; boundary="MimeMultipartBoundary"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Hello,
Probably I do misunderstand this, but I think this is just to provide an
answer for certificates which are already expired.
My problem is that I would like to check certificates which signs
transactions, e.g. within an e-mail. In this case   I should actually check
the validity of the certificate for the time of the signing process and not
when I receive it. For this I saw no mechanism in the standard.

Regards,
Markus

[e-mail] wrote:

> Hi Denis, Markus,
>     Yes, you can get historical data from an OCSP responder, as long
> as the responder chooses to support archiving of data. Check section
> 5.4.4.
>
> Regards,
> Ambarish
>
> 5.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).
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf
> > Of Denis Pinkas
> > Sent: Friday, January 29, 1999 2:26 AM
> > To: Markus Bitterli
> > Cc: [e-mail]
> > Subject: Re: OCSP and historical data
> >
> >
> > Markus,
> >
> > Your analysis is correct. OCSP assumes the current date only.
> >
> > > I've read the OCSP draft and wonder whether it is possible
> > to request
> > > information about the validity for a certificate for a
> > specific date and
> > > time in the past. As I've understood it, this is not
> > possible. If so,
> > > has somebody any idea for a solution to that requirement.
> >
> > There are several ways. One solution is to gather the
> > appropriate CRL or OCSP
> > responses close to the time of the signature.
> > If you want to rely on an external service, there have been
> > discussions around
> > the DCS draft and the DVS concept: "Data Validation Service".
> > This kind of
> > service is supposed to do some verification upon some data
> > that is presented.
> > I recently send an E-mail on that topic. Please refer to it.
> >
> > Denis
> >
> > > Markus Bitterli
> >

--MimeMultipartBoundary--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA18266 for ietf-pkix-bks; Sun, 31 Jan 1999 19:11:35 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA18220 for <[e-mail]>; Sun, 31 Jan 1999 19:11:21 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <1AYDD2TS>; Mon, 1 Feb 1999 14:14:13 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC0943B8@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Andrew Probert'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Date: Mon, 1 Feb 1999 14:14:12 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

As said many times - if you want DNS to have the same capability as
X.500 distributed directories - fair bet it will have to embrace all
that functionality. That should take about 5-10 years. Or the otherway
is do what is being done today, build RADIUS, DHCP and DNS server front
ends on X.500. 
Most have now recognised that distribution and distributed
authentication is key in large scale directory services and that single
LDAP servers on their own  are nothing more than repeating the limited
single central DB type architectures which were applied some 25 years
ago.

However, these can be integerated as a subordinate directory server if
one gets the right directory backbone technologies :-)))

regards alan
> -----Original Message-----
> From:	Andrew Probert 
> Sent:	Monday, February 01, 1999 11:23 AM
> To:	'Alan Lloyd'; 'Stephen Kent'
> Cc:	[e-mail]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> I have watched this dialogue with interest.
> 
> I must admit to being a fan of directories of any sort and can't but
> help
> comment on some real-world recent things I have seen, in favour of the
> approach..
> 
> The internet is build upon DNS (Domain Name Servers), DHCP
> (Distributed Host
> Control Protocol) et al.  Serious vendors such as CISCO have bought
> companies like American Internet Corporation to get a hold of
> infrastructure
> technologies to help them scale and lo and behold we see things like
> Radius
> Servers being bolted up to directories to give them the sorts of
> backends
> that can scale and perform.  
> 
> How many ISPs can you name that have woeful performance on initial
> connections, whilst I assume they grovel around in poorly designed
> backend
> database to find billing and profile information?  A directory should
> be
> considered to publish customer details internally to a service
> provider as
> well as a restricted profile of information to the outside world!
> 
> Sure systems can get pretty large upon lightweight technologies such
> as DNS
> etc, but they are definately creaking at the seams, especially when
> some
> maniacs are suggesting the next step of extending DNS servers with
> Certificate storage capabilities.
> 
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  [phone]
> Fax [phone]
> 
> 
> 
> > -----Original Message-----
> > From:	Alan Lloyd [SMTP:[e-mail]]
> > Sent:	Monday, February 01, 1999 9:12 AM
> > To:	'Stephen Kent'
> > Cc:	[e-mail]
> > Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> > 
> > 
> > 
> > > -----Original Message-----
> > > From:	Stephen Kent 
> > > Sent:	Sunday, January 31, 1999 7:16 AM
> > > To:	Alan Lloyd
> > > Cc:	'Stephen Kent'; [e-mail]
> > > Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> > > 
> > > Alan,
> > > 
> > > < much text deleted>
> > > 
> > > >	One can cite if one attacks a directory entry but I would expect
> > > >that a CA entry with its cert and CRL DP, etc is well protected
> from
> > > >casual writes - protected via authentication mechanisms and
> access
> > > >controls for CA modification only. The same issue would be with
> an
> > > >unprotected DB .
> > > 
> > > Certs and CRLs are signed and thus we rely less on the directiry
> > > system to
> > > protect them, since tampering is evident to the user.  As soon as
> we
> > > talk
> > > about relying on unsigned data items in a directory, the security
> > > situation
> > > is quite different.
> > > 
> > 	After N years with military X.500 and PKIs I think I do
> > understand this. But in addition to signing data, we can also place
> > "some" trust on the distributed authentication and access controls
> of
> > the directory system. Particularly when the user or certficate
> reader
> > has been requested to do strong authentication on the directory
> service
> > itself to read the CA entry. We do deal with trusted directory
> systems
> > you know.
> > > >
> > > >	At least the directory provides a distributed, profileable -
> > > >authentication and ACI regime which will be designed and deployed
> > > >according to a cost/trust and service model.
> > > 
> > > Yes, but that regime should not be relied upon for cert
> processing,
> > > exccept
> > > to mitigate denial of service concerns, i.e., one shoud rely on a
> > > directory
> > > in a cert processing context only to the extent that one needs
> some
> > > repository for signed objects.  To extend that reliance to
> unsigned
> > > objects, in a fashion that could undermine the security of cert
> > > processing,
> > > would be negligent.
> > > 
> > 	And in the case where this extra strengh is needed we can do
> > strong auth and signed ops on the directory service.. with DAP - you
> > know the protocol thats half the size of LDAP with twicw as many
> feature
> > including trusted signed operations :-))).
> > 
> > 
> > > <lots more text delted>
> > > 
> > > >	However, with a robust - distributed directory service - that is
> > > >designed to be robust - some of those concerns should dissipate.
> > > After
> > > >all the phone system is a very big infrastructure that in general
> > > >supports a service and one tends to think that any failure in any
> > > >component does not bring the whole system down. Infrastructure
> design
> > > >always makes sure that their is no single point of failure for
> the
> > > whole
> > > >service and that any failure only criples a componenet of area of
> the
> > > >service.
> > > >	All I am saying that directory system designs should parallel
> > > >the phone system re replicated/distributed paths and redundancy
> > > >features. Thus a "trust" can be placed on them - like any
> > > infrastructure
> > > >- water, gas, roads, etc. Otherwise what is the alternative to
> the
> > > >design of large scale systems?
> > > 
> > > Well, I now work for a phone company, and I do not believe the
> analogy
> > > is a
> > > good one.  Directories in the phone system have very simple access
> > > models
> > > and (legitimate) subscribers have very restricted access
> capabilities.
> > > When phone phreaks have gone after the phone system, they are
> often
> > > successful. The fundamental issue here is that one should rely on
> any
> > > infrastructure ONLY to the extent that is intrinsic in that
> > > infrastructure.
> > > When we rely on infrastructures in ways beyond their design
> intent, we
> > > get
> > > into trouble.  the OCSP server ID example does that, in my
> opinion.
> > > 
> > 	We need to talk re the two paradigms. Many people find the phone
> > system/directory system paradigm very useful.
> > 	As for infrastructures. They tend to be in fact very big systems
> > - by definition. If OCSP wants to be big - it will become an
> > infrastructure - but if it wants to be big it will have to be
> supported
> > by a big distributed information base... some thing like a directory
> > service. Otherwise its hand carved...
> > 
> > 
> > 
> > > <still more text deleted>
> > > 
> > > >>
> > > >	Thats the CA theory view that may not serve an operational
> > > >world. The transaction with a cert has a business/policy
> component
> > > also
> > > >and that must be tied to the cost/trust/business models that
> apply
> > > >certificates. ie. the theoretical CA model need not rule in all
> > > cases.
> > > 
> > > Of course PKI designs are driven by many factors, but that doesn't
> > > mean we
> > > have to be sloppy about security, and you have not provided any
> models
> > > that
> > > quantitatively compare the tow models we are debating.  This is
> the
> > > PKIX
> > > mailing list in the IETF; we worry about real CA concerns, not
> just
> > > theoretical ones. Your directory-centric perspective on these
> issues
> > > strikes me as much more theoretical :-).
> > > 
> > 	Theory ! Oh really. How many OCSP servers will be needed for 100
> > m users. What is the information system that supports this?
> > > <yet more text deleted>
> > > 
> > > >	As said, when one designs a distributed directory service
> > > >infrastructure with directory enabled processes attached to the
> > > service
> > > >for such things like org chart generation, subject matter context
> > > >clumping  and possibly cert validation and... specialised
> seach/data
> > > >engines for fingerprint validation, etc , then these processes by
> > > nature
> > > >are context sensitive (or insesnitive) - mult path, distributed
> > > >processes . ie with directory enabled distributed processing, the
> > > whole
> > > >system, service and processing paradigms change - including the
> > > >configuration and single point of failure models.
> > > >
> > > >
> > > >	The telephone network is very similar to the PKI validation
> > > >model that is needed for global services. Multi domains, multi
> > > services,
> > > >global roaming and distributed-fast authentication. As
> directories
> > > make
> > > >the phone system work, so will directories make big PKIs work.
> > > 
> > > As I noted above, I work for a large phone company and I dispute
> the
> > > validity of the analogy.  What it seems to boil down to is an
> > > assertion by
> > > you that directories will be ubiquitous, very fast, ultra
> reliable,
> > > and
> > > sufficiently secure so that we should abandon the crypto-integrity
> > > model
> > > upon which X.509 is based.  
> > > 
> > 	Thats it. Got it in one. 
> > 
> > > Clearly this is not the case today, so let's
> > > just see if the directory model you envision comes to pass.  if
> so,
> > > I'll
> > > withdraw my objections.  
> > > 
> > 	Its coming to pass. Simply bnecause all those "servers" being
> > promoted need ... wait for it...
> > 	Information and for that information to be applied in a
> > distributed and common way.
> > 
> > > However, in the mean time, I suggest that we not
> > > degrade the security of PKIs based on these projections.
> > > 
> > 	No infact we are enhancing the PKI with the reality of deployed
> > directory systems.
> > 	A PKI without a business purpose and information and service
> > deployment scaleability will be an orphan technology.
> > 	regards alan
> > 
> > > Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA15093 for ietf-pkix-bks; Sun, 31 Jan 1999 18:20:17 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15089 for <[e-mail]>; Sun, 31 Jan 1999 18:20:08 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <1AYDD2SW>; Mon, 1 Feb 1999 13:22:59 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC0943B0@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Andrew Probert'" <[e-mail]>, "'WHenry'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Attribute used to store cached certificate chains?
Date: Mon, 1 Feb 1999 13:22:57 +1100
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 SAA15090
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Operationally I tend to think that the certs for a document will be
archived as an archive record and that record to be signed by the
archiver - as it is the archive which will be trusted by name and by
nature. This means that the archiver keys/certs will have to archived.
But that is a minimal issue as one can store millions of archive records
with one set of archive keys.

just thoughts and regards alan

PS . this issue has to be dealt with simply because the archive record
has o be trusted to indicate the time at which the material was verified
and used. trusted time stamps need to be applied.

> -----Original Message-----
> From:	Andrew Probert 
> Sent:	Monday, February 01, 1999 9:38 AM
> To:	'WHenry'; '[e-mail]'
> Cc:	'[e-mail]'
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> In my opinion a signed document is archived for a purpose i.e. the
> potential
> for it to be retrieved as evidence at some point in time.  If this
> perspective is taken, then one wants to have the document as
> self-sufficient
> as possible.  
> 
> I think a document retrieved 7 years hence, will be more easy to
> validate if
> all of its certificates are embedded.  Otherwise, one could have a
> complex
> task to attempt to retrieve a number of CA certs, possibly expired and
> purged from most systems.
> 
> CRLs are another issue again, but maybe there's a hope that CAs
> archive them
> as a customer service, if not then the customers who care about these
> things, certainly should archive them!
> 
> eCommerce brings with it the eRecordsManagement issue which has yet to
> be
> addressed!
> 
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  [phone]
> Fax [phone]
> 
> 
> 
> > -----Original Message-----
> > From:	WHenry [SMTP:[e-mail]]
> > Sent:	Saturday, January 30, 1999 1:24 AM
> > To:	'[e-mail]'
> > Cc:	'[e-mail]'
> > Subject:	FW: Attribute used to store cached certificate chains?
> > 
> >  Maintaining a copy of a user's certificate chain has implications
> for
> > digitally signed archives, as well. 
> > 
> >  In the case of an archived (and signed) document, should the
> document
> > itself retain a copy of the certificate chain to aid in validation?
> Or
> > will PKI's/Directories support future path validation for archived
> > documents?
> > 
> >  Thoughts/comments? 
> > 
> >  Bill Henry 
> >  Performance Engineering Corporation 
> > 
> > -----Original Message----- 
> > From:   Tammy Carter [SMTP:[e-mail]] 
> > Sent:   Thursday, January 28, 1999 7:09 PM 
> > To:     [e-mail]; [e-mail];
> > [e-mail] 
> > Subject:        RE: Attribute used to store cached certificate
> chains? 
> > 
> > Hi, Alan, 
> > 
> > Thanks for clarifying.  It _is_ incorrect to say that an entire
> directory
> > is off-line. 
> > (Well, unless all the server's holding replicas have all gone down
> at 
> > exactly the same moment.)  
> > 
> > What I was referring to was more the inability of the user to read
> the set
> > of 
> > objects from which a chain can be constructed.  This inability could
> 
> > be caused by network outages (planned or unexpected), a bad 
> > replication scheme, or even the inability of the client to
> communicate 
> > with the necessary servers using the right protocols. 
> > 
> > For example, picture a company's tree that spans the world.  Servers
> 
> > are on every continent.  I have a certificate, stored on my user
> object.  
> > I travel to China for a month of consulting in our branch office. 
> My 
> > administrator, thinking ahead, puts a replica of the partition
> containing 
> > my user object on a server in China so that a copy of my object is 
> > being maintained locally.  Now, I want to send email and I need to 
> > send a certificate chain with my S/MIME message.  My CA has an 
> > object in the tree, but only Utah servers hold replicas of it's 
> > partition.  Unfortunately, due to network problems, I can't get 
> > to my CA's object.  
> > 
> > It would seem reasonable to store a cached copy of the user's 
> > certificate chain on their object rather than forcing the user to 
> > store it on the client's file system, or on a floppy disk.  This 
> > allows a "free seating policy" so that users can go to any 
> > client and perform their job functions without having to carry 
> > around floppy disks. 
> > 
> > My initial question was:  has anyone thought of caching this 
> > information in the directory yet?  If so, what attributes are being 
> > used? 
> > 
> > 
> > Tammy Green Carter 
> > [e-mail] 
> > 
> > 
> > >>> Alan Lloyd <[e-mail]> 1-28-99 3:03:33 PM
> >>> 
> > Some comments 
> > 
> > This debate seems to say that a directory tree is unavailable and 
> > therefore local caching is used. It would strike me that a major
> part of 
> > the system design of an organisation's information system. eg HR, 
> > database or PABX or RADIUS directory,  that replica's are placed at 
> > certain points to avoid service failures. Although there are major 
> > functional distinctions between a database, a file system, a
> directory 
> > service, etc. The system design and operational deployment of all of
> 
> > these things makes sure that service levels are maintained. Saying
> that 
> > "a directory" is off line is like saying a database is off line or
> the 
> > file server is off line. I would expect that a User who is mobile to
> 
> > contain on their local directory/file system all the things that
> support 
> > that environment eg address books, mail boxes and a bunch of keys
> and 
> > certs..which can be replica entries of the CAs system. 
> > 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA14648 for ietf-pkix-bks; Sun, 31 Jan 1999 16:22:03 -0800 (PST)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA14639 for <[e-mail]>; Sun, 31 Jan 1999 16:22:00 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <DLNAT1N1>; Mon, 1 Feb 1999 11:23:07 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A62BA@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Alan Lloyd'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Date: Mon, 1 Feb 1999 11:23:04 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have watched this dialogue with interest.

I must admit to being a fan of directories of any sort and can't but help
comment on some real-world recent things I have seen, in favour of the
approach..

The internet is build upon DNS (Domain Name Servers), DHCP (Distributed Host
Control Protocol) et al.  Serious vendors such as CISCO have bought
companies like American Internet Corporation to get a hold of infrastructure
technologies to help them scale and lo and behold we see things like Radius
Servers being bolted up to directories to give them the sorts of backends
that can scale and perform.  

How many ISPs can you name that have woeful performance on initial
connections, whilst I assume they grovel around in poorly designed backend
database to find billing and profile information?  A directory should be
considered to publish customer details internally to a service provider as
well as a restricted profile of information to the outside world!

Sure systems can get pretty large upon lightweight technologies such as DNS
etc, but they are definately creaking at the seams, especially when some
maniacs are suggesting the next step of extending DNS servers with
Certificate storage capabilities.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Alan Lloyd [SMTP:[e-mail]]
> Sent:	Monday, February 01, 1999 9:12 AM
> To:	'Stephen Kent'
> Cc:	[e-mail]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> 
> 
> > -----Original Message-----
> > From:	Stephen Kent 
> > Sent:	Sunday, January 31, 1999 7:16 AM
> > To:	Alan Lloyd
> > Cc:	'Stephen Kent'; [e-mail]
> > Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> > 
> > Alan,
> > 
> > < much text deleted>
> > 
> > >	One can cite if one attacks a directory entry but I would expect
> > >that a CA entry with its cert and CRL DP, etc is well protected from
> > >casual writes - protected via authentication mechanisms and access
> > >controls for CA modification only. The same issue would be with an
> > >unprotected DB .
> > 
> > Certs and CRLs are signed and thus we rely less on the directiry
> > system to
> > protect them, since tampering is evident to the user.  As soon as we
> > talk
> > about relying on unsigned data items in a directory, the security
> > situation
> > is quite different.
> > 
> 	After N years with military X.500 and PKIs I think I do
> understand this. But in addition to signing data, we can also place
> "some" trust on the distributed authentication and access controls of
> the directory system. Particularly when the user or certficate reader
> has been requested to do strong authentication on the directory service
> itself to read the CA entry. We do deal with trusted directory systems
> you know.
> > >
> > >	At least the directory provides a distributed, profileable -
> > >authentication and ACI regime which will be designed and deployed
> > >according to a cost/trust and service model.
> > 
> > Yes, but that regime should not be relied upon for cert processing,
> > exccept
> > to mitigate denial of service concerns, i.e., one shoud rely on a
> > directory
> > in a cert processing context only to the extent that one needs some
> > repository for signed objects.  To extend that reliance to unsigned
> > objects, in a fashion that could undermine the security of cert
> > processing,
> > would be negligent.
> > 
> 	And in the case where this extra strengh is needed we can do
> strong auth and signed ops on the directory service.. with DAP - you
> know the protocol thats half the size of LDAP with twicw as many feature
> including trusted signed operations :-))).
> 
> 
> > <lots more text delted>
> > 
> > >	However, with a robust - distributed directory service - that is
> > >designed to be robust - some of those concerns should dissipate.
> > After
> > >all the phone system is a very big infrastructure that in general
> > >supports a service and one tends to think that any failure in any
> > >component does not bring the whole system down. Infrastructure design
> > >always makes sure that their is no single point of failure for the
> > whole
> > >service and that any failure only criples a componenet of area of the
> > >service.
> > >	All I am saying that directory system designs should parallel
> > >the phone system re replicated/distributed paths and redundancy
> > >features. Thus a "trust" can be placed on them - like any
> > infrastructure
> > >- water, gas, roads, etc. Otherwise what is the alternative to the
> > >design of large scale systems?
> > 
> > Well, I now work for a phone company, and I do not believe the analogy
> > is a
> > good one.  Directories in the phone system have very simple access
> > models
> > and (legitimate) subscribers have very restricted access capabilities.
> > When phone phreaks have gone after the phone system, they are often
> > successful. The fundamental issue here is that one should rely on any
> > infrastructure ONLY to the extent that is intrinsic in that
> > infrastructure.
> > When we rely on infrastructures in ways beyond their design intent, we
> > get
> > into trouble.  the OCSP server ID example does that, in my opinion.
> > 
> 	We need to talk re the two paradigms. Many people find the phone
> system/directory system paradigm very useful.
> 	As for infrastructures. They tend to be in fact very big systems
> - by definition. If OCSP wants to be big - it will become an
> infrastructure - but if it wants to be big it will have to be supported
> by a big distributed information base... some thing like a directory
> service. Otherwise its hand carved...
> 
> 
> 
> > <still more text deleted>
> > 
> > >>
> > >	Thats the CA theory view that may not serve an operational
> > >world. The transaction with a cert has a business/policy component
> > also
> > >and that must be tied to the cost/trust/business models that apply
> > >certificates. ie. the theoretical CA model need not rule in all
> > cases.
> > 
> > Of course PKI designs are driven by many factors, but that doesn't
> > mean we
> > have to be sloppy about security, and you have not provided any models
> > that
> > quantitatively compare the tow models we are debating.  This is the
> > PKIX
> > mailing list in the IETF; we worry about real CA concerns, not just
> > theoretical ones. Your directory-centric perspective on these issues
> > strikes me as much more theoretical :-).
> > 
> 	Theory ! Oh really. How many OCSP servers will be needed for 100
> m users. What is the information system that supports this?
> > <yet more text deleted>
> > 
> > >	As said, when one designs a distributed directory service
> > >infrastructure with directory enabled processes attached to the
> > service
> > >for such things like org chart generation, subject matter context
> > >clumping  and possibly cert validation and... specialised seach/data
> > >engines for fingerprint validation, etc , then these processes by
> > nature
> > >are context sensitive (or insesnitive) - mult path, distributed
> > >processes . ie with directory enabled distributed processing, the
> > whole
> > >system, service and processing paradigms change - including the
> > >configuration and single point of failure models.
> > >
> > >
> > >	The telephone network is very similar to the PKI validation
> > >model that is needed for global services. Multi domains, multi
> > services,
> > >global roaming and distributed-fast authentication. As directories
> > make
> > >the phone system work, so will directories make big PKIs work.
> > 
> > As I noted above, I work for a large phone company and I dispute the
> > validity of the analogy.  What it seems to boil down to is an
> > assertion by
> > you that directories will be ubiquitous, very fast, ultra reliable,
> > and
> > sufficiently secure so that we should abandon the crypto-integrity
> > model
> > upon which X.509 is based.  
> > 
> 	Thats it. Got it in one. 
> 
> > Clearly this is not the case today, so let's
> > just see if the directory model you envision comes to pass.  if so,
> > I'll
> > withdraw my objections.  
> > 
> 	Its coming to pass. Simply bnecause all those "servers" being
> promoted need ... wait for it...
> 	Information and for that information to be applied in a
> distributed and common way.
> 
> > However, in the mean time, I suggest that we not
> > degrade the security of PKIs based on these projections.
> > 
> 	No infact we are enhancing the PKI with the reality of deployed
> directory systems.
> 	A PKI without a business purpose and information and service
> deployment scaleability will be an orphan technology.
> 	regards alan
> 
> > Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14224 for ietf-pkix-bks; Sun, 31 Jan 1999 14:36:44 -0800 (PST)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14220 for <[e-mail]>; Sun, 31 Jan 1999 14:36:41 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <DLNAT1MP>; Mon, 1 Feb 1999 09:37:44 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A62B5@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'WHenry'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Attribute used to store cached certificate chains?
Date: Mon, 1 Feb 1999 09:37:42 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
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 OAA14221
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In my opinion a signed document is archived for a purpose i.e. the potential
for it to be retrieved as evidence at some point in time.  If this
perspective is taken, then one wants to have the document as self-sufficient
as possible.  

I think a document retrieved 7 years hence, will be more easy to validate if
all of its certificates are embedded.  Otherwise, one could have a complex
task to attempt to retrieve a number of CA certs, possibly expired and
purged from most systems.

CRLs are another issue again, but maybe there's a hope that CAs archive them
as a customer service, if not then the customers who care about these
things, certainly should archive them!

eCommerce brings with it the eRecordsManagement issue which has yet to be
addressed!

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	WHenry [SMTP:[e-mail]]
> Sent:	Saturday, January 30, 1999 1:24 AM
> To:	'[e-mail]'
> Cc:	'[e-mail]'
> Subject:	FW: Attribute used to store cached certificate chains?
> 
>  Maintaining a copy of a user's certificate chain has implications for
> digitally signed archives, as well. 
> 
>  In the case of an archived (and signed) document, should the document
> itself retain a copy of the certificate chain to aid in validation? Or
> will PKI's/Directories support future path validation for archived
> documents?
> 
>  Thoughts/comments? 
> 
>  Bill Henry 
>  Performance Engineering Corporation 
> 
> -----Original Message----- 
> From:   Tammy Carter [SMTP:[e-mail]] 
> Sent:   Thursday, January 28, 1999 7:09 PM 
> To:     [e-mail]; [e-mail];
> [e-mail] 
> Subject:        RE: Attribute used to store cached certificate chains? 
> 
> Hi, Alan, 
> 
> Thanks for clarifying.  It _is_ incorrect to say that an entire directory
> is off-line. 
> (Well, unless all the server's holding replicas have all gone down at 
> exactly the same moment.)  
> 
> What I was referring to was more the inability of the user to read the set
> of 
> objects from which a chain can be constructed.  This inability could 
> be caused by network outages (planned or unexpected), a bad 
> replication scheme, or even the inability of the client to communicate 
> with the necessary servers using the right protocols. 
> 
> For example, picture a company's tree that spans the world.  Servers 
> are on every continent.  I have a certificate, stored on my user object.  
> I travel to China for a month of consulting in our branch office.  My 
> administrator, thinking ahead, puts a replica of the partition containing 
> my user object on a server in China so that a copy of my object is 
> being maintained locally.  Now, I want to send email and I need to 
> send a certificate chain with my S/MIME message.  My CA has an 
> object in the tree, but only Utah servers hold replicas of it's 
> partition.  Unfortunately, due to network problems, I can't get 
> to my CA's object.  
> 
> It would seem reasonable to store a cached copy of the user's 
> certificate chain on their object rather than forcing the user to 
> store it on the client's file system, or on a floppy disk.  This 
> allows a "free seating policy" so that users can go to any 
> client and perform their job functions without having to carry 
> around floppy disks. 
> 
> My initial question was:  has anyone thought of caching this 
> information in the directory yet?  If so, what attributes are being 
> used? 
> 
> 
> Tammy Green Carter 
> [e-mail] 
> 
> 
> >>> Alan Lloyd <[e-mail]> 1-28-99 3:03:33 PM >>> 
> Some comments 
> 
> This debate seems to say that a directory tree is unavailable and 
> therefore local caching is used. It would strike me that a major part of 
> the system design of an organisation's information system. eg HR, 
> database or PABX or RADIUS directory,  that replica's are placed at 
> certain points to avoid service failures. Although there are major 
> functional distinctions between a database, a file system, a directory 
> service, etc. The system design and operational deployment of all of 
> these things makes sure that service levels are maintained. Saying that 
> "a directory" is off line is like saying a database is off line or the 
> file server is off line. I would expect that a User who is mobile to 
> contain on their local directory/file system all the things that support 
> that environment eg address books, mail boxes and a bunch of keys and 
> certs..which can be replica entries of the CAs system. 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14101 for ietf-pkix-bks; Sun, 31 Jan 1999 14:09:00 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14097 for <[e-mail]>; Sun, 31 Jan 1999 14:08:52 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <1AYDD2QP>; Mon, 1 Feb 1999 09:11:39 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC0943AA@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Date: Mon, 1 Feb 1999 09:11:37 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Sunday, January 31, 1999 7:16 AM
> To:	Alan Lloyd
> Cc:	'Stephen Kent'; [e-mail]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Alan,
> 
> < much text deleted>
> 
> >	One can cite if one attacks a directory entry but I would expect
> >that a CA entry with its cert and CRL DP, etc is well protected from
> >casual writes - protected via authentication mechanisms and access
> >controls for CA modification only. The same issue would be with an
> >unprotected DB .
> 
> Certs and CRLs are signed and thus we rely less on the directiry
> system to
> protect them, since tampering is evident to the user.  As soon as we
> talk
> about relying on unsigned data items in a directory, the security
> situation
> is quite different.
> 
	After N years with military X.500 and PKIs I think I do
understand this. But in addition to signing data, we can also place
"some" trust on the distributed authentication and access controls of
the directory system. Particularly when the user or certficate reader
has been requested to do strong authentication on the directory service
itself to read the CA entry. We do deal with trusted directory systems
you know.
> >
> >	At least the directory provides a distributed, profileable -
> >authentication and ACI regime which will be designed and deployed
> >according to a cost/trust and service model.
> 
> Yes, but that regime should not be relied upon for cert processing,
> exccept
> to mitigate denial of service concerns, i.e., one shoud rely on a
> directory
> in a cert processing context only to the extent that one needs some
> repository for signed objects.  To extend that reliance to unsigned
> objects, in a fashion that could undermine the security of cert
> processing,
> would be negligent.
> 
	And in the case where this extra strengh is needed we can do
strong auth and signed ops on the directory service.. with DAP - you
know the protocol thats half the size of LDAP with twicw as many feature
including trusted signed operations :-))).


> <lots more text delted>
> 
> >	However, with a robust - distributed directory service - that is
> >designed to be robust - some of those concerns should dissipate.
> After
> >all the phone system is a very big infrastructure that in general
> >supports a service and one tends to think that any failure in any
> >component does not bring the whole system down. Infrastructure design
> >always makes sure that their is no single point of failure for the
> whole
> >service and that any failure only criples a componenet of area of the
> >service.
> >	All I am saying that directory system designs should parallel
> >the phone system re replicated/distributed paths and redundancy
> >features. Thus a "trust" can be placed on them - like any
> infrastructure
> >- water, gas, roads, etc. Otherwise what is the alternative to the
> >design of large scale systems?
> 
> Well, I now work for a phone company, and I do not believe the analogy
> is a
> good one.  Directories in the phone system have very simple access
> models
> and (legitimate) subscribers have very restricted access capabilities.
> When phone phreaks have gone after the phone system, they are often
> successful. The fundamental issue here is that one should rely on any
> infrastructure ONLY to the extent that is intrinsic in that
> infrastructure.
> When we rely on infrastructures in ways beyond their design intent, we
> get
> into trouble.  the OCSP server ID example does that, in my opinion.
> 
	We need to talk re the two paradigms. Many people find the phone
system/directory system paradigm very useful.
	As for infrastructures. They tend to be in fact very big systems
- by definition. If OCSP wants to be big - it will become an
infrastructure - but if it wants to be big it will have to be supported
by a big distributed information base... some thing like a directory
service. Otherwise its hand carved...



> <still more text deleted>
> 
> >>
> >	Thats the CA theory view that may not serve an operational
> >world. The transaction with a cert has a business/policy component
> also
> >and that must be tied to the cost/trust/business models that apply
> >certificates. ie. the theoretical CA model need not rule in all
> cases.
> 
> Of course PKI designs are driven by many factors, but that doesn't
> mean we
> have to be sloppy about security, and you have not provided any models
> that
> quantitatively compare the tow models we are debating.  This is the
> PKIX
> mailing list in the IETF; we worry about real CA concerns, not just
> theoretical ones. Your directory-centric perspective on these issues
> strikes me as much more theoretical :-).
> 
	Theory ! Oh really. How many OCSP servers will be needed for 100
m users. What is the information system that supports this?
> <yet more text deleted>
> 
> >	As said, when one designs a distributed directory service
> >infrastructure with directory enabled processes attached to the
> service
> >for such things like org chart generation, subject matter context
> >clumping  and possibly cert validation and... specialised seach/data
> >engines for fingerprint validation, etc , then these processes by
> nature
> >are context sensitive (or insesnitive) - mult path, distributed
> >processes . ie with directory enabled distributed processing, the
> whole
> >system, service and processing paradigms change - including the
> >configuration and single point of failure models.
> >
> >
> >	The telephone network is very similar to the PKI validation
> >model that is needed for global services. Multi domains, multi
> services,
> >global roaming and distributed-fast authentication. As directories
> make
> >the phone system work, so will directories make big PKIs work.
> 
> As I noted above, I work for a large phone company and I dispute the
> validity of the analogy.  What it seems to boil down to is an
> assertion by
> you that directories will be ubiquitous, very fast, ultra reliable,
> and
> sufficiently secure so that we should abandon the crypto-integrity
> model
> upon which X.509 is based.  
> 
	Thats it. Got it in one. 

> Clearly this is not the case today, so let's
> just see if the directory model you envision comes to pass.  if so,
> I'll
> withdraw my objections.  
> 
	Its coming to pass. Simply bnecause all those "servers" being
promoted need ... wait for it...
	Information and for that information to be applied in a
distributed and common way.

> However, in the mean time, I suggest that we not
> degrade the security of PKIs based on these projections.
> 
	No infact we are enhancing the PKI with the reality of deployed
directory systems.
	A PKI without a business purpose and information and service
deployment scaleability will be an orphan technology.
	regards alan

> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19040 for ietf-pkix-bks; Sat, 30 Jan 1999 13:33:05 -0800 (PST)
Received: from irwell.zetnet.co.uk ([e-mail] [194.247.47.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19036 for <[e-mail]>; Sat, 30 Jan 1999 13:33:03 -0800 (PST)
Received: from zetnet.co.uk (man-185.dialup.zetnet.co.uk [194.247.40.235]) by irwell.zetnet.co.uk (8.8.7/8.8.5) with SMTP id VAA08952; Sat, 30 Jan 1999 21:35:19 GMT
Message-Id: <[e-mail]>
From: "David Chadwick" <[e-mail]>
Organization: University of Salford
To: Bill Burr <[e-mail]>, ietf-pkix <[e-mail]>, Al Arsenault <[e-mail]>
Date: Sat, 30 Jan 1999 21:34:18 -0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Terminology question:  "root CA"
Reply-to: [e-mail]
In-reply-to: <4.1.19990128085211.00aa0b50@209.172.119.123>
References: <[e-mail]>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

From:           	Al Arsenault <[e-mail]>
Subject:        	Re: Terminology question:  "root CA"

I much prefer Al's suggestion below rather than Warwicks.

Al's definition of rootCA is absolute - i.e. the root CA is fixed -  
whereas Warwick's is relative and depends upon the perspective of 
the relying party. But the name rootCA does not imply relativity. 
However the term trust anchor or most trusted CA does imply 
relativity since you are automatically led to ask the question 
"trusted by whom" - and the answer is "the relying party" of course. 

David


> Folks,
> 
>
>  My personal choice is, as I've stated, to say that a CA at the top of a
> hierarchy - which must have a self-signed cert, by virtue of being the
> "top" - be called a "root CA".  As Bill Burr pointed out, this is more
> consistent with graph-theory notation than the CMP wording.  Note that it
> is perfectly legitimate to have a degenerate hierarchy, which consists of
> exactly one CA with a self-signed cert, and some users below it.  This
> degenerate hierarchy can then be cross-certified in peer-to-peer
> relationships with other such degenerate hierarchies (or even with other,
> non-degenerate hierarchies, as described above).  All of the graph-theory
> results still hold.
> 
>  Then, we need a term for what CMP calls a "root CA".  PKIX-1 calls it a
> "most-trusted CA"; I can live with that, but prefer the term "trust
> anchor". 

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

David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel [phone]  Fax [phone]
Mobile [phone]
Email [e-mail]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18780 for ietf-pkix-bks; Sat, 30 Jan 1999 12:37:12 -0800 (PST)
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 MAA18776 for <[e-mail]>; Sat, 30 Jan 1999 12:37:11 -0800 (PST)
Received: from [128.33.238.94] (TC094.BBN.COM [128.33.238.94]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id PAA16030; Sat, 30 Jan 1999 15:39:49 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04011717b2d7e8bd4552@[128.33.238.173]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC09437A@DSG1>
Date: Sat, 30 Jan 1999 15:15:58 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Cc: "'Stephen Kent'" <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

< much text deleted>

>	One can cite if one attacks a directory entry but I would expect
>that a CA entry with its cert and CRL DP, etc is well protected from
>casual writes - protected via authentication mechanisms and access
>controls for CA modification only. The same issue would be with an
>unprotected DB .

Certs and CRLs are signed and thus we rely less on the directiry system to
protect them, since tampering is evident to the user.  As soon as we talk
about relying on unsigned data items in a directory, the security situation
is quite different.

>
>	At least the directory provides a distributed, profileable -
>authentication and ACI regime which will be designed and deployed
>according to a cost/trust and service model.

Yes, but that regime should not be relied upon for cert processing, exccept
to mitigate denial of service concerns, i.e., one shoud rely on a directory
in a cert processing context only to the extent that one needs some
repository for signed objects.  To extend that reliance to unsigned
objects, in a fashion that could undermine the security of cert processing,
would be negligent.

<lots more text delted>

>	However, with a robust - distributed directory service - that is
>designed to be robust - some of those concerns should dissipate. After
>all the phone system is a very big infrastructure that in general
>supports a service and one tends to think that any failure in any
>component does not bring the whole system down. Infrastructure design
>always makes sure that their is no single point of failure for the whole
>service and that any failure only criples a componenet of area of the
>service.
>	All I am saying that directory system designs should parallel
>the phone system re replicated/distributed paths and redundancy
>features. Thus a "trust" can be placed on them - like any infrastructure
>- water, gas, roads, etc. Otherwise what is the alternative to the
>design of large scale systems?

Well, I now work for a phone company, and I do not believe the analogy is a
good one.  Directories in the phone system have very simple access models
and (legitimate) subscribers have very restricted access capabilities.
When phone phreaks have gone after the phone system, they are often
successful. The fundamental issue here is that one should rely on any
infrastructure ONLY to the extent that is intrinsic in that infrastructure.
When we rely on infrastructures in ways beyond their design intent, we get
into trouble.  the OCSP server ID example does that, in my opinion.

<still more text deleted>

>>
>	Thats the CA theory view that may not serve an operational
>world. The transaction with a cert has a business/policy component also
>and that must be tied to the cost/trust/business models that apply
>certificates. ie. the theoretical CA model need not rule in all cases.

Of course PKI designs are driven by many factors, but that doesn't mean we
have to be sloppy about security, and you have not provided any models that
quantitatively compare the tow models we are debating.  This is the PKIX
mailing list in the IETF; we worry about real CA concerns, not just
theoretical ones. Your directory-centric perspective on these issues
strikes me as much more theoretical :-).

<yet more text deleted>

>	As said, when one designs a distributed directory service
>infrastructure with directory enabled processes attached to the service
>for such things like org chart generation, subject matter context
>clumping  and possibly cert validation and... specialised seach/data
>engines for fingerprint validation, etc , then these processes by nature
>are context sensitive (or insesnitive) - mult path, distributed
>processes . ie with directory enabled distributed processing, the whole
>system, service and processing paradigms change - including the
>configuration and single point of failure models.
>
>
>	The telephone network is very similar to the PKI validation
>model that is needed for global services. Multi domains, multi services,
>global roaming and distributed-fast authentication. As directories make
>the phone system work, so will directories make big PKIs work.

As I noted above, I work for a large phone company and I dispute the
validity of the analogy.  What it seems to boil down to is an assertion by
you that directories will be ubiquitous, very fast, ultra reliable, and
sufficiently secure so that we should abandon the crypto-integrity model
upon which X.509 is based.  Clearly this is not the case today, so let's
just see if the directory model you envision comes to pass.  if so, I'll
withdraw my objections.  However, in the mean time, I suggest that we not
degrade the security of PKIs based on these projections.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA17913 for ietf-pkix-bks; Sat, 30 Jan 1999 12:15:01 -0800 (PST)
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 MAA17906 for <[e-mail]>; Sat, 30 Jan 1999 12:15:00 -0800 (PST)
Received: from [128.33.238.94] (TC094.BBN.COM [128.33.238.94]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id PAA14140; Sat, 30 Jan 1999 15:17:26 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v0401170eb2d7dbae5bc3@[128.33.238.173]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0943A5@DSG1>
Date: Fri, 29 Jan 1999 17:57:18 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Attribute used to store cached certificate chains?
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

Of course one wants directories to be highly available, but that does not
detract from the utility of a local cache with regard to improved
performance, and support for unconnected operation. Note that the
performance issues are not only associated with communication delays, but
also the need to re-verify signatures on certificates along a cert path. It
is NOT a good idea to store information that can be used to short circuit
cert chain validation in a directory, w/o cryptograophic integrity measures.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA17903 for ietf-pkix-bks; Sat, 30 Jan 1999 12:14:08 -0800 (PST)
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 MAA17899 for <[e-mail]>; Sat, 30 Jan 1999 12:14:06 -0800 (PST)
Received: from [128.33.238.94] (TC094.BBN.COM [128.33.238.94]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id PAA14099; Sat, 30 Jan 1999 15:16:50 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v0401170ab2d7cdbe0ba8@[128.33.238.173]>
In-Reply-To: <[e-mail]>
Date: Fri, 29 Jan 1999 17:56:33 -0500
To: "Tammy Carter" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Attribute used to store cached certificate chains?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tammy,

I agree wholeheartedly with your observations.  I've designed a number of
certificate-enabled systems over the last decade, and they have always
included the notion of a local cache of validated certificates and CRLs.
Directory access is not always feasible, and it always imposes some costs
in terms of delays.  Caches are a fine way to improve performance in
certificate chain validation, and a well-understood part of most system
designs.

The separate question is how to make such caches mobile, when a user is not
able to bring his/her computing environment along in all cases  In that
context I think it very appropriate to provide a well-defined directory
attribute for use in storing a crypto-protected cert, CRL, and key context.
At the RSA show a week ago, this was a common theme. The basic concept is
not new; it appears in the DEC Distributed System Security Architecture
published in the latter 80s, e.g., in the IEEE Security and Privacy
Symposium.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA17003 for ietf-pkix-bks; Fri, 29 Jan 1999 14:36:23 -0800 (PST)
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 OAA16999 for <[e-mail]>; Fri, 29 Jan 1999 14:36:22 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id OAA17761; Fri, 29 Jan 1999 14:35:22 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id OAA20352; Fri, 29 Jan 1999 14:38:34 -0800 (PST)
Received: by NEWMAN with Internet Mail Service (5.5.2232.9) id <D6Y6A01P>; Fri, 29 Jan 1999 14:38:38 -0800
Message-ID: <23E9E6DBBF4DD21190BC006008B0213E3ADFD8@NEWMAN>
From: Warwick Ford <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: Terminology question:  "root CA"
Date: Fri, 29 Jan 1999 14:38:37 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

An unfortunate typo in my final line -- "consistent" should have been
"inconsistent" -- i.e., I am unconvinced there is a problem with the
standards.

Warwick

-----Original Message-----
From: Warwick Ford [mailto:[e-mail]] 
Sent: Friday, January 29, 1999 7:01 AM
To: Al Arsenault; ietf-pkix
Subject: RE: Terminology question: "root CA"


Al:

I have always viewed it this way.  In PKIX, "root CA" is a term that is
relative to a relying party -- not a subscriber nor PKI community.  A root
CA is a CA whose public key is trusted a priori to validation of a
certificate chain.  (Such a root CA will often have a self-signed
certificate but other ways of distributing a root CA public key are not
precluded.) We explicitly agreed in the early stages of the PKIX project
that the structuring of CAs in the overall PKI is not restricted to a
hierarchy and can, from the PKIX profile perspective, be any arbitrary
structure.  For that reason we don't recognize the concept of "root of a
hierarchy" in PKIX.

Of course, in practice, PKIs are almost always structured as hierarchies (or
sets of hierarchies), and a relying party will trust, as its root CAs,
either CAs at the apexes of hierarchies or possibly a local CA which issues
certificates to CAs at the apexes of hierarchies.

I don't see how any of the PKIX documents are consistent with this view.

Warwick

> -----Original Message-----
> From: Al Arsenault [mailto:[e-mail]]
> Sent: Thursday, January 28, 1999 6:04 AM
> To: [e-mail]; Bill Burr; Brian Korver; Arnoud Galactus
> Engelfriet; ietf-pkix
> Subject: Re: Terminology question: "root CA"
> 
> 
> Folks,
> 
> 	Okay, let me try to clarify with a scenario:
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA16472 for ietf-pkix-bks; Fri, 29 Jan 1999 13:31:11 -0800 (PST)
Received: from mainserver.surfnetusa.com (mainserver.surfnetusa.com [208.201.152.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16468 for <[e-mail]>; Fri, 29 Jan 1999 13:31:10 -0800 (PST)
Received: from [208.201.152.17] by mainserver.surfnetusa.com (NTMail 4.01.0014/AX0201.00.c205c0ba) with ESMTP id hfbacaaa for <[e-mail]>; Fri, 29 Jan 1999 13:33:59 -0800
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04011702b2d7da8476ff@[208.201.152.17]>
Date: Fri, 29 Jan 1999 13:37:44 -0800
To: [e-mail]
From: Cynthia Deno <[e-mail]>
Subject: USENIX NETWORKING '99
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

For the first time, USENIX and SAGE are bringing together the
community

of network administrators -- Share in expertise learned at sites of all
sizes from throughout the world. Gain mastery of new technologies,
techniques, and strategies for managing complex networks. 


Tutorials * Invited Talks * Refereed Papers * Hosted Luncheons

 * Receptions * Birds-of-a-Feather Sessions


NETWORKING '99

   April 7-12, 1999

   Santa Clara Marriott Hotel

   Santa Clara, California, USA


Sponsored by USENIX, the Advanced Computing Systems Association

Co-Sponsored by SAGE, the System Administrators Guild


WEB SITE: http://www.usenix.org/networking99


Networking '99 includes:


CONFERENCE ON NETWORK ADMINISTRATION

Wednesday and Thursday, April 7-8, 1999

     Outstanding speakers share their expertise and experience of the

latest network technologies in case studies of real networks and 

refereed research papers.


NETWORKING TUTORIAL PROGRAM

Friday and Saturday, April 9-10, 1999

     Courses tailored to many levels of experience and spanning a wide

range of topics in network administration and computer security. 
Bring

home skills you can use immediately.


WORKSHOP ON INTRUSION DETECTION AND NETWORK MONITORING

Sunday and Monday, April 11-12, 1999

      Meet and learn from the researchers and practitioners who are

deploying the state of the art in techniques and technologies which
can

help you maintain your network's security by "automatically" detecting

weaknesses or attacks in progress.


For the full tutorial and technical program, and online registration,

http://www.usenix.org/networking99

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

The USENIX Association's international membership includes engineers,
scientists, and technicians working on the cutting edge of systems and
software.  SAGE, a special technical group within USENIX, is devoted to
the advancement and recognition of system administration as a
profession.  USENIX and SAGE are co-sponsors of the highly regarded
LISA--System Administrators Conference.   



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA15146 for ietf-pkix-bks; Fri, 29 Jan 1999 11:06:23 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA15142 for <[e-mail]>; Fri, 29 Jan 1999 11:06:22 -0800 (PST)
Received: (qmail 32486 invoked from network); 29 Jan 1999 19:09:02 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 29 Jan 1999 19:09:02 -0000
Received: (qmail 1501 invoked from network); 29 Jan 1999 19:08:56 -0000
Received: from rhone.valicert.com (HELO rhone) (10.0.0.101) by internal-mail.valicert.com with SMTP; 29 Jan 1999 19:08:56 -0000
From: "Ambarish Malpani" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Markus Bitterli'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP and historical data
Date: Fri, 29 Jan 1999 11:10:24 -0800
Message-ID: <00ec01be4bbb$065b5910$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Denis, Markus,
    Yes, you can get historical data from an OCSP responder, as long
as the responder chooses to support archiving of data. Check section
5.4.4.

Regards,
Ambarish



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



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


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]On Behalf
> Of Denis Pinkas
> Sent: Friday, January 29, 1999 2:26 AM
> To: Markus Bitterli
> Cc: [e-mail]
> Subject: Re: OCSP and historical data
> 
> 
> Markus,
> 
> Your analysis is correct. OCSP assumes the current date only.
> 
> > I've read the OCSP draft and wonder whether it is possible 
> to request
> > information about the validity for a certificate for a 
> specific date and
> > time in the past. As I've understood it, this is not 
> possible. If so,
> > has somebody any idea for a solution to that requirement.
> 
> There are several ways. One solution is to gather the 
> appropriate CRL or OCSP
> responses close to the time of the signature.
> If you want to rely on an external service, there have been 
> discussions around
> the DCS draft and the DVS concept: "Data Validation Service". 
> This kind of
> service is supposed to do some verification upon some data 
> that is presented.
> I recently send an E-mail on that topic. Please refer to it.
> 
> Denis
> 
> > Markus Bitterli
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA15038 for ietf-pkix-bks; Fri, 29 Jan 1999 10:56:46 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA15034 for <[e-mail]>; Fri, 29 Jan 1999 10:56:44 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 29 Jan 1999 11:58:55 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 29 Jan 1999 11:58:47 -0700
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Attribute used to store cached certificate chains?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA15035
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have been unable to find anyone in the IETF discussing, or even thinking about this particular issue.  However, I will continue to search the mailing lists for some possible clue.

As it turns out, the people that I have chatted with here at Novell have been quite concerned about storing a certificate chain for each certificate that each user has in the directory, especially because the same chain is likely to be valid for multiple certificates for a given user, and multiple users are also likely to have the same chain (e.g., every user in a particular division will likely get their certificates from the same CA).  Therefore, I have been trying to find a place to cache the chain in the directory to reduce duplicate storage.  

The best idea that I have come up with that involves minimal tree walking is to store a set of "commonly used" certificate chains on each CA's object.  In order to construct a certificate chain for inclusion with an S/MIME message, a user would find the object of the CA that issued his certificate, read the chains stored on the CA's object, and decide what set of certificates should be packaged with the S/MIME message.  

Defining an attribute to put on the CA's object, since it is not the logical place to put a certificate chain, would seem to mean that we will have a proprietary solution which I would rather avoid if possible.  It seems that someone working with a directory must also be facing the same kind of problems.....

You asked about storing the private key.  Currently, Novell's PKI solution encrypts the private key and stores it in the user's object.  The private key is encrypted with a partition specific key such that each server holding a replica of the partition in which the user's object resides can decrypt the private key.  We use ACLs provided by the directory (NDS in our case), to keep unauthorized people from reading the private key.  For those users who don't trust the directory or their administrators, we are working on a solution which will store the private key on a smart card.  When smart cards come along, the obvious place to store the chain is on the smart card, eliminating these issues altogether.

Tammy Green Carter
[e-mail] 


>>> Andrew Probert <[e-mail]> 1-28-99 8:25:27 PM >>>
Ok ..  for free seating and global roaming .. web mail .. semi-thin client
etc.. global profile stuff .. I can see a need.

1.  An auxiliary class for travelling sounds like a good thing, with
suitable attributes, for merging with
cosineNewPilotPerson and StrongAuthUser.  You could take a look at the
RADIUS schema for some possibilities where they are trying to handle some of
these things?

2.  It still leaves an open issue of where does the user get / use their
private key from?.  You'll still need a floppy or a smartcard to complete
the solution .. unless you are somehow going to have the private key held /
used by their server?

Interesting design issue for the Web mail fraternity.



Andew Probert
Rotek Consulting   http://www.rotek.com.au 
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Tammy Carter [SMTP:[e-mail]] 
> Sent:	Friday, January 29, 1999 11:09 AM
> To:	[e-mail]; [e-mail];
> [e-mail] 
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> Hi, Alan,
> 
> Thanks for clarifying.  It _is_ incorrect to say that an entire directory
> is off-line.
> (Well, unless all the server's holding replicas have all gone down at 
> exactly the same moment.)  
> 
> What I was referring to was more the inability of the user to read the set
> of
> objects from which a chain can be constructed.  This inability could
> be caused by network outages (planned or unexpected), a bad
> replication scheme, or even the inability of the client to communicate
> with the necessary servers using the right protocols.
> 
> For example, picture a company's tree that spans the world.  Servers 
> are on every continent.  I have a certificate, stored on my user object.  
> I travel to China for a month of consulting in our branch office.  My 
> administrator, thinking ahead, puts a replica of the partition containing
> my user object on a server in China so that a copy of my object is
> being maintained locally.  Now, I want to send email and I need to
> send a certificate chain with my S/MIME message.  My CA has an
> object in the tree, but only Utah servers hold replicas of it's 
> partition.  Unfortunately, due to network problems, I can't get
> to my CA's object.  
> 
> It would seem reasonable to store a cached copy of the user's
> certificate chain on their object rather than forcing the user to
> store it on the client's file system, or on a floppy disk.  This
> allows a "free seating policy" so that users can go to any
> client and perform their job functions without having to carry
> around floppy disks.
> 
> My initial question was:  has anyone thought of caching this
> information in the directory yet?  If so, what attributes are being
> used?
> 
> 
> Tammy Green Carter
> [e-mail] 
> 
> 
> >>> Alan Lloyd <[e-mail]> 1-28-99 3:03:33 PM >>>
> Some comments
> 
> This debate seems to say that a directory tree is unavailable and
> therefore local caching is used. It would strike me that a major part of
> the system design of an organisation's information system. eg HR,
> database or PABX or RADIUS directory,  that replica's are placed at
> certain points to avoid service failures. Although there are major
> functional distinctions between a database, a file system, a directory
> service, etc. The system design and operational deployment of all of
> these things makes sure that service levels are maintained. Saying that
> "a directory" is off line is like saying a database is off line or the
> file server is off line. I would expect that a User who is mobile to
> contain on their local directory/file system all the things that support
> that environment eg address books, mail boxes and a bunch of keys and
> certs..which can be replica entries of the CAs system.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA14933 for ietf-pkix-bks; Fri, 29 Jan 1999 10:47:47 -0800 (PST)
Received: from 157.22.235.99 (mactivity.com [157.22.235.99]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA14928 for <[e-mail]>; Fri, 29 Jan 1999 10:47:44 -0800 (PST)
Message-Id: <[e-mail]>
Received: from [157.22.235.107] by mactivity.com (AppleShare IP Mail Server 6.1) id 26870 via TCP with SMTP; Fri, 29 Jan 1999 10:51:19 -0800
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Fri, 29 Jan 1999 10:51:06 -0800
Subject: ANN: The Internet Security Conference
From: "Paul Kent" <[e-mail]>
To: [e-mail]
Mime-version: 1.0
X-Priority: 3
Content-type: multipart/alternative; boundary="MS_Mac_OE_3000451866_540457_MIME_Part"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

--MS_Mac_OE_3000451866_540457_MIME_Part
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

The Internet Security Conference
Making the Internet a Safer Place for Electronic Information Assets
April 19-23, 1999 * Fairmont Hotel * San Jose CA


The 2nd presentation of The Internet Security Conference (TISC,
http://tisc.corecom.com) will address the most pressing security
issues confronting Internet-enabled organizations today.

The most respected experts in nearly every field of security will gather in
the Fairmont Hotel, San Jose to present a technical conference and
exhibition, April
19-23, 1999.

The TISC faculty of over 50 experts, including:

* Fred Avolio, security, former product manager for TIS Gauntlet Internet
   Firewall
* Dr. William Hancock, Chief Technology Officer, Network-1
* Charlie Kaufman, Security Architect for Lotus Notes, IBM
* Dr. Stephen Kent, Chief Scientist, Information Security, BBN Technologies
* Rik Farrow, Internet and UNIX Security consultant and author
* Bob Moskowitz, Sr. technical director at the ICSA
* Dr. Radia Perlman, Distinguished Engineer, Sun Microsystems
* Marcus Ranum, firewall expert, CEO & Founder, Network Flight Recorder,
* Dr. Ron Ross, Sr. computer scientist at the Information Technology
Laboratory, NIST

will join Network Computing Magazine's Technology Editors Dan Backman, Mike
Fratto and Dave Willis in presenting workshops, seminars, and a two-day, 30
session Security Symposium.

An Interoperability Lab and Vendor Exhibit will complement the education
offered at TISC. The Interoperability Lab
(http://tisc.corecom.com/lab99.html)
will provide attendees  an opportunity to witness individual product
demonstrations,
conducted by vendor *technical* staff. Attendees will see and participate in
multi-vendor
demonstrations of:

* Network Attack, Penetration, and Intrusion Detection
* IPSec/IKE and CA Interoperability
* IPSec Configuration and Benchmarking
* Policy-Based Security Management
* Layered VPNs for Remote Access and Extranet Connectivity
* Desktop and Internet Application Security
* Authentication as an Enabler for Secure E-Commerce

coordinated by Aventail, Core Competence, Ernst & Young and Network
Computing Magazine.

Entrance to the TISC Interoperability Lab is free to all TISC '99 attendees.

TISC workshop students will receive a guided walking tour of security
technologies on display in the lab

A complete program guide is available at
http://tisc.corecom.com/programguide.pdf

Registration is now open, visit
https://secure.mactivity.com/tisc/register.html
or call 1-800-798-2928. Space is Limited.

The Internet Security Conference is presented by Core Competence, the
respected internetworking, fast packet and network management consulting
firm founded
by Dave Piscitello, and  Network Computing,  the premier technology
solutions
magazine.

Conference Sponsors include
* Compatible Systems * Checkpoint Software Technologies * Ernst & Young *
Microsoft
* Aventail * RadGuard * Internet Devices * NetScreen * 3Com * enCommerce *
RedCreek
* RSA Data Security * TimeStep * Xedia * Network Flight Recorder * Covad
Communications
* Axent Technologies * Kroll-O'Gara ISG* Exodus * Xcert * Network-1 *
Internet Week and NEC

(Visit http://tisc.corecom.com/sponsors.html for new additions to this
list.)
--MS_Mac_OE_3000451866_540457_MIME_Part
Content-type: text/html; charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>ANN: The Internet Security Conference</TITLE>
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF">
<TT>The Internet Security Conference<BR>
Making the Internet a Safer Place for Electronic Information Assets<BR>
April 19-23, 1999 * Fairmont Hotel * San Jose CA<BR>
<BR>
<BR>
The 2nd presentation of The Internet Security Conference (TISC,<BR>
<FONT COLOR=3D"#0000FF"><U>http://tisc.corecom.com</U></FONT>) will address t=
he most pressing security <BR>
issues confronting Internet-enabled organizations today.<BR>
<BR>
The most respected experts in nearly every field of security will gather in=
<BR>
the Fairmont Hotel, San Jose to present a technical conference and exhibiti=
on, April<BR>
19-23, 1999.<BR>
<BR>
The TISC faculty of over 50 experts, including:<BR>
<BR>
* Fred Avolio, security, former product manager for TIS Gauntlet Internet<B=
R>
&nbsp;&nbsp;&nbsp;Firewall<BR>
* Dr. William Hancock, Chief Technology Officer, Network-1 <BR>
* Charlie Kaufman, Security Architect for Lotus Notes, IBM<BR>
* Dr. Stephen Kent, Chief Scientist, Information Security, BBN Technologies=
<BR>
* Rik Farrow, Internet and UNIX Security consultant and author<BR>
* Bob Moskowitz, Sr. technical director at the ICSA<BR>
* Dr. Radia Perlman, Distinguished Engineer, Sun Microsystems<BR>
* Marcus Ranum, firewall expert, CEO &amp; Founder, Network Flight Recorder=
, &nbsp;<BR>
* Dr. Ron Ross, Sr. computer scientist at the Information Technology<BR>
Laboratory, NIST<BR>
<BR>
will join Network Computing Magazine's Technology Editors Dan Backman, Mike=
<BR>
Fratto and Dave Willis in presenting workshops, seminars, and a two-day, 30=
<BR>
session Security Symposium.<BR>
<BR>
An Interoperability Lab and Vendor Exhibit will complement the education<BR=
>
offered at TISC. The Interoperability Lab (<FONT COLOR=3D"#0000FF"><U>http://=
tisc.corecom.com/lab99.html</U></FONT>) <BR>
will provide attendees &nbsp;an opportunity to witness individual product d=
emonstrations, <BR>
conducted by vendor *technical* staff. Attendees will see and participate i=
n multi-vendor<BR>
demonstrations of:<BR>
<BR>
* Network Attack, Penetration, and Intrusion Detection<BR>
* IPSec/IKE and CA Interoperability<BR>
* IPSec Configuration and Benchmarking<BR>
* Policy-Based Security Management<BR>
* Layered VPNs for Remote Access and Extranet Connectivity<BR>
* Desktop and Internet Application Security<BR>
* Authentication as an Enabler for Secure E-Commerce<BR>
<BR>
coordinated by Aventail, Core Competence, Ernst &amp; Young and Network<BR>
Computing Magazine.<BR>
<BR>
Entrance to the TISC Interoperability Lab is free to all TISC '99 attendees=
.<BR>
<BR>
TISC workshop students will receive a guided walking tour of security <BR>
technologies on display in the lab <BR>
<BR>
A complete program guide is available at<BR>
<FONT COLOR=3D"#0000FF"><U>http://tisc.corecom.com/programguide.pdf<BR>
</U></FONT><BR>
Registration is now open, visit<BR>
<FONT COLOR=3D"#0000FF"><U>https://secure.mactivity.com/tisc/register.html<BR=
>
</U></FONT>or call 1-800-798-2928. Space is Limited.<BR>
<BR>
The Internet Security Conference is presented by Core Competence, the<BR>
respected internetworking, fast packet and network management consulting fi=
rm founded<BR>
by Dave Piscitello, and &nbsp;Network Computing, &nbsp;the premier technolo=
gy solutions<BR>
magazine.<BR>
<BR>
Conference Sponsors include<BR>
* Compatible Systems * Checkpoint Software Technologies * Ernst &amp; Young=
 * Microsoft <BR>
* Aventail * RadGuard * Internet Devices * NetScreen * 3Com * enCommerce * =
RedCreek <BR>
* RSA Data Security * TimeStep * Xedia * Network Flight Recorder * Covad Co=
mmunications <BR>
* Axent Technologies * Kroll-O'Gara ISG* Exodus * Xcert * Network-1 * Inter=
net Week and NEC<BR>
<BR>
(Visit <FONT COLOR=3D"#0000FF"><U>http://tisc.corecom.com/sponsors.html</U></=
FONT> for new additions to this<BR>
list.)</TT>
</BODY>
</HTML>

--MS_Mac_OE_3000451866_540457_MIME_Part--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA14469 for ietf-pkix-bks; Fri, 29 Jan 1999 09:52:05 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA14465 for <[e-mail]>; Fri, 29 Jan 1999 09:52:03 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id MAA06147; Fri, 29 Jan 1999 12:53:09 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 29 Jan 1999 12:55:03 -0500
To: WHenry <[e-mail]>
From: Francois Rousseau <[e-mail]>
Subject: Re: FW: Attribute used to store cached certificate chains?
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bill,

Although disk space is quite cheap these days, a repository of archived
(and signed) documents which maintains for each document a copy of the
certificate chain to aid in their validation would then have to store many
duplicated certificate chains, which would be taking superfluous disk space.

However, since a signed document under CMS must identify the signer's
certificate by the issuer's distinguished name and the certificate serial
number, one approach would be to store in a separate "attribute" of such a
repository only one copy of the certificate chain for each signer's
certificate.

Another approach would be not to store the certificate chains but instead
couple a PKI with a Data Certification Server (DCS) or a Data Validation
Service (DVS) in order to provide for a future path validation solution.

Francois Rousseau
AEPOS Technologies

>
>Maintaining a copy of a user's certificate chain has implications for
digitally signed archives, as well. 
>
>In the case of an archived (and signed) document, should the document
itself retain a copy of the certificate chain to aid in validation? Or will
PKI's/Directories support future path validation for archived documents?
>
>Thoughts/comments? 
>
>Bill Henry 
>Performance Engineering Corporation
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA12145 for ietf-pkix-bks; Fri, 29 Jan 1999 06:58:57 -0800 (PST)
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 GAA12141 for <[e-mail]>; Fri, 29 Jan 1999 06:58:56 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id GAA05401; Fri, 29 Jan 1999 06:57:42 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA03537; Fri, 29 Jan 1999 07:00:52 -0800 (PST)
Received: by NEWMAN with Internet Mail Service (5.5.2232.9) id <D6Y6A7PN>; Fri, 29 Jan 1999 07:00:57 -0800
Message-ID: <23E9E6DBBF4DD21190BC006008B0213EA0BE38@NEWMAN>
From: Warwick Ford <[e-mail]>
To: Al Arsenault <[e-mail]>, ietf-pkix <[e-mail]>
Subject: RE: Terminology question:  "root CA"
Date: Fri, 29 Jan 1999 07:00:56 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al:

I have always viewed it this way.  In PKIX, "root CA" is a term that is
relative to a relying party -- not a subscriber nor PKI community.  A root
CA is a CA whose public key is trusted a priori to validation of a
certificate chain.  (Such a root CA will often have a self-signed
certificate but other ways of distributing a root CA public key are not
precluded.) We explicitly agreed in the early stages of the PKIX project
that the structuring of CAs in the overall PKI is not restricted to a
hierarchy and can, from the PKIX profile perspective, be any arbitrary
structure.  For that reason we don't recognize the concept of "root of a
hierarchy" in PKIX.

Of course, in practice, PKIs are almost always structured as hierarchies (or
sets of hierarchies), and a relying party will trust, as its root CAs,
either CAs at the apexes of hierarchies or possibly a local CA which issues
certificates to CAs at the apexes of hierarchies.

I don't see how any of the PKIX documents are consistent with this view.

Warwick

> -----Original Message-----
> From: Al Arsenault [mailto:[e-mail]]
> Sent: Thursday, January 28, 1999 6:04 AM
> To: [e-mail]; Bill Burr; Brian Korver; Arnoud Galactus
> Engelfriet; ietf-pkix
> Subject: Re: Terminology question: "root CA"
> 
> 
> Folks,
> 
> 	Okay, let me try to clarify with a scenario:
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA11679 for ietf-pkix-bks; Fri, 29 Jan 1999 06:20:34 -0800 (PST)
Received: from exchng-fairfax.p-e-c.com (exchng-fairfax.pec.com [204.254.216.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA11675 for <[e-mail]>; Fri, 29 Jan 1999 06:20:33 -0800 (PST)
Received: by EXCHNG-FAIRFAX with Internet Mail Service (5.0.1460.8) id <D7493MA3>; Fri, 29 Jan 1999 09:24:15 -0500
Message-ID: <B4D5CF1358B7D211900F0008C7F450FD03BAB9@EXCHNG-FAIRFAX>
From: WHenry <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: FW: Attribute used to store cached certificate chains?
Date: Fri, 29 Jan 1999 09:24:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BE4B93.0BF83310"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------ =_NextPart_001_01BE4B93.0BF83310
Content-Type: text/plain

 Maintaining a copy of a user's certificate chain has implications for
digitally signed archives, as well.

 In the case of an archived (and signed) document, should the document
itself retain a copy of the certificate chain to aid in validation? Or will
PKI's/Directories support future path validation for archived documents?

 Thoughts/comments?

 Bill Henry
 Performance Engineering Corporation

> -----Original Message-----
> From:	Tammy Carter [SMTP:[e-mail]]
> Sent:	Thursday, January 28, 1999 7:09 PM
> To:	[e-mail]; [e-mail];
> [e-mail]
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> Hi, Alan,
> 
> Thanks for clarifying.  It _is_ incorrect to say that an entire directory
> is off-line.
> (Well, unless all the server's holding replicas have all gone down at 
> exactly the same moment.)  
> 
> What I was referring to was more the inability of the user to read the set
> of
> objects from which a chain can be constructed.  This inability could
> be caused by network outages (planned or unexpected), a bad
> replication scheme, or even the inability of the client to communicate
> with the necessary servers using the right protocols.
> 
> For example, picture a company's tree that spans the world.  Servers 
> are on every continent.  I have a certificate, stored on my user object.  
> I travel to China for a month of consulting in our branch office.  My 
> administrator, thinking ahead, puts a replica of the partition containing
> my user object on a server in China so that a copy of my object is
> being maintained locally.  Now, I want to send email and I need to
> send a certificate chain with my S/MIME message.  My CA has an
> object in the tree, but only Utah servers hold replicas of it's 
> partition.  Unfortunately, due to network problems, I can't get
> to my CA's object.  
> 
> It would seem reasonable to store a cached copy of the user's
> certificate chain on their object rather than forcing the user to
> store it on the client's file system, or on a floppy disk.  This
> allows a "free seating policy" so that users can go to any
> client and perform their job functions without having to carry
> around floppy disks.
> 
> My initial question was:  has anyone thought of caching this
> information in the directory yet?  If so, what attributes are being
> used?
> 
> 
> Tammy Green Carter
> [e-mail] 
> 
> 
> >>> Alan Lloyd <[e-mail]> 1-28-99 3:03:33 PM >>>
> Some comments
> 
> This debate seems to say that a directory tree is unavailable and
> therefore local caching is used. It would strike me that a major part of
> the system design of an organisation's information system. eg HR,
> database or PABX or RADIUS directory,  that replica's are placed at
> certain points to avoid service failures. Although there are major
> functional distinctions between a database, a file system, a directory
> service, etc. The system design and operational deployment of all of
> these things makes sure that service levels are maintained. Saying that
> "a directory" is off line is like saying a database is off line or the
> file server is off line. I would expect that a User who is mobile to
> contain on their local directory/file system all the things that support
> that environment eg address books, mail boxes and a bunch of keys and
> certs..which can be replica entries of the CAs system.

------ =_NextPart_001_01BE4B93.0BF83310
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.0.1460.9">
<TITLE>FW: Attribute used to store cached certificate chains?</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&nbsp;Maintaining a =
copy of a user's certificate chain has implications for digitally =
signed archives, as well.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&nbsp;In the case of =
an archived (and signed) document, should the document itself retain a =
copy of the certificate chain to aid in validation? Or will =
PKI's/Directories support future path validation for archived =
documents?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">&nbsp;Thoughts/comments?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&nbsp;Bill =
Henry</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&nbsp;Performance =
Engineering Corporation</FONT>
</P>

<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tammy Carter [SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, January 28, 1999 7:09 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">[e-mail]; [e-mail]; =
[e-mail]</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">RE: Attribute used to store cached =
certificate chains?</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Hi, Alan,</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Thanks for =
clarifying.&nbsp; It _is_ incorrect to say that an entire directory is =
off-line.</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">(Well, unless all =
the server's holding replicas have all gone down at </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">exactly the same =
moment.)&nbsp; </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">What I was referring =
to was more the inability of the user to read the set of</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">objects from which =
a chain can be constructed.&nbsp; This inability could</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">be caused by =
network outages (planned or unexpected), a bad</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">replication scheme, =
or even the inability of the client to communicate</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">with the necessary =
servers using the right protocols.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">For example, picture =
a company's tree that spans the world.&nbsp; Servers </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">are on every =
continent.&nbsp; I have a certificate, stored on my user object.&nbsp; =
</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">I travel to China =
for a month of consulting in our branch office.&nbsp; My </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">administrator, =
thinking ahead, puts a replica of the partition containing</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">my user object on a =
server in China so that a copy of my object is</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">being maintained =
locally.&nbsp; Now, I want to send email and I need to</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">send a certificate =
chain with my S/MIME message.&nbsp; My CA has an</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">object in the tree, =
but only Utah servers hold replicas of it's </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">partition.&nbsp; =
Unfortunately, due to network problems, I can't get</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">to my CA's =
object.&nbsp; </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">It would seem =
reasonable to store a cached copy of the user's</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">certificate chain =
on their object rather than forcing the user to</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">store it on the =
client's file system, or on a floppy disk.&nbsp; This</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">allows a &quot;free =
seating policy&quot; so that users can go to any</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">client and perform =
their job functions without having to carry</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">around floppy =
disks.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">My initial question =
was:&nbsp; has anyone thought of caching this</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">information in the =
directory yet?&nbsp; If so, what attributes are being</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">used?</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tammy Green =
Carter</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">[e-mail] =
</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;&gt;&gt; Alan =
Lloyd &lt;[e-mail]&gt; 1-28-99 3:03:33 PM =
&gt;&gt;&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Some =
comments</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">This debate seems to =
say that a directory tree is unavailable and</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">therefore local =
caching is used. It would strike me that a major part of</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">the system design =
of an organisation's information system. eg HR,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">database or PABX or =
RADIUS directory,&nbsp; that replica's are placed at</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">certain points to =
avoid service failures. Although there are major</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">functional =
distinctions between a database, a file system, a directory</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">service, etc. The =
system design and operational deployment of all of</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">these things makes =
sure that service levels are maintained. Saying that</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&quot;a =
directory&quot; is off line is like saying a database is off line or =
the</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">file server is off =
line. I would expect that a User who is mobile to</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">contain on their =
local directory/file system all the things that support</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">that environment eg =
address books, mail boxes and a bunch of keys and</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">certs..which can be =
replica entries of the CAs system.</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BE4B93.0BF83310--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA05120 for ietf-pkix-bks; Fri, 29 Jan 1999 02:22:56 -0800 (PST)
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 CAA05116 for <[e-mail]>; Fri, 29 Jan 1999 02:22:54 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id LAA22960; Fri, 29 Jan 1999 11:25:29 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA20658; Fri, 29 Jan 1999 11:28:12 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Fri, 29 Jan 1999 11:25:53 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Markus Bitterli <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP and historical data
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Markus,

Your analysis is correct. OCSP assumes the current date only.

> I've read the OCSP draft and wonder whether it is possible to request
> information about the validity for a certificate for a specific date and
> time in the past. As I've understood it, this is not possible. If so,
> has somebody any idea for a solution to that requirement.

There are several ways. One solution is to gather the appropriate CRL or OCSP
responses close to the time of the signature.
If you want to rely on an external service, there have been discussions around
the DCS draft and the DVS concept: "Data Validation Service". This kind of
service is supposed to do some verification upon some data that is presented.
I recently send an E-mail on that topic. Please refer to it.

Denis

> Markus Bitterli



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA04547 for ietf-pkix-bks; Fri, 29 Jan 1999 01:43:38 -0800 (PST)
Received: from uranus.ubs.com (uranus.ubs.com [193.134.254.67]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA04539 for <[e-mail]>; Fri, 29 Jan 1999 01:43:36 -0800 (PST)
Received: by uranus.ubs.com; id KAA20665; Fri, 29 Jan 1999 10:45:48 +0100 (MET)
Received: from svscan(192.168.85.11) by uranus.ubs.com via smap (4.1) id xma019946; Fri, 29 Jan 99 10:44:41 +0100
Received: from localhost by svscan.ubinet.ubs.com (SMI-8.6/SMI-SVR4) id KAA01015; Fri, 29 Jan 1999 10:44:35 +0100
Message-ID: <[e-mail]>
Date: Fri, 29 Jan 1999 10:44:21 +0100
From: Markus Bitterli <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: OCSP and historical data
Content-Type: multipart/mixed; boundary="MimeMultipartBoundary"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

I've read the OCSP draft and wonder whether it is possible to request
information about the validity for a certificate for a specific date and
time in the past. As I've understood it, this is not possible. If so,
has somebody any idea for a solution to that requirement.

Markus Bitterli

--MimeMultipartBoundary--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA04432 for ietf-pkix-bks; Fri, 29 Jan 1999 01:42:51 -0800 (PST)
Received: from uranus.ubs.com (uranus.ubs.com [193.134.254.67]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA04424 for <[e-mail]>; Fri, 29 Jan 1999 01:42:48 -0800 (PST)
Received: by uranus.ubs.com; id KAA20111; Fri, 29 Jan 1999 10:44:55 +0100 (MET)
Received: from svscan(192.168.85.11) by uranus.ubs.com via smap (4.1) id xma019794; Fri, 29 Jan 99 10:44:25 +0100
Received: from localhost by svscan.ubinet.ubs.com (SMI-8.6/SMI-SVR4) id KAA00334; Fri, 29 Jan 1999 10:42:26 +0100
Message-ID: <[e-mail]>
Date: Fri, 29 Jan 1999 10:42:01 +0100
From: Markus Bitterli <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: OCSP and historical data
Content-Type: multipart/mixed; boundary="MimeMultipartBoundary"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

I've read the OCSP draft and wonder whether it is possible to request
information about the validity for a certificate for a specific date and
time in the past. As I've understood it, this is not possible. If so,
has somebody any idea for a solution to that requirement.

Markus Bitterli

--MimeMultipartBoundary--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA14077 for ietf-pkix-bks; Thu, 28 Jan 1999 19:24:59 -0800 (PST)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA14065 for <[e-mail]>; Thu, 28 Jan 1999 19:24:56 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <DLNAT1G8>; Fri, 29 Jan 1999 14:25:28 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A62A8@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Tammy Carter'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Attribute used to store cached certificate chains?
Date: Fri, 29 Jan 1999 14:25:27 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ok ..  for free seating and global roaming .. web mail .. semi-thin client
etc.. global profile stuff .. I can see a need.

1.  An auxiliary class for travelling sounds like a good thing, with
suitable attributes, for merging with
cosineNewPilotPerson and StrongAuthUser.  You could take a look at the
RADIUS schema for some possibilities where they are trying to handle some of
these things?

2.  It still leaves an open issue of where does the user get / use their
private key from?.  You'll still need a floppy or a smartcard to complete
the solution .. unless you are somehow going to have the private key held /
used by their server?

Interesting design issue for the Web mail fraternity.



Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Tammy Carter [SMTP:[e-mail]]
> Sent:	Friday, January 29, 1999 11:09 AM
> To:	[e-mail]; [e-mail];
> [e-mail]
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> Hi, Alan,
> 
> Thanks for clarifying.  It _is_ incorrect to say that an entire directory
> is off-line.
> (Well, unless all the server's holding replicas have all gone down at 
> exactly the same moment.)  
> 
> What I was referring to was more the inability of the user to read the set
> of
> objects from which a chain can be constructed.  This inability could
> be caused by network outages (planned or unexpected), a bad
> replication scheme, or even the inability of the client to communicate
> with the necessary servers using the right protocols.
> 
> For example, picture a company's tree that spans the world.  Servers 
> are on every continent.  I have a certificate, stored on my user object.  
> I travel to China for a month of consulting in our branch office.  My 
> administrator, thinking ahead, puts a replica of the partition containing
> my user object on a server in China so that a copy of my object is
> being maintained locally.  Now, I want to send email and I need to
> send a certificate chain with my S/MIME message.  My CA has an
> object in the tree, but only Utah servers hold replicas of it's 
> partition.  Unfortunately, due to network problems, I can't get
> to my CA's object.  
> 
> It would seem reasonable to store a cached copy of the user's
> certificate chain on their object rather than forcing the user to
> store it on the client's file system, or on a floppy disk.  This
> allows a "free seating policy" so that users can go to any
> client and perform their job functions without having to carry
> around floppy disks.
> 
> My initial question was:  has anyone thought of caching this
> information in the directory yet?  If so, what attributes are being
> used?
> 
> 
> Tammy Green Carter
> [e-mail] 
> 
> 
> >>> Alan Lloyd <[e-mail]> 1-28-99 3:03:33 PM >>>
> Some comments
> 
> This debate seems to say that a directory tree is unavailable and
> therefore local caching is used. It would strike me that a major part of
> the system design of an organisation's information system. eg HR,
> database or PABX or RADIUS directory,  that replica's are placed at
> certain points to avoid service failures. Although there are major
> functional distinctions between a database, a file system, a directory
> service, etc. The system design and operational deployment of all of
> these things makes sure that service levels are maintained. Saying that
> "a directory" is off line is like saying a database is off line or the
> file server is off line. I would expect that a User who is mobile to
> contain on their local directory/file system all the things that support
> that environment eg address books, mail boxes and a bunch of keys and
> certs..which can be replica entries of the CAs system.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA05722 for ietf-pkix-bks; Thu, 28 Jan 1999 16:06:55 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA05718 for <[e-mail]>; Thu, 28 Jan 1999 16:06:54 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 28 Jan 1999 17:09:02 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Thu, 28 Jan 1999 17:08:52 -0700
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Attribute used to store cached certificate chains?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id QAA05719
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, Alan,

Thanks for clarifying.  It _is_ incorrect to say that an entire directory is off-line.
(Well, unless all the server's holding replicas have all gone down at 
exactly the same moment.)  

What I was referring to was more the inability of the user to read the set of
objects from which a chain can be constructed.  This inability could
be caused by network outages (planned or unexpected), a bad
replication scheme, or even the inability of the client to communicate
with the necessary servers using the right protocols.

For example, picture a company's tree that spans the world.  Servers 
are on every continent.  I have a certificate, stored on my user object.  
I travel to China for a month of consulting in our branch office.  My 
administrator, thinking ahead, puts a replica of the partition containing
my user object on a server in China so that a copy of my object is
being maintained locally.  Now, I want to send email and I need to
send a certificate chain with my S/MIME message.  My CA has an
object in the tree, but only Utah servers hold replicas of it's 
partition.  Unfortunately, due to network problems, I can't get
to my CA's object.  

It would seem reasonable to store a cached copy of the user's
certificate chain on their object rather than forcing the user to
store it on the client's file system, or on a floppy disk.  This
allows a "free seating policy" so that users can go to any
client and perform their job functions without having to carry
around floppy disks.

My initial question was:  has anyone thought of caching this
information in the directory yet?  If so, what attributes are being
used?


Tammy Green Carter
[e-mail] 


>>> Alan Lloyd <[e-mail]> 1-28-99 3:03:33 PM >>>
Some comments

This debate seems to say that a directory tree is unavailable and
therefore local caching is used. It would strike me that a major part of
the system design of an organisation's information system. eg HR,
database or PABX or RADIUS directory,  that replica's are placed at
certain points to avoid service failures. Although there are major
functional distinctions between a database, a file system, a directory
service, etc. The system design and operational deployment of all of
these things makes sure that service levels are maintained. Saying that
"a directory" is off line is like saying a database is off line or the
file server is off line. I would expect that a User who is mobile to
contain on their local directory/file system all the things that support
that environment eg address books, mail boxes and a bunch of keys and
certs..which can be replica entries of the CAs system.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA05643 for ietf-pkix-bks; Thu, 28 Jan 1999 16:01:07 -0800 (PST)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA05639 for <[e-mail]>; Thu, 28 Jan 1999 16:01:04 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <DLNAT1GJ>; Fri, 29 Jan 1999 11:01:34 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A62A4@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: Attribute used to store cached certificate chains?
Date: Fri, 29 Jan 1999 11:01:33 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Yep, caching is how its done by software that is out there today .. people
> aren't validating their own certificates by walking a directory tree.
> Microsoft store them in the CryptoAPI keystore (registry), Netscape in
> their Cryptoki (PKCS#11) keystore, PEM format keystores, etc.
> 
> So, today its proprietary caching, local to the workstation for offline
> use.
> 
> The CA certs and trust chain are typically loaded e.g. from diskette at
> the time her software was installed i.e. out-of-band.  If you don't do
> out-of-band installation of CA certs you are in trouble with trust because
> do you trust your directory link?
> 
> P.S. Sending of your whole trust chain in an SMIME message is optional.
> You could just send your own cert. and its up to the receiving client to
> check it out.
> 
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Solutions
> Tel  [phone]
> Fax [phone]
> 
> 
> 
> -----Original Message-----
> From:	Tammy Carter [SMTP:[e-mail]]
> Sent:	Thursday, January 28, 1999 10:43 AM
> To:	#060#[e-mail]#062#; [e-mail]
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> Andrew,
> 
> The question may seem a bit recursive on the surface, but I 
> don't think that it is.  Alice has a certificate which, after she received
> it, she validated by walking her directory tree.  Now, a couple of
> months later, she needs to use her certificate, but she is disconnected
> from her tree and won't be able to access it until tomorrow.  But,
> she needs to get to her chain today.  Is she out of luck??  Is Alice
> unable to use her key pair unless she can access her directory???
> 
> If so, something is dreadfully wrong here.  That would mean that
> users would be unable to send signed email while disconnected
> from their tree simply because they would be unable to construct
> a suitable chain for inclusion in the S/MIME message. 
> 
> What seems reasonable is that a user would have their certificate
> chain (or some PKCS 7 bag of certificates which can be used to
> verify their certificate) cached somewhere for times when
> they are unable to reach the tree to construct the chain.  Perhaps
> it would be stored on the client, or on a floppy, or in their email 
> package.... somewhere.
> 
> Now, I was thinking about the case where the user is partially
> connected to the tree.  In other words, the user is able to read
> their own object, but is unable to construct the chain.  Could the
> chain be cached in an attribute on the user's object instead of
> on the client?
> 
> Tammy Green Carter
> 
> 
> 
> 
> >>> Andrew Probert <[e-mail]> 1-27-99 3:29:53 PM >>>
> 
> > -----Original Message-----
> > From:	Tammy Carter [SMTP:[e-mail]] 
> > Sent:	Saturday, January 23, 1999 7:06 AM
> > To:	[e-mail] 
> > Subject:	Attribute used to store cached certificate chains?
> > 
> > Consider the following scenario:
> > -----------------------------------------------
> > A user, Alice, is a user of a directory service and the
> > PKI that she uses exists entirely within her own tree.  
> > Due to the nature of the directory, she is often unable
> > to compose her certificate chain (a chain back to a root
> > which she knows and trusts and which other people within
> > her tree know and trust) on the fly by walking her tree.  
> > Sometimes, Alice needs to construct her certificate 
> > chain in order to validate one of her own certificates.  
> > 
> [Andrew Probert]  This sounds a bit recursive!  If she can't validate her
> own chain locally, she's in trouble trust-wise.
> 
> > Other times,
> > she needs to send the certificate chain to another user, Bob, 
> > who may also not be able to walk the tree, but who needs to
> > validate her certificate.
> > 
> 	[Andrew Probert]  PKCS#7 (and the SMIME profile) is typically used
> to do this
> 
> > If Alice wanted to cache her certificate chain in the directory on
> > her user object for use when she was disconnected, what attribute
> > should she store it in?  Has such an attribute been defined yet?
> > 
> 	[Andrew Probert]  Certificates would normally be stored discretely,
> under their own names.  Its up to 
> 	the client software to walk the tree and retrieve each by name etc.
> 
> > Thanks,
> > 
> > Tammy Green Carter
> > [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA04430 for ietf-pkix-bks; Thu, 28 Jan 1999 14:01:07 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA04416 for <[e-mail]>; Thu, 28 Jan 1999 14:00:58 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <DSKVC56H>; Fri, 29 Jan 1999 09:03:34 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC0943A5@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Tammy Carter'" <[e-mail]>, "<" <[e-mail]>, [e-mail]
Subject: RE: Attribute used to store cached certificate chains?
Date: Fri, 29 Jan 1999 09:03:33 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some comments

This debate seems to say that a directory tree is unavailable and
therefore local caching is used. It would strike me that a major part of
the system design of an organisation's information system. eg HR,
database or PABX or RADIUS directory,  that replica's are placed at
certain points to avoid service failures. Although there are major
functional distinctions between a database, a file system, a directory
service, etc. The system design and operational deployment of all of
these things makes sure that service levels are maintained. Saying that
"a directory" is off line is like saying a database is off line or the
file server is off line. I would expect that a User who is mobile to
contain on their local directory/file system all the things that support
that environment eg address books, mail boxes and a bunch of keys and
certs..which can be replica entries of the CAs system.
.

hope this helps.
regards
> -----Original Message-----
> From:	Tammy Carter 
> Sent:	Thursday, January 28, 1999 10:43 AM
> To:	<; [e-mail]
> Subject:	RE: Attribute used to store cached certificate chains?
> 
> Andrew,
> 
> The question may seem a bit recursive on the surface, but I 
> don't think that it is.  Alice has a certificate which, after she
> received
> it, she validated by walking her directory tree.  Now, a couple of
> months later, she needs to use her certificate, but she is
> disconnected
> from her tree and won't be able to access it until tomorrow.  But,
> she needs to get to her chain today.  Is she out of luck??  Is Alice
> unable to use her key pair unless she can access her directory???
> 
> If so, something is dreadfully wrong here.  That would mean that
> users would be unable to send signed email while disconnected
> from their tree simply because they would be unable to construct
> a suitable chain for inclusion in the S/MIME message. 
> 
> What seems reasonable is that a user would have their certificate
> chain (or some PKCS 7 bag of certificates which can be used to
> verify their certificate) cached somewhere for times when
> they are unable to reach the tree to construct the chain.  Perhaps
> it would be stored on the client, or on a floppy, or in their email 
> package.... somewhere.
> 
> Now, I was thinking about the case where the user is partially
> connected to the tree.  In other words, the user is able to read
> their own object, but is unable to construct the chain.  Could the
> chain be cached in an attribute on the user's object instead of
> on the client?
> 
> Tammy Green Carter
> 
> 
> 
> 
> >>> Andrew Probert <[e-mail]> 1-27-99 3:29:53 PM >>>
> 
> > -----Original Message-----
> > From:	Tammy Carter [SMTP:[e-mail]] 
> > Sent:	Saturday, January 23, 1999 7:06 AM
> > To:	[e-mail] 
> > Subject:	Attribute used to store cached certificate chains?
> > 
> > Consider the following scenario:
> > -----------------------------------------------
> > A user, Alice, is a user of a directory service and the
> > PKI that she uses exists entirely within her own tree.  
> > Due to the nature of the directory, she is often unable
> > to compose her certificate chain (a chain back to a root
> > which she knows and trusts and which other people within
> > her tree know and trust) on the fly by walking her tree.  
> > Sometimes, Alice needs to construct her certificate 
> > chain in order to validate one of her own certificates.  
> > 
> [Andrew Probert]  This sounds a bit recursive!  If she can't validate
> her
> own chain locally, she's in trouble trust-wise.
> 
> > Other times,
> > she needs to send the certificate chain to another user, Bob, 
> > who may also not be able to walk the tree, but who needs to
> > validate her certificate.
> > 
> 	[Andrew Probert]  PKCS#7 (and the SMIME profile) is typically
> used
> to do this
> 
> > If Alice wanted to cache her certificate chain in the directory on
> > her user object for use when she was disconnected, what attribute
> > should she store it in?  Has such an attribute been defined yet?
> > 
> 	[Andrew Probert]  Certificates would normally be stored
> discretely,
> under their own names.  Its up to 
> 	the client software to walk the tree and retrieve each by name
> etc.
> 
> > Thanks,
> > 
> > Tammy Green Carter
> > [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02045 for ietf-pkix-bks; Thu, 28 Jan 1999 10:05:52 -0800 (PST)
Received: from pluto.deh.de (pluto.deh.de [194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02041 for <[e-mail]>; Thu, 28 Jan 1999 10:05:41 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id TAA31168; Thu, 28 Jan 1999 19:08:15 +0100
Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id TAA25411; Thu, 28 Jan 1999 19:08:19 +0100
Message-ID: <[e-mail]>
Date: Thu, 28 Jan 1999 19:11:01 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: Terminology question:  "root CA"
References: <4.1.19990127140608.00aa3dd0@209.172.119.123> <4.1.19990128085211.00aa0b50@209.172.119.123>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al,

 
> Suppose that a company establishes a PKI as a simple hierarchy, with a CA,
> T, at the top having a self-signed certificate; and three subordinate CAs,
> A, B, and C, underneath. A, B, and C each have certificates issued by T;
> they do not have self-signed certificates.  Suppose further that in
> furtherance of a business relationship, A cross-certifies with W, a CA
> somewhere else in the world but not in this company's hierarchy.  Now,
> there's a user, call him Fred, who gets a certificate from A.  Either by
> company policy or by personal choice, Fred chooses A -which issued his
> certificate - as his "trust anchor" or "root of trust" or whatever.  That
> is, it is A's public key that Fred acquires via secure means, and Fred
> accepts as valid certificate paths that end with A's certificate.
> 
> (Note that this type of arrangement is explicitly supported by PKIX.  That
> is, there is no requirement that a "most-trusted CA" or "root of a
> certificate path" or whatever we call it have a self-signed certificate.
> See Section 6 of the Profile document, PKIX-1, for an explanation.  That
> section notes that cert path validation is easier if this "most-trusted CA"
> has a self-signed cert, but it doesn't have to.)

Thanks for pointing that out. My preference is that any "most-trusted
CA" has (at least?) one self-signed certificate, but it doesn´t have to.
So, I have to read more carefully next time.

> 
>         In this situation,  PKIX-1 refers to T (from Fred's point of view) as the
> "root CA" and A as the "most-trusted CA".  On the other hand, CMP (also
> from Fred's point of view) refers to A as the "root CA" and doesn't refer
> to T at all.
> 
>         In the roadmap, I'm trying to write a paragraph that addresses what
> happens - particularly to A - if T's key is compromised.

It seems to be difficult. It depends on PKI design. I assume that A´s
certificate issued by T is revoked after T´s key compromise has
appeared. Some issues:

1) Formally, Fred has to accept all certificate paths with endpoint A
even if A´s certificate is revoked. Hopefully, there isn´t any
subliminal trust in T, i. e. A is Fred´s "most-trusted CA" why A has a
valid certificate issued by T. But this seems to be the case in your
example.

2) Hopefully, the designer of this PKI provides all relevant
information, usually contained in a self-signed certificate, in Fred´s
certificate issued by A or equivalent in a valid certificate path that
ends in A.

3) Hopefully, T does not sign the A´s CRL on the behalf of A and the CRL
signing key is not affected by T´s key compromise. 

4) ... to be continued 
 
[PKIX-1] says
The "most-trusted CA" is a matter of policy: it could be a root CA in
   a hierarchical PKI; the CA that issued the verifier's own
   certificate(s); or any other CA in a network PKI.  The path valida-
   tion procedure is the same regardless of the choice of "most-trusted
   CA." [PKIX-1]

I prefer the interpretation that the term "most-trusted CA" is an
operational issue according to the path validation software. That means,
when Fred validates a certificate, he does not check A´s certificate
issued by T. Furthermore, the term "most-trusted" does not influence the
certificate management, especially the revocation management.

Probably, I´ve overseen some facts. But I believe that analysis of your
example is far from being evidently. So, the more interesting fact is
this analysis and, I apologize, not the terminology of T.

>  Here's the
> problem:  how do I refer to T?   Do I use PKIX-1 terms and call T the 'root
> CA' (that's my choice) and A the 'most trusted CA' or 'trust anchor'?  Or,
> do I use CMP terms and call A the "root CA" and make up some other term for T?

Probably the best, repeat the description above, add a figure and call
it T :-)

Tomorrow I am out of office. Have a nice weekend.

Juergen

[...]
>                                 Al Arsenault
> 
> (PS - sorry for the inside joke, but -- the first wise person who suggests
> "root registry" is gonna get the electronic equivalent of a punch in the
> nose, real quick! :-)
> 
> -- these are my opinions only. They do not necessarily reflect the
> opinions of my employer, or of any other organization with which I have a
> relationship.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01087 for ietf-pkix-bks; Thu, 28 Jan 1999 08:27:31 -0800 (PST)
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 IAA01082 for <[e-mail]>; Thu, 28 Jan 1999 08:27:28 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id RAA40264; Thu, 28 Jan 1999 17:30:05 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id RAA12424; Thu, 28 Jan 1999 17:32:47 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Thu, 28 Jan 1999 17:30:27 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
CC: ietf-pkix <[e-mail]>
Subject: Re: Terminology question:  "root CA"
References: <4.1.19990127140608.00aa3dd0@209.172.119.123> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen,

Your statements sound quite reasonable. I have however a minor (?) comment.

> Al, Arnoud, Bill, Brian, all
>
> Firstly, I try to recognize what are the requirements according to a
> PKIX terminology.
> These are - in my opinion - the following
>
> 1) The definition of root-CA shall applicable for both hierarchical and
> non-hierarchical PKIs.
>
> 2) The root-CA shall issue a self-signed certificate called root
> certificate.

It may issue more than one, which will then contain either different security policies
and/or different naming constraints.

Denis


> 3) The root-CA shall appear at the end point of a certificate path that
> is constructed by applying the validation algorithm. The end point of
> the certificate path shall coincide with the directly trusted CA of the
> verifying entity.
>
> 4) The root-CA is free to being cross-certified by another CA or
> root-CA.
>
> Are there other and/or additional suggestions?
>
> The terminology root-CA may be interpreted in the way, that a root-CA is
> the root of a certificate path. This is always true (i. e. in
> hierarchical and non-hierarchical PKIs). Both certification paths and
> root-CAs may not uniquely determined. Nevertheless, the root-CA is in
> all cases the root in the tpological sense, i. e. the root of a
> certification path, which is the subgraph of the whole PKI graph. But
> the topology of the whole PKI graph is beyond the scope of PKIX
> specification as far as interoperability is concerned.
>
> I agree with Brian and Arnoud.
>
> [Brian] " I think I prefer "root" for any trusted node in the
> hierarchy--that such a
> node is directly trusted makes it a root, at least from a local
> perspective."
>
> [Arnoud] "Would using the term "top-level CA" for the hierarchy's top
> not
> be more clear? Then "root CA" can still be used for the starting
> point in a chain of trust."
>
> The CMP terminology is my personal preference, because it focuses on
> functional description. I think that the roadmap document should use the
> terminology as in CMP stated.
>
> According to PKIX-1 one may remain things unchanged at the moment. "at
> the top of hierarchy" may be interpreted as "at the top of certificate
> path". In addition the roadmap document may give guidance. Further work
> should incorporate non-hierarchical models and the CMP terminology.
>
> If there is a general description of trust models (i. e. hierarchical
> vs. non-hierarchical) needed, I prefer the terminology of a top-level
> CA. The top-level CA is then a root-CA which root-key has not been
> certified by any other CA. But this is predominantly an informational
> chapter of PKIX drafts.
>
> Let us consider hierarchically designed certification domains which are
> cross-certified. What is the top-level CA in this case? I´m afraid we
> arrive at the term "n-th top level CA" and only formal algebra may helps
> to survive the further PKIX standardization work.
>
> By the way, the CMP terminology fits very well, when one compares the
> model with a real-world tree as mentioned by Bill. The leaves of a tree
> needs the roots for ingestion whilst the entity needs the root-CA for
> trust. There may be more than one root/root-CA and more than one
> capillary/certificate path to the root/root-CA. The chosen root-CA may
> depend on the entity and his function (i. e. end-entity, relying party,
> RA, CA). I am not sure whether the last observation has a botanic
> analogy or not.
>
> Al Arsenault wrote:
> >
> > Okay, time to resolve a conflict in terminology:
> >
> > PKIX-1, the Cert & CRL profile,  implicitly uses "root CA" to indicate the
> > CA at the top of a hierarchy (see Section 6, "Certificate Path
> > Validation").  CMP, on the other hand, explicitly states:
> >
> >         " 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."  (See section 1.2.2, "Certification Authority".)
> >
> > In the original draft of the Roadmap, we used the term 'root CA' to
> > indicate the top of a hierarchy - possibly, a hierarchy of one CA.  It was
> > pointed out that this was inconsistent with CMP.  So - what do we do to fix
> > it in the next draft, especially given the apparent conflict between the
> > two soon-to-be RFC's pointed out above?
> >
> > My personal preference is to point out the conflict somewhere in the
> > Roadmap, and to use "root CA" to indicate the top of a hierarchy, and
> > "trust anchor" to indicate the node that is trusted directly.  I'm
> > soliciting other suggestions, though.
> >
> > Thanks for any inputs,
> >
> >                         Al Arsenault
> >
> > -- these are my opinions only. They do not necessarily reflect the
> > opinions of my employer, or of any other organization with which I have a
> > relationship.
>
> Juergen



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA00587 for ietf-pkix-bks; Thu, 28 Jan 1999 07:43:35 -0800 (PST)
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 HAA00582 for <[e-mail]>; Thu, 28 Jan 1999 07:43:32 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id QAA13748; Thu, 28 Jan 1999 16:46:00 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id QAA16684; Thu, 28 Jan 1999 16:48:42 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Thu, 28 Jan 1999 16:46:22 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: POP section for next Roadmap draft
References: <4.1.19990127112822.00aa1bc0@209.172.119.123>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al,

This is nice to send that section, otherwise I would not have taken a look at
the road map :-(

>  Folks,
>
> Sean and I are working on the next draft of the PKIX Roadmap.  One of the
> things that has to be done is filling in the Proof of Possession section
> (section 5.2 in draft -00).  Attached is a first cut at text for that
> section.  Any strong comments one way or the other on this?
>

Oh ! yes. I have strong opinions on this topic.


>      POP
>
> Proof of Possession, or POP, means that the CA is adequately convinced that
> the entity requesting a certificate containing a public key Y has access to
> the private key X corresponding to that public key.
>
> POP is important because it provides an appropriate level of assurance in
> the correct operation of the PKI as a whole.  There are those who dismiss
> POP as unimportant because the most direct threat it counters is the
> “self-inflicted denial of service”; that is, an entity voluntarily gets a
> certificate that cannot be used to sign or encrypt/decrypt information.

Up to here the text is fine.

There are three types of keys, each one being indicated with a different key
usage. Whether POP or is not required depends on the key usage. The three main
key usages for leaf certificates are: non repudiation, data encryption and ...
all others in particular authentication.

The case for signing key below does not match with this separation and
therefor is not adequate. You have to separate authentication from non
repudiation. You also have to consider "old" mechanisms (which contain
"errors") which mandate POP and "new" (error free) mechnisms which do not
mandate POP.

Because some people wanted to use PKIX in any context they wanted to mandate
POP. As soon as you use it with "new" mechanism POP is no more always needed
(see below).

The example you provide below is an example with an "old" mechanism. The bad
side is that many people could infer from the text that POP is always needed
whereas this is not true.


> However, as the following two examples demonstrate, the true threat
> countered by POP is less direct, but more important:
>
>      POP for signing keys:  it is important to provide POP for keys used to
>      sign material, in order to provide authentication and possibly
>      non-repudiation of transactions.  For example, suppose Alice
>      legitimately has private key X and its corresponding public key Y.
>      Alice has a certificate from Charlie, a CA, containing Y.  Alice uses X
>      to sign a transaction T.  Without POP, Mal could also get a certificate
>      from Charlie containing the same public key, Y.  Now, there are two
>      possible threats:  Mal could claim to have been the real signer of T;
>      or Alice can falsely deny signing T, claiming that it was instead Mal.
>      Since no one can reliably prove that Mal did or did not ever possess X,
>      neither of these claims can be refuted, and thus the service provided
>      by and the confidence in the PKI has been defeated.  (Of course, if Mal
>      really did possess X, Alice’s private key, then no POP mechanism in the
>      world will help, but that is a different problem.)
>

The simple solution to the problem is to include an identifier of the
certificate in the signed data. In this way the substitution is no more
possible. What you have provided is an example of an "old" mechanism whereas
my example would be refered as a "new" mechanism.

As far as authentication is concerned some "old" mechanisms cannot be changed
to include the certificate identifier. For non repudiation it is mandatory to
include it, not only because of the substitution with a certificate from
someone else but because the same signer may use different certificates all
containing the same public key but including different security attributes (in
an extension).


>
>      POP for key management keys:  Similarly, POP for key management keys
>      (that is, keys used for either key agreement or key exchange) can help
>      to prevent undermining confidence in the PKI.  Suppose that Al is a new
>      instructor in the Computer Science Department of a local University.
>      Al has created a draft final exam for the Introduction to Networking
>      course he is teaching.  He wants to send a copy of the draft final to
>      Dorothy, the Department Head, for her review prior to giving the exam.
>      This exam will of course be encrypted, as several students have access
>      to the computer system.  However, a quick search of the certificate
>      repository turns up the fact that several students have certificates
>      containing the same public key management key as Dorothy.  At this
>      point, if no POP has been done by the CA, Al has no way of knowing
>      whether all of the students have simply created these certificates
>      without knowing the corresponding private key (and thus it is safe to
>      send the encrypted exam to Dorothy), or whether the students have
>      somehow acquired Dorothy’s private key (and thus it is certainly not
>      safe to send the exam).  Thus, the service to be provided by the PKI -
>      allowing users to communicate with one another, with confidence in who
>      can read their communications - has been totally defeated. If the CA is
>      providing POP, then either no students will have such certificates, or
>      Al can know with certainty that the students do indeed know Dorothy’s
>      private key, and act accordingly.
>

I am not convinced by this example. Alice Dorothy will be able to decrypt the
document. If the key was indeed compromised, Dorothy would have reported it
(and any way POP would not have helped, since all others were indeed knowing
the key ansd would have get their certificate by exercising POP !).


> CMP requires that POP be provided for all keys, either through on-line or
> out-of-band means.

This may be necessary in some cases, however it is not only always necessary.
A conservative measure is to mandate it but I do not think this is
appropriate. For authentication if the mechanism is designed very fast and no
protection is taken, then POP is necessary. This is true for both signing keys
and (I guess) encryption keys. When a message is encrypted so that only the
intended recipient may decipher it, POP is not needed.

For non repudiation, since some protection is always needed at the protocol
level, POP is NOT needed.

You may have (re-)opened a new long thread on that topic. Anyway thanks for
trying to clarify this issue.

If I had the time I would have propose a new text. However, I thought it was
better to provide explanations first at that stage.
You may "canibalize" my rational and re-use it in a new text if you wish.

Denis


> There are any number of ways to provide POP, and the choice of which to use
> is a local matter.  Additionally, a certificate requester can provide POP to
> either a CA or to an RA, if the RA can adequately assure the CA that POP has
> been performed.  Some of the acceptable ways to provide POP include:
>
> POP by Out-of-band means:
>
>      For keys generated by the CA or an RA (e.g., on a token such as a smart
>      card or PCMCIA card), possession of the token can provide adequate
>      proof of possession of the private key.
>
>      For user-generated keys, another approach can be used in environments
>      where “key recovery” requirements force the requester to provide a copy
>      of the private key to the CA or an RA.  In this case, the CA will not
>      issue the requested certificate until such time as the requester has
>      provided the private key.  This approach is in general not recommended,
>      as it is extremely risky (e.g., the system designers need to figure out
>      a way to protect the private keys from compromise while they are being
>      sent to the CA/RA/other authority, and how to protect them there), but
>      it can be used.
>
>
> POP by On-line means:
>
>      For signature keys that are generated by an end-entity, the requester
>      of a certificate can be required to sign some piece of data (typically,
>      the certificate request itself) using the private key.  The CA will
>      then use the requested public key to verify the signature.  If the
>      signature verification works, the CA can safely conclude that the
>      requester had access to the private key.  If the signature verification
>      process fails, the CA can conclude that the requester did not have
>      access to the correct private key, and reject the request.
>
>      For key management keys that are generated by the requester, the CA can
>      send use the requested public key, along with the CA’s own private key,
>      to encrypt some piece of data, and send it to the requester to be
>      decrypted.  For example, the CA can generate some random challenge, and
>      require some action to be taken after decryption (e.g., “decrypt this
>      encrypted random number and send it back to me”).  If the requester
>      does not take the requested action, the CA concludes that the requester
>      did not possess the private key, and the certificate is not issued.
>
>      Another method of providing POP for key management keys is for the CA
>      to generate the requested certificate, and then send it to the
>      requester in encrypted form.  If the requester does not have access to
>      the appropriate private key, the requester cannot decrypt the
>      certificate, and thus cannot use it. After some period of time in which
>      the certificate is not used, the CA will revoke the certificate.  (This
>      only works if the certificate is not made available to any untrusted
>      entities until after the requester has successfully decrypted it.
>
>
>
>
>
>
> Thanks,
>
> Al Arsenault
>
> -- these are my opinions only. They do not necessarily reflect the
> opinions of my employer, or of any other organization with which I have a
> relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA29649 for ietf-pkix-bks; Thu, 28 Jan 1999 06:13:05 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA29644 for <[e-mail]>; Thu, 28 Jan 1999 06:13:04 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA13042; Thu, 28 Jan 1999 09:10:05 -0500
Message-Id: <4.1.19990128085211.00aa0b50@209.172.119.123>
X-Sender: aarsenault#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 28 Jan 1999 09:04:19 -0500
To: [e-mail], Bill Burr <[e-mail]>, Brian Korver <[e-mail]>, Arnoud Galactus Engelfriet <[e-mail]>, ietf-pkix <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: Re: Terminology question:  "root CA"
In-Reply-To: <[e-mail]>
References: <4.1.19990127140608.00aa3dd0@209.172.119.123>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

	Okay, let me try to clarify with a scenario:

Suppose that a company establishes a PKI as a simple hierarchy, with a CA,
T, at the top having a self-signed certificate; and three subordinate CAs,
A, B, and C, underneath. A, B, and C each have certificates issued by T;
they do not have self-signed certificates.  Suppose further that in
furtherance of a business relationship, A cross-certifies with W, a CA
somewhere else in the world but not in this company's hierarchy.  Now,
there's a user, call him Fred, who gets a certificate from A.  Either by
company policy or by personal choice, Fred chooses A -which issued his
certificate - as his "trust anchor" or "root of trust" or whatever.  That
is, it is A's public key that Fred acquires via secure means, and Fred
accepts as valid certificate paths that end with A's certificate.

(Note that this type of arrangement is explicitly supported by PKIX.  That
is, there is no requirement that a "most-trusted CA" or "root of a
certificate path" or whatever we call it have a self-signed certificate.
See Section 6 of the Profile document, PKIX-1, for an explanation.  That
section notes that cert path validation is easier if this "most-trusted CA"
has a self-signed cert, but it doesn't have to.)

	In this situation,  PKIX-1 refers to T (from Fred's point of view) as the
"root CA" and A as the "most-trusted CA".  On the other hand, CMP (also
from Fred's point of view) refers to A as the "root CA" and doesn't refer
to T at all.

	In the roadmap, I'm trying to write a paragraph that addresses what
happens - particularly to A - if T's key is compromised.  Here's the
problem:  how do I refer to T?   Do I use PKIX-1 terms and call T the 'root
CA' (that's my choice) and A the 'most trusted CA' or 'trust anchor'?  Or,
do I use CMP terms and call A the "root CA" and make up some other term for T?

	No matter which I do, some reviewer will correctly comment that I'm being
inconsistent with an RFC that's a Proposed Standard.  So, I'm trying to get
some resolution now.

	My personal choice is, as I've stated, to say that a CA at the top of a
hierarchy - which must have a self-signed cert, by virtue of being the
"top" - be called a "root CA".  As Bill Burr pointed out, this is more
consistent with graph-theory notation than the CMP wording.  Note that it
is perfectly legitimate to have a degenerate hierarchy, which consists of
exactly one CA with a self-signed cert, and some users below it.  This
degenerate hierarchy can then be cross-certified in peer-to-peer
relationships with other such degenerate hierarchies (or even with other,
non-degenerate hierarchies, as described above).  All of the graph-theory
results still hold.

	Then, we need a term for what CMP calls a "root CA".  PKIX-1 calls it a
"most-trusted CA"; I can live with that, but prefer the term "trust anchor". 

	Alternatively, if we're going go with CMP terminology, and a "root CA"
need not have a self-signed cert, then we need a term for that which does
have a self-signed cert and is above the root in a hierarchy, as described
above.

				Al Arsenault

(PS - sorry for the inside joke, but -- the first wise person who suggests
"root registry" is gonna get the electronic equivalent of a punch in the
nose, real quick! :-)


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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA29253 for ietf-pkix-bks; Thu, 28 Jan 1999 05:16:57 -0800 (PST)
Received: from pluto.deh.de (pluto.deh.de [194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA29247 for <[e-mail]>; Thu, 28 Jan 1999 05:16:35 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id OAA12324; Thu, 28 Jan 1999 14:18:52 +0100
Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id OAA14978; Thu, 28 Jan 1999 14:18:50 +0100
Message-ID: <[e-mail]>
Date: Thu, 28 Jan 1999 14:21:38 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>, Bill Burr <[e-mail]>, Brian Korver <[e-mail]>, Arnoud Galactus Engelfriet <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: Terminology question:  "root CA"
References: <4.1.19990127140608.00aa3dd0@209.172.119.123>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al, Arnoud, Bill, Brian, all

Firstly, I try to recognize what are the requirements according to a
PKIX terminology.
These are - in my opinion - the following

1) The definition of root-CA shall applicable for both hierarchical and
non-hierarchical PKIs.

2) The root-CA shall issue a self-signed certificate called root
certificate.

3) The root-CA shall appear at the end point of a certificate path that
is constructed by applying the validation algorithm. The end point of
the certificate path shall coincide with the directly trusted CA of the
verifying entity. 

4) The root-CA is free to being cross-certified by another CA or
root-CA.

Are there other and/or additional suggestions?

The terminology root-CA may be interpreted in the way, that a root-CA is
the root of a certificate path. This is always true (i. e. in
hierarchical and non-hierarchical PKIs). Both certification paths and
root-CAs may not uniquely determined. Nevertheless, the root-CA is in
all cases the root in the tpological sense, i. e. the root of a
certification path, which is the subgraph of the whole PKI graph. But
the topology of the whole PKI graph is beyond the scope of PKIX
specification as far as interoperability is concerned.

I agree with Brian and Arnoud.

[Brian] " I think I prefer "root" for any trusted node in the
hierarchy--that such a
node is directly trusted makes it a root, at least from a local
perspective."

[Arnoud] "Would using the term "top-level CA" for the hierarchy's top
not
be more clear? Then "root CA" can still be used for the starting
point in a chain of trust." 

The CMP terminology is my personal preference, because it focuses on
functional description. I think that the roadmap document should use the
terminology as in CMP stated.

According to PKIX-1 one may remain things unchanged at the moment. "at
the top of hierarchy" may be interpreted as "at the top of certificate
path". In addition the roadmap document may give guidance. Further work
should incorporate non-hierarchical models and the CMP terminology.

If there is a general description of trust models (i. e. hierarchical
vs. non-hierarchical) needed, I prefer the terminology of a top-level
CA. The top-level CA is then a root-CA which root-key has not been
certified by any other CA. But this is predominantly an informational
chapter of PKIX drafts.

Let us consider hierarchically designed certification domains which are
cross-certified. What is the top-level CA in this case? I´m afraid we
arrive at the term "n-th top level CA" and only formal algebra may helps
to survive the further PKIX standardization work.

By the way, the CMP terminology fits very well, when one compares the
model with a real-world tree as mentioned by Bill. The leaves of a tree
needs the roots for ingestion whilst the entity needs the root-CA for
trust. There may be more than one root/root-CA and more than one
capillary/certificate path to the root/root-CA. The chosen root-CA may
depend on the entity and his function (i. e. end-entity, relying party,
RA, CA). I am not sure whether the last observation has a botanic
analogy or not.

Al Arsenault wrote:
> 
> Okay, time to resolve a conflict in terminology:
> 
> PKIX-1, the Cert & CRL profile,  implicitly uses "root CA" to indicate the
> CA at the top of a hierarchy (see Section 6, "Certificate Path
> Validation").  CMP, on the other hand, explicitly states:
> 
>         " 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."  (See section 1.2.2, "Certification Authority".)
> 
> In the original draft of the Roadmap, we used the term 'root CA' to
> indicate the top of a hierarchy - possibly, a hierarchy of one CA.  It was
> pointed out that this was inconsistent with CMP.  So - what do we do to fix
> it in the next draft, especially given the apparent conflict between the
> two soon-to-be RFC's pointed out above?
> 
> My personal preference is to point out the conflict somewhere in the
> Roadmap, and to use "root CA" to indicate the top of a hierarchy, and
> "trust anchor" to indicate the node that is trusted directly.  I'm
> soliciting other suggestions, though.
> 
> Thanks for any inputs,
> 
>                         Al Arsenault
> 
> -- these are my opinions only. They do not necessarily reflect the
> opinions of my employer, or of any other organization with which I have a
> relationship.

Juergen


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29441 for ietf-pkix-bks; Wed, 27 Jan 1999 15:41:10 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA29437 for <[e-mail]>; Wed, 27 Jan 1999 15:41:08 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 27 Jan 1999 16:43:10 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 27 Jan 1999 16:43:02 -0700
From: "Tammy Carter" <[e-mail]>
To: "<"<[e-mail]>, <[e-mail]>
Subject: RE: Attribute used to store cached certificate chains?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA29438
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Andrew,

The question may seem a bit recursive on the surface, but I 
don't think that it is.  Alice has a certificate which, after she received
it, she validated by walking her directory tree.  Now, a couple of
months later, she needs to use her certificate, but she is disconnected
from her tree and won't be able to access it until tomorrow.  But,
she needs to get to her chain today.  Is she out of luck??  Is Alice
unable to use her key pair unless she can access her directory???

If so, something is dreadfully wrong here.  That would mean that
users would be unable to send signed email while disconnected
from their tree simply because they would be unable to construct
a suitable chain for inclusion in the S/MIME message. 

What seems reasonable is that a user would have their certificate
chain (or some PKCS 7 bag of certificates which can be used to
verify their certificate) cached somewhere for times when
they are unable to reach the tree to construct the chain.  Perhaps
it would be stored on the client, or on a floppy, or in their email 
package.... somewhere.

Now, I was thinking about the case where the user is partially
connected to the tree.  In other words, the user is able to read
their own object, but is unable to construct the chain.  Could the
chain be cached in an attribute on the user's object instead of
on the client?

Tammy Green Carter




>>> Andrew Probert <[e-mail]> 1-27-99 3:29:53 PM >>>

> -----Original Message-----
> From:	Tammy Carter [SMTP:[e-mail]] 
> Sent:	Saturday, January 23, 1999 7:06 AM
> To:	[e-mail] 
> Subject:	Attribute used to store cached certificate chains?
> 
> Consider the following scenario:
> -----------------------------------------------
> A user, Alice, is a user of a directory service and the
> PKI that she uses exists entirely within her own tree.  
> Due to the nature of the directory, she is often unable
> to compose her certificate chain (a chain back to a root
> which she knows and trusts and which other people within
> her tree know and trust) on the fly by walking her tree.  
> Sometimes, Alice needs to construct her certificate 
> chain in order to validate one of her own certificates.  
> 
[Andrew Probert]  This sounds a bit recursive!  If she can't validate her
own chain locally, she's in trouble trust-wise.

> Other times,
> she needs to send the certificate chain to another user, Bob, 
> who may also not be able to walk the tree, but who needs to
> validate her certificate.
> 
	[Andrew Probert]  PKCS#7 (and the SMIME profile) is typically used
to do this

> If Alice wanted to cache her certificate chain in the directory on
> her user object for use when she was disconnected, what attribute
> should she store it in?  Has such an attribute been defined yet?
> 
	[Andrew Probert]  Certificates would normally be stored discretely,
under their own names.  Its up to 
	the client software to walk the tree and retrieve each by name etc.

> Thanks,
> 
> Tammy Green Carter
> [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26682 for ietf-pkix-bks; Wed, 27 Jan 1999 14:45:40 -0800 (PST)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26675 for <[e-mail]>; Wed, 27 Jan 1999 14:45:34 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <DLNAT1BC>; Thu, 28 Jan 1999 09:46:52 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A6299@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Al Arsenault'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Terminology question:  "root CA"
Date: Thu, 28 Jan 1999 09:46:43 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think if its a CA this should still be stated, rather than introduce a new
term of trust anchor.

I would add a definition to PKIX : - root CA .. indicates a self-signed
certficate at the top of a trust hierarchy, which may 
have a number of subordinate CA certficates or cross-certified certficates.

Then change the paragraph in question by deletion of the word 'root'.

	" We use the term "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).(See section 1.2.2, "Certification
Authority".)


Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Al Arsenault [SMTP:[e-mail]]
> Sent:	Thursday, January 28, 1999 6:14 AM
> To:	[e-mail]
> Cc:	[e-mail]
> Subject:	Terminology question:  "root CA"
> 
> Okay, time to resolve a conflict in terminology:
> 
> PKIX-1, the Cert & CRL profile,  implicitly uses "root CA" to indicate the
> CA at the top of a hierarchy (see Section 6, "Certificate Path
> Validation").  CMP, on the other hand, explicitly states:
> 
> 	" 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."  (See section 1.2.2, "Certification
> Authority".)
> 
> In the original draft of the Roadmap, we used the term 'root CA' to
> indicate the top of a hierarchy - possibly, a hierarchy of one CA.  It was
> pointed out that this was inconsistent with CMP.  So - what do we do to
> fix
> it in the next draft, especially given the apparent conflict between the
> two soon-to-be RFC's pointed out above?
> 
> My personal preference is to point out the conflict somewhere in the
> Roadmap, and to use "root CA" to indicate the top of a hierarchy, and
> "trust anchor" to indicate the node that is trusted directly.  I'm
> soliciting other suggestions, though.
> 
> Thanks for any inputs,
> 
> 			Al Arsenault
> 
> 
> -- these are my opinions only. They do not necessarily reflect the 
> opinions of my employer, or of any other organization with which I have a 
> relationship.
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26266 for ietf-pkix-bks; Wed, 27 Jan 1999 14:36:04 -0800 (PST)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26257 for <[e-mail]>; Wed, 27 Jan 1999 14:35:58 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <DLNAT1BA>; Thu, 28 Jan 1999 09:37:13 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A6298@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Sarbari Gupta'" <[e-mail]>, "'Phillip M Hallam-Baker'" <[e-mail]>, [e-mail]
Cc: ietf-pkix <[e-mail]>
Subject: RE: OCSP & Authority Information Access
Date: Thu, 28 Jan 1999 09:37:08 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

... and if a key is bound to a name, then it is possible to renew keys and
certificates reusing the same name, where each is differentiated by its
serial number, thus a level of indirection / one-many relationship is
possible allowing date/time overlaps and other real world renewal issues.



Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Sarbari Gupta [SMTP:[e-mail]]
> Sent:	Thursday, January 28, 1999 4:38 AM
> To:	'Phillip M Hallam-Baker'; [e-mail]
> Cc:	ietf-pkix
> Subject:	RE: OCSP & Authority Information Access
> 
> A self-signed certificate offers some level of integrity protection to
> the root public key. It also binds the key to a name (although there is
> little trust in this binding since it is self-signed) - this name is
> useful for displaying to the human user. The self-signed certs (root
> keys and names) can be stored on unprotected media (if necessary)
> without any additional integrity protection mechanisms. 
> 
> - Sarbari
> =================================
> Sarbari Gupta
> CygnaCom Solutions
> [phone] (voice)
> [phone](FAX)
> [e-mail]
> =================================
> 
> -----Original Message-----
> From: Phillip M Hallam-Baker [mailto:[e-mail]]
> Sent: Wednesday, January 27, 1999 12:21 PM
> To: [e-mail]; Michael Myers; ietf-pkix
> Subject: RE: OCSP & Authority Information Access
> 
> 
> > 
> > I have a problem to understand why we consider self-signed
> certificates
> > instead of root keys as primary trusted data objects. More specific
> > comments in lines below. 
> 
> This is something I thought a lot about when I was at W3C, we were
> looking
> at a system in which root keys were expressed as URLs.
> 
> The distinction pointed out is that if the KEY is trusted then the means
> of revocation needs to refer to the KEY (which in our case it did, a 
> revocation statement referred to the URL of the revoked key).
> 
> In the case of PKIX however it is the Serial Number of the self signed
> cert which is used for revocation. Thus it is the binding of the key to
> the serial number which is trusted in this respect. A similar argument
> may then be made wrt the subject name.
> 
> 
> Although this may appear to be a debate in semantics, this is of course
> what a standards effort (court proceeding, academic paper) is.
> 
> I do not however think that it is necessary to over-analyse the point.
> SDSI is fine if one wishes to construct an algebra of trust in which
> to analyse a PKI such as PKIX. I now believe that the value of approach
> is limited to being an analytical tool and that reifying it in an
> implementation is a mistake. It is too low level, it is necessary to
> make simplifying assumptions to make the system tractible. 'Structured
> trust' is necessary for the same reason as 'structured programming'.
> 
> Although one can make a distinction between reliance on the key and 
> reliance on the self signed certificate, trusting the key if the
> certificate is lost it is IMHO not wise to do so.
> 
> 
> 		Phill
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25876 for ietf-pkix-bks; Wed, 27 Jan 1999 14:28:50 -0800 (PST)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25871 for <[e-mail]>; Wed, 27 Jan 1999 14:28:48 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.2232.9) id <DLNAT1A0>; Thu, 28 Jan 1999 09:30:00 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A6297@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Tammy Carter'" <[e-mail]>, [e-mail]
Subject: RE: Attribute used to store cached certificate chains?
Date: Thu, 28 Jan 1999 09:29:53 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Tammy Carter [SMTP:[e-mail]]
> Sent:	Saturday, January 23, 1999 7:06 AM
> To:	[e-mail]
> Subject:	Attribute used to store cached certificate chains?
> 
> Consider the following scenario:
> -----------------------------------------------
> A user, Alice, is a user of a directory service and the
> PKI that she uses exists entirely within her own tree.  
> Due to the nature of the directory, she is often unable
> to compose her certificate chain (a chain back to a root
> which she knows and trusts and which other people within
> her tree know and trust) on the fly by walking her tree.  
> Sometimes, Alice needs to construct her certificate 
> chain in order to validate one of her own certificates.  
> 
[Andrew Probert]  This sounds a bit recursive!  If she can't validate her
own chain locally, she's in trouble trust-wise.

> Other times,
> she needs to send the certificate chain to another user, Bob, 
> who may also not be able to walk the tree, but who needs to
> validate her certificate.
> 
	[Andrew Probert]  PKCS#7 (and the SMIME profile) is typically used
to do this

> If Alice wanted to cache her certificate chain in the directory on
> her user object for use when she was disconnected, what attribute
> should she store it in?  Has such an attribute been defined yet?
> 
	[Andrew Probert]  Certificates would normally be stored discretely,
under their own names.  Its up to 
	the client software to walk the tree and retrieve each by name etc.

> Thanks,
> 
> Tammy Green Carter
> [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25545 for ietf-pkix-bks; Wed, 27 Jan 1999 14:23:56 -0800 (PST)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA25540 for <[e-mail]>; Wed, 27 Jan 1999 14:23:55 -0800 (PST)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id RAA12307; Wed, 27 Jan 1999 17:25:54 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 27 Jan 1999 17:29:26 -0500
To: "Robert W. Shirey" <[e-mail]>, Al Arsenault <[e-mail]>
From: Bill Burr <[e-mail]>
Subject: Re: Terminology question:  "root CA"
Cc: [e-mail]
In-Reply-To: <v03110700b2d5280c6591@[192.1.7.164]>
References: <4.1.19990127140608.00aa3dd0@209.172.119.123>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,


I like Al's suggestion for "root" and "trust anchor."  I think that the
term "root" has a pretty well understood meaning in any tree graph, that
is much older and more broadly understood broader than its use in PKI,
and I would like to honor this meaning.  So I would prefer to reserve the
term root for the top node in a hierarchy (tree).  And I would use trust
anchor for any "trusted" CA that has a self-signed certificate and starts
a certification path, which includes all root CAs.


Having said that, the botanist in me says that more appropriate names
would not be root and leaf, but trunk and leaf, since roots themselves
are not singular points, but a tree structure.


Regards,


Bill Burr 




At 03:59 PM 1/27/99 -0500, Robert W. Shirey wrote:

>>>> 

<excerpt>At 2:13 PM -0500 1/27/99, Al Arsenault wrote:

>My personal preference is to point out the conflict somewhere in the

>Roadmap, and to use "root CA" to indicate the top of a hierarchy, and

>"trust anchor" to indicate the node that is trusted directly.  I'm

>soliciting other suggestions, though.


Al,


It would be better not to uproot (smile) either meaning from the base
word "root". Instead, we should define a root (smile) meaning for "root"
and then distinguish among the various branch meanings by attaching
appropriate adjectives. This approach has the advantage that it can be
used as the foundation, basis, footing--oh, heck; root--for a third,
fourth, etc. term that also wants to be rooted in "root"; you don't want
to have to stretch for more and more new near-synonyms like "anchor", do
you? So . . .


 - First, use "root" to refer to a public key certificate--or the public
key it contains, or the subject (possibly but not necessarily, a CA) to
which the key is bound--upon which some set of "certificate users"
(sometimes called "relying parties") base their trust in cryptographic
operations involving the public key. This covers both of your cases and
some others, too.


 - Then, replace the terms you propose with "certification hierarchy
root" ("hiearchy root" for short) and "certification path root" ("path
root" for short). (Of course, terms that incorporate root but don't
incorporate my proposed base meaning, should be replaced by something
else; an example is the old MISSI "root".)


By the way, my master listing currently has the following, which would
have to be revised: 


<bold><fontfamily><param>Times_New_Roman</param><bigger>root  

</bigger></fontfamily></bold><fontfamily><param>Times_New_Roman</param><bigger>(R)
<bold>General PKI usage: </bold>The <underline>certification
authority</underline> that is the highest level (most-trusted) CA in a
<underline>certification hierarchy</underline>; that is, the authority
upon whose <underline>public key</underline> all <underline>certificate
users</underline> base their trust.


(C) A root <underline>issue</underline>s <underline>public-key
certificates</underline> to one or more additional CAs that form the
second highest level. Each of these CAs may issue certificates to more
CAs at the third highest level, and so on. To initialize operation of a
hierarchical <underline>PKI</underline>, the root's initial
<underline>public key</underline> must be securely distributed to all
<underline>certificate users</underline> in a way that does not depend on
the PKI's certification relationships. The <underline>root's</underline>
<underline>public key</underline> may be distributed simply as a
numerical value, but typically is distributed in a <underline>self-signed
certificate</underline> in which the root is the
<underline>subject</underline>. The root's certificate is signed by the
root itself because there is no higher authority in a certification
hierarchy. The root's certificate is then the first certificate in every
<underline>certification path</underline>.


(S) <bold>MISSI usage:</bold> A name previously used for a
<underline>MISSI</underline> <underline>Policy Creation
Authority</underline>, which is <bold>NOT</bold> a
<underline>root</underline> as defined above for general usage, but is a
CA at the second level of the MISSI hierarchy, immediately subordinate to
a MISSI root called a <underline>Policy Approving 
Authority</underline>.


(S) <bold>PKIX usage:</bold> A CA whose certificate is self-signed; that
is, the issuer and subject are the same entity.


(S) <bold>UNIX usage:</bold> A system user account (also called
"superuser") that has all <underline>privileges</underline> (including
all <underline>security</underline>-related privileges) and thus can
manage the system and its other user accounts.


<bold>root certificate  

</bold>(R) The <underline>self-signed</underline> <underline>public-key
certificate</underline> at the top of a <underline>certification
hierarchy</underline>. (Also see <underline>root</underline>.)


</bigger></fontfamily>Finally, please note that this sort of rooting
around in terminology points out  the lack of a comprehensive and
internally consistent set of crisp, clean, clear definitions is the root
of much misunderstanding in the PKI arena. We need to do more than just
dig into this embedded problem one tuber--I mean, term--at a time, as we
have done with "root" and with "verify vs. validate".


Regards, -Rob-


[e-mail], Phone [phone], Reception 284-4600, Fax [phone]

Robert W. Shirey, GTE Internetworking - Mail Stop 30/12B2, Suite 1200 


1300 North Seventeenth Street, Arlington, Virginia   22209-3801   USA



-







</excerpt><<<<<<<<




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25221 for ietf-pkix-bks; Wed, 27 Jan 1999 14:16:41 -0800 (PST)
Received: from shell.tsoft.com ([e-mail] [207.201.34.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25217 for <[e-mail]>; Wed, 27 Jan 1999 14:16:40 -0800 (PST)
Received: from cs.stanford.edu ([209.133.59.212]) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id NAA06420; Wed, 27 Jan 1999 13:39:48 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 27 Jan 1999 13:49:44 -0800
From: Brian Korver <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 (Macintosh; I; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>
CC: [e-mail]
Subject: Re: Terminology question:  "root CA"
References: <4.1.19990127140608.00aa3dd0@209.172.119.123>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al Arsenault wrote:
> 
> Okay, time to resolve a conflict in terminology:
> 
> PKIX-1, the Cert & CRL profile,  implicitly uses "root CA" to indicate the
> CA at the top of a hierarchy (see Section 6, "Certificate Path
> Validation").  CMP, on the other hand, explicitly states:
> 
>         " 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."  (See section 1.2.2, "Certification Authority".)
> 
> In the original draft of the Roadmap, we used the term 'root CA' to
> indicate the top of a hierarchy - possibly, a hierarchy of one CA.  It was
> pointed out that this was inconsistent with CMP.  So - what do we do to fix
> it in the next draft, especially given the apparent conflict between the
> two soon-to-be RFC's pointed out above?
> 
> My personal preference is to point out the conflict somewhere in the
> Roadmap, and to use "root CA" to indicate the top of a hierarchy, and
> "trust anchor" to indicate the node that is trusted directly.  I'm
> soliciting other suggestions, though.
> 
> Thanks for any inputs,
> 
>                         Al Arsenault
> 
> -- these are my opinions only. They do not necessarily reflect the
> opinions of my employer, or of any other organization with which I have a
> relationship.

Al,

I think I prefer "root" for any trusted node in the hierarchy--that such a
node is directly trusted makes it a root, at least from a local
perspective.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA23618 for ietf-pkix-bks; Wed, 27 Jan 1999 13:32:28 -0800 (PST)
Received: from rosslyn.BBN.COM (ROSSLYN.BBN.COM [192.1.7.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA23609 for <[e-mail]>; Wed, 27 Jan 1999 13:32:26 -0800 (PST)
Received: from RSHIREY.BBN.COM by rosslyn.BBN.COM id aa03610; 27 Jan 99 16:08 EST
X-Sender: [e-mail]
Message-Id: <v03110700b2d5280c6591@[192.1.7.164]>
In-Reply-To: <4.1.19990127140608.00aa3dd0@209.172.119.123>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Jan 1999 15:59:13 -0500
To: Al Arsenault <[e-mail]>
From: "Robert W. Shirey" <[e-mail]>
Subject: Re: Terminology question:  "root CA"
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:13 PM -0500 1/27/99, Al Arsenault wrote:

>My personal preference is to point out the conflict somewhere in the

>Roadmap, and to use "root CA" to indicate the top of a hierarchy, and

>"trust anchor" to indicate the node that is trusted directly.  I'm

>soliciting other suggestions, though.


Al,


It would be better not to uproot (smile) either meaning from the base
word "root". Instead, we should define a root (smile) meaning for
"root" and then distinguish among the various branch meanings by
attaching appropriate adjectives. This approach has the advantage that
it can be used as the foundation, basis, footing--oh, heck; root--for a
third, fourth, etc. term that also wants to be rooted in "root"; you
don't want to have to stretch for more and more new near-synonyms like
"anchor", do you? So . . .


 - First, use "root" to refer to a public key certificate--or the
public key it contains, or the subject (possibly but not necessarily, a
CA) to which the key is bound--upon which some set of "certificate
users" (sometimes called "relying parties") base their trust in
cryptographic operations involving the public key. This covers both of
your cases and some others, too.


 - Then, replace the terms you propose with "certification hierarchy
root" ("hiearchy root" for short) and "certification path root" ("path
root" for short). (Of course, terms that incorporate root but don't
incorporate my proposed base meaning, should be replaced by something
else; an example is the old MISSI "root".)


By the way, my master listing currently has the following, which would
have to be revised:=20


<bold><fontfamily><param>Times_New_Roman</param><bigger>root =20

</bigger></fontfamily></bold><fontfamily><param>Times_New_Roman</param><bigg=
er>(R)
<bold>General PKI usage: </bold>The <underline>certification
authority</underline> that is the highest level (most-trusted) CA in a
<underline>certification hierarchy</underline>; that is, the authority
upon whose <underline>public key</underline> all <underline>certificate
users</underline> base their trust.


(C) A root <underline>issue</underline>s <underline>public-key
certificates</underline> to one or more additional CAs that form the
second highest level. Each of these CAs may issue certificates to more
CAs at the third highest level, and so on. To initialize operation of a
hierarchical <underline>PKI</underline>, the root's initial
<underline>public key</underline> must be securely distributed to all
<underline>certificate users</underline> in a way that does not depend
on the PKI's certification relationships. The
<underline>root's</underline> <underline>public key</underline> may be
distributed simply as a numerical value, but typically is distributed
in a <underline>self-signed certificate</underline> in which the root
is the <underline>subject</underline>. The root's certificate is signed
by the root itself because there is no higher authority in a
certification hierarchy. The root's certificate is then the first
certificate in every <underline>certification path</underline>.


(S) <bold>MISSI usage:</bold> A name previously used for a
<underline>MISSI</underline> <underline>Policy Creation
Authority</underline>, which is <bold>NOT</bold> a
<underline>root</underline> as defined above for general usage, but is
a CA at the second level of the MISSI hierarchy, immediately
subordinate to a MISSI root called a <underline>Policy Approving
Authority</underline>.


(S) <bold>PKIX usage:</bold> A CA whose certificate is self-signed;
that is, the issuer and subject are the same entity.


(S) <bold>UNIX usage:</bold> A system user account (also called
"superuser") that has all <underline>privileges</underline> (including
all <underline>security</underline>-related privileges) and thus can
manage the system and its other user accounts.


<bold>root certificate =20

</bold>(R) The <underline>self-signed</underline> <underline>public-key
certificate</underline> at the top of a <underline>certification
hierarchy</underline>. (Also see <underline>root</underline>.)


</bigger></fontfamily>Finally, please note that this sort of rooting
around in terminology points out  the lack of a comprehensive and
internally consistent set of crisp, clean, clear definitions is the
root of much misunderstanding in the PKI arena. We need to do more than
just dig into this embedded problem one tuber--I mean, term--at a time,
as we have done with "root" and with "verify vs. validate".


Regards, -Rob-


[e-mail], Phone [phone], Reception 284-4600, Fax [phone]

Robert W. Shirey, GTE Internetworking - Mail Stop 30/12B2, Suite 1200=20


1300 North Seventeenth Street, Arlington, Virginia   22209-3801   USA



-







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA23614 for ietf-pkix-bks; Wed, 27 Jan 1999 13:32:27 -0800 (PST)
Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA23608 for <[e-mail]>; Wed, 27 Jan 1999 13:32:25 -0800 (PST)
Received: from n31.dial.tue.nl [131.155.209.30] by mailhost.tue.nl (8.9.0) for <[e-mail]> id WAA15576 (SMTP). Wed, 27 Jan 1999 22:34:48 +0100 (MET)
From: [e-mail] (Arnoud "Galactus" Engelfriet)
Newsgroups: list.ietf.pkix
To: [e-mail]
Subject: Re: Terminology question: "root CA"
Date: Wed, 27 Jan 1999 22:26:54 +0100
Organization: MCGV STACK, Eindhoven, The Netherlands
Message-ID: <[e-mail]>
References: <4.1.19990127140608.00aa3dd0@209.172.119.123>
Lines: 20
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In article <4.1.19990127140608.00aa3dd0@209.172.119.123>,
Al Arsenault <[e-mail]> wrote:
> My personal preference is to point out the conflict somewhere in the
> Roadmap, and to use "root CA" to indicate the top of a hierarchy, and
> "trust anchor" to indicate the node that is trusted directly.  I'm
> soliciting other suggestions, though.

Would using the term "top-level CA" for the hierarchy's top not
be more clear? Then "root CA" can still be used for the starting
point in a chain of trust.

Greetings,

Arnoud

-- 
\/  Arnoud "Galactus" Engelfriet - [e-mail]              This space
    5th year Business & Computing Science student                 left blank
    URL: http://www.stack.nl/~galactus/  PGP: 0x416A1A35      intentionally.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA22348 for ietf-pkix-bks; Wed, 27 Jan 1999 11:16:54 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22344 for <[e-mail]>; Wed, 27 Jan 1999 11:16:52 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id OAA16701; Wed, 27 Jan 1999 14:19:26 -0500
Message-Id: <4.1.19990127140608.00aa3dd0@209.172.119.123>
X-Sender: aarsenault#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 27 Jan 1999 14:13:43 -0500
To: [e-mail]
From: Al Arsenault <[e-mail]>
Subject: Terminology question:  "root CA"
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Okay, time to resolve a conflict in terminology:

PKIX-1, the Cert & CRL profile,  implicitly uses "root CA" to indicate the
CA at the top of a hierarchy (see Section 6, "Certificate Path
Validation").  CMP, on the other hand, explicitly states:

	" 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."  (See section 1.2.2, "Certification Authority".)

In the original draft of the Roadmap, we used the term 'root CA' to
indicate the top of a hierarchy - possibly, a hierarchy of one CA.  It was
pointed out that this was inconsistent with CMP.  So - what do we do to fix
it in the next draft, especially given the apparent conflict between the
two soon-to-be RFC's pointed out above?

My personal preference is to point out the conflict somewhere in the
Roadmap, and to use "root CA" to indicate the top of a hierarchy, and
"trust anchor" to indicate the node that is trusted directly.  I'm
soliciting other suggestions, though.

Thanks for any inputs,

			Al Arsenault


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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21265 for ietf-pkix-bks; Wed, 27 Jan 1999 09:40:37 -0800 (PST)
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 JAA21261 for <[e-mail]>; Wed, 27 Jan 1999 09:40:34 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <DVHC5K2Q>; Wed, 27 Jan 1999 12:38:10 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E2AD417@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Phillip M Hallam-Baker'" <[e-mail]>, [e-mail]
Cc: ietf-pkix <[e-mail]>
Subject: RE: OCSP & Authority Information Access
Date: Wed, 27 Jan 1999 12:38:07 -0500
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A self-signed certificate offers some level of integrity protection to
the root public key. It also binds the key to a name (although there is
little trust in this binding since it is self-signed) - this name is
useful for displaying to the human user. The self-signed certs (root
keys and names) can be stored on unprotected media (if necessary)
without any additional integrity protection mechanisms. 

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================

-----Original Message-----
From: Phillip M Hallam-Baker [mailto:[e-mail]]
Sent: Wednesday, January 27, 1999 12:21 PM
To: [e-mail]; Michael Myers; ietf-pkix
Subject: RE: OCSP & Authority Information Access


> 
> I have a problem to understand why we consider self-signed
certificates
> instead of root keys as primary trusted data objects. More specific
> comments in lines below. 

This is something I thought a lot about when I was at W3C, we were
looking
at a system in which root keys were expressed as URLs.

The distinction pointed out is that if the KEY is trusted then the means
of revocation needs to refer to the KEY (which in our case it did, a 
revocation statement referred to the URL of the revoked key).

In the case of PKIX however it is the Serial Number of the self signed
cert which is used for revocation. Thus it is the binding of the key to
the serial number which is trusted in this respect. A similar argument
may then be made wrt the subject name.


Although this may appear to be a debate in semantics, this is of course
what a standards effort (court proceeding, academic paper) is.

I do not however think that it is necessary to over-analyse the point.
SDSI is fine if one wishes to construct an algebra of trust in which
to analyse a PKI such as PKIX. I now believe that the value of approach
is limited to being an analytical tool and that reifying it in an
implementation is a mistake. It is too low level, it is necessary to
make simplifying assumptions to make the system tractible. 'Structured
trust' is necessary for the same reason as 'structured programming'.

Although one can make a distinction between reliance on the key and 
reliance on the self signed certificate, trusting the key if the
certificate is lost it is IMHO not wise to do so.


		Phill




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21068 for ietf-pkix-bks; Wed, 27 Jan 1999 09:16:46 -0800 (PST)
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 JAA21064 for <[e-mail]>; Wed, 27 Jan 1999 09:16:45 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA12574; Wed, 27 Jan 1999 09:15:37 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA27191; Wed, 27 Jan 1999 09:18:46 -0800 (PST)
From: "Phillip M Hallam-Baker" <[e-mail]>
To: <[e-mail]>, "Michael Myers" <[e-mail]>, "ietf-pkix" <[e-mail]>
Subject: RE: OCSP & Authority Information Access
Date: Wed, 27 Jan 1999 12:20:48 -0500
Message-ID: <001701be4a19$6178d820$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> I have a problem to understand why we consider self-signed certificates
> instead of root keys as primary trusted data objects. More specific
> comments in lines below. 

This is something I thought a lot about when I was at W3C, we were looking
at a system in which root keys were expressed as URLs.

The distinction pointed out is that if the KEY is trusted then the means
of revocation needs to refer to the KEY (which in our case it did, a 
revocation statement referred to the URL of the revoked key).

In the case of PKIX however it is the Serial Number of the self signed
cert which is used for revocation. Thus it is the binding of the key to
the serial number which is trusted in this respect. A similar argument
may then be made wrt the subject name.


Although this may appear to be a debate in semantics, this is of course
what a standards effort (court proceeding, academic paper) is.

I do not however think that it is necessary to over-analyse the point.
SDSI is fine if one wishes to construct an algebra of trust in which
to analyse a PKI such as PKIX. I now believe that the value of approach
is limited to being an analytical tool and that reifying it in an
implementation is a mistake. It is too low level, it is necessary to
make simplifying assumptions to make the system tractible. 'Structured
trust' is necessary for the same reason as 'structured programming'.

Although one can make a distinction between reliance on the key and 
reliance on the self signed certificate, trusting the key if the
certificate is lost it is IMHO not wise to do so.


		Phill





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA20748 for ietf-pkix-bks; Wed, 27 Jan 1999 08:38:05 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA20744 for <[e-mail]>; Wed, 27 Jan 1999 08:38:04 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id LAA09697; Wed, 27 Jan 1999 11:40:35 -0500
Message-Id: <4.1.19990127112822.00aa1bc0@209.172.119.123>
X-Sender: aarsenault#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 27 Jan 1999 11:34:51 -0500
To: [e-mail]
From: Al Arsenault <[e-mail]>
Subject: POP section for next Roadmap draft
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_945425781==_.ALT"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--=====================_945425781==_.ALT
Content-Type: text/plain; charset="us-ascii"

Folks,

        Sean and I are working on the next draft of the PKIX Roadmap.  One of
the things that has to be done is filling in the Proof of Possession section
(section 5.2 in draft -00).  Attached is a first cut at text for that section. 
Any strong comments one way or the other on this?


POP 
Proof of Possession, or POP, means that the CA is adequately convinced that the
entity requesting a certificate containing a public key Y has access to the
private key X corresponding to that public key.  

POP is important because it provides an appropriate level of assurance in the
correct operation of the PKI as a whole.  There are those who dismiss POP as
unimportant because the most direct threat it counters is the “self-inflicted
denial of service”; that is, an entity voluntarily gets a certificate that
cannot be used to sign or encrypt/decrypt information.  However, as the
following two examples demonstrate, the true threat countered by POP is less
direct, but more important:
POP for signing keys:  it is important to provide POP for keys used to sign
material, in order to provide authentication and possibly non-repudiation of
transactions.  For example, suppose Alice legitimately has private key X and
its corresponding public key Y.  Alice has a certificate from Charlie, a CA,
containing Y.  Alice uses X to sign a transaction T.  Without POP, Mal could
also get a certificate from Charlie containing the same public key, Y.  Now,
there are two possible threats:  Mal could claim to have been the real signer
of T; or Alice can falsely deny signing T, claiming that it was instead Mal. 
Since no one can reliably prove that Mal did or did not ever possess X, neither
of these claims can be refuted, and thus the service provided by and the
confidence in the PKI has been defeated.  (Of course, if Mal really did possess
X, Alice’s private key, then no POP mechanism in the world will help, but that
is a different problem.)

POP for key management keys:  Similarly, POP for key management keys (that is,
keys used for either key agreement or key exchange) can help to prevent
undermining confidence in the PKI.  Suppose that Al is a new instructor in the
Computer Science Department of a local University.  Al has created a draft
final exam for the Introduction to Networking course he is teaching.  He wants
to send a copy of the draft final to Dorothy, the Department Head, for her
review prior to giving the exam.  This exam will of course be encrypted, as
several students have access to the computer system.  However, a quick search
of the certificate repository turns up the fact that several students have
certificates containing the same public key management key as Dorothy.  At this
point, if no POP has been done by the CA, Al has no way of knowing whether all
of the students have simply created these certificates without knowing the
corresponding private key (and thus it is safe to send the encrypted exam to
Dorothy), or whether the students have somehow acquired Dorothy’s private key
(and thus it is certainly not safe to send the exam).  Thus, the service to be
provided by the PKI - allowing users to communicate with one another, with
confidence in who can read their communications - has been totally defeated. If
the CA is providing POP, then either no students will have such certificates,
or Al can know with certainty that the students do indeed know Dorothy’s
private key, and act accordingly.

CMP requires that POP be provided for all keys, either through on-line or
out-of-band means.  There are any number of ways to provide POP, and the choice
of which to use is a local matter.  Additionally, a certificate requester can
provide POP to either a CA or to an RA, if the RA can adequately assure the CA
that POP has been performed.  Some of the acceptable ways to provide POP
include:

        POP by Out-of-band means:  
For keys generated by the CA or an RA (e.g., on a token such as a smart card or
PCMCIA card), possession of the token can provide adequate proof of possession
of the private key.

For user-generated keys, another approach can be used in environments where
“key recovery” requirements force the requester to provide a copy of the
private key to the CA or an RA.  In this case, the CA will not issue the
requested certificate until such time as the requester has provided the private
key.  This approach is in general not recommended, as it is extremely risky
(e.g., the system designers need to figure out a way to protect the private
keys from compromise while they are being sent to the CA/RA/other authority,
and how to protect them there), but it can be used. 

        POP by On-line means:
For signature keys that are generated by an end-entity, the requester of a
certificate can be required to sign some piece of data (typically, the
certificate request itself) using the private key.  The CA will then use the
requested public key to verify the signature.  If the signature verification
works, the CA can safely conclude that the requester had access to the private
key.  If the signature verification process fails, the CA can conclude that the
requester did not have access to the correct private key, and reject the
request.

For key management keys that are generated by the requester, the CA can send
use the requested public key, along with the CA’s own private key, to encrypt
some piece of data, and send it to the requester to be decrypted.  For example,
the CA can generate some random challenge, and require some action to be taken
after decryption (e.g., “decrypt this encrypted random number and send it back
to me”).  If the requester does not take the requested action, the CA concludes
that the requester did not possess the private key, and the certificate is not
issued.  

Another method of providing POP for key management keys is for the CA to
generate the requested certificate, and then send it to the requester in
encrypted form.  If the requester does not have access to the appropriate
private key, the requester cannot decrypt the certificate, and thus cannot use
it. After some period of time in which the certificate is not used, the CA will
revoke the certificate.  (This only works if the certificate is not made
available to any untrusted entities until after the requester has successfully
decrypted it.



Thanks,

                        Al Arsenault

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

--=====================_945425781==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
Folks,<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Sean and I
are working on the next draft of the PKIX Roadmap.&nbsp; One of the
things that has to be done is filling in the Proof of Possession section
(section 5.2 in draft -00).&nbsp; Attached is a first cut at text for
that section.&nbsp; Any strong comments one way or the other on
this?<br>
<br>
<br>
<font size=3D4><b><i>
<dl>
<dd>POP</font></b></i><font face=3D"Courier New, Courier">
</dl>Proof of Possession, or POP, means that the CA is adequately
convinced that the entity requesting a certificate containing a public
key Y has access to the private key X corresponding to that public
key.&nbsp; <br>
<br>
POP is important because it provides an appropriate level of assurance in
the correct operation of the PKI as a whole.&nbsp; There are those who
dismiss POP as unimportant because the most direct threat it counters is
the =93self-inflicted denial of service=94; that is, an entity voluntarily
gets a certificate that cannot be used to sign or encrypt/decrypt
information.&nbsp; However, as the following two examples demonstrate,
the true threat countered by POP is less direct, but more=20
important:<br>

<dl>
<dd>POP for signing keys:&nbsp; it is important to provide POP for keys
used to sign material, in order to provide authentication and possibly
non-repudiation of transactions.&nbsp; For example, suppose Alice
legitimately has private key X and its corresponding public key Y.&nbsp;
Alice has a certificate from Charlie, a CA, containing Y.&nbsp; Alice
uses X to sign a transaction T.&nbsp; Without POP, Mal could also get a
certificate from Charlie containing the same public key, Y.&nbsp; Now,
there are two possible threats:&nbsp; Mal could claim to have been the
real signer of T; or Alice can falsely deny signing T, claiming that it
was instead Mal.&nbsp; Since no one can reliably prove that Mal did or
did not ever possess X, neither of these claims can be refuted, and thus
the service provided by and the confidence in the PKI has been
defeated.&nbsp; (Of course, if Mal really did possess X, Alice=92s private
key, then no POP mechanism in the world will help, but that is a
different problem.)<br>
<br>

<dd>POP for key management keys:&nbsp; Similarly, POP for key management
keys (that is, keys used for either key agreement or key exchange) can
help to prevent undermining confidence in the PKI.&nbsp; Suppose that Al
is a new instructor in the Computer Science Department of a local
University.&nbsp; Al has created a draft final exam for the Introduction
to Networking course he is teaching.&nbsp; He wants to send a copy of the
draft final to Dorothy, the Department Head, for her review prior to
giving the exam.&nbsp; This exam will of course be encrypted, as several
students have access to the computer system.&nbsp; However, a quick
search of the certificate repository turns up the fact that several
students have certificates containing the same public key management key
as Dorothy.&nbsp; At this point, if no POP has been done by the CA, Al
has no way of knowing whether all of the students have simply created
these certificates without knowing the corresponding private key (and
thus it is safe to send the encrypted exam to Dorothy), or whether the
students have somehow acquired Dorothy=92s private key (and thus it is
certainly not safe to send the exam).&nbsp; Thus, the service to be
provided by the PKI - allowing users to communicate with one another,
with confidence in who can read their communications - has been totally
defeated. If the CA is providing POP, then either no students will have
such certificates, or Al can know with certainty that the students do
indeed know Dorothy=92s private key, and act accordingly.<br>
<br>

</dl>CMP requires that POP be provided for all keys, either through
on-line or out-of-band means.&nbsp; There are any number of ways to
provide POP, and the choice of which to use is a local matter.&nbsp;
Additionally, a certificate requester can provide POP to either a CA or
to an RA, if the RA can adequately assure the CA that POP has been
performed.&nbsp; Some of the acceptable ways to provide POP=20
include:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>POP by
Out-of-band means:
<dl>
<dd>For keys generated by the CA or an RA (e.g., on a token such as a
smart card or PCMCIA card), possession of the token can provide adequate
proof of possession of the private key.<br>
<br>

<dd>For user-generated keys, another approach can be used in environments
where =93key recovery=94 requirements force the requester to provide a copy
of the private key to the CA or an RA.&nbsp; In this case, the CA will
not issue the requested certificate until such time as the requester has
provided the private key.&nbsp; This approach is in general not
recommended, as it is extremely risky (e.g., the system designers need to
figure out a way to protect the private keys from compromise while they
are being sent to the CA/RA/other authority, and how to protect them
there), but it can be used. <br>
<br>

</dl><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>POP
by On-line means:<br>

<dl>
<dd>For signature keys that are generated by an end-entity, the requester
of a certificate can be required to sign some piece of data (typically,
the certificate request itself) using the private key.&nbsp; The CA will
then use the requested public key to verify the signature.&nbsp; If the
signature verification works, the CA can safely conclude that the
requester had access to the private key.&nbsp; If the signature
verification process fails, the CA can conclude that the requester did
not have access to the correct private key, and reject the request.<br>
<br>

<dd>For key management keys that are generated by the requester, the CA
can send use the requested public key, along with the CA=92s own private
key, to encrypt some piece of data, and send it to the requester to be
decrypted.&nbsp; For example, the CA can generate some random challenge,
and require some action to be taken after decryption (e.g., =93decrypt this
encrypted random number and send it back to me=94).&nbsp; If the requester
does not take the requested action, the CA concludes that the requester
did not possess the private key, and the certificate is not issued.&nbsp;
<br>
<br>

<dd>Another method of providing POP for key management keys is for the CA
to generate the requested certificate, and then send it to the requester
in encrypted form.&nbsp; If the requester does not have access to the
appropriate private key, the requester cannot decrypt the certificate,
and thus cannot use it. After some period of time in which the
certificate is not used, the CA will revoke the certificate.&nbsp; (This
only works if the certificate is not made available to any untrusted
entities until after the requester has successfully decrypted it.<br>
<br>
<br>
<br>
</font>
</dl>Thanks,<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Al
Arsenault<br>
<br>
-- these are my opinions only. They do not necessarily reflect the <br>
opinions of my employer, or of any other organization with which I have a
<br>
relationship.<br>
</html>

--=====================_945425781==_.ALT--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA20710 for ietf-pkix-bks; Wed, 27 Jan 1999 08:32:40 -0800 (PST)
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 IAA20706 for <[e-mail]>; Wed, 27 Jan 1999 08:32:38 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <DVHC5KHD>; Wed, 27 Jan 1999 11:30:14 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E2AD415@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Carlisle Adams'" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Key Recovery in the CMP
Date: Wed, 27 Jan 1999 11:30:12 -0500
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Carlisle,

Thanks for your response to the questions I brought up. Yes, your note
did clarify a lot of issues. 

Now, I am more convinced that the CMP document has insufficient
explanation about key recovery to do justice to the topic. I completely
misunderstood the use of the certificate template field in CertRequest
syntax when used for KR; I thought it was to identify the key to be
recovered, but your explanation now tells me it is the template for the
new signature certificate. At the very least, a lot more explanation is
required to establish the relation between KR and new signature key
certification - the relation is definitely not intuitive. 

I do not see the value of coupling key recovery (of decryption keys)
with new signature verification certificate issuance, at least at the
protocol level. At initialization time, when a new user requests a
encryption certificate, that request is separate from the request for a
signature certificate for the same user. In other words, two separate
requests go to the CA: one for encryption key certification, and another
for signature key certification, even though the user needs both
certificates to establish his/her PSE. Why is it, then, that for key
recovery, the protocols in CMP somehow couple decryption key recovery
with OPTIONAL signature key certification. Admittedly, when a user's PSE
is destroyed, they will not only want to recover their encryption key
pair(s), but will also need to obtain a new signature certificate -
however, that can be achieved with two separate requests sent to the CA,
one for KR and one for signature key certification. I would strongly
suggest that the two operations be separated at the CMP syntax level. 

Based upon your explanation, I have a new question. Is there any way to
identify the key I would like to have recovered? What if I don't want my
whole history of decryption keys returned to me, but want a specific
single key? Is that currently possible? 

You write that the "protectionBits" are to be used to pass
authentication information to the CA. In a key recovery request message,
do the "protectionBits" represent authorization information for key
recovery, or does it hold authentication information related to the new
signature key certification request? Or is it both? What if the
authorization information for recovering old keys happens to be
different that the authorization information required to be supplied for
new signature key certification? 

You write: 
"In other words, the user no longer has access to its PSE and thus -- in
terms of end entity operation -- is effectively in the same position as
a brand new entity trying to get initiated into the system."

I don't see the two situations as being equivalent. There are certainly
some commonalties; but I would argue that there are enough differences
to make it unwise to put "CertReqMessages" through double-duty as the
key recovery request syntax. The presence of a large number of OPTIONAL
fields (that make sense for initialization, but are of questionable
value for KR) make the usage of this syntax for key recovery very
non-intuitive. I am sure this can be corrected with detailed
explanations along the same lines as your response to my note. However,
I don't really see the point in trying to avoid defining a more targeted
syntax for KR request. 

Finally, you did not seem to address the following question from my
previous note:
>Comment 2: CertifiedKeyPair syntax contains the (recovered) private key
>as an EncryptedValue. Should this be EncryptedKey instead? Assuming
that
>the private key is encrypted (by the CA) with a symmetric key - how is
>that symmetric key transported to the requester? We have to assume that
>the requester does not have access to his encryption private key - (why
>else would he request key recovery??) - therefore, normal key transfer
>mechanisms cannot be used. Possibly, the symmetric encryption key that
>is used to encrypt the recovered private key, could have been passed in
>through the key recovery request message. However, the CertReqMessages
>syntax does not seem to support the passing of a symmetric key to be
>used to encrypt a private key returned by the CA. 

Regards, 

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================

-----Original Message-----
From: Carlisle Adams [mailto:[e-mail]]
Sent: Monday, January 25, 1999 12:13 PM
To: 'Sarbari Gupta'
Cc: PKIX (E-mail)
Subject: RE: Key Recovery in the CMP


Hi Sarbari,

Thank you for your questions/comments.  These may highlight a need for
further clarification or discussion in the document (something from
which
virtually any technical specification can always benefit), but I do
believe
that the seed explanations are there.

In particular, page 8 provides the underlying assumption of the document
with respect to key recovery:  it is "used when an end entity has 'lost'
its
PSE" (Personal Security Environment), for example "as a result of a
forgotten password or a lost key chain file".  In other words, the user
no
longer has access to its PSE and thus -- in terms of end entity
operation --
is effectively in the same position as a brand new entity trying to get
initiated into the system.  This is why the syntax used is identical to
the
initialization request; the end entity effectively needs to
re-initialize
(including the out-of-band exchange with the CA/RA to protect the
req/rep/conf messages).  Note, however, that the field for requesting a
new
signature certificate is optional.  This accommodates those situations
in
which the EE wishes to recover one (or more) decryption private keys
without
certifying a new verification public key.  This is one of the reasons
that
POP, too, is optional in the request message.  As for a "field in the
request to allow the requester to pass authorization information", this
is
what the protectionBits are for; there is no need to pass other pass
phrases
or authentication tokens.

In the response message, again the newSigCert is optional to accommodate
the
cases in which a new verification certificate is not generated.
Furthermore, the keyPairHist needs to be a sequence for generality
(i.e., to
accommodate the cases in which one, and in which more than one, key is
recovered).  The syntax of all the messages in CMP need to be general
enough
to meet the needs of certificate management in many different
environments;
any particular environment may omit some optional fields, or send only
one
element of a sequence, or whatever. 

Again, thank you for your interest.  I hope that this helps to clarify
things somewhat.

Carlisle.


-----Original Message-----
From: Sarbari Gupta [mailto:[e-mail]]
Sent: Thursday, January 21, 1999 2:32 PM
To: PKIX (E-mail)
Subject: Key Recovery in the CMP (RESEND WITH LINE FEEDS)

I had several comments related to the treatment of key recovery in the
CMP document. I realize that these comments would have applied to the
last version of CMP - however, I did not get a chance to send these out
in time.

Since there appears to be little or no explanation on how a key recovery
request operation is typically performed, I was forced to make my own
assumptions, and base my comments upon those assumptions. The primary
point I would like to make is that the handling of key recovery in the
current CMP document is much too terse, and, depending upon the
assumptions and envisioned scenarios, the message syntax may be
incomplete or even flawed. I personally think that the key recovery
portion of CMP needs to be reworked and expanded. 

My specific comments follow: 

I) In section 3.3.7, under key recovery request message: 

Comment 1: The CMP document says, "For key recovery requests the syntax
used is identical to the initialization request, CertReqMessages." I
would contend that key recovery is dissimilar enough from initial
certification request that it deserve a more targeted message syntax.
For example, the CertReqMessages syntax in CRMF has an optional
ProofOfPossession field that is in inapplicable for key recovery (how
can you prove possession of a private key that you are trying to
recover??) Conversely, the CertReqMessages syntax does not appear to
support a field that will allow the requester to pass authorization
information (such as a passphrase or authentication token) to the CA. I
would recommend that the syntax for a new message, KeyRecoveryReq, be
defined to specifically address the required fields for key recovery. I
would be happy to supply this new syntax if there is agreement on this
issue.  

Comment 2: The sentence "Typically, SubjectPublicKeyInfo and KeyId are
the template fields which may be used to supply a signature public key
for which a certificate is required" has many inconsistencies. First,
key recovery requires key identification, and not templates. Second, why
would I want to supply my signature public key for key recovery instead
of my encryption public key? Third, it says, "a certificate is required"
as the intended goal of key recovery - in actuality, a private key is
required. This sentence should be rewritten to something like: "
Typically, the SubjectPublicKeyInfo and KeyId fields are used to
identify the private key for which recovery is required."


II) In Section 3.3.8, under Key recovery response content: 

The syntax for the response message is specified in CMP as:
  >>KeyRecRepContent ::= SEQUENCE { 
  >>	status PKIStatusInfo, 
  >>	newSigCert [0] Certificate OPTIONAL, 
  >>	caCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, 
  >>	keyPairHist [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair

OPTIONAL }

Comment 1: The key recovery request message identifies the single key to
be recovered. Yet, the response message, (surprisingly) returns a new
signature certificate, and a sequence of key pairs. I understand that in
certain implementations of key recovery, the signature key is
automatically regenerated when an encryption key is recovered. However,
either there needs to be extensive explanation on this issue, or the key
recovery response syntax needs to be decoupled from the issuance of new
signature certificates. The current syntax and accompanying explanation
does not hang together.

Comment 2: CertifiedKeyPair syntax contains the (recovered) private key
as an EncryptedValue. Should this be EncryptedKey instead? Assuming that
the private key is encrypted (by the CA) with a symmetric key - how is
that symmetric key transported to the requester? We have to assume that
the requester does not have access to his encryption private key - (why
else would he request key recovery??) - therefore, normal key transfer
mechanisms cannot be used. Possibly, the symmetric encryption key that
is used to encrypt the recovered private key, could have been passed in
through the key recovery request message. However, the CertReqMessages
syntax does not seem to support the passing of a symmetric key to be
used to encrypt a private key returned by the CA. 

Best regards, 

- Sarbari Gupta 

=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA14123 for ietf-pkix-bks; Wed, 27 Jan 1999 02:30:40 -0800 (PST)
Received: from pluto.deh.de ([194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA14110 for <[e-mail]>; Wed, 27 Jan 1999 02:30:33 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id LAA18079; Wed, 27 Jan 1999 11:32:46 +0100
Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id LAA09421; Wed, 27 Jan 1999 11:32:50 +0100
Message-ID: <[e-mail]>
Date: Wed, 27 Jan 1999 11:35:31 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: OCSP & Authority Information Access
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

I have a problem to understand why we consider self-signed certificates
instead of root keys as primary trusted data objects. More specific
comments in lines below. 

[...]
> 
> 2) Even so, putting a fixed pointer in the CA cert for those that use this
> extension is ill-advised.  If the pointer were for some reason to change
> over time, it's fairly easy to begin using a new value in newly-issued
> end-entity certificates.  One can maintain the service at the old pointer
> during an transition period.  If the pointer is in the CA certificate, it's
> more difficult to change, particularly if you're talking about self-signed
> (or root) certificates.  This is and should be a trusted process.

The root key, i. e. the public key of the directly trusted CA, is
essentially the trusted data object less the self-signed (or root)
certificate, which contains this public key. 

>  In some
> circumstances, it may be necessary to recall hardware tokens that use a
> special trusted store for roots.  Definitely a painful and expensive
> process.

This would be definitely not when the CA reissue a self-signed (root)
certificate which certifies the already delivered root key. This process
is less painful and expensive. In a first step the CA has to publish a 
new self-signed root certificate containing the updated information.
This self-signed certificate is signed with the already delivered root
key. In a second step the CA publishs its new self-signed certificate.
In a transitional period there are two self-signed certificates. In your
example the old and the new pointer must be meaningful. In a third step,
after an appropriately chosen transition period, the old self-signed
certificate has to be revoked (reasonCode = superseded???).

The described process fits smart cards environments as well, doesn´t it?


> 
> Mike


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA12366 for ietf-pkix-bks; Wed, 27 Jan 1999 01:31:56 -0800 (PST)
Received: from barbar.esat.kuleuven.ac.be ([e-mail] [134.58.56.153]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA12362 for <[e-mail]>; Wed, 27 Jan 1999 01:31:51 -0800 (PST)
Received: from domus.esat.kuleuven.ac.be (domus.esat.kuleuven.ac.be [134.58.189.68]) by barbar (version 8.8.5)  with ESMTP id KAA13211; Wed, 27 Jan 1999 10:34:14 +0100 (MET)
Organization: ESAT, K.U.Leuven, Belgium
Date: Wed, 27 Jan 1999 10:34:14 +0100 (MET)
From: "CMS'99" <[e-mail]>
To: [e-mail]
Subject: CFP: Communications and Multimedia Security '99
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.proper.com id BAA12363
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Apologies if you receive this more than once.]

------------------------------------------------------------------------
           International Federation for Information Processing

                                 CMS '99
                  Communications and Multimedia Security        

                Joint working conference IFIP TC6 and TC11

                          September 20-21, 1999
                  Katholieke Universiteit Leuven, Belgium

 
------------------------------------------------------------------------
                              Call For Papers
 
------------------------------------------------------------------------

GOALS and TOPICS of INTEREST

CMS '99 is the fourth in a series of international conferences which aim 
at reviewing state-of-the-art issues as well as practical experiences
and new trends in the areas of communications and multimedia systems
security.

It is the intention of the organisers to focus the attention of the
conference presentations and discussions on issues which combine
innovative research work with a highly promising application potential.

Topics of interest include, but are not limited to
   * communications systems security
   * mobile communications security
   * Internet, intranet and extranet security
   * security of mobile code
   * multimedia systems security
   * applied cryptography
   * electronic commerce and digital signatures
   * security in distributed systems
   * secure teleworking, telecooperation, telemedicine
   * legal, social and ethical aspects of communication systems security
   * standards for communication and multimedia systems security

SUBMISSION DETAILS

Authors are strongly encouraged to submit their papers electronically.
Please email your submission in postscript (or pdf) format to:
[e-mail]
Electronic submissions must be received by March 15, 1999, 23:00 GMT in
order to be considered.

Authors unable to submit electronically are invited to send a cover
letter and 5 (five) copies of an anonymous paper (double-sided copies
preferred) to the Program Chair at the postal address below. Submissions
must be received by the Program Chair on or before March 15, 1999.

The cover letter should contain the paper's title and the names and
affiliations of the authors, and should identify the contact author
including e-mail and postal addresses.

Submissions must not substantially duplicate work that any of the
authors have published elsewhere or have submitted in parallel to any
other conference or workshop that has proceedings. The paper must be
anonymous, with no author names, affiliations, acknowledgments, or
obvious references. It should begin with a title, a short abstract, and
a list of key words, and its introduction should summarise the 
contributions of the paper at a level appropriate for a non-specialist
reader. The paper should be at most 5000 words long.  A full page figure
is 500 words. It is anticipated that the proceedings will be published by
Kluwer Academic Publishers. Therefore authors are encouraged to use for
their submissions the Kluwer IFIP templates for LaTeX or Word (see
http://www.wkap.com/IFIP).

All submitted papers will be refereed by at least three members of the
International Program Committee according to the standard blind
refereeing procedures. The Conference Proceedings will be published by
an international publisher; copies of the proceedings will be available
at the conference.

Notification of acceptance or rejection will be sent to authors by April
30, 1999. Authors of accepted papers must guarantee that their paper
will be presented at the conference.

Important dates:

   * Submission Deadline: March 15, 1999
   * Notification: April 30, 1999
   * Final camera-ready version: May 21, 1999
   * Conference: September 20-21, 1999

To submit a paper, or for further details, please contact:

  Prof. Bart Preneel,
  Program Committee Chair CMS'99
  Katholieke Universiteit Leuven
  Dept. Electrical Engineering-ESAT/COSIC
  K. Mercierlaan 94, B-3001 Heverlee, BELGIUM

  Email: [e-mail]
  Tel [phone]    Fax: [phone]
  For further details see http://www.esat.kuleuven.ac.be/cosic/cms99/

Program Committee Chair:
  B. Preneel, Katholieke Universiteit Leuven, Belgium

Program Committee:
  P. Ashley, Queensland University of Technology, Australia
  A. Casaca, Inesc, Portugal
  S. Fischer-Huebner, Hamburg University, Germany
  W. Fumy, Siemens Research, Germany
  D. Gollmann, Microsoft Research, UK
  D. Gritzalis, Athens University of Economics and Business, Greece
  P. Horster, University of Klagenfurt, Austria
  S. Katsikas, University of the Aegean, Greece
  L.R. Knudsen, University of Bergen, Norway
  C. Mitchell, Royal Holloway, University of London, UK
  D. Naccache, Gemplus, France
  R. Oppliger, BFI, Switzerland
  G. Pernul, University of Essen, Germany
  R. Posch, TU Graz, Austria
  G. Quirchmayr, University of Vienna, Austria
  J.-J. Quisquater, Université Catholique de Louvain, Belgium
  M. Reiter, Bell Labs, USA
  D. Tygar, University of California at Berkeley, USA
  P. van Oorschot, Entrust Technologies, Canada
  S.H. von Solms, Rand Afrikaans University, South Africa
  L. Yngstrom, Stockholm University and Royal Institute of Technology,
Sweden
  L Strous, De Nederlandsche Bank NV, The Netherlands, advisory member


Organising Committee Chair:
  J. Vandewalle, Katholieke Universiteit Leuven

Organising Committee:
  Joris Claessens,  Katholieke Universiteit Leuven
  Jorge Nakahara,  Katholieke Universiteit Leuven
  Péla Noë,  Katholieke Universiteit Leuven
  Vincent Rijmen,  Katholieke Universiteit Leuven
  Mark Vandenwauver,  Katholieke Universiteit Leuven

Main Organiser:
  IFIP TC 11 and TC 6
 
------------------------------------------------------------------------




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA12320 for ietf-pkix-bks; Wed, 27 Jan 1999 01:30:16 -0800 (PST)
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 BAA12315 for <[e-mail]>; Wed, 27 Jan 1999 01:30:14 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id KAA40360; Wed, 27 Jan 1999 10:32:33 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id KAA12500; Wed, 27 Jan 1999 10:35:14 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Wed, 27 Jan 1999 10:32:56 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: OCSP & Authority Information Access
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mike,

Let me answer to your arguments:


> I must respectfully disagree on two points:
>
> 1) To reiterate a point I made earlier, the semantics of the AII extension
> are defined by Part 1, not the OCSP draft.  So changing OCSP isn't
> sufficient.  It's also necessary to change Part 1.  Otherwise, the OCSP spec
> would fail to comply with the direction given in Part 1.

Oncre again, PKIX1, section 4.2.2.1 contains the following:

4.2.2.1  Authority Information Access

   The authority information access extension indicates how to access CA
   information and services for the issuer of the certificate in which
   the extension appears. Information and services may include on-line
   validation services and CA policy data.  (The location of CRLs is not
   specified in this extension; that information is provided by the
   cRLDistributionPoints extension.)  This extension may be included in
   subject or CA certificates, and it is always non-critical.

Part 1 needs no revision. It says MAY be included. So I respectfully disagree
with this argument.

>
> 2) Even so, putting a fixed pointer in the CA cert for those that use this
> extension is ill-advised.  If the pointer were for some reason to change
> over time, it's fairly easy to begin using a new value in newly-issued
> end-entity certificates.  One can maintain the service at the old pointer
> during an transition period.

The same argument applies with the self-signed certificate: one can maintain the
service at the old pointer
during a transition period.


> If the pointer is in the CA certificate, it's
> more difficult to change, particularly if you're talking about self-signed
> (or root) certificates.  This is and should be a trusted process.

True, but self-signed certificates changes over time. They are not for ever.

> In some
> circumstances, it may be necessary to recall hardware tokens that use a
> special trusted store for roots.  Definitely a painful and expensive
> process.

This is precisely because I care for the memory size of these hardware tokens
that the extension should not be placed in leaf certificates.

Now, to come back to the real topic, the spirit of PKIX is not to say that every
PKIX compliant implementation SHALL support every optional extension (even if it
is not used by the final customer). I cannot understand why you want to make a
special case for that OPTIONAL extension.

Regards,

Denis

>
> Mike



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA20238 for ietf-pkix-bks; Tue, 26 Jan 1999 18:27:03 -0800 (PST)
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 SAA20234 for <[e-mail]>; Tue, 26 Jan 1999 18:27:02 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id SAA00196; Tue, 26 Jan 1999 18:25:51 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id SAA11377; Tue, 26 Jan 1999 18:28:59 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <DJMYN0WR>; Tue, 26 Jan 1999 18:29:01 -0800
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: IETF-PXIX <[e-mail]>
Subject: RE: OCSP & Authority Information Access
Date: Tue, 26 Jan 1999 18:28:57 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Responses inline, with some trimming.

> You wrote:
> From: Denis Pinkas [mailto:[e-mail]]
> . . .
>
> > It means the capability shall be there, but its use in any 
> particular
> > circumstance is a matter of choice.  I would have preferred 
> the simplicity
> > of a single way of doing things, but legacy effect 
> considerations alone
> > warranted the wording of the requirement.
> 
> Well, let me see ...
> 
> Suppose I propose a PKIX Part 1 compliant PKI issuing CRLs. 
> My customer later
> on decides to install an OCSP server. According to the 
> wording it seems that
> my PKIX Part 1 compliant software suite is no more compliant with the
> standard. My customer might then complain that I provided him 
> with a non
> compliant software.

I agree that if you choose not to implement functionality required by any
spec, then that product could be non-compliant.  I must again note that the
requirement doesn't require deployment of AII extension, which I believe
meets your original concern.  Irregardless, there's strong merit in
maintaining the text as is . . . .

> It seems to me that this sort of situations should not 
> happen. We need to
> revise the wording now or later.
> At the minimum the SHALL "shall" be turned into a "SHOULD". I 
> did not say  the
> SHALL "should l" be turned into a "SHOULD".  :-)
> 
> Besides that point I also want to deprecate the use of such 
> an extension in
> leaf certificates. This this respect I am proposing again my 
> previous text,
> but changing the SHALL into a SHOULD:
> 
> " 4.1  Certificate Content
> 
> In order to convey to OCSP clients a well-known point of information
> access, CAs SHOULD provide the capability to include the
> AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1)
> in their self-signed certificates (CA certificate) so that it can be
> known that some or all the subjects certificates from that CA can be
> checked using OCSP. Alternatively, the accessLocation for the OCSP
> provider may be configured locally at the OCSP client."

I must respectfully disagree on two points:

1) To reiterate a point I made earlier, the semantics of the AII extension
are defined by Part 1, not the OCSP draft.  So changing OCSP isn't
sufficient.  It's also necessary to change Part 1.  Otherwise, the OCSP spec
would fail to comply with the direction given in Part 1. 

2) Even so, putting a fixed pointer in the CA cert for those that use this
extension is ill-advised.  If the pointer were for some reason to change
over time, it's fairly easy to begin using a new value in newly-issued
end-entity certificates.  One can maintain the service at the old pointer
during an transition period.  If the pointer is in the CA certificate, it's
more difficult to change, particularly if you're talking about self-signed
(or root) certificates.  This is and should be a trusted process.  In some
circumstances, it may be necessary to recall hardware tokens that use a
special trusted store for roots.  Definitely a painful and expensive
process.

Mike


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA19058 for ietf-pkix-bks; Tue, 26 Jan 1999 15:37:03 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA19053 for <[e-mail]>; Tue, 26 Jan 1999 15:36:52 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <DSKVC5Q8>; Wed, 27 Jan 1999 10:38:40 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC094386@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Krylov Pavel'" <[e-mail]>, [e-mail]
Subject: RE: RDN
Date: Wed, 27 Jan 1999 10:38:39 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Its to enable a name to have the flexibility in becoming distingushed by
having a range of attribute types applied to it eg. Common Name + Unique
Identifier
eg. Under Engine Parts we could have entries with names like 
Cam Sprocket  +  12345
Cam Sprocket + 133355


This approach can be used for a pile of John Smiths as well. ie Common
Name + DN Qualifer

Rigid Name syntax with single values  that are enforced into technology
just means that flexibility for directory applications in the real world
could be lost.


hope this helps and regards alan

> -----Original Message-----
> From:	Krylov Pavel 
> Sent:	Tuesday, January 26, 1999 7:23 PM
> To:	[e-mail]
> Subject:	RDN
> 
> Hi all,
> I'm sorry if I repeat someone's question, but I don't understand what
> logic is applied to multi-valued RDN ( RelativeDistinguishedName ).
> ( In X.500 there are contexts for each value in one RDN or nothing
> for main value in RDN ).
> 
> 	Q1. Are there any senses in this variety? and what?
> 	Q2. What logic is applied to compare such RDNs?
> 
> 	RelativeDistinguishedName ::=
>      		SET OF AttributeTypeAndValue
> 
> 	AttributeTypeAndValue ::= SEQUENCE {
>      		type     AttributeType,
>      		value    AttributeValue }
> 
> Thanks a lot.
> ___________________________________________
> Krylov Pavel	[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA09603 for ietf-pkix-bks; Tue, 26 Jan 1999 00:23:22 -0800 (PST)
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 AAA09593 for <[e-mail]>; Tue, 26 Jan 1999 00:23:19 -0800 (PST)
Received: by relay2.elvis.ru (8.8.5/1.30) id LAA24756; Tue, 26 Jan 1999 11:25:38 +0300 (MSK)
Received: from tws123(194.190.192.123) by ss10 via smap (V2.0) id xma024734; Tue, 26 Jan 99 11:24:49 +0300
Message-ID: <[e-mail]>
Date: Tue, 26 Jan 1999 11:23:03 +0300
From: Krylov Pavel <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: RDN
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,
I'm sorry if I repeat someone's question, but I don't understand what
logic is applied to multi-valued RDN ( RelativeDistinguishedName ).
( In X.500 there are contexts for each value in one RDN or nothing
for main value in RDN ).

	Q1. Are there any senses in this variety? and what?
	Q2. What logic is applied to compare such RDNs?

	RelativeDistinguishedName ::=
     		SET OF AttributeTypeAndValue

	AttributeTypeAndValue ::= SEQUENCE {
     		type     AttributeType,
     		value    AttributeValue }

Thanks a lot.
___________________________________________
Krylov Pavel	[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA10404 for ietf-pkix-bks; Mon, 25 Jan 1999 12:20:29 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA10400 for <[e-mail]>; Mon, 25 Jan 1999 12:20:27 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id PAA31259; Mon, 25 Jan 1999 15:22:07 -0500
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 22 Jan 1999 13:37:41 -0500
To: Ilan Shacham <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Diffie-Hellman key exchange key in pkix-ipki-part1
Cc: "Ietf-Pkix (E-mail)" <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

You found a typo.

Russ


At 03:15 PM 1/21/99 +0200, Ilan Shacham wrote:
>In pkix-ipki-part1 Diffie-Hellman key exchange algorithmIdentifier params
>are defined as:
>
>7.3.2  Diffie-Hellman Key Exchange Key
>
>   The Diffie-Hellman OID supported by this profile is defined by ANSI
>   X9.42 [X9.42].
>
>        dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
>                  us(840) ansi-x942(10046) number-type(2) 1 }
>
>   The dhpublicnumber OID is intended to be used in the algorithm field
>   of a value of type AlgorithmIdentifier. The parameters field of that
>   type, which has the algorithm-specific syntax ANY DEFINED BY algo-
>   rithm, have the ASN.1 type GroupParameters for this algorithm.
>
>        DomainParameters ::= SEQUENCE {
>              p       INTEGER, -- odd prime, p=jq +1
>              g       INTEGER, -- generator, g
>              q       INTEGER, -- factor of p-1
>              j       INTEGER OPTIONAL, -- subgroup factor
>              validationParms  ValidationParms OPTIONAL }
>
>        ValidationParms ::= SEQUENCE {
>              seed             BIT STRING,
>              pgenCounter      INTEGER }
>
>It looks to me like there is a typo here - GroupParameters written instead
>of DomainParameters. Is this true or am I missing something?
>
>apart from that, does anyone have a reference implementation with a DH
>public key?
>
>Ilan
>
>------------------------------------------------------------------------
>Ilan Shacham				mailto:[e-mail]
>Algorithmic Research Ltd.		http://www.arx.com
>10 Nevatim St.,			phone:	972 - 3 - 9279540
>Petach-Tikva, Israel			Fax:	972 - 3 - 9230864
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA08302 for ietf-pkix-bks; Mon, 25 Jan 1999 09:14:49 -0800 (PST)
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 JAA08298 for <[e-mail]>; Mon, 25 Jan 1999 09:14:48 -0800 (PST)
Received: 	id MAA23255; Mon, 25 Jan 1999 12:13:23 -0500
Received: by gateway id <D4V2S5HJ>; Mon, 25 Jan 1999 12:15:22 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Sarbari Gupta'" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Key Recovery in the CMP
Date: Mon, 25 Jan 1999 12:12:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Sarbari,

Thank you for your questions/comments.  These may highlight a need for
further clarification or discussion in the document (something from which
virtually any technical specification can always benefit), but I do believe
that the seed explanations are there.

In particular, page 8 provides the underlying assumption of the document
with respect to key recovery:  it is "used when an end entity has 'lost' its
PSE" (Personal Security Environment), for example "as a result of a
forgotten password or a lost key chain file".  In other words, the user no
longer has access to its PSE and thus -- in terms of end entity operation --
is effectively in the same position as a brand new entity trying to get
initiated into the system.  This is why the syntax used is identical to the
initialization request; the end entity effectively needs to re-initialize
(including the out-of-band exchange with the CA/RA to protect the
req/rep/conf messages).  Note, however, that the field for requesting a new
signature certificate is optional.  This accommodates those situations in
which the EE wishes to recover one (or more) decryption private keys without
certifying a new verification public key.  This is one of the reasons that
POP, too, is optional in the request message.  As for a "field in the
request to allow the requester to pass authorization information", this is
what the protectionBits are for; there is no need to pass other pass phrases
or authentication tokens.

In the response message, again the newSigCert is optional to accommodate the
cases in which a new verification certificate is not generated.
Furthermore, the keyPairHist needs to be a sequence for generality (i.e., to
accommodate the cases in which one, and in which more than one, key is
recovered).  The syntax of all the messages in CMP need to be general enough
to meet the needs of certificate management in many different environments;
any particular environment may omit some optional fields, or send only one
element of a sequence, or whatever. 

Again, thank you for your interest.  I hope that this helps to clarify
things somewhat.

Carlisle.


-----Original Message-----
From: Sarbari Gupta [mailto:[e-mail]]
Sent: Thursday, January 21, 1999 2:32 PM
To: PKIX (E-mail)
Subject: Key Recovery in the CMP (RESEND WITH LINE FEEDS)

I had several comments related to the treatment of key recovery in the
CMP document. I realize that these comments would have applied to the
last version of CMP - however, I did not get a chance to send these out
in time.

Since there appears to be little or no explanation on how a key recovery
request operation is typically performed, I was forced to make my own
assumptions, and base my comments upon those assumptions. The primary
point I would like to make is that the handling of key recovery in the
current CMP document is much too terse, and, depending upon the
assumptions and envisioned scenarios, the message syntax may be
incomplete or even flawed. I personally think that the key recovery
portion of CMP needs to be reworked and expanded. 

My specific comments follow: 

I) In section 3.3.7, under key recovery request message: 

Comment 1: The CMP document says, "For key recovery requests the syntax
used is identical to the initialization request, CertReqMessages." I
would contend that key recovery is dissimilar enough from initial
certification request that it deserve a more targeted message syntax.
For example, the CertReqMessages syntax in CRMF has an optional
ProofOfPossession field that is in inapplicable for key recovery (how
can you prove possession of a private key that you are trying to
recover??) Conversely, the CertReqMessages syntax does not appear to
support a field that will allow the requester to pass authorization
information (such as a passphrase or authentication token) to the CA. I
would recommend that the syntax for a new message, KeyRecoveryReq, be
defined to specifically address the required fields for key recovery. I
would be happy to supply this new syntax if there is agreement on this
issue.  

Comment 2: The sentence "Typically, SubjectPublicKeyInfo and KeyId are
the template fields which may be used to supply a signature public key
for which a certificate is required" has many inconsistencies. First,
key recovery requires key identification, and not templates. Second, why
would I want to supply my signature public key for key recovery instead
of my encryption public key? Third, it says, "a certificate is required"
as the intended goal of key recovery - in actuality, a private key is
required. This sentence should be rewritten to something like: "
Typically, the SubjectPublicKeyInfo and KeyId fields are used to
identify the private key for which recovery is required."


II) In Section 3.3.8, under Key recovery response content: 

The syntax for the response message is specified in CMP as:
  >>KeyRecRepContent ::= SEQUENCE { 
  >>	status PKIStatusInfo, 
  >>	newSigCert [0] Certificate OPTIONAL, 
  >>	caCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, 
  >>	keyPairHist [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair

OPTIONAL }

Comment 1: The key recovery request message identifies the single key to
be recovered. Yet, the response message, (surprisingly) returns a new
signature certificate, and a sequence of key pairs. I understand that in
certain implementations of key recovery, the signature key is
automatically regenerated when an encryption key is recovered. However,
either there needs to be extensive explanation on this issue, or the key
recovery response syntax needs to be decoupled from the issuance of new
signature certificates. The current syntax and accompanying explanation
does not hang together.

Comment 2: CertifiedKeyPair syntax contains the (recovered) private key
as an EncryptedValue. Should this be EncryptedKey instead? Assuming that
the private key is encrypted (by the CA) with a symmetric key - how is
that symmetric key transported to the requester? We have to assume that
the requester does not have access to his encryption private key - (why
else would he request key recovery??) - therefore, normal key transfer
mechanisms cannot be used. Possibly, the symmetric encryption key that
is used to encrypt the recovered private key, could have been passed in
through the key recovery request message. However, the CertReqMessages
syntax does not seem to support the passing of a symmetric key to be
used to encrypt a private key returned by the CA. 

Best regards, 

- Sarbari Gupta 

=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA04738 for ietf-pkix-bks; Mon, 25 Jan 1999 05:40:21 -0800 (PST)
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 FAA04733 for <[e-mail]>; Mon, 25 Jan 1999 05:40:09 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id OAA11110; Mon, 25 Jan 1999 14:42:30 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id OAA12968; Mon, 25 Jan 1999 14:45:09 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Mon, 25 Jan 1999 14:42:47 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: OCSP & Authority Information Access
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

My comments are along the text.

> Denis,
>
> This response took a bit longer to get to.
>
> > -----Original Message-----
> > > You can operate your CA without using the noted extension and
> > > still comply with the spec.
> >
> > I would like that !
> >
> > The text however says:
> >
> > "CAs SHALL provide the capability to include the
> > AuthorityInfoAccess extension
> > (defined in [PKIX1], section 4.2.2.1) in certificates that
> > can be checked using
> > OCSP."
> >
> > I have thus difficulties to interpret that sentence and
> > understand what the
> > SHALL means.
>
> It means the capability shall be there, but its use in any particular
> circumstance is a matter of choice.  I would have preferred the simplicity
> of a single way of doing things, but legacy effect considerations alone
> warranted the wording of the requirement.

Well, let me see ...

Suppose I propose a PKIX Part 1 compliant PKI issuing CRLs. My customer later
on decides to install an OCSP server. According to the wording it seems that
my PKIX Part 1 compliant software suite is no more compliant with the
standard. My customer might then complain that I provided him with a non
compliant software.

It seems to me that this sort of situations should not happen. We need to
revise the wording now or later.
At the minimum the SHALL "shall" be turned into a "SHOULD". I did not say  the
SHALL "should l" be turned into a "SHOULD".  :-)

Besides that point I also want to deprecate the use of such an extension in
leaf certificates. This this respect I am proposing again my previous text,
but changing the SHALL into a SHOULD:

" 4.1  Certificate Content

In order to convey to OCSP clients a well-known point of information
access, CAs SHOULD provide the capability to include the
AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1)
in their self-signed certificates (CA certificate) so that it can be
known that some or all the subjects certificates from that CA can be
checked using OCSP. Alternatively, the accessLocation for the OCSP
provider may be configured locally at the OCSP client."


Regards,

Denis

>
> Mike



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA29278 for ietf-pkix-bks; Sun, 24 Jan 1999 20:44:43 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA29268 for <[e-mail]>; Sun, 24 Jan 1999 20:44:37 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <DSKVC5KD>; Mon, 25 Jan 1999 15:46:19 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC09437A@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Date: Mon, 25 Jan 1999 15:46:17 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Monday, January 18, 1999 9:11 AM
> To:	Alan Lloyd
> Cc:	[e-mail]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Alan,
> 
> Well, we may be getting closer, but I'm not completely sure.
> 
> >> I think we have to pay close attention to the specific services in
> >> deciding
> >> what constitutes a good way to find appropriate servers.  For
> >> revocation, I
> >> think the CA has an obligation to state how/where is makes
> revocation
> >> data
> >> available, because the CA is the ultimate authority for this data.
> >> Thus,
> >> for example, we can bind into each cert one or more CRL
> distribution
> >> pointers. If a CA chooses to delegate that authority to some 3rd
> >> party, it
> >> needs to do so in a highly secure fashion.
> >	[Alan Lloyd]
> >	The X.500 CA related data structures do provide some of this.
> >The  CA entry can have  its CRL DP  reference pointing to a directory
> >entry of a third party that has the CRL DP with signed CRLs in. My
> usual
> >point here is that it is easier to add a new data structures to a
> >directory service to solve the prolem than hand config info objects
> with
> >server knowledge all over the place.
> >	I think the issue is that its back to the approach of hand
> >crafted knowledge of where things are and configuring them into
> >everything or using the naming/knowledge/authentication/ACI regimes
> of
> >directory services and appyling these in the CA issuer/subject and
> CRL
> >DP objects.
> >
> >	The directory service provides exactly that - named items in  a
> >distributed environment. So why try to emulate that service in data
> >structures with manual effort.
> 
> I'm confused by this example. If I attack the directory and change the
> CRL
> pointer to a different entry, this would be a serious security
> problem,
> unless the CRL in the other entry is signed by the CA.  If so, then
> what
> difference does it make in which entry it is stored?  Is your
> suggestion
> that the layer of indirection provided by the directory is important,
> even
> if the CRL is signed by the same entity in any case?
	One can cite if one attacks a directory entry but I would expect
that a CA entry with its cert and CRL DP, etc is well protected from
casual writes - protected via authentication mechanisms and access
controls for CA modification only. The same issue would be with an
unprotected DB .


	At least the directory provides a distributed, profileable -
authentication and ACI regime which will be designed and deployed
according to a cost/trust and service model.

> >
> >> One could include a set of OCSP
> >> server pointers, which would permit a more robust mechanism, though
> at
> >> the
> >> cost of cert size growth.
> >>
> >> For a directory system to provide a highly secure way to discover
> such
> >> delegation, I think we must have some way for a CA to post a
> signed,
> >> dated,
> >> attestation that provides the equivalent info.  We currently have
> no
> >> structure for such data.  Also, there is a potential performance
> >> tradeoff
> >> here as well, i.e., use of a directory server seems to add another
> >> level of
> >> indirection to the process, thus requiring more network accesses,
> ...
> >	[Alan Lloyd]  Dont think of the directory as a server, but as a
> >distributed service. If things are all over the place then by
> definition
> >the network traffic through a directory service will be the similar
> or
> >less than the client making the same requests to independent items.
> Its
> >just that with the directory service, the directory service has the
> >distribution mechanisms and knowledge all built in. And in this case
> all
> >the client does is access the single interface of the directory
> service
> >with requests for named items. Whereas with the client identifying
> with
> >bits of config info from many data structures (eg. like the WEB mode
> of
> >working), just means that all such structures are hand configured and
> >the client has many connections to retrieve all these fragments. And
> in
> >addition, each time the client connects to these fragmented servers,
> it
> >has to authenticate itself. Yet more hand crafted configuration,
> >replicated passwords and/or and key management.
> >	Ie. The latter model is more complex, key management starts to
> >get N*N, its harder to manage and has more network traffic and
> >interaction from the clients perspective.
> 
> We certainly disagree here.  Nothing in the example I described
> changes the
> key management to an order N**2 problem, from an order N problem. We
> certainly are NOT introducing passwords into these systems; we are
> trying
> to replace them with certificates.  I still don't see how the number
> of
> transactions does not grow as a result of putting more data into the
> directory.  Your comment is rather vague on this point; perhaps the
> intent
> is to say that "if we distribute all of the admin data need to
> communicate,
> then  what's a few more items?"  I understand that analysis, and might
> agree with it in general.  But, if we pursue that path, we will
> definately
> create a more fragile system, by requiring a greater number of
> directory
> accesses and requiring that the directory services be highly
> available.  I
> think your point is that this is a good tradeoff if it results in an
> easier
> to manage system, overall.  Here too I think we need to look at
> specific
> cases; sometimes the tradeoff may be appropriate, but in other cases
> we may
> be creating unacceptably fragile systems.  Maybe my work on the Trust
> in
> Cyberspace report for the NRC over the last 2 years has heightened my
> concerns over fragile infrastructures :-).
> 
	However, with a robust - distributed directory service - that is
designed to be robust - some of those concerns should dissipate. After
all the phone system is a very big infrastructure that in general
supports a service and one tends to think that any failure in any
component does not bring the whole system down. Infrastructure design
always makes sure that their is no single point of failure for the whole
service and that any failure only criples a componenet of area of the
service.
	All I am saying that directory system designs should parallel
the phone system re replicated/distributed paths and redundancy
features. Thus a "trust" can be placed on them - like any infrastructure
- water, gas, roads, etc. Otherwise what is the alternative to the
design of large scale systems?

> >
> >	As a bit of an after thought and thinking about OCSP-directory
> >integration. In a multi domain environment where domain a users send
> a
> >signed transaction to users in domain b. And domain A uses
> convetional
> >CA/CRL processes for its own validation , but domain B choses to use
> >OSCP validation processes, the certificate server configuration
> approach
> >will have problems. The point is that a user or a CA in one domain
> may
> >not know or care (at that level) the validation techniques of another
> >domain as this will be a system design and policy issue.
> >	It would be very hard for a CA issuer in any domain to foresee
> >where the cert would be propageted to and what servers (and the
> server
> >configs and mechanisms) it would be validated on. Naturally very
> small
> >systems dont have this issue.
> 
> Validation for certificates is a standard process, codified in X.509
> and
> PKIX. It is not a purely local policy matter.  Local policy comes into
> play
> with regard to how to make use of the data extracted from the
> certificate.
> Also, some aspects of the validation process are under the control of
> the
> CA issuing the certificate being validated, e.g., marking extensions
> with a
> critical bit or choosing to use CRLs vs. OCSP.
> 
	Thats the CA theory view that may not serve an operational
world. The transaction with a cert has a business/policy component also
and that must be tied to the cost/trust/business models that apply
certificates. ie. the theoretical CA model need not rule in all cases.
> >	I still quite like that the approach that a receiving client of
> >a cert, presents it to its "local" validation process (via OCSP) and
> >that server, can off load that to other OCSP validation servers if it
> is
> >necessary -  and these OCSP servers use the distributed information
> >services of the directory to find CRLs or validation items or
> references
> >to where CRLs might live. ie the business policy for within domains
> and
> >between domains is engineered as directory information objects
> (signed
> >or otherwise) according to trust requirements.
> 
> Here is where we disagree again, though I appreciate the attraction
> this
> holds. As I noted some time ago, if one offloads all of the validation
> process, in order to construct a very thin client, then the
> opportunities
> for subverting validation for a potentially large number of
> subscribers is
> greatly increased. The local validation server becomes a prime tagret
> for a
> wide range fo attacks, and its required high availability makes denial
> of
> service an even greater concern.  
> 
	As said, when one designs a distributed directory service
infrastructure with directory enabled processes attached to the service
for such things like org chart generation, subject matter context
clumping  and possibly cert validation and... specialised seach/data
engines for fingerprint validation, etc , then these processes by nature
are context sensitive (or insesnitive) - mult path, distributed
processes . ie with directory enabled distributed processing, the whole
system, service and processing paradigms change - including the
configuration and single point of failure models.


	The telephone network is very similar to the PKI validation
model that is needed for global services. Multi domains, multi services,
global roaming and distributed-fast authentication. As directories make
the phone system work, so will directories make big PKIs work.


	regards alan


	 With cacheing and normal, client
> validation capabilities, an inability to access a directory for a CRL
> may
> be an annoyance, but may not be fatal in many instances.  However, if
> one
> pushes off all of the processing, ...
> 
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA19171 for ietf-pkix-bks; Fri, 22 Jan 1999 12:34:47 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19167 for <[e-mail]>; Fri, 22 Jan 1999 12:34:46 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA01716; Fri, 22 Jan 1999 15:35:51 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates to Informational
Date: Fri, 22 Jan 1999 15:35:51 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'Internet X.509 Public Key
Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in
Internet X.509 Public Key Infrastructure Certificates'
<draft-ietf-pkix-ipki-kea-02.txt> as a Informational.  This document is
the product of the Public-Key Infrastructure (X.509) Working Group.

The IESG contact persons are Jeffrey Schiller and Marcus Leech.

 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18911 for ietf-pkix-bks; Fri, 22 Jan 1999 12:05:39 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA18906 for <[e-mail]>; Fri, 22 Jan 1999 12:05:37 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 22 Jan 1999 13:06:33 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 22 Jan 1999 13:06:26 -0700
From: "Tammy Carter" <[e-mail]>
To: <[e-mail]>
Subject: Attribute used to store cached certificate chains?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA18907
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Consider the following scenario:
-----------------------------------------------
A user, Alice, is a user of a directory service and the
PKI that she uses exists entirely within her own tree.  
Due to the nature of the directory, she is often unable
to compose her certificate chain (a chain back to a root
which she knows and trusts and which other people within
her tree know and trust) on the fly by walking her tree.  
Sometimes, Alice needs to construct her certificate 
chain in order to validate one of her own certificates.  Other times,
she needs to send the certificate chain to another user, Bob, 
who may also not be able to walk the tree, but who needs to
validate her certificate.

If Alice wanted to cache her certificate chain in the directory on
her user object for use when she was disconnected, what attribute
should she store it in?  Has such an attribute been defined yet?


Thanks,

Tammy Green Carter
[e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18910 for ietf-pkix-bks; Fri, 22 Jan 1999 12:05:39 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18902 for <[e-mail]>; Fri, 22 Jan 1999 12:05:37 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA00503; Fri, 22 Jan 1999 15:06:41 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework to Informational
Date: Fri, 22 Jan 1999 15:06:41 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'Internet X.509 Public Key
Infrastructure Certificate Policy and Certification Practices
Framework' <draft-ietf-pkix-ipki-part4-03.txt> as an Informational
RFC. This document is the product of the Public-Key Infrastructure (X.509)
Working Group.

The IESG contact persons are Jeffrey Schiller and Marcus Leech.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA17807 for ietf-pkix-bks; Fri, 22 Jan 1999 09:53:09 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17800 for <[e-mail]>; Fri, 22 Jan 1999 09:53:07 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA24645; Fri, 22 Jan 1999 12:54:12 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure Certificate Management Protocols to Proposed Standard
Date: Fri, 22 Jan 1999 12:54:12 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following Internet-Drafts as Proposed
Standards:

 o Internet X.509 Public Key Infrastructure Certificate Management
   Protocols
	<draft-ietf-pkix-ipki3cmp-09.txt>

 o Internet X.509 Certificate Request Message Format
	<draft-ietf-pkix-crmf-01.txt> 

These documents are the product of the Public-Key Infrastructure
(X.509) Working Group.  The IESG contact persons are: Jeffrey Schiller
and Marcus Leech.
 
 
Technical Summary
 
These documents define a protocol for managing the creation and
dissemination of X.509 Version 3 Certificates.

Working Group Summary

The Working Group came to consensus on these documents.

Protocol Quality

The PKIX Working Group has performed fairly rigorous evaluation of the
protocol described in these documents. The IESG reviewed was conducted
by Jeffrey I. Schiller.

Note to RFC Editor: 

Please remove the paragraph below from page 10:

> 7.  INTELLECTUAL PROPERTY STATEMENT
>
> The authors have no knowledge of any pending or granted patents covering
> the techniques described.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA03333 for ietf-pkix-bks; Thu, 21 Jan 1999 11:34:12 -0800 (PST)
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 LAA03329 for <[e-mail]>; Thu, 21 Jan 1999 11:34:09 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <DMYA1MQ3>; Thu, 21 Jan 1999 14:31:56 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E2AD3FF@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "PKIX (E-mail)" <[e-mail]>
Subject:  Key Recovery in the CMP (RESEND WITH LINE FEEDS)
Date: Thu, 21 Jan 1999 14:31:54 -0500
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I had several comments related to the treatment of key recovery in the
CMP document. I realize that these comments would have applied to the
last version of CMP - however, I did not get a chance to send these out
in time.

Since there appears to be little or no explanation on how a key recovery
request operation is typically performed, I was forced to make my own
assumptions, and base my comments upon those assumptions. The primary
point I would like to make is that the handling of key recovery in the
current CMP document is much too terse, and, depending upon the
assumptions and envisioned scenarios, the message syntax may be
incomplete or even flawed. I personally think that the key recovery
portion of CMP needs to be reworked and expanded. 

My specific comments follow: 

I) In section 3.3.7, under key recovery request message: 

Comment 1: The CMP document says, "For key recovery requests the syntax
used is identical to the initialization request, CertReqMessages." I
would contend that key recovery is dissimilar enough from initial
certification request that it deserve a more targeted message syntax.
For example, the CertReqMessages syntax in CRMF has an optional
ProofOfPossession field that is in inapplicable for key recovery (how
can you prove possession of a private key that you are trying to
recover??) Conversely, the CertReqMessages syntax does not appear to
support a field that will allow the requester to pass authorization
information (such as a passphrase or authentication token) to the CA. I
would recommend that the syntax for a new message, KeyRecoveryReq, be
defined to specifically address the required fields for key recovery. I
would be happy to supply this new syntax if there is agreement on this
issue.  

Comment 2: The sentence "Typically, SubjectPublicKeyInfo and KeyId are
the template fields which may be used to supply a signature public key
for which a certificate is required" has many inconsistencies. First,
key recovery requires key identification, and not templates. Second, why
would I want to supply my signature public key for key recovery instead
of my encryption public key? Third, it says, "a certificate is required"
as the intended goal of key recovery - in actuality, a private key is
required. This sentence should be rewritten to something like: "
Typically, the SubjectPublicKeyInfo and KeyId fields are used to
identify the private key for which recovery is required."


II) In Section 3.3.8, under Key recovery response content: 

The syntax for the response message is specified in CMP as:
  >>KeyRecRepContent ::= SEQUENCE { 
  >>	status PKIStatusInfo, 
  >>	newSigCert [0] Certificate OPTIONAL, 
  >>	caCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, 
  >>	keyPairHist [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair

OPTIONAL }

Comment 1: The key recovery request message identifies the single key to
be recovered. Yet, the response message, (surprisingly) returns a new
signature certificate, and a sequence of key pairs. I understand that in
certain implementations of key recovery, the signature key is
automatically regenerated when an encryption key is recovered. However,
either there needs to be extensive explanation on this issue, or the key
recovery response syntax needs to be decoupled from the issuance of new
signature certificates. The current syntax and accompanying explanation
does not hang together.

Comment 2: CertifiedKeyPair syntax contains the (recovered) private key
as an EncryptedValue. Should this be EncryptedKey instead? Assuming that
the private key is encrypted (by the CA) with a symmetric key - how is
that symmetric key transported to the requester? We have to assume that
the requester does not have access to his encryption private key - (why
else would he request key recovery??) - therefore, normal key transfer
mechanisms cannot be used. Possibly, the symmetric encryption key that
is used to encrypt the recovered private key, could have been passed in
through the key recovery request message. However, the CertReqMessages
syntax does not seem to support the passing of a symmetric key to be
used to encrypt a private key returned by the CA. 

Best regards, 

- Sarbari Gupta 

=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA03068 for ietf-pkix-bks; Thu, 21 Jan 1999 10:56:28 -0800 (PST)
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 KAA03064 for <[e-mail]>; Thu, 21 Jan 1999 10:56:27 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <YY7T0VXG>; Thu, 21 Jan 1999 13:54:02 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E2AD3FE@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "PKIX (E-mail)" <[e-mail]>
Subject: Key Recovery in the CMP
Date: Thu, 21 Jan 1999 13:54:00 -0500
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 KAA03065
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I had several comments related to the treatment of key recovery in the
CMP document. I realize that these comments would have applied to the
last version of CMP - however, I did not get a chance to send these out
in time.
Since there appears to be little or no explanation on how a key recovery
request operation is typically performed, I was forced to make my own
assumptions, and base my comments upon those assumptions. The primary
point I would like to make is that the handling of key recovery in the
current CMP document is much too terse, and, depending upon the
assumptions and envisioned scenarios, the message syntax may be
incomplete or even flawed. I personally think that the key recovery
portion of CMP needs to be reworked and expanded. 
My specific comments follow: 
I) In section 3.3.7, under key recovery request message: 
Comment 1: The CMP document says, "For key recovery requests the syntax
used is identical to the initialization request, CertReqMessages." I
would contend that key recovery is dissimilar enough from initial
certification request that it deserve a more targeted message syntax.
For example, the CertReqMessages syntax in CRMF has an optional
ProofOfPossession field that is in inapplicable for key recovery (how
can you prove possession of a private key that you are trying to
recover??) Conversely, the CertReqMessages syntax does not appear to
support a field that will allow the requester to pass authorization
information (such as a passphrase or authentication token) to the CA. I
would recommend that the syntax for a new message, KeyRecoveryReq, be
defined to specifically address the required fields for key recovery. I
would be happy to supply this new syntax if there is agreement on this
issue.  
Comment 2: The sentence "Typically, SubjectPublicKeyInfo and KeyId are
the template fields which may be used to supply a signature public key
for which a certificate is required" has many inconsistencies. First,
key recovery requires key identification, and not templates. Second, why
would I want to supply my signature public key for key recovery instead
of my encryption public key? Third, it says, "a certificate is required"
as the intended goal of key recovery - in actuality, a private key is
required. This sentence should be rewritten to something like: "
Typically, the SubjectPublicKeyInfo and KeyId fields are used to
identify the private key for which recovery is required."
II) In Section 3.3.8, under Key recovery response content: 
The syntax for the response message is specified in CMP as:
  >>KeyRecRepContent ::= SEQUENCE { 
  >>	status PKIStatusInfo, 
  >>	newSigCert [0] Certificate OPTIONAL, 
  >>	caCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, 
  >>	keyPairHist [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair
OPTIONAL }

Comment 1: The key recovery request message identifies the single key to
be recovered. Yet, the response message, (surprisingly) returns a new
signature certificate, and a sequence of key pairs. I understand that in
certain implementations of key recovery, the signature key is
automatically regenerated when an encryption key is recovered. However,
either there needs to be extensive explanation on this issue, or the key
recovery response syntax needs to be decoupled from the issuance of new
signature certificates. The current syntax and accompanying explanation
does not hang together.

Comment 2: CertifiedKeyPair syntax contains the (recovered) private key
as an EncryptedValue. Should this be EncryptedKey instead? Assuming that
the private key is encrypted (by the CA) with a symmetric key - how is
that symmetric key transported to the requester? We have to assume that
the requester does not have access to his encryption private key - (why
else would he request key recovery??) - therefore, normal key transfer
mechanisms cannot be used. Possibly, the symmetric encryption key that
is used to encrypt the recovered private key, could have been passed in
through the key recovery request message. However, the CertReqMessages
syntax does not seem to support the passing of a symmetric key to be
used to encrypt a private key returned by the CA. 

Best regards, 

- Sarbari Gupta 

=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA01875 for ietf-pkix-bks; Thu, 21 Jan 1999 09:10:44 -0800 (PST)
Received: from rosslyn.BBN.COM (ROSSLYN.BBN.COM [192.1.7.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA01871 for <[e-mail]>; Thu, 21 Jan 1999 09:10:42 -0800 (PST)
Received: from RSHIREY.BBN.COM by rosslyn.BBN.COM id aa19531; 21 Jan 99 12:22 EST
X-Sender: [e-mail]
Message-Id: <v03110700b2cd0847498a@[192.1.7.164]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 21 Jan 1999 12:14:44 -0500
To: [e-mail]
From: "Robert W. Shirey" <[e-mail]>
Subject: Revised "rule" for use of "validate" vs. "verify" in PKI docs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To the Working Group,

In late December, I sent a message to the pkix list to encourage correction
and clean-up of use of the words "validate" and "verify" in IETF security
documents and related material. Subsequently, I have had discussions with
the co-chairs of the pkix WG, Steve Kent and Warwick Ford, and with the the
chair of the Federal PKI Technical Working Group, Bill Burr at NIST, and
others.

Bill wisely suggested it would be better to have a usage rule, rather than
just a list of usage cases. He also wanted to preserve current Federal
usage of "validate" with regard to compliance with to FIPS 140-1 and other
standards.

Warwick showed me that he actually had been following some rules, which I
had not noticed.

Steve convinced me that what I suggested in my December message had some flaws.

So, after they enlightened me as to what is "correct", I synthesized the
following, which articulates a rationale for what Steve and Warwick have
been doing intuitively. All three subsequently concurred with this writeup.

Regards, -Rob-

[e-mail], Phone [phone], Reception 284-4600, Fax [phone]
Robert W. Shirey, GTE Internetworking - Mail Stop 30/12B2, Suite 1200
1300 North Seventeenth Street, Arlington, Virginia   22209-3801   USA

P.S. How many people think it would be useful to publish, as an
Informational RFC, a large (say roughly 1,000 terms) security glossary,
sort of in the style of Gary Malkin's networking glossary (RFC 1983)?
Please send replies directly to me and don't bother the list with this.


validate vs. verify
-------------------

The PKI community uses words inconsistently when describing what a
certificate user does to make certain that a digital certificate can be
trusted. Usually, we say "validate the certificate" but say "verify the
signature." Too often, however, verify and validate are used
interchangeably. Here, we recommend a rule, illustrated with some specific
applications, to make usage consistent and also align it with both
generally accepted PKI community practice and the dictionary.

*Rule*: Use "validate" when referring to a process intended to establish
the soundness or correctness of a construct, like a public key certificate
or a certification path. Use "verify" when referring to a process intended
to test or prove the truth or accuracy of a fact or value.

In other words, we verify atomic truths, but we validate data structures,
relationships, and systems that are composed of or depend on verified
items. The rationale for this distinction is as follows:

* Valid derives from a Latin word that means "strong". Validate means "to
establish the soundness of; corroborate" or "to mark with an indication of
official sanction" [American Heritage Dictionary of the English Language,
3rd edition]. Thus, a certificate user validates a public key certificate
to establish trust in the binding that the certificate asserts between an
identity and a key, and NIST validates cryptographic modules for
conformance with FIPS PUB 140-1.

* Verify derives from a Latin word that means "true". Verify means "to
determine or test the truth or accuracy of, as by comparison,
investigation, or reference" or "to prove the truth of by presentation of
evidence or testimony; substantiate" [AHDEL3]. Thus, to validate a
certificate, a certificate user must verify the digital signature on the
certificate, by performing calculations that test it; must verify that the
current time is within the certificate's validity period; and also may need
to validate a certification path involving additional certificates. In an
authentication process, we verify an identity by presenting or generating
identification information.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01098 for ietf-pkix-bks; Thu, 21 Jan 1999 08:04:23 -0800 (PST)
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 IAA01094 for <[e-mail]>; Thu, 21 Jan 1999 08:04:22 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA08415; Thu, 21 Jan 1999 08:02:46 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA05515; Thu, 21 Jan 1999 08:05:52 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <DJMYNHST>; Thu, 21 Jan 1999 08:05:54 -0800
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: IETF-PXIX <[e-mail]>
Subject: RE: OCSP & Authority Information Access
Date: Thu, 21 Jan 1999 08:05:53 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

This response took a bit longer to get to.

> -----Original Message-----
> > You can operate your CA without using the noted extension and
> > still comply with the spec.
> 
> I would like that !
> 
> The text however says:
> 
> "CAs SHALL provide the capability to include the 
> AuthorityInfoAccess extension
> (defined in [PKIX1], section 4.2.2.1) in certificates that 
> can be checked using
> OCSP."
> 
> I have thus difficulties to interpret that sentence and 
> understand what the
> SHALL means.

It means the capability shall be there, but its use in any particular
circumstance is a matter of choice.  I would have preferred the simplicity
of a single way of doing things, but legacy effect considerations alone
warranted the wording of the requirement.

Mike



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA28887 for ietf-pkix-bks; Thu, 21 Jan 1999 05:14:02 -0800 (PST)
Received: from mx.arx.com (mx.arx.com [212.25.66.96]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA28882 for <[e-mail]>; Thu, 21 Jan 1999 05:13:59 -0800 (PST)
Received: by mx.arx.com with Internet Mail Service (5.5.2232.9) id <DKB3C0R0>; Thu, 21 Jan 1999 15:15:12 +0200
Message-ID: <[e-mail]>
From: Ilan Shacham <[e-mail]>
To: "Ietf-Pkix (E-mail)" <[e-mail]>
Subject: Diffie-Hellman key exchange key in pkix-ipki-part1
Date: Thu, 21 Jan 1999 15:15:04 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In pkix-ipki-part1 Diffie-Hellman key exchange algorithmIdentifier params
are defined as:

7.3.2  Diffie-Hellman Key Exchange Key

   The Diffie-Hellman OID supported by this profile is defined by ANSI
   X9.42 [X9.42].

        dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                  us(840) ansi-x942(10046) number-type(2) 1 }

   The dhpublicnumber OID is intended to be used in the algorithm field
   of a value of type AlgorithmIdentifier. The parameters field of that
   type, which has the algorithm-specific syntax ANY DEFINED BY algo-
   rithm, have the ASN.1 type GroupParameters for this algorithm.

        DomainParameters ::= SEQUENCE {
              p       INTEGER, -- odd prime, p=jq +1
              g       INTEGER, -- generator, g
              q       INTEGER, -- factor of p-1
              j       INTEGER OPTIONAL, -- subgroup factor
              validationParms  ValidationParms OPTIONAL }

        ValidationParms ::= SEQUENCE {
              seed             BIT STRING,
              pgenCounter      INTEGER }

It looks to me like there is a typo here - GroupParameters written instead
of DomainParameters. Is this true or am I missing something?

apart from that, does anyone have a reference implementation with a DH
public key?

Ilan

------------------------------------------------------------------------
Ilan Shacham				mailto:[e-mail]
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA01779 for ietf-pkix-bks; Wed, 20 Jan 1999 15:20:45 -0800 (PST)
Received: from typhoon.dstc.qut.edu.au ([e-mail] [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA01769 for <[e-mail]>; Wed, 20 Jan 1999 15:20:42 -0800 (PST)
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 JAA26661; Thu, 21 Jan 1999 09:22:28 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: Re: Verifying certificate chains with different policies 
In-reply-to: Your message of "Tue, 19 Jan 1999 14:28:30 EST." <v04011707b2ca8c3f9d29@[128.33.238.98]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 21 Jan 1999 09:22:26 +1000
From: Dean Povey <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Dean,
>
>I think that one should keep the notion of accrediation of CAs (relative to
>some criteria) very separate from PKI topology for validation of
>certificate paths.  CAs can express the policies that they follow via
>appropriate extensions, and the accrediation authorities can then attest to
>the fact that the CAs in question do follow these policies.  The
>attestation can take many forms, including attribute certificates, online
>queries, etc.
>

I agree completely.  However I was trying to point out that the system we are 
proposing requires you to enforce different policies and enforce an ordering 
of those policies in a certificate path.  What I was indicating is that it is 
not possible to enforce ordering of policies using the given X.509 framework.  
This would seem to be a useful goal irrespective of whether there is an 
underlying accreditation framework.  X.509 uses the idea that a certificate 
path should contain certificates that are issued under the same (or deemed 
equivalent) policies.  However, I think there are many cases where this is not
appropriate (particularly as the length of the path increases).

BTW: The most pragmatic way of doing this I have seen so far is to specify 
all the policies in the initial policy set and rely on individual CAs in the 
path to enforce the ordering.  I still think that it would be nice if the 
path validation process could prove this assertion for you (but then I guess
there are a lot of things that it would be nice to have).

Cheers.

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24666 for ietf-pkix-bks; Wed, 20 Jan 1999 07:42:14 -0800 (PST)
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 HAA24662 for <[e-mail]>; Wed, 20 Jan 1999 07:42:13 -0800 (PST)
Received: from [128.33.238.35] (TC035.BBN.COM [128.33.238.35]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id KAA17611; Wed, 20 Jan 1999 10:43:58 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011707b2ca8c3f9d29@[128.33.238.98]>
In-Reply-To: <[e-mail]>
Date: Tue, 19 Jan 1999 14:28:30 -0500
To: Dean Povey <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Verifying certificate chains with different policies
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dean,

I think that one should keep the notion of accrediation of CAs (relative to
some criteria) very separate from PKI topology for validation of
certificate paths.  CAs can express the policies that they follow via
appropriate extensions, and the accrediation authorities can then attest to
the fact that the CAs in question do follow these policies.  The
attestation can take many forms, including attribute certificates, online
queries, etc.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23733 for ietf-pkix-bks; Wed, 20 Jan 1999 05:32:29 -0800 (PST)
Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA23729 for <[e-mail]>; Wed, 20 Jan 1999 05:32:28 -0800 (PST)
Received: from NS95LAP005.nscc.com by smtp0-alterdial.uu.net with SMTP  (peer crosschecked as: 1Cust245.tnt10.nyc3.da.uu.net [153.37.131.245]) id QQfyze29714; Wed, 20 Jan 1999 13:34:02 GMT
From: "Dwight Arthur" <[e-mail]>
To: "Dean Povey" <[e-mail]>, <[e-mail]>
Subject: RE: Verifying certificate chains with different policies
Date: Wed, 20 Jan 1999 08:34:07 -0500
Message-ID: <000601be4479$8dc3bee0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dean, you may benefit from reading the document at
http://internetcouncil.nacha.org/CARAT/CARAT921.pdf

In the approach advocated by CARAT, your RA the Policy Authority. The Policy
that it adopts covers the obligations and responsibilities of all of the
other parties. Specific contracts may be derived from the policy for
specific types of parties but all are tied to the policy by contract.

Using this approach, instead of multiple policies you have a single policy,
but a need bind each party to one of the various roles within the policy.
Specifying roles within an X.509v3 PKI is not altogether straightforward but
it's closer to the mainstream than trying to enforce a defined hierarchy of
policies.
------------------------------------------------
p:[phone]                   Dwight Arthur
f:[phone]      Managing Director: Systems
b:[phone]    National Securities Clearing
[e-mail]              55 Water Street
http://www.nscc.com      New York, NY 10041-0082



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23580 for ietf-pkix-bks; Wed, 20 Jan 1999 05:13:49 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA23576 for <[e-mail]>; Wed, 20 Jan 1999 05:13:48 -0800 (PST)
From: [e-mail]
Received: by arista.iris.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id 852566FF.0048D31B ; Wed, 20 Jan 1999 08:15:26 -0500
X-Lotus-FromDomain: IRIS
To: [e-mail]
cc: Crispin Cowan <[e-mail]>
Message-ID: <[e-mail]>
Date: Wed, 20 Jan 1999 08:16:18 -0500
Subject: NSPW 1999 Call For Papers
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

========================================================================

                            Call For Papers
                  New Security Paradigms Workshop 1999
                      A workshop sponsored by ACM
                         22 - 24 September 1999
                     Caledon Hills, Ontario, Canada
                          http://www.nspw.org
========================================================================

For seven years, the New Security Paradigms Workshop has provided a
productive and highly interactive forum in which innovative new
approaches (and some radical older approaches) to computer security have

been offered, explored, refined, and published. The workshop offers a
constructive environment where experienced researchers and practitioners

work alongside newer participants in the field.  The result is a unique
opportunity to exchange ideas.

The 1999 New Security Paradigms Workshop will take place from September
22 - 24, 1999 at The Millcroft Inn, an hour north of Toronto, Ontario,
Canada. In order to preserve the small, intimate nature of the workshop,

participation is limited to authors of accepted papers and conference
organizers. Because these are new paradigms, we cannot predict what
subjects will be covered. Any paper that presents a significant shift
in thinking about difficult security issues will be welcomed.

The New Security Paradigms Workshop is highly interactive in nature.
Authors are encouraged to present ideas that might be considered risky
in some other forum. All participants are charged with providing
feedback
in a constructive manner. The resulting non-threatening brainstorming
environment has proven to  be an excellent medium for furthering the
development of these ideas. The proceedings, published after the fact,
have consistently benefited from the inclusion of workshop feedback.

To participate, please submit the following, preferably via e-mail, to
both Program Chairs -- Steven J. Greenwald ([e-mail]) and Cristina
Serban ([e-mail]) -- by Friday, April 2, 1999 (hardcopy
submissions must be received by Friday, March 26, 1999).

1 - Your Paper
You should submit either a research paper, a 5 - 10 page position
paper, or a discussion topic proposal. Softcopy submissions should be
in Postscript or ASCII format. Papers may be submitted in hardcopy.
To submit hardcopy, please mail 5 (five) copies to Program co-chair
Cristina Serban. Please allow adequate time for delivery.

Discussion topic proposals should include an in-depth description of the

topic to be discussed, a convincing argument that the topic will lead to

a lively discussion, and any other supporting materials.

2 - Justification
You should describe, in one page or less, why your paper is appropriate
for the New Security Paradigms Workshop. A good justification will
describe the new paradigm being proposed, explain how it is a departure
from existing practice, and identify those aspects of the status quo
it challenges or rejects.

3 - Attendance Statement
You should state how many authors wish to attend the workshop. Accepted
papers require the attendance of at least one author. In order to ensure

that all papers receive equally strong feedback, all attendees are
expected to stay for the entire duration of the workshop.

The program committee will referee the papers and notify the authors of
acceptance status by June 11, 1999. We expect to be able to offer a
limited number of scholarships. More information will be provided on our

web site as it becomes available.

Workshop Co-Chairs

Darrell Kienzle                      Mary Ellen Zurko
The MITRE Corporation                Iris Associates
Mail Stop W423                       230 Nashua Rd.
1820 Dolley Madison Blvd.            Groton, MA 01450 USA
McLean, VA 22102 USA                 e-mail: [e-mail]
e-mail: [e-mail]            voice: [phone]
voice: [phone]                fax: [phone]
fax: [phone]

Program Committee Co-Chairs

Steven J. Greenwald                  Cristina Serban
2521 NE 135th Street                 AT&T Labs
North Miami, FL 33181 USA            307 Middletown-Lincroft Rd.
e-mail: [e-mail]                Lincroft, NJ 07738 USA
voice: [phone]                e-mail:   [e-mail]
fax: [phone]                  voice: [phone]
                                     fax: [phone]

Program Committee

Donald Beaver, Transarc Corp.
Bob Blakley, IBM
LiWu Chang, Naval Research Laboratory
Simon Foley, University College, Cork, Ireland
Erland Jonsson, Chalmers University
Clifford Kahn, EMC Corporation
M J Lin, The University of Texas at Austin
Keith Marzullo, University of California, San Diego
Catherine Meadows, Naval Research Laboratory
Ira S. Moskowitz, Naval Research Laboratory
Alfarez Abdul Rahman, University College London
Thomas Riechmann, University of Erlangen
O. Sami Saydjari, DARPA
Marvin Schaefer, ARCA Systems
Anil Somayaji, University of New Mexico
Brenda Timmerman, California State University, Northridge
Chenxi Wang, University of Virginia
John Michael Williams

Local Arrangements
Heather Hinton (Ryerson Polytechnic University) [phone] x6686

Scholarships
Hilary Hosmer (Data Security Inc.) [phone]
Brenda Timmerman (California State University) [phone]

Publications
Marv Schaefer (ARCA Systems) [phone]

Publicity
Crispin Cowan (Oregon Graduate Institute) [phone]

Treasurer/Registration
Daniel Essin (University of Southern California) [phone]

ACM-SIGSAC Chair
Ravi Sandhu (George Mason University) [phone]

Steering Committee
Dixie Baker, Bob Blakley, Steven J. Greenwald, Hilary Hosmer,
Darrell Kienzle, Catherine Meadows, Cristina Serban, Mary Ellen Zurko




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA19312 for ietf-pkix-bks; Tue, 19 Jan 1999 08:38:49 -0800 (PST)
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 IAA19308 for <[e-mail]>; Tue, 19 Jan 1999 08:38:47 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id RAA22448; Tue, 19 Jan 1999 17:40:40 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id RAA15456; Tue, 19 Jan 1999 17:43:13 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Tue, 19 Jan 1999 17:40:58 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: Re: OCSP & Authority Information Access
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

Thanks for your very fast response.

> Denis,
>
> That text has been there since the first draft.  Last Call has come and gone
> and OCSP is now up at the IESG.  So it's a bit late to go changing things
> right now.  But, for what it's worth, just because CAs (and, by inference,
> cert servers) are required to "provide the capability" doesn't mean they're
> required to use it (or that the capability in the cert server is required to
> be used).

You said:


> You can operate your CA without using the noted extension and
> still comply with the spec.

I would like that !

The text however says:

"CAs SHALL provide the capability to include the AuthorityInfoAccess extension
(defined in [PKIX1], section 4.2.2.1) in certificates that can be checked using
OCSP."

I have thus difficulties to interpret that sentence and understand what the
SHALL means.


> Also, the extension is intended to point upward in a chain to an issuing CA,
> not downward to certs.  That too has been the case since the earliest drafts
> of Part 1.
>
> Lastly, I would not advise anyone to configuring such a pointer into root
> certs since it bakes in a system configuration that they might want to
> change at some later date.
>

Self signed certificates my change over time. If this is not included in a leaf
certificate, I do not see another (secure) means to give the pointer.

Regards,

Denis


> Mike



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA19081 for ietf-pkix-bks; Tue, 19 Jan 1999 08:14:03 -0800 (PST)
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 IAA19077 for <[e-mail]>; Tue, 19 Jan 1999 08:14:02 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA19116; Tue, 19 Jan 1999 08:12:17 -0800 (PST)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA01912; Tue, 19 Jan 1999 08:15:23 -0800 (PST)
Received: by newman.verisign.com with Internet Mail Service (5.5.2232.9) id <YVH3NZ7S>; Tue, 19 Jan 1999 08:15:24 -0800
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, IETF-PXIX <[e-mail]>
Subject: RE: OCSP & Authority Information Access
Date: Tue, 19 Jan 1999 08:15:22 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

That text has been there since the first draft.  Last Call has come and gone
and OCSP is now up at the IESG.  So it's a bit late to go changing things
right now.  But, for what it's worth, just because CAs (and, by inference,
cert servers) are required to "provide the capability" doesn't mean they're
required to use it (or that the capability in the cert server is required to
be used).  You can operate your CA without using the noted extension and
still comply with the spec.

Also, the extension is intended to point upward in a chain to an issuing CA,
not downward to certs.  That too has been the case since the earliest drafts
of Part 1.

Lastly, I would not advise anyone to configuring such a pointer into root
certs since it bakes in a system configuration that they might want to
change at some later date.

Mike



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA17216 for ietf-pkix-bks; Tue, 19 Jan 1999 03:33:51 -0800 (PST)
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 DAA17212 for <[e-mail]>; Tue, 19 Jan 1999 03:33:48 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id MAA18840 for <[e-mail]>; Tue, 19 Jan 1999 12:35:42 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id MAA21270 for <[e-mail]>; Tue, 19 Jan 1999 12:38:14 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Tue, 19 Jan 1999 12:35:59 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: DCS or DVS ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

These comments are relative to the document: Internet X.509 Public Key
Infrastructure. Data Certification Server Protocols
During the last IETF meeting I have been requested to re-post these comments.
Here it is.

The various facets of the DCS functionality need to be looked at very
carefully before looking at the protocols.

The abstract says:

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

This addresses two items:

a) validation of signatures,
b) up-to-date information regarding the status of public key certificates.

Let us address the validation of signatures first.

When a signer signs something this is in accordance with a security policy.
That policy may specify one OR MORE trusted points but also the allowed
certification paths that can be used. That policy may be implicit for a given
application/context or may be extracted from the data itself, e.g. when you
receive a signed contract that contains the policy.

The policy does not specify only the trusted points. It may also specify other
conditions, like which TSAs (Time Stamping Authorities) need to be involved,
the grace time period for a user to ask for the revocation of its certificate
in case of a private key compromise, ...

The implication is that nominating one or more trusted points is not enough in
the general case and only a security policy is able to encompass all the
checks that need to be made.

Degenerated cases may consider only one or more trusted point, but saying that
the signature is *valid* is insufficient unless we say against what (see later
the various cases that may be considered).

Considering a "certification path validity checking" would thus be more
appropriate. This would leave room for more complete tests.

An intermediate conclusion is thus to consider in addition to the validity of
a signature, the validity of a certification path. What means performing a
checking against trusted points ? This includes the certification path that
may be used. One way (but not the single one) to define them, is to use
self-signed certificates that include naming constraints. The key point is to
remember that it is not because a certificate exists that it should be used.

When trust points are used instead of security policies, it would be needed to
refer to ONE OR MORE self-signed certificates. In order to make sure that the
path used for the verification is correct, it should be given back to the
requester so that it can check that it is OK.

Let us then address the second item: up-to-date information regarding the
status of public key certificates.

The *status* of public key certificates is already being addressed by OCSP, so
we should not duplicate the work here. It is NOT addressed for an old status,
but it is not evident that it should (see arguments later on, why it should
not).

It would be better to consider "up-to-date information regarding the
*validity* of public key certificates".

So both items would be about validity/validation. A better name would be a
Data Validation Server (DVS) instead of DCS where the word "Certification"
(from Data Certification server) may be confusing with the function of a CA.
As an example of this kind of problem the actual text speaks about: "When
certifying a public key certificate, the DCS verifies ..." A CA (Certification
Authority) does such a certification, not a DCS.

In the introduction (section 1) three functions are introduced:

1) validity and correctness of an entity's claim to possess data,
2) validity and revocation status of an entity's public key certificate,
3) validity and correctness of another entity's signature.

For the item 1, the TSA (Time Stamping Authority) already allows to prove that
the requester possessed the data in the request at the time indicated by the
DVS.

Is it thus needed in addition to consider the case where a single entity (the
DVS) both proves that the requester possessed the data in the request and a
valid signature key at the time indicated by the DVS ?

It would be better to keep the two functionality independent. The TSA
signature is always for later use, while the DVS signature is not (see
additional arguments later on). If needed, the same entity can support both
protocols. Since the last case (3) is about any entity's signature, it would
be easier to consider only that case and use the TSA, in addition, when
needed.

In the item 2, if validity is checked, by implication the revocation status is
also checked.

Note: It is not clear to understand what "correctness" means in addition to
validity in the items 1) and 3).

The various facets to consider for a DVS would then be along the following
(and the document should be restructured along thse lines) :

1) validity of an entity's public key certificate.
2) validity of a certification path.
3) validity of an entity's signature.

The validity may be checked against:

a) a security policy.
b) one or more self-signed certificates.
c) one or more certification paths.
d) one or more trusted points (provided that the path being used is returned).

The next question is what kind of information should be given to the DVS ?

There is not a single answer to this question, but it would be better to
restrict some of the possibilities when verifications "in the past" occur.

When something is signed, it seems natural that the verifier makes sure that,
at the first time it makes the verification, it gets everything back that he
will need later on to prove that the signature was valid (according to a non
repudiation policy).

If he (or someone else) wants to make the verification later on, it seems then
natural that he provides what he got at that time. This has two important
implications:

1) This means that the DVS does not have to fetch, e.g. back 3 years old CRLs
or ARLs.

2) This also means that the DVS *should return all what is needed for later
proof*. That stuff may then be used by any DVS to make the verification,
without the need for anyone to trust the first DVS for its good faith. This
would be a nice way to support the non repudiation APIs described in IDUP
(Independent Data Unit Protection, now RFC 2479 and authored by Carlisle)
where such a functionality exists.

CRLS and ARLs may then be part of the data that is given or returned to the
DVS. Time Stamp tokens may also be part of it.

All the functions listed above can be used in the context where the DVS is a
server trusted only by its requester (a short term signature from the DVS is
being used) and not necessarily by other users.

Regards,

Denis








Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA17123 for ietf-pkix-bks; Tue, 19 Jan 1999 03:17:02 -0800 (PST)
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 DAA17119 for <[e-mail]>; Tue, 19 Jan 1999 03:17:00 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id MAA11046 for <[e-mail]>; Tue, 19 Jan 1999 12:18:44 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id MAA28440 for <[e-mail]>; Tue, 19 Jan 1999 12:21:17 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Tue, 19 Jan 1999 12:19:02 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: OCSP & Authority Information Access
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have a major problem with OCSP related to the AuthorityInfoAccess extension
which is said to be mandatory in OSCP. OCSP-07 contains the following text:

4.1  Certificate Content

   In order to convey to OCSP clients a well-known point of information
   access, CAs SHALL provide the capability to include the
   AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1)
   in certificates that can be checked using OCSP.  Alternatively, the
   accessLocation for the OCSP provider may be configured locally at the
   OCSP client.

PKIX1, section 4.2.2.1 contains the following:

4.2.2.1  Authority Information Access

   The authority information access extension indicates how to access CA
   information and services for the issuer of the certificate in which
   the extension appears. Information and services may include on-line
   validation services and CA policy data.  (The location of CRLs is not
   specified in this extension; that information is provided by the
   cRLDistributionPoints extension.)  This extension may be included in
   subject or CA certificates, and it is always non-critical.

We should limit the size of the certificates to a minimum, in particular when
they are stored in a smart card. It is therefore not acceptable to mandate the
inclusion of that information in every subject certificate.

On the contrary it can make sense to include it in a self-signed certificate
from a CA.

To this respect, I propose to amend the text in the following way:

4.1  Certificate Content

In order to convey to OCSP clients a well-known point of information
access, CAs SHALL provide the capability to include the
AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1)
in their self-signed certificates (CA certificate) so that it can be
known that some or all the subjects certificates from that CA can be
checked using OCSP. Alternatively, the accessLocation for the OCSP
provider may be configured locally at the OCSP client.

Regards,

Denis







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA02386 for ietf-pkix-bks; Mon, 18 Jan 1999 17:30:50 -0800 (PST)
Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA02380 for <[e-mail]>; Mon, 18 Jan 1999 17:30:37 -0800 (PST)
From: [e-mail]
Received: from f03n07e.au.ibm.com (f03n07s.au.ibm.com [9.185.166.74]) by ausmtp02.au.ibm.com (1.0.0) with ESMTP id MAA74042; Tue, 19 Jan 1999 12:26:20 +1100
Received: from cn.ibm.com (f06n06s [9.185.166.68]) by f03n07e.au.ibm.com (8.8.7/8.8.7) with SMTP id MAA60986; Tue, 19 Jan 1999 12:31:53 +1100
Received: by cn.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 482566FE.00086784 ; Tue, 19 Jan 1999 09:31:47 +0800
X-Lotus-FromDomain: IBMCN
To: Dean Povey <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 19 Jan 1999 09:32:12 +0800
Subject: Re: Verifying certificate chains with different policies
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, Dean:

     I haven't considered your problem in detail. But I think it would be
helpful to refer to SET certificate chain.
     In the SET certificate chain, RA is Root CA, ICA is Brand CA, OCA may
include Cardholder CA, Merchant CA and PaymentGateway CA, then the
Cardholder, Merchant and PaymentGateway would be the EEs.

Thanks,
ZHU Qing Jiu
Staff Research Member,
e-business Technologies & Solutions,IBM China Research Lab




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA27539 for ietf-pkix-bks; Mon, 18 Jan 1999 08:02:35 -0800 (PST)
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 IAA27535 for <[e-mail]>; Mon, 18 Jan 1999 08:02:23 -0800 (PST)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id RAA17552; Mon, 18 Jan 1999 17:04:03 +0100
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id RAA18016; Mon, 18 Jan 1999 17:06:35 +0100 (NFT)
Message-ID: <[e-mail]>
Date: Mon, 18 Jan 1999 17:04:20 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Dean Povey <[e-mail]>
CC: [e-mail]
Subject: Re: Verifying certificate chains with different policies
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dean,

Let me add an important point to the problem you raised:

> However when processing Certificate paths, you simply input a list of
> acceptable policies and each certificate in the path must support one
> of those policies (or an equivalent policy).

Another parameter has to be taken into consideration: the naming constraints
as well. They may be even more important than the policies.

Regards,

Denis


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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA22189 for ietf-pkix-bks; Sun, 17 Jan 1999 22:49:01 -0800 (PST)
Received: from typhoon.dstc.qut.edu.au ([e-mail] [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA22182 for <[e-mail]>; Sun, 17 Jan 1999 22:48:58 -0800 (PST)
Received: from tornado.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 QAA15879 for <[e-mail]>; Mon, 18 Jan 1999 16:50:41 +1000 (EST)
Received: (from povey@localhost) by tornado.dstc.qut.edu.au (8.8.5/8.8.4) id QAA19176; Mon, 18 Jan 1999 16:50:38 +1000 (EST)
Date: Mon, 18 Jan 1999 16:50:38 +1000 (EST)
Message-Id: <[e-mail]>
From: Dean Povey <[e-mail]>
To: [e-mail]
Subject: Verifying certificate chains with different policies
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,

I am involved in the Standards Australia Working group IT/12/4/1 which
is looking at the deployment of a Public Key authentication framework
in Australia.  We are currently having a problem with how to handle
"policy chains" using the X.509 and PKIX certificate path processing
techniques, so I thought I might throw this question at PKIX'ers to
see if someone can come up with an appropriate solution.

(NB: the term "certify" is somewhat confusing when mixing X.509 and
ISO9000 jargon.  In X.509 it usually means to assure the binding
between a private/public key and one or more attributes (usually an
identity).  In the ISO9000 sense it means to audit ones compliance
with stated procedures and practices.  In the discussion below the
X.509 sense is meant unless otherwise indicated).


Our problem is this: one of the architechtures that we wish to support
is a hierarchy of CAs within an accreditation framework (similar to
ISO9000).  The way this would work would be to have a root authority
(RA) which acts as an accreditation body.  The RA then accredits
intermediate CAs (or ICAs), who in turn certify (in both the X.509 and
the ISO9000 sense) organisational CAs (OCAs).  Part of the role of the
ICA then in addition to POP and verifying the OCAs identity, is to
audit the OCA against the policy and practices they claim to
implement.  An OCA can then issue certificates to end entities or to
other OCAs depending on what policy they support.

Now the problem is this, there are several different policies at work
here: (In the notation below X -> Y means the certificate where X
certifies Y.)

RA -> RA : Policy indicating that the RA is an accreditation body

RA -> ICA : Policy indicating that the ICA can act as a certifying (in
	    the ISO9000 sense) body.  This policy may or may not
            specify the types of OCA that the ICA can specify.

ICA -> OCA : Policy indicating how the OCA will issue certificates.
             This also indicates that the ICA has been certified (in
             the ISO9000 sense) the OCA as implementing this policy or
             its CPS correctly

OCA -> EE : Policy indicating how the EE was identified.


Each of these policies has different semantics and so should be
interpreted differently.  While the ICA->OCA and the OCA->EE might be
able to be issued under the same policy if that policy differentiates
between certs issued to CAs and certs issued to End entities.  The
RA->RA and RA->ICA certififcates are obviously very different from the
ICA->OCA policy.  This is because the ICA should be able to issue
certificates to OCAs under any policy it wants whereas the RA->RA and
RA->ICA certs will be a specific policy saying that the ICA has been
accredited to act as a certifying (in the ISO9000 sense) body.

However when processing Certificate paths, you simply input a list of
acceptable policies and each certificate in the path must support one
of those policies (or an equivalent policy).

The problem I guess, is that here we want to enforce a particular
ordering of policies (or a "policy chain").  We want our certificate
paths to start with an accreditation body, which is followed by an
ICA, a certified (in the ISO9000 sense) OCA and then an EE.  There
seems to be no way to do this and enforce those semantics using the
existing path processing and policy extensions.

Is the problem clear?  Does anyone have a suggestion for how we might
work around this problem?

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


     



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA07166 for ietf-pkix-bks; Sun, 17 Jan 1999 17:08:20 -0800 (PST)
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 RAA07162 for <[e-mail]>; Sun, 17 Jan 1999 17:08:18 -0800 (PST)
Received: from [128.33.238.65] (TC065.BBN.COM [128.33.238.65]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id UAA19537; Sun, 17 Jan 1999 20:09:40 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04011703b2c80bad0ee4@[128.89.0.111]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC09435E@DSG1>
Date: Sun, 17 Jan 1999 17:10:32 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

Well, we may be getting closer, but I'm not completely sure.

>> I think we have to pay close attention to the specific services in
>> deciding
>> what constitutes a good way to find appropriate servers.  For
>> revocation, I
>> think the CA has an obligation to state how/where is makes revocation
>> data
>> available, because the CA is the ultimate authority for this data.
>> Thus,
>> for example, we can bind into each cert one or more CRL distribution
>> pointers. If a CA chooses to delegate that authority to some 3rd
>> party, it
>> needs to do so in a highly secure fashion.
>	[Alan Lloyd]
>	The X.500 CA related data structures do provide some of this.
>The  CA entry can have  its CRL DP  reference pointing to a directory
>entry of a third party that has the CRL DP with signed CRLs in. My usual
>point here is that it is easier to add a new data structures to a
>directory service to solve the prolem than hand config info objects with
>server knowledge all over the place.
>	I think the issue is that its back to the approach of hand
>crafted knowledge of where things are and configuring them into
>everything or using the naming/knowledge/authentication/ACI regimes of
>directory services and appyling these in the CA issuer/subject and CRL
>DP objects.
>
>	The directory service provides exactly that - named items in  a
>distributed environment. So why try to emulate that service in data
>structures with manual effort.

I'm confused by this example. If I attack the directory and change the CRL
pointer to a different entry, this would be a serious security problem,
unless the CRL in the other entry is signed by the CA.  If so, then what
difference does it make in which entry it is stored?  Is your suggestion
that the layer of indirection provided by the directory is important, even
if the CRL is signed by the same entity in any case?

>
>> One could include a set of OCSP
>> server pointers, which would permit a more robust mechanism, though at
>> the
>> cost of cert size growth.
>>
>> For a directory system to provide a highly secure way to discover such
>> delegation, I think we must have some way for a CA to post a signed,
>> dated,
>> attestation that provides the equivalent info.  We currently have no
>> structure for such data.  Also, there is a potential performance
>> tradeoff
>> here as well, i.e., use of a directory server seems to add another
>> level of
>> indirection to the process, thus requiring more network accesses, ...
>	[Alan Lloyd]  Dont think of the directory as a server, but as a
>distributed service. If things are all over the place then by definition
>the network traffic through a directory service will be the similar or
>less than the client making the same requests to independent items. Its
>just that with the directory service, the directory service has the
>distribution mechanisms and knowledge all built in. And in this case all
>the client does is access the single interface of the directory service
>with requests for named items. Whereas with the client identifying with
>bits of config info from many data structures (eg. like the WEB mode of
>working), just means that all such structures are hand configured and
>the client has many connections to retrieve all these fragments. And in
>addition, each time the client connects to these fragmented servers, it
>has to authenticate itself. Yet more hand crafted configuration,
>replicated passwords and/or and key management.
>	Ie. The latter model is more complex, key management starts to
>get N*N, its harder to manage and has more network traffic and
>interaction from the clients perspective.

We certainly disagree here.  Nothing in the example I described changes the
key management to an order N**2 problem, from an order N problem. We
certainly are NOT introducing passwords into these systems; we are trying
to replace them with certificates.  I still don't see how the number of
transactions does not grow as a result of putting more data into the
directory.  Your comment is rather vague on this point; perhaps the intent
is to say that "if we distribute all of the admin data need to communicate,
then  what's a few more items?"  I understand that analysis, and might
agree with it in general.  But, if we pursue that path, we will definately
create a more fragile system, by requiring a greater number of directory
accesses and requiring that the directory services be highly available.  I
think your point is that this is a good tradeoff if it results in an easier
to manage system, overall.  Here too I think we need to look at specific
cases; sometimes the tradeoff may be appropriate, but in other cases we may
be creating unacceptably fragile systems.  Maybe my work on the Trust in
Cyberspace report for the NRC over the last 2 years has heightened my
concerns over fragile infrastructures :-).


>
>	As a bit of an after thought and thinking about OCSP-directory
>integration. In a multi domain environment where domain a users send a
>signed transaction to users in domain b. And domain A uses convetional
>CA/CRL processes for its own validation , but domain B choses to use
>OSCP validation processes, the certificate server configuration approach
>will have problems. The point is that a user or a CA in one domain may
>not know or care (at that level) the validation techniques of another
>domain as this will be a system design and policy issue.
>	It would be very hard for a CA issuer in any domain to foresee
>where the cert would be propageted to and what servers (and the server
>configs and mechanisms) it would be validated on. Naturally very small
>systems dont have this issue.

Validation for certificates is a standard process, codified in X.509 and
PKIX. It is not a purely local policy matter.  Local policy comes into play
with regard to how to make use of the data extracted from the certificate.
Also, some aspects of the validation process are under the control of the
CA issuing the certificate being validated, e.g., marking extensions with a
critical bit or choosing to use CRLs vs. OCSP.

>	I still quite like that the approach that a receiving client of
>a cert, presents it to its "local" validation process (via OCSP) and
>that server, can off load that to other OCSP validation servers if it is
>necessary -  and these OCSP servers use the distributed information
>services of the directory to find CRLs or validation items or references
>to where CRLs might live. ie the business policy for within domains and
>between domains is engineered as directory information objects (signed
>or otherwise) according to trust requirements.

Here is where we disagree again, though I appreciate the attraction this
holds. As I noted some time ago, if one offloads all of the validation
process, in order to construct a very thin client, then the opportunities
for subverting validation for a potentially large number of subscribers is
greatly increased. The local validation server becomes a prime tagret for a
wide range fo attacks, and its required high availability makes denial of
service an even greater concern.  With cacheing and normal, client
validation capabilities, an inability to access a directory for a CRL may
be an annoyance, but may not be fatal in many instances.  However, if one
pushes off all of the processing, ...

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA07838 for ietf-pkix-bks; Sat, 16 Jan 1999 11:43:47 -0800 (PST)
Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA07834 for <[e-mail]>; Sat, 16 Jan 1999 11:43:39 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-39-2.s2.tnt10.ann.erols.com [207.172.39.2]) by smtp1.erols.com (8.8.8/8.8.5) with SMTP id OAA10234; Sat, 16 Jan 1999 14:44:56 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sat, 16 Jan 1999 12:39:55 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Reason codes vs Reason flags
Cc: Carlisle Adams <[e-mail]>, ietf-pkix <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mez:

The CRL, as defined in X.509 and profiled in Part 1, does not permit multiple
reasons.

   id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }

   -- reasonCode ::= { CRLReason }

   CRLReason ::= ENUMERATED {
        unspecified             (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6),
        removeFromCRL           (8) }

Russ


At 10:52 AM 1/14/99 -0500, [e-mail] wrote:
>Carlisle,
>Can you offer an alternative from John's list (or yet another
>one) about what to do about the mismatch then? As a refresher,
>he said:
>
>What should a CA do if it receives a CMP revocation request with more than one
>reason bit set?  Should it somehow prioritize the reasons, and put only the
>"most important reason" into the CRL?  Should it put multiple revocation 
>entries
>in the CRL, one for each requested reason?  Should it reject the request as
>mal-formed?  Should CMP use CRLReason instead of ReasonFlags?
>
>     Mez
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA07832 for ietf-pkix-bks; Sat, 16 Jan 1999 11:43:20 -0800 (PST)
Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA07828 for <[e-mail]>; Sat, 16 Jan 1999 11:43:19 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-39-2.s2.tnt10.ann.erols.com [207.172.39.2]) by smtp1.erols.com (8.8.8/8.8.5) with SMTP id OAA10209; Sat, 16 Jan 1999 14:44:50 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sat, 16 Jan 1999 12:37:21 -0500
To: Al Arsenault <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Reason codes vs Reason flags
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <4.1.19990114075121.00a90740@209.172.119.123>
References: <006e01be3f6c$95d16ae0$477c60cf@cwallace>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al Arsenault wrote:
>Side note:  here's an interesting point.  I was just checking PKIX-1 again
>for a couple of things, and looked at the definitions of ReasonFlags and
>CRLReason.  The difference (other than the obvious one of BIT STRING vs.
>ENUMERATED) is that ReasonFlags does not define the "removeFromCRL   (8)"
>option that's in CRLReason.  Thus, if you have a cert on hold and you want
>to take it off hold - i.e., remove it from the CRL - you can't use a
>ReasonFlags object to do it, anyway.
>
>Dave, Russ, Tim, and Warwick - is that intentional, or an editorial
>oversight in PKIX-1?  If it was intentional, what was the reason?

First, the structures are exactly those defind in X.509.

Second, the removeFromCRL value of ReasonFlags only appears on delta-CRLs.
In a full CRL, removal from hold is accomplished by removing the entry from
the CRL.  No trace of the previous hold status remains on the CRL.
Therefore, I do not see a case where a CRLDistributionPoint would have a
need to include this reason.

Russ




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23754 for ietf-pkix-bks; Fri, 15 Jan 1999 08:44:17 -0800 (PST)
Received: (from phoffman@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23717; Fri, 15 Jan 1999 08:43:58 -0800 (PST)
Date: Fri, 15 Jan 1999 08:43:58 -0800 (PST)
Message-Id: <[e-mail]>
From: List Manager of ietf-pkix <[e-mail]>
To: [e-mail]
Subject: How to be removed from this list
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings again. Occasionally, people will sign up for a mailing list and
forget how to be removed. This message is a reminder for those folks.

First off, when you subscribe to a mailing list, you almost always get a
first message from the list owner telling you about the mailing list, and
explaining how to unsubscribe. It is always a good idea to keep those
messages, since you never know when you will need to unsubscribe. This is
particularly useful when you change email addresses, because it is difficult
to unsubscribe from a list after you have a different mailing address.

In the case of this list, the method to unsubscribe is to send a message
to:
     [e-mail]
with the single word:
     unsubscribe
in the body of the message. This is the same as it always has been.

To make this easier for you, I have crafted this message so that you should
be able to simply reply to this message, and the reply address should be
[e-mail] (although some mail clients screw this up...).
Remove everything from the body of the reply, and put in the single word:
     unsubscribe

If you have tried this method, and the mailing list software won't let you
unsubscribe, it is probably because your address has changed. In that case,
please send a message to [e-mail] stating which list (or lists) you
want to unsubscribe from, and what you think your previous address was.
There is a human (that's me!) who will then try to take care of your
request, often within a few days.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA24871 for ietf-pkix-bks; Thu, 14 Jan 1999 14:10:53 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA24867 for <[e-mail]>; Thu, 14 Jan 1999 14:10:47 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <C7TKYT6F>; Fri, 15 Jan 1999 09:09:30 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC09435E@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: [e-mail]
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Date: Fri, 15 Jan 1999 09:09:30 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen, just a few comments - but it seems we are almost agreeing :-)

> -----Original Message-----
> From:	Stephen Kent [SMTP:[e-mail]]
> Sent:	Friday, 15 January 1999 2:52
> To:	Alan Lloyd
> Cc:	[e-mail]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Alan & John,
> 
> >Thanks for that John. My comments on OCSP also mentioned the use of
> this
> >extension in that in a domain agile and global wanderer envrionment -
> >and to deal with errors or failures in OCSP servers - it would be
> better
> >if the certificate did not cryptographically tie its validation
> server
> >to the users details. ie. if a "named" OCSP server failed the cert
> >cannot be validated however, if a fault tollerant and replicated
> >directory backbone service - that supported many OCSP validation
> >processes failed, then an alternative validation process can be dealt
> >with in the system. Its a question that OCSP seems to want to fix the
> >OCSP server details in the cert, whereas a directory enabled OCSP
> >approach with-distributed and replicated OCSP server funtions offers
> >better utility and scaleability without the need to crypto-bind
> config
> >info into certs.
> 
> I think we have to pay close attention to the specific services in
> deciding
> what constitutes a good way to find appropriate servers.  For
> revocation, I
> think the CA has an obligation to state how/where is makes revocation
> data
> available, because the CA is the ultimate authority for this data.
> Thus,
> for example, we can bind into each cert one or more CRL distribution
> pointers. If a CA chooses to delegate that authority to some 3rd
> party, it
> needs to do so in a highly secure fashion. 
	[Alan Lloyd]  
	The X.500 CA related data structures do provide some of this.
The  CA entry can have  its CRL DP  reference pointing to a directory
entry of a third party that has the CRL DP with signed CRLs in. My usual
point here is that it is easier to add a new data structures to a
directory service to solve the prolem than hand config info objects with
server knowledge all over the place.
	I think the issue is that its back to the approach of hand
crafted knowledge of where things are and configuring them into
everything or using the naming/knowledge/authentication/ACI regimes of
directory services and appyling these in the CA issuer/subject and CRL
DP objects.

	The directory service provides exactly that - named items in  a
distributed environment. So why try to emulate that service in data
structures with manual effort.

	 
> One could include a set of OCSP
> server pointers, which would permit a more robust mechanism, though at
> the
> cost of cert size growth.
> 
> For a directory system to provide a highly secure way to discover such
> delegation, I think we must have some way for a CA to post a signed,
> dated,
> attestation that provides the equivalent info.  We currently have no
> structure for such data.  Also, there is a potential performance
> tradeoff
> here as well, i.e., use of a directory server seems to add another
> level of
> indirection to the process, thus requiring more network accesses, ...
	[Alan Lloyd]  Dont think of the directory as a server, but as a
distributed service. If things are all over the place then by definition
the network traffic through a directory service will be the similar or
less than the client making the same requests to independent items. Its
just that with the directory service, the directory service has the
distribution mechanisms and knowledge all built in. And in this case all
the client does is access the single interface of the directory service
with requests for named items. Whereas with the client identifying with
bits of config info from many data structures (eg. like the WEB mode of
working), just means that all such structures are hand configured and
the client has many connections to retrieve all these fragments. And in
addition, each time the client connects to these fragmented servers, it
has to authenticate itself. Yet more hand crafted configuration,
replicated passwords and/or and key management.
	Ie. The latter model is more complex, key management starts to
get N*N, its harder to manage and has more network traffic and
interaction from the clients perspective.

>  In contrast, use of a timestamping service doesn't seem to be so
> closely
> tied to a specific cert and so it is not clear that a pointer needs to
> be
> included in a cert for such services.
	[Alan Lloyd]  agree

	As a bit of an after thought and thinking about OCSP-directory
integration. In a multi domain environment where domain a users send a
signed transaction to users in domain b. And domain A uses convetional
CA/CRL processes for its own validation , but domain B choses to use
OSCP validation processes, the certificate server configuration approach
will have problems. The point is that a user or a CA in one domain may
not know or care (at that level) the validation techniques of another
domain as this will be a system design and policy issue.
	It would be very hard for a CA issuer in any domain to foresee
where the cert would be propageted to and what servers (and the server
configs and mechanisms) it would be validated on. Naturally very small
systems dont have this issue.

	I still quite like that the approach that a receiving client of
a cert, presents it to its "local" validation process (via OCSP) and
that server, can off load that to other OCSP validation servers if it is
necessary -  and these OCSP servers use the distributed information
services of the directory to find CRLs or validation items or references
to where CRLs might live. ie the business policy for within domains and
between domains is engineered as directory information objects (signed
or otherwise) according to trust requirements.

	thoughts are welcome

	regards alan 
	  

> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA22030 for ietf-pkix-bks; Thu, 14 Jan 1999 09:27:40 -0800 (PST)
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 JAA22025 for <[e-mail]>; Thu, 14 Jan 1999 09:27:39 -0800 (PST)
Received: from [128.33.238.119] (TC036.BBN.COM [128.33.238.36]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA00773; Thu, 14 Jan 1999 12:28:51 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04011712b2c3c0a85176@[128.33.238.119]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC094336@DSG1>
Date: Thu, 14 Jan 1999 10:51:50 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan & John,

>Thanks for that John. My comments on OCSP also mentioned the use of this
>extension in that in a domain agile and global wanderer envrionment -
>and to deal with errors or failures in OCSP servers - it would be better
>if the certificate did not cryptographically tie its validation server
>to the users details. ie. if a "named" OCSP server failed the cert
>cannot be validated however, if a fault tollerant and replicated
>directory backbone service - that supported many OCSP validation
>processes failed, then an alternative validation process can be dealt
>with in the system. Its a question that OCSP seems to want to fix the
>OCSP server details in the cert, whereas a directory enabled OCSP
>approach with-distributed and replicated OCSP server funtions offers
>better utility and scaleability without the need to crypto-bind config
>info into certs.

I think we have to pay close attention to the specific services in deciding
what constitutes a good way to find appropriate servers.  For revocation, I
think the CA has an obligation to state how/where is makes revocation data
available, because the CA is the ultimate authority for this data.  Thus,
for example, we can bind into each cert one or more CRL distribution
pointers. If a CA chooses to delegate that authority to some 3rd party, it
needs to do so in a highly secure fashion. One could include a set of OCSP
server pointers, which would permit a more robust mechanism, though at the
cost of cert size growth.

For a directory system to provide a highly secure way to discover such
delegation, I think we must have some way for a CA to post a signed, dated,
attestation that provides the equivalent info.  We currently have no
structure for such data.  Also, there is a potential performance tradeoff
here as well, i.e., use of a directory server seems to add another level of
indirection to the process, thus requiring more network accesses, ...

In contrast, use of a timestamping service doesn't seem to be so closely
tied to a specific cert and so it is not clear that a pointer needs to be
included in a cert for such services.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA22026 for ietf-pkix-bks; Thu, 14 Jan 1999 09:27:39 -0800 (PST)
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 JAA22020 for <[e-mail]>; Thu, 14 Jan 1999 09:27:38 -0800 (PST)
Received: from [128.33.238.119] (TC036.BBN.COM [128.33.238.36]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA00787; Thu, 14 Jan 1999 12:28:54 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04011713b2c3c322e63f@[128.33.238.119]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC09433F@DSG1>
Date: Thu, 14 Jan 1999 11:02:47 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

>Agree with most you say and I am a realist you know. However, may I make
>the point, as below.

<deleted text>


>>
>> >IMHO  would be simpler to build a DN based directory service with
>> >logical issuer objects which support many cert based services than to
>> >hand configure references of many services in every cert.
>>
>> Unfortunately, we don't have a global directory service of the sort
>> envisioned by X.500, so finding a service based on the DN of the cert
>> issuer is not easy.
>	[Alan Lloyd]
>	This comment is common in that we (the planet) does not have a
>global directory service, therefore we wont use it.
>	In terms of engineering systems, a directory service is a
>function - and should be seen as just that ie. it is a distributed
>object oriented function - with auth and access control properties - and
>regardless of scale and operational deployment - if directory services
>are considered as a supporting information infrastructure that will be
>applied in many vertical markets and organisations for many operational,
>information management, security and service delivery reasons, then why
>not incorporate such functions into such things as PKI.

I'm not sopposed to directory services, but from a security perspective I
don't want to make PKIs too dependent on them.  For some range of
PKI-enabled applications, e.g., IPsec, we don't strictly require
directories, and to introduce a dependency would result in a less secure
system, e.g., in terms of availability, and may also degrade performance.
In other cases, e.g., S/MIME, we clearly benefit greatly from directories.

>	Its like that when OCSP or LDAP or HTTP were invented they all
>assumed and relied on the fact that TCP/IP and the Internet existed and
>was serviceable and they used that. When X.500 was designed it assumed
>underlying comms/Internet were there to support inter directory
>operations. When X.509 and CAs and the X.500 distributed authentication
>model was put together it assumed a distributed directory service with
>DSP, DAP (and LDAP) were available.

Yes, but not all of these examples are equally true.  TCP/IP does exist,
and the Internet does exist, but DSP/DAP and global X.500 directories do
not, in general.  Thus, the PKIX WG has worked to minimize this dependence,
to make use of X.509 technology more useful in the Internet.

>	By putting and crypto binding system config/directory references
>into certs and mapping subjects and issuers to the URLs of servers - all
>we are doing is operationally placing single directory entries all over
>the place in a fragmented and possibly uncordinated way - ie
>operationally if a directory service is not used. The certficate by
>definition becomes a directory entry (ie it related names to server
>addresses) and the humans that manage (the millions of these cert/dir
>information things) - become the directory infrastructure.

I think this is an overstatement of the current situation, but agree that
one could head this way.  I've have long argued against putting directory
entry data into certs (especially when it is not verified!), for the same
reason.  However, I think we have to look at each data item and asses the
security and performance implications of putting it into a cert or relying
on its availability and integrity in a directory.  For different data
ietems we should expect to come to different conclusions.

>	Not good for operational approaches re cost, reliability and
>scaling.
>	 I think directory supported OCSP servers will be the way to go.

OCSP servers may use directories, or may use private databases, depending
on scope.  For example, if I, as a CA, decide to offer OCSP service for the
certs I issue, I don't need to use a full fledged directory for that
purpose.  However, if I operate a third party OCSP service, I may want to
collect revocation data from directories, if available.  Alternatively, I
may simply have CAs e-mail me their CRLs.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA22018 for ietf-pkix-bks; Thu, 14 Jan 1999 09:27:14 -0800 (PST)
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 JAA22014 for <[e-mail]>; Thu, 14 Jan 1999 09:27:12 -0800 (PST)
Received: from [128.33.238.119] (TC036.BBN.COM [128.33.238.36]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA00711; Thu, 14 Jan 1999 12:28:36 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v0401170db2c3bc103d41@[128.33.238.119]>
In-Reply-To: <[e-mail]>
Date: Thu, 14 Jan 1999 10:29:48 -0500
To: sankar ramamoorthi <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: CRL size
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sankar,


>Actually I am looking at this problem purely from the
>thin client's (in my a case a network appliance) point
>of view.
>
>I agree that the problem of multiple CA domains and
>high revocation rate needs to be solved, but I am pushing this problem
>to an external server, which I believe is the right place to address
>these issues.
>The external server may be running some complex protocols to ensure
>the CRLs from multiple CAs are
>refreshed periodically.
>
>My company sells a network appliance which may be plugged into a
>customer environment which may
>have its own needs as for as checking the frequency of
>revocation info etc.
>
>My need is for the network appliance is to use certificates for
>authentication purposes and be able to use CRLs to ensure the
>certificates are not
>revoked, but not worry about the growing size of the
>CRL or revocation rate etc.

As a consumer of a CRL, you have no control over the size or the frequency
of issue.  These are managed by each CA, subject to a set of parameters,
some of which have already been discussed.  Are the only CRLs you will deal
with ones that "your" CA issued, or do you have to be able to process CRLs
issued by other CAs?  If the former case if the one of interest, the CA can
divide the CRL into pieces by using the CRL distribution piont facility, to
help bound the size of each CRL segment.  The CA also can help minimze CRL
growth by keeping the validity interval shorter, although that creates a
tradeoff between CRL size and frequency of reissue or renewal.

Another approacch to dealing with CRL size concerns is to use a base CRL
and incremental CRLs, but it's not clear that this helps in your case,
because your appliance would need to store the base CRL, even though it
could fetch smaller, incremental CRLs as they are issued.

If you have to accept CRLs from other CAs, you have NO control over any of
these parameters, and thus must be prepared to accept potentially very
large CRLs.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21492 for ietf-pkix-bks; Thu, 14 Jan 1999 08:33:22 -0800 (PST)
Received: from pluto.deh.de (pluto.deh.de [194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA21488 for <[e-mail]>; Thu, 14 Jan 1999 08:33:17 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id RAA25608; Thu, 14 Jan 1999 17:34:35 +0100
Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id RAA24378; Thu, 14 Jan 1999 17:34:43 +0100
Message-ID: <[e-mail]>
Date: Thu, 14 Jan 1999 17:37:07 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: Reason codes vs Reason flags
References: <4.1.19990114075121.00a90740@209.172.119.123>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al,

in PKIX-1 the usage of reasonFlags is restricted to
cRLDistributionPoints extension, so there is no need for this flag. I
would expect that I will found the delta-crl where I have found the crl
containing the certificateHold revocation, i.e. the certificateHold flag
is set.

Juergen   


[snip]

> 
> Side note:  here's an interesting point.  I was just checking PKIX-1 again
> for a couple of things, and looked at the definitions of ReasonFlags and
> CRLReason.  The difference (other than the obvious one of BIT STRING vs.
> ENUMERATED) is that ReasonFlags does not define the "removeFromCRL   (8)"
> option that's in CRLReason.  Thus, if you have a cert on hold and you want
> to take it off hold - i.e., remove it from the CRL - you can't use a
> ReasonFlags object to do it, anyway.
> 
> Dave, Russ, Tim, and Warwick - is that intentional, or an editorial
> oversight in PKIX-1?  If it was intentional, what was the reason?
> 
>                                                 Al Arsenault
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21444 for ietf-pkix-bks; Thu, 14 Jan 1999 08:27:28 -0800 (PST)
Received: from sisko.cygnacom.com ([e-mail] [205.177.169.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA21437 for <[e-mail]>; Thu, 14 Jan 1999 08:27:24 -0800 (PST)
Received: from carls_pc (endor.cygnacom.com [205.177.169.102]) by sisko.cygnacom.com (8.7.6/8.7.3) with SMTP id LAA10886 for <[e-mail]>; Thu, 14 Jan 1999 11:27:51 -0500
Message-ID: <001b01be3fdb$f97a1d70$5300a8c0@carls_pc>
From: "Carl Wallace" <[e-mail]>
To: "ietf-pkix" <[e-mail]>
Subject: Re: Reason codes vs Reason flags
Date: Thu, 14 Jan 1999 11:35:31 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Also, what should a CA do if it receives a request with information in the
revocationReason field or badSinceDate field and in the corresponding
extensions of the crlEntryDetails field?


-----Original Message-----
From: [e-mail] <[e-mail]>
To: Carlisle Adams <[e-mail]>
Cc: ietf-pkix <[e-mail]>
Date: Thursday, January 14, 1999 11:15 AM
Subject: RE: Reason codes vs Reason flags


>Carlisle,
>Can you offer an alternative from John's list (or yet another
>one) about what to do about the mismatch then? As a refresher,
>he said:
>
>What should a CA do if it receives a CMP revocation request with more than
one
>reason bit set?  Should it somehow prioritize the reasons, and put only the
>"most important reason" into the CRL?  Should it put multiple revocation
entries
>in the CRL, one for each requested reason?  Should it reject the request as
>mal-formed?  Should CMP use CRLReason instead of ReasonFlags?
>
>     Mez
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21251 for ietf-pkix-bks; Thu, 14 Jan 1999 08:10:12 -0800 (PST)
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 IAA21246 for <[e-mail]>; Thu, 14 Jan 1999 08:10:10 -0800 (PST)
Received: 	id LAA16743; Thu, 14 Jan 1999 11:08:24 -0500
Received: by gateway id <ZZJ1D6P3>; Thu, 14 Jan 1999 11:10:19 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: ietf-pkix <[e-mail]>
Subject: RE: Reason codes vs Reason flags
Date: Thu, 14 Jan 1999 11:08:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Mary Ellen,

Having multiple revocation entries in a CRL for a single certificate does
not seem sensible to me.  Furthermore, as I mentioned, I think it is too
late at this stage to get CMP to specify CRLReason instead of ReasonFlags.
Finally, given that there is nothing in the text (of any of the PKIX
documents) telling end entities *not* to set multiple reason bits, it is
hard to justify rejecting such a message as mal-formed.

To me, the most appropriate course of action is to have the CA prioritize
the reasons (according to whatever algorithm it thinks is meaningful) and
put the "most important reason" into the CRL.  This will get us through to
the next iteration of these documents, when we can perhaps specify all this
more tightly.  In practice, however, I can't imagine that this will come up
too often (i.e., I really doubt that EEs will set multiple reason bits
frequently).

Carlisle.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, January 14, 1999 10:53 AM
To: Carlisle Adams
Cc: ietf-pkix
Subject: RE: Reason codes vs Reason flags

Carlisle,
Can you offer an alternative from John's list (or yet another
one) about what to do about the mismatch then? As a refresher,
he said:

What should a CA do if it receives a CMP revocation request with more than
one
reason bit set?  Should it somehow prioritize the reasons, and put only the
"most important reason" into the CRL?  Should it put multiple revocation
entries
in the CRL, one for each requested reason?  Should it reject the request as
mal-formed?  Should CMP use CRLReason instead of ReasonFlags?

     Mez



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21103 for ietf-pkix-bks; Thu, 14 Jan 1999 07:51:11 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA21099 for <[e-mail]>; Thu, 14 Jan 1999 07:51:10 -0800 (PST)
From: [e-mail]
Received: by arista.iris.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id 852566F9.00572DC6 ; Thu, 14 Jan 1999 10:52:13 -0500
X-Lotus-FromDomain: IRIS
To: Carlisle Adams <[e-mail]>
cc: ietf-pkix <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 14 Jan 1999 10:52:57 -0500
Subject: RE: Reason codes vs Reason flags
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carlisle,
Can you offer an alternative from John's list (or yet another
one) about what to do about the mismatch then? As a refresher,
he said:

What should a CA do if it receives a CMP revocation request with more than one
reason bit set?  Should it somehow prioritize the reasons, and put only the
"most important reason" into the CRL?  Should it put multiple revocation entries
in the CRL, one for each requested reason?  Should it reject the request as
mal-formed?  Should CMP use CRLReason instead of ReasonFlags?

     Mez




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20873 for ietf-pkix-bks; Thu, 14 Jan 1999 07:31:55 -0800 (PST)
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 HAA20869 for <[e-mail]>; Thu, 14 Jan 1999 07:31:53 -0800 (PST)
Received: 	id KAA07574; Thu, 14 Jan 1999 10:29:48 -0500
Received: by gateway id <ZZJ1D616>; Thu, 14 Jan 1999 10:31:42 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Al Arsenault'" <[e-mail]>, Carl Wallace <[e-mail]>, ietf-pkix <[e-mail]>
Cc: [e-mail]
Subject: RE: Reason codes vs Reason flags
Date: Thu, 14 Jan 1999 10:29:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Al,

You're going back a long way and really taxing my memory here...  :-)

I inherited CMP (then called PKIX Part 3) very shortly after its first
appearance as a separate document (i.e., there was initially a single PKIX
document, which was quickly separated into four parts and I got involved
just after that point).  If I remember correctly, the ReasonFlags structure
was already in Part 3, pulled in from Part 1.  It never really occurred to
me to question this, or to change it to reasonCode, so it stayed (because it
seemed to work).  Apparently, it never occurred to anyone else to question
this either, until recently.

Carlisle.

P.S., I agree with your earlier comments, Al, regarding the lateness of the
hour.  CMP has already been approved by the IESG and we're just waiting for
the announcement from the RFC editor that the document is available.  If we
ever have a CMPv2, or if we ever decide to try to progress this
specification to Draft Standard, we can fix these sorts of things then.


-----Original Message-----
From: Al Arsenault [mailto:[e-mail]]
Sent: Thursday, January 14, 1999 8:03 AM
To: Carl Wallace; ietf-pkix
Cc: [e-mail]; [e-mail]
Subject: Re: Reason codes vs Reason flags

At 10:18 PM 1/13/99 -0500, Carl Wallace wrote:
>Why not use the reasonCode extension in the crlEntryDetails field and
>eliminate the revocationReason field all together?  Same goes for the
>invalidityDate extension and badSinceDate field.
>

I think that makes three of us so far that agree with that approach.  

Carlisle & Stephen,

	Any comments as to why you chose the ReasonFlags structure in
section
3.3.9 of CMP, vice CRLReason?


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA19778 for ietf-pkix-bks; Thu, 14 Jan 1999 05:06:53 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA19774 for <[e-mail]>; Thu, 14 Jan 1999 05:06:51 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id IAA20760; Thu, 14 Jan 1999 08:08:18 -0500
Message-Id: <4.1.19990114075121.00a90740@209.172.119.123>
X-Sender: aarsenault#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 14 Jan 1999 08:03:12 -0500
To: "Carl Wallace" <[e-mail]>, "ietf-pkix" <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: Re: Reason codes vs Reason flags
Cc: [e-mail], [e-mail]
In-Reply-To: <006e01be3f6c$95d16ae0$477c60cf@cwallace>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:18 PM 1/13/99 -0500, Carl Wallace wrote:
>Why not use the reasonCode extension in the crlEntryDetails field and
>eliminate the revocationReason field all together?  Same goes for the
>invalidityDate extension and badSinceDate field.
>


I think that makes three of us so far that agree with that approach.  

Carlisle & Stephen,

	Any comments as to why you chose the ReasonFlags structure in section
3.3.9 of CMP, vice CRLReason?


Side note:  here's an interesting point.  I was just checking PKIX-1 again
for a couple of things, and looked at the definitions of ReasonFlags and
CRLReason.  The difference (other than the obvious one of BIT STRING vs.
ENUMERATED) is that ReasonFlags does not define the "removeFromCRL   (8)"
option that's in CRLReason.  Thus, if you have a cert on hold and you want
to take it off hold - i.e., remove it from the CRL - you can't use a
ReasonFlags object to do it, anyway.

Dave, Russ, Tim, and Warwick - is that intentional, or an editorial
oversight in PKIX-1?  If it was intentional, what was the reason?

						Al Arsenault

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA19960 for ietf-pkix-bks; Wed, 13 Jan 1999 19:35:13 -0800 (PST)
Received: from grand.valicert.com (grand.valicert.com [209.185.6.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA19952 for <[e-mail]>; Wed, 13 Jan 1999 19:35:12 -0800 (PST)
Received: (qmail 19855 invoked from network); 14 Jan 1999 03:34:22 -0000
Received: from amazon.valicert.com (HELO atlantic.valicert.com) (209.185.6.2) by external-mail.valicert.com with SMTP; 14 Jan 1999 03:34:22 -0000
Received: (qmail 28672 invoked from network); 14 Jan 1999 03:34:32 -0000
Received: from merced.valicert.com (HELO merced) (10.0.0.132) by internal-mail.valicert.com with SMTP; 14 Jan 1999 03:34:32 -0000
From: "Venky Nakhate" <[e-mail]>
To: "sankar ramamoorthi" <[e-mail]>, <[e-mail]>
Subject: RE: CRL size
Date: Wed, 13 Jan 1999 19:37:49 -0800
Message-ID: <000001be3f6f$41e7c2a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Sankar,

Please check out http://www.valicert.com. we have a ocsp/crt toolkit which
I think  could meet your needs for doing revocation checking via our
ocsp/crt
servers .

If you need more information let me know. we also have a global VA
service which does CRL aggregation. I think this is what you are looking
for.

Thanks,

Venky
>
>
> Actually I am looking at this problem purely from the
> thin client's (in my a case a network appliance) point
> of view.
>
> I agree that the problem of multiple CA domains and
> high revocation rate needs to be solved, but I am pushing this problem
> to an external server, which I believe is the right place to address
> these issues.
> The external server may be running some complex protocols to ensure
> the CRLs from multiple CAs are
> refreshed periodically.
>
> My company sells a network appliance which may be plugged into a
> customer environment which may
> have its own needs as for as checking the frequency of
> revocation info etc.
>
> My need is for the network appliance is to use certificates for
> authentication purposes and be able to use CRLs to ensure the
> certificates are not
> revoked, but not worry about the growing size of the
> CRL or revocation rate etc.
>
> -- sankar --
>
> ---Alan Lloyd <[e-mail]> wrote:
> >
> > Sankar - there are many system and operational assumptions based or
> your
> > request/requirements.
> > ie if the system has a small number of locally contained users, the CA
> > DB and the CRLs can live in a single DB and then its just over to
> > estimating the reasons and frequency of revocation and putting in the
> > CRL fragment algorithm processing in the client and the CA that
> matches
> > your needs.
> >
> > If your system needs to scale and deal with multi CA domains with high
> > revocation rates across many DBs or interconnected directory systems,
> > the similar estimation must be taken in line with the total CA/CRL
> > directory information model and validation processes. And standards
> > should be applied.
> >
> > I don think you can just guess this situation unless the system and
> the
> > trusted transactions betwen the users and CAs in the system is
> > proprietary and self contained.
> > Otherwise it is a User/Revocation rate assessment and how the
> resultant
> > CRLs are managed, placed and tested.
> >
> > Some firm system details may help.
> >
> > Hope this helps.
> >
> > regards alan
> >
> > > -----Original Message-----
> > > From:	sankar ramamoorthi [SMTP:[e-mail]]
> > > Sent:	Thursday, 14 January 1999 8:17
> > > To:	[e-mail]
> > > Subject:	CRL size
> > >
> > > Question on CRL size.
> > >
> > >
> > > I have a thin client which needs to verify a certificate validity.
> The
> > > plan is for the thin client
> > > to communicate with a backend database server to get
> > > the CRL associated with the cert. serial number. The
> > > database is used only as a repository for CRLs.
> > > The thin client only trusts the CA, so it can not
> > > ask the backend to verify the certificate and hence
> > > needs to get the associated CRL unit. There is also
> > > no plan to implment OCSP in the thin client.
> > >
> > > The question is - what can I assume about the size
> > > of the CRL unit? What is the minimum size of CRL unit
> > > that is signed by the CA? I need to know the size to ensure it
> > > ismanagable by the thin client and yet
> > > can be fully trusted by it.
> > >
> > > Ideally I would like the CRLs to be distributed in
> > > managable quantas and each quanta is a signed by the
> > > CA. The backend database acts as repository for these
> > > signed CRL quantas, and the thin client is able to
> > > validate the cert by querying for the associated
> > > CRL quanta.
> > >
> > > Thanks for any input,
> > >
> > > -- sankar --
> > >
> > >
> > > PS: I admit I have not fully gone through all the
> > > PKIX drafts. I had briefly scanned through them, but was getting
> lost.
> > >
> > >
> > >
> > >
> > >
> > >
> > > _________________________________________________________
> > > DO YOU YAHOO!?
> > > Get your free @yahoo.com address at http://mail.yahoo.com
> >
>
> _________________________________________________________
> DO YOU YAHOO!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA16344 for ietf-pkix-bks; Wed, 13 Jan 1999 19:17:14 -0800 (PST)
Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA16336 for <[e-mail]>; Wed, 13 Jan 1999 19:17:13 -0800 (PST)
Received: from cwallace (jazzhive.erols.com [207.96.124.71]) by smtp3.erols.com (8.8.8/8.8.5) with SMTP id WAA07424 for <[e-mail]>; Wed, 13 Jan 1999 22:18:27 -0500 (EST)
Message-ID: <006e01be3f6c$95d16ae0$477c60cf@cwallace>
From: "Carl Wallace" <[e-mail]>
To: "ietf-pkix" <[e-mail]>
Subject: Re: Reason codes vs Reason flags
Date: Wed, 13 Jan 1999 22:18:32 -0500
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.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Why not use the reasonCode extension in the crlEntryDetails field and
eliminate the revocationReason field all together?  Same goes for the
invalidityDate extension and badSinceDate field.


-----Original Message-----
From: Juergen Walter <[e-mail]>
To: Al Arsenault <[e-mail]>; [e-mail]
<[e-mail]>; ietf-pkix <[e-mail]>; Carlisle Adams
<[e-mail]>; farrell <[e-mail]>
Date: Wednesday, January 13, 1999 1:16 PM
Subject: Re: Reason codes vs Reason flags


>Al, John
>
>Al Arsenault wrote:
>>
>> Juergen,
>>
>>         Whoa!  While I appreciate your approach, I think it makes things
way
>> more complicated than they need to be.
>
>I apologize. This was the result of doing mathematics during lunch time
>and thinking about reason codes vs reason flags afterwards. :-)
>
>>Why, for example, should my software
>> have to deal with a single reasonFlags and multiple certTemplates, when
I'll
>> just have to go in and parse each certificate to see what reason it was
revoked
>> for, anyway?
>
>Firstly, a huge number of certTemplates with identically revocation
>reasons, secondly ... (see below)
>
>> It doesn't seem to be any benefit to me to know that "of the
>> following six certificates, one or more was revoked for keyCompromise,
one or
>> more for affiliationChanged, one or more for superseded, and one or more
for
>> certificateHold".  I'm going to have to look at each individual
certificate to
>> see why it specifically should be revoked, so the extra reasonFlags
doesn't buy
>> me anything.
>
>This is exactly the situation with respect to the current CMP draft. To
>each certTemplate one may find two sources of revocation reasons. Taking
>this into consideration I suggested that reason codes should be chosen.
>
>>
>>         The only time when I can see something like that being useful is
if you
>> consider one particular reason to be 'worse" than the others.  For
example, in
>> some situations, keyCompromise may be more "important" than all the other
>> reasons (that's clearly not always true, but it may well be in some
>> circumstances).  Thus, you could look at the initial reasonFlags to see
if you
>> had any keyCompromises, and if so, expedite processing of this revocation
>> request.  Other than that, I don't see a win, and I do see more
complicated
>> code.
>
>..., secondly ... exactly as you described.
>
>I see. Indeed, the only advantage may be a situation whereby CA´s
>operator is bombarded with long revocation request sent by many RAs at
>the same time. A reason flags in front of the sequence of revocation
>details may help the operator to select the priority, provided that
>there is a ranking in the considered environment.
>
>
>>
>>         I looked at this differently.  When John posed his question about
>> whether any certificate should be revoked for multiple reasons, I looked
at the
>> reason codes listed in PKIX-1.  They are:
>>
>>         CRLReason ::= ENUMERATED {
>>                 unspecified (0),
>>                 keyCompromise (1),
>>                 cACompromise (2),
>>                 affiliationChanged (3),
>>                 superseded (4),
>>                 cessationOfOperation (5),
>>                 certificateHold (6),
>>                 removeFromCRL (8) }
>>
>> Now, it doesn't make sense to me to revoke a certificate for a reason of
>> "unspecified" AND for another, specified reason at the same time.
Besides,
>> PKIX-1 discourages the use of "unspecified", anyway, so I think we can
>> eliminate any combinations including "unspecified".
>>
>> Next, keyCompromise.  I suppose it is possible to revoke a certificate
because
>> its private key and the private key of its issuer were simultaneously
>> compromised, but only if the CRL-issuer is using a different key.
Otherwise,
>> in an event where the key was compromised at the same time the user's
>> affiliation changed or the certificate was superseded (by one with a new
key, I
>> would hope :-), I would suggest that the requester just pick one -
whichever is
>> more important in her environment.
>>
>> Similarly, looking at other possible pairs, very few of them make sense.
For
>> example, I can't see where you would simultaneously want to revoke a
>> certificate because it was superseded AND because of cessation of
operations.
>
>I agree. Otherwise, one may add other reasons when people ask for it.
>
>>
>> Because of this, I'd prefer that CMP use CRLReason vice reasonFlags so
that the
>> sender can only specify one reason, but I'm willing to keep things the
way they
>> are so as not to delay CMP any further.
>
>So, CA´s operators software has to be aware of both the reason flags and
>the reason codes. For clarity, I would prefer that CMP did not use
>reason flags assigned to each certTemplate. Dropping of reason flags
>would be fine, because if there are any ambiguities between these two
>reason data, you will need a ranking of revocation reasons.
>Alternatively, the unkown code may be approriate to this case.
>
>>
>> So, from the standpoint of making everything interoperate, and making the
>> software simpler to develop,
>
>I completely agree with this standpoint.
>
>> I propose the following:
>> - Senders of CMP revocation requests SHOULD only include one reason for
each
>> certificate in the request.  (I'd personally prefer MUST, but I'm willing
to
>> accept that there might be some rare cases when two or more things pop up
at
>> once, and you want to let the recipient know all of the reasons.)
Senders
>> SHOULD choose the reason that is most important in their system, if there
is a
>> way of ranking them in importance.  If not, senders SHOULD pick any one.
>>
>> - Recipients of CMP revocation requests MUST accept messages with
multiple
>> reasonFlags selected.  If the request is accepted, the revoked
certificate MUST
>> only be placed on the CRL once, for one reason.  If one reason is deemed
to be
>> more important than others in the revoker's environment, the revoker
SHOULD
>> choose that reason; otherwise, the revoker can choose any reason for
>> revocation.
>
>I would prefer that PKIX uses only one revocation reasons encoding
>throughout all drafts, i.e. the usage of reason codes. This gives
>consistancy. The reason codes may be enlarged if required. In order to
>implement this, combinations of elementary reasons could be enumerated.
>Therefore, I propose that reason flags should be dropped. (I do not know
>the history of CMP. So, I do not know whether the reason flags are
>prehistoric vehicles or not. There is at least a second place where
>reason flags is specified. You can find them in the CRL profile in
>PKIX-1.)
>
>Furthermore, one may think about reason flags in front of "long vehicle"
>revocation requests. Firstly, this may help the CA´s operator to set a
>priority of revocation request, when the revocation waiting queue is
>overcrowded. Secondly, one may save bits in the case of multiple
>certTemplates assigned to identical revocation reasons. This can be left
>to further work. If this change will not lead to those advantages that I
>have seen at a first glance, then it should not be done.
>
>>
>> Any changes based on this can be made later; for now, this can be left as
>> "yeah, we implementers understand that this should happen this way."
 Hey -
>> maybe it can even go in another version of the Roadmap. :-)
>>
>> Comments?
>>
>>                                 Al Arsenault
>>
>> -- these are my opinions only. They do not necessarily reflect the
>> opinions of my employer, or of any other organization with which I have a
>> relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA11110 for ietf-pkix-bks; Wed, 13 Jan 1999 18:35:39 -0800 (PST)
Received: from send106.yahoomail.com (send106.yahoomail.com [205.180.60.43]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA11105 for <[e-mail]>; Wed, 13 Jan 1999 18:35:38 -0800 (PST)
Message-ID: <[e-mail]>
Received: from [209.1.17.161] by send106.yahoomail.com; Wed, 13 Jan 1999 18:38:00 PST
Date: Wed, 13 Jan 1999 18:38:00 -0800 (PST)
From: sankar ramamoorthi <[e-mail]>
Subject: RE: CRL size
To: Alan Lloyd <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Actually I am looking at this problem purely from the
thin client's (in my a case a network appliance) point
of view.

I agree that the problem of multiple CA domains and
high revocation rate needs to be solved, but I am pushing this problem
to an external server, which I believe is the right place to address
these issues.
The external server may be running some complex protocols to ensure
the CRLs from multiple CAs are
refreshed periodically.

My company sells a network appliance which may be plugged into a
customer environment which may
have its own needs as for as checking the frequency of
revocation info etc.

My need is for the network appliance is to use certificates for
authentication purposes and be able to use CRLs to ensure the
certificates are not
revoked, but not worry about the growing size of the
CRL or revocation rate etc.

-- sankar --

---Alan Lloyd <[e-mail]> wrote:
>
> Sankar - there are many system and operational assumptions based or
your
> request/requirements. 
> ie if the system has a small number of locally contained users, the CA
> DB and the CRLs can live in a single DB and then its just over to
> estimating the reasons and frequency of revocation and putting in the
> CRL fragment algorithm processing in the client and the CA that
matches
> your needs.
> 
> If your system needs to scale and deal with multi CA domains with high
> revocation rates across many DBs or interconnected directory systems,
> the similar estimation must be taken in line with the total CA/CRL
> directory information model and validation processes. And standards
> should be applied.
> 
> I don think you can just guess this situation unless the system and
the
> trusted transactions betwen the users and CAs in the system is
> proprietary and self contained.
> Otherwise it is a User/Revocation rate assessment and how the
resultant
> CRLs are managed, placed and tested.
> 
> Some firm system details may help.
> 
> Hope this helps.
> 
> regards alan
> 
> > -----Original Message-----
> > From:	sankar ramamoorthi [SMTP:[e-mail]]
> > Sent:	Thursday, 14 January 1999 8:17
> > To:	[e-mail]
> > Subject:	CRL size
> > 
> > Question on CRL size.
> > 
> > 
> > I have a thin client which needs to verify a certificate validity.
The
> > plan is for the thin client
> > to communicate with a backend database server to get
> > the CRL associated with the cert. serial number. The
> > database is used only as a repository for CRLs.
> > The thin client only trusts the CA, so it can not
> > ask the backend to verify the certificate and hence
> > needs to get the associated CRL unit. There is also
> > no plan to implment OCSP in the thin client. 
> > 
> > The question is - what can I assume about the size
> > of the CRL unit? What is the minimum size of CRL unit
> > that is signed by the CA? I need to know the size to ensure it
> > ismanagable by the thin client and yet
> > can be fully trusted by it. 
> > 
> > Ideally I would like the CRLs to be distributed in
> > managable quantas and each quanta is a signed by the
> > CA. The backend database acts as repository for these
> > signed CRL quantas, and the thin client is able to
> > validate the cert by querying for the associated
> > CRL quanta.
> > 
> > Thanks for any input,
> > 
> > -- sankar --
> > 
> > 
> > PS: I admit I have not fully gone through all the
> > PKIX drafts. I had briefly scanned through them, but was getting
lost.
> > 
> > 
> > 
> > 
> > 
> > 
> > _________________________________________________________
> > DO YOU YAHOO!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03932 for ietf-pkix-bks; Wed, 13 Jan 1999 16:21:56 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03927 for <[e-mail]>; Wed, 13 Jan 1999 16:21:39 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <C7TKYTYP>; Thu, 14 Jan 1999 11:20:05 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC094355@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'sankar ramamoorthi'" <[e-mail]>, [e-mail]
Subject: RE: CRL size
Date: Thu, 14 Jan 1999 11:20:05 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sankar - there are many system and operational assumptions based or your
request/requirements. 
ie if the system has a small number of locally contained users, the CA
DB and the CRLs can live in a single DB and then its just over to
estimating the reasons and frequency of revocation and putting in the
CRL fragment algorithm processing in the client and the CA that matches
your needs.

If your system needs to scale and deal with multi CA domains with high
revocation rates across many DBs or interconnected directory systems,
the similar estimation must be taken in line with the total CA/CRL
directory information model and validation processes. And standards
should be applied.

I don think you can just guess this situation unless the system and the
trusted transactions betwen the users and CAs in the system is
proprietary and self contained.
Otherwise it is a User/Revocation rate assessment and how the resultant
CRLs are managed, placed and tested.

Some firm system details may help.

Hope this helps.

regards alan

> -----Original Message-----
> From:	sankar ramamoorthi [SMTP:[e-mail]]
> Sent:	Thursday, 14 January 1999 8:17
> To:	[e-mail]
> Subject:	CRL size
> 
> Question on CRL size.
> 
> 
> I have a thin client which needs to verify a certificate validity. The
> plan is for the thin client
> to communicate with a backend database server to get
> the CRL associated with the cert. serial number. The
> database is used only as a repository for CRLs.
> The thin client only trusts the CA, so it can not
> ask the backend to verify the certificate and hence
> needs to get the associated CRL unit. There is also
> no plan to implment OCSP in the thin client. 
> 
> The question is - what can I assume about the size
> of the CRL unit? What is the minimum size of CRL unit
> that is signed by the CA? I need to know the size to ensure it
> ismanagable by the thin client and yet
> can be fully trusted by it. 
> 
> Ideally I would like the CRLs to be distributed in
> managable quantas and each quanta is a signed by the
> CA. The backend database acts as repository for these
> signed CRL quantas, and the thin client is able to
> validate the cert by querying for the associated
> CRL quanta.
> 
> Thanks for any input,
> 
> -- sankar --
> 
> 
> PS: I admit I have not fully gone through all the
> PKIX drafts. I had briefly scanned through them, but was getting lost.
> 
> 
> 
> 
> 
> 
> _________________________________________________________
> DO YOU YAHOO!?
> Get your free @yahoo.com address at http://mail.yahoo.com


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA23530 for ietf-pkix-bks; Wed, 13 Jan 1999 13:20:58 -0800 (PST)
Received: from send1e.yahoomail.com (send1e.yahoomail.com [205.180.60.64]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA23526 for <[e-mail]>; Wed, 13 Jan 1999 13:20:57 -0800 (PST)
Message-ID: <[e-mail]>
Received: from [209.1.17.161] by send1e; Wed, 13 Jan 1999 13:17:22 PST
Date: Wed, 13 Jan 1999 13:17:22 -0800 (PST)
From: sankar ramamoorthi <[e-mail]>
Subject: CRL size
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Question on CRL size.


I have a thin client which needs to verify a certificate validity. The
plan is for the thin client
to communicate with a backend database server to get
the CRL associated with the cert. serial number. The
database is used only as a repository for CRLs.
The thin client only trusts the CA, so it can not
ask the backend to verify the certificate and hence
needs to get the associated CRL unit. There is also
no plan to implment OCSP in the thin client. 

The question is - what can I assume about the size
of the CRL unit? What is the minimum size of CRL unit
that is signed by the CA? I need to know the size to ensure it
ismanagable by the thin client and yet
can be fully trusted by it. 

Ideally I would like the CRLs to be distributed in
managable quantas and each quanta is a signed by the
CA. The backend database acts as repository for these
signed CRL quantas, and the thin client is able to
validate the cert by querying for the associated
CRL quanta.

Thanks for any input,

-- sankar --


PS: I admit I have not fully gone through all the
PKIX drafts. I had briefly scanned through them, but was getting lost.






_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA22674 for ietf-pkix-bks; Wed, 13 Jan 1999 11:25:20 -0800 (PST)
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 LAA22670 for <[e-mail]>; Wed, 13 Jan 1999 11:25:20 -0800 (PST)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id LAA25081; Wed, 13 Jan 1999 11:26:33 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 13 Jan 1999 11:25:47 -0800
To: [e-mail], Al Arsenault <[e-mail]>, "[e-mail]" <[e-mail]>, ietf-pkix <[e-mail]>, Carlisle Adams <[e-mail]>, farrell <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Reason codes vs Reason flags
In-Reply-To: <[e-mail]>
References: <[e-mail]> <4.1.19990113095846.00a988c0@209.172.119.123>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Apologies for the naive suggestion:

If expedited processing is a major goal, why not require that any "bundled"
(multi-cert-template) revocation request be allowed only if all elements
of the bundle have the same (primary) reason code?

This way, perhaps for some codes, the individual reason flags may either be
ignored entirely, or for other codes, inspected individually as a second step.

Then, I suppose, "unspecified" would indicate that every individual must
be looked at separately.

Just a thought.

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [e-mail]   phone: [phone]             LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA21874 for ietf-pkix-bks; Wed, 13 Jan 1999 10:03:47 -0800 (PST)
Received: from pluto.deh.de (pluto.deh.de [194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21870 for <[e-mail]>; Wed, 13 Jan 1999 10:03:43 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id TAA19901; Wed, 13 Jan 1999 19:04:03 +0100
Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id TAA19734; Wed, 13 Jan 1999 19:03:47 +0100
Message-ID: <[e-mail]>
Date: Wed, 13 Jan 1999 19:06:14 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>, "[e-mail]" <[e-mail]>, ietf-pkix <[e-mail]>, Carlisle Adams <[e-mail]>, farrell <[e-mail]>
Subject: Re: Reason codes vs Reason flags
References: <[e-mail]> <4.1.19990113095846.00a988c0@209.172.119.123>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al, John

Al Arsenault wrote:
> 
> Juergen,
> 
>         Whoa!  While I appreciate your approach, I think it makes things way
> more complicated than they need to be.  

I apologize. This was the result of doing mathematics during lunch time
and thinking about reason codes vs reason flags afterwards. :-)

>Why, for example, should my software
> have to deal with a single reasonFlags and multiple certTemplates, when I'll
> just have to go in and parse each certificate to see what reason it was revoked
> for, anyway?

Firstly, a huge number of certTemplates with identically revocation
reasons, secondly ... (see below)

> It doesn't seem to be any benefit to me to know that "of the
> following six certificates, one or more was revoked for keyCompromise, one or
> more for affiliationChanged, one or more for superseded, and one or more for
> certificateHold".  I'm going to have to look at each individual certificate to
> see why it specifically should be revoked, so the extra reasonFlags doesn't buy
> me anything.

This is exactly the situation with respect to the current CMP draft. To
each certTemplate one may find two sources of revocation reasons. Taking
this into consideration I suggested that reason codes should be chosen.

> 
>         The only time when I can see something like that being useful is if you
> consider one particular reason to be 'worse" than the others.  For example, in
> some situations, keyCompromise may be more "important" than all the other
> reasons (that's clearly not always true, but it may well be in some
> circumstances).  Thus, you could look at the initial reasonFlags to see if you
> had any keyCompromises, and if so, expedite processing of this revocation
> request.  Other than that, I don't see a win, and I do see more complicated
> code.

..., secondly ... exactly as you described.

I see. Indeed, the only advantage may be a situation whereby CA´s
operator is bombarded with long revocation request sent by many RAs at
the same time. A reason flags in front of the sequence of revocation
details may help the operator to select the priority, provided that
there is a ranking in the considered environment.
 

> 
>         I looked at this differently.  When John posed his question about
> whether any certificate should be revoked for multiple reasons, I looked at the
> reason codes listed in PKIX-1.  They are:
> 
>         CRLReason ::= ENUMERATED {
>                 unspecified (0),
>                 keyCompromise (1),
>                 cACompromise (2),
>                 affiliationChanged (3),
>                 superseded (4),
>                 cessationOfOperation (5),
>                 certificateHold (6),
>                 removeFromCRL (8) }
> 
> Now, it doesn't make sense to me to revoke a certificate for a reason of
> "unspecified" AND for another, specified reason at the same time.  Besides,
> PKIX-1 discourages the use of "unspecified", anyway, so I think we can
> eliminate any combinations including "unspecified".
> 
> Next, keyCompromise.  I suppose it is possible to revoke a certificate because
> its private key and the private key of its issuer were simultaneously
> compromised, but only if the CRL-issuer is using a different key.  Otherwise,
> in an event where the key was compromised at the same time the user's
> affiliation changed or the certificate was superseded (by one with a new key, I
> would hope :-), I would suggest that the requester just pick one - whichever is
> more important in her environment.
> 
> Similarly, looking at other possible pairs, very few of them make sense.  For
> example, I can't see where you would simultaneously want to revoke a
> certificate because it was superseded AND because of cessation of operations.

I agree. Otherwise, one may add other reasons when people ask for it. 

> 
> Because of this, I'd prefer that CMP use CRLReason vice reasonFlags so that the
> sender can only specify one reason, but I'm willing to keep things the way they
> are so as not to delay CMP any further.

So, CA´s operators software has to be aware of both the reason flags and
the reason codes. For clarity, I would prefer that CMP did not use
reason flags assigned to each certTemplate. Dropping of reason flags
would be fine, because if there are any ambiguities between these two
reason data, you will need a ranking of revocation reasons.
Alternatively, the unkown code may be approriate to this case.

> 
> So, from the standpoint of making everything interoperate, and making the
> software simpler to develop,

I completely agree with this standpoint.

> I propose the following:
> - Senders of CMP revocation requests SHOULD only include one reason for each
> certificate in the request.  (I'd personally prefer MUST, but I'm willing to
> accept that there might be some rare cases when two or more things pop up at
> once, and you want to let the recipient know all of the reasons.)  Senders
> SHOULD choose the reason that is most important in their system, if there is a
> way of ranking them in importance.  If not, senders SHOULD pick any one.
> 
> - Recipients of CMP revocation requests MUST accept messages with multiple
> reasonFlags selected.  If the request is accepted, the revoked certificate MUST
> only be placed on the CRL once, for one reason.  If one reason is deemed to be
> more important than others in the revoker's environment, the revoker SHOULD
> choose that reason; otherwise, the revoker can choose any reason for
> revocation.

I would prefer that PKIX uses only one revocation reasons encoding
throughout all drafts, i.e. the usage of reason codes. This gives
consistancy. The reason codes may be enlarged if required. In order to
implement this, combinations of elementary reasons could be enumerated.
Therefore, I propose that reason flags should be dropped. (I do not know
the history of CMP. So, I do not know whether the reason flags are
prehistoric vehicles or not. There is at least a second place where
reason flags is specified. You can find them in the CRL profile in
PKIX-1.)

Furthermore, one may think about reason flags in front of "long vehicle"
revocation requests. Firstly, this may help the CA´s operator to set a
priority of revocation request, when the revocation waiting queue is
overcrowded. Secondly, one may save bits in the case of multiple
certTemplates assigned to identical revocation reasons. This can be left
to further work. If this change will not lead to those advantages that I
have seen at a first glance, then it should not be done.

> 
> Any changes based on this can be made later; for now, this can be left as
> "yeah, we implementers understand that this should happen this way."  Hey -
> maybe it can even go in another version of the Roadmap. :-)
> 
> Comments?
> 
>                                 Al Arsenault
> 
> -- these are my opinions only. They do not necessarily reflect the
> opinions of my employer, or of any other organization with which I have a
> relationship.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21352 for ietf-pkix-bks; Wed, 13 Jan 1999 09:25:54 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA21348 for <[e-mail]>; Wed, 13 Jan 1999 09:25:50 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA12539; Wed, 13 Jan 1999 12:26:40 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki3cmp-09.txt
Date: Wed, 13 Jan 1999 12:26:40 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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 Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-ipki3cmp-09.txt
	Pages		: 67
	Date		: 12-Jan-99
	
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocols. Protocol messages are defined
for all relevant aspects of certificate creation and management.  Note
that 'certificate' in this document refers to an X.509v3 Certificate as
defined in [COR95, X509-AM].
 
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHOULD', 'SHOULD NOT',
'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document (in uppercase,
as shown) are to be interpreted as described in [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki3cmp-09.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki3cmp-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-09.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20382 for ietf-pkix-bks; Wed, 13 Jan 1999 07:47:37 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20378 for <[e-mail]>; Wed, 13 Jan 1999 07:47:35 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id KAA18826; Wed, 13 Jan 1999 10:26:33 -0500
Message-Id: <4.1.19990113095846.00a988c0@209.172.119.123>
X-Sender: aarsenault#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 13 Jan 1999 10:21:27 -0500
To: [e-mail], [e-mail], Carlisle Adams <[e-mail]>, [e-mail], ietf-pkix <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: Re: Reason codes vs Reason flags
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen,

        Whoa!  While I appreciate your approach, I think it makes things way
more complicated than they need to be.  Why, for example, should my software
have to deal with a single reasonFlags and multiple certTemplates, when I'll
just have to go in and parse each certificate to see what reason it was revoked
for, anyway?  It doesn't seem to be any benefit to me to know that "of the
following six certificates, one or more was revoked for keyCompromise, one or
more for affiliationChanged, one or more for superseded, and one or more for
certificateHold".  I'm going to have to look at each individual certificate to
see why it specifically should be revoked, so the extra reasonFlags doesn't buy
me anything.

        The only time when I can see something like that being useful is if you
consider one particular reason to be 'worse" than the others.  For example, in
some situations, keyCompromise may be more "important" than all the other
reasons (that's clearly not always true, but it may well be in some
circumstances).  Thus, you could look at the initial reasonFlags to see if you
had any keyCompromises, and if so, expedite processing of this revocation
request.  Other than that, I don't see a win, and I do see more complicated
code.

        I looked at this differently.  When John posed his question about
whether any certificate should be revoked for multiple reasons, I looked at the
reason codes listed in PKIX-1.  They are:

        CRLReason ::= ENUMERATED { 
                unspecified (0), 
                keyCompromise (1), 
                cACompromise (2), 
                affiliationChanged (3), 
                superseded (4), 
                cessationOfOperation (5), 
                certificateHold (6), 
                removeFromCRL (8) }

Now, it doesn't make sense to me to revoke a certificate for a reason of
"unspecified" AND for another, specified reason at the same time.  Besides,
PKIX-1 discourages the use of "unspecified", anyway, so I think we can
eliminate any combinations including "unspecified".

Next, keyCompromise.  I suppose it is possible to revoke a certificate because
its private key and the private key of its issuer were simultaneously
compromised, but only if the CRL-issuer is using a different key.  Otherwise,
in an event where the key was compromised at the same time the user's
affiliation changed or the certificate was superseded (by one with a new key, I
would hope :-), I would suggest that the requester just pick one - whichever is
more important in her environment.

Similarly, looking at other possible pairs, very few of them make sense.  For
example, I can't see where you would simultaneously want to revoke a
certificate because it was superseded AND because of cessation of operations.  

Because of this, I'd prefer that CMP use CRLReason vice reasonFlags so that the
sender can only specify one reason, but I'm willing to keep things the way they
are so as not to delay CMP any further.

So, from the standpoint of making everything interoperate, and making the
software simpler to develop, I propose the following:
- Senders of CMP revocation requests SHOULD only include one reason for each
certificate in the request.  (I'd personally prefer MUST, but I'm willing to
accept that there might be some rare cases when two or more things pop up at
once, and you want to let the recipient know all of the reasons.)  Senders
SHOULD choose the reason that is most important in their system, if there is a
way of ranking them in importance.  If not, senders SHOULD pick any one.

- Recipients of CMP revocation requests MUST accept messages with multiple
reasonFlags selected.  If the request is accepted, the revoked certificate MUST
only be placed on the CRL once, for one reason.  If one reason is deemed to be
more important than others in the revoker's environment, the revoker SHOULD
choose that reason; otherwise, the revoker can choose any reason for
revocation.

Any changes based on this can be made later; for now, this can be left as
"yeah, we implementers understand that this should happen this way."  Hey -
maybe it can even go in another version of the Roadmap. :-)

Comments?

                                Al Arsenault

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





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA19093 for ietf-pkix-bks; Wed, 13 Jan 1999 04:59:14 -0800 (PST)
Received: from pluto.deh.de ([194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA19089 for <[e-mail]>; Wed, 13 Jan 1999 04:59:07 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id OAA29483; Wed, 13 Jan 1999 14:00:09 +0100
Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id OAA18267; Wed, 13 Jan 1999 14:00:00 +0100
Message-ID: <[e-mail]>
Date: Wed, 13 Jan 1999 14:02:27 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], Carlisle Adams <[e-mail]>, [e-mail], ietf-pkix <[e-mail]>
Subject: Re: Reason codes vs Reason flags
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

I think, that reasonFlags should be used for the purpose of encoding
revocationReasons for more than one CertTemplate. Therefore, the setting
of more than one flag may be appropriate (see CRL profile in PKIX part
1). The current CMP draft has mapped one CertTemplate to one
reasonFlags. In addition, ReasonCodes are contained in the optional
Extensions.

My suggestion:
   

  RevReqContent ::= SEQUENCE {

      revocationReason    ReasonFlags      OPTIONAL, 
      -- the reason that revocation is requested
      revReqDetails SEQUENCE OF RevDetails }


  RevDetails ::= SEQUENCE { 
      certDetails         CertTemplate, 
      -- allows requester to specify as much as they can about 
      -- the cert. for which revocation is requested 
      -- (e.g., for cases in which serialNumber is not available)
      badSinceDate        GeneralizedTime  OPTIONAL, 
      -- indicates best knowledge of sender 
      crlEntryDetails     Extensions       OPTIONAL
      -- requested crlEntryExtensions 
  }
 
So, the requester may send more than one CertTemplate. For each
CertTemplate the requester may give a revocation reason in the
crlEntryDetails structure. Then ReasonFlags may be set in the following
way:

 Flag A is set if and only if there exists a CertTemplate that is
requested to be revoked due to reason A.
 
This may be done independently of reason codes optionally contained in
crlEntryDetails. But I would prefer the following usage:
If the revocation request contains more than one certificate templates
and the corresponding revocation reasons are different, then reason
codes (housed in the crlEntryDetails field) must be used. Optionally,
reason flags may be set as above described. But if the revocation
request contains only one certificate then the reason flag and/or the
reason code may be encoded. Otherwise, if the revocation request
contains more than one certificate templates and the corresponding
revocation reason is in each case the same, then the appropriate flag of
reason flag may be set. 

Futhermore, if there are any ambiguities with respect to revocation
reasons, then the CA has to issue a CRL, where the worst case reason
encoded in the request is referenced.

[e-mail] wrote:
> 
> The reason code field in a CRL encodes the reason for a revocation as an
> enumerated type;  the CMP revocation request field encodes it as a bitstring.
> 
> What should a CA do if it receives a CMP revocation request with more than one
> reason bit set?  Should it somehow prioritize the reasons, and put only the
> "most important reason" into the CRL?  Should it put multiple revocation entries
> in the CRL, one for each requested reason?  Should it reject the request as
> mal-formed?  Should CMP use CRLReason instead of ReasonFlags?
> 
> John


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA17101 for ietf-pkix-bks; Tue, 12 Jan 1999 07:36:11 -0800 (PST)
Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA17097 for <[e-mail]>; Tue, 12 Jan 1999 07:36:09 -0800 (PST)
From: [e-mail]
Received: by arista.iris.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 852566F7.0055C898 ; Tue, 12 Jan 1999 10:36:59 -0500
X-Lotus-FromDomain: IRIS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 12 Jan 1999 10:37:25 -0500
Subject: Reason codes vs Reason flags
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The reason code field in a CRL encodes the reason for a revocation as an
enumerated type;  the CMP revocation request field encodes it as a bitstring.

What should a CA do if it receives a CMP revocation request with more than one
reason bit set?  Should it somehow prioritize the reasons, and put only the
"most important reason" into the CRL?  Should it put multiple revocation entries
in the CRL, one for each requested reason?  Should it reject the request as
mal-formed?  Should CMP use CRLReason instead of ReasonFlags?

John




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA28064 for ietf-pkix-bks; Mon, 11 Jan 1999 20:22:02 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA28031 for <[e-mail]>; Mon, 11 Jan 1999 20:21:52 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <CY3P4NRR>; Tue, 12 Jan 1999 15:20:33 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC09433F@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: "'Peter Sylvester'" <[e-mail]>, [e-mail]
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Date: Tue, 12 Jan 1999 15:20:31 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Agree with most you say and I am a realist you know. However, may I make
the point, as below.

> -----Original Message-----
> From:	Stephen Kent [SMTP:[e-mail]]
> Sent:	Tuesday, 12 January 1999 9:58
> To:	Alan Lloyd
> Cc:	'Peter Sylvester'; [e-mail]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Alan,
> 
> >terms like "issuer" in the cert should be used - via a directory
> >service. - these are logical names of objects in the real world that
> >provide cert based services such a travel cards, etc. In addition a
> cert
> >can be used for authentication in many services so it (the cert)
> should
> >be as simple as possible re references to the services on which it is
> >used. In addition services may change by name/location and physical
> >properties due to error, compromise or failure - so in that case
> (where
> >references to services are tied to a cert) - all the certs would have
> to
> >be re issued.
> 
> I am not a believer in the one-size-fits-all certificate, so I am less
> concerned about the possible complexity that you suggest above.  A
> reasonable model of cert issuance suggests that users acquire multiple
> certs, each of which has limited scope, just like the many forms of
> ID,
> membership, and charge cards we carry today.  This simplifies many
> aspects
> of cert management, especially revocation, and avoids the complexities
> due
> to trying to "trust" one CA for many different credential forms.
> 
> >IMHO  would be simpler to build a DN based directory service with
> >logical issuer objects which support many cert based services than to
> >hand configure references of many services in every cert.
> 
> Unfortunately, we don't have a global directory service of the sort
> envisioned by X.500, so finding a service based on the DN of the cert
> issuer is not easy.
	[Alan Lloyd]  
	This comment is common in that we (the planet) does not have a
global directory service, therefore we wont use it.
	In terms of engineering systems, a directory service is a
function - and should be seen as just that ie. it is a distributed
object oriented function - with auth and access control properties - and
regardless of scale and operational deployment - if directory services
are considered as a supporting information infrastructure that will be
applied in many vertical markets and organisations for many operational,
information management, security and service delivery reasons, then why
not incorporate such functions into such things as PKI.

	Its like that when OCSP or LDAP or HTTP were invented they all
assumed and relied on the fact that TCP/IP and the Internet existed and
was serviceable and they used that. When X.500 was designed it assumed
underlying comms/Internet were there to support inter directory
operations. When X.509 and CAs and the X.500 distributed authentication
model was put together it assumed a distributed directory service with
DSP, DAP (and LDAP) were available. 
	By putting and crypto binding system config/directory references
into certs and mapping subjects and issuers to the URLs of servers - all
we are doing is operationally placing single directory entries all over
the place in a fragmented and possibly uncordinated way - ie
operationally if a directory service is not used. The certficate by
definition becomes a directory entry (ie it related names to server
addresses) and the humans that manage (the millions of these cert/dir
information things) - become the directory infrastructure.

	Not good for operational approaches re cost, reliability and
scaling.
	 I think directory supported OCSP servers will be the way to go.

	just thoughts and regards alan

> PKIX recommends use of an extension that we developed specifically so
> that
> the issuer of a cert can point users to the locations where anciliary
> services can be accessed.  If one has suitable directory support,
> e.g., due
> to limited scope or as a result of config data, then it might be a
> fine
> alternative.  However, in an effort to not hold up deployment of such
> services while waiting for ubiquitous directory service, ...
> 
> >I do not think adding references in certs beyond that of issuer DN is
> >the way to go. The danger is that each cert will end up like a web
> >document and all PKIs will be like the WEB in terms of their
> management
> >resources and overheads.
> 
> One could easily overdo it, but I don't think we're in danger of that
> yet.
> 
> Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA25476 for ietf-pkix-bks; Mon, 11 Jan 1999 20:04:05 -0800 (PST)
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 UAA25470 for <[e-mail]>; Mon, 11 Jan 1999 20:04:03 -0800 (PST)
Received: from [128.33.238.144] (TC073.BBN.COM [128.33.238.73]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id XAA28164; Mon, 11 Jan 1999 23:04:44 -0500 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04011709b2c030ae2f3c@[128.33.238.144]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC09431D@DSG1>
Date: Mon, 11 Jan 1999 17:58:04 -0500
To: Alan Lloyd <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Cc: "'Peter Sylvester'" <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan,

>terms like "issuer" in the cert should be used - via a directory
>service. - these are logical names of objects in the real world that
>provide cert based services such a travel cards, etc. In addition a cert
>can be used for authentication in many services so it (the cert) should
>be as simple as possible re references to the services on which it is
>used. In addition services may change by name/location and physical
>properties due to error, compromise or failure - so in that case (where
>references to services are tied to a cert) - all the certs would have to
>be re issued.

I am not a believer in the one-size-fits-all certificate, so I am less
concerned about the possible complexity that you suggest above.  A
reasonable model of cert issuance suggests that users acquire multiple
certs, each of which has limited scope, just like the many forms of ID,
membership, and charge cards we carry today.  This simplifies many aspects
of cert management, especially revocation, and avoids the complexities due
to trying to "trust" one CA for many different credential forms.

>IMHO  would be simpler to build a DN based directory service with
>logical issuer objects which support many cert based services than to
>hand configure references of many services in every cert.

Unfortunately, we don't have a global directory service of the sort
envisioned by X.500, so finding a service based on the DN of the cert
issuer is not easy.
PKIX recommends use of an extension that we developed specifically so that
the issuer of a cert can point users to the locations where anciliary
services can be accessed.  If one has suitable directory support, e.g., due
to limited scope or as a result of config data, then it might be a fine
alternative.  However, in an effort to not hold up deployment of such
services while waiting for ubiquitous directory service, ...

>I do not think adding references in certs beyond that of issuer DN is
>the way to go. The danger is that each cert will end up like a web
>document and all PKIs will be like the WEB in terms of their management
>resources and overheads.

One could easily overdo it, but I don't think we're in danger of that yet.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA15987 for ietf-pkix-bks; Mon, 11 Jan 1999 18:28:18 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15980 for <[e-mail]>; Mon, 11 Jan 1999 18:28:10 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <CY3P4NRA>; Tue, 12 Jan 1999 13:26:49 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC094336@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Linn, John'" <[e-mail]>, [e-mail], "'Peter Sylvester'" <[e-mail]>
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Date: Tue, 12 Jan 1999 13:26:48 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for that John. My comments on OCSP also mentioned the use of this
extension in that in a domain agile and global wanderer envrionment -
and to deal with errors or failures in OCSP servers - it would be better
if the certificate did not cryptographically tie its validation server
to the users details. ie. if a "named" OCSP server failed the cert
cannot be validated however, if a fault tollerant and replicated
directory backbone service - that supported many OCSP validation
processes failed, then an alternative validation process can be dealt
with in the system. Its a question that OCSP seems to want to fix the
OCSP server details in the cert, whereas a directory enabled OCSP
approach with-distributed and replicated OCSP server funtions offers
better utility and scaleability without the need to crypto-bind config
info into certs.

just thoughts 
regards alan
> -----Original Message-----
> From:	Linn, John [SMTP:[e-mail]]
> Sent:	Tuesday, 12 January 1999 5:09
> To:	[e-mail]; 'Peter Sylvester'
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Peter, all, re:
> 
> > > IMHO  would be simpler to build a DN based directory service with
> > > logical issuer objects which support many cert based services than
> to
> > > hand configure references of many services in every cert.
> > I guess you missed one point here: The extensions are not in the
> > end user certs but in a cert that describes the service, for exemple
> > in the public key certificate of some OCSP or DCS service. 
> > 
> This isn't how I read ocsp-07, section 4.1, 1st paragraph, which
> states, "In
> order to convey to OCSP clients a well-known point of information
> access,
> CAs SHALL provide the capability to include the AuthorityInfoAccess
> extension (defined in [PKIX1], section 4.2.2.1) in certificates that
> can be
> checked using OCSP".  Absent restatement or rescoping, this seems to
> include
> end users as well as OCSP services themselves within the set of
> certified
> entities for which OCSP-conformant CAs are expected to be able to
> include
> certificate-resident AIA extensions for use in locating an appropriate
> OCSP
> responder.  The remainder of the paragraph notes that locally
> configured
> client data can be used as an alternative to inclusion of AIA
> extensions,
> suggesting that this required capability may not be used in all cases,
> but I
> don't see discussion suggesting that intended use is confined to
> certificates above the end-user level.
> 
> --jl
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09221 for ietf-pkix-bks; Mon, 11 Jan 1999 10:40:07 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09217 for <[e-mail]>; Mon, 11 Jan 1999 10:40:06 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA10467 for <[e-mail]>; Mon, 11 Jan 1999 19:41:19 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 11 Jan 1999 19:41:18 +0100 (MET)
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 TAA25252 for <[e-mail]>; Mon, 11 Jan 1999 19:41:18 +0100
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA10145 for [e-mail]; Mon, 11 Jan 1999 19:41:17 +0100
Date: Mon, 11 Jan 1999 19:41:17 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Actually, the second and third paragraph of 4.1 seem to describe
what I have been asking for if one changes the following text.


   In order to convey to OCSP clients a well-known point of information
   access, CAs SHALL provide the capability to include the
   AuthorityInfoAccess extension (defined in [PKIX1], section 4.2.2.1)
   in certificates that can be checked using OCSP 
+  or in in certificates for CAs or Authorised Responders.
   Alternatively, the accessLocation for the OCSP provider may be
   configured locally at the OCSP client.

Two scenarios:

- A end-user client has some knowledge about one single local provider
  (kind of local proxy/broker).

- An end user-client (which may be the proxy/broker) knows about CAs
  and the OCSP providers. 

The first case can be covered by 'a local configuration'. if one
wants OCSP requests to be signed, then this local configuration
would contain a public key of the local proxy, probably in a
certificate, and it makes sense to me to have the indicated
extension in this certificate.  

In the second case, I would see the extension in a certificate
describing an issuer's service for ALL certificates issued
by the issuer. 


Similar remarks for DCS etc. are left as an exercise






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09215 for ietf-pkix-bks; Mon, 11 Jan 1999 10:39:17 -0800 (PST)
Received: from exchng-fairfax.p-e-c.com (exchng-fairfax.pec.com [204.254.216.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09211 for <[e-mail]>; Mon, 11 Jan 1999 10:39:15 -0800 (PST)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <CXYLKPHX>; Mon, 11 Jan 1999 13:41:40 -0500
Message-ID: <[e-mail]>
From: WHenry <[e-mail]>
To: [e-mail]
Cc: "'[e-mail]'" <[e-mail]>
Subject: Document-centric Digital Signatures
Date: Mon, 11 Jan 1999 13:41:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BE3D92.05D97DE0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------ =_NextPart_001_01BE3D92.05D97DE0
Content-Type: text/plain

 All:

 Several months ago I started a discussion thread about the viability of
embedding digital signatures within electronic documents (e.g. Word, Excel,
etc).

 Some of the responses I received ranged from "use CMS!" to "it would be
difficult to get application vendors on-board." There seemed to be some
interest in establishing a BOF at the next IETF mtg to discuss this.

 In the absence of a BOF, I've set up a listserv for discussing this issue
at http://www.onelist.com. You can subscribe to Disig-arch under Computers -
Security or use the following URL
http://www.onelist.com/viewarchive.cgi?listname=digsig-arch

 Subscribers post to the list using the following address:
[e-mail]

 "Digsig-arch" is an unmoderated list intended to provide a forum for the
discussion of issues related to the archiving of digitally signed electronic
documents. The list focuses on public key infrastructure (PKI) associated
digital signature issues vice biometric or electronic signature issues.

 Apologies for not providing an email subscribe/unsubscribe capability.
However, the service is free and very easy to maintain (which we like!).
Onelist will maintain a discussion archive at the site for those interested
in reviewing previous postings.

 I've taken the liberty of posting my (and others) previous ietf-pkix
postings regarding this issue in the archive (from May '98 timeframe).

 Regards,
 Bill Henry
 Performance Engineering Corporation
 Fairfax, VA


------ =_NextPart_001_01BE3D92.05D97DE0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.0.1460.9">
<TITLE>Document-centric Digital Signatures</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;All:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Several months ago I started a =
discussion thread about the viability of embedding digital signatures =
within electronic documents (e.g. Word, Excel, etc).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Some of the responses I received =
ranged from &quot;use CMS!&quot; to &quot;it would be difficult to get =
application vendors on-board.&quot; There seemed to be some interest in =
establishing a BOF at the next IETF mtg to discuss this.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;In the absence of a BOF, I've =
set up a listserv for discussing this issue at<U></U></FONT><U> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.onelist.com" =
TARGET=3D"_blank">http://www.onelist.com</A></FONT></U><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">. You can subscribe to</FONT> =
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Disig-arch under =
Computers - Security or use the following URL</FONT><U> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.onelist.com/viewarchive.cgi?listname=3Ddigsig-arch" =
TARGET=3D"_blank">http://www.onelist.com/viewarchive.cgi?listname=3Ddigs=
ig-arch</A></FONT></U></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&nbsp;Subscribers =
post to the list using the following address:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">[e-mail]</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">&nbsp;&quot;Digsig-arch&quot; is an unmoderated list =
intended to provide a forum for the discussion of issues related to the =
archiving of digitally signed electronic documents. The list focuses on =
public key infrastructure (PKI) associated digital signature issues =
vice biometric or electronic signature issues.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&nbsp;Apologies for =
not providing an email subscribe/unsubscribe capability.&nbsp; However, =
the service is free and very easy to maintain (which we like!). Onelist =
will maintain a discussion archive at the site for those interested in =
reviewing previous postings.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&nbsp;I've taken the =
liberty of posting my (and others) previous ietf-pkix postings =
regarding this issue in the archive (from May '98 =
timeframe).</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">&nbsp;Regards,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&nbsp;Bill =
Henry</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&nbsp;Performance =
Engineering Corporation</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&nbsp;Fairfax, =
VA</FONT>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BE3D92.05D97DE0--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA08871 for ietf-pkix-bks; Mon, 11 Jan 1999 10:04:57 -0800 (PST)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA08867 for <[e-mail]>; Mon, 11 Jan 1999 10:04:56 -0800 (PST)
Received: from mail.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 11 Jan 1999 18:06:21 UT
Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id NAA04866; Mon, 11 Jan 1999 13:13:58 -0500 (EST)
Received: by exna01.securitydynamics.com with Internet Mail Service (5.5.2232.9) id <YY4R2W47>; Mon, 11 Jan 1999 13:05:57 -0500
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: [e-mail], "'Peter Sylvester'" <[e-mail]>
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Date: Mon, 11 Jan 1999 13:09:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter, all, re:

> > IMHO  would be simpler to build a DN based directory service with
> > logical issuer objects which support many cert based services than to
> > hand configure references of many services in every cert.
> I guess you missed one point here: The extensions are not in the
> end user certs but in a cert that describes the service, for exemple
> in the public key certificate of some OCSP or DCS service. 
> 
This isn't how I read ocsp-07, section 4.1, 1st paragraph, which states, "In
order to convey to OCSP clients a well-known point of information access,
CAs SHALL provide the capability to include the AuthorityInfoAccess
extension (defined in [PKIX1], section 4.2.2.1) in certificates that can be
checked using OCSP".  Absent restatement or rescoping, this seems to include
end users as well as OCSP services themselves within the set of certified
entities for which OCSP-conformant CAs are expected to be able to include
certificate-resident AIA extensions for use in locating an appropriate OCSP
responder.  The remainder of the paragraph notes that locally configured
client data can be used as an alternative to inclusion of AIA extensions,
suggesting that this required capability may not be used in all cases, but I
don't see discussion suggesting that intended use is confined to
certificates above the end-user level.

--jl




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06142 for ietf-pkix-bks; Mon, 11 Jan 1999 04:40:47 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA06138 for <[e-mail]>; Mon, 11 Jan 1999 04:40:45 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA24226 for <[e-mail]>; Mon, 11 Jan 1999 13:41:55 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 11 Jan 1999 13:41:55 +0100 (MET)
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 NAA17274 for <[e-mail]>; Mon, 11 Jan 1999 13:41:54 +0100
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id NAA09960 for [e-mail]; Mon, 11 Jan 1999 13:41:54 +0100
Date: Mon, 11 Jan 1999 13:41:54 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Some thoughts:
> terms like "issuer" in the cert should be used - via a directory
> service. - these are logical names of objects in the real world that
> provide cert based services such a travel cards, etc. In addition a cert
> can be used for authentication in many services so it (the cert) should
> be as simple as possible re references to the services on which it is
> used. In addition services may change by name/location and physical
> properties due to error, compromise or failure - so in that case (where
> references to services are tied to a cert) - all the certs would have to
> be re issued.
> 
> IMHO  would be simpler to build a DN based directory service with
> logical issuer objects which support many cert based services than to
> hand configure references of many services in every cert.
I guess you missed one point here: The extensions are not in the
end user certs but in a cert that describes the service, for exemple
in the public key certificate of some OCSP or DCS service. 

I am not talking about any protocol that tells you how to get from 
an end user cert to whatever service provider. 

Certificates for OCSP signing or DCS services are rather special
things. They are really end user certificates but closely related to
CAs. 

> 
> I do not think adding references in certs beyond that of issuer DN is
> the way to go. The danger is that each cert will end up like a web
> document and all PKIs will be like the WEB in terms of their management
> resources and overheads.

I fully agree with you that filling end user certificates with such
information would not be a very good idea. 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA01579 for ietf-pkix-bks; Sun, 10 Jan 1999 20:50:34 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA01575; Sun, 10 Jan 1999 20:50:31 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <CVPZ6865>; Mon, 11 Jan 1999 15:49:13 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC094330@DSG1>
From: Alan Lloyd <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Last Call: X.509 Internet Public Key Infrastructure Online Ce rtificate Status Protocol - OCSP to Proposed Standard
Date: Mon, 11 Jan 1999 15:49:11 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All, HNY
I put some comments in on the OCSP doc. Did they get incorporated?
regards alan

> -----Original Message-----
> From:	The IESG [SMTP:[e-mail]]
> Sent:	Saturday, 9 January 1999 0:47
> Cc:	[e-mail]
> Subject:	Last Call: X.509 Internet Public Key Infrastructure
> Online Certificate Status Protocol - OCSP to Proposed Standard
> 
> 
> The IESG has received a request from the Public-Key Infrastructure
> (X.509) Working Group to consider X.509 Internet Public Key
> Infrastructure Online Certificate Status Protocol - OCSP
> <draft-ietf-pkix-ocsp-07.txt> as a Proposed Standard.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [e-mail] or [e-mail] mailing lists by January 21, 1999.
> 
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-07.txt
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA29919 for ietf-pkix-bks; Sun, 10 Jan 1999 15:17:30 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA29915 for <[e-mail]>; Sun, 10 Jan 1999 15:17:25 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <CVPZ68YR>; Mon, 11 Jan 1999 10:15:50 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC09431D@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, [e-mail]
Subject: RE: finding services : DCS, OCSP, Timestamping, ..
Date: Mon, 11 Jan 1999 10:15:48 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Some thoughts:
terms like "issuer" in the cert should be used - via a directory
service. - these are logical names of objects in the real world that
provide cert based services such a travel cards, etc. In addition a cert
can be used for authentication in many services so it (the cert) should
be as simple as possible re references to the services on which it is
used. In addition services may change by name/location and physical
properties due to error, compromise or failure - so in that case (where
references to services are tied to a cert) - all the certs would have to
be re issued.

IMHO  would be simpler to build a DN based directory service with
logical issuer objects which support many cert based services than to
hand configure references of many services in every cert.

I do not think adding references in certs beyond that of issuer DN is
the way to go. The danger is that each cert will end up like a web
document and all PKIs will be like the WEB in terms of their management
resources and overheads.

regards alan 



> -----Original Message-----
> From:	Peter Sylvester [SMTP:[e-mail]]
> Sent:	Tuesday, 5 January 1999 3:06
> To:	[e-mail]
> Subject:	finding services : DCS, OCSP, Timestamping, ..
> 
> happy new year
> 
> The current texts of DCS, OCSP, Timestaping do not specify how one can
> find the actual service. It seems useful to me to use some
> certificate extension.
> 
> The service operate (or can operate) in 'signed' environments, thus
> a client has some knowledge of the public key of the service;
> there are some chances that this knowledge comes from a certificate. 
> On the other hand the actual method of getting the service, 
> http, ftp, xyz, and the addresses is not known. It seems 
> logical to me to put extensions conforming to
> 
> pkix part 1: 4.2.2.1  Authority Information Access
> 
> into the certificate that describes the access point and method to
> that service. 
> 
> 
> 
> Peter Sylvester


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA01079 for ietf-pkix-bks; Fri, 8 Jan 1999 10:32:44 -0800 (PST)
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 KAA01075 for <[e-mail]>; Fri, 8 Jan 1999 10:32:42 -0800 (PST)
Received: 	id NAA05656; Fri, 8 Jan 1999 13:29:41 -0500
Received: by gateway id <ZZJ1DH1Y>; Fri, 8 Jan 1999 13:31:35 -0500
Message-ID: <91AE69321799D211AEC500105A9C46961650DC@SOTHMXS05>
From: Luke Koops <[e-mail]>
To: "'Brian LaMacchia'" <[e-mail]>, [e-mail]
Cc: "Barb Fox (Exchange)" <[e-mail]>
Subject: RE: CMC Comments? 
Date: Fri, 8 Jan 1999 13:29:47 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks to Carlisle for responding to many of your comments.  I will attempt
to reply to the few remaining outstanding issues.  I have deleted the
sections of the original message to which I am not responding.  Hopefully
the result is readable and fair.

-Luke Koops
[e-mail]


> ----------
> From: 	Brian LaMacchia[SMTP:[e-mail]]
> Sent: 	Wednesday, December 23, 1998 5:58 PM
> To: 	'Luke Koops'
> Cc: 	[e-mail]; Barb Fox (Exchange)
> Subject: 	RE: CMC Comments? 
> 
> Luke--
> 
> 	1) It is not clear what a minimally compliant implementation MUST
> support.  It
> 	seems to be:
> 
[ ...MUNCH... ]

> 	In order to be compliant with the protocol, clients just need to
> continue
> 	operating as they already do.
> 
> No, they also need to understand the Full PKI Response message.  A current
> client (that only speaks PKCS#10/7) is not CMC-compliant because it does
> not
> support a standard mechanism for returning error information.
> 
> 	Is there a need to lower the bar for PKIX compliance to this level?
> 
> Obviously, the long-term goal is to use Full PKI Request and Response
> messages throughout.
<Luke>I would not ascribe goals to a standard per se, and I do not claim to
know what the goals of the authors are.

<Luke>It seems to me that this protocol will promote the status quo by
embodying it within a standard.

>   However, CMC also has a goal of supporting
> industry-standard PKCS#10/7 as a subset of the protocol, so that current
> clients and servers can also participate in the CMC world.
<Luke>Current certificate clients could participate in the CMC world with
minimal modifications (support for full response).  A certificate server
could also participate in the CMC world with minimal modifications as well
(issue full response).  But, such a server would not be CMC compliant.  The
standard has many more MUST clauses for a compliant server than it does for
a compliant client.  Your statement illustrates the confusion that will
arise when vendors tout their product as "conforming with", "interoperating
with", "complying to", or "supporting" the PKIX-CMC protocol.  It seems
likely that servers will be written to support minimally compliant clients.

> 	PKIX-CMC needs to clearly state what MUST be supported by a
> minimally
> 	compliant implementation of the client and server.
> 
> Agreed; I will suggest text to the authors for a Conformance section
> (following the table at the top of this mail).
> 
> 	2) There is duplicate information in CRMF and CMC messages.  
[ ...MUNCH... ]
> This comment is similar to the one Carlisle raised.  The intent is that
> controls should appear in the CMC control section, and not in individual
> request bodies.
<Luke>If the intent is not specified in the standard, then other behaviour
should be anticipated and addressed by the standard.
>   Putting the controls in CMC allows individual controls to
> reference/apply to multiple request bodies.  It also puts all the
> processing
> information up front, which facilitates one-pass processing.
> 
> 	3) The regInfo and respInfo controls are 'too open'.  The result is
> that a CA
> 	or RA might not be able to interoperate with two different clients
> which use
> 	regInfo differently.  A bit pattern could be a valid message from
> both types
> 	of clients, but with different semantics.  It might not be possible
> to
> 	specify a parser which can handle both requests.
> 
> 	It would be much better if regInfo and respInfo were not octet
> strings, but
> 	were defined in the following manner.
> 
> 	  ExtraInfo ::= SEQUENCE {
> 	    infoType OBJECT IDENTIFIER,
> 	    info ANY DEFINED BY infoType }
> 
> (I assume you mean responseInfo, not respInfo...)
> 
> I don't see the need to extend the definition of regInfo or responseInfo
> into a SEQUENCE of OID/ANY as you suggest.  If client and server choose to
> define particular semantics for their specific information, and there's an
> OID tagging a structure with those semantics, then that information can be
> passed at top-level as just another CMC control attribute.  It is expected
> that clients and servers that choose to define additional information
> specific to their agreements will pass this information through additional
> control attributes; there's no reason to bury it down inside a
> regInfo/responseInfo/ExtraInfo structure.
> 
> (The regInfo and responseInfo controls themselves were defined for clients
> and servers that have agreed on the semantics of that OCTET STRING through
> some out-of-band mechanism.  For example, in a Web-based enrollment
> scenario
> the server could construct the regInfo using form field values & script.) 
<Luke>This creates the possibility that it would be impossible for a server
to interoperate with the clients from several vendors that use these
controls.  My original statement remains unanswered.

[ ...MUNCH... ]

> ======================================================================
> 	Other observations (collected from other readers here):
> 
[ ...MUNCH... ]

> 	   - it is not possible to securely send the CA root key in the
> response
> 	message.  This might be a serious limitation in some environments.
> 
> What do you mean by "securely send the CA root key"?  Please expand on
> this
> remark.
<Luke>During initialization, a one time password could be used for _mutual_
authentication of the client and the server.  Then the client could rely on
the server to advise it of trusted root keys which would be used for
verifying certificates.

<Luke>In some environments this might be a preferable way to seed the client
with trusted root keys.  Rather than have the software vendor decide which
root keys are trusted, the end user would choose the trust network(s) in
which she will participate.  After making this choice, the user gets an i.d.
and a one time password.  This is all that is required to bootstrap the
client into full participation.

> Hope this answers your questions,
> 
> 					--Brian LaMacchia
> 					  [e-mail]
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA28798 for ietf-pkix-bks; Fri, 8 Jan 1999 05:46:25 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA28794 for <[e-mail]>; Fri, 8 Jan 1999 05:46:24 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA11647; Fri, 8 Jan 1999 08:46:48 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP to Proposed Standard
Reply-to: [e-mail]
Date: Fri, 08 Jan 1999 08:46:48 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP
<draft-ietf-pkix-ocsp-07.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by January 21, 1999.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-07.txt




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA28721 for ietf-pkix-bks; Fri, 8 Jan 1999 05:29:05 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA28717 for <[e-mail]>; Fri, 8 Jan 1999 05:29:04 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA11109; Fri, 8 Jan 1999 08:29:29 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Internet X.509 Public Key Infrastructure LDAPv2 Schema to Proposed Standard
Reply-to: [e-mail]
Date: Fri, 08 Jan 1999 08:29:28 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider Internet X.509 Public Key
Infrastructure LDAPv2 Schema <draft-ietf-pkix-ldapv2-schema-02.txt> as
a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by January 21, 1999.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-02.txt


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA28711 for ietf-pkix-bks; Fri, 8 Jan 1999 05:27:45 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA28707 for <[e-mail]>; Fri, 8 Jan 1999 05:27:44 -0800 (PST)
Received: from scoya.cnri.reston.va.us ([10.27.4.17]) by ietf.org (8.8.5/8.8.7a) with SMTP id IAA11074 for <[e-mail]>; Fri, 8 Jan 1999 08:28:09 -0500 (EST)
Date: Fri, 8 Jan 1999 08:28:19 -0500 (Eastern Standard Time)
From: Steve Coya <[e-mail]>
To: [e-mail]
Subject: Last Call: Internet X.509 Public Key Infrastructure  Operational Protocols: FTP and HTTP to Proposed Standard (fwd)
Message-ID: <[e-mail]>
X-X-Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

fyi (sorry 'bout the oldd address....)

---------- Forwarded message ----------
Date: Fri, 08 Jan 1999 08:13:19 -0500
From: The IESG <[e-mail]>
Reply-To: [e-mail]
To: IETF-Announce:  ;
Cc: [e-mail]
Subject: Last Call: Internet X.509 Public Key Infrastructure  Operational Protocols: FTP and HTTP to Proposed Standard


The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP
<draft-ietf-pkix-opp-ftp-http-04.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by January 21, 1999.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-opp-ftp-http-04.txt




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA24460 for ietf-pkix-bks; Fri, 8 Jan 1999 00:21:08 -0800 (PST)
Received: from krdl.org.sg (rodin.krdl.org.sg [137.132.252.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA24378; Fri, 8 Jan 1999 00:16:28 -0800 (PST)
Received: from mailhost.krdl.org.sg (mailbox.krdl.org.sg [137.132.247.30]) by krdl.org.sg (8.9.0/8.9.0) with ESMTP id QAA19629; Fri, 8 Jan 1999 16:20:41 +0800 (SGT)
Received: from colorado (colorado [137.132.249.218]) by mailhost.krdl.org.sg (8.9.0/8.9.0) with SMTP id QAA10492; Fri, 8 Jan 1999 16:14:52 +0800 (SGT)
Date: Fri, 8 Jan 1999 16:14:09 +0800 (SGT)
From: Jianying Zhou <[e-mail]>
X-Sender: jyzhou@colorado
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: ACM CCS'99 CFP 
In-Reply-To: <Pine.GSO.4.02.9901081110300.2413-101000@colorado>
Message-ID: <Pine.GSO.4.02.9901081612280.2595-100000@colorado>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I apology for sending a large attachment in an early message.

Sorry.

Jianying Zhou





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA20084 for ietf-pkix-bks; Tue, 5 Jan 1999 11:51:10 -0800 (PST)
Received: from gateway-ext.StructuredArts.COM ([e-mail] [206.127.192.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA20080 for <[e-mail]>; Tue, 5 Jan 1999 11:51:08 -0800 (PST)
Received: from structuredarts.com (kuma.structuredarts.com [206.127.206.4]) by gateway-ext.StructuredArts.COM (8.8.5/8.8.5) with ESMTP id MAA09136 for <[e-mail]>; Tue, 5 Jan 1999 12:06:21 -0800
Message-ID: <[e-mail]>
Date: Tue, 05 Jan 1999 11:53:52 -0800
From: "Anil R. Gangolli" <[e-mail]>
Organization: Structured Arts Computing Corporation
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Questions on Issuing Distribution Point CRL extension
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have a couple of questions in reference to section 
5.2.5 of draft 11.  I think the draft could use a bit
of clarification on these points.

1. Are the indications onlyContainsUserCerts and onlyContainsCACerts
   applicable to the CRL in which they appear, or to the CRL obtained at
   the distribution point, or both.  My current reading is that
   they apply to both.  One needs some indication within the CRL if
   it only contains some classes of certs, and I don't see another mechanism
   defined for that.

2. What does the indirectCRL indication mean?  A description seems to be
   missing from the spec, (and might partly be a source of my confusion).

3. I have seen a test CRL issued with multiple distribution points bearing
   distinct indications of classes of certs "covered".  Is this allowed? 
   This might be appropriate for  indicating where to get CRLs for other classes
   of certs in the case of partitioned CRLs, but then there is then a need to define 
   some separate mechanism to indicate which indications apply directly to the CRL
   in which the extension appears.  (Read item 1 above as well).  I don't see one;  
   my current interpretation is that the Issuing Distribution Point extension in a 
   given CRL indicate only where to get updates for that one CRL, and that the 
   indications that specify classes of certs "covered" by the CRL apply to that 
   CRL and any update obtained at that distribution point.  Is this correct?

Could someone (maybe one of the draft 11 authors) suggest some revisions
to 5.2.5 that clarify these points?


--a.
-- 
Anil R. Gangolli
Structured Arts Computing Corporation
mailto:[e-mail]
http://www.structuredarts.com


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA19077 for ietf-pkix-bks; Tue, 5 Jan 1999 09:51:38 -0800 (PST)
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 JAA19073 for <[e-mail]>; Tue, 5 Jan 1999 09:51:37 -0800 (PST)
Received: 	id MAA08300; Tue, 5 Jan 1999 12:48:53 -0500
Received: by gateway id <ZZJ1CYVB>; Tue, 5 Jan 1999 12:50:46 -0500
Message-ID: <91AE69321799D211AEC500105A9C4696196E9B@SOTHMXS05>
From: Carlisle Adams <[e-mail]>
To: "'Brian LaMacchia'" <[e-mail]>
Cc: [e-mail]
Subject: RE: CMC Comments? 
Date: Tue, 5 Jan 1999 12:49:09 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Brian,

Now that I'm back after a long (but way too short!) Christmas break, let me
jump in and address a couple of your points below.


-----Original Message-----
From: Brian LaMacchia [mailto:[e-mail]]
Sent: Wednesday, December 23, 1998 5:59 PM
To: 'Luke Koops'
Cc: [e-mail]; Barb Fox (Exchange)
Subject: RE: CMC Comments? 

Luke--

(...stuff deleted...)

	4) The absence of a client confirmation message means that there is
no way to
	be sure that a client recieved a response, or that a client accepts
the
	response.

In what particular scenarios do you believe a confirmation message is
required?  In particular, could you expand on what it means for a client to
"accept the response?"  I know that CMP uses the client confirmation message
as means of doing after-the-fact POP on an encryption key (the "indirect
method" defined in section 2.3.2): the cert is issued to the encryption key
before POP, the cert is returned to the client encrypted, the client
demonstrates POP by decrypting the encrypted cert, and failure to respond
requires that the CA now revoke the cert it just issued.  CMC takes the
approach that the cert should not be issued in the first place unless CA
policy has been completely satisfied (e.g. POP for encryption keys
demonstrated before the request is granted); this avoids extraneous
revocations.


<Carlisle> Actually, CMP does not specify that "failure to respond requires
that the CA now revoke the cert it just issued" (in fact, it suggests
exactly the opposite -- see the final sentence of Section 3.3.4 -- because
an encrypted certificate is of no use to anyone without the key to decrypt
it, so it does not need to be revoked).  However, POP for encryption key
pairs is not the reason that CMP specifies a confirmation message.  Recall
that the CA has the power/authority/privilege/prerogative/etc. to modify the
fields of any cert request that arrives.  The confirmation message allows
the EE to accept or deny the generated certificate, based upon whether or
not any changes made are acceptable to it.  Such a function is not merely
"nice-to-have"; it may be legally required in some environments.
Additionally, the confirmation message may simply be used to show that the
EE did, in fact, receive the certificate, triggering the CA to make the
certificate publicly available by some appropriate means.

<Carlisle> The fact that the confirmation message could simultaneously be
used for proof-of-possession of a decryption key was a happy coincidence
that CMP was pleased to exploit in order to achieve POP for all types of key
pairs without requiring any extra messages.




	p.1, item 1 in Abstract:  "need" should be replaced with "desire".

I respectfully disagree :-), as there is clearly a need within the community
to standardize current industry practice, as has long been identified within
the PKIX WG.

<Carlisle> I respectfully disagree with your respectful disagreement.  :-)
Something that is really "current industry practice", something that is
actually done by many/most products now, is already a de facto standard and
does not *need* to be standardized.  What needs to be standardized is the
next step, the next level of functionality addressing greater generality or
different environments (so that people know what to build).  I can
understand that there may be a *desire* to standardize current practice,
simply to formalize it and get it written down in concrete,
widely-accessible documents, but this is not actually a *need* if everyone
has already implemented it the same way (of course, if they *haven't*
implemented it the same way, then there really isn't "current industry
practice", is there?).  But this is a very minor quibble.




	p.2, section 2:  "The two different request messages" should be
replaced
	with "The three different request messages".

There are only two different request messages: Simple Enrollment Request and
Full PKI Request.  What is the third?

<Carlisle> Simple Enrollment Request, Full PKI Request (using PKCS #10), and
Full PKI Request (using CRMF) seem like three messages, but for me this is a
minor quibble as well.




	p.7, section 3.3.2 [see also p.6, section 3.3.1]:  MUST include both
the
	subject name and public key fields, although the subject may be
NULL.  There
	is an attack here on the initialization mechanism whereby I can copy
	somebody else's request and then send in my own request, ending up
with
	their public key and my identity in a valid verification
certificate.  In
	other words, the initialization mechanism is not secure.

This has already been pointed out by Carlisle in his previous list comments;
the authors are currently evaluating a number of proposals to nullify
self-inflicted denial-of-service attacks, including this one.

<Carlisle> The attack mentioned here is not a "self-inflicted
denial-of-service" attack.  It allows me to get my name and your
verification key put into a certificate which allows me, for example, to
(legally) claim as mine documents that you have signed, or to substitute
your certificate for mine in an authentication protocol that you are
engaging in such that the other party thinks it is communicating with me.
This is not denial-of-service stuff.




	p.7, section 3.3.3:  "[DH-SIG] provides a way to product necessary
	signature."  Change "product" to "produce the".  Also, note that
this
	mechanism is not strictly conformant with PKCS #10, which is very
explicit
	about how you sign the request.

This grammar will be fixed in the next draft.  As for the signature in a
PKCS#10, I'm not sure I understand your point.  PKCS#10 (as available at
ftp://ftp.rsa.com/pub/pkcs/doc/pkcs-10.doc, and as structurally included in
CMC) defines a CertificationRequest as a SEQUENCE of
CertificationRequestInfo, SignatureAlgorithm (an AlgorithmIdentifier) and a
Signature (BIT STRING), equivalent to the X.509 SIGNED macro.  All we need
to do is define the AlgorithmIdentifier and semantics of the Signature BIT
STRING for whatever DH-SIG ends up using.

<Carlisle> While syntactically conformant, such an interpretation of
"signatureAlgorithm" and "signature" are not strictly conformant with PKCS
#10 because the semantics are very different.  Section 6.2 of PKCS #10
(specifically the 3rd bullet and the 2nd step) make this clear, especially
when combined with Section 3.1 of the document "An Overview of the PKCS
Standards", which defines digital signature.  Again, however, this is a
relatively minor quibble, since in Orlando it was agreed that the
terminology "Diffie-Hellman *signature*" would no longer be used.




	p.9, section 4.2:  it seems to me that digging into the bowels of a
message
	in order to verify the outer envelope is a violation of the intent
of
	CMS/PKCS7.  Is there really no way to avoid this layering mismatch?

Somehow you need to get a copy of the public component of the signature key
pair in order to verify the signature.  CMS provides two types of hints in
SignerInfo to help you try to find the right key: an Issuer&SerialNumber
pointer and a SubjectKeyIdentifier value (SKI was just added in Orlando).
In S/MIMEv3 use, the I&SN identifies a cert for the corresponding public
key, and typically a copy of that cert will be included in the
CertificateSet.  if you're signing your Full PKI Request with a
previously-certified key that works fine.  However, this approach doesn't
work in CMC if you're signing the Full PKI Request with one of the key for
which you are requesting certification.  That's why draft -02 overloaded
I&SN, putting the bodyPartID in the SN slot and NULL IssuerName.  In the
next draft CMC will take advantage of the SKI form to identify a particular
key contained within the message.

<Carlisle> Taking advantage of the SKI to identify a particular key within
the message does not address the question asked.  The point is still that
you need to dig into the contents of the message before you can verify the
outer envelope for initialization messages.  This seems to be a layering
mismatch and seems to violate the intent of CMS/PKCS7.




	p.22, section 5.10.4.1:  "DH-PrivateKey ::= INTEGER" should be
	"DH-PrivateKey ::= INTEGER, re-encoded as an OCTET STRING" (written
in valid
	ASN.1).

	p.22, section 5.10.4.2:  "RSAPrivateKey" should be "RSAPrivateKey,
	re-encoded as an OCTET STRING" (written in valid ASN.1).

I don't understand this; are you asking for the INTEGER to be wrapped within
an OCTET STRING?  Why?  PKIX Part 1 uses INTEGER for the public components
of DSA an DH, and RSAprivate is pulled directly from PKCS#1.

<Carlisle> This comes from the definition of PrivateKeyInfo on the top of
page 22, where privateKey is defined to be an OCTET STRING.  In Sections
5.10.4.1 and 5.10.4.2 it says that privateKey must be INTEGER and
RSAPrivateKey, respectively, but in order for these to fit into the
specified PrivateKeyInfo structure, they must be re-encoded as OCTET
STRINGs.


Hope everyone else had a great Christmas as well!

Carlisle.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA15813 for ietf-pkix-bks; Mon, 4 Jan 1999 10:49:52 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA15809 for <[e-mail]>; Mon, 4 Jan 1999 10:49:46 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id NAA11552; Mon, 4 Jan 1999 13:50:00 -0500
Message-Id: <4.1.19990104133121.00a914a0@209.172.119.123>
X-Sender: aarsenault#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 04 Jan 1999 13:45:44 -0500
To: [e-mail], Nada Kapidzic Cicovic <[e-mail]>, Peter Gutmann <[e-mail]>, ietf-pkix <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: Re: CRL reason codes
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 05:38 PM 1/4/99 +0100, Juergen Walter wrote:
>Al, Nada, Peter,
>
>Do you know an example, where it is necessary to allow the CRL signed
>with  a key that is on the same CRL? 
>

There are two scenarios I can think of.  The first involves the compromise
of the CA's private CRL-signing key, and the second involves cessation of
CA operations.

In the compromise case, there are at least two ways to avoid having a CRL
signed with a key associated with a certificate that's on the list.  The
first involves the use of something like CRL Distribution Points and
Indirect CRLs (ICRLs), where you have a "trusted authority" who can notify
users that a CA's key has been compromised, and thus that any CRLs and/or
new certificates from that CA should not be trusted.  The second is to have
pre-placed a "replacement" key; i.e., 'the current key used by the CA is
key x, and the next key to be used by the CA will be key (x+1).'  

In the ICRL case, users have to go check a separate CRL (in addition to the
CA's regular CRL) to ensure that the CA's cert hasn't been revoked.  Other
than this performance impact/user inconvenience, though, this approach
works well as long as you can really trust the ICRL authority.  Otherwise,
you wind up with one node that can cause big-time denial of service
problems, just by revoking CAs at will.  

In the "replacement" key approach, this works as long as key (x+1) is not
compromised at the same time that key x is.  If x is compromised, but (x+1)
is not, then the CA switches to the new key, and sends out a CRL revoking
any certificate associated with x.  However, if x and (x+1) are compromised
at the same time, you're back where you were when you didn't have a
replacement key.

If you don't have one of these two strategies - ICRL or replacement key -
then I think that your only choice is to use the compromised key to sign a
CRL revoking certificates associated with that very key.

In the cessation of operations case, you can also use the ICRL approach to
avoid signing with the key associated with the certificate to be revoked,
because the ICRL Authority would outlive the CA.  I suppose you could also
use the replacement key approach, although it's not clear then how you'd
revoke the certs associated with the replacement key (or if you'd really
need to).  Otherwise, you just live with the original problem.  In this
case, it seems clear to me that the "safe" thing to do is accept the CRL as
valid, and then have applications refuse to honor the CA's key after that
point.

				Al Arsenault

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA15251 for ietf-pkix-bks; Mon, 4 Jan 1999 09:57:02 -0800 (PST)
Received: from pluto.deh.de (pluto.deh.de [194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA15247 for <[e-mail]>; Mon, 4 Jan 1999 09:57:00 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id SAA07584; Mon, 4 Jan 1999 18:57:30 +0100
Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id SAA13343; Mon, 4 Jan 1999 18:57:26 +0100
Message-ID: <[e-mail]>
Date: Mon, 04 Jan 1999 18:59:42 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: CRL reason codes
References: <[e-mail]> <4.1.19990104075715.00a87180@209.172.119.123>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al,

 
>         That's basically the scenario I'm talking about.  I have obtained through
> out of band methods the public key of a CA that I trust.  (Maybe it came on
> a tamper-resistant hardware token; maybe I got it by physically going to
> the CA workstation and copying it onto a floppy disk, which I hand carried
> back; maybe I used some other means to get it.) That public key is also
> contained in that CA's self-signed certificate.
> 
>         Then, the certificate containing the public key is listed on a CRL.  If it
> makes a difference, the reason code can be "key compromise"; i.e., we
> believe that the private key corresponding to the "trusted" public key has
> been compromised.
> 
>         So - a certificate containing the key I trust has now been declared to be
> revoked.  The declaration comes in a CRL, signed with the very private key
> that is now declared to be compromised. Do I believe it?

In my opinion, you have to believe it. As a consequence, all
certificates signed with the compromised key are invalid. Furthermore,
it does not matter, whether the certificates are listed in the issued
CRL. I have serious doubts that a validation software will detect this.
The additional CRL informations (like revocation date, invalidity date,
revocation reason, ...) are not authenticated. In this sense, your
validation software must be aware of fake CRLs.

> 
> >If the CRL was signed with the private key corresponding to your CA's
> >trusted public key, then you regard all of the revocations from the CRL as
> >valid (thus even the self-signed certificate is invalid, if you ever come
> >to verifying it).
> >
> 
>         Personally, that's my preference.  I believe that if a certificate
> containing a public key is revoked, and the revocation notice (e.g., the
> CRL) is signed with the  private key matching that public key, then the
> revocation notice should be treated as valid, and the certificate only
> marked revoked AFTER the revocation notice is processed.  I'm interested in
> other people's opinions, though.

What is about the following case? Your validation software has to verify
a certificate validity at T<"NOW". Supposed your software retrieves the
CRL that contains a CRL entry for the CRL signing key, then you know
that the revocation date is REV<"NOW", because the included revocation
date is not properly authenticated. Your software is not able to decide,
whether the certificate was valid at T.  Otherwise, the certificate
validation at T="NOW" would be still fine. Therefore, this handling is
appropriate at least for those communities that set T="NOW". More
sophisticated certificate validation (i.e. T<"NOW") requires additional
certificate and revocation management.

I think that the handling you described should be allowed. But, I am not
sure, whether it is compliant to the current PKIX drafts or not. I would
tend to say that it is not. 

[snip]
> >Regards,
> >
> >Nada
> 
>         A variation on this occurs when that same key is used in multiple
> different self-signed certificates, and only one of them is marked as
> revoked.  I personally believe that using the key this way is a bad idea,
> and hope that it never occurs, but I suppose that it's theoretically possible.
> 

I agree completely. This occurs when a CA operator wants to reuse the
CA`s private key. In my opinion, the certificate path validation
algorithm is quite clear. All certificates are invalid provided that one
of the self-signed certificates is revoked. I dislike this reuse.

-- 

Juergen


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA14605 for ietf-pkix-bks; Mon, 4 Jan 1999 08:35:40 -0800 (PST)
Received: from pluto.deh.de (pluto.deh.de [194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14601 for <[e-mail]>; Mon, 4 Jan 1999 08:35:35 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id RAA04902; Mon, 4 Jan 1999 17:36:02 +0100
Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id RAA13073; Mon, 4 Jan 1999 17:36:17 +0100
Message-ID: <[e-mail]>
Date: Mon, 04 Jan 1999 17:38:27 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Nada Kapidzic Cicovic <[e-mail]>, Al Arsenault <[e-mail]>, Peter Gutmann <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: CRL reason codes
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al, Nada, Peter,

Do you know an example, where it is necessary to allow the CRL signed
with  a key that is on the same CRL? 

I think that a well-done key update of CRL signing key may help that
this construction is avoidable. Apart from that I see the following
cases:

(1) CRL signing key compromise (see my last mail),
(2) CA change of affiliation (i. e. a certification domain changes to
another),
(3) cessation of CA operation (Al´s lab observation?)

I believe that the current PKIX drafts are quite silent about these
topics. 

Nada,
some comments in lines:
> 
> I suppose you should never "trust" a self-signed certificate in the first
> place. You should trust a CA's public key that you received in a trusted
> way and installed in your PSE.

I agree with you. But, this is a cost-intensive initialization
procedure. Please note, that a CA´s key change is desirable unless the
initialization procedure is repeated.

> 
> If the CRL was signed with the private key corresponding to your CA's
> trusted public key, then you regard all of the revocations from the CRL as
> valid (thus even the self-signed certificate is invalid, if you ever come
> to verifying it).
> 
> You may raise the question about the way of getting the trusted CA's key.
> Even if it is sent in the form of a self-signed certificate, it should not
> be tested against the latest CRL, since you should trust the source of the
> key and the means of the transportation (out-of-band).
> 
> So, in my opinion in this particular chicken-and-egg problem, the trusted
> public key is the oldest one.

Surely, this is not applied, if the CRL signing key (= root key) is
compromised. In the unlikely event of CRL signing key compromise the
validation software must be aware of fake CRLs (especially additional
CRL information). Apart from this case, I believe that the current
certificate path validation algorithm does not work well.


> 
> Regards,
> 
> Nada

> >


Juergen


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA14375 for ietf-pkix-bks; Mon, 4 Jan 1999 08:06:33 -0800 (PST)
Received: from relay.hq.tis.com ([e-mail] [192.94.214.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14371 for <[e-mail]>; Mon, 4 Jan 1999 08:06:32 -0800 (PST)
Received: by relay.hq.tis.com; id LAA05139; Mon, 4 Jan 1999 11:14:33 -0500 (EST)
Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.1) id xma005124; Mon, 4 Jan 99 11:14:19 -0500
Received: from balenson.hq.tis.com (balenson.hq.tis.com [10.33.80.11]) by clipper.hq.tis.com (8.9.1/8.9.1) with SMTP id LAA25665; Mon, 4 Jan 1999 11:02:42 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 04 Jan 1999 11:03:47 -0500
To: [e-mail]
From: "David M. Balenson" <[e-mail]>
Subject: REMINDER: Jan 6th Early Bird Deadline for NDSS '99
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_915483827==_"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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


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

S A V E   $ 7 0   O F F   R E G I S T R A T I O N   F E E ! !
R E G I S T E R   B Y   J A N U A R Y   6 ,   1 9 9 9 

THE INTERNET SOCIETY'S
1999 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
February 3-5, 1999
Catamaran Resort Hotel
San Diego, California
Program Chairs:  Steve Kent, BBN Technologies
                 Gene Tsudik, USC/Information Sciences Institute

ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss99

KEYNOTE SPEAKER: Whitfield Diffie, Sun Microsystems.  Co-author of
"Privacy on the Line: The Politics of Wiretapping and Encryption."

THIS YEAR'S TOPICS INCLUDE:
- Secure Password-Based Protocol for Downloading a Private Key
- A Real-World Analysis of Kerberos Password Security
- Secure Remote Access to an Internal Web Server
- Security and the User
- Experimenting with Shared Generation of RSA Keys
- Addressing the Problem of Undetected Signature Key Compromise
- Practical Approach to Anonymity in Large Scale Electronic Voting Schemes
- Securing the Internet's Exterior Routing Infrastructure
- Distributed Policy Management for Java 1.2
- Distributed Execution with Remote Audit
- An Algebra for Assessing Trust in Certification Chains
- A Network Security Research Agenda
- PGRIP: PNNI Global Routing Infrastructure Protection
- A Cryptographic Countermeasure Against Connection Depletion Attacks
- IPSec: Friend or Foe?

EXPANDED PRE-CONFERENCE TECHNICAL TUTORIALS:
- Principles of Network Security (Dr. Stephen T. Kent, BBN  Technologies)
- Optical Network Security (Jeff Ingle and Dr. Eric Harder, NSA)
- Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI)
- Windows NT Security (Dominique Brezinski, Secure Computing Corp.)
- Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI)
- JAVA Security (Dr. Gary McGraw, Reliable Software Technologies)
Full details and biographies at http://www.isoc.org/ndss99/technical.shtml


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



----------------------------------------------------------------------
David M. Balenson, Publicity Chair, NDSS '99
TIS Labs at Network Associates, Inc.
3060 Washington Road, Suite 100, Glenwood, MD 21738  USA
[e-mail]; 443-259-2358; fax [phone]
--=====================_915483827==_--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA14363 for ietf-pkix-bks; Mon, 4 Jan 1999 08:04:58 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14359 for <[e-mail]>; Mon, 4 Jan 1999 08:04:56 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA11032 for <[e-mail]>; Mon, 4 Jan 1999 17:05:33 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 4 Jan 1999 17:05:32 +0100 (MET)
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 RAA15490 for <[e-mail]>; Mon, 4 Jan 1999 17:05:32 +0100
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id RAA06535 for [e-mail]; Mon, 4 Jan 1999 17:05:31 +0100
Date: Mon, 4 Jan 1999 17:05:31 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: finding services : DCS, OCSP, Timestamping, ..
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

happy new year

The current texts of DCS, OCSP, Timestaping do not specify how one can
find the actual service. It seems useful to me to use some
certificate extension.

The service operate (or can operate) in 'signed' environments, thus
a client has some knowledge of the public key of the service;
there are some chances that this knowledge comes from a certificate. 
On the other hand the actual method of getting the service, 
http, ftp, xyz, and the addresses is not known. It seems 
logical to me to put extensions conforming to

pkix part 1: 4.2.2.1  Authority Information Access

into the certificate that describes the access point and method to
that service. 



Peter Sylvester


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA13987 for ietf-pkix-bks; Mon, 4 Jan 1999 07:14:59 -0800 (PST)
Received: from pluto.deh.de ([194.162.233.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA13983 for <[e-mail]>; Mon, 4 Jan 1999 07:14:54 -0800 (PST)
Received: from chappi.deh.de (chappi.deh.de [194.162.234.60]) by pluto.deh.de (8.9.1a/8.9.1) with ESMTP id QAA31361; Mon, 4 Jan 1999 16:14:56 +0100
Received: from deh.de (juergen.deh.de [194.162.234.54]) by chappi.deh.de (8.9.0/8.9.0) with ESMTP id QAA12776; Mon, 4 Jan 1999 16:15:09 +0100
Message-ID: <[e-mail]>
Date: Mon, 04 Jan 1999 16:17:19 +0100
From: Juergen Walter <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], Peter Gutmann <[e-mail]>, ietf-pkix <[e-mail]>
Subject: Re: CRL reason codes
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al, Peter,

I have scanned the current drafts. The result is the same that Al has
already found in the lab. I refer to the variable T in the certificate
path validation chapter of the current draft. T is not specified. T is
an arbitrary date in the past:

[PKIX] "(d)  the time, T, for which the validity of the path should be
      determined.  (This may be the current date/time, or some point in
      the past.)" [PKIX]

Hence, the certiifcate path validation algorithm is not well-defined.
Actually, it depends on T. This may explain  Al´s observations. Two
additional requirements would solve the problem:
(1) CRL signing certificate _must_ be valid at least until _nextUpdate_,
and
(2) in the unlikely event that the CRL signing key is compromised the
CRL _must_ be reissued and _must_ signed with a key that certificate is
valid at least until _nextUpdate_ of the reissued CRL.
I do not know whether these requirements are (implicitly) contained in
the current drafts or not. If they are, the remaining lines may be
skipped.  

I assume that the CRL may be signed with a key that is present at the
signed CRL in the following.

Another issue is the authentication of CRLs. This depends on the key
usage on the one side and on CRL content on the other side. Al and Peter
has considered the case that the CA root key is used for both signing
certificates and signing CRLs. But a different key usage is still
allowed. Secondly, the CRL may contain _revocationDate_,
_invalidityDate_, _reasonCode_, ... information. So, the
_revocationReason_ of the root certificate comes into question.

I would like to give the following (extremal) example. The CA signs its
own CRL applying the CA´s private key. In the unlikely event that the
CA´s private key is compromised disaster handling consists of publishing
a CRL including an revocation entry for its own root key. When an
application verifies the validity of a certificate signed with the
compromised CA´s key the result must be "invalid". This result must be
independent whether this certificate is present at the issued CRL or
not. In addition, the _revocationDate_ and other information usually
provided by CRL is not authenticated. The application knows only the
latest date of revocation in this case, i. e. the date, when the CRL was
retrieved. Furthermore, the application must be aware of fake CRLs. An
attacker may issue a CRL without root certificate entry.

Other reasons of revocation result in several scenarios. They differ in
the amount of available information authenticated by the issued CRL.

I think that the revocation of the CRL signing key is a matter of
disaster management and bussiness continuity planning, respectively.
These topics should be covered by the PKIX drafts such that the error
situation described by Al no longer appears.

Juergen

[e-mail] wrote:
> 
> Peter:
> 
> You asked:
> 
> Another question about CRL's, what happens when a CA with a self-signed cert
> revokes its own cert?  Is the cert regarded as valid for the purposes of
> authenticating the CRL, but invalid a few microseconds later once its
> revocation is read from the CRL?
> 
> Gee, when I asked that same question about 3 weeks ago on this same list, all I got was deafening silence.
> 
> As I noted in my posting on this topic, I've seen a CA revoke its own self-signed cert in the lab on two occasions.  Some of the end-entity applications accepted the CRL as valid, and then revoked the cert;  some rejected the CRL as invalid (it was signed with a revoked certificate); and some of the applications just died.
> 
> I'm still interested in any consensus on what's "supposed" to happen in this case.
> 
>                     Al Arsenault
> 

Juergen


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA13404 for ietf-pkix-bks; Mon, 4 Jan 1999 05:37:39 -0800 (PST)
Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA13399 for <[e-mail]>; Mon, 4 Jan 1999 05:37:37 -0800 (PST)
Received: from xedia.com by relay7.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfwsc28362; Mon, 4 Jan 1999 08:37:06 -0500 (EST)
Received: from aruba by xedia.com (4.1/SMI-4.1) id AA03781; Mon, 4 Jan 99 08:34:11 EST
Message-Id: <[e-mail]>
Date: Mon, 04 Jan 1999 08:37:04 -0500
From: Eric Bomarsi <[e-mail]>
Organization: xedia.com
X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
Mime-Version: 1.0
To: Andrew Probert <[e-mail]>
Cc: [e-mail]
Subject: Re: Cert Rqsts and Key Pairs
References: <C13ABC20EDDAD111B29E0000B456EABC0A6275@SPRINGFIELD>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks Andrew,

A few people have pointed out the need for multiple cert requests
to use the same keypair, so it's clear that the keypair and cert request
tables need to be separate.

RE: I'd be interested to hear the context in which you would use a PKIX
MIB?

The PKI MIB I'm working on is for a VPN Gateway, but could be used for
any networking device which supported PKI.  It currently supports keypair
and cert request generation, loading self and static certificates into the
device,
and a certificate table to manage all certs (self, static, dynamic) in the
local
database.  I plan to add support for CRLs and LDAP client config soon.

/Eric Bomarsi

Andrew Probert wrote:

> I have used multiple certs for the same keypaire, where the device was a
> Web server, having multiple SSL ports e.g. www1a.site.com,
> www1b.site.com, www1c.site.com.  These were virtual IP mapped onto
> differing services on the server.
>
> But the hardware crypto engine behind the scenes used the same keys, no
> matter which virtual / logical server was used.  This simplified key
> management on the SSL server and especially in the hardware crypto.
>
> I'd be interested to hear the context in which you would use a PKIX MIB?
>
> Regards.
>
> Andew Probert
> Rotek Consulting   http://www.rotek.com.au
> a Division of Secure Network Services
> Tel  [phone]
> Fax [phone]
>
> > -----Original Message-----
> > From: Eric Bomarsi [SMTP:[e-mail]]
> > Sent: Thursday, December 31, 1998 5:57 AM
> > To:   [e-mail]
> > Subject:      Cert Rqsts and Key Pairs
> >
> >
> > Is there any practical reason why a network device would
> > need to generate multiple certificate requests each including
> > the same public/private key pair?  Maybe for some reason
> > two cert rqsts would include the same key pair, but have
> > different distinguished names or extensions?
> >
> > I am writing a PKI MIB and need to determine the best way
> > for a pkiCertRqstEntry to reference a public/private key-pair:
> >
> > 1) include keypair info (algorithm and length) in pkiCertRqstEntry
> > such that the keypair is created along with the pkiCertRqstEntry.
> > This would limit the key-pair use to the single pkiCertRqstEntry.
> >
> > 2) create a separate pkiKeyPairTable where pkiKeyPairEntries
> > are referenced by pkiCertRqstEntries:
> >
> > 2a) If always 1 pkiCertRqstEntry to 1 pkiKeyPairEntry, then
> > I can use the same index for both tables.
> >
> > 2b) Otherwise (n pkiCertRqstEntries to 1 pkiKeyPairEntry)
> > a different index for the pkiCertRqstTable is necessary.
> >
> > Thanks in advance,
> > Eric Bomarsi
> >



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA13267 for ietf-pkix-bks; Mon, 4 Jan 1999 05:15:45 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA13263 for <[e-mail]>; Mon, 4 Jan 1999 05:15:44 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id IAA31460; Mon, 4 Jan 1999 08:15:53 -0500
Message-Id: <4.1.19990104075715.00a87180@209.172.119.123>
X-Sender: aarsenault#207.212.34.30@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 04 Jan 1999 08:11:38 -0500
To: Nada Kapidzic Cicovic <[e-mail]>, [e-mail] (Peter Gutmann), [e-mail]
From: Al Arsenault <[e-mail]>
Subject: Re: CRL reason codes
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nada,

	I'm a little unclear as to your logic here.

At 11:59 AM 1/4/99 +0100, Nada Kapidzic Cicovic wrote:
><snip>
>
>I suppose you should never "trust" a self-signed certificate in the first
>place. You should trust a CA's public key that you received in a trusted
>way and installed in your PSE.
>

	That's basically the scenario I'm talking about.  I have obtained through
out of band methods the public key of a CA that I trust.  (Maybe it came on
a tamper-resistant hardware token; maybe I got it by physically going to
the CA workstation and copying it onto a floppy disk, which I hand carried
back; maybe I used some other means to get it.) That public key is also
contained in that CA's self-signed certificate.

	Then, the certificate containing the public key is listed on a CRL.  If it
makes a difference, the reason code can be "key compromise"; i.e., we
believe that the private key corresponding to the "trusted" public key has
been compromised.

	So - a certificate containing the key I trust has now been declared to be
revoked.  The declaration comes in a CRL, signed with the very private key
that is now declared to be compromised. Do I believe it?

>If the CRL was signed with the private key corresponding to your CA's
>trusted public key, then you regard all of the revocations from the CRL as
>valid (thus even the self-signed certificate is invalid, if you ever come
>to verifying it).
>

	Personally, that's my preference.  I believe that if a certificate
containing a public key is revoked, and the revocation notice (e.g., the
CRL) is signed with the  private key matching that public key, then the
revocation notice should be treated as valid, and the certificate only
marked revoked AFTER the revocation notice is processed.  I'm interested in
other people's opinions, though.

>You may raise the question about the way of getting the trusted CA's key.
>Even if it is sent in the form of a self-signed certificate, it should not
>be tested against the latest CRL, since you should trust the source of the
>key and the means of the transportation (out-of-band).
>

	I think I disagree with this, although I'm not sure that I understand your
point.  If I get a new "trusted" key, I should check its revocation status
before each use.  Yes, self-signed keys should rarely if ever be revoked,
but it might happen.  (It reminds me of the old doctor joke:  "Doctor, it
hurts when I do this."  "Well, don't do that."  If it hurts when you revoke
your own self-signed certificate, in general you shouldn't do it.  But
there might be a reason - the CA's private key might really have been
compromised.)

>So, in my opinion in this particular chicken-and-egg problem, the trusted
>public key is the oldest one.
>
	And if that oldest trusted public key has been compromised...?

>Regards,
>
>Nada

	A variation on this occurs when that same key is used in multiple
different self-signed certificates, and only one of them is marked as
revoked.  I personally believe that using the key this way is a bad idea,
and hope that it never occurs, but I suppose that it's theoretically possible.


						Al Arsenault

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA10476 for ietf-pkix-bks; Mon, 4 Jan 1999 02:59:55 -0800 (PST)
Received: from marcellus.cost.se (marcellus.cost.se [195.100.88.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA10472 for <[e-mail]>; Mon, 4 Jan 1999 02:59:54 -0800 (PST)
Received: from jimmie ([10.0.0.22]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id LAA11359; Mon, 4 Jan 1999 11:58:25 +0100 (MET)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 04 Jan 1999 11:59:45 +0100
To: [e-mail], [e-mail] (Peter Gutmann), [e-mail]
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: Re: CRL reason codes
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:12 1/2/99, [e-mail] wrote:
>Peter:
>
>You asked:
> 
>Another question about CRL's, what happens when a CA with a self-signed cert 
>revokes its own cert?  Is the cert regarded as valid for the purposes of 
>authenticating the CRL, but invalid a few microseconds later once its 
>revocation is read from the CRL?  
> 
>Gee, when I asked that same question about 3 weeks ago on this same list,
all I got was deafening silence. 
>
>As I noted in my posting on this topic, I've seen a CA revoke its own
self-signed cert in the lab on two occasions.  Some of the end-entity
applications accepted the CRL as valid, and then revoked the cert;  some
rejected the CRL as invalid (it was signed with a revoked certificate); and
some of the applications just died.
>
>I'm still interested in any consensus on what's "supposed" to happen in
this case.

I suppose you should never "trust" a self-signed certificate in the first
place. You should trust a CA's public key that you received in a trusted
way and installed in your PSE.

If the CRL was signed with the private key corresponding to your CA's
trusted public key, then you regard all of the revocations from the CRL as
valid (thus even the self-signed certificate is invalid, if you ever come
to verifying it).

You may raise the question about the way of getting the trusted CA's key.
Even if it is sent in the form of a self-signed certificate, it should not
be tested against the latest CRL, since you should trust the source of the
key and the means of the transportation (out-of-band).

So, in my opinion in this particular chicken-and-egg problem, the trusted
public key is the oldest one.

Regards,

Nada

>
>                    Al Arsenault
>
>-- my own opinions; not representing those of my employer or any other
organization; etc. etc.  Oh, and Happy New Year, too!
>
>
> 
>
>
>
>
>
>
>---------------------------------------------------------------------
>This message has been posted from Mail2Web (http://www.mail2web.com/)
>---------------------------------------------------------------------
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA07943 for ietf-pkix-bks; Sun, 3 Jan 1999 20:39:40 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA07939; Sun, 3 Jan 1999 20:39:39 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 03 Jan 1999 20:34:22 -0800
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Wassenaar Agreement
In-Reply-To: <H0001289101d731d@MHS>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Have anybody/organization has ever evaluate the 
>impact of the Wassenaar Arrangement in Dec 1998
>about the dual use regulation on the global PKI 
>market and whether this will cause a new barrier 
>to the export of strong cryptographic technology 
>from other non-us countries.

I believe that neither the ietf-smime mailing list nor the ietf-pkix
mailing lists is an appropriate place to discuss this. There are plenty of
other discussion lists on which the Wassenaar Arrangement and its effects
are being debated.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA01219 for ietf-pkix-bks; Sun, 3 Jan 1999 19:29:09 -0800 (PST)
Received: from zeus.planetworld.com (smtp.planetworld.com [38.234.12.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA01212; Sun, 3 Jan 1999 19:29:07 -0800 (PST)
Received: by smtp.planetworld.com with Internet Mail Service (5.5.2232.9) id <C2MLGD2D>; Sun, 3 Jan 1999 21:31:27 -0600
Message-ID: <[e-mail]>
From: Bill Brice <[e-mail]>
To: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: Impact of US Export Regulation changes on WG documents
Date: Sun, 3 Jan 1999 21:31:26 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Not at all. There may be no impact. My posting is
simply in response to many debates I've seen fly by
on algorithm support. I'm merely suggesting that the
technologists see if this has any impact. 
If there is none, then great.

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]]
Sent: Sunday, January 03, 1999 7:57 PM
To: [e-mail]; [e-mail]
Subject: Re: Impact of US Export Regulation changes on WG documents


At 07:46 PM 1/3/99 -0600, Bill Brice wrote:
>My purpose in bringing this to the attention of these
>lists it that many of the Work Group documents are in
>last call or near completion. The appropriate authors
>should consider whether the changes made by the BXA
>might impact these documents.

Could you be a bit more explicit? What do you mean by "impact"? I hope you
are not suggesting that we break backwards compatibility with S/MIME v2 by
substituting one weak algorithm for another.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA27166 for ietf-pkix-bks; Sun, 3 Jan 1999 18:51:42 -0800 (PST)
Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA27162; Sun, 3 Jan 1999 18:51:37 -0800 (PST)
From: [e-mail]
Received: from hkmail.hkg.hp.com ([e-mail] [15.19.68.29]) by palrel3.hp.com (8.8.6 (PHNE_14041)/8.8.5tis) with ESMTP id SAA23205; Sun, 3 Jan 1999 18:52:14 -0800 (PST)
Received: from localhost (root@localhost) by hkmail.hkg.hp.com with SMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0 Openmail) id KAA13015; Mon, 4 Jan 1999 10:51:57 +0800 (HKG)
X-OpenMail-Hops: 1
Date: Mon, 4 Jan 1999 10:51:49 +0800
Message-Id: <H0001289101d731d@MHS>
Subject: Wassenaar Agreement
MIME-Version: 1.0
TO: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset=US-ASCII; name="Wassenaar"
Content-Disposition: inline; filename="Wassenaar"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello all,

Have anybody/organization has ever evaluate the 
impact of the Wassenaar Arrangement in Dec 1998
about the dual use regulation on the global PKI 
market and whether this will cause a new barrier 
to the export of strong cryptographic technology 
from other non-us countries.

In the past, non-US countries company like Ireland 
Balimore can export strong crypto.  Will it be
changed after the signing of the Wassenaar 
Arrangement.

Best REegards,
Esmond TONG



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA26764 for ietf-pkix-bks; Sun, 3 Jan 1999 18:02:10 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA26760; Sun, 3 Jan 1999 18:02:08 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 03 Jan 1999 17:57:09 -0800
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Impact of US Export Regulation changes on WG documents
In-Reply-To: <[e-mail] m>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 07:46 PM 1/3/99 -0600, Bill Brice wrote:
>My purpose in bringing this to the attention of these
>lists it that many of the Work Group documents are in
>last call or near completion. The appropriate authors
>should consider whether the changes made by the BXA
>might impact these documents.

Could you be a bit more explicit? What do you mean by "impact"? I hope you
are not suggesting that we break backwards compatibility with S/MIME v2 by
substituting one weak algorithm for another.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26570 for ietf-pkix-bks; Sun, 3 Jan 1999 17:44:21 -0800 (PST)
Received: from zeus.planetworld.com (smtp.planetworld.com [38.234.12.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26566; Sun, 3 Jan 1999 17:44:20 -0800 (PST)
Received: by smtp.planetworld.com with Internet Mail Service (5.5.2232.9) id <YPFWKJYB>; Sun, 3 Jan 1999 19:46:38 -0600
Message-ID: <[e-mail]>
From: Bill Brice <[e-mail]>
To: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Impact of US Export Regulation changes on WG documents
Date: Sun, 3 Jan 1999 19:46:30 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PKIX and S/MIME lists:

On Thursday, December 31 the US Department of Commerce,
Bureau of Export Administration published it's awaited
revised regulations on the export of Encryption Items.

My purpose in bringing this to the attention of these
lists it that many of the Work Group documents are in
last call or near completion. The appropriate authors
should consider whether the changes made by the BXA
might impact these documents.

The most significant change is that the allowable key
lengths have been increased for export grade software.
Previously, symmetric confidentiality ciphers were limited
to 40-bits and asymmetric ciphers (such as RSA) used for
key exchange were limited to 512 bits. 

The new regulations permit the following key lengths for
export:
Symmetric confidentiality algorithms RC2, RC4, RC5, DES
and CAST: 56-bits
Symmetric key exchange ciphers: 112 bits
Asymmetric key exchange ciphers: 1024 bits

This has the effect of permitting the export versions of
such products as Microsoft Internet Explorer (CryptoAPI)
and Netscape Communicator (PKCS#11) to, by default, use
56-bit DES and 1024-bit RSA.

For certificate authorities, this has the impact of permitting
browser based enrollment controls (Xenroll or KeyGen) to
default to 1024-bit RSA worldwide (except the 7 bad countries).

Between now and March 31, 1999 any manufacturer of encryption
software may upgrade their export versions to the new bit
levels by merely sending notice to the BXA. I'd like for
Microsoft and Netscape to comment as to how quickly they
expect to have crypto upgrades available for release.

The relevant BXA link for the complete text is:
http://www.bxa.doc.gov/Encryption/1231ERC.htm or
http://www.bxa.doc.gov/PDF/1231ERC.pdf

The relevant text covering mass-market software is quoted in
the postscript.

-Bill Brice, CEO
 AlphaTrust Corp.

Postscript:
    (iv) Mass-market encryption software that has already been 
classified after a technical review and that has been released from EI 
controls under the provisions of this paragraph (b)(1) will be 
permitted for export and reexport under license exception TSU with 
increases of 56-bits for the confidentiality algorithm, the same or 
double the key length authorized for the confidentiality algorithm for
symmetric
algorithms for key exchange mechanisms and with key spaces of 512, 768 
or up to and including 1024 bits for asymmetric algorithms for key 
exchange without an additional technical review, provided that there is 
no other change in the cryptographic functionality. Exporters must 
notify BXA in writing of the increase in the key length for the 
confidentiality algorithm, the asymmetric or symmetric key exchange 
algorithms, and include the original authorization number issued by BXA 
and the information identified in paragraphs (a)(2)(iii) through (v) of 
Supplement No. 6 to part 742 of the EAR (if this information was 
submitted previously, then only identify the modifications). BXA must 
receive such notification by March 31, 1999.
    (A) The notification should be sent to:
Office of Strategic Trade and Foreign Policy Controls, Bureau of 
Export Administration, Department of Commerce, 14th Street and 
Pennsylvania Ave., N.W., Room 2705, Washington, D.C. 20230, Attn: 
Encryption Upgrade    (B) A copy of the certification should be sent to:
Attn: ENC Encryption Request Coordinator, P.O. Box 246, Annapolis 
Junction, MD 20701-0246

End Postscript.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25161 for ietf-pkix-bks; Sun, 3 Jan 1999 14:25:16 -0800 (PST)
Received: from springfield.SIMPSONS (rotek1.lnk.telstra.net [139.130.48.58]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25157 for <[e-mail]>; Sun, 3 Jan 1999 14:25:14 -0800 (PST)
Received: by SPRINGFIELD with Internet Mail Service (5.5.1960.3) id <ZD6GM0FW>; Mon, 4 Jan 1999 09:24:03 +1100
Message-ID: <C13ABC20EDDAD111B29E0000B456EABC0A6275@SPRINGFIELD>
From: Andrew Probert <[e-mail]>
To: "'Eric Bomarsi'" <[e-mail]>, [e-mail]
Subject: RE: Cert Rqsts and Key Pairs
Date: Mon, 4 Jan 1999 09:24:02 +1100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have used multiple certs for the same keypaire, where the device was a
Web server, having multiple SSL ports e.g. www1a.site.com,
www1b.site.com, www1c.site.com.  These were virtual IP mapped onto
differing services on the server.

But the hardware crypto engine behind the scenes used the same keys, no
matter which virtual / logical server was used.  This simplified key
management on the SSL server and especially in the hardware crypto.

I'd be interested to hear the context in which you would use a PKIX MIB?

Regards.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Services
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Eric Bomarsi [SMTP:[e-mail]]
> Sent:	Thursday, December 31, 1998 5:57 AM
> To:	[e-mail]
> Subject:	Cert Rqsts and Key Pairs
> 
> 
> Is there any practical reason why a network device would
> need to generate multiple certificate requests each including
> the same public/private key pair?  Maybe for some reason
> two cert rqsts would include the same key pair, but have
> different distinguished names or extensions?
> 
> I am writing a PKI MIB and need to determine the best way
> for a pkiCertRqstEntry to reference a public/private key-pair:
> 
> 1) include keypair info (algorithm and length) in pkiCertRqstEntry
> such that the keypair is created along with the pkiCertRqstEntry.
> This would limit the key-pair use to the single pkiCertRqstEntry.
> 
> 2) create a separate pkiKeyPairTable where pkiKeyPairEntries
> are referenced by pkiCertRqstEntries:
> 
> 2a) If always 1 pkiCertRqstEntry to 1 pkiKeyPairEntry, then
> I can use the same index for both tables.
> 
> 2b) Otherwise (n pkiCertRqstEntries to 1 pkiKeyPairEntry)
> a different index for the pkiCertRqstTable is necessary.
> 
> Thanks in advance,
> Eric Bomarsi
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24085 for ietf-pkix-bks; Sat, 2 Jan 1999 09:15:49 -0800 (PST)
Received: from mail.softcomca.com (softcomca.com [168.144.1.9]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA24081 for <[e-mail]>; Sat, 2 Jan 1999 09:15:48 -0800 (PST)
From: [e-mail]
Message-Id: <[e-mail]>
Received: from phantom [168.144.1.30] by mail.softcomca.com (SMTPD32-4.07) id A37B11F0140; Sat, 02 Jan 1999 12:12:27 EDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: [e-mail] (Peter Gutmann), [e-mail]
Subject: Re: CRL reason codes
Date: Sat, 02 Jan 1999 12:12:19
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

You asked:
 
Another question about CRL's, what happens when a CA with a self-signed cert 
revokes its own cert?  Is the cert regarded as valid for the purposes of 
authenticating the CRL, but invalid a few microseconds later once its 
revocation is read from the CRL?  
 
Gee, when I asked that same question about 3 weeks ago on this same list, all I got was deafening silence. 

As I noted in my posting on this topic, I've seen a CA revoke its own self-signed cert in the lab on two occasions.  Some of the end-entity applications accepted the CRL as valid, and then revoked the cert;  some rejected the CRL as invalid (it was signed with a revoked certificate); and some of the applications just died.

I'm still interested in any consensus on what's "supposed" to happen in this case.

                    Al Arsenault

-- my own opinions; not representing those of my employer or any other organization; etc. etc.  Oh, and Happy New Year, too!


 






---------------------------------------------------------------------
This message has been posted from Mail2Web (http://www.mail2web.com/)
---------------------------------------------------------------------



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23889 for ietf-pkix-bks; Sat, 2 Jan 1999 08:22:27 -0800 (PST)
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 IAA23883 for <[e-mail]>; Sat, 2 Jan 1999 08:22:24 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id FAA31355 for <[e-mail]>; Sun, 3 Jan 1999 05:22:49 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91529416913470>; Sun, 3 Jan 1999 05:22:49 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: CRL reason codes
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sun, 3 Jan 1999 05:22:49 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

While I was playing with CRL's today I found a somewhat annoying problem in 
the way the CRL reasons are defined: In two different locations they're 
defined as either an enumerated type (CRLReason) or a bit string 
(ReasonFlags).  What this means is that a name like 'affiliationChanged' can 
be associated with the value 8 for a ReasonFlag but 3 for a CRLReason.  This 
makes it a real pain for programmers because even with fascist range checking 
in the code it's quite possible to pass in a ReasonFlags keyCompromise where a 
function is expecting a CRLReason keyCompromise (you just end up with a 
'superseded' instead).  I can't think of any easy solution for this, but 
perhaps changing the ReasonFlags names so they end in 'Flag' (eg 
affiliationChanged vs affiliationChangedFlag) would help a bit.
 
Another question about CRL's, what happens when a CA with a self-signed cert 
revokes its own cert?  Is the cert regarded as valid for the purposes of 
authenticating the CRL, but invalid a few microseconds later once its 
revocation is read from the CRL?  
 
Peter.