RE: Attribute used to store cached certificate chains?
Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> Mon, 01 February 1999 03:52 UTC
Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA09166 for <pkix-archive@odin.ietf.org>; Sun, 31 Jan 1999 22:52:25 -0500 (EST)
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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au>
To: 'Andrew Probert' <AndrewP@rotek.com.au>, 'WHenry' <WHenry@pec.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Cc: "'digsig-arch@onelist.com'" <digsig-arch@onelist.com>
Subject: RE: Attribute used to store cached certificate chains?
Date: Mon, 01 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: owner-ietf-pkix@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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'; 'ietf-pkix@imc.org' > Cc: 'digsig-arch@onelist.com' > 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 +61 3 9690 8877 > Fax +61 3 9690 8171 > > > > > -----Original Message----- > > From: WHenry [SMTP:WHenry@pec.com] > > Sent: Saturday, January 30, 1999 1:24 AM > > To: 'ietf-pkix@imc.org' > > Cc: 'digsig-arch@onelist.com' > > 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:TCARTER@novell.com] > > Sent: Thursday, January 28, 1999 7:09 PM > > To: ietf-pkix@imc.org; Alan.Lloyd@OpenDirectory.com.au; > > AndrewP@rotek.com.au > > 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 > > tcarter@novell.com > > > > > > >>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 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 <ietf-pkix@imc.org>; 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: <36B5508F.32E3FAFF@ubs.com> Date: Mon, 01 Feb 1999 07:58:24 +0100 From: Markus Bitterli <markus.bitterli@ubs.com> X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ambarish@valicert.com CC: Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: RE: OCSP and historical data References: <00ec01be4bbb$065b5910$6500000a@rhone.valicert.com> Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 ambarish@valicert.com 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. ambarish@valicert.com > 1215 Terra Bella Ave. http://www.valicert.com > Mountain View, CA 94043-1833 > > > -----Original Message----- > > From: owner-ietf-pkix@imc.org > > [mailto:owner-ietf-pkix@imc.org]On Behalf > > Of Denis Pinkas > > Sent: Friday, January 29, 1999 2:26 AM > > To: Markus Bitterli > > Cc: ietf-pkix@imc.org > > 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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> To: "'Andrew Probert'" <AndrewP@rotek.com.au>, "'Stephen Kent'" <kent@bbn.com> Cc: ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: ietf-pkix@imc.org > 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 +61 3 9690 8877 > Fax +61 3 9690 8171 > > > > > -----Original Message----- > > From: Alan Lloyd [SMTP:Alan.Lloyd@OpenDirectory.com.au] > > Sent: Monday, February 01, 1999 9:12 AM > > To: 'Stephen Kent' > > Cc: ietf-pkix@imc.org > > 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'; ietf-pkix@imc.org > > > 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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> To: "'Andrew Probert'" <AndrewP@rotek.com.au>, "'WHenry'" <WHenry@pec.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Cc: "'digsig-arch@onelist.com'" <digsig-arch@onelist.com> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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'; 'ietf-pkix@imc.org' > Cc: 'digsig-arch@onelist.com' > 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 +61 3 9690 8877 > Fax +61 3 9690 8171 > > > > > -----Original Message----- > > From: WHenry [SMTP:WHenry@pec.com] > > Sent: Saturday, January 30, 1999 1:24 AM > > To: 'ietf-pkix@imc.org' > > Cc: 'digsig-arch@onelist.com' > > 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:TCARTER@novell.com] > > Sent: Thursday, January 28, 1999 7:09 PM > > To: ietf-pkix@imc.org; Alan.Lloyd@OpenDirectory.com.au; > > AndrewP@rotek.com.au > > 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 > > tcarter@novell.com > > > > > > >>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 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 <ietf-pkix@imc.org>; 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 <AndrewP@rotek.com.au> To: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, "'Stephen Kent'" <kent@bbn.com> Cc: ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 +61 3 9690 8877 Fax +61 3 9690 8171 > -----Original Message----- > From: Alan Lloyd [SMTP:Alan.Lloyd@OpenDirectory.com.au] > Sent: Monday, February 01, 1999 9:12 AM > To: 'Stephen Kent' > Cc: ietf-pkix@imc.org > 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'; ietf-pkix@imc.org > > 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 <ietf-pkix@imc.org>; 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 <AndrewP@rotek.com.au> To: "'WHenry'" <WHenry@pec.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Cc: "'digsig-arch@onelist.com'" <digsig-arch@onelist.com> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 +61 3 9690 8877 Fax +61 3 9690 8171 > -----Original Message----- > From: WHenry [SMTP:WHenry@pec.com] > Sent: Saturday, January 30, 1999 1:24 AM > To: 'ietf-pkix@imc.org' > Cc: 'digsig-arch@onelist.com' > 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:TCARTER@novell.com] > Sent: Thursday, January 28, 1999 7:09 PM > To: ietf-pkix@imc.org; Alan.Lloyd@OpenDirectory.com.au; > AndrewP@rotek.com.au > 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 > tcarter@novell.com > > > >>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> To: "'Stephen Kent'" <kent@bbn.com> Cc: ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > -----Original Message----- > From: Stephen Kent > Sent: Sunday, January 31, 1999 7:16 AM > To: Alan Lloyd > Cc: 'Stephen Kent'; ietf-pkix@imc.org > 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 (root@irwell.zetnet.co.uk [194.247.47.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19036 for <ietf-pkix@imc.org>; 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: <199901302135.VAA08952@irwell.zetnet.co.uk> From: "David Chadwick" <d.w.chadwick@iti.salford.ac.uk> Organization: University of Salford To: Bill Burr <william.burr@nist.gov>, ietf-pkix <ietf-pkix@imc.org>, Al Arsenault <aarsenault@spyrus.com> 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: d.w.chadwick@iti.salford.ac.uk In-reply-to: <4.1.19990128085211.00aa0b50@209.172.119.123> References: <36B06462.6D9489FE@deh.de> X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> From: Al Arsenault <aarsenault@spyrus.com> 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 +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 370 957 287 Email D.W.Chadwick@iti.salford.ac.uk 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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> From: Stephen Kent <kent@bbn.com> Subject: RE: finding services : DCS, OCSP, Timestamping, .. Cc: "'Stephen Kent'" <kent@bbn.com>, ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> From: Stephen Kent <kent@bbn.com> Subject: RE: Attribute used to store cached certificate chains? Cc: <ietf-pkix@imc.org> Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <s6af421e.083@prv-mail20.provo.novell.com> Date: Fri, 29 Jan 1999 17:56:33 -0500 To: "Tammy Carter" <TCARTER@novell.com> From: Stephen Kent <kent@bbn.com> Subject: RE: Attribute used to store cached certificate chains? Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <WFord@verisign.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:WFord@verisign.com] 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:aarsenault@spyrus.com] > Sent: Thursday, January 28, 1999 6:04 AM > To: Juergen.Walter@deh.de; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Fri, 29 Jan 1999 13:33:59 -0800 Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Sender: cynthia@mail.surfnetusa.com Message-Id: <v04011702b2d7da8476ff@[208.201.152.17]> Date: Fri, 29 Jan 1999 13:37:44 -0800 To: cynthia@usenix.org From: Cynthia Deno <cynthia@surfnetusa.com> Subject: USENIX NETWORKING '99 Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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" <ambarish@valicert.com> To: "'Denis Pinkas'" <Denis.Pinkas@bull.net>, "'Markus Bitterli'" <markus.bitterli@ubs.com> Cc: <ietf-pkix@imc.org> Subject: RE: OCSP and historical data Date: Fri, 29 Jan 1999 11:10:24 -0800 Message-ID: <00ec01be4bbb$065b5910$6500000a@rhone.valicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <36B18CB0.11037C5F@bull.net> Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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. ambarish@valicert.com 1215 Terra Bella Ave. http://www.valicert.com Mountain View, CA 94043-1833 > -----Original Message----- > From: owner-ietf-pkix@imc.org > [mailto:owner-ietf-pkix@imc.org]On Behalf > Of Denis Pinkas > Sent: Friday, January 29, 1999 2:26 AM > To: Markus Bitterli > Cc: ietf-pkix@imc.org > 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 <ietf-pkix@imc.org>; 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: <s6b1a27f.094@prv-mail20.provo.novell.com> X-Mailer: Novell GroupWise 5.5 Date: Fri, 29 Jan 1999 11:58:47 -0700 From: "Tammy Carter" <TCARTER@novell.com> To: <ietf-pkix@imc.org>, <Alan.Lloyd@OpenDirectory.com.au>, <AndrewP@rotek.com.au> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 tcarter@novell.com >>> Andrew Probert <AndrewP@rotek.com.au> 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 +61 3 9690 8877 Fax +61 3 9690 8171 > -----Original Message----- > From: Tammy Carter [SMTP:TCARTER@novell.com] > Sent: Friday, January 29, 1999 11:09 AM > To: ietf-pkix@imc.org; Alan.Lloyd@OpenDirectory.com.au; > AndrewP@rotek.com.au > 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 > tcarter@novell.com > > > >>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 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 <ietf-pkix@imc.org>; Fri, 29 Jan 1999 10:47:44 -0800 (PST) Message-Id: <199901291847.KAA14928@mail.proper.com> 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" <paul@mactivity.com> To: ietf-pkix@imc.org Mime-version: 1.0 X-Priority: 3 Content-type: multipart/alternative; boundary="MS_Mac_OE_3000451866_540457_MIME_Part" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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> 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 & Founder, Network Flight Recorder= , <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 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 & 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 Network Computing, the premier technolo= gy solutions<BR> magazine.<BR> <BR> Conference Sponsors include<BR> * Compatible Systems * Checkpoint Software Technologies * Ernst & 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 <ietf-pkix@imc.org>; 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: <3.0.1.32.19990129125503.009d2a30@adga.ca> X-Sender: frousseau@adga.ca X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 29 Jan 1999 12:55:03 -0500 To: WHenry <WHenry@pec.com> From: Francois Rousseau <f.rousseau@adga.ca> Subject: Re: FW: Attribute used to store cached certificate chains? Cc: ietf-pkix@imc.org, digsig-arch@onelist.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <WFord@verisign.com> To: Al Arsenault <aarsenault@spyrus.com>, ietf-pkix <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:aarsenault@spyrus.com] > Sent: Thursday, January 28, 1999 6:04 AM > To: Juergen.Walter@deh.de; 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 <ietf-pkix@imc.org>; 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 <WHenry@pec.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Cc: "'digsig-arch@onelist.com'" <digsig-arch@onelist.com> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:TCARTER@novell.com] > Sent: Thursday, January 28, 1999 7:09 PM > To: ietf-pkix@imc.org; Alan.Lloyd@OpenDirectory.com.au; > AndrewP@rotek.com.au > 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 > tcarter@novell.com > > > >>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 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"> 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"> 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"> Thoughts/comments?</FONT> </P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"> Bill = Henry</FONT> <BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"> Performance = Engineering Corporation</FONT> </P> <P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT> <BR><B><FONT SIZE=3D1 FACE=3D"Arial">From: </FONT></B> <FONT = SIZE=3D1 FACE=3D"Arial">Tammy Carter [SMTP:TCARTER@novell.com]</FONT> <BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent: </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: </FONT></B> <FONT SIZE=3D1 = FACE=3D"Arial">ietf-pkix@imc.org; Alan.Lloyd@OpenDirectory.com.au; = AndrewP@rotek.com.au</FONT> <BR><B><FONT SIZE=3D1 = FACE=3D"Arial">Subject: </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. 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.) </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. 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. Servers </FONT> <BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">are on every = continent. I have a certificate, stored on my user object. = </FONT> <BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">I travel to China = for a month of consulting in our branch office. 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. 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. 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. = 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. </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. This</FONT> <BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">allows a "free = seating policy" 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: has anyone thought of caching this</FONT> <BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">information in the = directory yet? 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">tcarter@novell.com = </FONT> </P> <BR> <P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">>>> Alan = Lloyd <Alan.Lloyd@OpenDirectory.com.au> 1-28-99 3:03:33 PM = >>></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, 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">"a = directory" 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 <ietf-pkix@imc.org>; 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: <36B18CB0.11037C5F@bull.net> Date: Fri, 29 Jan 1999 11:25:53 +0100 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: Markus Bitterli <markus.bitterli@ubs.com> CC: ietf-pkix@imc.org Subject: Re: OCSP and historical data References: <36B182F5.167E5294@ubs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <36B182F5.167E5294@ubs.com> Date: Fri, 29 Jan 1999 10:44:21 +0100 From: Markus Bitterli <markus.bitterli@ubs.com> X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: OCSP and historical data Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <36B18269.D5AE5F7@ubs.com> Date: Fri, 29 Jan 1999 10:42:01 +0100 From: Markus Bitterli <markus.bitterli@ubs.com> X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: OCSP and historical data Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <AndrewP@rotek.com.au> To: "'Tammy Carter'" <TCARTER@novell.com>, ietf-pkix@imc.org, Alan.Lloyd@OpenDirectory.com.au 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 +61 3 9690 8877 Fax +61 3 9690 8171 > -----Original Message----- > From: Tammy Carter [SMTP:TCARTER@novell.com] > Sent: Friday, January 29, 1999 11:09 AM > To: ietf-pkix@imc.org; Alan.Lloyd@OpenDirectory.com.au; > AndrewP@rotek.com.au > 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 > tcarter@novell.com > > > >>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 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 <ietf-pkix@imc.org>; 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: <s6b099ae.006@prv-mail20.provo.novell.com> X-Mailer: Novell GroupWise 5.5 Date: Thu, 28 Jan 1999 17:08:52 -0700 From: "Tammy Carter" <TCARTER@novell.com> To: <ietf-pkix@imc.org>, <Alan.Lloyd@OpenDirectory.com.au>, <AndrewP@rotek.com.au> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 tcarter@novell.com >>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 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 <ietf-pkix@imc.org>; 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 <AndrewP@rotek.com.au> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 +61 3 9690 8877 > Fax +61 3 9690 8171 > > > > -----Original Message----- > From: Tammy Carter [SMTP:TCARTER@novell.com] > Sent: Thursday, January 28, 1999 10:43 AM > To: #060#ietf-pkix@imc.org#062#; AndrewP@rotek.com.au > 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 <AndrewP@rotek.com.au> 1-27-99 3:29:53 PM >>> > > > -----Original Message----- > > From: Tammy Carter [SMTP:TCARTER@novell.com] > > Sent: Saturday, January 23, 1999 7:06 AM > > To: ietf-pkix@imc.org > > 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 > > tcarter@novell.com 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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> To: "'Tammy Carter'" <TCARTER@novell.com>, "<" <ietf-pkix@imc.org>, AndrewP@rotek.com.au 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: <; AndrewP@rotek.com.au > 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 <AndrewP@rotek.com.au> 1-27-99 3:29:53 PM >>> > > > -----Original Message----- > > From: Tammy Carter [SMTP:TCARTER@novell.com] > > Sent: Saturday, January 23, 1999 7:06 AM > > To: ietf-pkix@imc.org > > 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 > > tcarter@novell.com 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 <ietf-pkix@imc.org>; 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: <36B0A835.EC0507FE@deh.de> Date: Thu, 28 Jan 1999 19:11:01 +0100 From: Juergen Walter <Juergen.Walter@deh.de> Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Al Arsenault <aarsenault@spyrus.com>, ietf-pkix <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <36B090A3.6FCE9553@bull.net> Date: Thu, 28 Jan 1999 17:30:27 +0100 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: Juergen.Walter@deh.de CC: ietf-pkix <ietf-pkix@imc.org> Subject: Re: Terminology question: "root CA" References: <4.1.19990127140608.00aa3dd0@209.172.119.123> <36B06462.6D9489FE@deh.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <36B0864E.818C8B79@bull.net> Date: Thu, 28 Jan 1999 16:46:22 +0100 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: Al Arsenault <aarsenault@spyrus.com> CC: ietf-pkix@imc.org, turners@ieca.com 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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, Alices 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 Dorothys 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 Dorothys > 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 CAs 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 (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA29644 for <ietf-pkix@imc.org>; 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: Juergen.Walter@deh.de, Bill Burr <william.burr@nist.gov>, Brian Korver <briank@CS.Stanford.EDU>, Arnoud Galactus Engelfriet <galactus@stack.nl>, ietf-pkix <ietf-pkix@imc.org> From: Al Arsenault <aarsenault@spyrus.com> Subject: Re: Terminology question: "root CA" In-Reply-To: <36B06462.6D9489FE@deh.de> References: <4.1.19990127140608.00aa3dd0@209.172.119.123> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <36B06462.6D9489FE@deh.de> Date: Thu, 28 Jan 1999 14:21:38 +0100 From: Juergen Walter <Juergen.Walter@deh.de> Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Al Arsenault <aarsenault@spyrus.com>, Bill Burr <william.burr@nist.gov>, Brian Korver <briank@CS.Stanford.EDU>, Arnoud Galactus Engelfriet <galactus@stack.nl>, ietf-pkix <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <s6af421e.083@prv-mail20.provo.novell.com> X-Mailer: Novell GroupWise 5.5 Date: Wed, 27 Jan 1999 16:43:02 -0700 From: "Tammy Carter" <TCARTER@novell.com> To: "<"<ietf-pkix@imc.org>, <AndrewP@rotek.com.au> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <AndrewP@rotek.com.au> 1-27-99 3:29:53 PM >>> > -----Original Message----- > From: Tammy Carter [SMTP:TCARTER@novell.com] > Sent: Saturday, January 23, 1999 7:06 AM > To: ietf-pkix@imc.org > 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 > tcarter@novell.com 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 <ietf-pkix@imc.org>; 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 <AndrewP@rotek.com.au> To: "'Al Arsenault'" <aarsenault@spyrus.com>, ietf-pkix@imc.org Cc: turners@ieca.com 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 +61 3 9690 8877 Fax +61 3 9690 8171 > -----Original Message----- > From: Al Arsenault [SMTP:aarsenault@spyrus.com] > Sent: Thursday, January 28, 1999 6:14 AM > To: ietf-pkix@imc.org > Cc: turners@ieca.com > 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 <ietf-pkix@imc.org>; 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 <AndrewP@rotek.com.au> To: "'Sarbari Gupta'" <sgupta@cygnacom.com>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Juergen.Walter@deh.de Cc: ietf-pkix <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 +61 3 9690 8877 Fax +61 3 9690 8171 > -----Original Message----- > From: Sarbari Gupta [SMTP:sgupta@cygnacom.com] > Sent: Thursday, January 28, 1999 4:38 AM > To: 'Phillip M Hallam-Baker'; Juergen.Walter@deh.de > 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 > (703)848-0883 (voice) > (703)848-0960(FAX) > sgupta@cygnacom.com > ================================= > > -----Original Message----- > From: Phillip M Hallam-Baker [mailto:pbaker@verisign.com] > Sent: Wednesday, January 27, 1999 12:21 PM > To: Juergen.Walter@deh.de; 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 <ietf-pkix@imc.org>; 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 <AndrewP@rotek.com.au> To: "'Tammy Carter'" <TCARTER@novell.com>, ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Andew Probert Rotek Consulting http://www.rotek.com.au a Division of Secure Network Solutions Tel +61 3 9690 8877 Fax +61 3 9690 8171 > -----Original Message----- > From: Tammy Carter [SMTP:TCARTER@novell.com] > Sent: Saturday, January 23, 1999 7:06 AM > To: ietf-pkix@imc.org > 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 > tcarter@novell.com 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 <ietf-pkix@imc.org>; 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: <3.0.5.32.19990127172926.00ac1780@csmes.ncsl.nist.gov> X-Sender: burr@csmes.ncsl.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 27 Jan 1999 17:29:26 -0500 To: "Robert W. Shirey" <rshirey@bbn.com>, Al Arsenault <aarsenault@spyrus.com> From: Bill Burr <william.burr@nist.gov> Subject: Re: Terminology question: "root CA" Cc: ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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- rshirey@bbn.com, Phone 703-284-4641, Reception 284-4600, Fax 284-2766 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 (root@shell.tsoft.com [207.201.34.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25217 for <ietf-pkix@imc.org>; 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: <36AF89F5.5A2D4156@cs.stanford.edu> Date: Wed, 27 Jan 1999 13:49:44 -0800 From: Brian Korver <briank@CS.Stanford.EDU> Reply-To: briank@CS.Stanford.EDU X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Al Arsenault <aarsenault@spyrus.com> CC: ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: rshirey@rosslyn.bbn.com 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 <aarsenault@spyrus.com> From: "Robert W. Shirey" <rshirey@bbn.com> Subject: Re: Terminology question: "root CA" Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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- rshirey@bbn.com, Phone 703-284-4641, Reception 284-4600, Fax 284-2766 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org> id WAA15576 (SMTP). Wed, 27 Jan 1999 22:34:48 +0100 (MET) From: galactus@stack.nl (Arnoud "Galactus" Engelfriet) Newsgroups: list.ietf.pkix To: ietf-pkix@imc.org Subject: Re: Terminology question: "root CA" Date: Wed, 27 Jan 1999 22:26:54 +0100 Organization: MCGV STACK, Eindhoven, The Netherlands Message-ID: <eS4r24uYOZ8V089yn@stack.nl> References: <4.1.19990127140608.00aa3dd0@209.172.119.123> Lines: 20 Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> In article <4.1.19990127140608.00aa3dd0@209.172.119.123>, Al Arsenault <aarsenault@spyrus.com> 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 - galactus@stack.nl 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 (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22344 for <ietf-pkix@imc.org>; 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: ietf-pkix@imc.org From: Al Arsenault <aarsenault@spyrus.com> Subject: Terminology question: "root CA" Cc: turners@ieca.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <sgupta@cygnacom.com> To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Juergen.Walter@deh.de Cc: ietf-pkix <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 (703)848-0883 (voice) (703)848-0960(FAX) sgupta@cygnacom.com ================================= -----Original Message----- From: Phillip M Hallam-Baker [mailto:pbaker@verisign.com] Sent: Wednesday, January 27, 1999 12:21 PM To: Juergen.Walter@deh.de; 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 <ietf-pkix@imc.org>; 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" <pbaker@verisign.com> To: <Juergen.Walter@deh.de>, "Michael Myers" <MMyers@verisign.com>, "ietf-pkix" <ietf-pkix@imc.org> Subject: RE: OCSP & Authority Information Access Date: Wed, 27 Jan 1999 12:20:48 -0500 Message-ID: <001701be4a19$6178d820$c807a8c0@pbaker-pc.verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <36AEEBF3.7A3BF3F4@deh.de> Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA20744 for <ietf-pkix@imc.org>; 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: ietf-pkix@imc.org From: Al Arsenault <aarsenault@spyrus.com> Subject: POP section for next Roadmap draft Cc: turners@ieca.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_945425781==_.ALT" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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, Alices 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 Dorothys 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 Dorothys 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 CAs 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> </x-tab>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?<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. <br> <br> 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 =93self-inflicted denial of service=94; 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=20 important:<br> <dl> <dd>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=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: 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=92s 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=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. 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=20 include:<br> <br> <x-tab> </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. 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. <br> <br> </dl><x-tab> </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. 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.<br> <br> <dd>For key management keys that are generated by the requester, the CA can send use the requested public key, along with the CA=92s own private key, to encrypt some piece of data, and send it to the requester to be decrypted. For example, the CA can generate some random challenge, and require some action to be taken after decryption (e.g., =93decrypt this encrypted random number and send it back to me=94). If the requester does not take the requested action, the CA concludes that the requester did not possess the private key, and the certificate is not issued. <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. 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.<br> <br> <br> <br> </font> </dl>Thanks,<br> <br> <x-tab> </x-tab><x-tab> = </x-tab><x-tab> &= 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 <ietf-pkix@imc.org>; 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 <sgupta@cygnacom.com> To: "'Carlisle Adams'" <carlisle.adams@entrust.com> Cc: "PKIX (E-mail)" <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 (703)848-0883 (voice) (703)848-0960(FAX) sgupta@cygnacom.com ================================= -----Original Message----- From: Carlisle Adams [mailto:carlisle.adams@entrust.com] 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:sgupta@cygnacom.com] 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 (703)848-0883 (voice) (703)848-0960(FAX) sgupta@cygnacom.com ================================= 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 <ietf-pkix@imc.org>; 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: <36AEEBF3.7A3BF3F4@deh.de> Date: Wed, 27 Jan 1999 11:35:31 +0100 From: Juergen Walter <Juergen.Walter@deh.de> Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Myers <MMyers@verisign.com>, ietf-pkix <ietf-pkix@imc.org> Subject: Re: OCSP & Authority Information Access References: <23E9E6DBBF4DD21190BC006008B0213E41ED13@newman.verisign.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 (root@barbar.esat.kuleuven.ac.be [134.58.56.153]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA12362 for <ietf-pkix@imc.org>; 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" <cms99@esat.kuleuven.ac.be> To: ietf-pkix@imc.org Subject: CFP: Communications and Multimedia Security '99 Message-ID: <Pine.HPX.4.05.9901271033400.27656-100000@domus.esat.kuleuven.ac.be> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: cms99@esat.kuleuven.ac.be 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: cms99@esat.kuleuven.ac.be Tel +32 16 32 10 50 Fax: +32 16 32 19 86 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 <ietf-pkix@imc.org>; 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: <36AEDD47.C09FA523@bull.net> Date: Wed, 27 Jan 1999 10:32:56 +0100 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: Michael Myers <MMyers@verisign.com> CC: IETF-PXIX <ietf-pkix@imc.org> Subject: Re: OCSP & Authority Information Access References: <23E9E6DBBF4DD21190BC006008B0213E41ED13@newman.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <23E9E6DBBF4DD21190BC006008B0213E41ED13@newman.verisign.com> From: Michael Myers <MMyers@verisign.com> To: "'Denis Pinkas'" <Denis.Pinkas@bull.net> Cc: IETF-PXIX <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Denis, Responses inline, with some trimming. > You wrote: > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > . . . > > > 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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> To: "'Krylov Pavel'" <versed@elvis.ru>, ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: ietf-pkix@imc.org > 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 Pavel.Krylov@trustworks.com 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 <ietf-pkix@imc.org>; 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: <36AD7B67.BB263028@elvis.ru> Date: Tue, 26 Jan 1999 11:23:03 +0300 From: Krylov Pavel <versed@elvis.ru> X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: RDN Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 Pavel.Krylov@trustworks.com 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 (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA10400 for <ietf-pkix@imc.org>; 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: <4.1.19990122133728.009c4eb0@mail.spyrus.com> Message-Id: <4.1.19990122133728.009c4eb0@mail.spyrus.com> 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 <ilans@arx.com> From: Russ Housley <housley@spyrus.com> Subject: Re: Diffie-Hellman key exchange key in pkix-ipki-part1 Cc: "Ietf-Pkix (E-mail)" <ietf-pkix@imc.org> In-Reply-To: <51473D5D4EECD111AF63006008C9A1A30EEF48@mx.arx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:ilans@arx.com >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 <ietf-pkix@imc.org>; 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: <91AE69321799D211AEC500105A9C4696196ED4@sothmxs05.entrust.com> From: Carlisle Adams <carlisle.adams@entrust.com> To: "'Sarbari Gupta'" <sgupta@cygnacom.com> Cc: "PKIX (E-mail)" <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:sgupta@cygnacom.com] 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 (703)848-0883 (voice) (703)848-0960(FAX) sgupta@cygnacom.com ================================= 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 <ietf-pkix@imc.org>; 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: <36AC74D7.3A9A14DA@bull.net> Date: Mon, 25 Jan 1999 14:42:47 +0100 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: Michael Myers <MMyers@verisign.com> CC: IETF-PXIX <ietf-pkix@imc.org> Subject: Re: OCSP & Authority Information Access References: <23E9E6DBBF4DD21190BC006008B0213E41ED0D@newman.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> To: "'Stephen Kent'" <kent@bbn.com> Cc: ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> > -----Original Message----- > From: Stephen Kent > Sent: Monday, January 18, 1999 9:11 AM > To: Alan Lloyd > Cc: ietf-pkix@imc.org > 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 <ietf-pkix@imc.org>; 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: <199901222035.PAA01716@ietf.org> To: IETF-Announce: ; Cc: RFC Editor <rfc-editor@ISI.EDU> Cc: Internet Architecture Board <iab@ISI.EDU> Cc: ietf-pkix@imc.org From: The IESG <iesg-secretary@ietf.org> Subject: 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <s6a877d9.047@prv-mail20.provo.novell.com> X-Mailer: Novell GroupWise 5.5 Date: Fri, 22 Jan 1999 13:06:26 -0700 From: "Tammy Carter" <TCARTER@novell.com> To: <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 tcarter@novell.com 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 <ietf-pkix@imc.org>; 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: <199901222006.PAA00503@ietf.org> To: IETF-Announce: ; Cc: RFC Editor <rfc-editor@ISI.EDU> Cc: Internet Architecture Board <iab@ISI.EDU> Cc: ietf-pkix@imc.org From: The IESG <iesg-secretary@ietf.org> Subject: 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <199901221754.MAA24645@ietf.org> To: IETF-Announce: ; Cc: RFC Editor <rfc-editor@ISI.EDU> Cc: Internet Architecture Board <iab@ISI.EDU> Cc: ietf-pkix@imc.org From: The IESG <iesg-secretary@ietf.org> Subject: Protocol Action: Internet X.509 Public Key Infrastructure Certificate Management Protocols to Proposed Standard Date: Fri, 22 Jan 1999 12:54:12 -0500 Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <sgupta@cygnacom.com> To: "PKIX (E-mail)" <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 (703)848-0883 (voice) (703)848-0960(FAX) sgupta@cygnacom.com ================================= 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 <ietf-pkix@imc.org>; 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 <sgupta@cygnacom.com> To: "PKIX (E-mail)" <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 (703)848-0883 (voice) (703)848-0960(FAX) sgupta@cygnacom.com ================================= 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 <ietf-pkix@imc.org>; 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: rshirey@rosslyn.bbn.com 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: ietf-pkix@imc.org From: "Robert W. Shirey" <rshirey@bbn.com> Subject: Revised "rule" for use of "validate" vs. "verify" in PKI docs Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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- rshirey@bbn.com, Phone 703-284-4641, Reception 284-4600, Fax 284-2766 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 <ietf-pkix@imc.org>; 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: <23E9E6DBBF4DD21190BC006008B0213E41ED0D@newman.verisign.com> From: Michael Myers <MMyers@verisign.com> To: "'Denis Pinkas'" <Denis.Pinkas@bull.net> Cc: IETF-PXIX <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <51473D5D4EECD111AF63006008C9A1A30EEF48@mx.arx.com> From: Ilan Shacham <ilans@arx.com> To: "Ietf-Pkix (E-mail)" <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:ilans@arx.com 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 (root@typhoon.dstc.qut.edu.au [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA01769 for <ietf-pkix@imc.org>; 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: <199901202322.JAA26661@typhoon.dstc.qut.edu.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Stephen Kent <kent@bbn.com> Cc: ietf-pkix@imc.org 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 <povey@dstc.qut.edu.au> Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: povey@dstc.edu.au | Cryptozilla: Research Scientist | ph: +61 7 3864 5120 | www.cryptozilla.org/ Security Unit, DSTC | fax: +61 7 3864 1282 | Oscar - PKI Toolkit: Brisbane, Australia | www: security.dstc.edu.au/ | oscar.dstc.qut.edu.au/ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id 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 <ietf-pkix@imc.org>; 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: kent@po1.bbn.com (Unverified) Message-Id: <v04011707b2ca8c3f9d29@[128.33.238.98]> In-Reply-To: <199901180650.QAA19176@tornado.dstc.qut.edu.au> Date: Tue, 19 Jan 1999 14:28:30 -0500 To: Dean Povey <povey@dstc.edu.au> From: Stephen Kent <kent@bbn.com> Subject: Re: Verifying certificate chains with different policies Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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" <darthur@bigfoot.com> To: "Dean Povey" <povey@dstc.edu.au>, <ietf-pkix@imc.org> Subject: RE: Verifying certificate chains with different policies Date: Wed, 20 Jan 1999 08:34:07 -0500 Message-ID: <000601be4479$8dc3bee0$708394c6@NS95LAP005.nscc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 In-Reply-To: <199901180650.QAA19176@tornado.dstc.qut.edu.au> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:(212) 412-8687 Dwight Arthur f:(212) 908-2345 Managing Director: Systems b:(917) 646-6682 National Securities Clearing darthur@bigfoot.com 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 <ietf-pkix@imc.org>; Wed, 20 Jan 1999 05:13:48 -0800 (PST) From: Mary_Ellen_Zurko@iris.com 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: ietf-pkix@imc.org cc: Crispin Cowan <crispin@cse.ogi.edu> Message-ID: <852566FF.0048D140.00@arista.iris.com> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 (sjg6@gate.net) and Cristina Serban (cserban@att.com) -- 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: mzurko@iris.com e-mail: kienzle@mitre.org voice: (978) 392-6018 voice: (703) 883-5836 fax: (978) 692-7365 fax: (703) 883-1245 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: sjg6@gate.net Lincroft, NJ 07738 USA voice: (305) 944-7842 e-mail: cserban@att.com fax: (305) 944-5746 voice: (732) 576-3279 fax: (732) 576-6406 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) (416) 979-5000 x6686 Scholarships Hilary Hosmer (Data Security Inc.) (781) 275-8231 Brenda Timmerman (California State University) (818) 677-7341 Publications Marv Schaefer (ARCA Systems) (410) 309-1780 Publicity Crispin Cowan (Oregon Graduate Institute) (503) 690-1265 Treasurer/Registration Daniel Essin (University of Southern California) (323) 226-3188 ACM-SIGSAC Chair Ravi Sandhu (George Mason University) (703) 993-1659 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 <ietf-pkix@imc.org>; 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: <36A4B599.EBCA0216@bull.net> Date: Tue, 19 Jan 1999 17:40:58 +0100 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: Michael Myers <MMyers@verisign.com> CC: IETF-PXIX <ietf-pkix@imc.org> Subject: Re: OCSP & Authority Information Access References: <23E9E6DBBF4DD21190BC006008B0213E41ED07@newman.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <23E9E6DBBF4DD21190BC006008B0213E41ED07@newman.verisign.com> From: Michael Myers <MMyers@verisign.com> To: "'Denis Pinkas'" <Denis.Pinkas@bull.net>, IETF-PXIX <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Tue, 19 Jan 1999 12:38:14 +0100 (NFT) Message-ID: <36A46E1F.5073956@bull.net> Date: Tue, 19 Jan 1999 12:35:59 +0100 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: IETF-PXIX <ietf-pkix@imc.org> Subject: DCS or DVS ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Tue, 19 Jan 1999 12:21:17 +0100 (NFT) Message-ID: <36A46A25.8CA8A304@bull.net> Date: Tue, 19 Jan 1999 12:19:02 +0100 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: IETF-PXIX <ietf-pkix@imc.org> Subject: OCSP & Authority Information Access Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; Mon, 18 Jan 1999 17:30:37 -0800 (PST) From: zhuqingj@cn.ibm.com 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 <povey@dstc.edu.au> cc: ietf-pkix@imc.org Message-ID: <482566FE.0008662E.00@cn.ibm.com> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <36A35B83.8932F214@bull.net> Date: Mon, 18 Jan 1999 17:04:20 +0100 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: Dean Povey <povey@dstc.edu.au> CC: ietf-pkix@imc.org Subject: Re: Verifying certificate chains with different policies References: <199901180650.QAA19176@tornado.dstc.qut.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: povey@dstc.edu.au | Cryptozilla: > Research Scientist | ph: +61 7 3864 5120 | www.cryptozilla.org/ > Security Unit, DSTC | fax: +61 7 3864 1282 | Oscar - PKI Toolkit: > Brisbane, Australia | www: security.dstc.edu.au/ | oscar.dstc.qut.edu.au/ > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA22189 for ietf-pkix-bks; Sun, 17 Jan 1999 22:49:01 -0800 (PST) Received: from typhoon.dstc.qut.edu.au (root@typhoon.dstc.qut.edu.au [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA22182 for <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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: <199901180650.QAA19176@tornado.dstc.qut.edu.au> From: Dean Povey <povey@dstc.edu.au> To: ietf-pkix@imc.org Subject: Verifying certificate chains with different policies Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: povey@dstc.edu.au | Cryptozilla: Research Scientist | ph: +61 7 3864 5120 | www.cryptozilla.org/ Security Unit, DSTC | fax: +61 7 3864 1282 | Oscar - PKI Toolkit: Brisbane, Australia | www: security.dstc.edu.au/ | oscar.dstc.qut.edu.au/ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id 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 <ietf-pkix@imc.org>; 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: kent@po1.bbn.com (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 <Alan.Lloyd@OpenDirectory.com.au> From: Stephen Kent <kent@bbn.com> Subject: RE: finding services : DCS, OCSP, Timestamping, .. Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <4.1.19990116123843.0099cab0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 16 Jan 1999 12:39:55 -0500 To: Mary_Ellen_Zurko@iris.com From: Russ Housley <housley@spyrus.com> Subject: RE: Reason codes vs Reason flags Cc: Carlisle Adams <carlisle.adams@entrust.com>, ietf-pkix <ietf-pkix@imc.org> In-Reply-To: <852566F9.00572C73.00@arista.iris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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, Mary_Ellen_Zurko@iris.com 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 <ietf-pkix@imc.org>; 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: <4.1.19990116122755.009a3b00@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 16 Jan 1999 12:37:21 -0500 To: Al Arsenault <aarsenault@spyrus.com> From: Russ Housley <housley@spyrus.com> Subject: Re: Reason codes vs Reason flags Cc: cwallace@erols.com, ietf-pkix@imc.org, cadams@entrust.com, stephen.farrell@sse.ie 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: <199901151643.IAA23717@mail.proper.com> From: List Manager of ietf-pkix <ietf-pkix-request@imc.org> To: ietf-pkix@imc.org Subject: How to be removed from this list Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: ietf-pkix-request@imc.org 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 ietf-pkix-request@imc.org (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 subs@imc.org 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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> To: "'Stephen Kent'" <kent@bbn.com> Cc: ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> Stephen, just a few comments - but it seems we are almost agreeing :-) > -----Original Message----- > From: Stephen Kent [SMTP:kent@bbn.com] > Sent: Friday, 15 January 1999 2:52 > To: Alan Lloyd > Cc: ietf-pkix@imc.org > 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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> From: Stephen Kent <kent@bbn.com> Subject: RE: finding services : DCS, OCSP, Timestamping, .. Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> From: Stephen Kent <kent@bbn.com> Subject: RE: finding services : DCS, OCSP, Timestamping, .. Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <19990114023800.10487.rocketmail@send106.yahoomail.com> Date: Thu, 14 Jan 1999 10:29:48 -0500 To: sankar ramamoorthi <sanka2g@yahoo.com> From: Stephen Kent <kent@bbn.com> Subject: RE: CRL size Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <369E1D33.76520E0D@deh.de> Date: Thu, 14 Jan 1999 17:37:07 +0100 From: Juergen Walter <walter@deh.de> Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Al Arsenault <aarsenault@spyrus.com>, ietf-pkix <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 (root@sisko.cygnacom.com [205.177.169.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA21437 for <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Thu, 14 Jan 1999 11:27:51 -0500 Message-ID: <001b01be3fdb$f97a1d70$5300a8c0@carls_pc> From: "Carl Wallace" <cwallace@erols.com> To: "ietf-pkix" <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: Mary_Ellen_Zurko@iris.com <Mary_Ellen_Zurko@iris.com> To: Carlisle Adams <carlisle.adams@entrust.com> Cc: ietf-pkix <ietf-pkix@imc.org> 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 <ietf-pkix@imc.org>; 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: <91AE69321799D211AEC500105A9C4696196EBD@sothmxs05.entrust.com> From: Carlisle Adams <carlisle.adams@entrust.com> To: "'Mary_Ellen_Zurko@iris.com'" <Mary_Ellen_Zurko@iris.com> Cc: ietf-pkix <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: Mary_Ellen_Zurko@iris.com [mailto:Mary_Ellen_Zurko@iris.com] 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 <ietf-pkix@imc.org>; Thu, 14 Jan 1999 07:51:10 -0800 (PST) From: Mary_Ellen_Zurko@iris.com 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 <carlisle.adams@entrust.com> cc: ietf-pkix <ietf-pkix@imc.org> Message-ID: <852566F9.00572C73.00@arista.iris.com> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <91AE69321799D211AEC500105A9C4696196EBB@sothmxs05.entrust.com> From: Carlisle Adams <carlisle.adams@entrust.com> To: "'Al Arsenault'" <aarsenault@spyrus.com>, Carl Wallace <cwallace@erols.com>, ietf-pkix <ietf-pkix@imc.org> Cc: stephen.farrell@sse.ie 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:aarsenault@spyrus.com] Sent: Thursday, January 14, 1999 8:03 AM To: Carl Wallace; ietf-pkix Cc: cadams@entrust.com; stephen.farrell@sse.ie 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 (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA19774 for <ietf-pkix@imc.org>; 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" <cwallace@erols.com>, "ietf-pkix" <ietf-pkix@imc.org> From: Al Arsenault <aarsenault@spyrus.com> Subject: Re: Reason codes vs Reason flags Cc: cadams@entrust.com, stephen.farrell@sse.ie In-Reply-To: <006e01be3f6c$95d16ae0$477c60cf@cwallace> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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" <venky@valicert.com> To: "sankar ramamoorthi" <sanka2g@yahoo.com>, <ietf-pkix@imc.org> Subject: RE: CRL size Date: Wed, 13 Jan 1999 19:37:49 -0800 Message-ID: <000001be3f6f$41e7c2a0$8400000a@merced.valicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <19990114023800.10487.rocketmail@send106.yahoomail.com> Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <Alan.Lloyd@OpenDirectory.com.au> 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:sanka2g@yahoo.com] > > > Sent: Thursday, 14 January 1999 8:17 > > > To: ietf-pkix@imc.org > > > 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Wed, 13 Jan 1999 22:18:27 -0500 (EST) Message-ID: <006e01be3f6c$95d16ae0$477c60cf@cwallace> From: "Carl Wallace" <cwallace@erols.com> To: "ietf-pkix" <ietf-pkix@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <walter@deh.de> To: Al Arsenault <aarsenault@spyrus.com>; John_Wray@iris.com <John_Wray@iris.com>; ietf-pkix <ietf-pkix@imc.org>; Carlisle Adams <carlisle.adams@entrust.com>; farrell <farrell@sse.ie> 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 <ietf-pkix@imc.org>; Wed, 13 Jan 1999 18:35:38 -0800 (PST) Message-ID: <19990114023800.10487.rocketmail@send106.yahoomail.com> 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 <sanka2g@yahoo.com> Subject: RE: CRL size To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <Alan.Lloyd@OpenDirectory.com.au> 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:sanka2g@yahoo.com] > > Sent: Thursday, 14 January 1999 8:17 > > To: ietf-pkix@imc.org > > 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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> To: "'sankar ramamoorthi'" <sanka2g@yahoo.com>, ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:sanka2g@yahoo.com] > Sent: Thursday, 14 January 1999 8:17 > To: ietf-pkix@imc.org > 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 <ietf-pkix@imc.org>; Wed, 13 Jan 1999 13:20:57 -0800 (PST) Message-ID: <19990113211722.25129.rocketmail@send1e.yahoomail.com> 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 <sanka2g@yahoo.com> Subject: CRL size To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <3.0.3.32.19990113112547.009b9a70@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 13 Jan 1999 11:25:47 -0800 To: Juergen.Walter@deh.de, Al Arsenault <aarsenault@spyrus.com>, "John_Wray@iris.com" <John_Wray@iris.com>, ietf-pkix <ietf-pkix@imc.org>, Carlisle Adams <carlisle.adams@entrust.com>, farrell <farrell@sse.ie> From: Tony Bartoletti <azb@llnl.gov> Subject: Re: Reason codes vs Reason flags In-Reply-To: <369CE096.B4403981@deh.de> References: <852566F7.0055C436.00@arista.iris.com> <4.1.19990113095846.00a988c0@209.172.119.123> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: azb@llnl.gov phone: 925-422-3881 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 <ietf-pkix@imc.org>; 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: <369CE096.B4403981@deh.de> Date: Wed, 13 Jan 1999 19:06:14 +0100 From: Juergen Walter <walter@deh.de> Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Al Arsenault <aarsenault@spyrus.com>, "John_Wray@iris.com" <John_Wray@iris.com>, ietf-pkix <ietf-pkix@imc.org>, Carlisle Adams <carlisle.adams@entrust.com>, farrell <farrell@sse.ie> Subject: Re: Reason codes vs Reason flags References: <852566F7.0055C436.00@arista.iris.com> <4.1.19990113095846.00a988c0@209.172.119.123> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <199901131726.MAA12539@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ipki3cmp-09.txt Date: Wed, 13 Jan 1999 12:26:40 -0500 Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990112161314.I-D@ietf.org> 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: <19990112161314.I-D@ietf.org> --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 (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20378 for <ietf-pkix@imc.org>; 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: Juergen.Walter@deh.de, John_Wray@iris.com, Carlisle Adams <carlisle.adams@entrust.com>, farrell@sse.ie, ietf-pkix <ietf-pkix@imc.org> From: Al Arsenault <aarsenault@spyrus.com> Subject: Re: Reason codes vs Reason flags In-Reply-To: <369C9963.17E989A0@deh.de> References: <852566F7.0055C436.00@arista.iris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <369C9963.17E989A0@deh.de> Date: Wed, 13 Jan 1999 14:02:27 +0100 From: Juergen Walter <walter@deh.de> Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John_Wray@iris.com, Carlisle Adams <carlisle.adams@entrust.com>, farrell@sse.ie, ietf-pkix <ietf-pkix@imc.org> Subject: Re: Reason codes vs Reason flags References: <852566F7.0055C436.00@arista.iris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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. John_Wray@iris.com 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 <ietf-pkix@imc.org>; Tue, 12 Jan 1999 07:36:09 -0800 (PST) From: John_Wray@iris.com 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: ietf-pkix@imc.org Message-ID: <852566F7.0055C436.00@arista.iris.com> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> To: "'Stephen Kent'" <kent@bbn.com> Cc: "'Peter Sylvester'" <Peter.Sylvester@edelweb.fr>, ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:kent@bbn.com] > Sent: Tuesday, 12 January 1999 9:58 > To: Alan Lloyd > Cc: 'Peter Sylvester'; ietf-pkix@imc.org > 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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> From: Stephen Kent <kent@bbn.com> Subject: RE: finding services : DCS, OCSP, Timestamping, .. Cc: "'Peter Sylvester'" <Peter.Sylvester@edelweb.fr>, ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> To: "'Linn, John'" <jlinn@securitydynamics.com>, ietf-pkix@imc.org, "'Peter Sylvester'" <Peter.Sylvester@edelweb.fr> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:jlinn@securitydynamics.com] > Sent: Tuesday, 12 January 1999 5:09 > To: ietf-pkix@imc.org; '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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Mon, 11 Jan 1999 19:41:18 +0100 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA10145 for ietf-pkix@imc.org; Mon, 11 Jan 1999 19:41:17 +0100 Date: Mon, 11 Jan 1999 19:41:17 +0100 Message-Id: <199901111841.TAA10145@emeriau.edelweb.fr> To: ietf-pkix@imc.org Subject: RE: finding services : DCS, OCSP, Timestamping, .. Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <3C7EABA3F6F1D1118FD90008C7F450FDEF78A5@exchang-fairfax.pec.com> From: WHenry <WHenry@pec.com> To: ietf-pkix@imc.org Cc: "'digsig-arch@onelist.com'" <digsig-arch@onelist.com> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: digsig-arch@onelist.com "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"> All:</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Arial"> 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"> 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.</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial"> 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"> Subscribers = post to the list using the following address:</FONT> <BR><FONT COLOR=3D"#000000" SIZE=3D2 = FACE=3D"Arial">digsig-arch@onelist.com</FONT> </P> <P><FONT COLOR=3D"#000000" SIZE=3D2 = FACE=3D"Arial"> "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.</FONT></P> <P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> 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.</FONT></P> <P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> 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"> Regards,</FONT> <BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> Bill = Henry</FONT> <BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> Performance = Engineering Corporation</FONT> <BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> 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 <ietf-pkix@imc.org>; 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: <D104150098E6D111B7830000F8D90AE845A42D@exna02.securitydynamics.com> From: "Linn, John" <jlinn@securitydynamics.com> To: ietf-pkix@imc.org, "'Peter Sylvester'" <Peter.Sylvester@edelweb.fr> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Mon, 11 Jan 1999 13:41:54 +0100 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id NAA09960 for ietf-pkix@imc.org; Mon, 11 Jan 1999 13:41:54 +0100 Date: Mon, 11 Jan 1999 13:41:54 +0100 Message-Id: <199901111241.NAA09960@emeriau.edelweb.fr> To: ietf-pkix@imc.org Subject: RE: finding services : DCS, OCSP, Timestamping, .. Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <Alan.Lloyd@OpenDirectory.com.au> To: ietf-pkix@imc.org Cc: ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:iesg-secretary@ietf.org] > Sent: Saturday, 9 January 1999 0:47 > Cc: ietf-pkix@imc.org > 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 > iesg@ietf.org or ietf@ietf.org 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 <ietf-pkix@imc.org>; 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 <Alan.Lloyd@OpenDirectory.com.au> To: "'Peter Sylvester'" <Peter.Sylvester@edelweb.fr>, ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:Peter.Sylvester@edelweb.fr] > Sent: Tuesday, 5 January 1999 3:06 > To: ietf-pkix@imc.org > 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 <ietf-pkix@imc.org>; 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 <luke.koops@entrust.com> To: "'Brian LaMacchia'" <bal@microsoft.com>, ietf-pkix@imc.org Cc: "Barb Fox (Exchange)" <bfox@exchange.microsoft.com> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 luke.koops@entrust.com > ---------- > From: Brian LaMacchia[SMTP:bal@microsoft.com] > Sent: Wednesday, December 23, 1998 5:58 PM > To: 'Luke Koops' > Cc: ietf-pkix@imc.org; 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 > bal@microsoft.com > 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 <ietf-pkix@imc.org>; 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: <199901081346.IAA11647@ietf.org> To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: The IESG <iesg-secretary@ietf.org> SUBJECT: Last Call: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 08 Jan 1999 08:46:48 -0500 Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 iesg@ietf.org or ietf@ietf.org 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 <ietf-pkix@imc.org>; 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: <199901081329.IAA11109@ietf.org> To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: The IESG <iesg-secretary@ietf.org> SUBJECT: Last Call: Internet X.509 Public Key Infrastructure LDAPv2 Schema to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 08 Jan 1999 08:29:28 -0500 Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 iesg@ietf.org or ietf@ietf.org 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Fri, 8 Jan 1999 08:28:09 -0500 (EST) Date: Fri, 8 Jan 1999 08:28:19 -0500 (Eastern Standard Time) From: Steve Coya <scoya@ietf.org> To: ietf-pkix@imc.org Subject: Last Call: Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP to Proposed Standard (fwd) Message-ID: <Pine.WNT.3.96.990108082643.-129713H-100000@scoya.cnri.reston.va.us> X-X-Sender: scoya@odin.cnri.reston.va.us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> fyi (sorry 'bout the oldd address....) ---------- Forwarded message ---------- Date: Fri, 08 Jan 1999 08:13:19 -0500 From: The IESG <iesg-secretary@ietf.org> Reply-To: iesg@ietf.org To: IETF-Announce: ; Cc: ietf-pkix@tandem.com 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 iesg@ietf.org or ietf@ietf.org 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 <jyzhou@krdl.org.sg> X-Sender: jyzhou@colorado To: aft@socks.nec.com, ietf-cat-wg@lists.stanford.edu, cryptography@c2.net, dns-security@tis.com, Firewalls@lists.gnac.net, ids@uow.edu.au, ietf-open-pgp@imc.org, ietf-otp@bellcore.com, ietf-pkix@imc.org, ietf-radius@livingston.com, ietf-smime@imc.org, ietf-ssh@clinet.fi, ietf-tls@consensus.com, ietf@ietf.org, ipsec@tis.com, OGsecurity@opengroup.org, pem-dev@tis.com, risks@csl.sri.com, spki@c2.net, virus-l@lehigh.edu, www-buyinfo@allegra.att.com, www-security@ns2.rutgers.edu 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 (root@gateway-ext.structuredarts.com [206.127.192.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA20080 for <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Tue, 5 Jan 1999 12:06:21 -0800 Message-ID: <36926DD0.A05DA7DC@structuredarts.com> Date: Tue, 05 Jan 1999 11:53:52 -0800 From: "Anil R. Gangolli" <gangolli@structuredarts.com> Organization: Structured Arts Computing Corporation X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Questions on Issuing Distribution Point CRL extension Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:gangolli@structuredarts.com 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 <ietf-pkix@imc.org>; 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 <carlisle.adams@entrust.com> To: "'Brian LaMacchia'" <bal@microsoft.com> Cc: ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:bal@microsoft.com] Sent: Wednesday, December 23, 1998 5:59 PM To: 'Luke Koops' Cc: ietf-pkix@imc.org; 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 (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA15809 for <ietf-pkix@imc.org>; 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: Juergen.Walter@deh.de, Nada Kapidzic Cicovic <nada@cost.se>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, ietf-pkix <ietf-pkix@imc.org> From: Al Arsenault <aarsenault@spyrus.com> Subject: Re: CRL reason codes In-Reply-To: <3690EE83.F0C44348@deh.de> References: <3.0.3.32.19990104115945.00c09a10@mail.cost.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <3691018E.FFC0EA04@deh.de> Date: Mon, 04 Jan 1999 18:59:42 +0100 From: Juergen Walter <walter@deh.de> Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Al Arsenault <aarsenault@spyrus.com>, ietf-pkix <ietf-pkix@imc.org> Subject: Re: CRL reason codes References: <199901021715.JAA24081@mail.proper.com> <4.1.19990104075715.00a87180@209.172.119.123> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <3690EE83.F0C44348@deh.de> Date: Mon, 04 Jan 1999 17:38:27 +0100 From: Juergen Walter <walter@deh.de> Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Nada Kapidzic Cicovic <nada@cost.se>, Al Arsenault <aarsenault@spyrus.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, ietf-pkix <ietf-pkix@imc.org> Subject: Re: CRL reason codes References: <3.0.3.32.19990104115945.00c09a10@mail.cost.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 (firewall-user@relay.hq.tis.com [192.94.214.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14371 for <ietf-pkix@imc.org>; 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: <Version.32.19990104110317.00dc16e0@pop.hq.tis.com> X-Sender: balenson@pop.hq.tis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 04 Jan 1999 11:03:47 -0500 To: ietf-pkix@imc.org From: "David M. Balenson" <balenson@tis.com> Subject: REMINDER: Jan 6th Early Bird Deadline for NDSS '99 Cc: balenson@tis.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_915483827==_" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 balenson@tis.com; 443-259-2358; fax 301-854-4731 --=====================_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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; 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 <ietf-pkix@imc.org>; Mon, 4 Jan 1999 17:05:32 +0100 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id RAA06535 for ietf-pkix@imc.org; Mon, 4 Jan 1999 17:05:31 +0100 Date: Mon, 4 Jan 1999 17:05:31 +0100 Message-Id: <199901041605.RAA06535@emeriau.edelweb.fr> To: ietf-pkix@imc.org Subject: finding services : DCS, OCSP, Timestamping, .. Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <3690DB7F.6A80F5E7@deh.de> Date: Mon, 04 Jan 1999 16:17:19 +0100 From: Juergen Walter <walter@deh.de> Reply-To: Juergen.Walter@deh.de X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: aarsenault@mail.spyrus.com, Peter Gutmann <pgut001@cs.auckland.ac.nz>, ietf-pkix <ietf-pkix@imc.org> Subject: Re: CRL reason codes References: <199901021715.JAA24081@mail.proper.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 aarsenault@mail.spyrus.com 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 <ietf-pkix@imc.org>; 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: <3690C400.1CA63025@xedia.com> Date: Mon, 04 Jan 1999 08:37:04 -0500 From: Eric Bomarsi <ebomarsi@xedia.com> 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 <AndrewP@rotek.com.au> Cc: ietf-pkix@imc.org Subject: Re: Cert Rqsts and Key Pairs References: <C13ABC20EDDAD111B29E0000B456EABC0A6275@SPRINGFIELD> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 +61 3 9690 8877 > Fax +61 3 9690 8171 > > > -----Original Message----- > > From: Eric Bomarsi [SMTP:ebomarsi@xedia.com] > > Sent: Thursday, December 31, 1998 5:57 AM > > To: ietf-pkix@imc.org > > 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 (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA13263 for <ietf-pkix@imc.org>; 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 <nada@cost.se>, pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-pkix@imc.org From: Al Arsenault <aarsenault@spyrus.com> Subject: Re: CRL reason codes In-Reply-To: <3.0.3.32.19990104115945.00c09a10@mail.cost.se> References: <199901021715.JAA24081@mail.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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: <3.0.3.32.19990104115945.00c09a10@mail.cost.se> X-Sender: nada@mail.cost.se X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 04 Jan 1999 11:59:45 +0100 To: aarsenault@mail.spyrus.com, pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-pkix@imc.org From: Nada Kapidzic Cicovic <nada@cost.se> Subject: Re: CRL reason codes In-Reply-To: <199901021715.JAA24081@mail.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> At 12:12 1/2/99, aarsenault@mail.spyrus.com 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: <4.1.19990103203051.028c4270@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 03 Jan 1999 20:34:22 -0800 To: ietf-pkix@imc.org, ietf-smime@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: Wassenaar Agreement In-Reply-To: <H0001289101d731d@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: <410E16F6AD02D011A9A6080009F89C760B420A@smtp.planetworld.com> From: Bill Brice <bill.brice@idtrust.com> To: ietf-pkix@imc.org, "'ietf-smime@imc.org'" <ietf-smime@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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:phoffman@imc.org] Sent: Sunday, January 03, 1999 7:57 PM To: ietf-pkix@imc.org; ietf-smime@imc.org 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: ESMOND_TONG@HP-HongKong-om1.om.hp.com Received: from hkmail.hkg.hp.com (root@hkmail.hkg.hp.com [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: bill.brice@idtrust.com, ietf-pkix@imc.org, ietf-smime@imc.org Content-Type: text/plain; charset=US-ASCII; name="Wassenaar" Content-Disposition: inline; filename="Wassenaar" Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: <4.1.19990103174708.027a88a0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 03 Jan 1999 17:57:09 -0800 To: ietf-pkix@imc.org, ietf-smime@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: Impact of US Export Regulation changes on WG documents In-Reply-To: <410E16F6AD02D011A9A6080009F89C760B4205@smtp.planetworld.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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: <410E16F6AD02D011A9A6080009F89C760B4205@smtp.planetworld.com> From: Bill Brice <bill.brice@idtrust.com> To: ietf-pkix@imc.org, "'ietf-smime@imc.org'" <ietf-smime@imc.org> 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; 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 <AndrewP@rotek.com.au> To: "'Eric Bomarsi'" <ebomarsi@xedia.com>, ietf-pkix@imc.org 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: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 +61 3 9690 8877 Fax +61 3 9690 8171 > -----Original Message----- > From: Eric Bomarsi [SMTP:ebomarsi@xedia.com] > Sent: Thursday, December 31, 1998 5:57 AM > To: ietf-pkix@imc.org > 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 <ietf-pkix@imc.org>; Sat, 2 Jan 1999 09:15:48 -0800 (PST) From: aarsenault@mail.spyrus.com Message-Id: <199901021715.JAA24081@mail.proper.com> 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: pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-pkix@imc.org Subject: Re: CRL reason codes Date: Sat, 02 Jan 1999 12:12:19 Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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 <ietf-pkix@imc.org>; Sat, 2 Jan 1999 08:22:24 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id FAA31355 for <ietf-pkix@imc.org>; Sun, 3 Jan 1999 05:22:49 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91529416913470>; Sun, 3 Jan 1999 05:22:49 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: CRL reason codes Reply-To: pgut001@cs.auckland.ac.nz X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Sun, 3 Jan 1999 05:22:49 (NZDT) Message-ID: <91529416913470@cs26.cs.auckland.ac.nz> Sender: owner-ietf-pkix@imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?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.
- RE: Attribute used to store cached certificate ch… Andrew Probert
- Attribute used to store cached certificate chains? Tammy Carter
- RE: Attribute used to store cached certificate ch… Andrew Probert
- RE: Attribute used to store cached certificate ch… Tammy Carter
- RE: Attribute used to store cached certificate ch… Alan Lloyd
- RE: Attribute used to store cached certificate ch… Tammy Carter
- FW: Attribute used to store cached certificate ch… Andrew Probert
- RE: Attribute used to store cached certificate ch… Andrew Probert
- FW: Attribute used to store cached certificate ch… WHenry
- Re: FW: Attribute used to store cached certificat… Francois Rousseau
- RE: Attribute used to store cached certificate ch… Tammy Carter
- RE: Attribute used to store cached certificate ch… Stephen Kent
- RE: Attribute used to store cached certificate ch… Stephen Kent
- RE: Attribute used to store cached certificate ch… Andrew Probert
- RE: Attribute used to store cached certificate ch… Alan Lloyd
- RE: Attribute used to store cached certificate ch… Tammy Carter
- RE: FW: Attribute used to store cached certificat… Alan Lloyd
- RE: Attribute used to store cached certificate ch… Stephen Kent
- RE: Attribute used to store cached certificate ch… Stephen Kent
- RE: FW: Attribute used to store cached certificat… Stephen Kent
- RE: Attribute used to store cached certificate ch… Tony Bartoletti
- RE: Attribute used to store cached certificate ch… Alan Lloyd
- RE: Attribute used to store cached certificate ch… Alan Lloyd
- RE: Attribute used to store cached certificate ch… Alan Lloyd
- RE: Attribute used to store cached certificate ch… Tammy Carter
- RE: Attribute used to store cached certificate ch… Tony Bartoletti
- RE: Attribute used to store cached certificate ch… Tony Bartoletti
- RE: Attribute used to store cached certificate ch… Tammy Carter
- RE: Attribute used to store cached certificate ch… Bob Jueneman
- FW: Attribute used to store cached certificate ch… Andrew Probert
- RE: Attribute used to store cached certificate ch… Tony Bartoletti
- RE: Attribute used to store cached certificate ch… Tony Bartoletti
- RE: Attribute used to store cached certificate ch… Andrew Probert
- RE: Attribute used to store cached certificate ch… Bob Jueneman
- RE: Attribute used to store cached certificate ch… Tammy Carter
- RE: Attribute used to store cached certificate ch… Tammy Carter
- RE: FW: Attribute used to store cached certificat… Andrew Probert
- RE: FW: Attribute used to store cached certificat… Alan Lloyd
- Re: FW: Attribute used to store cached certificat… Bob Jueneman
- Re: FW: Attribute used to store cached certificat… Bob Jueneman
- Re: FW: Attribute used to store cached certificat… Peter Williams
- Re: FW: Attribute used to store cached certificat… Stephen Kent
- RE: Attribute used to store cached certificate ch… Miklos, Sue A.