RE: NEW Data type for certificate selection ?
Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> Thu, 01 October 1998 01:48 UTC
Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA20401 for <pkix-archive@odin.ietf.org>; Wed, 30 Sep 1998 21:48:50 -0400 (EDT)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03186 for ietf-pkix-bks; Wed, 30 Sep 1998 16:21:27 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03180 for <ietf-pkix@imc.org>; Wed, 30 Sep 1998 16:21:04 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX35284S>; Thu, 1 Oct 1998 09:25:21 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC07B9C9@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: 'Dave Horvath ' <dave@chromatix.com>, 'Stefan Santesson ' <stefan@accurata.se>
Cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "''ietf-pkix@imc.org ' '" <ietf-pkix@imc.org>, "''list@seis.nc-forum.com ' '" <list@seis.nc-forum.com>, "''pgut001@cs.auckland.ac.nz ' '" <pgut001@cs.auckland.ac.nz>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 01 Oct 1998 09:25:18 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sob story introduction - still on the road in the UK now - and flat chat with the upswing in big X.500 systems and PKIs from every point on the compass. So the details below may have been skipped... anyway. I always thought that the matching rules for certs and crls as defined in X.509 were like other matching rules in that objects/attrs of particular types can be searched for and managed whilst in the directory system. The issues is that the PKI /CA design has been designed as a set of "sort of related objects, but operationally there are multipaths and multi domains.. so we have an information relationship and managment issue (in an originators domain).. and in some form, knowledge of this "environment" must be propagated to the recipient of signed message with a cert - so that efficient validation can occur. The matching rule system is a mechanism for finding what one wants and it can be configured with the desired values - ie knowledge (not knowledge as per DSA access point knowledge) english meaning. It strikes me that this knowledge (and the certficate)of the originating domain should be transferred to the recipient domain and this knowledge supplimented by the recipient - where appropriate - and this applied through the matching rule mechanism into the directory system to achieve validation. the draft I submitted - draft-lloyd-dir-cert-stat starts the validation/matching rule direction off. And in fact permits orgainised knowledge of validity - which is maintained by a CA.. Any way please read. Its an information management and knowledge issue associated with CA/directory systems we are dealing with - it wont be fixed by more attributes on certficates and more protocols like OCSP. thoughts are welcome regards alan ---------- From: Stefan Santesson To: Dave Horvath Cc: Alan Lloyd; 'ietf-pkix@imc.org '; 'list@seis.nc-forum.com '; 'pgut001@cs.auckland.ac.nz ' Sent: 10/1/98 8:53:52 AM Subject: Re: NEW Data type for certificate selection ? Dave, (Sorry for misspelling your name before) I really do agree with you, sticking with the X.500 matching rules makes it possible to link a certificate select from a local application to a suitable directory. Say that the client certificates is stored in a directory and not in the client application (or any mix). When receiving the match rule from the server it would then be very easy to use the same match data to perform an extended lookup in the directory. The question is now, Should this be worked on in IETF ? Is there enough interest in getting this done and implemented? Steve and Warwick, what do you say? Is this something for PKIX? Unfortunately I just represent some of those service providers who need this to be done, I will not be implementing this myself. Personally I can just predict better business for all if we solve this. /Stefan At 01:20 PM 9/30/98 -0400, Dave Horvath wrote: >Stefan, > >Agreed, particularly on the point of not creating any new extensions. > >I would add that I firmly believe the matching rule mechanisms should be >compatible with the work being done in X.500 and LDAP. I would also like to >see X.500 and LDAP join forces and be compatible in the area of matching rules, >I am not sure where LDAP stands at this time. > > >Dave Horvath > >Stefan Santesson wrote: >> >> David, >> >> Thank's for putting this issue in the right focus. >> >> Alan, I don't suggest any new certificate extensions >> Ed, I don't want to define any universal criteria for how certificate >> selection SHALL be done or any who decides what for whom, regulations. >> >> All I want to do is to define some mechanisms that CAN be used, if >> required, by local PKI-related services in order to make it POSSIBLE for >> them to build working services with STANDARD components. >> >> Let me highlight this again and describe a realistic problem relevant to me. >> >> Bank A offer web-based banking applications. This requires the end user to >> get a specific certificate issued by Bank A. The certificate and the >> corresponding private key is processed through the standard web browser of >> the client. >> >> Two certificates and private keys are used in the normal process. >> 1) Certificate for SSL (TLS) security >> 2) Certificate for non-repudiation protection of Bank transactions. >> >> In addition to these certificates, a specific end-user may be populated >> with several other certificates, un-known to the Bank. >> >> The question is. How can this Bank create a web based application without >> distributing a customized client plug-in for the purpose. Well the Bank can >> get far using Java Scripts but it will fail due to the problem that the >> end-user may have to select a certificate. >> Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION. >> >> I realize that today there is no way to do this without distributing >> customized plug-in components to end-users, but I strongly would like to se >> options developed that helps getting around this. The current matching >> mechanism in SSL and TLS is just not good enough to solve the problem. >> >> So If we instead had a standardized matching rule that could be invoked >> into protocols and Java Scripts etc, then the situation would be much more >> hopeful for the Bank in my case. >> >> They would then construct a match rule that with high probability would >> point out the right end-user certificate and invoke that matching rule both >> in the TLS protocol and in the Java Script, forming their secure >> transaction application. >> >> It wouldn't have to be perfect, just good enough to handle some 95%+ of the >> cases as long as the Bank could detect cases where it didn't work. Then the >> non-working cases could be fixed by personal customer service. >> >> I see even more use for this matching rule. It could be used in S/MIME so >> specify a preferred encryption certificate for replies to a mail. Of course >> this matching rule could be used for X.500 directories as well (that's what >> it was built for). MY concern here is however not _where_ the certificates >> are stored but, how to select 1 of several known certificates regardless of >> where they reside. >> >> Comments? >> How do wee proceed ? >> Could we have any comments from Microsoft and Netscape ? >> >> /Stefan >> >> At 11:15 AM 9/30/98 -0400, David Horvath wrote: >> >--- Message on the SEIS mailing list (list@seis.nc-forum.com) >> > >> >Alan, >> > >> >While I personally agree that X.500 provides a mature and feature rich >> >core to implement certificate repositories, I am having trouble >> >understanding some of your assertions as to why X.500 is the answer to >> >so many problems. >> > >> >It seems to me that the first step for locating certificates in a >> >repository is to define the fields in the certificate object that are a >> >prerequisite to perform the match. Matching rules are a good start and >> >foster the thought process required to provide a well designed solution. >> >Once the matching rules are defined, a protocol such as DAP or LDAP V3 >> >with extensions may be used to exploit the matching rules. In some >> >cases, clients may choose not to use the matching rules and retrieve all >> >certificates. Perhaps matching rules are not supported by the protocol >> >(LDAP V2 or HTTP), therefore the client will collect all the >> >certificates and perform the match locally. This may be even more >> >efficient than submitting multiple searches with different variations of >> >matching rules. It could easily be more efficient to submit one search >> >and retrieve 10 certificates, then to submit 3 searches with different >> >matching rules each time until the required certificate is found. This >> >should be defined by local policies based on performance analysis. >> > >> >Once the rules for matching certificates are defined ( and I think X.500 >> >matching rules are an excellent start ) the distribution model can be >> >analyzed. This is another case where X.500 may be superior to LDAP, but >> >unless you have a well planned global infrastructure neither X.500 or >> >LDAP can help with the distribution model. >> > >> >Dave Horvath >> > >> >Alan Lloyd wrote: >> >> >> >> >> >> Snip >> >> >> >> ---------- >> >> From: pgut001@cs.auckland.ac.nz >> >> To: cert-talk@structuredarts.com; ietf-pkix@imc.org; >> >> list@seis.nc-forum.com >> >> Sent: 9/29/98 1:01:30 PM >> >> Subject: Re: NEW Data type for certificate selection ? >> >> >> >> Peter - you went through great lenghts to define the problem with >> >> relationships between and searching directory based objects and a >> >> distributed information issue and then you say: >> >> " >> >> If anyone has any useful solutions for this (apart from "We should >> >> force >> >> everyone to use an X.500 directory, that would solve everything" :-) I'd >> >> be interested in hearing them. >> >> >> >> " >> >> Oh well - that counts me out. I cannot do solutions - without the >> >> solution :-))) >> >> regards alan >> >> >> >> Peter. >> >> >> > >> > >> >----------------- SEIS mailing list (list@seis.nc-forum.com) >> >Info about this list: http://www.nc-forum.com/seis >> >SEIS Contact: info@seis.se >> > >> > >> > >> ------------------------------------------------------------------- >> Stefan Santesson <stefan@accurata.se> >> Accurata Systemsäkerhet AB >> Lotsgatan 27 D Tel. +46-40 152211 >> 216 42 Malmö Fax. +46-40 150790 >> Sweden Mobile +46-70 5247799 >> >> PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 >> ------------------------------------------------------------------- > >-- > ================================================ > > _/_/_/ David J. Horvath > _/ _/ > _/ _/ Chromatix, Inc. > _/ _/ _/ 10451 Twin Rivers Road, Suite 265 >_/ _/_/ Columbia, MD 21044 > _/ _/ _/_/ Phone: (301) 596-8466 | http://www.chromatix.com > _/_/_/ _/ _/ Fax: (410) 997-4306 | dave@chromatix.com > > ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA06142 for ietf-pkix-bks; Wed, 30 Sep 1998 20:42:21 -0700 (PDT) Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA06133 for <ietf-pkix@imc.org>; Wed, 30 Sep 1998 20:42:19 -0700 (PDT) Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id AAA28197; Thu, 1 Oct 1998 00:48:37 -0300 Date: Thu, 1 Oct 1998 00:48:37 -0300 (EST) From: Ed Gerck <egerck@laser.cps.softex.br> To: Stefan Santesson <stefan@accurata.se> cc: David Horvath <dave@chromatix.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz> Subject: Re: NEW Data type for certificate selection ? In-Reply-To: <3.0.32.19981001003423.00a2d2b0@m1.403.telia.com> Message-ID: <Pine.LNX.4.02.9810010015150.25643-100000@laser.cps.softex.br> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-pkix@imc.org Precedence: bulk On Thu, 1 Oct 1998, Stefan Santesson wrote: >Ed, > >Thank you for very interesting input. If I may try a very compressed sum of >your discussion it would be: > >1) In SSL the server may select preferred client certificate by Issuer DN, >and "certificate type" Stefan: pls add in your 1) "if the server is non-anonymous" pls add also a 0) "a self-signed common CA cert for the server and user certs can make your life and the customer's life a lot more pleasant" >2) You suggest hashed SSN (social security numbers) using "salt" if you must add SSN-based info in a public cert, IMO yes! > >Regarding "certificate type" I can't find this as an active selection >mechanism. It is however mentioned as prerequisite that the certificate >type have to match the selected key exchange algorithm. > I fail to see why you "can't find this as an active selection mechanism" together with the issuer DN, even if you want to keep the same type for your repudiable and non-repudiable cases (which I possibly would not, but that is another story). As I wrote: >> (for higher security) with a different CA cert for each type. and, again, later in the same msg: >> Or, for higher security, the Bank can use different CA certs for >> each type and send their DNs accordingly, in each case. >> so, all you need is to have different "types" (ie, DNs) of CA certs, where both "types" should be signed by the same root CA cert of course and the public-key root CA cert should be included in the distribution. Can you pls explain what causes selection difficulties for you in the above scenario? >Regardless of this I fail to see how this can be used to pick the right >"non-repudiation" certificate in the Java script application. Please read above, I hope it is clearer now. > I also fail >to understand if you suggest that the current SSL/TLS functions solves all >my problems or just a part of them. > ;-) If "all your problems" is what you stated, sure, all at one stop. >Do you suggest that a more general matching mechanism is not needed? > If the problem is what you defined, yes. >/Stefan > >P.s >Regarding hashed SSN with salt, I don't get how the "salt" solves this. If >the salt is unknown then the SSN can't be checked and if the salt is known >the dictionary attack is still possible. 1. The salt is only known to those entities that should know the SSN -- not to the evildoer that is trying to get SSNs from a list of cached client certs, in a common access area or in memory. 2. the salt is treated as client's private information -- and kept separate from the cert, in a protected area together with other private information from the client. BTW, this is similar to "dividing" a SSN "signature" into two parts, one public (in the cert) and another private (the salt). > I would say that your "salt" is >equal to suggest that the SSN should be encrypted with a secret key (where >the "salt" is being that secret key). > Yes, certainly -- but it is more appropriately called a keyed-MAC. BTW, I am glad that you now repudiate your phrase after your P.s above ;-) >You and I can argue for centuries if certificates handled in browsers >should, or should not, be allowed to contain SSN. No, I don't argue. As I wrote two msgs ago, some think they have valid reasons for it and I do not disagree with the need to preserve freedom. In that, I follow the C maxim -- even though I think that security work is perhaps not the best place to leave enough rope so that you may hang yourself with it if you so want or don't think it is dangerous... Cheers, Ed Gerck ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br http://novaware.cps.softex.br Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA03186 for ietf-pkix-bks; Wed, 30 Sep 1998 16:21:27 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03180 for <ietf-pkix@imc.org>; Wed, 30 Sep 1998 16:21:04 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX35284S>; Thu, 1 Oct 1998 09:25:21 +1000 Message-ID: <D1A949D4508DD1119C8100400533BEDC07B9C9@DSG1> From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> To: "'Dave Horvath '" <dave@chromatix.com>, "'Stefan Santesson '" <stefan@accurata.se> Cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "''ietf-pkix@imc.org ' '" <ietf-pkix@imc.org>, "''list@seis.nc-forum.com ' '" <list@seis.nc-forum.com>, "''pgut001@cs.auckland.ac.nz ' '" <pgut001@cs.auckland.ac.nz> Subject: RE: NEW Data type for certificate selection ? Date: Thu, 1 Oct 1998 09:25:18 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Sob story introduction - still on the road in the UK now - and flat chat with the upswing in big X.500 systems and PKIs from every point on the compass. So the details below may have been skipped... anyway. I always thought that the matching rules for certs and crls as defined in X.509 were like other matching rules in that objects/attrs of particular types can be searched for and managed whilst in the directory system. The issues is that the PKI /CA design has been designed as a set of "sort of related objects, but operationally there are multipaths and multi domains.. so we have an information relationship and managment issue (in an originators domain).. and in some form, knowledge of this "environment" must be propagated to the recipient of signed message with a cert - so that efficient validation can occur. The matching rule system is a mechanism for finding what one wants and it can be configured with the desired values - ie knowledge (not knowledge as per DSA access point knowledge) english meaning. It strikes me that this knowledge (and the certficate)of the originating domain should be transferred to the recipient domain and this knowledge supplimented by the recipient - where appropriate - and this applied through the matching rule mechanism into the directory system to achieve validation. the draft I submitted - draft-lloyd-dir-cert-stat starts the validation/matching rule direction off. And in fact permits orgainised knowledge of validity - which is maintained by a CA.. Any way please read. Its an information management and knowledge issue associated with CA/directory systems we are dealing with - it wont be fixed by more attributes on certficates and more protocols like OCSP. thoughts are welcome regards alan ---------- From: Stefan Santesson To: Dave Horvath Cc: Alan Lloyd; 'ietf-pkix@imc.org '; 'list@seis.nc-forum.com '; 'pgut001@cs.auckland.ac.nz ' Sent: 10/1/98 8:53:52 AM Subject: Re: NEW Data type for certificate selection ? Dave, (Sorry for misspelling your name before) I really do agree with you, sticking with the X.500 matching rules makes it possible to link a certificate select from a local application to a suitable directory. Say that the client certificates is stored in a directory and not in the client application (or any mix). When receiving the match rule from the server it would then be very easy to use the same match data to perform an extended lookup in the directory. The question is now, Should this be worked on in IETF ? Is there enough interest in getting this done and implemented? Steve and Warwick, what do you say? Is this something for PKIX? Unfortunately I just represent some of those service providers who need this to be done, I will not be implementing this myself. Personally I can just predict better business for all if we solve this. /Stefan At 01:20 PM 9/30/98 -0400, Dave Horvath wrote: >Stefan, > >Agreed, particularly on the point of not creating any new extensions. > >I would add that I firmly believe the matching rule mechanisms should be >compatible with the work being done in X.500 and LDAP. I would also like to >see X.500 and LDAP join forces and be compatible in the area of matching rules, >I am not sure where LDAP stands at this time. > > >Dave Horvath > >Stefan Santesson wrote: >> >> David, >> >> Thank's for putting this issue in the right focus. >> >> Alan, I don't suggest any new certificate extensions >> Ed, I don't want to define any universal criteria for how certificate >> selection SHALL be done or any who decides what for whom, regulations. >> >> All I want to do is to define some mechanisms that CAN be used, if >> required, by local PKI-related services in order to make it POSSIBLE for >> them to build working services with STANDARD components. >> >> Let me highlight this again and describe a realistic problem relevant to me. >> >> Bank A offer web-based banking applications. This requires the end user to >> get a specific certificate issued by Bank A. The certificate and the >> corresponding private key is processed through the standard web browser of >> the client. >> >> Two certificates and private keys are used in the normal process. >> 1) Certificate for SSL (TLS) security >> 2) Certificate for non-repudiation protection of Bank transactions. >> >> In addition to these certificates, a specific end-user may be populated >> with several other certificates, un-known to the Bank. >> >> The question is. How can this Bank create a web based application without >> distributing a customized client plug-in for the purpose. Well the Bank can >> get far using Java Scripts but it will fail due to the problem that the >> end-user may have to select a certificate. >> Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION. >> >> I realize that today there is no way to do this without distributing >> customized plug-in components to end-users, but I strongly would like to se >> options developed that helps getting around this. The current matching >> mechanism in SSL and TLS is just not good enough to solve the problem. >> >> So If we instead had a standardized matching rule that could be invoked >> into protocols and Java Scripts etc, then the situation would be much more >> hopeful for the Bank in my case. >> >> They would then construct a match rule that with high probability would >> point out the right end-user certificate and invoke that matching rule both >> in the TLS protocol and in the Java Script, forming their secure >> transaction application. >> >> It wouldn't have to be perfect, just good enough to handle some 95%+ of the >> cases as long as the Bank could detect cases where it didn't work. Then the >> non-working cases could be fixed by personal customer service. >> >> I see even more use for this matching rule. It could be used in S/MIME so >> specify a preferred encryption certificate for replies to a mail. Of course >> this matching rule could be used for X.500 directories as well (that's what >> it was built for). MY concern here is however not _where_ the certificates >> are stored but, how to select 1 of several known certificates regardless of >> where they reside. >> >> Comments? >> How do wee proceed ? >> Could we have any comments from Microsoft and Netscape ? >> >> /Stefan >> >> At 11:15 AM 9/30/98 -0400, David Horvath wrote: >> >--- Message on the SEIS mailing list (list@seis.nc-forum.com) >> > >> >Alan, >> > >> >While I personally agree that X.500 provides a mature and feature rich >> >core to implement certificate repositories, I am having trouble >> >understanding some of your assertions as to why X.500 is the answer to >> >so many problems. >> > >> >It seems to me that the first step for locating certificates in a >> >repository is to define the fields in the certificate object that are a >> >prerequisite to perform the match. Matching rules are a good start and >> >foster the thought process required to provide a well designed solution. >> >Once the matching rules are defined, a protocol such as DAP or LDAP V3 >> >with extensions may be used to exploit the matching rules. In some >> >cases, clients may choose not to use the matching rules and retrieve all >> >certificates. Perhaps matching rules are not supported by the protocol >> >(LDAP V2 or HTTP), therefore the client will collect all the >> >certificates and perform the match locally. This may be even more >> >efficient than submitting multiple searches with different variations of >> >matching rules. It could easily be more efficient to submit one search >> >and retrieve 10 certificates, then to submit 3 searches with different >> >matching rules each time until the required certificate is found. This >> >should be defined by local policies based on performance analysis. >> > >> >Once the rules for matching certificates are defined ( and I think X.500 >> >matching rules are an excellent start ) the distribution model can be >> >analyzed. This is another case where X.500 may be superior to LDAP, but >> >unless you have a well planned global infrastructure neither X.500 or >> >LDAP can help with the distribution model. >> > >> >Dave Horvath >> > >> >Alan Lloyd wrote: >> >> >> >> >> >> Snip >> >> >> >> ---------- >> >> From: pgut001@cs.auckland.ac.nz >> >> To: cert-talk@structuredarts.com; ietf-pkix@imc.org; >> >> list@seis.nc-forum.com >> >> Sent: 9/29/98 1:01:30 PM >> >> Subject: Re: NEW Data type for certificate selection ? >> >> >> >> Peter - you went through great lenghts to define the problem with >> >> relationships between and searching directory based objects and a >> >> distributed information issue and then you say: >> >> " >> >> If anyone has any useful solutions for this (apart from "We should >> >> force >> >> everyone to use an X.500 directory, that would solve everything" :-) I'd >> >> be interested in hearing them. >> >> >> >> " >> >> Oh well - that counts me out. I cannot do solutions - without the >> >> solution :-))) >> >> regards alan >> >> >> >> Peter. >> >> >> > >> > >> >----------------- SEIS mailing list (list@seis.nc-forum.com) >> >Info about this list: http://www.nc-forum.com/seis >> >SEIS Contact: info@seis.se >> > >> > >> > >> ------------------------------------------------------------------- >> Stefan Santesson <stefan@accurata.se> >> Accurata Systemsäkerhet AB >> Lotsgatan 27 D Tel. +46-40 152211 >> 216 42 Malmö Fax. +46-40 150790 >> Sweden Mobile +46-70 5247799 >> >> PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 >> ------------------------------------------------------------------- > >-- > ================================================ > > _/_/_/ David J. Horvath > _/ _/ > _/ _/ Chromatix, Inc. > _/ _/ _/ 10451 Twin Rivers Road, Suite 265 >_/ _/_/ Columbia, MD 21044 > _/ _/ _/_/ Phone: (301) 596-8466 | http://www.chromatix.com > _/_/_/ _/ _/ Fax: (410) 997-4306 | dave@chromatix.com > > ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA03019 for ietf-pkix-bks; Wed, 30 Sep 1998 15:50:00 -0700 (PDT) Received: from mailc.telia.com (root@mailc.telia.com [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA03010 for <ietf-pkix@imc.org>; Wed, 30 Sep 1998 15:49:51 -0700 (PDT) Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id AAA07763; Thu, 1 Oct 1998 00:56:48 +0200 (CEST) Received: from stefans (t1o68p120.telia.com [62.20.138.120]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id AAA28412; Thu, 1 Oct 1998 00:56:46 +0200 (CEST) Message-Id: <3.0.32.19981001005315.009f7d30@m1.403.telia.com> X-Sender: u40400192@m1.403.telia.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 01 Oct 1998 00:53:52 +0200 To: Dave Horvath <dave@chromatix.com> From: Stefan Santesson <stefan@accurata.se> Subject: Re: NEW Data type for certificate selection ? Cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA03011 Sender: owner-ietf-pkix@imc.org Precedence: bulk Dave, (Sorry for misspelling your name before) I really do agree with you, sticking with the X.500 matching rules makes it possible to link a certificate select from a local application to a suitable directory. Say that the client certificates is stored in a directory and not in the client application (or any mix). When receiving the match rule from the server it would then be very easy to use the same match data to perform an extended lookup in the directory. The question is now, Should this be worked on in IETF ? Is there enough interest in getting this done and implemented? Steve and Warwick, what do you say? Is this something for PKIX? Unfortunately I just represent some of those service providers who need this to be done, I will not be implementing this myself. Personally I can just predict better business for all if we solve this. /Stefan At 01:20 PM 9/30/98 -0400, Dave Horvath wrote: >Stefan, > >Agreed, particularly on the point of not creating any new extensions. > >I would add that I firmly believe the matching rule mechanisms should be >compatible with the work being done in X.500 and LDAP. I would also like to >see X.500 and LDAP join forces and be compatible in the area of matching rules, >I am not sure where LDAP stands at this time. > > >Dave Horvath > >Stefan Santesson wrote: >> >> David, >> >> Thank's for putting this issue in the right focus. >> >> Alan, I don't suggest any new certificate extensions >> Ed, I don't want to define any universal criteria for how certificate >> selection SHALL be done or any who decides what for whom, regulations. >> >> All I want to do is to define some mechanisms that CAN be used, if >> required, by local PKI-related services in order to make it POSSIBLE for >> them to build working services with STANDARD components. >> >> Let me highlight this again and describe a realistic problem relevant to me. >> >> Bank A offer web-based banking applications. This requires the end user to >> get a specific certificate issued by Bank A. The certificate and the >> corresponding private key is processed through the standard web browser of >> the client. >> >> Two certificates and private keys are used in the normal process. >> 1) Certificate for SSL (TLS) security >> 2) Certificate for non-repudiation protection of Bank transactions. >> >> In addition to these certificates, a specific end-user may be populated >> with several other certificates, un-known to the Bank. >> >> The question is. How can this Bank create a web based application without >> distributing a customized client plug-in for the purpose. Well the Bank can >> get far using Java Scripts but it will fail due to the problem that the >> end-user may have to select a certificate. >> Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION. >> >> I realize that today there is no way to do this without distributing >> customized plug-in components to end-users, but I strongly would like to se >> options developed that helps getting around this. The current matching >> mechanism in SSL and TLS is just not good enough to solve the problem. >> >> So If we instead had a standardized matching rule that could be invoked >> into protocols and Java Scripts etc, then the situation would be much more >> hopeful for the Bank in my case. >> >> They would then construct a match rule that with high probability would >> point out the right end-user certificate and invoke that matching rule both >> in the TLS protocol and in the Java Script, forming their secure >> transaction application. >> >> It wouldn't have to be perfect, just good enough to handle some 95%+ of the >> cases as long as the Bank could detect cases where it didn't work. Then the >> non-working cases could be fixed by personal customer service. >> >> I see even more use for this matching rule. It could be used in S/MIME so >> specify a preferred encryption certificate for replies to a mail. Of course >> this matching rule could be used for X.500 directories as well (that's what >> it was built for). MY concern here is however not _where_ the certificates >> are stored but, how to select 1 of several known certificates regardless of >> where they reside. >> >> Comments? >> How do wee proceed ? >> Could we have any comments from Microsoft and Netscape ? >> >> /Stefan >> >> At 11:15 AM 9/30/98 -0400, David Horvath wrote: >> >--- Message on the SEIS mailing list (list@seis.nc-forum.com) >> > >> >Alan, >> > >> >While I personally agree that X.500 provides a mature and feature rich >> >core to implement certificate repositories, I am having trouble >> >understanding some of your assertions as to why X.500 is the answer to >> >so many problems. >> > >> >It seems to me that the first step for locating certificates in a >> >repository is to define the fields in the certificate object that are a >> >prerequisite to perform the match. Matching rules are a good start and >> >foster the thought process required to provide a well designed solution. >> >Once the matching rules are defined, a protocol such as DAP or LDAP V3 >> >with extensions may be used to exploit the matching rules. In some >> >cases, clients may choose not to use the matching rules and retrieve all >> >certificates. Perhaps matching rules are not supported by the protocol >> >(LDAP V2 or HTTP), therefore the client will collect all the >> >certificates and perform the match locally. This may be even more >> >efficient than submitting multiple searches with different variations of >> >matching rules. It could easily be more efficient to submit one search >> >and retrieve 10 certificates, then to submit 3 searches with different >> >matching rules each time until the required certificate is found. This >> >should be defined by local policies based on performance analysis. >> > >> >Once the rules for matching certificates are defined ( and I think X.500 >> >matching rules are an excellent start ) the distribution model can be >> >analyzed. This is another case where X.500 may be superior to LDAP, but >> >unless you have a well planned global infrastructure neither X.500 or >> >LDAP can help with the distribution model. >> > >> >Dave Horvath >> > >> >Alan Lloyd wrote: >> >> >> >> >> >> Snip >> >> >> >> ---------- >> >> From: pgut001@cs.auckland.ac.nz >> >> To: cert-talk@structuredarts.com; ietf-pkix@imc.org; >> >> list@seis.nc-forum.com >> >> Sent: 9/29/98 1:01:30 PM >> >> Subject: Re: NEW Data type for certificate selection ? >> >> >> >> Peter - you went through great lenghts to define the problem with >> >> relationships between and searching directory based objects and a >> >> distributed information issue and then you say: >> >> " >> >> If anyone has any useful solutions for this (apart from "We should >> >> force >> >> everyone to use an X.500 directory, that would solve everything" :-) I'd >> >> be interested in hearing them. >> >> >> >> " >> >> Oh well - that counts me out. I cannot do solutions - without the >> >> solution :-))) >> >> regards alan >> >> >> >> Peter. >> >> >> > >> > >> >----------------- SEIS mailing list (list@seis.nc-forum.com) >> >Info about this list: http://www.nc-forum.com/seis >> >SEIS Contact: info@seis.se >> > >> > >> > >> ------------------------------------------------------------------- >> Stefan Santesson <stefan@accurata.se> >> Accurata Systemsäkerhet AB >> Lotsgatan 27 D Tel. +46-40 152211 >> 216 42 Malmö Fax. +46-40 150790 >> Sweden Mobile +46-70 5247799 >> >> PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 >> ------------------------------------------------------------------- > >-- > ================================================ > > _/_/_/ David J. Horvath > _/ _/ > _/ _/ Chromatix, Inc. > _/ _/ _/ 10451 Twin Rivers Road, Suite 265 >_/ _/_/ Columbia, MD 21044 > _/ _/ _/_/ Phone: (301) 596-8466 | http://www.chromatix.com > _/_/_/ _/ _/ Fax: (410) 997-4306 | dave@chromatix.com > > ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA02842 for ietf-pkix-bks; Wed, 30 Sep 1998 15:31:06 -0700 (PDT) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02838 for <ietf-pkix@imc.org>; Wed, 30 Sep 1998 15:31:04 -0700 (PDT) Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id AAA18769; Thu, 1 Oct 1998 00:37:58 +0200 (CEST) Received: from stefans (t1o68p120.telia.com [62.20.138.120]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id AAA23766; Thu, 1 Oct 1998 00:37:55 +0200 (CEST) Message-Id: <3.0.32.19981001003423.00a2d2b0@m1.403.telia.com> X-Sender: u40400192@m1.403.telia.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 01 Oct 1998 00:35:02 +0200 To: Ed Gerck <egerck@laser.cps.softex.br> From: Stefan Santesson <stefan@accurata.se> Subject: Re: NEW Data type for certificate selection ? Cc: David Horvath <dave@chromatix.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA02839 Sender: owner-ietf-pkix@imc.org Precedence: bulk Ed, Thank you for very interesting input. If I may try a very compressed sum of your discussion it would be: 1) In SSL the server may select preferred client certificate by Issuer DN, and "certificate type" 2) You suggest hashed SSN (social security numbers) using "salt" Regarding "certificate type" I can't find this as an active selection mechanism. It is however mentioned as prerequisite that the certificate type have to match the selected key exchange algorithm. Regardless of this I fail to see how this can be used to pick the right "non-repudiation" certificate in the Java script application. I also fail to understand if you suggest that the current SSL/TLS functions solves all my problems or just a part of them. Do you suggest that a more general matching mechanism is not needed? /Stefan P.s Regarding hashed SSN with salt, I don't get how the "salt" solves this. If the salt is unknown then the SSN can't be checked and if the salt is known the dictionary attack is still possible. I would say that your "salt" is equal to suggest that the SSN should be encrypted with a secret key (where the "salt" is being that secret key). You and I can argue for centuries if certificates handled in browsers should, or should not, be allowed to contain SSN. The fact is that many organizations require this and they will create those certificates regardless of whether you and I like it or not. All we can do is to try to help building architectural principles that to the greatest extent is as forgiving as possible for those examples of bad engineering that by provable fact will show up out there. D.s. At 03:08 PM 9/30/98 -0300, Ed Gerck wrote: >On Wed, 30 Sep 1998, Stefan Santesson wrote: > >> >>Alan, I don't suggest any new certificate extensions >>Ed, I don't want to define any universal criteria for how certificate >>selection SHALL be done or any who decides what for whom, regulations. > >Stefan: > >Thank you for changing the focus and not requiring (as in your >previous examples) that Alice would have her SSN in a public cert :-) > >Your question below fits now the first part of my previous reply, >with a direct solution in SSL, as I present below. > >> >>All I want to do is to define some mechanisms that CAN be used, if >>required, by local PKI-related services in order to make it POSSIBLE for >>them to build working services with STANDARD components. >> >>Let me highlight this again and describe a realistic problem relevant to me. >> >>Bank A offer web-based banking applications. This requires the end user to >>get a specific certificate issued by Bank A. The certificate and the >>corresponding private key is processed through the standard web browser of >>the client. >> >>Two certificates and private keys are used in the normal process. >>1) Certificate for SSL (TLS) security >>2) Certificate for non-repudiation protection of Bank transactions. >> >>In addition to these certificates, a specific end-user may be populated >>with several other certificates, un-known to the Bank. >> >>The question is. How can this Bank create a web based application without >>distributing a customized client plug-in for the purpose. > > >Suppose the Bank signs its own CA certificate and uses that >self-signed CA cert to sign all Bank customer's certs of a certain >class (to make your problem still more realistic), for types (1) and >(2) above for each customer or, (for higher security) with a >different CA cert for each type. > >Of course, that CA cert can be easily registered in a costumer's >browser -- just using the standard menu options. This is justifiable >regarding trust acceptance by a Bank's customer, because the Bank >already exibits trusted functionality to the Bank's customer and the >Bank's CA cert is used in the realm of said trusted functionality in >regard to the customer's browser in cases (1) and (2) of your >example. In other words, it requires no new assumptions, for neither >party. > >Now, you have two phases: > >1. The customer's browser must automatically authenticate the Bank's >server, using the pre-acquired and trusted public-key Bank CA cert. > > If the Bank's server sends its server cert to the browser in SSL, > right after the "server hello" message and self-signed by their own > CA, the browser will be able to automatically verify and accept the > Bank's server cert -- since it can be checked by the public-key > contained in the Bank's own self-signed CA cert stored at the > costumer's browser. > >2. The Bank's server must authenticate the required customer's cert, >which is appropriately requested by the Bank's server and is >automatically presented by the customer's browser according to cert >class and cert type, from a larger collection. > > Since the Bank's server is non-anonymous, it can automatically > request the intended cert from the browser by sending only the DN of > their own appropriate (ie, for that customer's class) CA cert in the > "certificate request" message sent from server to browser in SSL -- > which Bank CA cert is exactly the one that signed the required > customer's cert. Since the Bank certainly did not use their own CA > cert to sign any other types of certs for the customer, the Bank > (and the customer) can trust the browser/SSL combination to block > other customer certs that could have been selected from the > customer's certificate pool and sent back in response. The server > can also specify in the "certificate request" message the customer's > "certificate type" it is requesting, as needed by the Bank -- for > example in your cases (1) and (2) above. Or, for higher security, > the Bank can use different CA certs for each type and send their DNs > accordingly, in each case. > > >It is important to note that *if* the customer's browser fails to >authenticate the Bank's server, then this will generate a fatal >handshake-failure alert in SSL if the non-authenticated Bank still >tries to go into phase 2 above -- so, the second phase is privacy >protected by the first. Perhaps, this also answers some of your >previous concerns and could allow more sensitive information (from >the customer) to be included in the customer's cert sent to the >server -- but, by all means, not in plain (eg, the SSN itself) if >privacy is really a concern since public client certificates are >stored in general access areas at the server. > > >Regarding possible problems of using hashes to protect US's SSN >numbers in public certs (as I suggested in my previous reply), I >include below one comentary I received and my reply -- since it may >be also useful in your context: > >=============================== >>This does not help. American SSN is only 9 digits long and only >>includes digits. It will be trivial to do a dictionary attack in >>this case. This may be true for other pieces of sensitive info as >>well. > >The solution is to add "salt" -- like it is done in UNIX passwords. >For example, you can add 50 chars of salt or as many as you want -- a >passphrase. The point here is that since you know the SSN and the >salt, no one else can guess the SSN from a dictionary attack on only >9 digits. Better still, you can change the hash in a new cert and >keep the SSN constant, by changing the salt, so no one can verify >your SSN in a new cert without your cooperation. > >Part of this technique is used in the MC-DN token in the >Meta-Certificate Standard being developed by the MCG. See >http://www.mcg.org.br/mcfaq.htm > >=============================== > > >Cheers, > >Ed Gerck >______________________________________________________________________ >Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br >http://novaware.cps.softex.br > > > > > ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00464 for ietf-pkix-bks; Wed, 30 Sep 1998 11:04:46 -0700 (PDT) Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00443 for <ietf-pkix@imc.org>; Wed, 30 Sep 1998 11:02:19 -0700 (PDT) Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id PAA27526; Wed, 30 Sep 1998 15:08:28 -0300 Date: Wed, 30 Sep 1998 15:08:26 -0300 (EST) From: Ed Gerck <egerck@laser.cps.softex.br> To: Stefan Santesson <stefan@accurata.se> cc: David Horvath <dave@chromatix.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz> Subject: Re: NEW Data type for certificate selection ? In-Reply-To: <3.0.32.19980930164259.00a84cc0@m1.403.telia.com> Message-ID: <Pine.LNX.4.02.9809301211200.25643-100000@laser.cps.softex.br> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-pkix@imc.org Precedence: bulk On Wed, 30 Sep 1998, Stefan Santesson wrote: > >Alan, I don't suggest any new certificate extensions >Ed, I don't want to define any universal criteria for how certificate >selection SHALL be done or any who decides what for whom, regulations. Stefan: Thank you for changing the focus and not requiring (as in your previous examples) that Alice would have her SSN in a public cert :-) Your question below fits now the first part of my previous reply, with a direct solution in SSL, as I present below. > >All I want to do is to define some mechanisms that CAN be used, if >required, by local PKI-related services in order to make it POSSIBLE for >them to build working services with STANDARD components. > >Let me highlight this again and describe a realistic problem relevant to me. > >Bank A offer web-based banking applications. This requires the end user to >get a specific certificate issued by Bank A. The certificate and the >corresponding private key is processed through the standard web browser of >the client. > >Two certificates and private keys are used in the normal process. >1) Certificate for SSL (TLS) security >2) Certificate for non-repudiation protection of Bank transactions. > >In addition to these certificates, a specific end-user may be populated >with several other certificates, un-known to the Bank. > >The question is. How can this Bank create a web based application without >distributing a customized client plug-in for the purpose. Suppose the Bank signs its own CA certificate and uses that self-signed CA cert to sign all Bank customer's certs of a certain class (to make your problem still more realistic), for types (1) and (2) above for each customer or, (for higher security) with a different CA cert for each type. Of course, that CA cert can be easily registered in a costumer's browser -- just using the standard menu options. This is justifiable regarding trust acceptance by a Bank's customer, because the Bank already exibits trusted functionality to the Bank's customer and the Bank's CA cert is used in the realm of said trusted functionality in regard to the customer's browser in cases (1) and (2) of your example. In other words, it requires no new assumptions, for neither party. Now, you have two phases: 1. The customer's browser must automatically authenticate the Bank's server, using the pre-acquired and trusted public-key Bank CA cert. If the Bank's server sends its server cert to the browser in SSL, right after the "server hello" message and self-signed by their own CA, the browser will be able to automatically verify and accept the Bank's server cert -- since it can be checked by the public-key contained in the Bank's own self-signed CA cert stored at the costumer's browser. 2. The Bank's server must authenticate the required customer's cert, which is appropriately requested by the Bank's server and is automatically presented by the customer's browser according to cert class and cert type, from a larger collection. Since the Bank's server is non-anonymous, it can automatically request the intended cert from the browser by sending only the DN of their own appropriate (ie, for that customer's class) CA cert in the "certificate request" message sent from server to browser in SSL -- which Bank CA cert is exactly the one that signed the required customer's cert. Since the Bank certainly did not use their own CA cert to sign any other types of certs for the customer, the Bank (and the customer) can trust the browser/SSL combination to block other customer certs that could have been selected from the customer's certificate pool and sent back in response. The server can also specify in the "certificate request" message the customer's "certificate type" it is requesting, as needed by the Bank -- for example in your cases (1) and (2) above. Or, for higher security, the Bank can use different CA certs for each type and send their DNs accordingly, in each case. It is important to note that *if* the customer's browser fails to authenticate the Bank's server, then this will generate a fatal handshake-failure alert in SSL if the non-authenticated Bank still tries to go into phase 2 above -- so, the second phase is privacy protected by the first. Perhaps, this also answers some of your previous concerns and could allow more sensitive information (from the customer) to be included in the customer's cert sent to the server -- but, by all means, not in plain (eg, the SSN itself) if privacy is really a concern since public client certificates are stored in general access areas at the server. Regarding possible problems of using hashes to protect US's SSN numbers in public certs (as I suggested in my previous reply), I include below one comentary I received and my reply -- since it may be also useful in your context: =============================== >This does not help. American SSN is only 9 digits long and only >includes digits. It will be trivial to do a dictionary attack in >this case. This may be true for other pieces of sensitive info as >well. The solution is to add "salt" -- like it is done in UNIX passwords. For example, you can add 50 chars of salt or as many as you want -- a passphrase. The point here is that since you know the SSN and the salt, no one else can guess the SSN from a dictionary attack on only 9 digits. Better still, you can change the hash in a new cert and keep the SSN constant, by changing the salt, so no one can verify your SSN in a new cert without your cooperation. Part of this technique is used in the MC-DN token in the Meta-Certificate Standard being developed by the MCG. See http://www.mcg.org.br/mcfaq.htm =============================== Cheers, Ed Gerck ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br http://novaware.cps.softex.br Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00258 for ietf-pkix-bks; Wed, 30 Sep 1998 10:37:53 -0700 (PDT) Received: from mailsvr.basit.com (mailsvr-gw.basit.com [128.209.1.213]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00254 for <ietf-pkix@imc.org>; Wed, 30 Sep 1998 10:37:44 -0700 (PDT) Received: from klerer.basit.com (shiva120 [128.209.144.120]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id NAA06626 for <ietf-pkix@imc.org>; Wed, 30 Sep 1998 13:44:11 -0400 (EDT) Message-ID: <008101bdec99$e9fa7a60$010ed180@klerer.basit.com> From: "Robert Klerer" <klerer@xhair.com> To: <ietf-pkix@imc.org> Subject: Re: NEW Data type for certificate selection ? Date: Wed, 30 Sep 1998 13:44:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ietf-pkix@imc.org Precedence: bulk Stefan, If I can suggest a more trivial example. I have a key pair that others use to send me encrypted email and another for encrypting files on my hard disk. There are good reasons to use two key pairs (different escrow policies, key lengths etc.). Locally my applications can use various means of keeping my private keys straight. My CA, by policy, will put both certifucates in a repository. People who have access to the repository who want to send me mail have no distinguishing application usage to select the proper certificate. The answer is not "Don't put your file certificate in the repostory". >David, > >Thank's for putting this issue in the right focus. > >Alan, I don't suggest any new certificate extensions >Ed, I don't want to define any universal criteria for how certificate >selection SHALL be done or any who decides what for whom, regulations. > >All I want to do is to define some mechanisms that CAN be used, if >required, by local PKI-related services in order to make it POSSIBLE for >them to build working services with STANDARD components. > >Let me highlight this again and describe a realistic problem relevant to me. > >Bank A offer web-based banking applications. This requires the end user to >get a specific certificate issued by Bank A. The certificate and the >corresponding private key is processed through the standard web browser of >the client. > >Two certificates and private keys are used in the normal process. >1) Certificate for SSL (TLS) security >2) Certificate for non-repudiation protection of Bank transactions. > >In addition to these certificates, a specific end-user may be populated >with several other certificates, un-known to the Bank. > >The question is. How can this Bank create a web based application without >distributing a customized client plug-in for the purpose. Well the Bank can >get far using Java Scripts but it will fail due to the problem that the >end-user may have to select a certificate. >Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION. > >I realize that today there is no way to do this without distributing >customized plug-in components to end-users, but I strongly would like to se >options developed that helps getting around this. The current matching >mechanism in SSL and TLS is just not good enough to solve the problem. > >So If we instead had a standardized matching rule that could be invoked >into protocols and Java Scripts etc, then the situation would be much more >hopeful for the Bank in my case. > >They would then construct a match rule that with high probability would >point out the right end-user certificate and invoke that matching rule both >in the TLS protocol and in the Java Script, forming their secure >transaction application. > >It wouldn't have to be perfect, just good enough to handle some 95%+ of the >cases as long as the Bank could detect cases where it didn't work. Then the >non-working cases could be fixed by personal customer service. > >I see even more use for this matching rule. It could be used in S/MIME so >specify a preferred encryption certificate for replies to a mail. Of course >this matching rule could be used for X.500 directories as well (that's what >it was built for). MY concern here is however not _where_ the certificates >are stored but, how to select 1 of several known certificates regardless of >where they reside. > > >Comments? >How do wee proceed ? >Could we have any comments from Microsoft and Netscape ? > >/Stefan > >At 11:15 AM 9/30/98 -0400, David Horvath wrote: >>--- Message on the SEIS mailing list (list@seis.nc-forum.com) >> >>Alan, >> >>While I personally agree that X.500 provides a mature and feature rich >>core to implement certificate repositories, I am having trouble >>understanding some of your assertions as to why X.500 is the answer to >>so many problems. >> >>It seems to me that the first step for locating certificates in a >>repository is to define the fields in the certificate object that are a >>prerequisite to perform the match. Matching rules are a good start and >>foster the thought process required to provide a well designed solution. >>Once the matching rules are defined, a protocol such as DAP or LDAP V3 >>with extensions may be used to exploit the matching rules. In some >>cases, clients may choose not to use the matching rules and retrieve all >>certificates. Perhaps matching rules are not supported by the protocol >>(LDAP V2 or HTTP), therefore the client will collect all the >>certificates and perform the match locally. This may be even more >>efficient than submitting multiple searches with different variations of >>matching rules. It could easily be more efficient to submit one search >>and retrieve 10 certificates, then to submit 3 searches with different >>matching rules each time until the required certificate is found. This >>should be defined by local policies based on performance analysis. >> >>Once the rules for matching certificates are defined ( and I think X.500 >>matching rules are an excellent start ) the distribution model can be >>analyzed. This is another case where X.500 may be superior to LDAP, but >>unless you have a well planned global infrastructure neither X.500 or >>LDAP can help with the distribution model. >> >>Dave Horvath >> >>Alan Lloyd wrote: >>> >>> >>> Snip >>> >>> ---------- >>> From: pgut001@cs.auckland.ac.nz >>> To: cert-talk@structuredarts.com; ietf-pkix@imc.org; >>> list@seis.nc-forum.com >>> Sent: 9/29/98 1:01:30 PM >>> Subject: Re: NEW Data type for certificate selection ? >>> >>> Peter - you went through great lenghts to define the problem with >>> relationships between and searching directory based objects and a >>> distributed information issue and then you say: >>> " >>> If anyone has any useful solutions for this (apart from "We should >>> force >>> everyone to use an X.500 directory, that would solve everything" :-) I'd >>> be interested in hearing them. >>> >>> " >>> Oh well - that counts me out. I cannot do solutions - without the >>> solution :-))) >>> regards alan >>> >>> Peter. >>> >> >> >>----------------- SEIS mailing list (list@seis.nc-forum.com) >>Info about this list: http://www.nc-forum.com/seis >>SEIS Contact: info@seis.se >> >> >> >------------------------------------------------------------------- >Stefan Santesson <stefan@accurata.se> >Accurata Systemsäkerhet AB >Lotsgatan 27 D Tel. +46-40 152211 >216 42 Malmö Fax. +46-40 150790 >Sweden Mobile +46-70 5247799 > >PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 >------------------------------------------------------------------- > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29980 for ietf-pkix-bks; Wed, 30 Sep 1998 10:14:37 -0700 (PDT) Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29976 for <ietf-pkix@imc.org>; Wed, 30 Sep 1998 10:14:34 -0700 (PDT) Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id NAA08397; Wed, 30 Sep 1998 13:21:48 -0400 (EDT) (envelope-from dave@chromatix.com) Message-ID: <3612686B.C127798B@chromatix.com> Date: Wed, 30 Sep 1998 13:20:43 -0400 From: Dave Horvath <dave@chromatix.com> Organization: Chromatix Inc. X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780) MIME-Version: 1.0 To: Stefan Santesson <stefan@accurata.se> CC: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz> Subject: Re: NEW Data type for certificate selection ? References: <3.0.32.19980930164259.00a84cc0@m1.403.telia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Stefan, Agreed, particularly on the point of not creating any new extensions. I would add that I firmly believe the matching rule mechanisms should be compatible with the work being done in X.500 and LDAP. I would also like to see X.500 and LDAP join forces and be compatible in the area of matching rules, I am not sure where LDAP stands at this time. Dave Horvath Stefan Santesson wrote: > > David, > > Thank's for putting this issue in the right focus. > > Alan, I don't suggest any new certificate extensions > Ed, I don't want to define any universal criteria for how certificate > selection SHALL be done or any who decides what for whom, regulations. > > All I want to do is to define some mechanisms that CAN be used, if > required, by local PKI-related services in order to make it POSSIBLE for > them to build working services with STANDARD components. > > Let me highlight this again and describe a realistic problem relevant to me. > > Bank A offer web-based banking applications. This requires the end user to > get a specific certificate issued by Bank A. The certificate and the > corresponding private key is processed through the standard web browser of > the client. > > Two certificates and private keys are used in the normal process. > 1) Certificate for SSL (TLS) security > 2) Certificate for non-repudiation protection of Bank transactions. > > In addition to these certificates, a specific end-user may be populated > with several other certificates, un-known to the Bank. > > The question is. How can this Bank create a web based application without > distributing a customized client plug-in for the purpose. Well the Bank can > get far using Java Scripts but it will fail due to the problem that the > end-user may have to select a certificate. > Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION. > > I realize that today there is no way to do this without distributing > customized plug-in components to end-users, but I strongly would like to se > options developed that helps getting around this. The current matching > mechanism in SSL and TLS is just not good enough to solve the problem. > > So If we instead had a standardized matching rule that could be invoked > into protocols and Java Scripts etc, then the situation would be much more > hopeful for the Bank in my case. > > They would then construct a match rule that with high probability would > point out the right end-user certificate and invoke that matching rule both > in the TLS protocol and in the Java Script, forming their secure > transaction application. > > It wouldn't have to be perfect, just good enough to handle some 95%+ of the > cases as long as the Bank could detect cases where it didn't work. Then the > non-working cases could be fixed by personal customer service. > > I see even more use for this matching rule. It could be used in S/MIME so > specify a preferred encryption certificate for replies to a mail. Of course > this matching rule could be used for X.500 directories as well (that's what > it was built for). MY concern here is however not _where_ the certificates > are stored but, how to select 1 of several known certificates regardless of > where they reside. > > Comments? > How do wee proceed ? > Could we have any comments from Microsoft and Netscape ? > > /Stefan > > At 11:15 AM 9/30/98 -0400, David Horvath wrote: > >--- Message on the SEIS mailing list (list@seis.nc-forum.com) > > > >Alan, > > > >While I personally agree that X.500 provides a mature and feature rich > >core to implement certificate repositories, I am having trouble > >understanding some of your assertions as to why X.500 is the answer to > >so many problems. > > > >It seems to me that the first step for locating certificates in a > >repository is to define the fields in the certificate object that are a > >prerequisite to perform the match. Matching rules are a good start and > >foster the thought process required to provide a well designed solution. > >Once the matching rules are defined, a protocol such as DAP or LDAP V3 > >with extensions may be used to exploit the matching rules. In some > >cases, clients may choose not to use the matching rules and retrieve all > >certificates. Perhaps matching rules are not supported by the protocol > >(LDAP V2 or HTTP), therefore the client will collect all the > >certificates and perform the match locally. This may be even more > >efficient than submitting multiple searches with different variations of > >matching rules. It could easily be more efficient to submit one search > >and retrieve 10 certificates, then to submit 3 searches with different > >matching rules each time until the required certificate is found. This > >should be defined by local policies based on performance analysis. > > > >Once the rules for matching certificates are defined ( and I think X.500 > >matching rules are an excellent start ) the distribution model can be > >analyzed. This is another case where X.500 may be superior to LDAP, but > >unless you have a well planned global infrastructure neither X.500 or > >LDAP can help with the distribution model. > > > >Dave Horvath > > > >Alan Lloyd wrote: > >> > >> > >> Snip > >> > >> ---------- > >> From: pgut001@cs.auckland.ac.nz > >> To: cert-talk@structuredarts.com; ietf-pkix@imc.org; > >> list@seis.nc-forum.com > >> Sent: 9/29/98 1:01:30 PM > >> Subject: Re: NEW Data type for certificate selection ? > >> > >> Peter - you went through great lenghts to define the problem with > >> relationships between and searching directory based objects and a > >> distributed information issue and then you say: > >> " > >> If anyone has any useful solutions for this (apart from "We should > >> force > >> everyone to use an X.500 directory, that would solve everything" :-) I'd > >> be interested in hearing them. > >> > >> " > >> Oh well - that counts me out. I cannot do solutions - without the > >> solution :-))) > >> regards alan > >> > >> Peter. > >> > > > > > >----------------- SEIS mailing list (list@seis.nc-forum.com) > >Info about this list: http://www.nc-forum.com/seis > >SEIS Contact: info@seis.se > > > > > > > ------------------------------------------------------------------- > Stefan Santesson <stefan@accurata.se> > Accurata Systemsäkerhet AB > Lotsgatan 27 D Tel. +46-40 152211 > 216 42 Malmö Fax. +46-40 150790 > Sweden Mobile +46-70 5247799 > > PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 > ------------------------------------------------------------------- -- ================================================ _/_/_/ David J. Horvath _/ _/ _/ _/ Chromatix, Inc. _/ _/ _/ 10451 Twin Rivers Road, Suite 265 _/ _/_/ Columbia, MD 21044 _/ _/ _/_/ Phone: (301) 596-8466 | http://www.chromatix.com _/_/_/ _/ _/ Fax: (410) 997-4306 | dave@chromatix.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28790 for ietf-pkix-bks; Wed, 30 Sep 1998 07:39:59 -0700 (PDT) Received: from mailc.telia.com (root@mailc.telia.com [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28786 for <ietf-pkix@imc.org>; Wed, 30 Sep 1998 07:39:57 -0700 (PDT) Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id QAA02188; Wed, 30 Sep 1998 16:46:36 +0200 (CEST) Received: from stefans (t3o68p79.telia.com [62.20.139.79]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id QAA25183; Wed, 30 Sep 1998 16:46:29 +0200 (CEST) Message-Id: <3.0.32.19980930164259.00a84cc0@m1.403.telia.com> X-Sender: u40400192@m1.403.telia.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 30 Sep 1998 16:43:41 +0200 To: David Horvath <dave@chromatix.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> From: Stefan Santesson <stefan@accurata.se> Subject: Re: NEW Data type for certificate selection ? Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA28787 Sender: owner-ietf-pkix@imc.org Precedence: bulk David, Thank's for putting this issue in the right focus. Alan, I don't suggest any new certificate extensions Ed, I don't want to define any universal criteria for how certificate selection SHALL be done or any who decides what for whom, regulations. All I want to do is to define some mechanisms that CAN be used, if required, by local PKI-related services in order to make it POSSIBLE for them to build working services with STANDARD components. Let me highlight this again and describe a realistic problem relevant to me. Bank A offer web-based banking applications. This requires the end user to get a specific certificate issued by Bank A. The certificate and the corresponding private key is processed through the standard web browser of the client. Two certificates and private keys are used in the normal process. 1) Certificate for SSL (TLS) security 2) Certificate for non-repudiation protection of Bank transactions. In addition to these certificates, a specific end-user may be populated with several other certificates, un-known to the Bank. The question is. How can this Bank create a web based application without distributing a customized client plug-in for the purpose. Well the Bank can get far using Java Scripts but it will fail due to the problem that the end-user may have to select a certificate. Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION. I realize that today there is no way to do this without distributing customized plug-in components to end-users, but I strongly would like to se options developed that helps getting around this. The current matching mechanism in SSL and TLS is just not good enough to solve the problem. So If we instead had a standardized matching rule that could be invoked into protocols and Java Scripts etc, then the situation would be much more hopeful for the Bank in my case. They would then construct a match rule that with high probability would point out the right end-user certificate and invoke that matching rule both in the TLS protocol and in the Java Script, forming their secure transaction application. It wouldn't have to be perfect, just good enough to handle some 95%+ of the cases as long as the Bank could detect cases where it didn't work. Then the non-working cases could be fixed by personal customer service. I see even more use for this matching rule. It could be used in S/MIME so specify a preferred encryption certificate for replies to a mail. Of course this matching rule could be used for X.500 directories as well (that's what it was built for). MY concern here is however not _where_ the certificates are stored but, how to select 1 of several known certificates regardless of where they reside. Comments? How do wee proceed ? Could we have any comments from Microsoft and Netscape ? /Stefan At 11:15 AM 9/30/98 -0400, David Horvath wrote: >--- Message on the SEIS mailing list (list@seis.nc-forum.com) > >Alan, > >While I personally agree that X.500 provides a mature and feature rich >core to implement certificate repositories, I am having trouble >understanding some of your assertions as to why X.500 is the answer to >so many problems. > >It seems to me that the first step for locating certificates in a >repository is to define the fields in the certificate object that are a >prerequisite to perform the match. Matching rules are a good start and >foster the thought process required to provide a well designed solution. >Once the matching rules are defined, a protocol such as DAP or LDAP V3 >with extensions may be used to exploit the matching rules. In some >cases, clients may choose not to use the matching rules and retrieve all >certificates. Perhaps matching rules are not supported by the protocol >(LDAP V2 or HTTP), therefore the client will collect all the >certificates and perform the match locally. This may be even more >efficient than submitting multiple searches with different variations of >matching rules. It could easily be more efficient to submit one search >and retrieve 10 certificates, then to submit 3 searches with different >matching rules each time until the required certificate is found. This >should be defined by local policies based on performance analysis. > >Once the rules for matching certificates are defined ( and I think X.500 >matching rules are an excellent start ) the distribution model can be >analyzed. This is another case where X.500 may be superior to LDAP, but >unless you have a well planned global infrastructure neither X.500 or >LDAP can help with the distribution model. > >Dave Horvath > >Alan Lloyd wrote: >> >> >> Snip >> >> ---------- >> From: pgut001@cs.auckland.ac.nz >> To: cert-talk@structuredarts.com; ietf-pkix@imc.org; >> list@seis.nc-forum.com >> Sent: 9/29/98 1:01:30 PM >> Subject: Re: NEW Data type for certificate selection ? >> >> Peter - you went through great lenghts to define the problem with >> relationships between and searching directory based objects and a >> distributed information issue and then you say: >> " >> If anyone has any useful solutions for this (apart from "We should >> force >> everyone to use an X.500 directory, that would solve everything" :-) I'd >> be interested in hearing them. >> >> " >> Oh well - that counts me out. I cannot do solutions - without the >> solution :-))) >> regards alan >> >> Peter. >> > > >----------------- SEIS mailing list (list@seis.nc-forum.com) >Info about this list: http://www.nc-forum.com/seis >SEIS Contact: info@seis.se > > > ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA05527 for ietf-pkix-bks; Tue, 29 Sep 1998 20:00:40 -0700 (PDT) Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA05523 for <ietf-pkix@imc.org>; Tue, 29 Sep 1998 20:00:39 -0700 (PDT) Received: from chromatix.com (cc1020663-a.hwrd1.md.home.com [24.3.62.220]) by chromatix.com (8.8.8/8.8.8) with ESMTP id XAA06421; Tue, 29 Sep 1998 23:07:34 -0400 (EDT) (envelope-from dave@chromatix.com) Message-ID: <36124B27.2FE16E0C@chromatix.com> Date: Wed, 30 Sep 1998 11:15:51 -0400 From: David Horvath <dave@chromatix.com> Organization: @Home Network X-Mailer: Mozilla 4.05 [en]C-AtHome0404 (Win95; U) MIME-Version: 1.0 To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> CC: "'cert-talk@structuredarts.com '" <cert-talk@structuredarts.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz> Subject: Re: NEW Data type for certificate selection ? References: <D1A949D4508DD1119C8100400533BEDC07B96A@DSG1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Alan, While I personally agree that X.500 provides a mature and feature rich core to implement certificate repositories, I am having trouble understanding some of your assertions as to why X.500 is the answer to so many problems. It seems to me that the first step for locating certificates in a repository is to define the fields in the certificate object that are a prerequisite to perform the match. Matching rules are a good start and foster the thought process required to provide a well designed solution. Once the matching rules are defined, a protocol such as DAP or LDAP V3 with extensions may be used to exploit the matching rules. In some cases, clients may choose not to use the matching rules and retrieve all certificates. Perhaps matching rules are not supported by the protocol (LDAP V2 or HTTP), therefore the client will collect all the certificates and perform the match locally. This may be even more efficient than submitting multiple searches with different variations of matching rules. It could easily be more efficient to submit one search and retrieve 10 certificates, then to submit 3 searches with different matching rules each time until the required certificate is found. This should be defined by local policies based on performance analysis. Once the rules for matching certificates are defined ( and I think X.500 matching rules are an excellent start ) the distribution model can be analyzed. This is another case where X.500 may be superior to LDAP, but unless you have a well planned global infrastructure neither X.500 or LDAP can help with the distribution model. Dave Horvath Alan Lloyd wrote: > > > Snip > > ---------- > From: pgut001@cs.auckland.ac.nz > To: cert-talk@structuredarts.com; ietf-pkix@imc.org; > list@seis.nc-forum.com > Sent: 9/29/98 1:01:30 PM > Subject: Re: NEW Data type for certificate selection ? > > Peter - you went through great lenghts to define the problem with > relationships between and searching directory based objects and a > distributed information issue and then you say: > " > If anyone has any useful solutions for this (apart from "We should > force > everyone to use an X.500 directory, that would solve everything" :-) I'd > be interested in hearing them. > > " > Oh well - that counts me out. I cannot do solutions - without the > solution :-))) > regards alan > > Peter. > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06015 for ietf-pkix-bks; Tue, 29 Sep 1998 10:32:40 -0700 (PDT) Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06011 for <ietf-pkix@imc.org>; Tue, 29 Sep 1998 10:32:39 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA18568; Tue, 29 Sep 1998 10:38:57 -0700 (PDT) Message-Id: <4.1.0.67.19980929132920.009c4d20@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.67 (Beta) Date: Tue, 29 Sep 1998 13:30:03 -0400 To: Allen_Rochkind@3com.com From: Russ Housley <housley@spyrus.com> Subject: Re: A question and comment about PKIX - Part 1, Version 11. Cc: ietf-pkix@imc.org In-Reply-To: <8825668D.00778D10.00@hqoutbound.ops.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk Allen: It means that the data in the CRL cannot be used to validate any certificates. Another source of revocation information must be used. Russ At 02:55 PM 9/28/98 -0700, Allen_Rochkind@3com.com wrote: >First the question. In Section 5.2 "CRL Extensions", p. 46, it says: > > "A CRL validation MUST fail if it encounters a critical extension >which it does not know how to process". > >My question is exactly what does it means that a "CRL validation fails"?. >Does this mean that the CRL is to be ignored and that any certificates that >might appear on the CRL are not invalidated by the CRL?. I would suppose >it is that interpretation rather than that a certificate validation fails >if such a CRL is encountered. > >And now a minor comment. I notice that RFC 2044 (on UTF8 strings) has been >obsoleted by RFC 2279. The comment is just to update the RFC reference in >the spec in Appendix A.1 under UTF8String (p.69). > > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA03135 for ietf-pkix-bks; Tue, 29 Sep 1998 05:01:19 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA03131 for <ietf-pkix@imc.org>; Tue, 29 Sep 1998 05:01:18 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA07388; Tue, 29 Sep 1998 08:06:01 -0400 (EDT) Message-Id: <199809291206.IAA07388@ietf.org> To: IETF-Announce: ; Cc: RFC Editor <rfc-editor@isi.edu> Cc: Internet Architecture Board <iab@isi.edu> Cc: ietf-pkix@imc.org From: The IESG <iesg-secretary@ietf.org> Subject: Protocol Action: Internet X.509 Public Key Infrastructure Certificate and CRL Profile to Proposed Standard Date: Tue, 29 Sep 1998 08:06:00 -0400 Sender: owner-ietf-pkix@imc.org Precedence: bulk The IESG has approved the Internet-Draft Internet X.509 Public Key Infrastructure Certificate and CRL Profile <draft-ietf-pkix-ipki-part1-11.txt> as a Proposed Standard. This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Technical Summary The PKIX Working Group is chartered to specify an Internet profile for the use of X.509 certificates. The focus of the profile is to ensure interoperation between implementations that conform to it. The Part I specification defines formats and requirements for Certificates and Certificate Revocation Lists (CRLs). It is part of a suite of documents, but can stand alone. Working Group Summary This document is the tenth revision of the Part I profile document. Input from many members of the community has gone into this draft which the working group has consensus on. Protocol Quality Many experts on Public Key Infrastructure and contributed and commented on this specification. Jeffrey I. Schiller reviewed the document for the IESG. Y2K Compliance The protocols and formats in this document are Year 2000 compliant. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA25568 for ietf-pkix-bks; Tue, 29 Sep 1998 00:26:22 -0700 (PDT) Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA25564 for <ietf-pkix@imc.org>; Tue, 29 Sep 1998 00:26:14 -0700 (PDT) Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA18103; Tue, 29 Sep 1998 09:32:34 +0200 Received: by HYDRA with Microsoft Mail id <01BDEB8B.32948E60@HYDRA>; Tue, 29 Sep 1998 09:26:11 +0200 Message-ID: <01BDEB8B.32948E60@HYDRA> From: Anders Rundgren <anders.rundgren@jaybis.com> To: "'Ed Gerck'" <egerck@laser.cps.softex.br>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Cc: "'Stefan Santesson'" <stefan@accurata.se> Subject: RE: NEW Data type for certificate selection ? Date: Tue, 29 Sep 1998 09:26:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Peter, see in-line comment below. On Tue, 29 Sep 1998, Peter Gutmann wrote: >In that, the server application cannot define anything, at most could >suggest a list of CAs (see below), otherwise it would be easy either >to subvert the user's security choices or do a DoS attack. So, the >server must not be allowed to "help" in a decisive way which user >cert *will* be used -- as though it might seem useful at first: >> In order to make this user friendly, we have to create a mechanism >> where a server can help a client application to select one proper >> certificate out of many. In the example there is just 3 >> certificates to choose among but what if there is 20 or 30? >but such is not safe. The authenticating server may surely *suggest* a list of possible certificates that it may accept because it is always *you* (the user) that should manually select the proper one. In case you feel that a cert with SSN could create a disaster if you accidentally gave it to a wrong server the solution would be to have a local (user-defined) set of valid servers (i.e. their public keys). To insert a new server would require a few more clicks. I.e. similar to ActiveX controls or signed Java Applets. Such servers would typically be governmental (who gave you the SSN) and a *few* other parties that you hopefully trust like your bank or employer. A similar scheme could be used for defining a list of valid receivers of mail signed with a cert containing an SSN (or other sensitive information). I will come back soon with a server-to-cert selection scheme. Anders Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA07285 for ietf-pkix-bks; Mon, 28 Sep 1998 15:25:34 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA07281 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 15:25:33 -0700 (PDT) Message-Id: <199809282225.PAA07281@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta) Date: Mon, 28 Sep 1998 15:31:45 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: A question and comment about PKIX - Part 1, Version 11. In-Reply-To: <8825668D.00778D10.00@hqoutbound.ops.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk >And now a minor comment. I notice that RFC 2044 (on UTF8 strings) has been >obsoleted by RFC 2279. The comment is just to update the RFC reference in >the spec in Appendix A.1 under UTF8String (p.69). Yes, please, since RFC 2279 had some technical corrections to RFC 2044, I believe. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA07078 for ietf-pkix-bks; Mon, 28 Sep 1998 14:49:02 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA07074 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 14:49:01 -0700 (PDT) From: Allen_Rochkind@3com.com Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id OAA21156 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 14:55:57 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id OAA06803 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 14:55:56 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 8825668D.007878E7 ; Mon, 28 Sep 1998 14:55:52 -0700 X-Lotus-FromDomain: 3COM To: ietf-pkix@imc.org Message-ID: <8825668D.00778D10.00@hqoutbound.ops.3com.com> Date: Mon, 28 Sep 1998 14:55:42 -0700 Subject: A question and comment about PKIX - Part 1, Version 11. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk First the question. In Section 5.2 "CRL Extensions", p. 46, it says: "A CRL validation MUST fail if it encounters a critical extension which it does not know how to process". My question is exactly what does it means that a "CRL validation fails"?. Does this mean that the CRL is to be ignored and that any certificates that might appear on the CRL are not invalidated by the CRL?. I would suppose it is that interpretation rather than that a certificate validation fails if such a CRL is encountered. And now a minor comment. I notice that RFC 2044 (on UTF8 strings) has been obsoleted by RFC 2279. The comment is just to update the RFC reference in the spec in Appendix A.1 under UTF8String (p.69). Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA06782 for ietf-pkix-bks; Mon, 28 Sep 1998 14:07:46 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA06778 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 14:07:43 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX3528L9>; Tue, 29 Sep 1998 07:11:57 +1000 Message-ID: <D1A949D4508DD1119C8100400533BEDC07B96A@DSG1> From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> To: "'cert-talk@structuredarts.com '" <cert-talk@structuredarts.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz> Subject: RE: NEW Data type for certificate selection ? Date: Tue, 29 Sep 1998 07:11:56 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk Snip ---------- From: pgut001@cs.auckland.ac.nz To: cert-talk@structuredarts.com; ietf-pkix@imc.org; list@seis.nc-forum.com Sent: 9/29/98 1:01:30 PM Subject: Re: NEW Data type for certificate selection ? Peter - you went through great lenghts to define the problem with relationships between and searching directory based objects and a distributed information issue and then you say: " If anyone has any useful solutions for this (apart from "We should force everyone to use an X.500 directory, that would solve everything" :-) I'd be interested in hearing them. " Oh well - that counts me out. I cannot do solutions - without the solution :-))) regards alan Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA06221 for ietf-pkix-bks; Mon, 28 Sep 1998 12:40:54 -0700 (PDT) Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06217 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 12:40:51 -0700 (PDT) Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id QAA25781; Mon, 28 Sep 1998 16:47:26 -0300 Date: Mon, 28 Sep 1998 16:47:25 -0300 (EST) From: Ed Gerck <egerck@laser.cps.softex.br> To: Peter Gutmann <pgut001@cs.auckland.ac.nz> cc: cert-talk@structuredarts.com, ietf-pkix@imc.org, list@seis.nc-forum.com Subject: Re: NEW Data type for certificate selection ? In-Reply-To: <199809281406.HAA29579@gateway-ext.StructuredArts.COM> Message-ID: <Pine.LNX.4.02.9809281408220.25643-100000@laser.cps.softex.br> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-pkix@imc.org Precedence: bulk On Tue, 29 Sep 1998, Peter Gutmann wrote: >Stefan Santesson <stefan@accurata.se> writes: > >>The problem I want to solve is how to pick 1 out of many certificates within >>an end user application. > >>The problem is how to select the right certificate in every suitable occasion >>when several certificates is accessed by the same application. > >>In order to make this user friendly, we have to create a mechanism where a >>server can help a client application to select one proper certificate out of >>many. In the example there is just 3 certificates to choose among but what if >>there is 20 or 30? > >This was something I looked at about 6 months ago while trying to come up with >a general abstraction for a certificate store. The problem you face is that >while it's easy enough to go from certificate -> capabilities, it's very >difficult to go from capabilities -> certificate. Put another way, given a >cert it's easy to answer the query "Can I do X with this", but given a >collection of certs it's very difficult to answer the query "Which cert is >required to do X". Stefan and Peter: As I understood, Stefan's problem (and examples) was pertinent to *signing* and *user authentication*. Specifically, this leads to two different subproblems, which are how to: 1. select which user's private-key should be used in response to a web *signing* query to be done by the user -- when many private-keys exist that can be accessed by the same application (eg, web browser), and 2. select which user public-key certificate should be exported in response to a web *authentication* query on the user, without exporting any public-key cert that has sensitive attribute data (eg, Alice's SSN). Of course, one can argue that "public-key certs" are just what the name implies -- public. Hence, sensitive private data such as SSN should not be stored in them and it is immaterial which public-key cert you export, securitywise and privacywise. In this line of thought, if hardpressed one would include a hash of the sensitive data in the public cert but never the data itself. In this scenario, subproblem (2) is trivial: select any or all. Subproblem (1) is not trivial, due to non-repudiation bits and other qualifiers, but is answered by each application and its user customization/history -- how it allows signing to be done (eg, if signing is automatic, if it requires a yes/no decision, if it needs a passphrase, etc.), how each private-key certificate is stored (eg, in plain-text, off-line in a SC, encrypted, etc.), and so on. However, if we accept that there may be valid uses for "public-key certs" which are not public, with all the security and privacy risks that may ensue from such usage (such as when Bill trusts Monica that trusts Linda; or, when Bill cannot revoke a token that was given to Monica and which unfortunately Monica had to surrender) -- then we must consider that each "non-public" public-key cert and private-key will be handled either by a special application or by an interactive and possibly customized procedure in a general application (eg, a web browser). Which then answers subproblems (1) and (2) also for "non-public" public-key certs. In that, the server application cannot define anything, at most could suggest a list of CAs (see below), otherwise it would be easy either to subvert the user's security choices or do a DoS attack. So, the server must not be allowed to "help" in a decisive way which user cert *will* be used -- as though it might seem useful at first: >> In order to make this user friendly, we have to create a mechanism >> where a server can help a client application to select one proper >> certificate out of many. In the example there is just 3 >> certificates to choose among but what if there is 20 or 30? but such is not safe. Regarding Peter's statements above, they seem to address a more general scenario where also server authentication is involved -- not just user signing/authentication. The server already sends a list of server acceptable CAs, to the client in SSL, but indeed that does not help much as the server is gropping in the dark as to what CAs would be acceptable to the user and what their capabilities might be acceptable to the user at the time. Which seems to need a deeper look in terms of Peter's two questions, also as we ask ourselves if the first question (ie, the relation certificate -> capabilities) is really "easy enough" in a more general scenario. Cheers, Ed Gerck ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br http://novaware.cps.softex.br Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA05133 for ietf-pkix-bks; Mon, 28 Sep 1998 10:36:01 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA05129 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 10:36:00 -0700 (PDT) Received: id NAA23349; Mon, 28 Sep 1998 13:40:24 -0400 Received: by gateway id <TTXVY461>; Mon, 28 Sep 1998 13:36:56 -0400 Message-ID: <D789F71F24B4D111955D00A0C99B4F500139B046@sothmxs01.entrust.com> From: Robert Zuccherato <robert.zuccherato@entrust.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: Time Stamp and Notary Drafts Date: Mon, 28 Sep 1998 13:36:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk As some of you may have noticed, I have submitted the latest versions of our Time Stamp and Data Certification Server drafts as PKIX Internet Drafts, in accordance with the decisions made in Chicago. These drafts are based on the drafts that we have been submitting independently on these topics for some time now and reporting to PKIX on their progress. The Time Stamp Draft describes a protocol in which a trusted Time Stamp Authority provides evidence that a message existed at a particular point in time. It is available at: http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt The Data Certification Server provides "notary" type services (signature validation, certificate path validation) in support of non-repudiation. This draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt As usual, comments are welcome. Robert Zuccherato. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA03570 for ietf-pkix-bks; Mon, 28 Sep 1998 07:54:56 -0700 (PDT) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA03564 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 07:54:54 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id DAA31163; Tue, 29 Sep 1998 03:01:30 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90699489017466>; Tue, 29 Sep 1998 03:01:30 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: cert-talk@structuredarts.com, ietf-pkix@imc.org, list@seis.nc-forum.com Subject: Re: NEW Data type for certificate selection ? Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Tue, 29 Sep 1998 03:01:30 (NZST) Message-ID: <90699489017466@cs26.cs.auckland.ac.nz> Sender: owner-ietf-pkix@imc.org Precedence: bulk Stefan Santesson <stefan@accurata.se> writes: >The problem I want to solve is how to pick 1 out of many certificates within >an end user application. >The problem is how to select the right certificate in every suitable occasion >when several certificates is accessed by the same application. >In order to make this user friendly, we have to create a mechanism where a >server can help a client application to select one proper certificate out of >many. In the example there is just 3 certificates to choose among but what if >there is 20 or 30? This was something I looked at about 6 months ago while trying to come up with a general abstraction for a certificate store. The problem you face is that while it's easy enough to go from certificate -> capabilities, it's very difficult to go from capabilities -> certificate. Put another way, given a cert it's easy to answer the query "Can I do X with this", but given a collection of certs it's very difficult to answer the query "Which cert is required to do X". Take the example of using a cert for email encryption. You start by trying a search for one of the extKeyUsage's which cover email encryption. If this fails you try again with a Netscape cert-type. If that fails you try again with one of the appropriate keyUsage's. Finally, if that fails you try again with no particular usage specified. This is an incredible pain to do, especially since each step can involve matching on multiple usage attributes, possibly with some sort of preferred order for a match. I never really came up with a solution for this, the best I could do was define a meta-attribute which summarised the various usage types in a single place so I could perform a single query to match on "name = foo and usage = mail encryption" (rather than arbitrary numbers of queries with the possibility of conflicting usages). The disadvantages of this are that you have to keep extending it to cover new usage types, and it needs to be stored somewhere other than the cert itself. My general idea was to include a kind of TLB mechanism for cert lookups which would allow (reasonably) fast and simple matching for frequently-used certs, but this is messy to do in an abstract manner. After discussing it with various people I dropped it into the "leave it for the next release" basket. If anyone has any useful solutions for this (apart from "We should force everyone to use an X.500 directory, that would solve everything" :-) I'd be interested in hearing them. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA03363 for ietf-pkix-bks; Mon, 28 Sep 1998 07:26:38 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA03359 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 07:26:37 -0700 (PDT) Message-Id: <199809281426.HAA03359@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta) Date: Mon, 28 Sep 1998 07:32:49 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: Questions about PKIX In-Reply-To: <8525668D.002BF40F.00@mta2.lotus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk Actually, those are questions about a specific PKIX implementation. As announced here earlier, that's being discussed on a different mailing list. See <http://www.imc.org/imc-pfl/> for information about signing up for the list and all the news that is known about the product. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA02828 for ietf-pkix-bks; Mon, 28 Sep 1998 06:08:00 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA02824 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 06:07:58 -0700 (PDT) Received: id JAA14392; Mon, 28 Sep 1998 09:12:56 -0400 Received: by gateway id <TTXVYTLB>; Mon, 28 Sep 1998 09:09:28 -0400 Message-ID: <D789F71F24B4D111955D00A0C99B4F500206DD8A@sothmxs01.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au> Cc: "'Warwick Ford'" <wford@verisign.com>, "'Steve Kent'" <kent@bbn.com> Subject: RE: comments on draft-ietf-pkix-ipki2opp-08.txt Date: Mon, 28 Sep 1998 09:07:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Hi Alan, The PKIX WG embarked on this spec well over a year ago with the primary purpose being to standardize what was predominantly deployed at that time - LDAPv2 for use to access PKI repositories. A minimum subset of the LDAPv2 protocol was profiled, in order to enable relying party and certification authority systems to be able to access LDAP server PKI repositories without needing all the code a typical LDAP client would have. We were not attempting to standardize server to server communications, only a protocol for clients (relying parties and CAs) to use to access the repository. While I personally agree with some of your views about the more comprehensive functionality that can be provided in an X.500 based distributed systems environment, that wasn't the task we undertook. As the work on LDAPv2 dragged on and on and on we qestioned several times within the WG whether to drop this activity and concentrate instead on a more 'modern' directory technology such as LDAPv3, but every time this was raised, the PKIX WG agreed to proceed with the LDAPv2 specs and get them progressed since this is still a very widely deployed protocol, even though there is plenty of interest in LDAPv3 as well. The LDAPv2 protocol profile completed PKIX WG last call in January and the schema spec just a short time ago. No changes have been made to the protocol spec, the only reason it was re-issued was because it was about to expire becasue the schema spec (required for IESG approval of the protocol profile) took so long. I hope this answers your questions on 'why' the LDAP activity. Sharon > ---------- > From: Alan Lloyd[SMTP:Alan.Lloyd@OpenDirectory.com.au] > Sent: September 27, 1998 6:24 PM > To: 'ietf-pkix@imc.org' > Subject: comments on draft-ietf-pkix-ipki2opp-08.txt > > Comments: Internet X.509 Public Key Infrastructure > Operational Protocols - LDAPv2 > > Sorry for being my usual self. But what does this document do or solve. > > All it states is use LDAP V2 to a PKI repository? and highlights the > major failings of LDAP encoding when dealing with certificate attributes > with multiple values. ie. In that the client gets the lot (every > certificate - regardless) -- and if the client goes for CRLs as well - > and they are multi values of a CRL attribute - the client will get the > lot as well. > > Lets do some rough sums. A cert = 600 - 2k bytes average 1kb, 5-10 certs > per user, 3 certs in a path.. transfer = 20- 30kb just to verify a > signature. In addition CRLs - bad sites, and they could get large. > And LDAP accesses for the certs could be via referrals. Lets say that > we could be looking at optimistically at 10-30 seconds of validation > time. > I would be happy to be corrected here.. > > > Fundamental Problems with LDAP > > LDAP servers are "string based" and non distributed - hence the need to > use X.500 and migrate these LDAP servers to a distributed architecture. > Not all certificates one wishes to deal with will be in your local ldap > server - they will be in the directory system that one cooperates with. > > X.500 has certficate matching rules to enable selection of certificates > within a multi value attribute. > > I am not sure what cert matching rules LDAP servers have or even if they > support multi valued att matching or if they are compatible with X.500. > Again the encoding restrictions in LDAP could imply the non use of > these. > > It is obvious to most that LDAP is not very good generally and in the > case of PKI / certficate issues over a wider scale, totally unusable. > > In addition the process one builds into an LDAP client to deal with > referrals and LDAP certficate servers has to be lot larger and therefore > problematic, than that that uses distributed directories with sound > matching rules. > > ie. the best it can get depends on the tools to hand. > > I therefore beg why the document is being put forward because IMHO - it > promotes systems to be built that will not provide the business utility > demanded by companies using large scale EC/509 technologies. The result > can only be commercial disasters and pain for both suppliers and the > poor customer. > > Oh well - > > regards alan > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA02819 for ietf-pkix-bks; Mon, 28 Sep 1998 06:07:45 -0700 (PDT) Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA02815 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 06:07:43 -0700 (PDT) Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id WAA08964; Mon, 28 Sep 1998 22:03:40 +0900 (JST) Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA04781; Mon, 28 Sep 98 22:08:15 JST Received: from katase.katase.isl.melco.co.jp ([133.141.13.135]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with SMTP id WAA15195; Mon, 28 Sep 1998 22:20:13 +0900 (JST) Received: from iss.iss.isl.melco.co.jp by katase.katase.isl.melco.co.jp (4.1/6.4J.6-katase-2/) id AA27264; Mon, 28 Sep 98 22:14:03 JST Received: from zaku by iss.iss.isl.melco.co.jp (1.38.193.4/6.4J.6-isl2-2/iss-master) id AA23057; Mon, 28 Sep 1998 22:14:02 +0900 Message-Id: <360F8B0E.D3FD99CC@iss.isl.melco.co.jp> Date: Mon, 28 Sep 1998 22:11:42 +0900 From: "=?iso-2022-jp?B?GyRCNUhJcCEhPV8bKEI=?=" <yositake@iss.isl.melco.co.jp> X-Mailer: Mozilla 4.05 [ja] (Win95; I) Mime-Version: 1.0 To: Stefan Santesson <stefan@accurata.se> Cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'cert-talk@structuredarts.com '" <cert-talk@structuredarts.com> Subject: Re: NEW Data type for certificate selection ? References: <3.0.32.19980928111642.00a76390@m1.403.telia.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Mr. Santesson, I am not necessarily against you. I write all of my comments below because I would like to contribute to this issue. Stefan Santesson wrote: > Let me clarify my case. > > The problem I want to solve is how to pick 1 out of many certificates > within an end user application. > I think that the real problem is how an application select a suitable (or correct) certificate when there are multiple applications and multiple certificates within one PC. In your example below, S/MIME and another application (say, application X) hold Cert 1 in common. If we limit the situation to e-mail applications, this may be easy, but how do we realize it in a generalized way ? > An example. > > Alice has 4 certificates. > 1) E-mail based ID with low security > 2) Anonymous cert used for anonymous information services. > 3) Qualified ID-certificate (with her social security number) > 4) VISA SET-certificate. > > In this example: > - Cert 1 and 2 are issued by the same CA and have the same key usage. > - Cert 3 has key usage non-repudiation > > The problem is how to select the right certificate in every suitable > occasion when several certificates is accessed by the same application. > Clearly certificate 4 is no problem since it is used by a separate > application (the SET wallet). So starting the SET wallet application > automatically selects the right certificate. > > The problem in this case is not even S/MIME since Alice in this example > only uses certificate 1 in her mail application. > > Here the problem is her web-based applications since she use certificate > 1,2 and 3 with her browser. So every time she is asked to make a signature > or authenticate via TLS, there is a risk that she will select and export > the wrong certificate. In some cases maybe with a very unpleasant result. > In this example, I think the client application needs two kinds of information: which application it is and which level of security it needs. Something like "application identifier" and "secuirty level identifier" are necessary ? (Honestly speaking, I myself don't like the idea, "let's register an object identifier for each application in the world". Somebody has a good idea for this ?) Or something like "security context" which can determine a suitable certificate from among Cert 1, 2, or 3 ? > In order to make this user friendly, we have to create a mechanism where a > server can help a client application to select one proper certificate out > of many. In the example there is just 3 certificates to choose among but > what if there is 20 or 30? > This is not limited to that a server can help a client application. I think there is a case where a client application has to "think" which certificate it must select for itself. (I mean, without help from other party.) I think there is a case where an application has to select a certificate before it begins to communicate with other party, especially in the case of peer to peer communication. > The way to do this is, as I would suggest, a 2 step process: > 1) To define a general selective mechanism (such as the X.500 match rule) > 2) Get protocols, script languages and applications to support this. > Regretfully, the X.500 matching rule doesn't have "application identifer", "security level identifer", "security context", or something like that. I think we have to think a new mechanism outside it, if we don't modify or enhance it any more. > So this is not about whether selection should be done based on issuer name, > policy OID pr something else, but instead how to define a general > mechanisms which allows customized selection rules within a broad range of > applications and protocols. (In step 2 it is also about how a certificate > can be stored and marked so it won't be exported by any application without > the consent from its owner.) > For this purpose, too, I think we need a general mechanism to store and to select (namely, to manage) certificates within one machine. > I still think that The X.500 certificateMatch rule sounds interesting. > Is there any will to go further in this process? > As I said, I think we have to think a new mechanism outside the X.500 matching rules. I also think we can use the X.500 matching rules if we have some pieces of information within a certificate, but that in the situation which we are thinking, we are trying to select a certificate based on the information outside the certificate. (This is the one reason that I think of the term, "security context".) > To us this is a MAJOR factor for succeeding with a broad CA business case > and the vendors picking up this line will at least be in favor in those > procurements that I'm involved in. > > /Stefan (snip) Actually I have designed a system where there are a few applications and a few certificates in one PC. And I faced the problem how an application could select a suitable or correct certificate. In the end, I used something like "application identifier" for that system. But as I said, to "register an object identifier for each application in the world" don't seem to be a good idea. I have kept seeking a good solution since then ... Sorry that I can't show a clear and good solution, but I hope my comments will be of some help. Regards, Jun Yoshitake Mitsubishi Electric Corp. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA02371 for ietf-pkix-bks; Mon, 28 Sep 1998 05:12:10 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA02367 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 05:12:08 -0700 (PDT) Received: id IAA05607; Mon, 28 Sep 1998 08:16:44 -0400 Received: by gateway id <TTXVYT12>; Mon, 28 Sep 1998 08:13:15 -0400 Message-ID: <D789F71F24B4D111955D00A0C99B4F500206DD84@sothmxs01.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: "'Santosh Chokhani'" <chokhani@cygnacom.com> Cc: ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt Date: Mon, 28 Sep 1998 08:13:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Hi Santosh, This mechanism does allow Delta CRLs to be included in pkiCA entries. Both pkiCA and deltaCRL are auxiliary object classes. Multiple auxiliary object classes can be present in the same directory entry. Only one structural object class can be present in that same entry. For example, a CA entry could also be an organization entry. In that case, organization would be the structural object class. pkiCA would be an auxiliary class present in the same entry. If that CA used delta CRLs then the deltaCRL auxiliary object class would also be present in the same entry. The primary difference between structural and auxiliary object classes is that the structural object class is the one that is used to base the naming and the entry's location in in a directory tree structure, that's the reason there can only be one present in each entry. Auxiliary classes do not have this restriction. By defining the separate class for deltas we are now able to add them, in a uniform way, to entries of other types in future (e.g. possibly in attribute authority). Hope this helps. Happy to discuss further if required, give me a call. Sharon > ---------- > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > Sent: September 27, 1998 12:32 PM > To: 'Internet-Drafts@ietf.org' > Cc: ietf-pkix@imc.org > Subject: RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt > > I find the schema acceptable for the certificates. > > I do not find the schema acceptable for delta CRL. I thought we had a > mechanism by which delta CRL could be stored in the object class pkiCA. > It does not seem to be the case. Sharon, I assume you recall the > comment and resolution in this forum. > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] > > Sent: Thursday, September 24, 1998 10:27 AM > > Cc: ietf-pkix@imc.org > > Subject: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Public-Key Infrastructure (X.509) > > Working Group > > of the IETF. > > > > Title : Internet X.509 Public Key Infrastructure > > LDAPv2 Schema > > Author(s) : S. Boeyen, T. Howes, P. Richard > > Filename : draft-ietf-pkix-ldapv2-schema-02.txt > > Pages : 7 > > Date : 23-Sep-98 > > > > The schema defined in this document is a minimal schema to > > support > > PKIX in an LDAPv2 environment, as defined in > > draft-ietf-pkix- > > ipki2opp-07.txt. Only PKIX-specific components are specified > > here. > > LDAP servers, acting as PKIX repositories should support the > > auxi- > > liary object classes defined in this specification and > > integrate > > this schema specification with the generic and other > > application- > > specific schemas as appropriate, depending on the services to > > be > > supplied by that server. > > > > The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', > > 'RECOMMENDED', > > and 'MAY' in this document are to be interpreted as described > > in > > RFC 2119. > > > > Please send comments on this document to the ietf-pkix@imc.org > > mail > > list. > > > > Internet-Drafts are available by anonymous FTP. Login with the > > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-pkix-ldapv2-schema-02.txt". > > A URL for the Internet-Draft is: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-02.tx > > t > > > > Internet-Drafts directories are located at: > > > > Africa: ftp.is.co.za > > > > Europe: ftp.nordu.net > > ftp.nis.garr.it > > > > Pacific Rim: munnari.oz.au > > > > US East Coast: ftp.ietf.org > > > > US West Coast: ftp.isi.edu > > > > Internet-Drafts are also available by mail. > > > > Send a message to: mailserv@ietf.org. In the body type: > > "FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-02.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. << Message: Untitled Attachment >> > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA29636 for ietf-pkix-bks; Mon, 28 Sep 1998 02:14:15 -0700 (PDT) Received: from mailc.telia.com (root@mailc.telia.com [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA29632 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 02:14:11 -0700 (PDT) Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id LAA01066; Mon, 28 Sep 1998 11:20:25 +0200 (MET DST) Received: from stefans (t4o68p93.telia.com [62.20.139.213]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id LAA29513; Mon, 28 Sep 1998 11:20:09 +0200 (CEST) Message-Id: <3.0.32.19980928111642.00a76390@m1.403.telia.com> X-Sender: u40400192@m1.403.telia.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 28 Sep 1998 11:17:31 +0200 To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'cert-talk@structuredarts.com '" <cert-talk@structuredarts.com> From: Stefan Santesson <stefan@accurata.se> Subject: RE: NEW Data type for certificate selection ? Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA29633 Sender: owner-ietf-pkix@imc.org Precedence: bulk Let me clarify my case. The problem I want to solve is how to pick 1 out of many certificates within an end user application. An example. Alice has 4 certificates. 1) E-mail based ID with low security 2) Anonymous cert used for anonymous information services. 3) Qualified ID-certificate (with her social security number) 4) VISA SET-certificate. In this example: - Cert 1 and 2 are issued by the same CA and have the same key usage. - Cert 3 has key usage non-repudiation The problem is how to select the right certificate in every suitable occasion when several certificates is accessed by the same application. Clearly certificate 4 is no problem since it is used by a separate application (the SET wallet). So starting the SET wallet application automatically selects the right certificate. The problem in this case is not even S/MIME since Alice in this example only uses certificate 1 in her mail application. Here the problem is her web-based applications since she use certificate 1,2 and 3 with her browser. So every time she is asked to make a signature or authenticate via TLS, there is a risk that she will select and export the wrong certificate. In some cases maybe with a very unpleasant result. In order to make this user friendly, we have to create a mechanism where a server can help a client application to select one proper certificate out of many. In the example there is just 3 certificates to choose among but what if there is 20 or 30? The way to do this is, as I would suggest, a 2 step process: 1) To define a general selective mechanism (such as the X.500 match rule) 2) Get protocols, script languages and applications to support this. So this is not about whether selection should be done based on issuer name, policy OID pr something else, but instead how to define a general mechanisms which allows customized selection rules within a broad range of applications and protocols. (In step 2 it is also about how a certificate can be stored and marked so it won't be exported by any application without the consent from its owner.) I still think that The X.500 certificateMatch rule sounds interesting. Is there any will to go further in this process? To us this is a MAJOR factor for succeeding with a broad CA business case and the vendors picking up this line will at least be in favor in those procurements that I'm involved in. /Stefan At 09:30 AM 9/27/98 +1000, Alan Lloyd wrote: >Yes I have views - see my draft lloyd-dir-cert-stat .. > >First one needs a fully distributed directory system. >Then one needs a good set of certificate matching rules in that >directory system to permit the selection of certficate components. >Including rules that can handle multi valued attributes. >Then one needs directory based certficate searches based on client >business semantics. >And then one needs certficate paths to associated with business >semantics in a trusted way rather than just crypto-cert-issuerId >mechanisms. > >I dont see the problem, simply because one has to add something else to >certs and pkis to make them work in a scaleable and useful way - and >that is big directory systems, matching rules that assist the >verification and a business information model that supports the >cert/crypto mechanisms. > > >I do not believe one will achieve much with to fix this issue without an >operational, business and information perspective. > > >just thoughts >regards alan > > > >---------- >From: Stefan Santesson >To: ietf-pkix@imc.org; list@seis.nc-forum.com; ietf-tls@consensus.com; >cert-talk@structuredarts.com >Sent: 9/24/98 10:41:23 PM >Subject: NEW Data type for certificate selection ? > >All, > >During the TLS session in Chicago (IETF meeting) I discussed with Jeff >Weinstein, Netscape, the problem of certificate selection in an >environment >where the client is populated with many similar certificates for >different >purposes. > >We concluded that this is a general problem, not only for TLS, but for >S/MIME, Java, Java script, etc, where signing and encryption based on an >X.509 PKI is an option. I also conclude that the current TLS approach, >using Issuer name as selection criteria, is hopelessly insufficient for >the >general case. > >In fact we can NEVER claim that we have an X.509 based architecture >ready >for the big market IF WE DON'T SOLVE THIS PROBLEM. > >A normal user (I.e grandmother) will never be able to pick the right >certificate by herself, if there is more than 1 to pick. > >The question raised here is: > >WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD >START. > >If we could create a standardized ASN.1 data type with the purpose of >defining the criteria for selecting 1 out of n certificates, then this >could be used as a common base for enhancing TLS, Java, Java script, >S/MIME >etc. > >The data type could be communicated from server to client, client to >server, server to server, client to client; I.e in any case where one >party >which to assist another party in selecting an appropriate certificate >for >any purpose (defined by the context). > >Do anyone have a better idea. > >I think this is a lost problem that has to be fixed, hopefully in a >standardized way. > >Comments, suggestions. > >/Stefan Santesson >------------------------------------------------------------------- >Stefan Santesson <stefan@accurata.se> >Accurata Systemsäkerhet AB >Lotsgatan 27 D Tel. +46-40 152211 >216 42 Malmö Fax. +46-40 150790 >Sweden Mobile +46-70 5247799 > >PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 >------------------------------------------------------------------- > > > ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA29311 for ietf-pkix-bks; Mon, 28 Sep 1998 01:12:47 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA29307 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 01:12:40 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX3528J0>; Mon, 28 Sep 1998 18:16:46 +1000 Message-ID: <D1A949D4508DD1119C8100400533BEDC07B94C@DSG1> From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'tyone '" <tyone@iss.isl.melco.co.jp> Subject: RE: NEW Data type for certificate selection ? Date: Mon, 28 Sep 1998 18:16:45 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk Tyone - the problem gets worse if one uses extensions - It means one is tying (by cryptography) the local context/usage of a certificate. And as you say, contexts may not be universal. In fact scaleability will hit once we force "application" tags into certificates, simply because - as you say, usage identifiers are open ended. Nothing will be perfect in this space, but my preference is to have certificate/permissions/business information approach that ties the crypto trust components to the User capabilities and applies these into a business context - all of which must be designed from a directory information perspective because of the authentication, access control, distribution and validation requirements demanded. As said, the requirement is to have a trusted EC environment. The components of such an environment include cert based fns, distributed dirs and a business/organisational directory schema and (as small as possible) client applications that rely on such services. Adding an extension in my mind does not solve the problem, it simply creates more because the "fix" is in the wrong place. And as you say correctly - its hard and difficult which just indicates IMHO that the problem is somewhere else. I personally think that one cannot add anymore detail to PKI/509 becuase the problems that are now being discussed are the limitations of LDAP to support efficient and scaleable PKI systems (when X.500 should be used) and the application,performance and trust of certificate based systems now depend on the application they are used for. And these are cost, operational, assurance and cost related issues. regards alan ---------- From: tyone To: ietf-pkix@imc.org Sent: 9/28/98 12:19:19 PM Subject: Re: NEW Data type for certificate selection ? Hi. What do you think of the idea that using cert policies extension for this purpose? The reason is, cert policies extension indicating how the certificate has been issued, and how the certificate should be used. If two different certificates have the same cert policies extension value and one can be used for application A, then it is reasonable that the other can be used for application A. if we decide to introduce a new extension or a new ASN1 field to X509 format, ,which indicates what kinds of applications can use the certificate, we first have to categorize applications from some view points( data sensitivity?). This categorizing work seems to be very hard and difficult. Takeshi Yoneda Mitsubishi Electric Corp. >All, >During the TLS session in Chicago (IETF meeting) I discussed with Jeff >Weinstein, Netscape, the problem of certificate selection in an environment >where the client is populated with many similar certificates for different >purposes. >We concluded that this is a general problem, not only for TLS, but for >S/MIME, Java, Java script, etc, where signing and encryption based on an >X.509 PKI is an option. I also conclude that the current TLS approach, >using Issuer name as selection criteria, is hopelessly insufficient for the >general case. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA28865 for ietf-pkix-bks; Mon, 28 Sep 1998 00:48:15 -0700 (PDT) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA28861 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 00:48:14 -0700 (PDT) From: Stefan_Salzmann/HAM/Lotus@lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id DAA10830 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 03:59:14 -0400 (EDT) Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id DAA28532 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 03:53:32 -0400 (EDT) Received: by mta2.lotus.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 8525668D.002BF5DA ; Mon, 28 Sep 1998 04:00:09 -0400 X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA To: ietf-pkix@imc.org cc: Helmut_Speichermann/FRA/Lotus@lotus.com, Boris_Baltzer/MUC1/Lotus@lotus.com, Georg_Zyprian/FRA/Lotus@lotus.com Message-ID: <8525668D.002BF40F.00@mta2.lotus.com> Date: Mon, 28 Sep 1998 09:51:59 +0200 Subject: Questions about PKIX Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk Hi, I have got some questions concerning PKIX. So here they are: When will be the code of the PKIX reference available at the MIT Web Pages? What is Jonah in relation to PKIX? When starts the PKIX developers converence in October? Are there already White Papers available? Thanks for answering, Regards Stefan Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA10325 for ietf-pkix-bks; Sun, 27 Sep 1998 19:17:09 -0700 (PDT) Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA10321 for <ietf-pkix@imc.org>; Sun, 27 Sep 1998 19:17:07 -0700 (PDT) Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id LAA05603 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 11:13:31 +0900 (JST) Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA27021; Mon, 28 Sep 98 11:18:05 JST Received: from katase.katase.isl.melco.co.jp ([133.141.13.135]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with SMTP id LAA04167 for <ietf-pkix@imc.org>; Mon, 28 Sep 1998 11:30:03 +0900 (JST) Received: from iss.iss.isl.melco.co.jp by katase.katase.isl.melco.co.jp (4.1/6.4J.6-katase-2/) id AA15585; Mon, 28 Sep 98 11:23:54 JST Received: from edberg by iss.iss.isl.melco.co.jp (1.38.193.4/6.4J.6-isl2-2/iss-master) id AA09263; Mon, 28 Sep 1998 11:23:53 +0900 Message-Id: <360EF227.7D17CD5B@iss.isl.melco.co.jp> Date: Mon, 28 Sep 1998 11:19:19 +0900 From: tyone <tyone@iss.isl.melco.co.jp> X-Mailer: Mozilla 4.05 [ja] (WinNT; I) Mime-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: NEW Data type for certificate selection ? Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Hi. What do you think of the idea that using cert policies extension for this purpose? The reason is, cert policies extension indicating how the certificate has been issued, and how the certificate should be used. If two different certificates have the same cert policies extension value and one can be used for application A, then it is reasonable that the other can be used for application A. if we decide to introduce a new extension or a new ASN1 field to X509 format, ,which indicates what kinds of applications can use the certificate, we first have to categorize applications from some view points( data sensitivity?). This categorizing work seems to be very hard and difficult. Takeshi Yoneda Mitsubishi Electric Corp. >All, >During the TLS session in Chicago (IETF meeting) I discussed with Jeff >Weinstein, Netscape, the problem of certificate selection in an environment >where the client is populated with many similar certificates for different >purposes. >We concluded that this is a general problem, not only for TLS, but for >S/MIME, Java, Java script, etc, where signing and encryption based on an >X.509 PKI is an option. I also conclude that the current TLS approach, >using Issuer name as selection criteria, is hopelessly insufficient for the >general case. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA09408 for ietf-pkix-bks; Sun, 27 Sep 1998 15:20:57 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA09403 for <ietf-pkix@imc.org>; Sun, 27 Sep 1998 15:20:53 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TX352825>; Mon, 28 Sep 1998 08:24:58 +1000 Message-ID: <D1A949D4508DD1119C8100400533BEDC07B944@DSG1> From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: comments on draft-ietf-pkix-ipki2opp-08.txt Date: Mon, 28 Sep 1998 08:24:56 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk Comments: Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 Sorry for being my usual self. But what does this document do or solve. All it states is use LDAP V2 to a PKI repository? and highlights the major failings of LDAP encoding when dealing with certificate attributes with multiple values. ie. In that the client gets the lot (every certificate - regardless) -- and if the client goes for CRLs as well - and they are multi values of a CRL attribute - the client will get the lot as well. Lets do some rough sums. A cert = 600 - 2k bytes average 1kb, 5-10 certs per user, 3 certs in a path.. transfer = 20- 30kb just to verify a signature. In addition CRLs - bad sites, and they could get large. And LDAP accesses for the certs could be via referrals. Lets say that we could be looking at optimistically at 10-30 seconds of validation time. I would be happy to be corrected here.. Fundamental Problems with LDAP LDAP servers are "string based" and non distributed - hence the need to use X.500 and migrate these LDAP servers to a distributed architecture. Not all certificates one wishes to deal with will be in your local ldap server - they will be in the directory system that one cooperates with. X.500 has certficate matching rules to enable selection of certificates within a multi value attribute. I am not sure what cert matching rules LDAP servers have or even if they support multi valued att matching or if they are compatible with X.500. Again the encoding restrictions in LDAP could imply the non use of these. It is obvious to most that LDAP is not very good generally and in the case of PKI / certficate issues over a wider scale, totally unusable. In addition the process one builds into an LDAP client to deal with referrals and LDAP certficate servers has to be lot larger and therefore problematic, than that that uses distributed directories with sound matching rules. ie. the best it can get depends on the tools to hand. I therefore beg why the document is being put forward because IMHO - it promotes systems to be built that will not provide the business utility demanded by companies using large scale EC/509 technologies. The result can only be commercial disasters and pain for both suppliers and the poor customer. Oh well - regards alan Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA08414 for ietf-pkix-bks; Sun, 27 Sep 1998 09:26:54 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA08410 for <ietf-pkix@imc.org>; Sun, 27 Sep 1998 09:26:53 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19XDQFB>; Sun, 27 Sep 1998 12:32:13 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E1B1ADC@WUHER> From: Santosh Chokhani <chokhani@cygnacom.com> To: "'Internet-Drafts@ietf.org'" <Internet-Drafts@ietf.org> Cc: ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt Date: Sun, 27 Sep 1998 12:32:11 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk I find the schema acceptable for the certificates. I do not find the schema acceptable for delta CRL. I thought we had a mechanism by which delta CRL could be stored in the object class pkiCA. It does not seem to be the case. Sharon, I assume you recall the comment and resolution in this forum. > -----Original Message----- > From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org] > Sent: Thursday, September 24, 1998 10:27 AM > Cc: ietf-pkix@imc.org > Subject: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Public-Key Infrastructure (X.509) > Working Group > of the IETF. > > Title : Internet X.509 Public Key Infrastructure > LDAPv2 Schema > Author(s) : S. Boeyen, T. Howes, P. Richard > Filename : draft-ietf-pkix-ldapv2-schema-02.txt > Pages : 7 > Date : 23-Sep-98 > > The schema defined in this document is a minimal schema to > support > PKIX in an LDAPv2 environment, as defined in > draft-ietf-pkix- > ipki2opp-07.txt. Only PKIX-specific components are specified > here. > LDAP servers, acting as PKIX repositories should support the > auxi- > liary object classes defined in this specification and > integrate > this schema specification with the generic and other > application- > specific schemas as appropriate, depending on the services to > be > supplied by that server. > > The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', > 'RECOMMENDED', > and 'MAY' in this document are to be interpreted as described > in > RFC 2119. > > Please send comments on this document to the ietf-pkix@imc.org > mail > list. > > Internet-Drafts are available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-pkix-ldapv2-schema-02.txt". > A URL for the Internet-Draft is: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-02.tx > t > > Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > > Internet-Drafts are also available by mail. > > Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. << Message: Untitled Attachment >> Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA21031 for ietf-pkix-bks; Sat, 26 Sep 1998 16:25:58 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21027 for <ietf-pkix@imc.org>; Sat, 26 Sep 1998 16:25:50 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <TS1VBY1B>; Sun, 27 Sep 1998 09:30:03 +1000 Message-ID: <D1A949D4508DD1119C8100400533BEDC07B92F@DSG1> From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'ietf-tls@consensus.com '" <ietf-tls@consensus.com>, "'cert-talk@structuredarts.com '" <cert-talk@structuredarts.com>, "'Stefan Santesson '" <stefan@accurata.se> Subject: RE: NEW Data type for certificate selection ? Date: Sun, 27 Sep 1998 09:30:02 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id QAA21028 Sender: owner-ietf-pkix@imc.org Precedence: bulk Yes I have views - see my draft lloyd-dir-cert-stat .. First one needs a fully distributed directory system. Then one needs a good set of certificate matching rules in that directory system to permit the selection of certficate components. Including rules that can handle multi valued attributes. Then one needs directory based certficate searches based on client business semantics. And then one needs certficate paths to associated with business semantics in a trusted way rather than just crypto-cert-issuerId mechanisms. I dont see the problem, simply because one has to add something else to certs and pkis to make them work in a scaleable and useful way - and that is big directory systems, matching rules that assist the verification and a business information model that supports the cert/crypto mechanisms. I do not believe one will achieve much with to fix this issue without an operational, business and information perspective. just thoughts regards alan ---------- From: Stefan Santesson To: ietf-pkix@imc.org; list@seis.nc-forum.com; ietf-tls@consensus.com; cert-talk@structuredarts.com Sent: 9/24/98 10:41:23 PM Subject: NEW Data type for certificate selection ? All, During the TLS session in Chicago (IETF meeting) I discussed with Jeff Weinstein, Netscape, the problem of certificate selection in an environment where the client is populated with many similar certificates for different purposes. We concluded that this is a general problem, not only for TLS, but for S/MIME, Java, Java script, etc, where signing and encryption based on an X.509 PKI is an option. I also conclude that the current TLS approach, using Issuer name as selection criteria, is hopelessly insufficient for the general case. In fact we can NEVER claim that we have an X.509 based architecture ready for the big market IF WE DON'T SOLVE THIS PROBLEM. A normal user (I.e grandmother) will never be able to pick the right certificate by herself, if there is more than 1 to pick. The question raised here is: WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD START. If we could create a standardized ASN.1 data type with the purpose of defining the criteria for selecting 1 out of n certificates, then this could be used as a common base for enhancing TLS, Java, Java script, S/MIME etc. The data type could be communicated from server to client, client to server, server to server, client to client; I.e in any case where one party which to assist another party in selecting an appropriate certificate for any purpose (defined by the context). Do anyone have a better idea. I think this is a lost problem that has to be fixed, hopefully in a standardized way. Comments, suggestions. /Stefan Santesson ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23104 for ietf-pkix-bks; Fri, 25 Sep 1998 09:18:29 -0700 (PDT) Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23100 for <ietf-pkix@imc.org>; Fri, 25 Sep 1998 09:18:29 -0700 (PDT) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA27992; Fri, 25 Sep 1998 09:22:39 -0700 (PDT) Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA00996; Fri, 25 Sep 1998 09:24:33 -0700 (PDT) Message-Id: <3.0.32.19980925090738.0094f7e8@mail.verisign.com> X-Sender: mmyers@mail.verisign.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 25 Sep 1998 09:24:36 -0700 To: Denis Pinkas <Denis.Pinkas@bull.net>, IETF-PXIX <ietf-pkix@imc.org> From: Michael Myers <mmyers@verisign.com> Subject: Re: Archive cutoff & Retention period Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA23101 Sender: owner-ietf-pkix@imc.org Precedence: bulk Denis, At 10:03 AM 9/23/98 -0700, Denis Pinkas wrote: > >The "retention period" should be supported by all OCSP responders >and thus should be part of the standard response. Adding a >"retentionPeriod" after the "produceAt" from the ResponseData would >be simpler than defining an extension. We didn't want to break the response syntax, especially in light of the fact that support for long term retention of status data is not a core requirement. >Then, let us address the « Archive Cutoff » issue. > >If we were to support the archiving capability, with e.g. a 7 year >retention, we would need an additional time parameter in the request >to point to the equivalent of the right CRL issued at that time e.g. >7 years ago. This parameter is currently not present. Unless it is >added, the function cannot work. We thus have two options : add the >missing parameter or delete this capability. Opinions ? As the public debate on this issue had concluded, the requirement is to enable responders to assert a bound on the historical accuracy of their responses. The archive cutoff extension satisfies this requirement. This function speaks only to the most current status of the certificate, not to its status at any point in time. Mike Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22174 for ietf-pkix-bks; Fri, 25 Sep 1998 07:21:50 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22170 for <ietf-pkix@imc.org>; Fri, 25 Sep 1998 07:21:49 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA06021; Fri, 25 Sep 1998 10:27:54 -0400 (EDT) Message-Id: <199809251427.KAA06021@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ipki2opp-08.txt Date: Fri, 25 Sep 1998 10:27:54 -0400 Sender: owner-ietf-pkix@imc.org Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 Author(s) : S. Boeyen, T. Howes, P. Richard Filename : draft-ietf-pkix-ipki2opp-08.txt Pages : 12 Date : 24-Sep-98 The protocol described in this document is designed to satisfy some of the operational requirements within the Internet X.509 Public Key Infrastructure (IPKI). Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. The mechanism described in this document is based on the Lightweight Directory Access Protocol (LDAP) v2, defined in RFC 1777, defining a profile of that protocol for use within the IPKI and updates encodings for certificates and revocation lists from RFC 1778. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in this document are to be interpreted as described in RFC 2119. Please send comments on this document to the ietf-pkix@imc.org mail list. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ipki2opp-08.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki2opp-08.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ipki2opp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980924132531.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ipki2opp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ipki2opp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980924132531.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA21217 for ietf-pkix-bks; Fri, 25 Sep 1998 04:31:00 -0700 (PDT) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA21213 for <ietf-pkix@imc.org>; Fri, 25 Sep 1998 04:30:59 -0700 (PDT) Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id NAA16726; Fri, 25 Sep 1998 13:37:15 +0200 (CEST) Received: from stefans (t3o68p4.telia.com [62.20.139.4]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id NAA10344; Fri, 25 Sep 1998 13:37:14 +0200 (CEST) Message-Id: <3.0.32.19980925133351.00a88250@m1.403.telia.com> X-Sender: u40400192@m1.403.telia.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 25 Sep 1998 13:34:29 +0200 To: "Miklos, Sue A." <samiklo@missi.ncsc.mil>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com'" <list@seis.nc-forum.com>, "'cert-talk@structuredarts.com'" <cert-talk@structuredarts.com> From: Stefan Santesson <stefan@accurata.se> Subject: RE: NEW Data type for certificate selection ? Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA21214 Sender: owner-ietf-pkix@imc.org Precedence: bulk Thank you Sue, This looks very useful. I could think of some enhancements, but since this is standard it's a very good way to start. Could you elaborate how the certificate mach rule could be invoked into a protocoll. Would it just be for the entity suggesting use of a certain type of certificate to communicate one (or a SEQUECE OF) CertificateAssertion data value(s)? If this is so, then all we have to do is to have this included in various protocolls and convince Microsoft, Netscape etc, to allow certificate selection using this maching rule. If we could achieve this then I think it would be a giant step in the right direction. What does Microsoft and Netscape say about this ??? Comments, suggestions! /Stefan Santesson At 12:02 PM 9/24/98 -0400, Miklos, Sue A. wrote: > > >Please consider the following matching rules for certificates, based on >the X.500 series. I would really like to see products developed that >can invoke them (as client) and products developed that can retrieve >them from the storage (as repository). I am not advocating this exact >syntax, but something very similar would be extremely beneficial. >Sandi > >>---------- >>From: Stefan Santesson[SMTP:stefan@accurata.se] >>Sent: Thursday, September 24, 1998 8:41 AM >>To: ietf-pkix@imc.org; list@seis.nc-forum.com; ietf-tls@consensus.com; >>cert-talk@structuredarts.com >>Subject: NEW Data type for certificate selection ? >> >>All, >> >>During the TLS session in Chicago (IETF meeting) I discussed with Jeff >>Weinstein, Netscape, the problem of certificate selection in an environment >>where the client is populated with many similar certificates for different >>purposes. >> >>We concluded that this is a general problem, not only for TLS, but for >>S/MIME, Java, Java script, etc, where signing and encryption based on an >>X.509 PKI is an option. I also conclude that the current TLS approach, >>using Issuer name as selection criteria, is hopelessly insufficient for the >>general case. >> >>In fact we can NEVER claim that we have an X.509 based architecture ready >>for the big market IF WE DON'T SOLVE THIS PROBLEM. >> >>A normal user (I.e grandmother) will never be able to pick the right >>certificate by herself, if there is more than 1 to pick. >> >>The question raised here is: >> >>WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD START. >> >>If we could create a standardized ASN.1 data type with the purpose of >>defining the criteria for selecting 1 out of n certificates, then this >>could be used as a common base for enhancing TLS, Java, Java script, S/MIME >>etc. >> >>The data type could be communicated from server to client, client to >>server, server to server, client to client; I.e in any case where one party >>which to assist another party in selecting an appropriate certificate for >>any purpose (defined by the context). >> >>Do anyone have a better idea. >> >>I think this is a lost problem that has to be fixed, hopefully in a >>standardized way. >> >>Comments, suggestions. >> >>/Stefan Santesson >>------------------------------------------------------------------- >>Stefan Santesson <stefan@accurata.se> >>Accurata Systemsäkerhet AB >>Lotsgatan 27 D Tel. +46-40 152211 >>216 42 Malmö Fax. +46-40 150790 >>Sweden Mobile +46-70 5247799 >> >>PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 >>------------------------------------------------------------------- >> > >Attachment Converted: "c:\internet\eudora\attach\MATCH2.DOC" > ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18649 for ietf-pkix-bks; Fri, 25 Sep 1998 02:25:59 -0700 (PDT) Received: from florida.melco.co.jp (florida.melco.co.jp [192.218.140.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18645 for <ietf-pkix@imc.org>; Fri, 25 Sep 1998 02:25:52 -0700 (PDT) Received: from melcoweb.melco.co.jp ([133.141.191.73]) by florida.melco.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-florida) with SMTP id SAA24749; Fri, 25 Sep 1998 18:21:35 +0900 (JST) Received: from inetgw.melco.co.jp (inetgw) by melcoweb.melco.co.jp (5.65+1.6W/3.5Wbeta) id AA00363; Fri, 25 Sep 98 18:26:06 JST Received: from katase.katase.isl.melco.co.jp ([133.141.13.135]) by inetgw.melco.co.jp (8.8.8+2.7Wbeta7/3.6W-inetgw) with SMTP id SAA08497; Fri, 25 Sep 1998 18:37:55 +0900 (JST) Received: from iss.iss.isl.melco.co.jp by katase.katase.isl.melco.co.jp (4.1/6.4J.6-katase-2/) id AA29300; Fri, 25 Sep 98 18:31:52 JST Received: from zaku by iss.iss.isl.melco.co.jp (1.38.193.4/6.4J.6-isl2-2/iss-master) id AA19581; Fri, 25 Sep 1998 18:31:52 +0900 Message-Id: <360B627F.981A419E@iss.isl.melco.co.jp> Date: Fri, 25 Sep 1998 18:29:35 +0900 From: "=?iso-2022-jp?B?GyRCNUhJcCEhPV8bKEI=?=" <yositake@iss.isl.melco.co.jp> X-Mailer: Mozilla 4.05 [ja] (Win95; I) Mime-Version: 1.0 To: Stefan Santesson <stefan@accurata.se> Cc: ietf-pkix@imc.org, list@seis.nc-forum.com, ietf-tls@consensus.com, cert-talk@structuredarts.com Subject: Re: NEW Data type for certificate selection ? References: <3.0.32.19980924144039.00a6ccf0@m1.403.telia.com> Content-Type: text/plain; charset=iso-2022-jp X-Mime-Autoconverted: from 8bit to quoted-printable by inetgw.melco.co.jp id SAA08497 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA18646 Sender: owner-ietf-pkix@imc.org Precedence: bulk I have two comments. 1. I'd like to clarify the scope. Is it limited to the case where one party which to assist another party ? I suggest that it include the case where a person has multiple certificates in his / her PC, WS, etc. It will be more useful and more efficient if there is a standardized mechanism for the case like this rather than that each application manages its certificates in its own way on one machine. Some applications could hold a certificate in common. 2. It would be better that we consider the generation management of a certificate. Suppose a certificate has expired and you get the new certificate on your PC. Namely, you have two certificates on your PC, the old one and the new one. Attention should be paid not to let an application select the old one. (Of course, things are easy if the old one is deleted. But is it really always good for all the cases, all applications,...?) (Issuer and Serial Number is nice, but you need the mechanism to record "this serial number is for the new one" when you get it for the first time.) Jun Yoshitake Mitsubishi Electric Corp. Stefan Santesson wrote: > All, > > During the TLS session in Chicago (IETF meeting) I discussed with Jeff > Weinstein, Netscape, the problem of certificate selection in an environment > where the client is populated with many similar certificates for different > purposes. > > We concluded that this is a general problem, not only for TLS, but for > S/MIME, Java, Java script, etc, where signing and encryption based on an > X.509 PKI is an option. I also conclude that the current TLS approach, > using Issuer name as selection criteria, is hopelessly insufficient for the > general case. > > In fact we can NEVER claim that we have an X.509 based architecture ready > for the big market IF WE DON'T SOLVE THIS PROBLEM. > > A normal user (I.e grandmother) will never be able to pick the right > certificate by herself, if there is more than 1 to pick. > > The question raised here is: > > WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD START. > > If we could create a standardized ASN.1 data type with the purpose of > defining the criteria for selecting 1 out of n certificates, then this > could be used as a common base for enhancing TLS, Java, Java script, S/MIME > etc. > > The data type could be communicated from server to client, client to > server, server to server, client to client; I.e in any case where one party > which to assist another party in selecting an appropriate certificate for > any purpose (defined by the context). > > Do anyone have a better idea. > > I think this is a lost problem that has to be fixed, hopefully in a > standardized way. > > Comments, suggestions. > > /Stefan Santesson > ------------------------------------------------------------------- > Stefan Santesson <stefan@accurata.se> > Accurata Systems$BgL(Berhet AB > Lotsgatan 27 D Tel. +46-40 152211 > 216 42 Malm$Bö (B Fax. +46-40 150790 > Sweden Mobile +46-70 5247799 > > PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 > ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22412 for ietf-pkix-bks; Thu, 24 Sep 1998 08:55:58 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22408 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 08:55:56 -0700 (PDT) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id MAA24293 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 12:02:10 -0400 (EDT) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id MAA24288 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 12:02:09 -0400 (EDT) Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id MAA15598 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 12:01:26 -0400 (EDT) Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000285171@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 12:02:06 -0400 Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BDE7B3.263212E0@avenger.missi.ncsc.mil>; Thu, 24 Sep 1998 12:02:06 -0400 Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-980924160205Z-6343@avenger.missi.ncsc.mil> From: "Miklos, Sue A." <samiklo@missi.ncsc.mil> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com'" <list@seis.nc-forum.com>, "'ietf-tls@consensus.com'" <ietf-tls@consensus.com>, "'cert-talk@structuredarts.com'" <cert-talk@structuredarts.com>, "'Stefan Santesson'" <stefan@accurata.se> Subject: RE: NEW Data type for certificate selection ? Date: Thu, 24 Sep 1998 12:02:05 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BDE7B3.26345CD0" Sender: owner-ietf-pkix@imc.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BDE7B3.26345CD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Please consider the following matching rules for certificates, based on the X.500 series. I would really like to see products developed that can invoke them (as client) and products developed that can retrieve them from the storage (as repository). I am not advocating this exact syntax, but something very similar would be extremely beneficial. Sandi >---------- >From: Stefan Santesson[SMTP:stefan@accurata.se] >Sent: Thursday, September 24, 1998 8:41 AM >To: ietf-pkix@imc.org; list@seis.nc-forum.com; ietf-tls@consensus.com; >cert-talk@structuredarts.com >Subject: NEW Data type for certificate selection ? > >All, > >During the TLS session in Chicago (IETF meeting) I discussed with Jeff >Weinstein, Netscape, the problem of certificate selection in an = environment >where the client is populated with many similar certificates for = different >purposes. > >We concluded that this is a general problem, not only for TLS, but for >S/MIME, Java, Java script, etc, where signing and encryption based on = an >X.509 PKI is an option. I also conclude that the current TLS approach, >using Issuer name as selection criteria, is hopelessly insufficient for = the >general case. > >In fact we can NEVER claim that we have an X.509 based architecture = ready >for the big market IF WE DON'T SOLVE THIS PROBLEM. > >A normal user (I.e grandmother) will never be able to pick the right >certificate by herself, if there is more than 1 to pick. > >The question raised here is: > >WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD = START. > >If we could create a standardized ASN.1 data type with the purpose of >defining the criteria for selecting 1 out of n certificates, then this >could be used as a common base for enhancing TLS, Java, Java script, = S/MIME >etc. > >The data type could be communicated from server to client, client to >server, server to server, client to client; I.e in any case where one = party >which to assist another party in selecting an appropriate certificate = for >any purpose (defined by the context). > >Do anyone have a better idea. > >I think this is a lost problem that has to be fixed, hopefully in a >standardized way. > >Comments, suggestions. > >/Stefan Santesson >------------------------------------------------------------------- >Stefan Santesson <stefan@accurata.se> >Accurata Systems=E4kerhet AB =20 >Lotsgatan 27 D Tel. +46-40 152211 =20 >216 42 Malm=F6 Fax. +46-40 150790 =20 >Sweden Mobile +46-70 5247799 > >PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 >------------------------------------------------------------------- > ------ =_NextPart_000_01BDE7B3.26345CD0 Content-Type: application/msword; name="MATCH.DOC" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAAgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////HgAAAP7///8fAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA ACAAAAD+/////v///yEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAP7///////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8DAAAAAAkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAIZMlDsA6rwB AwAAAIADAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAYgAAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAf////8EAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAdTQAAAAAAAE8AYgBqAGUAYwB0AFAAbwBv AGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEBAQAAAAIA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAACGTJQ7AOq8AYZMlDsA6rwBAAAAANQNNBRABNQNAQAA AP7///8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAP7///////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////8BAP7/ AwoAAP////8ACQIAAAAAAMAAAAAAAABGHAAAAE1pY3Jvc29mdCBXb3JkIDYuMCBEb2N1bWVudAAK AAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjYAAAAAADsAAwD+/wkABgAAAAAAAAAAAAAA AQAAAAEAAAAAAP7/AAADCgAAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAA ALACAAAOAAAABwAAAJgAAAACAAAA3AAAAAQAAAAAAQAACAAAACQBAAAMAAAASAEAAAsAAABsAQAA DQAAAJABAAAPAAAAtAEAABAAAADYAQAACgAAAPwBAAASAAAAIAIAAA4AAABEAgAACQAAAGgCAAAT AAAAjAIAAP//////////////////////////////////////////HgAAACgAAABDOlxNU09GRklD RVxXSU5XT1JEXFRFTVBMQVRFXE5PUk1BTC5ET1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAeAAAAFAAA ADEyLjcJTWF0Y2hpbmcgcnVsZXMAAAAAAAAAAAAeAAAADgAAAFN1ZSBBLiBNaWtsb3MAAAAAAAAA AAAAAAAAAAAeAAAADgAAAFN1ZSBBLiBNaWtsb3MAAAAAAAAAAAAAAAAAAABAAAAAhn3TndylZQA9 wAkEAAAAAGUAAAAAAAAAAAAAAAADAAAHMwAAHU0AAAAAAAAAAAAAAAAAAAAAAAAHMAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAKAMAAABEAAAoAwAAKEcAAAAAAAAoRwAAAAAA AChHAAAAAAAAKEcAAAAAAAAoRwAAFAAAAKJHAAA8AAAAokcAAAAAAADeRwAAAAAAAN5HAAAAAAAA 3kcAAAAAAADeRwAAFgAAAPRHAAAiAAAAokcAAAAAAAAjTAAAZQAAABZIAAAAAAAAFkgAAAAAAAAW SAAAAAAAABZIAAAAAAAAFkgAAAAAAAAWSAAAAAAAABZIAAAAAAAAFkgAAAAAAAA4SAAAAgAAADpI AAAAAAAAOkgAAAAAAAA6SAAAIwAAAF1IAADUAQAAMUoAANQBAAAFTAAAHgAAAIhMAABUAAAA3EwA AEEAAAAjTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoRwAAAAAAABZIAAAAAAAAAAAaAB0AAwAFABZI AAAAAAAAFkgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFkgAAAAAAAAWSAAAAAAAACNMAAAAAAAAFkgA AAAAAAAoRwAAAAAAAChHAAAAAAAAFkgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFkgAAAAAAAAWSAAA AAAAABZIAAAAAAAAFkgAAAAAAAAWSAAAAAAAAChHAAAAAAAAFkgAAAAAAAAoRwAAAAAAABZIAAAA AAAAOEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPEcAACYAAABiRwAAQAAAAChHAAAAAAAAKEcAAAAA AAAoRwAAAAAAAChHAAAAAAAAFkgAAAAAAAA4SAAAAAAAABZIAAAiAAAAFkgAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEVYQ0VSUFRTIEZST00gVEhFIDE5OTcgWC41MDAgU2VyaWVz IG9mIFJlY29tbWVuZGF0aW9ucyBmb3IgSW5mb3JtYXRpb25hbCBQdXJwb3NlcyBPbmx5Lg0NMTIu NwlNYXRjaGluZyBydWxlcw1UaGlzIERpcmVjdG9yeSBTcGVjaWZpY2F0aW9uIGRlZmluZXMgbWF0 Y2hpbmcgcnVsZXMgZm9yIHVzZSB3aXRoIGF0dHJpYnV0ZXMgb2YgdHlwZSBDZXJ0aWZpY2F0ZSwg Q2VydGlmaWNhdGVQYWlyLCBDZXJ0aWZpY2F0ZUxpc3QsIGFuZCBTdXBwb3J0ZWRBbGdvcml0aG0s IHJlc3BlY3RpdmVseS4NMTIuNy4xCUNlcnRpZmljYXRlIGV4YWN0IG1hdGNoDVRoZSBjZXJ0aWZp Y2F0ZSBleGFjdCBtYXRjaCBydWxlIGNvbXBhcmVzIGZvciBlcXVhbGl0eSBhIHByZXNlbnRlZCB2 YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSB2YWx1ZSBvZiB0eXBlIENlcnRpZmljYXRlLiBJdCB1bmlx dWVseSBzZWxlY3RzIGEgc2luZ2xlIGNlcnRpZmljYXRlLg1jZXJ0aWZpY2F0ZUV4YWN0TWF0Y2gg TUFUQ0hJTkctUlVMRSA6Oj0gewsJU1lOVEFYCQlDZXJ0aWZpY2F0ZUV4YWN0QXNzZXJ0aW9uCwlJ RAkJCWlkLW1yLWNlcnRpZmljYXRlRXhhY3RNYXRjaCB9DUNlcnRpZmljYXRlRXhhY3RBc3NlcnRp b24gOjo9IFNFUVVFTkNFIHsLCXNlcmlhbE51bWJlcgkJQ2VydGlmaWNhdGVTZXJpYWxOdW1iZXIs Cwlpc3N1ZXIJCQlOYW1lIH0NVGhpcyBtYXRjaGluZyBydWxlIHJldHVybnMgVFJVRSBpZiB0aGUg Y29tcG9uZW50cyBpbiB0aGUgYXR0cmlidXRlIHZhbHVlIG1hdGNoIHRob3NlIGluIHRoZSBwcmVz ZW50ZWQgdmFsdWUuDTEyLjcuMglDZXJ0aWZpY2F0ZSBtYXRjaA1UaGUgY2VydGlmaWNhdGUgbWF0 Y2ggcnVsZSBjb21wYXJlcyBhIHByZXNlbnRlZCB2YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSB2YWx1 ZSBvZiB0eXBlIENlcnRpZmljYXRlLiBJdCBzZWxlY3RzIG9uZSBvciBtb3JlIGNlcnRpZmljYXRl cyBvbiB0aGUgYmFzaXMgb2YgdmFyaW91cyBjaGFyYWN0ZXJpc3RpY3MuDWNlcnRpZmljYXRlTWF0 Y2ggTUFUQ0hJTkctUlVMRSA6Oj0gewsJU1lOVEFYCQlDZXJ0aWZpY2F0ZUFzc2VydGlvbgsJSUQJ CQlpZC1tci1jZXJ0aWZpY2F0ZU1hdGNoIH0NQ2VydGlmaWNhdGVBc3NlcnRpb24gOjo9IFNFUVVF TkNFIHsLCXNlcmlhbE51bWJlcgkJWzBdIENlcnRpZmljYXRlU2VyaWFsTnVtYmVyCQlPUFRJT05B TCwLCWlzc3VlcgkJCQlbMV0gTmFtZSAJCQlPUFRJT05BTCwLCXN1YmplY3RLZXlJZGVudGlmaWVy CVsyXSBTdWJqZWN0S2V5SWRlbnRpZmllcgkJT1BUSU9OQUwsCwlhdXRob3JpdHlLZXlJZGVudGlm aWVyCVszXSBBdXRob3JpdHlLZXlJZGVudGlmaWVyIAkJT1BUSU9OQUwsCwljZXJ0aWZpY2F0ZVZh bGlkCQlbNF0gVVRDVGltZQkJCU9QVElPTkFMLAsJcHJpdmF0ZUtleVZhbGlkCQlbNV0gR2VuZXJh bGl6ZWRUaW1lCQlPUFRJT05BTCwLCXN1YmplY3RQdWJsaWNLZXlBbGdJRAlbNl0gT0JKRUNUIElE RU5USUZJRVIJCU9QVElPTkFMLAsJa2V5VXNhZ2UJCQlbN10gS2V5VXNhZ2UJCQlPUFRJT05BTCwL CXN1YmplY3RBbHROYW1lCQlbOF0gQWx0TmFtZVR5cGUJCU9QVElPTkFMLAsJcG9saWN5CQkJCVs5 XSBDZXJ0UG9saWN5U2V0CQlPUFRJT05BTCwLCXBhdGhUb05hbWUJCVsxMF0gTmFtZQkJCU9QVElP TkFMIH0NQWx0TmFtZVR5cGUgOjo9IENIT0lDRSB7IAsJYnVpbHRpbk5hbWVGb3JtCUVOVU1FUkFU RUQgewsJCQkJCXJmYzgyMk5hbWUJCSgxKSwLCQkJCQlkTlNOYW1lCQkoMiksCwkJCQkJeDQwMEFk ZHJlc3MJCSgzKSwLCQkJCQlkaXJlY3RvcnlOYW1lCSg0KSwLCQkJCQllZGlQYXJ0eU5hbWUJCSg1 KSwLCQkJCQl1bmlmb3JtUmVzb3VyY2VJZGVudGlmaWVyICg2KSwLCQkJCQlpUEFkZHJlc3MJCSg3 KSwLCQkJCQlyZWdpc3RlcmVkSWQJCSg4KSB9LAsJb3RoZXJOYW1lRm9ybQlPQkpFQ1QgSURFTlRJ RklFUiB9DVRoaXMgbWF0Y2hpbmcgcnVsZSByZXR1cm5zIFRSVUUgaWYgYWxsIG9mIHRoZSBjb21w b25lbnRzIHRoYXQgYXJlIHByZXNlbnQgaW4gdGhlIHByZXNlbnRlZCB2YWx1ZSBtYXRjaCB0aGUg Y29ycmVzcG9uZGluZyBjb21wb25lbnRzIG9mIHRoZSBhdHRyaWJ1dGUgdmFsdWUsIGFzIGZvbGxv d3M6DWEpCXNlcmlhbE51bWJlciBtYXRjaGVzIGlmIHRoZSB2YWx1ZSBvZiB0aGlzIGNvbXBvbmVu dCBpbiB0aGUgYXR0cmlidXRlIHZhbHVlIGVxdWFscyB0aGF0IGluIHRoZSBwcmVzZW50ZWQgdmFs dWU7DWIpCWlzc3VlciBtYXRjaGVzIGlmIHRoZSB2YWx1ZSBvZiB0aGlzIGNvbXBvbmVudCBpbiB0 aGUgYXR0cmlidXRlIHZhbHVlIGVxdWFscyB0aGF0IGluIHRoZSBwcmVzZW50ZWQgdmFsdWU7DWMp CXN1YmplY3RLZXlJZGVudGlmaWVyIG1hdGNoZXMgaWYgdGhlIHZhbHVlIG9mIHRoaXMgY29tcG9u ZW50IGluIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlIGVxdWFscyB0aGF0IGluIHRoZSBwcmVz ZW50ZWQgdmFsdWU7IHRoZXJlIGlzIG5vIG1hdGNoIGlmIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZh bHVlIGNvbnRhaW5zIG5vIHN1YmplY3Qga2V5IGlkZW50aWZpZXIgZXh0ZW5zaW9uOw1kKQlhdXRo b3JpdHlLZXlJZGVudGlmaWVyIG1hdGNoZXMgaWYgdGhlIHZhbHVlIG9mIHRoaXMgY29tcG9uZW50 IGluIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlIGVxdWFscyB0aGF0IGluIHRoZSBwcmVzZW50 ZWQgdmFsdWU7IHRoZXJlIGlzIG5vIG1hdGNoIGlmIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVl IGNvbnRhaW5zIG5vIGF1dGhvcml0eSBrZXkgaWRlbnRpZmllciBleHRlbnNpb24gb3IgaWYgbm90 IGFsbCBjb21wb25lbnRzIGluIHRoZSBwcmVzZW50ZWQgdmFsdWUgYXJlIHByZXNlbnQgaW4gdGhl IHN0b3JlZCBhdHRyaWJ1dGUgdmFsdWU7DWUpCWNlcnRpZmljYXRlVmFsaWQgbWF0Y2hlcyBpZiB0 aGUgcHJlc2VudGVkIHZhbHVlIGZhbGxzIHdpdGhpbiB0aGUgdmFsaWRpdHkgcGVyaW9kIG9mIHRo ZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlOw1mKQlwcml2YXRlS2V5VmFsaWQgbWF0Y2hlcyBpZiB0 aGUgcHJlc2VudGVkIHZhbHVlIGZhbGxzIHdpdGhpbiB0aGUgcGVyaW9kIGluZGljYXRlZCBieSB0 aGUgcHJpdmF0ZSBrZXkgdXNhZ2UgcGVyaW9kIGV4dGVuc2lvbiBvZiB0aGUgc3RvcmVkIGF0dHJp YnV0ZSB2YWx1ZSBvciBpZiB0aGVyZSBpcyBubyBwcml2YXRlIGtleSB1c2FnZSBwZXJpb2QgZXh0 ZW5zaW9uIGluIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlOw1nKQlzdWJqZWN0UHVibGljS2V5 QWxnSUQgbWF0Y2hlcyBpZiBpdCBpcyBlcXVhbCB0byB0aGUgYWxnb3JpdGhtIGNvbXBvbmVudCBv ZiB0aGUgYWxnb3JpdGhtSWRlbnRpZmllciBvZiB0aGUgc3ViamVjdFB1YmxpY0tleUluZm9ybWF0 aW9uIGNvbXBvbmVudCBvZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsNaCkJa2V5VXNhZ2Ug bWF0Y2hlcyBpZiBhbGwgb2YgdGhlIGJpdHMgc2V0IGluIHRoZSBwcmVzZW50ZWQgdmFsdWUgYXJl IGFsc28gc2V0IGluIHRoZSBrZXkgdXNhZ2UgZXh0ZW5zaW9uIGluIHRoZSBzdG9yZWQgYXR0cmli dXRlIHZhbHVlLCBvciBpZiB0aGVyZSBpcyBubyBrZXkgdXNhZ2UgZXh0ZW5zaW9uIGluIHRoZSBz dG9yZWQgYXR0cmlidXRlIHZhbHVlOw1pKQlzdWJqZWN0QWx0TmFtZSBtYXRjaGVzIGlmIHRoZSBz dG9yZWQgYXR0cmlidXRlIHZhbHVlIGNvbnRhaW5zIHRoZSBzdWJqZWN0IGFsdGVybmF0aXZlIG5h bWUgZXh0ZW5zaW9uIHdpdGggYW4gQWx0TmFtZXMgY29tcG9uZW50IG9mIHRoZSBzYW1lIG5hbWUg dHlwZSBhcyBpbmRpY2F0ZWQgaW4gdGhlIHByZXNlbnRlZCB2YWx1ZTsNaikJcG9saWN5IG1hdGNo ZXMgaWYgYWxsIG9mIHRoZSBwb2xpY3kgZWxlbWVudHMgaWRlbnRpZmllZCBpbiBvbmUgb2YgdGhl IHByZXNlbnRlZCB2YWx1ZXMgYXJlIGNvbnRhaW5lZCBpbiB0aGUgc2V0IG9mIHBvbGljeUVsZW1l bnRJZHMgaW4gYW55IG9mIHRoZSBwb2xpY3lJbmZvcm1hdGlvbiB2YWx1ZXMgaW4gdGhlIGNlcnRp ZmljYXRlIHBvbGljaWVzIGV4dGVuc2lvbiBpbiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsg IHRoZXJlIGlzIG5vIG1hdGNoIGlmIHRoZXJlIGlzIG5vIGNlcnRpZmljYXRlIHBvbGljaWVzIGV4 dGVuc2lvbiBpbiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsNaykJcGF0aFRvTmFtZSBtYXRj aGVzIHVubGVzcyB0aGUgY2VydGlmaWNhdGUgaGFzIGEgbmFtZSBjb25zdHJhaW50cyBleHRlbnNp b24gd2hpY2ggaW5oaWJpdHMgdGhlIGNvbnN0cnVjdGlvbiBvZiBhIGNlcnRpZmljYXRpb24gcGF0 aCB0byB0aGUgcHJlc2VudGVkIG5hbWUgdmFsdWUuDTEyLjcuMwlDZXJ0aWZpY2F0ZSBwYWlyIGV4 YWN0IG1hdGNoDVRoZSBjZXJ0aWZpY2F0ZSBwYWlyIGV4YWN0IG1hdGNoIHJ1bGUgY29tcGFyZXMg Zm9yIGVxdWFsaXR5IGEgcHJlc2VudGVkIHZhbHVlIHdpdGggYW4gYXR0cmlidXRlIHZhbHVlIG9m IHR5cGUgQ2VydGlmaWNhdGVQYWlyLiBJdCB1bmlxdWVseSBzZWxlY3RzIGEgc2luZ2xlIGNyb3Nz LWNlcnRpZmljYXRlIHBhaXIuDWNlcnRpZmljYXRlUGFpckV4YWN0TWF0Y2ggTUFUQ0hJTkctUlVM RQk6Oj0JewsJU1lOVEFYCQlDZXJ0aWZpY2F0ZVBhaXJFeGFjdEFzc2VydGlvbgsJSUQJCQlpZC1t ci1jZXJ0aWZpY2F0ZVBhaXJFeGFjdE1hdGNoIH0NQ2VydGlmaWNhdGVQYWlyRXhhY3RBc3NlcnRp b24gOjo9IFNFUVVFTkNFIHsNCWZvcndhcmRBc3NlcnRpb24gCVswXSBDZXJ0aWZpY2F0ZUV4YWN0 QXNzZXJ0aW9uIE9QVElPTkFMLA0JcmV2ZXJzZUFzc2VydGlvbiAJWzFdIENlcnRpZmljYXRlRXhh Y3RBc3NlcnRpb24gT1BUSU9OQUwgfQ0JKCBXSVRIIENPTVBPTkVOVFMgCXsuLi4sIGZvcndhcmRB c3NlcnRpb24gUFJFU0VOVH0gfA0JICBXSVRIIENPTVBPTkVOVFMgCXsuLi4sIHJldmVyc2VBc3Nl cnRpb24gUFJFU0VOVH0gKQ1UaGlzIG1hdGNoaW5nIHJ1bGUgcmV0dXJucyBUUlVFIGlmIHRoZSBj b21wb25lbnRzIHRoYXQgYXJlIHByZXNlbnQgaW4gdGhlIGZvcndhcmRBc3NlcnRpb24gYW5kIHJl dmVyc2VBc3NlcnRpb24gY29tcG9uZW50cyBvZiB0aGUgcHJlc2VudGVkIHZhbHVlIG1hdGNoIHRo ZSBjb3JyZXNwb25kaW5nIGNvbXBvbmVudHMgb2YgdGhlIGZvcndhcmQgYW5kIHJldmVyc2UgY29t cG9uZW50cywgcmVzcGVjdGl2ZWx5LCBpbiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZS4NMTIu Ny40CUNlcnRpZmljYXRlIHBhaXIgbWF0Y2gNVGhlIGNlcnRpZmljYXRlIHBhaXIgbWF0Y2ggcnVs ZSBjb21wYXJlcyBhIHByZXNlbnRlZCB2YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSB2YWx1ZSBvZiB0 eXBlIENlcnRpZmljYXRlUGFpci4gSXQgc2VsZWN0cyBvbmUgb3IgbW9yZSBjcm9zcy1jZXJ0aWZp Y2F0ZSBwYWlycyBvbiB0aGUgYmFzaXMgb2YgdmFyaW91cyBjaGFyYWN0ZXJpc3RpY3Mgb2YgZWl0 aGVyIHRoZSBmb3J3YXJkIG9yIHJldmVyc2UgY2VydGlmaWNhdGUgb2YgdGhlIHBhaXIuDWNlcnRp ZmljYXRlUGFpck1hdGNoIE1BVENISU5HLVJVTEUgOjo9CXsLCVNZTlRBWAkJQ2VydGlmaWNhdGVQ YWlyQXNzZXJ0aW9uCwlJRAkJCWlkLW1yLWNlcnRpZmljYXRlUGFpck1hdGNoIH0NQ2VydGlmaWNh dGVQYWlyQXNzZXJ0aW9uIDo6PSBTRVFVRU5DRSB7DQlmb3J3YXJkQXNzZXJ0aW9uIAlbMF0gQ2Vy dGlmaWNhdGVBc3NlcnRpb24gT1BUSU9OQUwsDQlyZXZlcnNlQXNzZXJ0aW9uIAlbMV0gQ2VydGlm aWNhdGVBc3NlcnRpb24gT1BUSU9OQUwgfQ0JKCBXSVRIIENPTVBPTkVOVFMgCXsuLi4sIGZvcndh cmRBc3NlcnRpb24gUFJFU0VOVH0gfA0JICBXSVRIIENPTVBPTkVOVFMgCXsuLi4sIHJldmVyc2VB c3NlcnRpb24gUFJFU0VOVH0gKQ1UaGlzIG1hdGNoaW5nIHJ1bGUgcmV0dXJucyBUUlVFIGlmIGFs bCBvZiB0aGUgY29tcG9uZW50cyB0aGF0IGFyZSBwcmVzZW50IGluIHRoZSBmb3J3YXJkQXNzZXJ0 aW9uIGFuZCByZXZlcnNlQXNzZXJ0aW9uIGNvbXBvbmVudHMgb2YgdGhlIHByZXNlbnRlZCB2YWx1 ZSBtYXRjaCB0aGUgY29ycmVzcG9uZGluZyBjb21wb25lbnRzIG9mIHRoZSBmb3J3YXJkIGFuZCBy ZXZlcnNlIGNvbXBvbmVudHMsIHJlc3BlY3RpdmVseSwgaW4gdGhlIHN0b3JlZCBhdHRyaWJ1dGUg dmFsdWUsIHVzaW5nIHRoZSBydWxlcyBnaXZlbiBpbiAxMi43LjIuDTEyLjcuNQlDZXJ0aWZpY2F0 ZSBsaXN0IGV4YWN0IG1hdGNoDVRoZSBjZXJ0aWZpY2F0ZSBsaXN0IGV4YWN0IG1hdGNoIHJ1bGUg Y29tcGFyZXMgZm9yIGVxdWFsaXR5IGEgcHJlc2VudGVkIHZhbHVlIHdpdGggYW4gYXR0cmlidXRl IHZhbHVlIG9mIHR5cGUgQ2VydGlmaWNhdGVMaXN0LiBJdCB1bmlxdWVseSBzZWxlY3RzIGEgc2lu Z2xlIENSTC4NY2VydGlmaWNhdGVMaXN0RXhhY3RNYXRjaCBNQVRDSElORy1SVUxFCTo6PQl7CwlT WU5UQVgJCUNlcnRpZmljYXRlTGlzdEV4YWN0QXNzZXJ0aW9uCwlJRAkJCWlkLW1yLWNlcnRpZmlj YXRlTGlzdEV4YWN0TWF0Y2ggfQ1DZXJ0aWZpY2F0ZUxpc3RFeGFjdEFzc2VydGlvbiA6Oj0gU0VR VUVOQ0Ugew0JaXNzdWVyCQkJTmFtZSwNCXRoaXNVcGRhdGUJCVVUQ1RpbWUsDQlkaXN0cmlidXRp b25Qb2ludAlEaXN0cmlidXRpb25Qb2ludE5hbWUgT1BUSU9OQUwgfQ1UaGUgcnVsZSByZXR1cm5z IFRSVUUgaWYgdGhlIGNvbXBvbmVudHMgaW4gdGhlIHN0b3JlZCBhdHRyaWJ1dGUgdmFsdWUgbWF0 Y2ggdGhvc2UgaW4gdGhlIHByZXNlbnRlZCB2YWx1ZS4gSWYgdGhlIGRpc3RyaWJ1dGlvblBvaW50 IGNvbXBvbmVudCBpcyBwcmVzZW50IHRoZW4gaXQgbXVzdCBtYXRjaCBpbiBhdCBsZWFzdCBvbmUg bmFtZSBmb3JtLg0xMi43LjYJQ2VydGlmaWNhdGUgbGlzdCBtYXRjaA1UaGUgY2VydGlmaWNhdGUg bGlzdCBtYXRjaCBydWxlIGNvbXBhcmVzIGEgcHJlc2VudGVkIHZhbHVlIHdpdGggYW4gYXR0cmli dXRlIHZhbHVlIG9mIHR5cGUgQ2VydGlmaWNhdGVMaXN0LiBJdCBzZWxlY3RzIG9uZSBvciBtb3Jl IENSTHMgb24gdGhlIGJhc2lzIG9mIHZhcmlvdXMgY2hhcmFjdGVyaXN0aWNzLg1jZXJ0aWZpY2F0 ZUxpc3RNYXRjaCBNQVRDSElORy1SVUxFIDo6PSB7DQlTWU5UQVgJQ2VydGlmaWNhdGVMaXN0QXNz ZXJ0aW9uCwlJRAkJaWQtbXItY2VydGlmaWNhdGVMaXN0TWF0Y2ggfQ1DZXJ0aWZpY2F0ZUxpc3RB c3NlcnRpb24gOjo9IFNFUVVFTkNFIHsNCWlzc3VlcgkJCU5hbWUJT1BUSU9OQUwsDQltaW5DUkxO dW1iZXIJCVswXQlDUkxOdW1iZXIJT1BUSU9OQUwsCwltYXhDUkxOdW1iZXIJCVsxXQlDUkxOdW1i ZXIJT1BUSU9OQUwsCwlyZWFzb25GbGFncwkJUmVhc29uRmxhZ3MJT1BUSU9OQUwsCwlkYXRlQW5k VGltZQkJVVRDVGltZQlPUFRJT05BTCwNCWRpc3RyaWJ1dGlvblBvaW50CQlbMl0JRGlzdHJpYnV0 aW9uUG9pbnROYW1lIE9QVElPTkFMIH0NVGhlIG1hdGNoaW5nIHJ1bGUgcmV0dXJucyBUUlVFIGlm IGFsbCBvZiB0aGUgY29tcG9uZW50cyB0aGF0IGFyZSBwcmVzZW50IGluIHRoZSBwcmVzZW50ZWQg dmFsdWUgbWF0Y2ggdGhlIGNvcnJlc3BvbmRpbmcgY29tcG9uZW50cyBvZiB0aGUgc3RvcmVkIGF0 dHJpYnV0ZSB2YWx1ZSwgYXMgZm9sbG93czoNYSkJaXNzdWVyIG1hdGNoZXMgaWYgdGhlIHZhbHVl IG9mIHRoaXMgY29tcG9uZW50IGluIHRoZSBhdHRyaWJ1dGUgdmFsdWUgZXF1YWxzIHRoYXQgaW4g dGhlIHByZXNlbnRlZCB2YWx1ZTsNYikJbWluQ1JMTnVtYmVyIG1hdGNoZXMgaWYgaXRzIHZhbHVl IGlzIGxlc3MgdGhhbiBvciBlcXVhbCB0byB0aGUgdmFsdWUgaW4gdGhlIENSTCBudW1iZXIgZXh0 ZW5zaW9uIG9mIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlOyB0aGVyZSBpcyBubyBtYXRjaCBp ZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucyBubyBDUkwgbnVtYmVyIGV4dGVu c2lvbjsNYykJbWF4Q1JMTnVtYmVyIG1hdGNoZXMgaWYgaXRzIHZhbHVlIGlzIGdyZWF0ZXIgdGhh biBvciBlcXVhbCB0byB0aGUgdmFsdWUgaW4gdGhlIENSTCBudW1iZXIgZXh0ZW5zaW9uIG9mIHRo ZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlOyB0aGVyZSBpcyBubyBtYXRjaCBpZiB0aGUgc3RvcmVk IGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucyBubyBDUkwgbnVtYmVyIGV4dGVuc2lvbjsNZCkJcmVh c29uRmxhZ3MgbWF0Y2hlcyBpZiBhbnkgb2YgdGhlIGJpdHMgdGhhdCBhcmUgYXJlIHNldCBpbiB0 aGUgcHJlc2VudGVkIHZhbHVlIGFyZSBhbHNvIHNldCBpbiB0aGUgb25seVNvbWVSZWFzb25zIGNv bXBvbmVudHMgb2YgdGhlIGlzc3VpbmcgZGlzdHJpYnV0aW9uIHBvaW50IGV4dGVuc2lvbiBvZiB0 aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsgdGhlcmUgaXMgbm8gbWF0Y2ggaWYgdGhlIHN0b3Jl ZCBhdHRyaWJ1dGUgdmFsdWUgY29udGFpbnMgbm8gaXNzdWluZyBkaXN0cmlidXRpb24gcG9pbnQg ZXh0ZW5zaW9uOw1lKQlkYXRlQW5kVGltZSBtYXRjaGVzIGlmIHRoZSB2YWx1ZSBpcyBlcXVhbCB0 byBvciBsYXRlciB0aGFuIHRoZSB2YWx1ZSBpbiB0aGUgdGhpc1VwZGF0ZSBjb21wb25lbnQgb2Yg dGhlIHN0b3JlZCBhdHRyaWJ1dGUgdmFsdWUgYW5kIGlzIGVhcmxpZXIgdGhhbiB0aGUgdmFsdWUg aW4gdGhlIG5leHRVcGRhdGUgY29tcG9uZW50IG9mIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVl OyB0aGVyZSBpcyBubyBtYXRjaCBpZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlu cyBubyBuZXh0VXBkYXRlIGNvbXBvbmVudDsNZikJZGlzdHJpYnV0aW9uUG9pbnQgbWF0Y2hlcyBp ZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucyBhbiBpc3N1aW5nIGRpc3RyaWJ1 dGlvbiBwb2ludCBleHRlbnNpb24gYW5kIHRoZSB2YWx1ZSBvZiB0aGlzIGNvbXBvbmVudCBpbiB0 aGUgcHJlc2VudGVkIHZhbHVlIGVxdWFscyB0aGUgY29ycmVzcG9uZGluZyB2YWx1ZSwgaW4gYXQg bGVhc3Qgb25lIG5hbWUgZm9ybSwgaW4gdGhhdCBleHRlbnNpb24uDTEyLjcuNwlBbGdvcml0aG0g aWRlbnRpZmllciBtYXRjaA1UaGUgYWxnb3JpdGhtIGlkZW50aWZpZXIgbWF0Y2ggcnVsZSBjb21w YXJlcyBmb3IgZXF1YWxpdHkgYSBwcmVzZW50ZWQgdmFsdWUgd2l0aCBhbiBhdHRyaWJ1dGUgdmFs dWUgb2YgdHlwZSBTdXBwb3J0ZWRBbGdvcml0aG0uIA1hbGdvcml0aG1JZGVudGlmaWVyTWF0Y2gg TUFUQ0hJTkctUlVMRQk6Oj0gICB7CwlTWU5UQVgJCUFsZ29yaXRobUlkZW50aWZpZXILCUlECQkJ aWQtbXItYWxnb3JpdGhtSWRlbnRpZmllck1hdGNoIH0NVGhlIHJ1bGUgcmV0dXJucyBUUlVFIGlm IHRoZSBwcmVzZW50ZWQgdmFsdWUgaXMgZXF1YWwgdG8gdGhlIGFsZ29yaXRobUlkZW50aWZpZXIg Y29tcG9uZW50IG9mIHRoZSBzdG9yZWQgYXR0cmlidXRlIHZhbHVlLg0xMy4zCUF0dHJpYnV0ZSBD ZXJ0aWZpY2F0ZSBNYXRjaGluZyBSdWxlDVRoZSBhdHRyaWJ1dGUgY2VydGlmaWNhdGUgbWF0Y2hp bmcgcnVsZSBjb21wYXJlcyBhIHByZXNlbnRlZCB2YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSB2YWx1 ZSBvZiB0eXBlIEF0dHJpYnV0ZUNlcnRpZmljYXRlLiBUaGlzIG1hdGNoaW5nIHJ1bGVzIGFsbG93 cyBtb3JlIGNvbXBsZXggbWF0Y2hpbmcgdGhhbiB0aGUgY2VydGlmaWNhdGVFeGFjdE1hdGNoLg1h dHRyaWJ1dGVDZXJ0aWZpY2F0ZU1hdGNoICBNQVRDSElORy1SVUxFICA6Oj0gIHsLCVNZTlRBWAlB dHRyaWJ1dGVDZXJ0aWZpY2F0ZUFzc2VydGlvbgsJSUQJCWlkLW1yLWF0dHJpYnV0ZUNlcnRpZmlj YXRlTWF0Y2ggIH0NQXR0cmlidXRlQ2VydGlmaWNhdGVBc3NlcnRpb24gIDo6PSAgU0VRVUVOQ0Ug IHsLCXN1YmplY3QJWzBdCUNIT0lDRSB7CwkJYmFzZUNlcnRpZmljYXRlSUQJWzBdICBJc3N1ZXJT ZXJpYWwsCwkJc3ViamVjdE5hbWUJCVsxXSAgR2VuZXJhbE5hbWVzfSBPUFRJT05BTCwLCWlzc3Vl cgkJWzFdCUdlbmVyYWxOYW1lcyBPUFRJT05BTCwLCWF0dENlcnRWYWxpZAlbMl0JR2VuZXJhbGl6 ZWRUaW1lIE9QVElPTkFMLA0JYXR0VHlwZQlbM10JU0VUIE9GIEF0dHJpYnV0ZVR5cGUgT1BUSU9O QUx9DZUJQXQgbGVhc3Qgb25lIGNvbXBvbmVudCBvZiB0aGUgc2VxdWVuY2UgbXVzdCBiZSBwcmVz ZW50DVRoZSBtYXRjaGluZyBydWxlIHJldHVybnMgVFJVRSBpZiBhbGwgb2YgdGhlIGNvbXBvbmVu dHMgdGhhdCBhcmUgcHJlc2VudCBpbiB0aGUgcHJlc2VudGVkIHZhbHVlIG1hdGNoIHRoZSBjb3Jy ZXNwb25kaW5nIGNvbXBvbmVudHMgb2YgdGhlIGF0dHJpYnV0ZSB2YWx1ZSwgYXMgZm9sbG93czoN YSkJYmFzZUNlcnRpZmljYXRlSUQgbWF0Y2hlcyBpZiBpdCBpcyBlcXVhbCB0byB0aGUgSXNzdWVy U2VyaWFsIGNvbXBvbmVudCBvZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZTsNYikJc3ViamVj dE5hbWUgbWF0Y2hlcyBpZiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZSBjb250YWlucyB0aGUg bmFtZSBleHRlbnNpb24gd2l0aCB0aGUgc2FtZSBuYW1lIHR5cGUgYXMgaW5kaWNhdGVkIGluIHRo ZSBwcmVzZW50ZWQgdmFsdWU7DWMpCWlzc3VlciBtYXRjaGVzIGlmIHRoZSBzdG9yZWQgYXR0cmli dXRlIHZhbHVlIGNvbnRhaW5zIHRoZSBuYW1lIGNvbXBvbmVudCBvZiB0aGUgc2FtZSBuYW1lIHR5 cGUgYXMgaW5kaWNhdGVkIGluIHRoZSBwcmVzZW50ZWQgdmFsdWU7DWQpCWF0dENlcnRWYWxpZGQg bWF0Y2hlcyBpZiBpdCBmYWxscyB3aXRoaW4gdGhlIHNwZWNpZmllZCB2YWxpZGl0eSBwZXJpb2Qg b2YgdGhlIHN0b3JlZCBhdHRyaWJ1dGUgdmFsdWUuDWUpIAlmb3IgZWFjaCBhdHRUeXBlIGluIHRo ZSBwcmVzZW50ZWQgdmFsdWUsIHRoZXJlIGlzIGFuIGF0dHJpYnV0ZSBvZiB0aGF0IHR5cGUgcHJl c2VudCBpbiB0aGUgYXR0cmlidXRlcyBjb21wb25lbnQgb2YgdGhlIHN0b3JlZCB2YWx1ZS4NMTgu Mi40CVJlYWRlciBhbmQgS2V5IElkZW50aWZpZXIgTWF0Y2hpbmcgUnVsZQ1BIG1hdGNoaW5nIHJ1 bGUgZm9yIGEgbGlzdCBvZiBhdXRob3JpemVkIHJlYWRlcnMgYW5kIHRoZWlyIGFzc29jaWF0ZWQg a2V5cyBpcyBhcyBmb2xsb3dzOg1yZWFkZXJBbmRLZXlJRE1hdGNoIE1BVENISU5HLVJVTEUgIDo6 PSAgewsJU1lOVEFYCVJlYWRlckFuZEtleUlEQXNzZXJ0aW9uCwlJRAkJaWQtbXItcmVhZGVyQW5k S2V5SURNYXRjaCAgfQ1SZWFkZXJBbmRLZXlJREFzc2VydGlvbiAgOjo9ICBTRVFVRU5DRSB7DQsJ a2V5SWRlbnRpZmllcglLZXlJZGVudGlmaWVyLAsJYXV0aFJlYWRlcnMJQXV0aFJlYWRlcnMgT1BU SU9OQUwgIH0NVGhlIG1hdGNoaW5nIHJ1bGUgcmV0dXJucyBhIFRSVUUgaWYgYWxsIG9mIHRoZSBj b21wb25lbnRzIHRoYXQgYXJlIHByZXNlbnQgaW4gdGhlIHByZXNlbnRlZCB2YWx1ZSBtYXRjaCB0 aGUgY29ycmVzcG9uZGluZyBjb21wb25lbnRzIG9mIHRoZSBhdHRyaWJ1dGUgdmFsdWUsIGFzIGZv bGxvd3M6DWEpCWtleUlkZW50aWZpZXIgbWF0Y2hlcyBpZiBpdCBpcyBlcXVhbCB0byB0aGUga2V5 SWRlbnRpZmllciBjb21wb25lbnQgb2YgdGhlIFByb3RlY3RlZEtleSBpbiB0aGUgc3RvcmVkIGF0 dHJpYnV0ZSB2YWx1ZTsNYikJaWYgcHJlc2VudCB0aGUgYXV0aFJlYWRlcnMgbWF0Y2hlcyBpZiBp dCBpcyBlcXVhbCB0byBvbmUgb2YgdGhlIG5hbWVzIGluIHRoZSBhdXRoUmVhZGVycyBjb21wb25l bnQgb2YgdGhlIFByb3RlY3RlZEtleSBpbiB0aGUgc3RvcmVkIGF0dHJpYnV0ZSB2YWx1ZS4NDQ0N DQ0NDQ0NDQ0NUmVmLg1uby4HTWF0Y2hpbmcgUnVsZQdEB0FDUCAxMzMHTm90ZXMNKG15IHJlY29t bWVuZGVkIG9yZGVyIGZvciBzdXBwb3J0ICNuKQcHMS4HYWxnb3JpdGhtSWRlbnRpZmllck1hdGNo B28HbQcjMQcHMi4HYXR0cmlidXRlQ2VydGlmaWNhdGVNYXRjaAdvB20HIzYHBzMuB2F0dHJpYnV0 ZUludGVncml0eU1hdGNoB28HbwcHBzQuB2NlcnRpZmljYXRlRXhhY3RNYXRjaAdvB28HBwc1Lgdj ZXJ0aWZpY2F0ZUxpc3RFeGFjdE1hdGNoB28HbQcjNQcHNi4HY2VydGlmaWNhdGVMaXN0TWF0Y2gH bwdtByM0Bwc3LgdjZXJ0aWZpY2F0ZU1hdGNoB28HbQcjMgcHOC4HY2VydGlmaWNhdGVQYWlyRXhh Y3RNYXRjaAdvB28HBwc5LgdjZXJ0aWZpY2F0ZVBhaXJNYXRjaAdvB20HIzMHBzEwLgdyZWFkZXJB bmRLZXlJRE1hdGNoB28HbQdDb25kaXRpb25hbCBvbiBzdXBwb3J0IG9mIHRoZSBlbmNyeXB0ZWQg dmFyaWFudCBvZiBhdHRyaWJ1dGVzIGFzIGRlc2NyaWJlZCBpbiBQYXJhIDQwOCBvZiBBQ1AgMTMz DSM3BwcNDQ0NVGFibGUgZnJvbSBBQ1AgMTMzLCBBbm5leCBEIC0gVGFibGUgRC0xNS4NDVBsZWFz ZSBub3RlIHRoYXQgaXQgaXNuknQgdmFsaWQgZm9yIGEgRFNBIHRvIGJlIGFibGUgdG8gbWF0Y2gg YXNzZXJ0aW9ucywgdW5sZXNzIHRoZSBjbGllbnRzIGNhbiBhc3NlcnQgdGhlIG1hdGNoIGNyaXRl cmlhLg3QzxHgobEa4QAAAAAAAAAAAAAAAAAAAAA7AAMA/v8JAAYAAAAAAAAAAAAAAAEAAAABAAAA AAAAAAAQAAACAAAAAQAAAP7///8AAAAAAAAAAP////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////8FAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAADgAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPtsvAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAhjMCGQDqvAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAGKYxQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDYuMAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAeAAAAAgAAADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQzxHgobEa4QAAAAAAAAAAAAAAAAAA AAA7AAMA/v8JAP////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////AAMAAFkDAADBAwAAzAMAAM4DAADdAwAA3wMAAO4DAAD0 AwAABgQAABUEAAAWBAAAngQAAKkEAADUBAAA1QQAABQGAAAVBgAAhAYAAI8GAADdBgAA3gYAAC4L AAA6CwAAoAsAAKYLAAAMDAAAIAwAAOsMAAABDQAAKA4AADgOAACbDgAAqg4AAIsPAACgDwAAvw8A AMgPAADaDwAA7g8AAPUPAAAQEAAAPRAAAEUQAAALEQAAGREAAHgRAACAEQAAyREAAM8RAAA8EgAA TBIAAFsSAABsEgAAHBMAACYTAABOFAAAXRQAAJMUAACUFAAAaxYAAHsWAACAFgAAkBYAAN0WAADk FgAA6RYAAPAWAAApFwAAKhcAAKMXAACyFwAARBgAAEUYAAAFGgAAFRoAABoaAAAqGgAAdxoAAH4a AACDGgAAihoAAOQaAADlGgAAdxsAAIYbAACpGwAAqhsAAB8dAAAwHQAAcx0AAHQdAADtHQAA/B0A AGggAABpIAAAAP328Pb99v32/QD99v0A/QD99v0A/fb99v32/fb99v32/fb99v32/fb99v32/fb9 9v32/fb99v32/QD99v32/fb99v0A/fb9AP32/fb99v32/QD99v0A/fb9AP32/QAACl0DAGMSAEkB AAEADFWBXQMAYxIASQEAAQAESQEAAV9pIAAAbCAAAHIgAADYIAAA5CAAAK0hAAC5IQAAhSIAAJAi AADoIgAA9yIAALMjAAC+IwAA/yMAAAkkAABXJAAAYSQAAMckAADRJAAA4CQAAPEkAABcJgAAbiYA AHAmAABxJgAAIScAADQnAABdJwAAhycAAAAoAAA6KAAATygAAFEoAAABKQAACCkAAAkpAAANKQAA LikAAC8pAABPKQAAUCkAAFEpAABYKQAAXCkAAF0pAABeKQAAZykAAHEpAAB9KQAAgSkAAIIpAACO KQAA4ykAAOQpAADlKQAAHSoAAB4qAADEKgAAxSoAAMgqAADZKgAA+CoAAAQrAAAxKwAAPCsAAL8r AADFKwAARiwAAFMsAABzLAAAfSwAAKssAAC5LAAAwCwAAAstAAAWLQAAvi0AAJcuAABDLwAAUC8A AG8vAAB8LwAAji8AAJovAADMLwAA1i8AANcvAAAKMAAAFTAAACcwAAAzMAAA/fb99v32/fb99v32 /fb99v32/fb99v0A/fb9AP0A9AD9AP0A/QD9AP0A/QD9AP0A/QD9AP0A8ez9AP32/fb99v32/ef9 AP0A9AD0AOUA5wDnAPQA9ucA5wD0AAAAAANQFgAIVYFdAwBjEgAACFWBVoFJAQABAARVgVaBAAJV gQAMVYFdAwBjEgBJAQABAARJAQABWjMwAABfMAAAsDAAAMgwAADUMAAA7TAAADkxAABSMQAAXjEA AHIxAACaMQAAszEAAL0xAADRMQAA2TEAANoxAABcMgAABzMAAAD9+v36/fr9+v36/fr99/0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABVAWAFWBBEkBAAEAA1AWAAARAAMAAFgDAABZAwAAbQMAABYEAAA1BAAA1QQAAEYFAACoBQAA FQYAAC4GAADeBgAAQAcAAGUJAACDCgAAKwsAAJ0LAAAJDAAA6AwAACUOAACYDgAAiA8AADoQAAAI EQAAxhEAABkTAAC8EwAA4BMAAJQUAAARFQAAPhUAAHkVAAC1FQAA6xUAACEWAAAqFwAASBcAAEUY AACzGAAA2xgAABEZAABIGQAAfhkAAP0AAsAhCAH7AAHAIQgB+wABwCEIAfkAAsAh8AD3AAHAIfAA +QACwCHwAPMAA8Ah2ADzAAPAIdgA+QACwCHwAPcAAcAh8AD5AALAIfAA8wADwCHYAPMADMAh2ADz AAvAIdgA8QACwCHwAO8AAsAh8ADvAALAIfAA7wADwCHwAO8ABMAh8ADvAALAIfAA7wADwCHwAO8A A8Ah8ADvAAPAIfAA7wADwCHwAO8ABMAh8ADvAALAIfAA9wABwCHwAPkAAsAh8ADzAAPAIdgA8wAB wCHYAO0AAcAh2ADtAAHAIdgA7QABwCHYAO0AAcAh2AD5AAPAIfAA9wABwCHwAPkAA8Ah8ADzAAPA IdgA8wABwCHYAO0AAcAh2ADtAAHAIdgA7QABwCHYAAAAAAAAAAAAAREAAAEPAAABAAAAAxAAEAoA AAABBAAAARMAAAECAAACAgAFACp+GQAAtBkAAOUaAAAJGwAAqhsAACccAABUHAAAZBwAAHocAACu HAAAdB0AAJIdAABDHgAAbB4AAK8eAADXHgAA8B4AAIIfAAC7HwAAaSAAANUgAACqIQAAgiIAALAj AADdJAAAziUAAPAlAABxJgAA5CYAAF4nAACHJwAAUSgAANAoAAC5KQAA5SkAAB4qAADFKgAALisA ALwrAABDLAAArCwAADUtAABkLQAA/gABwCHYAPwAA8Ah8AD6AAHAIfAA/AACwCHwAPYAA8Ah2AD2 AAHAIdgA/gABwCHYAP4AAcAh2AD+AAHAIdgA/AACwCHwAPoAAcAh8AD0AALAIfAA9gABwCHYAP4A AsAh2AD2AAHAIdgA/gABwCHYAP4ABMAh2AD+AAHAIdgA/AACwCHwAPIAAsAh8ADyAAPAIfAA8gAD wCHwAPIABMAh8ADyAATAIfAA8gADwCHwAPoAAcAh8AD8AALAIfAA9gADwCHYAPwAAsAh8ADwAAHA IQgB/AACwCHwAO4AA8Ah2ADuAAbAIdgA/gABwCHYAOwAAcAh3QD8AALAIfAA8gACwCHwAPIAAsAh 8ADyAALAIfAA8gACwCHwAPIAAsAh8ADpAAHAISABAgkABQAAARQAAAEQAAABAgAAAQ8AAAESAAAD EAAQCgAAAAEEAAABEwAAAREAKmQtAAC+LQAAKi4AAFMuAACXLgAAQC8AALovAABTMAAAVDAAAFUw AABWMAAAVzAAAFgwAABZMAAAWjAAAFswAABcMAAAXTAAAF4wAABfMAAAZDAAAGgwAAB2MAAAeDAA AIAwAACGMAAArDAAAK0wAACwMAAAyTAAAMswAADNMAAA0DAAANEwAADUMAAA7jAAAPAwAADyMAAA 9TAAAPYwAAD5MAAA/gABwCHwAPwAA8Ah3QD8AAHAId0A/AADwCHdAP4AAsAh8AD6AALAIfAA+gAC wCHwAPoAAcAh8AD6AAHAIfAA+gABwCHwAPoAAcAh8AD6AAHAIfAA+gABwCHwAPoAAcAh8AD6AAHA IfAA+gABwCHwAPoAAcAh8AD6AAHAIfAA+gABwCHwAPQAAYoB3QD0AAGKAd0A9AABSw3dAPQAAUQB 3QD0AAKsAt0A9AAByxHdAPQAAcsR3QDgAAHLEd0A9AABigHdAPQAAUsN3QD0AAFEAd0A9AABrALd APQAAcsR3QDgAAHLEd0A9AABigHdAPQAAUsN3QD0AAFEAd0A9AABrALdAPQAAcsR3QDgAAHLEd0A 9AABigHdAAAAAAATAAAYARkBuGwAuwoACgAKAAoACQAJAL4OAAUU+3b9mgu2DToR3CMABRQAEAAA EQAAGAEAARUAAAEUAAABEwAo+TAAABExAAATMQAAFTEAABYxAAAXMQAAGjEAADAxAAAyMQAANDEA ADUxAAA2MQAAOTEAAFMxAABVMQAAVzEAAFoxAABbMQAAXjEAAHMxAAB1MQAAdzEAAHoxAAB7MQAA fjEAAI8xAACRMQAAkzEAAJYxAACXMQAAmjEAALQxAAC2MQAAuDEAALkxAAC6MQAAvTEAANIxAADU MQAA1jEAANkxAADaMQAA+gABSw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A +gABSw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A+gABSw3dAPoAAUQB3QD6 AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A+gABSw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYA AcsR3QD6AAGKAd0A+gABSw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A+gAB Sw3dAPoAAUQB3QD6AAGsAt0A+gAByxHdAOYAAcsR3QD6AAGKAd0A+gABSw3dAPoAAUQB3QD6AAGs At0A+gAByxHdAOYAAcsR3QAAAAAAABMAABgBGQG4bAC7CgAKAAoACgAJAAkAvg4ABRT7dv2aC7YN OhHcIwAFFAAQAAARAAAYASnaMQAA3jEAAPIxAAD0MQAA9jEAAFgyAABbMgAAXDIAAF0yAABeMgAA XzIAAGAyAACKMgAAizIAAAczAAD6AAGKAd0A+gABSw3dAPoAAUQB3QD6AAGsAt0A+gACyxHdAPoA AcsR3QDmAAHLEd0A5AABwCHwAOQAAcAh8ADkAAHAIfAA5AABwCHwAOQAAcAh8ADkAAHAIfAA5AAC wCHwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAAAAEwAAGAEZAbhsALsKAAoACgAKAAkACQC+DgAFFPt2/ZoLtg06 EdwjAAUUABAAABEAABgBDg4AFwAIAAEASwAPAAAAAAAaAABA8f8CABoABk5vcm1hbAACAAAAAwBh CQQALgABQAEAAgAuAAlIZWFkaW5nIDEAAAoAAQAIARXwABY8AAsAVYFdAgBjHABrHAAASgACQAEA AgBKAA5IZWFkaW5nIDIsMixsMQAhAAIABQMHAQgBERoDE+b8FTkBDw4ABBoDpwQ0BsEHAAAAAAAL AFWBXQQAYQkIYxYAACgAA0ABAAIAKAAJSGVhZGluZyAzAAAKAAMACAEV8AAWPAAFAFWBYxgAAEgA BEAxAAIASAAOSGVhZGluZyA0LDQsbDMAIgAEAAUDBwERGgMT5vwVtQAWAAAPDgAEGgOnBDQGwQcA AAAACQBdBABhCQhjFAAAAAAAAAAAAAAwAAlAEQACADAACUhlYWRpbmcgOQAADAAJAAUBBwEV4AEW AAAMAF0EAGEJCGMYAGsAACIAQUDy/6EAIgAWRGVmYXVsdCBQYXJhZ3JhcGggRm9udAAAAAAAAAAA AAAAOgD+TwEA8gA6AAhlbnVtbGV2MQAdAA8ABQMRpwQTc/4VVgAPDgAEGgOnBDQGwQcAAAAAAAYA XQQAYQkIRAD+TwEAEgFEAAVBU04uMQAAJAAQABWIAA8dAAn+Af0DpwQ0BmsIEwtKDQ8QYBQAAAAA AAAAAAALAFWBXQMAYQkIYxIAACAA/k8BARIBIAALQVNOLjEgQ29udC4AAAUAEQAVAAAAAAAkAP5P AQACACQAAmxiAA8AEgAFAwgBEA4AFYgAFngAAAMAXQQAADgAQkABADIBOAAJQm9keSBUZXh0AAAa ABMABQMViAAWeAAPDgAEGgOnBDQGwQcAAAAABgBdBABhCQheAP5PAQBCAV4AA2FzbgAAQwAUAAcB ECsAEWwCFCT/AAAWeAAPLwAPawKOBLIGHQmIC/MNXhDKEjUVoBcLGnYc4h5NIbgjQEBAQEBAQEBA QEBAQEBAAAgAVYFdAwBjEgAkAP5PAQBSASQAAmxpAA0AFQAFAxHQAhOY/hZ4AAAFAF0EAGIBABoA /k+iAGEBGgAKQVNOLjEgV29yZAADAGEABAAAAAAABzAAAAUA/////wAA/////wYABCH//wEAACH/ /wIABCH//wMAACH//wQABCH//wUAACD//wYAAAAAAEYHAAAhEwAAuxwAAB4nAABfLQAABzAAAAAA PQAAAAEACQEAAAIArgAAAAMApwAAAAQABQAAAAUAAAAAAAAAAADQJQAAHicAAC4oAAC8KAAAQykA AJcrAAAHMAAAmgAUAJoAFACaABMAmgATAJoAEwCaABQABgAAAAADAABpIAAAMzAAAAczAAAaABsA HAAAAwAAfhkAAGQtAAD5MAAA2jEAAAczAAAdAB4AHwAgACEAIgANU3VlIEEuIE1pa2xvcxFDOlxY NTAwXE1BVENILkRPQ/9ASFAgTGFzZXJKZXQgNVNpLzVTaSBNWABMUFQyOgBIUDVTSQBIUCBMYXNl ckpldCA1U2kvNVNpIE1YAAAAAAAAAAAAAAoDNwJEAJABA/cAAAEAAQDAGMASZAABAAcAWAIBAAEA WAICAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANwIBAAAACAAAAAEAA1BYAlgCBgACAAAAAQAAEFdJ TldPUkQAAAAAAAEAAAAAgAEAAQABAAAAAAAAAAAAAAAAAAABQ291cmllciBOZXcAAAAAAAAAAAAA AAAAAAAAAAAAAACwBJABAAADACAABwAAACgAAAAIAAEAAgABAAYAAwABAFgCAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwlMUFQyAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhQNVNJ AAAAAABIUCBMYXNlckpldCA1U2kvNVNpIE1YAAAAAAAAAAAAAAoDNwJEAJABA/cAAAEAAQDAGMAS ZAABAAcAWAIBAAEAWAICAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANwIBAAAACAAAAAEAA1BYAlgC BgACAAAAAQAAEFdJTldPUkQAAAAAAAEAAAAAgAEAAQABAAAAAAAAAAAAAAAAAAABQ291cmllciBO ZXcAAAAAAAAAAAAAAAAAAAAAAAAAAACwBJABAAADACAABwAAACgAAAAIAAEAAgABAAYAAwABAFgC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdwlMUFQyAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAEhQNVNJAAAAAAABgAEABjAAAAYwAAAJAACAAIAGMAAABQAAAFwvAABlABUWkAEAAFRp bWVzIE5ldyBSb21hbgAMFpABAgBTeW1ib2wACyaQAQAAQXJpYWwAFiKQAQAKSGVsdmV0aWNhAEFy aWFsAPIcEpABAAZUaW1lcwBUaW1lcyBOZXcgUm9tYW4AACIABAABCIgYAADQAgAAaAEAAAAAUPMV puErG2YAAAAABAAbAAAAAAAAAAAAAAAAAAAAAAAEAIMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABZAkEAAAATMTIuNwlNYXRjaGluZyBydWxlcwAAAA1TdWUgQS4gTWlrbG9zDVN1ZSBBLiBNaWts b3MAAAAAAAAAAAAA0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAAB AAAAAQAAAAAAAAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////8= ------ =_NextPart_000_01BDE7B3.26345CD0-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21795 for ietf-pkix-bks; Thu, 24 Sep 1998 07:59:51 -0700 (PDT) Received: from always.got.net (root@you.got.net [207.111.232.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21791 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 07:59:50 -0700 (PDT) Received: from got.net (SantaCruz-x2-3-133.got.net [209.66.100.133]) by always.got.net (8.8.8/8.8.7/Debian/GNU) with ESMTP id IAA22427; Thu, 24 Sep 1998 08:05:37 -0700 Message-ID: <360A5FAF.9012BC3D@got.net> Date: Thu, 24 Sep 1998 08:05:20 -0700 From: Michael McNeil <memcneil@got.net> Organization: GMT X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: Denis Pinkas <Denis.Pinkas@bull.net> CC: Stephen Kent <kent@bbn.com>, Warwick Ford <wford@verisign.com>, ietf-pkix@imc.org, Jeffrey Schiller <jis@mit.edu> Subject: Re: meeting minutes References: <v04011701b22c2cbc4e8e@[128.33.238.151]> <3609BEDD.B8F71C12@got.net> <360A8F3E.B7DA84C5@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Denis Pinkas wrote: >Michael, >As you say it, the minutes from the meeting are correct. >>Stephen Kent wrote: >>[snip] >>>NEW TOPICS: >>>- Timestamp & Notary proposals (Carlisle Adams) >>> >>>Several folks continuing work on these topics and have published >>>an independent draft on these topics. The authors received a fair >>>amount of private feedback, and hope to be able to bring forward a >>>well-formed proposal. Jeff Schiller gave his permission to bring >>>this into the WG, based on the WG having made substantial progress >>>on the other work items. Thus we will expand the charter to >>>encompass these topics. >>This is what occurred during the PKIX sessions at the 42nd IETF >>meeting with regards to timestamping; however the above is not >>the whole story. >> >>Between sessions at the IETF meeting I talked with various people >>about the new Internet-Draft (authored by Dave Mills, Todd Glassey, >>and me) which extends the NTP protocol towards serving as a vehicle >>for PKI certified and secured time ("ephemeral" time; "what time is >>it *now*?" time), as well as also providing for *timestamps* of >>data -- within the same protocol, essentially as gravy (a different >>usage, I admit). >From your short description, people might think that the two drafts >are equivalent. Yes, thank you for pointing that out. The two sets of drafts are quite distinct, of course, as we're well aware. I thought insufficiently of the readers' perspective in wording the description unfortunately. >Let me highlight some of the main differences: >Let us call: > >"draft 1", the draft: >ftp://ietf.org/internet-drafts/draft-adams-time-stamp-02.txt Et al. >and "draft 2", the draft: >ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-01.txt > >Draft 1 is all in ASN1, as the rest of the other messages supported >by PKIX, e.g. CMP. So it is in the spirit of the other documents. On >the contrary, Draft 2 is supporting 32 bits words and is much more >compact (unless that advantage will be lost by many extensions !) We think not, but good point. >The time formats are different between draft 1 and 2. Draft 1 is >using the same time format as the rest of the PKIX documents, while >draft 2 is using a 32 bits time representation. NTP actually uses 64 bits of time, with 32 bits of fractional second information. The 32-bit seconds count will roll over in 2038; I have suggested (Dave Mills and I disagree as to the desirability of this) that 8-bit extensions to the time fields be added in an extension field. >Draft 1 supports the time stamping of an imprint and as a side >effect, may provide a trusted time when using the optional nonces. The question is what would be the quality of the time (ephemeral time) passed using that protocol. A heavyweight protocol almost by definition takes more time to convey than a lightweight one -- and it's the quality of the time itself that we're interested in here (ignoring timestamps for the moment). A longer time to pass the time futzes the precision of the time. Moreover, draft 1 lacks the fractional seconds information NTP maintains, lacks the extra fields NTP possesses which allow it to communicate the accuracy of the time and the last time that the server's time was updated from a reliable source. These last deficiencies can be fixed, of course, in the draft 1 proposal (though perhaps not the "heavyweight" issue); any deficiencies in the draft 2 protocol noted below can also be repaired (except perhaps the "lightweight" issue). ;-) >Draft 2 is unclear about time stamping, in particular the indication >of the hash function used for the imprint and its protection. It >allows various extension fields and so the minimum format to be >supported is left undefined. Draft 2 is a work in progress (this last is the second version), and admittedly is less finished in this regard than draft 1. We expect to have another Internet-Draft ready for publication, with details of the important extensions fields fleshed out, by the 43rd IETF in December. >It is also unclear about the replay protection when only the time >is returned (unless that information is present is some other >documents ?). NTP has inherent replay resistance in that if your time is already reasonably good, replay attacks are instantly visible as being old. Moreover, NTP normally (despite conveying an absolute time) only steers the time -- it doesn't reset a machine to a radically different time, appearing out of the blue within an NTP packet. Even so, additional authentication is desirable to present spurious NTP attacks; that is the point of the "draft 2" Internet-Draft. A more fundamental protection against replay attacks, from a cryptographic point of view, is to require that the client as a sanity check do a unicast probe of the server every now and then, rather than depending on broadcast packets, including random bits of its own in its request -- which then get echoed back in the signed NTP reply from the server. Detecting its bits in the reply, the client knows it's in response to its own most recent request. >>I spoke with Jeff Schiller about this. After he'd had a chance >>to look over the Internet-Draft (i.e., >><draft-mills-ntp-auth-coexist-01.txt>), we spoke again, very near >>the end of the IETF meeting. Jeff at that time suggested that >>since it was now apparent to him that the issue of PKI and time >>goes well beyond the question of timestamps to the issue of how >>secure *time itself* can be conveyed over an insecure network, he >>thought that perhaps the PKIX working group was not equipped to >>properly address this expanded issue -- or at least Jeff thought >>the IESG ought to be consulted first on the question before the >>issue of PKIX handling it or a separate "time" working group >>being set up is laid to rest. >From what is above, "draft 2" would not be usable in a PKIX >environment, where the compactness of the messages is not the >issue, since the Time Stamp will be used mostly either in a >store and forward environment or in a local environment. > >However, there may be some good reasons to have a 32 bits >oriented and more compact protocol for acquiring a secure time >for other environments and therefore it can make sense to have >two protocols. I agree. >>Thus the issue stands as far as I know. I've addressed two e-mails >>to Jeff since the IETF meeting (on 8 and 21 September) but so far >>have not received a reply (I assume it takes time to poll the IESG >>membership). I have no particular stake in which way the decision >>goes (except I think *some* working group needs to address time >>*and* timestamping), >I am not sure that a *single* working group needs to address both >time and timestamping. Good point. >As a good example, we have already have the PKIX and the SPKI >working groups: PKIX is using ASN.1, while SPKI does not. >A similar parallelism ! :-) A parallelism I hope doesn't draw a rain of stones and bricks! ;-) >>but wished to alert you that despite the outcome of the PKIX sessions, >>the question of whether PKIX handles it appears not quite settled. Thank you for your comments, Denis! Regards, Michael McNeil GMT memcneil@got.net 1-831-438-7811 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21579 for ietf-pkix-bks; Thu, 24 Sep 1998 07:25:27 -0700 (PDT) Received: from bilbo.thawte.com (bilbo.thawte.com [196.25.207.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21575 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 07:25:14 -0700 (PDT) Received: from thawte.com (really [196.25.207.2]) by thawte.com via in.smtpd with esmtp id <m0zMCQA-0004eAC@bilbo.thawte.com> (Debian Smail3.2.0.101) for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 16:31:02 +0200 (SAST) Message-ID: <360A56AA.93669667@thawte.com> Date: Thu, 24 Sep 1998 16:26:50 +0200 From: Mark Shuttleworth <marks@thawte.com> Reply-To: marks@thawte.com Organization: Thawte Consulting X-Mailer: Mozilla 4.5b2 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: NEW Data type for certificate selection ? Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms78C9DE34404C8A045EF33A31" Sender: owner-ietf-pkix@imc.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms78C9DE34404C8A045EF33A31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiya I'd love to see a general solution to this problem. For example, this might enable servers to run multiple SSL servers on one IP/port address, instead of requiring an IP per secure domain. It might also work well with our Strong Extranet, because the server could say "I need a client cert from one of these CA's, and it must have an identity in this sxnet zone". -- Mark Shuttleworth Thawte --------------ms78C9DE34404C8A045EF33A31 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH8AYJKoZIhvcNAQcCoIIH4TCCB90CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BhMwggLSMIICO6ADAgECAgItQzANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5 OC45LjE2MB4XDTk4MDkxNjE4MzQ1NFoXDTk5MDkxNjE4MzQ1NFowczEVMBMGA1UEBBMMU2h1 dHRsZXdvcnRoMRUwEwYDVQQqEwxNYXJrIFJpY2hhcmQxIjAgBgNVBAMTGU1hcmsgUmljaGFy ZCBTaHV0dGxld29ydGgxHzAdBgkqhkiG9w0BCQEWEG1hcmtzQHRoYXd0ZS5jb20wXDANBgkq hkiG9w0BAQEFAANLADBIAkEAw8CXH/zhGBuu9boNBAXbPp+77G8rFuuuzboLsKl5DkqfgmXf /JOadF3bwNG1QetRQKuEQek4jTNQPqjxdiQo/QIDAQABo3IwcDARBglghkgBhvhCAQEEBAMC BaAwDgYDVR0PAQH/BAQDAgWgMBwGBStlAQQBBBMwEQIBADAMMAoCAQEEBW1hcmtzMAwGA1Ud EwEB/wQCMAAwHwYDVR0jBBgwFoAU/j5gnGuMD7DYM8bKxh5YsHE4teAwDQYJKoZIhvcNAQEE BQADgYEATUOQ3uxrewGzaUVHZZgsul+T2PrBsQMe/Tw2CZO7jjj0EM4ajBLo334y5xJNBtjo n9SoxhnEhfKo5GQsXgy+Ugb0FxFlrP3d1gMNHzDmg80gxw5JCPuzgN6IQGBXewnxdb2W2tse Gbo5uJjquMwIggkVMd8Hz2O8uQvIBm1LdZowggM5MIICoqADAgECAgEKMA0GCSqGSIb3DQEB BAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20w HhcNOTgwOTE2MTc1NTM0WhcNMDAwOTE1MTc1NTM0WjCBuTELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAxNzo1 NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5OC45 LjE2MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpeXU1NBfCALuByF9JL+ra44e6yAH AhWEa4/QkyQfG53uaLK5LE/pk2cXEBceoflDQSO5MKp2l7vz5/2BwLUxi/amUCZU8pUo6xmk HpcesOK4m8EEmjLQPAlsT+Q1T/B2vwATA09FCGDz/LTQkAGKEsmcun9S6iqTNTY8POQ1LwID AQABozcwNTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFHJJwnM0xlX0C3ZygX53 9IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBACzHgh8BQz4Hj+5pXKlkgvjAlq2TK8ubUNdAmoHC uqZ2nTyVQNxVweFVgnmrCimm1QzhVyg+j/m71d8Nk1iqWy2LjzPk3VgVNXZyFSm9QvRakgt3 X50n25otThuCBo7SjVa7ld7bDGUF3pWeAt1TF76+/GvDGiJ6FCthvcKfXnpaMYIBpTCCAaEC AQEwgcAwgbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcT C0R1cmJhbnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhh d3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNgICLUMwCQYFKw4DAhoFAKB9MBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MDkyNDE0MjY1MFowHgYJ KoZIhvcNAQkPMREwDzANBggqhkiG9w0DAgIBKDAjBgkqhkiG9w0BCQQxFgQUdte0yJez9q3I TJRb4V+uB9bopawwDQYJKoZIhvcNAQEBBQAEQDhgTnn8/oGeVEanel2njqWPQsFdd4BaZzO6 6aRt8q/LvBwyO+baEiC25qSgyfF6iOA8AV4l7WDZu5Y/2B6r6Eg= --------------ms78C9DE34404C8A045EF33A31-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21513 for ietf-pkix-bks; Thu, 24 Sep 1998 07:21:25 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21509 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 07:21:24 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02163; Thu, 24 Sep 1998 10:27:24 -0400 (EDT) Message-Id: <199809241427.KAA02163@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt Date: Thu, 24 Sep 1998 10:27:24 -0400 Sender: owner-ietf-pkix@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure LDAPv2 Schema Author(s) : S. Boeyen, T. Howes, P. Richard Filename : draft-ietf-pkix-ldapv2-schema-02.txt Pages : 7 Date : 23-Sep-98 The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in draft-ietf-pkix- ipki2opp-07.txt. Only PKIX-specific components are specified here. LDAP servers, acting as PKIX repositories should support the auxi- liary object classes defined in this specification and integrate this schema specification with the generic and other application- specific schemas as appropriate, depending on the services to be supplied by that server. The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in this document are to be interpreted as described in RFC 2119. Please send comments on this document to the ietf-pkix@imc.org mail list. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ldapv2-schema-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980923172008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ldapv2-schema-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980923172008.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21495 for ietf-pkix-bks; Thu, 24 Sep 1998 07:20:40 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21491 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 07:20:39 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02093; Thu, 24 Sep 1998 10:26:39 -0400 (EDT) Message-Id: <199809241426.KAA02093@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-dcs-00.txt Date: Thu, 24 Sep 1998 10:26:39 -0400 Sender: owner-ietf-pkix@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Data Certification Server Protocols Author(s) : C. Adams, R. Zuccherato Filename : draft-ietf-pkix-dcs-00.txt Pages : 14 Date : 23-Sep-98 This document describes a general data certification service and the protocols to be used when communicating with it. The Data Certification Server is a Trusted Third Party (TTP) that can be used as one component in building reliable non-repudiation services (see [ISONR]). Useful Data Certification Server responsibilities in a PKI are to validate signatures and to provide up-to-date information regarding the status of public key certificates. We give examples of how to use the Data Certification Server to extend the lifetime of a signature beyond key expiry or revocation and to query the Data Certification Server regarding the status of a public key certificate. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119 [RFC2119]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-dcs-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-dcs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980923134838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-dcs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-dcs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980923134838.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21490 for ietf-pkix-bks; Thu, 24 Sep 1998 07:20:35 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21486 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 07:20:34 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02081; Thu, 24 Sep 1998 10:26:34 -0400 (EDT) Message-Id: <199809241426.KAA02081@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-time-stamp-00.txt Date: Thu, 24 Sep 1998 10:26:34 -0400 Sender: owner-ietf-pkix@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Time Stamp Protocols Author(s) : C. Adams, P. Cain, B. Pinkas, R. Zuccherato Filename : draft-ietf-pkix-time-stamp-00.txt Pages : 15 Date : 23-Sep-98 This document describes the format of the data returned by a Time Stamp Authority and the protocols to be used when communicating with it. The time stamping service can be used as a Trusted Third Party (TTP) as one component in building reliable non-repudiation services (see [ISONR]). In order to reduce the amount of trust required of a TSA we introduce (in Appendix C) the optional Temporal Data Authority (TDA) whose function is to provide further corroborating evidence of the time contained in the token. We also give an example of how to place a signature at a particular point in time, from which the appropriate certificate status information (e.g. CRLs) may be checked. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-time-stamp-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-time-stamp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980923134327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-time-stamp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-time-stamp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980923134327.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21482 for ietf-pkix-bks; Thu, 24 Sep 1998 07:20:10 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21477 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 07:20:08 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02063; Thu, 24 Sep 1998 10:26:09 -0400 (EDT) Message-Id: <199809241426.KAA02063@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-11.txt Date: Thu, 24 Sep 1998 10:26:08 -0400 Sender: owner-ietf-pkix@imc.org Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Certificate and CRL Profile Author(s) : R. Housley, W. Ford, T. Polk, D. Solo Filename : draft-ietf-pkix-ipki-part1-11.txt Pages : 128 Date : 23-Sep-98 This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. An overview of the approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms (e.g., IP addresses). Standard certificate extensions are described, and a set of required extensions is defined. The X.509 v2 CRL format is described and a required extension set is defined as well. An algorithm for X.509 certificate path validation is described. Supplemental information is provided describing the format of public keys and digital signatures in X.509 certificates for common Internet public key encryption algorithms (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are provided in the appendices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119. Please send comments on this document to the ietf-pkix@imc.org mail list. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ipki-part1-11.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-11.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ipki-part1-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980923132903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ipki-part1-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ipki-part1-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980923132903.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21425 for ietf-pkix-bks; Thu, 24 Sep 1998 07:06:55 -0700 (PDT) Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21421 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 07:06:54 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA09631; Thu, 24 Sep 1998 07:12:51 -0700 (PDT) Message-Id: <199809241412.HAA09631@spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta) Date: Thu, 24 Sep 1998 09:56:50 -0400 To: "Todd S. Glassey" <TSGman@earthlink.net> From: Russ Housley <housley@spyrus.com> Subject: Re: Amending the PKIX-WG Charter to reflect the addition of timestamping Cc: ietf-pkix@imc.org In-Reply-To: <001c01bde698$615e7640$200ba8c0@tsg-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk It looks okay to me..... At 07:17 PM 9/22/98 -0700, you wrote: >Hi All, back in February we were working to amend the PKI WG's charter to >encompass timestamping and the certified timer resources that enable these >facilities. Now that Jeff Schiller has OK'd PKIX's having its own >timestamping/timebase facility we need to finish the charter update process. >here then is a proposed charter for your review and comments. > >Thanks, > >----- > >Todd Glassey > >Stephen Kent's report of the meeting minutes - excerpt below - > >- Timestamp & Notary proposals (Carlisle Adams) > >Several folks continuing work on these topics and have published an >independent draft on >these topics. The authors received a fair amount of private feedback, and >hope to be able to >bring forward a well-formed proposal. Jeff Schiller gave his permission to >bring this into >the WG, based on the WG having made substantial progress on the other work >items. Thus >we will expand the charter to encompass these topics. > > >----- BEGINNING OF CHARTER TEXT ---- > >Public-Key Infrastructure (X.509) (PKIX) >-------------------------------------------------- > > Charter > Last Modified: September 18, 1998 > > Current Status: Active Working Group > >Chair(s): >Stephen Kent <kent@bbn.com> >Warwick Ford <wford@verisign.com> > >Security Area Director(s): >Jeffrey Schiller <jis@mit.edu> >Marcus Leech <mleech@nortel.ca> > >Security Area Advisor: >Jeffrey Schiller <jis@mit.edu> > >Mailing Lists: >General Discussion:ietf-pkix@imc.org >To Subscribe: ietf-pkix-request@imc.org >In Body: subscribe (In Body) >Archive: http://www.imc.org/ietf-pkix > >Description of Working Group: >Many Internet protocols and applications which use the Internet employ >public-key technology for security purposes and require a public-key >infrastructure (PKI) to securely manage public keys for widely-distributed >users or systems. The X.509 standard constitutes a widely-accepted basis >for such >an infrastructure, defining data formats and procedures related to >distribution >of public keys via certificates digitally signed by certification >authorities >(CAs). > >For example, RFC 1422 specified the basis of an X.509-based PKI, targeted >primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM). >Since RFC 1422 was issued, application requirements for an Internet PKI have >broadened tremendously, and the capabilities of X.509 have advanced with the >development of standards defining the X.509 version 3 certificate and >version 2 certificate revocation list (CRL). > >Charter of the Working Group: >The charter of the working group will be to develop Internet standards >needed to support the use of an X.509-based PKI. The goal of this Working >Group (WG) >will be to further facilitate the use of X.509 certificates in applications >that >make use of the Internet and to promote interoperability between different >implementations choosing to make use of X.509 certificates. > >The resulting PKI is intended to provide a framework, which will support a >range of trust/hierarchy environments and a range of usage environments >(RFC1422 >is an example of one such model). > >Candidate applications to be served by this PKI include, but are not limited >to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), IPSEC protocols, Internet >payment protocols, time based authentication, timestamping, and www >protocols. > >This project will not preclude use of non-infrastructure public-key >distribution techniques nor of non-X.509 PKIs by such applications. Efforts >will be made to coordinate with the IETF White Pages (X.500/WHOIS++) >project. > >The group will focus on tailoring and profiling the features available in >the v3 X.509 certificate to best match the requirements and characteristics >of the >Internet environment. > >Other topics to be addressed potentially include: > > * Alternatives for CA-to-CA certification links and structures, >including > guidelines for constraints > > * Revocation alternatives, including profiling of X.509 v2 CRL >extensions > * Certificate and CRL distribution options (X.500-based, >non-X.500-based) > * Guidelines for policy definition and registration > * Administrative protocols and procedures, including certificate > generation, revocation notification, cross-certification, and >key-pair > updating > * Naming and name forms (how entities are identified, e.g., email > address, URN, DN, misc.) > * Generation of client key pairs by the PKI > * Services that support non-repudiation. This can include sources of > credible time data and/or certificate path validation services. > >----- END OF CHARTER TEXT ---- > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20975 for ietf-pkix-bks; Thu, 24 Sep 1998 05:50:11 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA20971 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 05:50:10 -0700 (PDT) Received: id IAA22113; Thu, 24 Sep 1998 08:54:41 -0400 Received: by gateway id <S2S6ZMGZ>; Thu, 24 Sep 1998 08:51:16 -0400 Message-ID: <D789F71F24B4D111955D00A0C99B4F500206DD59@sothmxs01.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: CryptoNEWS@aol.com, "'Denis Pinkas'" <Denis.Pinkas@bull.net> Cc: ietf-pkix@imc.org Subject: RE: X.509 Documentation Date: Thu, 24 Sep 1998 08:51:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA20972 Sender: owner-ietf-pkix@imc.org Precedence: bulk On the server that Denis pointed to, you'll find the final text of the 1997 edition of X.509 (as submitted to the ITU and ISO for publication) at: ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc (the primary reason this is not yet available for purchase from either ITU or ISO is that they will not publish or sell it until all the other parts of the 1997 X.500 Series are also ready (soon we're told by the editor). As for current work underway in X.509, there is a Working Document which is currently being revised to reflect the outcome of the September meeting. The previous version of that document is available at: ftp://ftp.bull.com/pub/OSIdirectory/Phoenix98Output/CertificateExtensionsWD. doc When the revisions are complete (within 2 months) the new version will likely be found in: ftp://ftp.bull.com/pub/OSIdirectory/Beijing98/Vancouver98/ These two documents provide a complete picture of the X.509 activity except of course for defect reports. These are recorded together with the defects on the other parts of the X.500 Series at the bull.com site, but at present it is somewhat out of date (should be updated within 2 months as well). Hope this helps. Sharon > ---------- > From: Denis Pinkas[SMTP:Denis.Pinkas@bull.net] > Sent: September 24, 1998 2:59 PM > To: CryptoNEWS@aol.com > Cc: ietf-pkix@imc.org > Subject: Re: X.509 Documentation > > CryptoNEWS@aol.com a écrit: > > > Ladies and Gentlemen, > > > > Some body posted an address of a site where a document for X.509 can be > > obtained. > > Can that kind person post the information again? > > Take a look at :ftp://ftp.bull.com/pub/OSIdirectory/ > > Denis > > > Thanks, > > > > CryptoNEWS > > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20857 for ietf-pkix-bks; Thu, 24 Sep 1998 05:38:06 -0700 (PDT) Received: from maild.telia.com (root@maild.telia.com [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20853 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 05:38:04 -0700 (PDT) Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by maild.telia.com (8.8.8/8.8.8) with ESMTP id OAA03085; Thu, 24 Sep 1998 14:44:08 +0200 (CEST) Received: from stefans (t4o68p1.telia.com [62.20.139.121]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id OAA25911; Thu, 24 Sep 1998 14:44:02 +0200 (CEST) Message-Id: <3.0.32.19980924144039.00a6ccf0@m1.403.telia.com> X-Sender: u40400192@m1.403.telia.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 24 Sep 1998 14:41:23 +0200 To: ietf-pkix@imc.org, list@seis.nc-forum.com, ietf-tls@consensus.com, cert-talk@structuredarts.com From: Stefan Santesson <stefan@accurata.se> Subject: NEW Data type for certificate selection ? Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA20854 Sender: owner-ietf-pkix@imc.org Precedence: bulk All, During the TLS session in Chicago (IETF meeting) I discussed with Jeff Weinstein, Netscape, the problem of certificate selection in an environment where the client is populated with many similar certificates for different purposes. We concluded that this is a general problem, not only for TLS, but for S/MIME, Java, Java script, etc, where signing and encryption based on an X.509 PKI is an option. I also conclude that the current TLS approach, using Issuer name as selection criteria, is hopelessly insufficient for the general case. In fact we can NEVER claim that we have an X.509 based architecture ready for the big market IF WE DON'T SOLVE THIS PROBLEM. A normal user (I.e grandmother) will never be able to pick the right certificate by herself, if there is more than 1 to pick. The question raised here is: WOULD A STANDARDIZED DATA TYPE FOR CERTIFICATE SELECTION BE A GOOD START. If we could create a standardized ASN.1 data type with the purpose of defining the criteria for selecting 1 out of n certificates, then this could be used as a common base for enhancing TLS, Java, Java script, S/MIME etc. The data type could be communicated from server to client, client to server, server to server, client to client; I.e in any case where one party which to assist another party in selecting an appropriate certificate for any purpose (defined by the context). Do anyone have a better idea. I think this is a lost problem that has to be fixed, hopefully in a standardized way. Comments, suggestions. /Stefan Santesson ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20658 for ietf-pkix-bks; Thu, 24 Sep 1998 04:54:03 -0700 (PDT) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20654 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 04:54:02 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id XAA13067; Thu, 24 Sep 1998 23:59:34 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90663837419831>; Thu, 24 Sep 1998 23:59:34 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Petra.Gloeckner@darmstadt.gmd.de, ietf-pkix@imc.org Subject: Re: basic constraint extension Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Thu, 24 Sep 1998 23:59:34 (NZST) Message-ID: <90663837419831@cs26.cs.auckland.ac.nz> Sender: owner-ietf-pkix@imc.org Precedence: bulk >the draft-ietf-pkix-ipki-part1-10 says the basic constraint extension MUST >appear as a critical extension in all CA certificates but it SHOULD NOT >appear in end entity certificates. > >Why should the basic constraint extension not appear in end entity >certificates? Looking back through the different versions, this has been in there since at least -08, although not worded quite as strongly as this. It seems like a Bad Thing, since this clashes with the (US) federal profile and Australian profile and... well I'm not going to enumerate them all, but unless there's some really good reason for it I don't see why it should be absent, especially since the generally accepted way (other profiles notwithstanding) seems to be to encode it as an empty sequence in end-user certs. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18001 for ietf-pkix-bks; Thu, 24 Sep 1998 02:51:43 -0700 (PDT) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA17997 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 02:51:41 -0700 (PDT) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id LAA09608; Thu, 24 Sep 1998 11:59:00 +0200 Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA15648; Thu, 24 Sep 1998 11:59:08 +0200 (DFT) Message-ID: <360A968C.FD285E0E@bull.net> Date: Thu, 24 Sep 1998 11:59:24 -0700 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.03 [fr] (Win16; I) MIME-Version: 1.0 To: CryptoNEWS@aol.com CC: ietf-pkix@imc.org Subject: Re: X.509 Documentation References: <4932bdcf.360a0cc8@aol.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk CryptoNEWS@aol.com a écrit: > Ladies and Gentlemen, > > Some body posted an address of a site where a document for X.509 can be > obtained. > Can that kind person post the information again? Take a look at :ftp://ftp.bull.com/pub/OSIdirectory/ Denis > Thanks, > > CryptoNEWS Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA17852 for ietf-pkix-bks; Thu, 24 Sep 1998 02:21:50 -0700 (PDT) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA17848 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 02:21:47 -0700 (PDT) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id LAA12895; Thu, 24 Sep 1998 11:28:09 +0200 Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA16688; Thu, 24 Sep 1998 11:27:58 +0200 (DFT) Message-ID: <360A8F3E.B7DA84C5@bull.net> Date: Thu, 24 Sep 1998 11:28:15 -0700 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.03 [fr] (Win16; I) MIME-Version: 1.0 To: Michael McNeil <memcneil@got.net> CC: Stephen Kent <kent@bbn.com>, Warwick Ford <wford@verisign.com>, ietf-pkix@imc.org, Jeffrey Schiller <jis@mit.edu> Subject: Re: meeting minutes References: <v04011701b22c2cbc4e8e@[128.33.238.151]> <3609BEDD.B8F71C12@got.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Michael, As you say it, the minutes from the meeting are correct. > Stephen Kent wrote: > [snip] > >NEW TOPICS: > >- Timestamp & Notary proposals (Carlisle Adams) > > > >Several folks continuing work on these topics and have published > >an independent draft on these topics. The authors received a fair > >amount of private feedback, and hope to be able to bring forward a > >well-formed proposal. Jeff Schiller gave his permission to bring > >this into the WG, based on the WG having made substantial progress > >on the other work items. Thus we will expand the charter to > >encompass these topics. > > This is what occurred during the PKIX sessions at the 42nd IETF meeting > with regards to timestamping; however the above is not the whole story. > > Between sessions at the IETF meeting I talked with various people about > the new Internet-Draft (authored by Dave Mills, Todd Glassey, and me) > which extends the NTP protocol towards serving as a vehicle for PKI > certified and secured time ("ephemeral" time; "what time is it *now*?" > time), as well as also providing for *timestamps* of data -- within the > same protocol, essentially as gravy (a different usage, I admit). >From your short description, people might think that the two drafts are equivalent. Let me highlight some of the main differences: Let us call: "draft 1", the draft: ftp://ietf.org/internet-drafts/draft-adams-time-stamp-02.txt and "draft 2", the draft: ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-01.txt Draft 1 is all in ASN1, as the rest of the other messages supported by PKIX, e.g. CMP. So it is in the spirit of the other documents. On the contrary, Draft 2 is supporting 32 bits words and is much more compact (unless that advantage will be lost by many extensions !) The time formats are different between draft 1 and 2. Draft 1 is using the same time format as the rest of the PKIX documents, while draft 2 is using a 32 bits time representation. Draft 1 supports the time stamping of an imprint and as a side effect, may provide a trusted time when using the optional nonces. Draft 2 is unclear about time stamping, in particular the indication of the hash function used for the imprint and its protection. It allows various extension fields and so the minimum format to be supported is left undefined. It is also unclear about the replay protection when only the time is returned (unless that information is present is some other documents ?). > I spoke with Jeff Schiller about this. After he'd had a chance to look > over the Internet-Draft (i.e., <draft-mills-ntp-auth-coexist-01.txt>), > we spoke again, very near the end of the IETF meeting. Jeff at that > time suggested that since it was now apparent to him that the issue of > PKI and time goes well beyond the question of timestamps to the issue of > how secure *time itself* can be conveyed over an insecure network, he > thought that perhaps the PKIX working group was not equipped to properly > address this expanded issue -- or at least Jeff thought the IESG ought > to be consulted first on the question before the issue of PKIX handling > it or a separate "time" working group being set up is laid to rest. >From what is above, "draft 2" would not be usable in a PKIX environment, where the compactness of the messages is not the issue, since the Time Stamp will be used mostly either in a store and forward environment or in a local environment. However, there may be some good reasons to have a 32 bits oriented and more compact protocol for acquiring a secure time for other environments and therefore it can make sense to have two protocols. > Thus the issue stands as far as I know. I've addressed two e-mails to > Jeff since the IETF meeting (on 8 and 21 September) but so far have not > received a reply (I assume it takes time to poll the IESG membership). > I have no particular stake in which way the decision goes (except I > think *some* working group needs to address time *and* timestamping), I am not sure that a *single* working group needs to address both time and timestamping. As a good example, we have already have the PKIX and the SPKI working groups: PKIX is using ASN.1, while SPKI does not. A similar parallelism ! :-) Regards, Denis > but wished to alert you that despite the outcome of the PKIX sessions, > the question of whether PKIX handles it appears not quite settled. > > Regards, > Michael McNeil > GMT > memcneil@got.net > 1-831-438-7811 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA17767 for ietf-pkix-bks; Thu, 24 Sep 1998 02:05:52 -0700 (PDT) Received: from imo26.mx.aol.com (imo26.mx.aol.com [198.81.17.70]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA17763 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 02:05:50 -0700 (PDT) From: CryptoNEWS@aol.com Received: from CryptoNEWS@aol.com by imo26.mx.aol.com (IMOv16.10) id 7HBDa02301 for <ietf-pkix@imc.org>; Thu, 24 Sep 1998 05:11:36 -0400 (EDT) Message-ID: <4932bdcf.360a0cc8@aol.com> Date: Thu, 24 Sep 1998 05:11:36 EDT To: ietf-pkix@imc.org Mime-Version: 1.0 Subject: X.509 Documentation Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 224 Sender: owner-ietf-pkix@imc.org Precedence: bulk Ladies and Gentlemen, Some body posted an address of a site where a document for X.509 can be obtained. Can that kind person post the information again? Thanks, CryptoNEWS Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA29806 for ietf-pkix-bks; Wed, 23 Sep 1998 20:33:18 -0700 (PDT) Received: from always.got.net (root@you.got.net [207.111.232.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA29799 for <ietf-pkix@imc.org>; Wed, 23 Sep 1998 20:33:17 -0700 (PDT) Received: from got.net (SantaCruz-x2-3-133.got.net [209.66.100.133]) by always.got.net (8.8.8/8.8.7/Debian/GNU) with ESMTP id UAA17148; Wed, 23 Sep 1998 20:39:22 -0700 Message-ID: <3609BEDD.B8F71C12@got.net> Date: Wed, 23 Sep 1998 20:39:10 -0700 From: Michael McNeil <memcneil@got.net> Organization: GMT X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: Stephen Kent <kent@bbn.com>, Warwick Ford <wford@verisign.com> CC: ietf-pkix@imc.org, Jeffrey Schiller <jis@mit.edu> Subject: Re: meeting minutes References: <v04011701b22c2cbc4e8e@[128.33.238.151]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Stephen Kent wrote: [snip] >NEW TOPICS: >- Timestamp & Notary proposals (Carlisle Adams) > >Several folks continuing work on these topics and have published >an independent draft on these topics. The authors received a fair >amount of private feedback, and hope to be able to bring forward a >well-formed proposal. Jeff Schiller gave his permission to bring >this into the WG, based on the WG having made substantial progress >on the other work items. Thus we will expand the charter to >encompass these topics. This is what occurred during the PKIX sessions at the 42nd IETF meeting with regards to timestamping; however the above is not the whole story. Between sessions at the IETF meeting I talked with various people about the new Internet-Draft (authored by Dave Mills, Todd Glassey, and me) which extends the NTP protocol towards serving as a vehicle for PKI certified and secured time ("ephemeral" time; "what time is it *now*?" time), as well as also providing for *timestamps* of data -- within the same protocol, essentially as gravy (a different usage, I admit). I spoke with Jeff Schiller about this. After he'd had a chance to look over the Internet-Draft (i.e., <draft-mills-ntp-auth-coexist-01.txt>), we spoke again, very near the end of the IETF meeting. Jeff at that time suggested that since it was now apparent to him that the issue of PKI and time goes well beyond the question of timestamps to the issue of how secure *time itself* can be conveyed over an insecure network, he thought that perhaps the PKIX working group was not equipped to properly address this expanded issue -- or at least Jeff thought the IESG ought to be consulted first on the question before the issue of PKIX handling it or a separate "time" working group being set up is laid to rest. Thus the issue stands as far as I know. I've addressed two e-mails to Jeff since the IETF meeting (on 8 and 21 September) but so far have not received a reply (I assume it takes time to poll the IESG membership). I have no particular stake in which way the decision goes (except I think *some* working group needs to address time *and* timestamping), but wished to alert you that despite the outcome of the PKIX sessions, the question of whether PKIX handles it appears not quite settled. Regards, Michael McNeil GMT memcneil@got.net 1-831-438-7811 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24408 for ietf-pkix-bks; Wed, 23 Sep 1998 11:00:10 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA24404 for <ietf-pkix@imc.org>; Wed, 23 Sep 1998 11:00:08 -0700 (PDT) Message-Id: <199809231800.LAA24404@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta) Date: Wed, 23 Sep 1998 11:05:32 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Fwd: I-D ACTION:draft-ietf-tls-ac509prof-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk I thought this might be of interest to the PKIX WG. --Paul Hoffman, Director --Internet Mail Consortium >To: IETF-Announce: ; >Cc: ietf-tls@consensus.com >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-tls-ac509prof-00.txt >Date: Wed, 23 Sep 1998 10:43:01 -0400 >Sender: cclark@ns.cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Transport Layer Security Working Group of >the IETF. > > Title : An Internet AttributeCertificate Profile > for Authorization > Author(s) : S. Farrell > Filename : draft-ietf-tls-ac509prof-00.txt > Pages : 11 > Date : 22-Sep-98 > > Authorization support is required for various Internet > protocols, for example, TLS, CMS and their consumers, > and others. The X.509 AttributeCertificate provides a > structure which can form the basis for such services > [X.509]. This specification defines two profiles (a > simple one and a 'full' one) for the use of X.509 > AttributeCertificates to provide such authorization > services. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-tls-ac509prof-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-ac509prof-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-tls-ac509prof-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <19980922141332.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-tls-ac509prof-00.txt > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-ac509prof-00.txt> Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22037 for ietf-pkix-bks; Wed, 23 Sep 1998 06:57:39 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA22033 for <ietf-pkix@imc.org>; Wed, 23 Sep 1998 06:57:37 -0700 (PDT) Received: id KAA28894; Wed, 23 Sep 1998 10:01:06 -0400 Received: by gateway id <S2S6Z20Q>; Wed, 23 Sep 1998 09:57:44 -0400 Message-ID: <D789F71F24B4D111955D00A0C99B4F50AC97BC@sothmxs01.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Cc: "'Steve Kent'" <kent@bbn.com>, "'Warwick Ford'" <wford@verisign.com> Subject: Revised LDAPv2 specs have been submitted Date: Wed, 23 Sep 1998 09:57:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk A revision of the PKIX LDAPv2 protocol profile has been submitted and notice should appear shortly. The only reason for this revision is because the previous one (in the hands of the IESG pending submission of an accompanying schema spec) exires this month. No changes other than updating version number, date and the name of the ietf-pkix mail list were made. A revision of the PKIX LDAPv2 schema I-D has been submitted and notice should appear shortly. This revision addresses the comments submitted during PKIX WG last call. Sharon ------------------ Sharon Boeyen Entrust Technologies mailto:sharon.boeyen@entrust.com Tel: (613) 247-3181 http://www.entrust.com Fax: (613) 247-3690 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA21064 for ietf-pkix-bks; Wed, 23 Sep 1998 04:29:19 -0700 (PDT) Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA21060 for <ietf-pkix@imc.org>; Wed, 23 Sep 1998 04:29:00 -0700 (PDT) Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by maila.telia.com (8.8.8/8.8.8) with ESMTP id NAA12330; Wed, 23 Sep 1998 13:35:13 +0200 (CEST) Received: from stefans (t4o68p71.telia.com [62.20.139.191]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id NAA26921; Wed, 23 Sep 1998 13:35:09 +0200 (CEST) Message-Id: <3.0.32.19980923133149.00a71210@m1.403.telia.com> X-Sender: u40400192@m1.403.telia.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 23 Sep 1998 13:32:27 +0200 To: Al Arsenault <aarsenault@spyrus.com>, Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, "Arsenault, Al W." <awarsen@missi.ncsc.mil> From: Stefan Santesson <stefan@accurata.se> Subject: Re: PKIX Roadmap Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA21061 Sender: owner-ietf-pkix@imc.org Precedence: bulk Al, I totally agree with everything you say in this last mail. /Stefan At 08:15 AM 9/22/98 -0400, Al Arsenault wrote: >At 06:25 AM 9/22/98 +0200, Stefan Santesson wrote: >>Al, >> >>Just a short reply to CA disaster (See below). >> >>Thanks for your reply, I still disagree to the disaster part. >> >>CA2 does not have to be dismanteled, since CA 2:s key is intact. >>What has to be done is that: >>- CA1 is rebuilt with new key >>- The compromise of CA1 and its new key has to be communicated with >>out-of-band means >>- CA1 cross certify CA2 (and other CA:s) using the new key >>- New cross certificates to CA1 has to be issued and published by other CA:s. >> >>Now all certificates issued by CA2 before the disaster of CA1 can be used >>and trusted. >>This since the disaster of CA1 didn't destroy CA2, just the link to CA2 >>from CA1. >> >>/Stefan > >Stefan, > > The more I think about this, the more I realize we agree. It's the words >that need figuring out. Perhaps the words in the draft roadmap are too >strong; we'll have to think about that. > > First, let me note that when CA1 and CA2 are cross-certified - that is, >have a peer relationship, with neither subordinate to the other - I agree >with you about what happens when CA1's key is compromised. > > Now, let us assume that there is a hierarchical relationship - CA2 is >subordinate to CA1. This means to me that the trust anchor used by end >entities below CA2 is not CA2 - it's CA1. When CA1's key is discovered to >be compromised, what you do is: > > 1 - communicate out of band the compromise. This means that CA2 and all >entities below it are essentially "out of action" temporarily; since CA1 is >the trust anchor, there's no way to construct a valid cert path > > 2 - reconstitute CA1 with a new key; > > 3 - get CA2's key to CA1 for certification (most likely through >out-of-band means). Yes, this can still be the same key; since CA2's key >wasn't compromised, it can still be used, and it will make things easier in >that you don't have to go re-signing end-entity certs with a new CA2 key. > >Now, you're back in action. > >If you agree that this is right, we can figure out words that say that. >The point I wanted to convey is that the entire PKI is dead in this case >until CA1 is brought up and a new CA2 cert is signed, because you can't >construct a valid path back to a valid trust anchor. > >(Of course, if trust anchor's compromised key happens to be on all >end-entity hardware tokens in a form that can't easily be changed, you've >still got a problem, but that's beyond the scope of PKIX :-) > > Al Arsenault > >- the above opinions are my own. They may or may not reflect the opinions >of my employer or of any other organization with which I have a relationship. > > > > > ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA17883 for ietf-pkix-bks; Wed, 23 Sep 1998 00:56:18 -0700 (PDT) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA17879 for <ietf-pkix@imc.org>; Wed, 23 Sep 1998 00:56:16 -0700 (PDT) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id KAA15024 for <ietf-pkix@imc.org>; Wed, 23 Sep 1998 10:03:30 +0200 Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id KAA17156 for <ietf-pkix@imc.org>; Wed, 23 Sep 1998 10:03:37 +0200 (DFT) Message-ID: <360929FB.C577E062@bull.net> Date: Wed, 23 Sep 1998 10:03:55 -0700 From: Denis Pinkas <Denis.Pinkas@bull.net> X-Mailer: Mozilla 4.03 [fr] (Win16; I) MIME-Version: 1.0 To: IETF-PXIX <ietf-pkix@imc.org> Subject: Archive cutoff & Retention period Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Archive cutoff & Retention period This item has been separated from my list of other comments since it might start a new thread. On page 12 there is section 5.4.4. named « Archive Cutoff ». In part PKIX-1 on page 12, we have the following sentence: An entry may be removed from the CRL after appearing on one regularly scheduled CRL issued beyond the revoked certificate's validity period. This means that a revoked entry has to stay at least "little bit" after the expiration date of the certificate. In practice this is a few days, but not necessarily years because the size of the information to keep would be pretty big. So we need to make a difference between a "retention period" of a few days and a possible archiving of the status information during years (see later). The "retention period" should be supported by all OCSP responders and thus should be part of the standard response. Adding a "retentionPeriod" after the "produceAt" from the ResponseData would be simpler than defining an extension. Then, let us address the « Archive Cutoff » issue. If we were to support the archiving capability, with e.g. a 7 year retention, we would need an additional time parameter in the request to point to the equivalent of the right CRL issued at that time e.g. 7 years ago. This parameter is currently not present. Unless it is added, the function cannot work. We thus have two options : add the missing parameter or delete this capability. Opinions ? Denis Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA17850 for ietf-pkix-bks; Wed, 23 Sep 1998 00:52:30 -0700 (PDT) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA17846 for <ietf-pkix@imc.org>; Wed, 23 Sep 1998 00:52:25 -0700 (PDT) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id JAA04146 for <ietf-pkix@imc.org>; Wed, 23 Sep 1998 09:59:15 +0200 Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA12434 for <ietf-pkix@imc.org>; Wed, 23 Sep 1998 09:59:22 +0200 (DFT) Message-ID: <360928FB.2D9D963E@bull.net> Date: Wed, 23 Sep 1998 09:59:40 -0700 From: Denis Pinkas <Denis.Pinkas@bull.net> X-Mailer: Mozilla 4.03 [fr] (Win16; I) MIME-Version: 1.0 To: IETF-PXIX <ietf-pkix@imc.org> Subject: Minor comments on OCSP-06 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Here are a few minor/editorial comments on OCSP-06. An additional comment (on "Archive cutoff") has been separated from this list of comments since it might generate a new thread. Some of them might be a duplication of comments already made. 1. On page 2, in the second paragraph of the section 3 a sentence may let think that once the OCSP server replies « good » the certificate can be accepted. The only thing that is known is « not revoked ». A better rewording would be : « An OCSP client issues a status request to an OCSP responder and obtains a revocation status of the certificate in question. » 2. On page 3, third paragraph before the bottom of the page. The term « produceAt » is used but not yet introduced. For clarity of reading a rephrasing should be made. Hereafter is a proposal : « At the minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the current time is within the certificates validity interval ». 3. On page 3, second paragraph before the bottom of the page. « On hold » is reason code under « revoke ». In the explanations it would be nice to remember here that « on hold » is under this category. Here is a proposal: « The « revoked » state indicates that the certificate has been definitively or temporarily revoked (i.e. placed on hold). » 4. On page 4, in the fifth paragraph of the section 3.3. the response « certRequired » is of no use any more since only a CertId can be placed in the request. Therefore it should be deleted. [This comment has already be made]. 5. On page 6, the fifth item of the section 4.2. states : « The response is in its validity period ». It is unclear to understand what this means. It may be guessed that it is the time interval between the « thisUpdate » and « nextUpdate ». However in section 5.2.2.1. pages 9/10, nextUpdate is optional so this test cannot be done in general. By splitting this item into two items, a better wording would be : 6. The time at which the status being indicated is known to be correct (thisUpdate) is sufficiently recent. 7. When available, the time at or before which newer information will be available about the status of the certificate (nextUpdate)is greater than the current time. 8. On page 8, in the same way « certRequired (4) » should be deleted. [This comment has already be made] 9. On page 9, CRLReason should be expanded so that the « on hold » status can be made visible. This is pretty important since by trying again it is possible to get later on a « good » result. 10. On page 11, The section 5.4 "Extensions" should be renumbered 6 in order to have a section dealing with all the optional extensions. Denis Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA02987 for ietf-pkix-bks; Tue, 22 Sep 1998 19:13:48 -0700 (PDT) Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.120.50]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA02983 for <ietf-pkix@imc.org>; Tue, 22 Sep 1998 19:13:47 -0700 (PDT) Received: from tsg-laptop (1Cust96.tnt4.sfo1.da.uu.net [208.250.191.96]) by avocet.prod.itd.earthlink.net (8.8.7/8.8.5) with SMTP id TAA10448 for <ietf-pkix@imc.org>; Tue, 22 Sep 1998 19:20:08 -0700 (PDT) From: "Todd S. Glassey" <TSGman@earthlink.net> To: "Ietf-Pkix" <ietf-pkix@imc.org> Subject: Amending the PKIX-WG Charter to reflect the addition of timestamping Date: Tue, 22 Sep 1998 19:17:57 -0700 Message-ID: <001c01bde698$615e7640$200ba8c0@tsg-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-pkix@imc.org Precedence: bulk Hi All, back in February we were working to amend the PKI WG's charter to encompass timestamping and the certified timer resources that enable these facilities. Now that Jeff Schiller has OK'd PKIX's having its own timestamping/timebase facility we need to finish the charter update process. here then is a proposed charter for your review and comments. Thanks, ----- Todd Glassey Stephen Kent's report of the meeting minutes - excerpt below - - Timestamp & Notary proposals (Carlisle Adams) Several folks continuing work on these topics and have published an independent draft on these topics. The authors received a fair amount of private feedback, and hope to be able to bring forward a well-formed proposal. Jeff Schiller gave his permission to bring this into the WG, based on the WG having made substantial progress on the other work items. Thus we will expand the charter to encompass these topics. ----- BEGINNING OF CHARTER TEXT ---- Public-Key Infrastructure (X.509) (PKIX) -------------------------------------------------- Charter Last Modified: September 18, 1998 Current Status: Active Working Group Chair(s): Stephen Kent <kent@bbn.com> Warwick Ford <wford@verisign.com> Security Area Director(s): Jeffrey Schiller <jis@mit.edu> Marcus Leech <mleech@nortel.ca> Security Area Advisor: Jeffrey Schiller <jis@mit.edu> Mailing Lists: General Discussion:ietf-pkix@imc.org To Subscribe: ietf-pkix-request@imc.org In Body: subscribe (In Body) Archive: http://www.imc.org/ietf-pkix Description of Working Group: Many Internet protocols and applications which use the Internet employ public-key technology for security purposes and require a public-key infrastructure (PKI) to securely manage public keys for widely-distributed users or systems. The X.509 standard constitutes a widely-accepted basis for such an infrastructure, defining data formats and procedures related to distribution of public keys via certificates digitally signed by certification authorities (CAs). For example, RFC 1422 specified the basis of an X.509-based PKI, targeted primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM). Since RFC 1422 was issued, application requirements for an Internet PKI have broadened tremendously, and the capabilities of X.509 have advanced with the development of standards defining the X.509 version 3 certificate and version 2 certificate revocation list (CRL). Charter of the Working Group: The charter of the working group will be to develop Internet standards needed to support the use of an X.509-based PKI. The goal of this Working Group (WG) will be to further facilitate the use of X.509 certificates in applications that make use of the Internet and to promote interoperability between different implementations choosing to make use of X.509 certificates. The resulting PKI is intended to provide a framework, which will support a range of trust/hierarchy environments and a range of usage environments (RFC1422 is an example of one such model). Candidate applications to be served by this PKI include, but are not limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), IPSEC protocols, Internet payment protocols, time based authentication, timestamping, and www protocols. This project will not preclude use of non-infrastructure public-key distribution techniques nor of non-X.509 PKIs by such applications. Efforts will be made to coordinate with the IETF White Pages (X.500/WHOIS++) project. The group will focus on tailoring and profiling the features available in the v3 X.509 certificate to best match the requirements and characteristics of the Internet environment. Other topics to be addressed potentially include: * Alternatives for CA-to-CA certification links and structures, including guidelines for constraints * Revocation alternatives, including profiling of X.509 v2 CRL extensions * Certificate and CRL distribution options (X.500-based, non-X.500-based) * Guidelines for policy definition and registration * Administrative protocols and procedures, including certificate generation, revocation notification, cross-certification, and key-pair updating * Naming and name forms (how entities are identified, e.g., email address, URN, DN, misc.) * Generation of client key pairs by the PKI * Services that support non-repudiation. This can include sources of credible time data and/or certificate path validation services. ----- END OF CHARTER TEXT ---- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA25907 for ietf-pkix-bks; Tue, 22 Sep 1998 05:29:18 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA25903 for <ietf-pkix@imc.org>; Tue, 22 Sep 1998 05:29:16 -0700 (PDT) Received: id IAA16369; Tue, 22 Sep 1998 08:31:45 -0400 Received: by gateway id <S2S6Z1VK>; Tue, 22 Sep 1998 08:28:25 -0400 Message-ID: <D789F71F24B4D111955D00A0C99B4F50AC97A8@sothmxs01.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Cc: "'Steve Kent'" <kent@bbn.com>, "'Warwick Ford'" <wford@verisign.com>, "'Santosh Chokhani'" <chokhani@sisko.cygnacom.com> Subject: text for attributes Date: Tue, 22 Sep 1998 08:28:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk Although we have not reached specific wording which is 100% agreed by everyone, we have reached agreement on what the contents of the cACertificate and crossCertificatePair attributes are to be used for. In order to bring this to closure, Santosh and I plan to go with the advice of our co-chairs and proceed with the word 'realm', along with the clarification that its meaning is defined locally and hope everyone will be willing to live with that. Also, this will be liaised to the X.509 group as the PKIX recommendation to resolve the associated defect report in that standard. Thanks to everyone for their input and I assume I'm not the only one looking forward to a reduced amount of email each morning :-) ------------------ Sharon Boeyen Entrust Technologies mailto:sharon.boeyen@entrust.com Tel: (613) 247-3181 http://www.entrust.com Fax: (613) 247-3690 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA25745 for ietf-pkix-bks; Tue, 22 Sep 1998 05:13:14 -0700 (PDT) Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA25741 for <ietf-pkix@imc.org>; Tue, 22 Sep 1998 05:13:13 -0700 (PDT) Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA15055; Tue, 22 Sep 1998 05:17:57 -0700 (PDT) Message-Id: <3.0.6.32.19980922081543.00902790@mail.spyrus.com> X-Sender: aarsenault@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 22 Sep 1998 08:15:43 -0400 To: Stefan Santesson <stefan@accurata.se>, Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, "Arsenault, Al W." <awarsen@missi.ncsc.mil> From: Al Arsenault <aarsenault@spyrus.com> Subject: Re: PKIX Roadmap In-Reply-To: <3.0.32.19980922062458.00a7e6f0@m1.403.telia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk At 06:25 AM 9/22/98 +0200, Stefan Santesson wrote: >Al, > >Just a short reply to CA disaster (See below). > >Thanks for your reply, I still disagree to the disaster part. > >CA2 does not have to be dismanteled, since CA 2:s key is intact. >What has to be done is that: >- CA1 is rebuilt with new key >- The compromise of CA1 and its new key has to be communicated with >out-of-band means >- CA1 cross certify CA2 (and other CA:s) using the new key >- New cross certificates to CA1 has to be issued and published by other CA:s. > >Now all certificates issued by CA2 before the disaster of CA1 can be used >and trusted. >This since the disaster of CA1 didn't destroy CA2, just the link to CA2 >from CA1. > >/Stefan Stefan, The more I think about this, the more I realize we agree. It's the words that need figuring out. Perhaps the words in the draft roadmap are too strong; we'll have to think about that. First, let me note that when CA1 and CA2 are cross-certified - that is, have a peer relationship, with neither subordinate to the other - I agree with you about what happens when CA1's key is compromised. Now, let us assume that there is a hierarchical relationship - CA2 is subordinate to CA1. This means to me that the trust anchor used by end entities below CA2 is not CA2 - it's CA1. When CA1's key is discovered to be compromised, what you do is: 1 - communicate out of band the compromise. This means that CA2 and all entities below it are essentially "out of action" temporarily; since CA1 is the trust anchor, there's no way to construct a valid cert path 2 - reconstitute CA1 with a new key; 3 - get CA2's key to CA1 for certification (most likely through out-of-band means). Yes, this can still be the same key; since CA2's key wasn't compromised, it can still be used, and it will make things easier in that you don't have to go re-signing end-entity certs with a new CA2 key. Now, you're back in action. If you agree that this is right, we can figure out words that say that. The point I wanted to convey is that the entire PKI is dead in this case until CA1 is brought up and a new CA2 cert is signed, because you can't construct a valid path back to a valid trust anchor. (Of course, if trust anchor's compromised key happens to be on all end-entity hardware tokens in a form that can't easily be changed, you've still got a problem, but that's beyond the scope of PKIX :-) Al Arsenault - the above opinions are my own. They may or may not reflect the opinions of my employer or of any other organization with which I have a relationship. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA25513 for ietf-pkix-bks; Tue, 22 Sep 1998 04:31:33 -0700 (PDT) Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA25509 for <ietf-pkix@imc.org>; Tue, 22 Sep 1998 04:31:31 -0700 (PDT) Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA78840; Tue, 22 Sep 1998 13:36:57 +0200 Received: by HYDRA with Microsoft Mail id <01BDE62D.342F16E0@HYDRA>; Tue, 22 Sep 1998 13:30:45 +0200 Message-ID: <01BDE62D.342F16E0@HYDRA> From: Anders Rundgren <anders.rundgren@jaybis.com> To: "'Denis Pinkas'" <Denis.Pinkas@bull.net> Cc: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: RE: OCSP - Public Key Dstribution Date: Tue, 22 Sep 1998 13:30:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Denis, > something that is nontrivial. And "Certificate Domain" is also missing. ??? Certificate Domain is some kind of indication of what kind of certificate(s) you want to validate. I.e. like SET-certificates, a National ID-card, OBI-trader etc. This could be of interest in both the request and in the response. I.e. a trusted OCSP server may support overlapping or disjunct domains and a typical subscriber may be interested in just one type. To standardize this seems unnecessary in the same sense as defining trust models in OCSP. It is a *deployment* issue like certificate policies and liabilities. Other extensions, like certificate validation might be considered once OCSP is closed. I assume that the "closing" of OCSP will be pretty theoretical when the definition of extensions starts. Already an IETF agenda item it seems Regards Anders Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA25221 for ietf-pkix-bks; Tue, 22 Sep 1998 03:35:04 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA25217 for <ietf-pkix@imc.org>; Tue, 22 Sep 1998 03:35:01 -0700 (PDT) Received: from darmstadt.gmd.de (pc-ravenna [141.12.33.61]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id LAA28659; Tue, 22 Sep 1998 11:28:34 +0200 (MET DST) Message-ID: <36076D59.62280554@darmstadt.gmd.de> Date: Tue, 22 Sep 1998 11:26:49 +0200 From: "Petra Glöckner" <Petra.Gloeckner@darmstadt.gmd.de> X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: ietf-pkix@imc.org CC: herfert@darmstadt.gmd.de Subject: basic constraint extension References: <199809081502.LAA04610@ietf.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6C21A3596B2679A5F64C275F" Sender: owner-ietf-pkix@imc.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms6C21A3596B2679A5F64C275F Content-Type: multipart/mixed; boundary="------------C84E92343668538B0D7F006C" This is a multi-part message in MIME format. --------------C84E92343668538B0D7F006C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, the draft-ietf-pkix-ipki-part1-10 says the basic constraint extension MUST appear as a critical extension in all CA certificates but it SHOULD NOT appear in end entity certificates. Why should the basic constraint extension not appear in end entity certificates ? Is it purely to safe some bits or is there another reason, like keeping the draft more flexibel, e.g. to allow an end entity to issue a certificate for his encryption key himself using his signature key and certificate ? In general, is it possible for an end entity to use his signature key and certificate to issue a certificate for his encryption key himself ? Or do you have to have the CA bit set to true in your certificate in order to be able to issue certificates for your own encryption keys ? Any ideas and thoughts are welcome ! Best regards - Petra --------------C84E92343668538B0D7F006C Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Petra Glöckner Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Petra Glöckner n: ;Petra Glöckner org: GMD-TKT email;internet: Petra.Gloeckner@darmstadt.gmd.de x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------C84E92343668538B0D7F006C-- --------------ms6C21A3596B2679A5F64C275F Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIO7wYJKoZIhvcNAQcCoIIO4DCCDtwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DVcwggMFMIICbqADAgECAgIC8zANBgkqhkiG9w0BAQQFADB2MQswCQYDVQQGEwJERTEMMAoG A1UEChMDR01EMR8wHQYDVQQLExZDTEFTUyAwIFRSSUFMIFNFUlZJQ0VTMTgwNgYDVQQLEy9U cnVzdEZhY3RvcnkgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENlcnRpZmljYXRlczAeFw05ODA3 MTMxNzQ2NDlaFw0wMDAxMDEwMDAwMDBaMGYxCzAJBgNVBAYTAkRFMQwwCgYDVQQKEwNHTUQx LzAtBgkqhkiG9w0BCQEWIFBldHJhLkdsb2Vja25lckBkYXJtc3RhZHQuZ21kLmRlMRgwFgYD VQQDEw9QZXRyYSBHbG9lY2tuZXIwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAwgqVtX54BPIm LAu+u8i7lnOV6lf+79amGCL9Ao5UOStKuLHC2dwH7MP5A8gPVeeiP1kk2tr9hXJmIVDYP7kS cQIDAQABo4H1MIHyMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgCwMIHRBglghkgBhvhC AQ0EgcMWgcBDQVVUSU9OOiBUaGUgRGlnaXRhbCBJRCBzdWJqZWN0cyBvZiBJQ0UtVEVMCkNs YXNzIDAgVHJpYWwgU2VydmljZXMgYXJlIG5vdCBhdXRoZW50aWNhdGVkLgpJdCBtYXkgYmUg dGhlIGhvbGRlcidzIHJlYWwgbmFtZSBvciBhbiBhbGlhcy4KVXNlIHRoaXMgRGlnaXRhbCBJ RCBmb3IgdGVzdCBwdXJwb3NlZCBvbmx5LgooYykgR01EIDE5OTcwDQYJKoZIhvcNAQEEBQAD gYEASgeR+7xR+g2YPSXpdAojcDD1jeo2sMa1hyspawERPfLgagUDcaX5MS/TjYZ8K3lz3Tve G6U0pWPwRBtAnns/A8hoNApONSQEXupnhNgaRwljFEXm+shdanA33iZKfs6NVCnb1Mbs96pK xUgpXw4TRe//afL0nNiaRCmSfXohytgwggOhMIIDCqADAgECAgEBMA0GCSqGSIb3DQEBBAUA MGcxCzAJBgNVBAYTAkRFMQwwCgYDVQQKEwNHTUQxHzAdBgNVBAsTFkNMQVNTIDAgVFJJQUwg U0VSVklDRVMxKTAnBgNVBAsTIFRydXN0RmFjdG9yeSBEaWdpdGFsIElEIFNlcnZpY2VzMB4X DTk3MTIxNzA4MDMyNloXDTAwMDEwMTAwMDAwMFowdjELMAkGA1UEBhMCREUxDDAKBgNVBAoT A0dNRDEfMB0GA1UECxMWQ0xBU1MgMCBUUklBTCBTRVJWSUNFUzE4MDYGA1UECxMvVHJ1c3RG YWN0b3J5IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDZXJ0aWZpY2F0ZXMwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBANQJUsDpSSmA85HJLPHj4jDUTWXPUwYaqNvA3r3AdhFqIacLQwtn FOoMR4CZqaewurOWI23kw2NK4/2I+GdTwkk5aEYAo4eA9FFwHBxq+b80xbO4ymTKxkah8DTv acv+JkLwFnjc7DEzuJoK61ywR8UJP/FQjD53o8ATXhoGNIIDAgMBAAGjggFMMIIBSDAfBgNV HSMEGDAWgBR43QkpxguDM6Uc3wFLHlNH8iD1SzAdBgNVHQ4EFgQUM47EbBv7+7Tjj2OaluUR VEIj7fwwDgYDVR0PAQH/BAQDAgH2MA8GA1UdEwEB/wQFMAMBAf8wEQYJYIZIAYb4QgEBBAQD AgAHMIHRBglghkgBhvhCAQ0EgcMWgcBDQVVUSU9OOiBUaGUgRGlnaXRhbCBJRCBzdWJqZWN0 cyBvZiBJQ0UtVEVMCkNsYXNzIDAgVHJpYWwgU2VydmljZXMgYXJlIG5vdCBhdXRoZW50aWNh dGVkLgpJdCBtYXkgYmUgdGhlIGhvbGRlcidzIHJlYWwgbmFtZSBvciBhbiBhbGlhcy4KVXNl IHRoaXMgRGlnaXRhbCBJRCBmb3IgdGVzdCBwdXJwb3NlZCBvbmx5LgooYykgR01EIDE5OTcw DQYJKoZIhvcNAQEEBQADgYEAXWnV7vH1s9e0opHh/Hk1nOgpxEbx7XaSAbnVzdUoOxxKvbkl o0QaB79OV4oLkrFAscMU8iKWN9RkBmWuartRnq45DRsAWMur8DlgbrShlMBEC71OsE2I1FMP xGe/rJwp2x5Or1M1mchKI808S7WblPyJxCBOMt3Q1in7F1Boz1wwggNgMIICyaADAgECAgEB MA0GCSqGSIb3DQEBBAUAMEgxDzANBgNVBAcTBkV1cm9wZTEQMA4GA1UEChMHSUNFLVRFTDEj MCEGA1UECxMaQ0xBU1MgMCBUUklBTCBTRVJWSUNFUyBQS0kwHhcNOTcxMjE3MDgwMzI0WhcN MDAwMTAxMDAwMDAwWjBnMQswCQYDVQQGEwJERTEMMAoGA1UEChMDR01EMR8wHQYDVQQLExZD TEFTUyAwIFRSSUFMIFNFUlZJQ0VTMSkwJwYDVQQLEyBUcnVzdEZhY3RvcnkgRGlnaXRhbCBJ RCBTZXJ2aWNlczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA7gWKqAf0MfIp/QL9wMe3 mzEt/+DYSUs6VqkgXehMSbLblwPV7v+QhzhH/JSUoQKVi85qQom7+tnXBJxylB4mfl4AsqyG SE4IGZPnVcxI4rzW5vhrNVCSzeAkqe2PnoPpZrlh8IYYYKINeGzmZ5QMWEmnDp8+M13zzAUD A/11ZFMCAwEAAaOCATkwggE1MB8GA1UdIwQYMBaAFLNK4JQgbBz8WKb6QycGs8Hxz6SyMB0G A1UdDgQWBBR43QkpxguDM6Uc3wFLHlNH8iD1SzAOBgNVHQ8BAf8EBAMCAfYwDwYDVR0TAQH/ BAUwAwEB/zCB0QYJYIZIAYb4QgENBIHDFoHAQ0FVVElPTjogVGhlIERpZ2l0YWwgSUQgc3Vi amVjdHMgb2YgSUNFLVRFTApDbGFzcyAwIFRyaWFsIFNlcnZpY2VzIGFyZSBub3QgYXV0aGVu dGljYXRlZC4KSXQgbWF5IGJlIHRoZSBob2xkZXIncyByZWFsIG5hbWUgb3IgYW4gYWxpYXMu ClVzZSB0aGlzIERpZ2l0YWwgSUQgZm9yIHRlc3QgcHVycG9zZWQgb25seS4KKGMpIEdNRCAx OTk3MA0GCSqGSIb3DQEBBAUAA4GBAK+hyS6CuuCt2kH7FlvTgpYf39q4sji5JytL3KCExfLe b4H+YPNbO7cy08KTGa9qSQyodh5+KwXFH9lUct5//bFkm4WfKHH7O2u4+rjWGfGZV6VB1ZCD dX5CdvVu8O3qNPoQThw60WowKJIS8FkW5BKLP7SB4VJetNrKMz9zwWnJMIIDQTCCAqqgAwIB AgIBADANBgkqhkiG9w0BAQQFADBIMQ8wDQYDVQQHEwZFdXJvcGUxEDAOBgNVBAoTB0lDRS1U RUwxIzAhBgNVBAsTGkNMQVNTIDAgVFJJQUwgU0VSVklDRVMgUEtJMB4XDTk3MTIxNzA3NTg0 NVoXDTAwMDEwMTAwMDAwMFowSDEPMA0GA1UEBxMGRXVyb3BlMRAwDgYDVQQKEwdJQ0UtVEVM MSMwIQYDVQQLExpDTEFTUyAwIFRSSUFMIFNFUlZJQ0VTIFBLSTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEA9jNYTNZLLl7MxMhg1dSc0wq+PiSq4LkPwDL9J+dQk1EJdLWaopkd/NNR uM37r03RVbSHeI0FPQoylnJpu0Kj6KNWxVwIeGeWGrIdhRShUSh3n2bFSD/0T5uHWvsN1U9f d6uxDaYHcnfLLCtTi76Piu2GCJK4eH3W76Oo3Ei4VoMCAwEAAaOCATkwggE1MB8GA1UdIwQY MBaAFLNK4JQgbBz8WKb6QycGs8Hxz6SyMB0GA1UdDgQWBBSzSuCUIGwc/Fim+kMnBrPB8c+k sjAOBgNVHQ8BAf8EBAMCAfYwDwYDVR0TAQH/BAUwAwEB/zCB0QYJYIZIAYb4QgENBIHDFoHA Q0FVVElPTjogVGhlIERpZ2l0YWwgSUQgc3ViamVjdHMgb2YgSUNFLVRFTApDbGFzcyAwIFRy aWFsIFNlcnZpY2VzIGFyZSBub3QgYXV0aGVudGljYXRlZC4KSXQgbWF5IGJlIHRoZSBob2xk ZXIncyByZWFsIG5hbWUgb3IgYW4gYWxpYXMuClVzZSB0aGlzIERpZ2l0YWwgSUQgZm9yIHRl c3QgcHVycG9zZWQgb25seS4KKGMpIEdNRCAxOTk3MA0GCSqGSIb3DQEBBAUAA4GBALkKsGZG E5ckTCE0F7hTF2eZgnDZYgm709UJeozPRB/3KjuyjdxlbVj2eiCWVB9HpH0KK2kEqnhgiHWL xwQGuycFD7Px7SDIwjEC/7c9YERIw1GmGWe2g6EatOP3oS/4tCy72TODDhD5WeYAMFcpKihR Skp0N+zOhEuDvxyXGauuMYIBYDCCAVwCAQEwfDB2MQswCQYDVQQGEwJERTEMMAoGA1UEChMD R01EMR8wHQYDVQQLExZDTEFTUyAwIFRSSUFMIFNFUlZJQ0VTMTgwNgYDVQQLEy9UcnVzdEZh Y3RvcnkgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENlcnRpZmljYXRlcwICAvMwCQYFKw4DAhoF AKB9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MDkyMjA5 MjY0OVowHgYJKoZIhvcNAQkPMREwDzANBggqhkiG9w0DAgIBKDAjBgkqhkiG9w0BCQQxFgQU Ypl1kQvQEkbLfHbDhyuczu2HatYwDQYJKoZIhvcNAQEBBQAEQCWTOZQScCOMbV6jt7j/IN+M XcHMcvD2wgOSKEb1Sqr48Aof6oFV3oeBQseB8SJqpl93ZiCRYZBl+1T3SVMCdZc= --------------ms6C21A3596B2679A5F64C275F-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA03834 for ietf-pkix-bks; Mon, 21 Sep 1998 21:22:03 -0700 (PDT) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA03830 for <ietf-pkix@imc.org>; Mon, 21 Sep 1998 21:22:01 -0700 (PDT) Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id GAA05716; Tue, 22 Sep 1998 06:28:20 +0200 (CEST) Received: from stefans (t2o68p111.telia.com [62.20.138.231]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id GAA27141; Tue, 22 Sep 1998 06:28:18 +0200 (CEST) Message-Id: <3.0.32.19980922062458.00a7e6f0@m1.403.telia.com> X-Sender: u40400192@m1.403.telia.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 22 Sep 1998 06:25:35 +0200 To: Al Arsenault <aarsenault@spyrus.com>, Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, "Arsenault, Al W." <awarsen@missi.ncsc.mil> From: Stefan Santesson <stefan@accurata.se> Subject: Re: PKIX Roadmap Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id VAA03831 Sender: owner-ietf-pkix@imc.org Precedence: bulk Al, Just a short reply to CA disaster (See below). Thanks for your reply, I still disagree to the disaster part. CA2 does not have to be dismanteled, since CA 2:s key is intact. What has to be done is that: - CA1 is rebuilt with new key - The compromise of CA1 and its new key has to be communicated with out-of-band means - CA1 cross certify CA2 (and other CA:s) using the new key - New cross certificates to CA1 has to be issued and published by other CA:s. Now all certificates issued by CA2 before the disaster of CA1 can be used and trusted. This since the disaster of CA1 didn't destroy CA2, just the link to CA2 from CA1. /Stefan At 01:32 PM 9/21/98 -0400, Al Arsenault wrote: >Stefan, > > Thanks for your comments. Responses in line (Sean can make changes to the >draft as appropriate). > > >At 04:19 PM 9/21/98 +0200, Stefan Santesson wrote: >>Al, >> >>I finally got time to look a little bit deeper into the roadmap document. >>I think it is very well formed but I have some minor disagreements. >> >>1) Concerning definition and use of the term Root CA >>2) Result from CA compromise >>3) Use of certificates. >> >>1 - Root CA >>--------- >>Definition and use of the term Root CA in sections 2, 3.4.5 and 5.1.2 gives >>the impression that Root CA is at the top of some hierarchy. >> >>This does not seem to harmonize with the definition of root CA in >>"Certificate Management Protocols" >> >> "We use the term "root CA" to indicate a CA that is directly trusted by >> an end entity; that is, securely acquiring the value of a root CA public >> key requires some out-of-band step(s). This term is not meant to imply >> that a root CA is necessarily at the top of any hierarchy, simply that >> the CA in question is trusted directly." >> >>So in fact every CA in a domain is likely to be "root" for some of its >>subscribers. >>I personally prefer the rem "Top CA" when describing a hierarchy. >> > >You are correct; I was using the term "rootCA" to indicate the top of a >hierarchy (possibly, a hierarchy of depth one - two counting the end >entity). That is inconsistent with CMP. We'll have to resolve that. I >personally prefer using the term "rootCA" to mean the top of a hierarchy, >and "trust anchor" to mean the CA that the end-entity directly trusts. But >we'll figure out something - "topCA" is probably feasible for now. > > >> >>2 - CA compromise >>------------------ >>In section 3.4.5 it is said that compromise of a root CA is always >>catastrophic and that the entire infrastructure subordinate to that root CA >>has to be dismantled and started over again. This gives the impression that >>a subordinate CA has to be dismatled. >> >>My comment is that >>a) Since the rootCA does not denote any hierarchy we can't define which CA >>that is subordinate or not to a specific root CA >>b) A compromised CA does only require that particular CA to be dismantled. >>No other non-compromised CA has to be dismantled. Other CA:s has to revoke >>cross certificates to th compromised CA and all subscribers using the >>compromised CA as root CA, are totally cut off until they get another >>rootCA key, but that's another aspect. >> > >Your comment (a) is correct, given the different meaning of "rootCA" that I >didn't catch earlier. However, I disagree with part of your comment (b). >That to me goes to the heart of a "CA Certificate" vs. a >"Cross-certificate". > >Suppose that CA2 has no self-signed certificates (it might have a >self-issued certificate for key management, but that's not relevant at this >point). CA2's CA certificate is issued and signed by CA1. Thus, CA2 is >subordinate to CA1. Now, if CA1's private key is compromised, then CA2 >must be "dismantled". That is, there is no reliable way for an outside >entity to know whether CA2's cert was legitimately issued prior to the >compromise of CA1's key, or whether CA2's cert was signed by the malicious >party now holding the copy of CA1's private key. The only thing you can do >is kill CA2 and start over with a new cert issued by the new, re-installed >CA1. (Not to mention the mechanical problem of constructing a valid cert >path going through CA2 to the valid CA1:-). Of course, "dismantling" is a >strong word; you'd have to rebuild CA1 with a new key, and sign a new >certificate for CA2 using the new, un-compromised key. You wouldn't >necessarily need to erase CA2's database, train new people, buy a new >hardware platform, etc. :-) > >With a cross-certificate, as you point out, there's no need to do anything >over than revoke the cross-cert CA2 has issued for CA1 (if there is one). > > >>3 - Certificate usage >>--------------------- >>Section 3.1 states that: >>"Certificates is used in the process of validating signed data." >>This definition is leaving out any use for the purpose of encryption. I.e. >>data encryption, key agreement and key exchange. >> > >Agreed. > > > Al Arsenault > >- the above opinions are my own. They may or may not reflect the opinions >of my employer or of any other organization with which I have a relationship. > > > > > ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29811 for ietf-pkix-bks; Mon, 21 Sep 1998 10:30:40 -0700 (PDT) Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29807 for <ietf-pkix@imc.org>; Mon, 21 Sep 1998 10:30:39 -0700 (PDT) Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA06046; Mon, 21 Sep 1998 10:35:08 -0700 (PDT) Message-Id: <3.0.6.32.19980921133257.009044e0@mail.spyrus.com> X-Sender: aarsenault@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 21 Sep 1998 13:32:57 -0400 To: Stefan Santesson <stefan@accurata.se>, Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, "Arsenault, Al W." <awarsen@missi.ncsc.mil> From: Al Arsenault <aarsenault@spyrus.com> Subject: Re: PKIX Roadmap In-Reply-To: <3.0.32.19980921161854.00a71640@m1.403.telia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk Stefan, Thanks for your comments. Responses in line (Sean can make changes to the draft as appropriate). At 04:19 PM 9/21/98 +0200, Stefan Santesson wrote: >Al, > >I finally got time to look a little bit deeper into the roadmap document. >I think it is very well formed but I have some minor disagreements. > >1) Concerning definition and use of the term Root CA >2) Result from CA compromise >3) Use of certificates. > >1 - Root CA >--------- >Definition and use of the term Root CA in sections 2, 3.4.5 and 5.1.2 gives >the impression that Root CA is at the top of some hierarchy. > >This does not seem to harmonize with the definition of root CA in >"Certificate Management Protocols" > > "We use the term "root CA" to indicate a CA that is directly trusted by > an end entity; that is, securely acquiring the value of a root CA public > key requires some out-of-band step(s). This term is not meant to imply > that a root CA is necessarily at the top of any hierarchy, simply that > the CA in question is trusted directly." > >So in fact every CA in a domain is likely to be "root" for some of its >subscribers. >I personally prefer the rem "Top CA" when describing a hierarchy. > You are correct; I was using the term "rootCA" to indicate the top of a hierarchy (possibly, a hierarchy of depth one - two counting the end entity). That is inconsistent with CMP. We'll have to resolve that. I personally prefer using the term "rootCA" to mean the top of a hierarchy, and "trust anchor" to mean the CA that the end-entity directly trusts. But we'll figure out something - "topCA" is probably feasible for now. > >2 - CA compromise >------------------ >In section 3.4.5 it is said that compromise of a root CA is always >catastrophic and that the entire infrastructure subordinate to that root CA >has to be dismantled and started over again. This gives the impression that >a subordinate CA has to be dismatled. > >My comment is that >a) Since the rootCA does not denote any hierarchy we can't define which CA >that is subordinate or not to a specific root CA >b) A compromised CA does only require that particular CA to be dismantled. >No other non-compromised CA has to be dismantled. Other CA:s has to revoke >cross certificates to th compromised CA and all subscribers using the >compromised CA as root CA, are totally cut off until they get another >rootCA key, but that's another aspect. > Your comment (a) is correct, given the different meaning of "rootCA" that I didn't catch earlier. However, I disagree with part of your comment (b). That to me goes to the heart of a "CA Certificate" vs. a "Cross-certificate". Suppose that CA2 has no self-signed certificates (it might have a self-issued certificate for key management, but that's not relevant at this point). CA2's CA certificate is issued and signed by CA1. Thus, CA2 is subordinate to CA1. Now, if CA1's private key is compromised, then CA2 must be "dismantled". That is, there is no reliable way for an outside entity to know whether CA2's cert was legitimately issued prior to the compromise of CA1's key, or whether CA2's cert was signed by the malicious party now holding the copy of CA1's private key. The only thing you can do is kill CA2 and start over with a new cert issued by the new, re-installed CA1. (Not to mention the mechanical problem of constructing a valid cert path going through CA2 to the valid CA1:-). Of course, "dismantling" is a strong word; you'd have to rebuild CA1 with a new key, and sign a new certificate for CA2 using the new, un-compromised key. You wouldn't necessarily need to erase CA2's database, train new people, buy a new hardware platform, etc. :-) With a cross-certificate, as you point out, there's no need to do anything over than revoke the cross-cert CA2 has issued for CA1 (if there is one). >3 - Certificate usage >--------------------- >Section 3.1 states that: >"Certificates is used in the process of validating signed data." >This definition is leaving out any use for the purpose of encryption. I.e. >data encryption, key agreement and key exchange. > Agreed. Al Arsenault - the above opinions are my own. They may or may not reflect the opinions of my employer or of any other organization with which I have a relationship. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29336 for ietf-pkix-bks; Mon, 21 Sep 1998 09:17:24 -0700 (PDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29332 for <ietf-pkix@imc.org>; Mon, 21 Sep 1998 09:17:22 -0700 (PDT) Received: from [128.33.238.151] (TC151.BBN.COM [128.33.238.151]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA05250 for <ietf-pkix@imc.org>; Mon, 21 Sep 1998 12:23:14 -0400 (EDT) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="============_-1305727475==_ma============" X-Sender: kent@po1.bbn.com Message-Id: <v04011701b22c2cbc4e8e@[128.33.238.151]> Date: Mon, 21 Sep 1998 12:20:00 -0400 To: ietf-pkix@imc.org From: Stephen Kent <kent@bbn.com> Subject: meeting minutes Sender: owner-ietf-pkix@imc.org Precedence: bulk --============_-1305727475==_ma============ Content-Type: text/plain; charset="us-ascii" Folks, I apologize for not having mailed these sooner, for review. They were done by Friday, of IETF week, but then got lost in an avalanche of travel and e-mail. Please review and respond to me with corrections by the end of this week. Thanks, Steve ----------------------- PKIX WG Meeting Minutes 8/26-27/98 The PKIX WG met twice during the 42nd IETF and a approximately 190 individuals participated in these meetings. The meeting began with a review of the status of all of the WG document, presented by Warwick Ford, WG co-chair. The following text summarizes the status of the documents: PKIX Certificate/CRL Profile (draft-ietf-pkix-ipki-part1-09.txt) - IESG Last Call KEA Algorithm Profile (draft-ietf-pkix-ipki-kea-02.txt) - Close to completion by Editors HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) - Ready for WG last call LDAP V2 Profile (March 98 draft)- At IESG, pending WG delivery of V2 Schema LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt) - In WG last call OCSP (draft-ietf-pkix-ocsp-05.txt) - In WG last call CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF (draft-ietf-pkix-crmf-01.txt) - In hands of IESG; pending IESG last call CMMF (draft-ietf-pkix-cmmf-02.txt) and CMC (draft-ietf-pkix-cmc-01.txt) - In WG last call Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt) - In SA Director's hands, pending publication as Informational RFC REVIEWS OF ESTABLISHED PROJECTS: - PKIX Certificate and CRL Profile (Tim Polk) Ready for IESG ballot, after receipt of minor editorial comments during IETF last call. Straw polls used to resolve last few contentious issues, specifically mandating use of DNs for all Issuers, and mandating use of strict subtrees for the NameConstraints extension. Jeff Schiller noted that the IETF web site has pointers to the Entrust license required for inclusion of CRL distribution point within this document. The license is easy to execute; there is a reciprocity clause that requires licensing to Entrust any intellectual property associated with CRL distribution, as a side effect of - KEA and ECDS Algorithms (Tim Polk) Work on these algorithm IDs continues, subject to resolution of some intellectual property issues. - LDAP V2 Schema and Profile (Tim Moses, Dave Horvath, Santosh Chokhani) Most of the schema are not controversial; outstanding issues is whether all CA certificates should appear in the cross certificate directory attribute, or whether certificates that are internal to a domain should appear in the CA certificate attribute. There is consensus that any self-signed CA certificates belong in the latter attribute. The disagreement here revolves around alternative certificate validation algorithms; both approaches have been implemented and both work, each favoring a different PKI model. The CA certificate attribute has been a feature of X.509 for a long while, so the proposal to move all (non- self-signed) CA certificates to the cross CA certificate attribute represents a non-backward compatible change for systems not making use of cross certificates. Still, this is the direction currently being pursued by the X.509 committee in resolving this ambiguity in the original standard. Performance analysis of 6 different approaches, under varying assumptions of PKI models, shows that putting all (non-self signed) CA certificates in the cross certificate attribute results in worse performance. We can make a decision now to get this long overdue schema out, or postpone and discuss more (since this is a newly discovered issue). (Although this discussion is taking place in the context of LDAP v2, the same issue arises in LDAP v3. However, v3 has better filtering capabilities and this it is believed that the issue would be less of a concern, but this is not universally agreed upon.) Work on LDAP v3 is progressing in the IETF, and so if we postpone action on this ID, it may be OBE and we will need to focus on v3 instead. Proposed compromise approach is to duplicate intra-domain CA certificates in both attributes (#4 in Santosh's analysis posted to the WG list), and which has very good overall performance. One objection raised to this is that it can result in added data sent back if one retrieves both attribute contents. Straw poll conducted resulted on no clear winner, but the two finalists are the proposed compromise and the older, backward compatible approach; the WG rejected the proposal from the current LDAP schema. - OCSP (Tim Myers and Ambrish Malpani) Various minor, but technically important, edits to many parts of the document, in response to comments from the WG list. Changes included a uniform key identifier, optional use of TLS/SSL for privacy protection of exchanges, etc. An objection was raised to mandating use of a signature, when a lower layer protocol might be used to provide security. A straw poll overwhelmingly supported the mandatory use of signatures of in OCSP. Thus there appears to be no outstanding significant technical issues at this time. A separate OCSP response extensions document will be created to define additional responses - CMP and CRMF In IESG last call. No further status to report. - CMMF and CMC (Mike Myers) The CMMF draft has completed WG last call, minor changes have been made in response to comments received during last call, it and will be forwarded to the IESG. CMC also has completed WG last call, and undergone changes in response to comments received during that process. Pending approval of secure initialization issues briefed at this meeting, the document will be forwarded to the IESG. The secure initialization requirements for CMC include use of a shared secret in a keyed hash calculation, with this secret distributed via a confidentiality-secure channel. However, objections were raised to defining this as the only way to achieve secure initialization, e.g., as opposed to use of SecurID cards or S-KEY authentication in the context of an integrity and confidentiality secure channel. It seems likely that additional mechanisms should be allowed, but there is a desire to avoid an explosion of allowed user authentication techniques, which would hinder interoperability or greatly burden CA software. This issue will be brought to the list for resolution. - IBM PKIX Software Distribution (Charlie Kaufman) IBM is implementing PKIX technology and making it available for use in products, as well as in R&D environments. Code is a mix of C++ software plus Java GUIs. Provided facilities include CMP, CRMF, LDAP, basic CA and RA functions, and client certificate processing. No crypto is included in the distribution; the software makes calls to a CAPI. The first release relies on the Cylink cyrpto toolkit, which also will be available via this web site; later version will also make use of BSAFE. Initial distribution is via an MIT web site and is not exportable. A pointer for a mailing list was provided: imc-pfi@imc.org. NEW TOPICS: - Timestamp & Notary proposals (Carlisle Adams) Several folks continuing work on these topics and have published an independent draft on these topics. The authors received a fair amount of private feedback, and hope to be able to bring forward a well-formed proposal. Jeff Schiller gave his permission to bring this into the WG, based on the WG having made substantial progress on the other work items. Thus we will expand the charter to encompass these topics. - Web-based Integrated CA services Protocol (Mine Sakurai) This presentation describes use of HTTP as an underlying communication protocol among CAs, RAs, etc. The underlying model also defines issuing, validation, and publishing authority modules within the CA. ICAP has been implemented for use with S/MIME in a medical information system in Japan. An I-D has been published describing ICAP: draft-ietf-????. It was noted that the acronym "ICAP" is already in use by a calendar protocol, so another protocol acronym would be appropriate. - Enhanced CRL Distribution Options (Phillip Hallam-Baker & Warwick Ford) There is an I-D describing alternatives CRL distribution technique, which was developed in response to the intellectual property problem that temporarily prevented use of the CRL distribution point mechanism. The CRL format can be extended to specify the scope of the CRL, e.g., by serial number range, as an alternative to placing the pointer in the certificate. To address the CRL location aspect of CRL distribution points, one also can establish CRL managers that are either locally trusted or that represent a separate CRL distribution channel, perhaps serving multiple CAs. By adding two new CRL extensions, one can extend the CRL distribution model in interesting new ways. These suggestions are being forwarded to ISO for consideration. See the latest I-D, under the PKIX, for more details. - PKIX Roadmap (Al Arsenault) The set of PKIX documents has become rather large and potentially confusing. An outline was presented as a basis for a document that would become an informational RFC, to help explain the relationships among these documents, and to other efforts, e.g., SPKI. An initial draft is ready and will be made available immediately after this IETF meeting. - Qualified Certificates (Stefan Santesson) In EC a legal framework for "qualified certificates" is being developed, referring to individual certificates that will be accepted for legally binding, international transactions, and with legal liability implications for the CAs issuing such certificates. (These certificates are used only for non-repudiation.) It is analogous to some of the work under UNICTRAL for EDI. For PKIX, the potential work item would be a profile for such certificates, specifying which extensions are mandatory and optional, establishing values and semantics for some of the extensions. For example, one might mandate use of the policy extension with a specific value to identify such certificates, with policy qualifiers to express additional characteristics of policy variants, appropriate key usage flags, naming schema constraints, etc. --============_-1305727475==_ma============ Content-Type: text/enriched; charset="us-ascii" Folks, I apologize for not having mailed these sooner, for review. They were done by Friday, of IETF week, but then got lost in an avalanche of travel and e-mail. Please review and respond to me with corrections by the end of this week. Thanks, Steve ----------------------- <fontfamily><param>Times</param><bigger><bigger>PKIX WG Meeting Minutes 8/26-27/98 The PKIX WG met twice during the 42nd IETF and a approximately 190 individuals participated in these meetings. The meeting began with a review of the status of all of the WG document, presented by Warwick Ford, WG co-chair. The following text summarizes the status of the documents: PKIX Certificate/CRL Profile (draft-ietf-pkix-ipki-part1-09.txt) - IESG Last Call KEA Algorithm Profile (draft-ietf-pkix-ipki-kea-02.txt) - Close to completion by Editors HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) - Ready for WG last call LDAP V2 Profile (March 98 draft)- At IESG, pending WG delivery of V2 Schema LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt) - In WG last call OCSP (draft-ietf-pkix-ocsp-05.txt) - In WG last call CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF (draft-ietf-pkix-crmf-01.txt) - In hands of IESG; pending IESG last call CMMF (draft-ietf-pkix-cmmf-02.txt) and CMC (draft-ietf-pkix-cmc-01.txt) - In WG last call Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt) - In SA Director's hands, pending publication as Informational RFC REVIEWS OF ESTABLISHED PROJECTS: - PKIX Certificate and CRL Profile (Tim Polk) Ready for IESG ballot, after receipt of minor editorial comments during IETF last call. Straw polls used to resolve last few contentious issues, specifically mandating use of DNs for all Issuers, and mandating use of strict subtrees for the NameConstraints extension. Jeff Schiller noted that the IETF web site has pointers to the Entrust license required for inclusion of CRL distribution point within this document. The license is easy to execute; there is a reciprocity clause that requires licensing to Entrust any intellectual property associated with CRL distribution, as a side effect of - KEA and ECDS Algorithms (Tim Polk) Work on these algorithm IDs continues, subject to resolution of some intellectual property issues. - LDAP V2 Schema and Profile (Tim Moses, Dave Horvath, Santosh Chokhani) Most of the schema are not controversial; outstanding issues is whether all CA certificates should appear in the cross certificate directory attribute, or whether certificates that are internal to a domain should appear in the CA certificate attribute. There is consensus that any self-signed CA certificates belong in the latter attribute. The disagreement here revolves around alternative certificate validation algorithms; both approaches have been implemented and both work, each favoring a different PKI model. The CA certificate attribute has been a feature of X.509 for a long while, so the proposal to move all (non- self-signed) CA certificates to the cross CA certificate attribute represents a non-backward compatible change for systems not making use of cross certificates. Still, this is the direction currently being pursued by the X.509 committee in resolving this ambiguity in the original standard. Performance analysis of 6 different approaches, under varying assumptions of PKI models, shows that putting all (non-self signed) CA certificates in the cross certificate attribute results in worse performance. We can make a decision now to get this long overdue schema out, or postpone and discuss more (since this is a newly discovered issue). (Although this discussion is taking place in the context of LDAP v2, the same issue arises in LDAP v3. However, v3 has better filtering capabilities and this it is believed that the issue would be less of a concern, but this is not universally agreed upon.) Work on LDAP v3 is progressing in the IETF, and so if we postpone action on this ID, it may be OBE and we will need to focus on v3 instead. Proposed compromise approach is to duplicate intra-domain CA certificates in both attributes (#4 in Santosh's analysis posted to the WG list), and which has very good overall performance. One objection raised to this is that it can result in added data sent back if one retrieves both attribute contents. Straw poll conducted resulted on no clear winner, but the two finalists are the proposed compromise and the older, backward compatible approach; the WG rejected the proposal from the current LDAP schema. - OCSP (Tim Myers and Ambrish Malpani) Various minor, but technically important, edits to many parts of the document, in response to comments from the WG list. Changes included a uniform key identifier, optional use of TLS/SSL for privacy protection of exchanges, etc. An objection was raised to mandating use of a signature, when a lower layer protocol might be used to provide security. A straw poll overwhelmingly supported the mandatory use of signatures of in OCSP. Thus there appears to be no outstanding significant technical issues at this time. A separate OCSP response extensions document will be created to define additional responses - CMP and CRMF In IESG last call. No further status to report. - CMMF and CMC (Mike Myers) The CMMF draft has completed WG last call, minor changes have been made in response to comments received during last call, it and will be forwarded to the IESG. CMC also has completed WG last call, and undergone changes in response to comments received during that process. Pending approval of secure initialization issues briefed at this meeting, the document will be forwarded to the IESG. The secure initialization requirements for CMC include use of a shared secret in a keyed hash calculation, with this secret distributed via a confidentiality-secure channel. However, objections were raised to defining this as the only way to achieve secure initialization, e.g., as opposed to use of SecurID cards or S-KEY authentication in the context of an integrity and confidentiality secure channel. It seems likely that additional mechanisms should be allowed, but there is a desire to avoid an explosion of allowed user authentication techniques, which would hinder interoperability or greatly burden CA software. This issue will be brought to the list for resolution. - IBM PKIX Software Distribution (Charlie Kaufman) IBM is implementing PKIX technology and making it available for use in products, as well as in R&D environments. Code is a mix of C++ software plus Java GUIs. Provided facilities include CMP, CRMF, LDAP, basic CA and RA functions, and client certificate processing. No crypto is included in the distribution; the software makes calls to a CAPI. The first release relies on the Cylink cyrpto toolkit, which also will be available via this web site; later version will also make use of BSAFE. Initial distribution is via an MIT web site and is not exportable. A pointer for a mailing list was provided: imc-pfi@imc.org. NEW TOPICS: - Timestamp & Notary proposals (Carlisle Adams) Several folks continuing work on these topics and have published an independent draft on these topics. The authors received a fair amount of private feedback, and hope to be able to bring forward a well-formed proposal. Jeff Schiller gave his permission to bring this into the WG, based on the WG having made substantial progress on the other work items. Thus we will expand the charter to encompass these topics. - Web-based Integrated CA services Protocol (Mine Sakurai) This presentation describes use of HTTP as an underlying communication protocol among CAs, RAs, etc. The underlying model also defines issuing, validation, and publishing authority modules within the CA. ICAP has been implemented for use with S/MIME in a medical information system in Japan. An I-D has been published describing ICAP: draft-ietf-????. It was noted that the acronym "ICAP" is already in use by a calendar protocol, so another protocol acronym would be appropriate. - Enhanced CRL Distribution Options (Phillip Hallam-Baker & Warwick Ford) There is an I-D describing alternatives CRL distribution technique, which was developed in response to the intellectual property problem that temporarily prevented use of the CRL distribution point mechanism. The CRL format can be extended to specify the scope of the CRL, e.g., by serial number range, as an alternative to placing the pointer in the certificate. To address the CRL location aspect of CRL distribution points, one also can establish CRL managers that are either locally trusted or that represent a separate CRL distribution channel, perhaps serving multiple CAs. By adding two new CRL extensions, one can extend the CRL distribution model in interesting new ways. These suggestions are being forwarded to ISO for consideration. See the latest I-D, under the PKIX, for more details. - PKIX Roadmap (Al Arsenault) The set of PKIX documents has become rather large and potentially confusing. An outline was presented as a basis for a document that would become an informational RFC, to help explain the relationships among these documents, and to other efforts, e.g., SPKI. An initial draft is ready and will be made available immediately after this IETF meeting. - Qualified Certificates (Stefan Santesson) In EC a legal framework for "qualified certificates" is being developed, referring to individual certificates that will be accepted for legally binding, international transactions, and with legal liability implications for the CAs issuing such certificates. (These certificates are used only for non-repudiation.) It is analogous to some of the work under UNICTRAL for EDI. For PKIX, the potential work item would be a profile for such certificates, specifying which extensions are mandatory and optional, establishing values and semantics for some of the extensions. For example, one might mandate use of the policy extension with a specific value to identify such certificates, with policy qualifiers to express additional characteristics of policy variants, appropriate key usage flags, naming schema constraints, etc. </bigger></bigger></fontfamily> --============_-1305727475==_ma============-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28710 for ietf-pkix-bks; Mon, 21 Sep 1998 07:34:25 -0700 (PDT) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28706 for <ietf-pkix@imc.org>; Mon, 21 Sep 1998 07:34:21 -0700 (PDT) Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id QAA11344; Mon, 21 Sep 1998 16:40:31 +0200 (CEST) Received: from stefans (t4o68p96.telia.com [62.20.139.216]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id QAA06265; Mon, 21 Sep 1998 16:22:11 +0200 (CEST) Message-Id: <3.0.32.19980921161854.00a71640@m1.403.telia.com> X-Sender: u40400192@m1.403.telia.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 21 Sep 1998 16:19:49 +0200 To: Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, "Arsenault, Al W." <awarsen@missi.ncsc.mil> From: Stefan Santesson <stefan@accurata.se> Subject: Re: PKIX Roadmap Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA28707 Sender: owner-ietf-pkix@imc.org Precedence: bulk Al, I finally got time to look a little bit deeper into the roadmap document. I think it is very well formed but I have some minor disagreements. 1) Concerning definition and use of the term Root CA 2) Result from CA compromise 3) Use of certificates. 1 - Root CA --------- Definition and use of the term Root CA in sections 2, 3.4.5 and 5.1.2 gives the impression that Root CA is at the top of some hierarchy. This does not seem to harmonize with the definition of root CA in "Certificate Management Protocols" "We use the term "root CA" to indicate a CA that is directly trusted by an end entity; that is, securely acquiring the value of a root CA public key requires some out-of-band step(s). This term is not meant to imply that a root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly." So in fact every CA in a domain is likely to be "root" for some of its subscribers. I personally prefer the rem "Top CA" when describing a hierarchy. 2 - CA compromise ------------------ In section 3.4.5 it is said that compromise of a root CA is always catastrophic and that the entire infrastructure subordinate to that root CA has to be dismantled and started over again. This gives the impression that a subordinate CA has to be dismatled. My comment is that a) Since the rootCA does not denote any hierarchy we can't define which CA that is subordinate or not to a specific root CA b) A compromised CA does only require that particular CA to be dismantled. No other non-compromised CA has to be dismantled. Other CA:s has to revoke cross certificates to th compromised CA and all subscribers using the compromised CA as root CA, are totally cut off until they get another rootCA key, but that's another aspect. 3 - Certificate usage --------------------- Section 3.1 states that: "Certificates is used in the process of validating signed data." This definition is leaving out any use for the purpose of encryption. I.e. data encryption, key agreement and key exchange. Regards /Stefan ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA22403 for ietf-pkix-bks; Mon, 21 Sep 1998 00:38:25 -0700 (PDT) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA22390 for <ietf-pkix@imc.org>; Mon, 21 Sep 1998 00:36:58 -0700 (PDT) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id JAA17478; Mon, 21 Sep 1998 09:18:26 +0200 Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA16740; Mon, 21 Sep 1998 09:18:25 +0200 (DFT) Message-ID: <36067C64.DE008EBB@bull.net> Date: Mon, 21 Sep 1998 09:18:44 -0700 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.03 [fr] (Win16; I) MIME-Version: 1.0 To: Anders Rundgren <anders.rundgren@jaybis.com> CC: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: Re: OCSP - Public Key Dstribution References: <01BDE484.F1DA1820@HYDRA> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Anders Rundgren a écrit: > Salut Denis, This sounds a little bit familiar to me. :-( Please do not mix French and English. > Pardon my ignorance but does a returned issuerKeyHash give you the > possibility to verify a certificate signature *after* its status has been checked? Yes. > Don't you need the original (unhashed) issuer public key to to that? You can get it after the OCSP request. > I.e. does this enhanced OCSP draft essentially support my suggested OCSP++ > (previously I called it OCVP) system *without* requiring extensions? That would be > just fantastic! I took a look at the URL address you are providing. Since the description is pretty short, it is hard to answer your question. However the text says "an easy-to-use system for checking status and validity of a certificate." In this version of OCSP, there is no intent for checking the validity of the certificate but only its revocation/on-hold status. Checking the status would be far more complicated and controversial. Denis > http://www.jaybis.com/specifications/pkix/ocsp.html > > Please enlighten me! > > Regards > Anders Rundgren > > ---------- > From: Denis Pinkas [SMTP:Denis.Pinkas@bull.net] > Sent: Saturday, September 19, 1998 02:15 > To: Andreas Berger > Cc: Peter Sylvester; ambarish@valicert.com; ietf-pkix@imc.org > Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt > > Andreas, > > I share your concerns. > > The current definition of CertId is as follows: > > CertID ::= SEQUENCE { > hashAlgorithm AlgorithmIdentifier, > issuerNameHash OCTET STRING, -- Hash of Issuer's DN > issuerKeyHash OCTET STRING, -- Hash of Issuers public > key > serialNumber CertificateSerialNumber } > > CertID is used both in the request and in the response. > I would suggest to change it to: > > CertID ::= SEQUENCE { > hashAlgorithm AlgorithmIdentifier, > issuerNameHash OCTET STRING, -- Hash of Issuer's DN > issuerKeyHash OCTET STRING OPTIONAL, -- Hash of > Issuers public key > serialNumber CertificateSerialNumber } > > making the issuerKeyHash optional. > > The issuerKeyHash would be optional for a request but mandatory for > a response. The rational is as follows: the requester needs "at > some time" to get the public key of the issuer in order to verify > the certificate. If we mandate that field to be always present > thent it must get it *before* the request to the OCSP server. If we > make it optional, then it may get it before or after the request to > the OCSP server. This gives some flexibility, without too many > options. > > The OCSP server should anyway have the Issuers public key and thus > its hash. The hash may allow the requester to disambigous some > responses in case of anonymity. > > Denis > > > I agree with this discussion and would like to add some thoughts: > > > > Peter Sylvester wrote: > > > > I actually think OCVP is a bigger thing than just making the hash > > > > of the issuer's PUBLIC key NULL. That whole topic should be > > > > addressed at one shot > > > > > > > I am *not* really talking about OCVP, I am talking about 'CertID', > > > a short way to identify a certificate. The syntax > > > for the identification should be flexible enough > > > > > > - not to require more than the original certificate in > > > order to construct the identification. > > The is a very good assumption. While the authority key *may* be > > available, it certainly isn´t always available. > > > > > - to allow identification of a certificate in a given context > > > ==> serial number for example or/and hash of cert > > The serial number is a little bit weaker but supported by other parts of > > X.509, PKIX and several mail protocols, using issuer/serial for > > identification of a certificate. So issuer/serial or > > issuer/certificate-hash look like valid combinations. It may be a good > > idea to be able add a subject public key hash if necessary. > > > > > - to allow the OCSP provider to find the source of > > > information provider. > > > ==> name of issuer may be necessary, hash of issuer name > > > may not be sufficient. > > So for identification of issuer we probably have a choice of issuer-name > > or issuer-hash, probably in combination with issuer-public-key or > > issuer-public-key-hash as an optional parameter. > > > > > - to ensure that the creator of the certificate really has > > > a copy of a cert. > > > ==> hash of cert for example, or serialnumber if authority > > > allocates them in a sparse way. > > > If we assume that the orginal version of OCSP where it was > > > possible to just have a cert did make sense, thus I do not > > > see why there is a need for the issuer public key extract > > > in the certID. At least it should be optional in some way. > > > > > > It seems useful to me to fix a syntax for CertID that > > > is sufficiently open for extensions without requiring > > > a new protocol version.. > > > > The removal of the certificate proper as a means to "identify" a > > certificate forced us to specify an extension to OCSP to do this > > (transport the certificate in the request - optional, or in the reply - > > optional). If the consensus is that OCSP should not be able to transport > > the certificate proper, I think we should at least open the possibility > > to transport a certitficate hash. > > > > That leads me back to the idea of making a lot of the identification > > parameters in "CertID" optional. But we will get serious > > interoperability issues. So either we build specific CertIDs with > > specific purposes in mind or we need some profiling (and probably a > > means for the responder to transport valid combinations back to the > > client). > > > > Andreas > > -- > > Fifty-three percent of Fortune 1000 executives think the > > Arch Deluxe is something that helps to run a computer. > > -- Jericho Communications > > -- > Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net > Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 > 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA22389 for ietf-pkix-bks; Mon, 21 Sep 1998 00:36:51 -0700 (PDT) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA22383 for <ietf-pkix@imc.org>; Mon, 21 Sep 1998 00:36:11 -0700 (PDT) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id JAA09835; Mon, 21 Sep 1998 09:29:18 +0200 Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA15096; Mon, 21 Sep 1998 09:29:22 +0200 (DFT) Message-ID: <36067EF5.8F246720@bull.net> Date: Mon, 21 Sep 1998 09:29:41 -0700 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.03 [fr] (Win16; I) MIME-Version: 1.0 To: Michael Myers <mmyers@verisign.com> CC: ietf-pkix@imc.org Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt References: <3.0.32.19980918180005.00920ee4@mail.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Michael, I first suggest that you re-read my last proposal from Friday which does not contradicts your rational but contradicts your conclusion. > All, > > The intent was to provide an alternative to CRLs. Following that model, > there's an underlying assumption that the end-entity is in possession of > the CA's certificate (as would be needed to validate the signature on a CRL.) Yes, the underlying assumption that the end-entity has to get the CA's public key or certificate. But, we should not make any assumption whether that information must be obtained BEFORE or AFTER the OCSP request. > OCSP never had a requirement to validate an end-entity certificate in the > absence of the CA certificate at the requestor end. It's not just a > requirement on syntax at the request. This would also imply path > validation logic on the server. The consensus has been conclusively > established that full certificate validation is beyond the scope of this > protocol. I strongly agree with your last sentence. > There's consequently no need to alter the request syntax. I respectfully disagree with your conclusion. Denis > Mike -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04797 for ietf-pkix-bks; Sun, 20 Sep 1998 17:02:12 -0700 (PDT) Received: from typhoon.dstc.qut.edu.au (root@typhoon.dstc.qut.edu.au [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04793 for <ietf-pkix@imc.org>; Sun, 20 Sep 1998 17:02:06 -0700 (PDT) Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with ESMTP id KAA06232 for <ietf-pkix@imc.org>; Mon, 21 Sep 1998 10:08:18 +1000 (EST) Message-Id: <199809210008.KAA06232@typhoon.dstc.qut.edu.au> X-Mailer: exmh version 2.0.2 2/24/98 To: ietf-pkix@imc.org Subject: Re: Testing the ASN.1 in Part 1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Sep 1998 10:08:16 +1000 From: Dean Povey <povey@dstc.qut.edu.au> Sender: owner-ietf-pkix@imc.org Precedence: bulk Just another minor point: id-ad, id-ad-ocsp and id-ad-caIssuers are defined in both PKIX1Implicit88 and PKIX1Explicit88. -- Dean Povey, | e-m: povey@dstc.edu.au | Cryptozilla: Research Scientist | ph: +61 7 3864 5120 | www.cryptozilla.org/ Security Unit, DSTC | fax: +61 7 3864 1282 | Oscar - PKI Toolkit: Brisbane, Australia | www: security.dstc.edu.au/ | oscar.dstc.qut.edu.au/ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02905 for ietf-pkix-bks; Sun, 20 Sep 1998 10:35:53 -0700 (PDT) Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02901 for <ietf-pkix@imc.org>; Sun, 20 Sep 1998 10:35:51 -0700 (PDT) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id TAA10451; Sun, 20 Sep 1998 19:41:59 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id TAA02115; Sun, 20 Sep 1998 19:41:58 +0200 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA18646; Sun, 20 Sep 1998 19:41:58 +0200 Date: Sun, 20 Sep 1998 19:41:58 +0200 Message-Id: <199809201741.TAA18646@emeriau.edelweb.fr> To: anders.rundgren@jaybis.com Subject: Re: OCSP - Public Key Dstribution Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk Anders, the proposal of Denis solves a different problem. It makes the syntax easier for the client, it doesn't require a field that may be unnecessary. An interpretation of OCSP or OCVP is independant of the syntax change. It is the interpretation of the RESULT that counts: - In OCSP you interprete 'good' as 'I have not information that it is NOT GOOD'. - in OCSP you would interprete 'unknown' as 'I know that this CA has never issued the CA, or I do not know the CA'. Denis' proposal makes the proposal more lightweight. You can even consider that an OCSP or OCVP does not need more than just a serial number (because it operated in a very restricted environment of just one CA), but well, the protocol should be able to cover a large range of applications. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02899 for ietf-pkix-bks; Sun, 20 Sep 1998 10:35:23 -0700 (PDT) Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02895 for <ietf-pkix@imc.org>; Sun, 20 Sep 1998 10:35:21 -0700 (PDT) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id TAA10447; Sun, 20 Sep 1998 19:41:29 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id TAA02111; Sun, 20 Sep 1998 19:41:28 +0200 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA18643; Sun, 20 Sep 1998 19:41:28 +0200 Date: Sun, 20 Sep 1998 19:41:28 +0200 Message-Id: <199809201741.TAA18643@emeriau.edelweb.fr> To: ietf-pkix@imc.org, mmyers@verisign.com Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt Sender: owner-ietf-pkix@imc.org Precedence: bulk > All, You :-) , > > The intent was to provide an alternative to CRLs. Following that model, > there's an underlying assumption that the end-entity is in possession of > the CA's certificate (as would be needed to validate the signature on a CRL.) This is a description that is somewhat strange. What is an alternative to CRLs? Read part1 of pkix. An alternative is something that replace completely the usage of CRLs. CRLs by definition are one means to detect revoked certs, YOUR intention was to have just access to a remotely manged CRL. There has been a lot of discussion that OCSP is a service that allows what it says in its definition, online status verification, and not just lookup of a remote CRL base. A lot of effort has been made to ensure that a minimal OCSP service can actually implemented using CRLs, otherwise one may have just used a certHash in the request, and not used the serial number. Anyway, an alternative has not a defined model, so what do we have to follow? And why is there any underlying model. This is NOT documented in OCSP, and the contrary seems to be indicated in pkix part 1. Splitting a local logic that looks into a list a CRLs into a client server protocol MAY require additional security (as it is mentioned in pkix part1). You MAY require that a request an a response to be signed by requestor and the responder sign the response. A server MAY require that the client proves in some way that it is actually in possession of a cert, or whatever else you can image. Or: CRLs are ONE way to obtain status information of certs OCSP is not a client server implemention of CRL lookup but a general mecanism to obtain status information about certificates, and it CAN be implemented using just CRLs on the server side but it is open to provide MORE service. > > OCSP never had a requirement to validate an end-entity certificate in the > absence of the CA certificate at the requestor end. It's not just a > requirement on syntax at the request. This would also imply path > validation logic on the server. The consensus has been conclusively > established that full certificate validation is beyond the scope of this > protocol. > The first version of the protocol allowed just to present a certificate in a request. Whether the client actually has the corresponding cert before or after the validation is left to the client. Denis proposal does not put any requirement for path validation on the server, on the contrary, The server otherwise tell: I know about ONE CA and it's public key hash is what I return in the response. It the request needs to contain a key hash, the server MUST validate the public key in order to return 'unknown' if it doesn't match. Thus, in some sense the actual text requires validation on the server, and Denis' proposal removes that requirement. The only TECHNICAL problem that can happen is that the server KNOWS about more than ONE certificate having the SAME serial number and the same CA name. In this case the server should return the status of all of them, and let the client decide. > There's consequently no need to alter the request syntax. You can always deduce everything from an empty or false premises. Peter Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA29413 for ietf-pkix-bks; Sun, 20 Sep 1998 01:54:00 -0700 (PDT) Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA29409 for <ietf-pkix@imc.org>; Sun, 20 Sep 1998 01:53:57 -0700 (PDT) Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id KAA59705; Sun, 20 Sep 1998 10:59:56 +0200 Received: by HYDRA with Microsoft Mail id <01BDE484.F1DA1820@HYDRA>; Sun, 20 Sep 1998 10:53:48 +0200 Message-ID: <01BDE484.F1DA1820@HYDRA> From: Anders Rundgren <anders.rundgren@jaybis.com> To: "'Denis Pinkas'" <Denis.Pinkas@bull.net> Cc: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: OCSP - Public Key Dstribution Date: Sun, 20 Sep 1998 10:53:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA29410 Sender: owner-ietf-pkix@imc.org Precedence: bulk Salut Denis, Pardon my ignorance but does a returned issuerKeyHash give you the possibility to verify a certificate signature *after* its status has been checked? Don't you need the original (unhashed) issuer public key to to that? I.e. does this enhanced OCSP draft essentially support my suggested OCSP++ (previously I called it OCVP) system *without* requiring extensions? That would be just fantastic! http://www.jaybis.com/specifications/pkix/ocsp.html Please enlighten me! Regards Anders Rundgren ---------- From: Denis Pinkas [SMTP:Denis.Pinkas@bull.net] Sent: Saturday, September 19, 1998 02:15 To: Andreas Berger Cc: Peter Sylvester; ambarish@valicert.com; ietf-pkix@imc.org Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt Andreas, I share your concerns. The current definition of CertId is as follows: CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } CertID is used both in the request and in the response. I would suggest to change it to: CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING OPTIONAL, -- Hash of Issuers public key serialNumber CertificateSerialNumber } making the issuerKeyHash optional. The issuerKeyHash would be optional for a request but mandatory for a response. The rational is as follows: the requester needs "at some time" to get the public key of the issuer in order to verify the certificate. If we mandate that field to be always present thent it must get it *before* the request to the OCSP server. If we make it optional, then it may get it before or after the request to the OCSP server. This gives some flexibility, without too many options. The OCSP server should anyway have the Issuers public key and thus its hash. The hash may allow the requester to disambigous some responses in case of anonymity. Denis > I agree with this discussion and would like to add some thoughts: > > Peter Sylvester wrote: > > > I actually think OCVP is a bigger thing than just making the hash > > > of the issuer's PUBLIC key NULL. That whole topic should be > > > addressed at one shot > > > > > I am *not* really talking about OCVP, I am talking about 'CertID', > > a short way to identify a certificate. The syntax > > for the identification should be flexible enough > > > > - not to require more than the original certificate in > > order to construct the identification. > The is a very good assumption. While the authority key *may* be > available, it certainly isn´t always available. > > > - to allow identification of a certificate in a given context > > ==> serial number for example or/and hash of cert > The serial number is a little bit weaker but supported by other parts of > X.509, PKIX and several mail protocols, using issuer/serial for > identification of a certificate. So issuer/serial or > issuer/certificate-hash look like valid combinations. It may be a good > idea to be able add a subject public key hash if necessary. > > > - to allow the OCSP provider to find the source of > > information provider. > > ==> name of issuer may be necessary, hash of issuer name > > may not be sufficient. > So for identification of issuer we probably have a choice of issuer-name > or issuer-hash, probably in combination with issuer-public-key or > issuer-public-key-hash as an optional parameter. > > > - to ensure that the creator of the certificate really has > > a copy of a cert. > > ==> hash of cert for example, or serialnumber if authority > > allocates them in a sparse way. > > If we assume that the orginal version of OCSP where it was > > possible to just have a cert did make sense, thus I do not > > see why there is a need for the issuer public key extract > > in the certID. At least it should be optional in some way. > > > > It seems useful to me to fix a syntax for CertID that > > is sufficiently open for extensions without requiring > > a new protocol version.. > > The removal of the certificate proper as a means to "identify" a > certificate forced us to specify an extension to OCSP to do this > (transport the certificate in the request - optional, or in the reply - > optional). If the consensus is that OCSP should not be able to transport > the certificate proper, I think we should at least open the possibility > to transport a certitficate hash. > > That leads me back to the idea of making a lot of the identification > parameters in "CertID" optional. But we will get serious > interoperability issues. So either we build specific CertIDs with > specific purposes in mind or we need some profiling (and probably a > means for the responder to transport valid combinations back to the > client). > > Andreas > -- > Fifty-three percent of Fortune 1000 executives think the > Arch Deluxe is something that helps to run a computer. > -- Jericho Communications -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21235 for ietf-pkix-bks; Sat, 19 Sep 1998 13:51:03 -0700 (PDT) Received: from cylink.com ([204.160.108.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA21231 for <ietf-pkix@imc.org>; Sat, 19 Sep 1998 13:51:02 -0700 (PDT) Received: by cylink.com (8.8.8/SMI-SVR4) id OAA07962; Sat, 19 Sep 1998 14:01:17 -0700 (PDT) Received: from cylink252.cylink.com(205.226.82.252) by enforcer.cylink.com via smap (V2.0) id xma007960; Sat, 19 Sep 98 14:00:57 -0700 Reply-To: <amit@netcom.com> From: "Amit Kapoor" <amit@netcom.com> To: "PKIX" <ietf-pkix@imc.org> Subject: Testing the ASN.1 in Part 1 Date: Sat, 19 Sep 1998 13:58:24 -0700 Message-ID: <001a01bde410$3dbd7cc0$0a01040a@mordor.cylink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-pkix@imc.org Precedence: bulk The following two in PKIX1Implicit93 (and 88): DistributionPoint ::= SEQUENCE { distributionPoint [0] DistributionPointName OPTIONAL, reasons [1] ReasonFlags OPTIONAL, cRLIssuer [2] GeneralNames OPTIONAL } DistributionPointName ::= CHOICE { fullName [0] GeneralNames, nameRelativeToCRLIssuer [1] RelativeDistinguishedName } Is the tagging correct for DistributionPointName in DistributionPoint considering the package is defined as IMPLICIT tagging? How will will the decoder know which one of the two DistributionPointName (GeneralNames | RelativeDistinguishedName) is represented by [0]? Similarly for IssuingDistPointSyntax. I recall a message from someone from OSS a while back on somewhat a similar subject but afraid could not locate it in the archives. Thanks. Amit Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26882 for ietf-pkix-bks; Fri, 18 Sep 1998 17:54:41 -0700 (PDT) Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26878 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 17:54:40 -0700 (PDT) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id RAA13604; Fri, 18 Sep 1998 17:58:14 -0700 (PDT) Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id SAA11253; Fri, 18 Sep 1998 18:00:07 -0700 (PDT) Message-Id: <3.0.32.19980918180005.00920ee4@mail.verisign.com> X-Sender: mmyers@mail.verisign.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 18 Sep 1998 18:00:08 -0700 To: ietf-pkix@imc.org From: Michael Myers <mmyers@verisign.com> Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk All, The intent was to provide an alternative to CRLs. Following that model, there's an underlying assumption that the end-entity is in possession of the CA's certificate (as would be needed to validate the signature on a CRL.) OCSP never had a requirement to validate an end-entity certificate in the absence of the CA certificate at the requestor end. It's not just a requirement on syntax at the request. This would also imply path validation logic on the server. The consensus has been conclusively established that full certificate validation is beyond the scope of this protocol. There's consequently no need to alter the request syntax. Mike Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25592 for ietf-pkix-bks; Fri, 18 Sep 1998 14:33:09 -0700 (PDT) Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25586 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 14:33:07 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id OAA19912; Fri, 18 Sep 1998 14:39:10 -0700 (PDT) Message-Id: <3.0.3.32.19980918143811.00b1f6e0@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 18 Sep 1998 14:38:11 -0700 To: "Flanigan, Bill" <flanigab@ncr.disa.mil>, ietf-pkix@imc.org From: Tony Bartoletti <azb@llnl.gov> Subject: RE: proposed text for attributes In-Reply-To: <5F21F6A15446D211B0730020484016A34A8DED@RBMAIL103> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk At 04:39 PM 9/18/98 -0400, Flanigan, Bill wrote: >Hmm. I'm starting to have a what-does-it really-say/mean problem with >things like the "may" word, the "local policy" words, and, in fact, the >wording of the entire paragraph on the cACertificate attribute. What >happened to the "shall" word, and what does "local policy" add in the way >clarification? > It's not what goes where (we seem to have rough consensus here), but >rather how to express this with minimal ambiguity and number of words. How >about a single sentence along the lines of "The cACertificate attribute of a >CA's directory entry shall be used to store self-issued certificates (if >any) and certificates issued to this CA by CAs in the same realm as this >CA"? Why not replace "realm" (or domain or scope) with what the word(s) intend. I take "CA's in the same realm/domain" to mean "CA's acting under a common authority-to-issue". Does this help? ___tony___ Tony Bartoletti LL SPI-NET GURU LL LL Computer Security Technology Center LL LL LL Lawrence Livermore National Lab LL LL LL PO Box 808, L - 303 LL LL LLLLLLLL Livermore, CA 94551-9900 LL LLLLLLLL email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25057 for ietf-pkix-bks; Fri, 18 Sep 1998 13:29:40 -0700 (PDT) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25053 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 13:29:39 -0700 (PDT) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <TDQTCBB7>; Fri, 18 Sep 1998 16:34:34 -0400 Message-ID: <5F21F6A15446D211B0730020484016A34A8DED@RBMAIL103> From: "Flanigan, Bill" <flanigab@ncr.disa.mil> To: ietf-pkix@imc.org Subject: RE: proposed text for attributes Date: Fri, 18 Sep 1998 16:39:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk Hmm. I'm starting to have a what-does-it really-say/mean problem with things like the "may" word, the "local policy" words, and, in fact, the wording of the entire paragraph on the cACertificate attribute. What happened to the "shall" word, and what does "local policy" add in the way clarification? It's not what goes where (we seem to have rough consensus here), but rather how to express this with minimal ambiguity and number of words. How about a single sentence along the lines of "The cACertificate attribute of a CA's directory entry shall be used to store self-issued certificates (if any) and certificates issued to this CA by CAs in the same realm as this CA"? Bill Flanigan %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% William F. Flanigan, Jr., Ph.D. Voice: (703) 681-2318 Defense Information Systems Agency Fax: (703) 681-2814 Information Assurance Engineering DSN: 761 5600 Columbia Pike, Room 632 Voice Mail: (703) 681-2318 Falls Church, VA 22041-2717 Internet: <flanigab@ncr.disa.mil> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > -----Original Message----- > From: Paul Hoffman / IMC [SMTP:phoffman@imc.org] > Sent: Friday, September 18, 1998 12:39 PM > To: ietf-pkix@imc.org > Subject: Re: proposed text for attributes > > >Unless there are any other objections to the wording, I'll get the draft > >revised with this wording and submitted by Monday. > > I'd like to echo David Kurn's concern that the wording with respect to the > cACertificate attribute of a CA's directory entry. If you don't define > "realm", > then there doesn't seem much point to saying that "some things that person > accessing the directory cannot determine will appear in the cACertificate > attribute". Why is that still in the spec if it's up to local policy to > decide > what to put there? > > Maybe better wording would be "The cACertificate attribute of a CA's > directory > entry may be populated with certificates defined by local policy" and > leave > the > rest of the paragraph out. > > > --Paul Hoffman, Director > --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23955 for ietf-pkix-bks; Fri, 18 Sep 1998 11:09:14 -0700 (PDT) Received: from romulus.cs.ut.ee (jan@romulus.cs.ut.ee [193.40.5.125]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA23951 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 11:09:12 -0700 (PDT) Received: from localhost (jan@localhost) by romulus.cs.ut.ee (8.9.1/8.9.1/romulus-1.4) with SMTP id VAA13259 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 21:15:08 +0300 (EET DST) Date: Fri, 18 Sep 1998 21:15:06 +0300 ( ) From: Jan Willemson <jan@cs.ut.ee> To: ietf-pkix@imc.org Subject: Who uses what? Message-ID: <Pine.GSO.4.02A.9809182058590.12460-100000@romulus.cs.ut.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-pkix@imc.org Precedence: bulk Hello! Excuse me please for being yet-another-newbie and asking a newbie question. But this is the only way to get smart. I have been reading ietf-pkix drafts for some time and found a lot of proposed X.509 extensions. On the other hand there are many companies (Netscape etc) producing cert-software that uses (as I understand) some of these extensions and some extensions of their own. So - is there somewhere out there an overview of who uses what? I believe there is, but my webcrawling has not been able to find it yet. I would be grateful for all hints/links etc. Thank you:) Jan Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23493 for ietf-pkix-bks; Fri, 18 Sep 1998 10:23:23 -0700 (PDT) Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23488; Fri, 18 Sep 1998 10:23:22 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA15812; Fri, 18 Sep 1998 10:28:13 -0700 (PDT) Message-Id: <199809181728.KAA15812@spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta) Date: Fri, 18 Sep 1998 13:29:49 -0400 To: Dean Povey <povey@dstc.qut.edu.au> From: Russ Housley <housley@spyrus.com> Subject: Re: Testing the ASN.1 in Part 1 Cc: Paul Hoffman / IMC <phoffman@imc.org>, ietf-pkix@imc.org In-Reply-To: <199809180548.PAA24765@typhoon.dstc.qut.edu.au> References: <Your message of "Tue, 15 Sep 1998 14:29:01 +1000." <199809150429.OAA08287@typhoon.dstc.qut.edu.au> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk <html> You found a minor editorial error in the document, but not an ASN.1 error.<br> <br> For some reason, CertificatePolicies is defined here and where it should be.<br> <br> The two lines with '*' at the front should be deleted:<br> <br> <font face="Courier New, Courier"> id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }<br> <br> * CertificatePoliciesSyntax ::=<br> * SEQUENCE SIZE (1..MAX) OF PolicyInformation<br> <br> PolicyConstraints ::= SEQUENCE {<br> requireExplicitPolicy [0] SkipCerts OPTIONAL,<br> inhibitPolicyMapping [1] SkipCerts OPTIONAL }<br> <br> SkipCerts ::= INTEGER (0..MAX)<br> <br> <br> </font>Russ<br> <br> <br> <br> At 03:47 PM 9/18/98 +1000, Dean Povey wrote:<br> ><br> >><br> >><br> >>>Anyone who plans to get around to checking the ASN.1 after part 1 becomes<br> >>>an RFC: could you do it now instead? This would be a great help to us all.<br> >>>Thanks!<br> >>><br> ><br> >More bugs in PKIX1ImplictXX<br> ><br> >The ASN.1 for PolicyConstraints is incorrect. In both the 88 and 93 versions <br> >it is specified as a SEQUENCE SIZE(1..MAX) OF SEQUENCE { ... }. This is <br> >inconsistent with the X.509 definition and it also doesn't make any sense for <br> >it to be a SEQUENCE OF. The definition of PolicyConstraints should be:<br> ><br> >PolicyConstraints ::= SEQUENCE {<br> ><x-tab> </x-tab>requireExplicitPolicy<x-tab> </x-tab>[0] SkipCerts OPTIONAL,<br> ><x-tab> </x-tab>inhibitPolicyMapping<x-tab> </x-tab>[1] SkipCerts OPTIONAL }<br> ><br> >Also the authorityInfoAccess OID is missing in the 88 module, it should be:<br> ><br> >id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }<br> ><br> >More as I find 'em :-).<br> ><br> ><br> >-- <br> >Dean Povey, | e-m: povey@dstc.edu.au | Cryptozilla:<br> >Research Scientist | ph: +61 7 3864 5120 | <a href="http://www.cryptozilla.org/" eudora="autourl">www.cryptozilla.org/</a><br> >Security Unit, DSTC | fax: +61 7 3864 1282 | Oscar - PKI Toolkit:<br> >Brisbane, Australia | www: security.dstc.edu.au/ | oscar.dstc.qut.edu.au/<br> ><br> ><br> </html> Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23017 for ietf-pkix-bks; Fri, 18 Sep 1998 09:33:46 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23013 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 09:33:45 -0700 (PDT) Message-Id: <199809181633.JAA23013@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta) Date: Fri, 18 Sep 1998 09:39:16 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: proposed text for attributes In-Reply-To: <D789F71F24B4D111955D00A0C99B4F50AC9788@sothmxs01.entrust.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk >Unless there are any other objections to the wording, I'll get the draft >revised with this wording and submitted by Monday. I'd like to echo David Kurn's concern that the wording with respect to the cACertificate attribute of a CA's directory entry. If you don't define "realm", then there doesn't seem much point to saying that "some things that person accessing the directory cannot determine will appear in the cACertificate attribute". Why is that still in the spec if it's up to local policy to decide what to put there? Maybe better wording would be "The cACertificate attribute of a CA's directory entry may be populated with certificates defined by local policy" and leave the rest of the paragraph out. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22573 for ietf-pkix-bks; Fri, 18 Sep 1998 08:40:12 -0700 (PDT) Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22569 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 08:40:10 -0700 (PDT) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id RAA21236; Fri, 18 Sep 1998 17:41:08 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id RAA21071; Fri, 18 Sep 1998 17:41:07 +0200 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id RAA17885; Fri, 18 Sep 1998 17:41:07 +0200 Date: Fri, 18 Sep 1998 17:41:07 +0200 Message-Id: <199809181541.RAA17885@emeriau.edelweb.fr> To: aberger@darmstadt.gmd.de, Denis.Pinkas@bull.net Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt Cc: ambarish@valicert.com, ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk I support the suggestion from Denis. I suggest that one adds an optional hash of the certificate. it MAY be returned by the OCSP server, and it MAY be requested by the OCSP server. one could use the now obsolete error code certrequired (rename it certhashrequired). Whenever a client actually has the cert I would expect that it always sets the certHash in the request, the OCSP server may remove the certHash in the response if the certHash value was not used in order for identification, e.g. when only the serialNumber was used. CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING OPTIONAL, -- Hash of Issuers public key serialNumber CertificateSerialNumber certHash OCTET STRING OPTIONAL, -- hash of the certificate. } Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22288 for ietf-pkix-bks; Fri, 18 Sep 1998 08:08:01 -0700 (PDT) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22284 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 08:07:56 -0700 (PDT) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id RAA16372; Fri, 18 Sep 1998 17:14:34 +0200 Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id RAA17286; Fri, 18 Sep 1998 17:14:27 +0200 (DFT) Message-ID: <3602F778.27E7C98D@bull.net> Date: Fri, 18 Sep 1998 17:14:48 -0700 From: Denis Pinkas <Denis.Pinkas@bull.net> Organization: Bull X-Mailer: Mozilla 4.03 [fr] (Win16; I) MIME-Version: 1.0 To: Andreas Berger <aberger@darmstadt.gmd.de> CC: Peter Sylvester <Peter.Sylvester@edelweb.fr>, ambarish@valicert.com, ietf-pkix@imc.org Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt References: <199809180856.KAA17797@emeriau.edelweb.fr> <360230B4.B31B53E8@darmstadt.gmd.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Andreas, I share your concerns. The current definition of CertId is as follows: CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } CertID is used both in the request and in the response. I would suggest to change it to: CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING OPTIONAL, -- Hash of Issuers public key serialNumber CertificateSerialNumber } making the issuerKeyHash optional. The issuerKeyHash would be optional for a request but mandatory for a response. The rational is as follows: the requester needs "at some time" to get the public key of the issuer in order to verify the certificate. If we mandate that field to be always present thent it must get it *before* the request to the OCSP server. If we make it optional, then it may get it before or after the request to the OCSP server. This gives some flexibility, without too many options. The OCSP server should anyway have the Issuers public key and thus its hash. The hash may allow the requester to disambigous some responses in case of anonymity. Denis > I agree with this discussion and would like to add some thoughts: > > Peter Sylvester wrote: > > > I actually think OCVP is a bigger thing than just making the hash > > > of the issuer's PUBLIC key NULL. That whole topic should be > > > addressed at one shot > > > > > I am *not* really talking about OCVP, I am talking about 'CertID', > > a short way to identify a certificate. The syntax > > for the identification should be flexible enough > > > > - not to require more than the original certificate in > > order to construct the identification. > The is a very good assumption. While the authority key *may* be > available, it certainly isn´t always available. > > > - to allow identification of a certificate in a given context > > ==> serial number for example or/and hash of cert > The serial number is a little bit weaker but supported by other parts of > X.509, PKIX and several mail protocols, using issuer/serial for > identification of a certificate. So issuer/serial or > issuer/certificate-hash look like valid combinations. It may be a good > idea to be able add a subject public key hash if necessary. > > > - to allow the OCSP provider to find the source of > > information provider. > > ==> name of issuer may be necessary, hash of issuer name > > may not be sufficient. > So for identification of issuer we probably have a choice of issuer-name > or issuer-hash, probably in combination with issuer-public-key or > issuer-public-key-hash as an optional parameter. > > > - to ensure that the creator of the certificate really has > > a copy of a cert. > > ==> hash of cert for example, or serialnumber if authority > > allocates them in a sparse way. > > If we assume that the orginal version of OCSP where it was > > possible to just have a cert did make sense, thus I do not > > see why there is a need for the issuer public key extract > > in the certID. At least it should be optional in some way. > > > > It seems useful to me to fix a syntax for CertID that > > is sufficiently open for extensions without requiring > > a new protocol version.. > > The removal of the certificate proper as a means to "identify" a > certificate forced us to specify an extension to OCSP to do this > (transport the certificate in the request - optional, or in the reply - > optional). If the consensus is that OCSP should not be able to transport > the certificate proper, I think we should at least open the possibility > to transport a certitficate hash. > > That leads me back to the idea of making a lot of the identification > parameters in "CertID" optional. But we will get serious > interoperability issues. So either we build specific CertIDs with > specific purposes in mind or we need some profiling (and probably a > means for the responder to transport valid combinations back to the > client). > > Andreas > -- > Fifty-three percent of Fortune 1000 executives think the > Arch Deluxe is something that helps to run a computer. > -- Jericho Communications -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21046 for ietf-pkix-bks; Fri, 18 Sep 1998 05:00:00 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA21042 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 04:59:58 -0700 (PDT) Received: id IAA04558; Fri, 18 Sep 1998 08:03:06 -0400 Received: by gateway id <S2S6Y5Z8>; Fri, 18 Sep 1998 07:59:50 -0400 Message-ID: <D789F71F24B4D111955D00A0C99B4F50AC9788@sothmxs01.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: proposed text for attributes Date: Fri, 18 Sep 1998 07:59:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk Santosh and I prefer the use of 'realm'. Scope, although not as bad as domain, also has some other meanings associated with it in the PKI area. Unless there are any other objections to the wording, I'll get the draft revised with this wording and submitted by Monday. I also will be submitting a new version of the LDAPv2 protocol profile, but this is only because the current draft expires this month. There are no changes to it and it passed last call back in January (for those who weren't following this list at that time, the IESG would not allow it to progress to RFC without this accompanying schema). Sharon ------------------ Sharon Boeyen Entrust Technologies mailto:sharon.boeyen@entrust.com Tel: (613) 247-3181 http://www.entrust.com Fax: (613) 247-3690 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA18545 for ietf-pkix-bks; Fri, 18 Sep 1998 03:02:10 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA18541 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 03:02:07 -0700 (PDT) Received: from darmstadt.gmd.de (aberger@pc-turin [141.12.33.71]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id MAA27586; Fri, 18 Sep 1998 12:06:18 +0200 (MET DST) Message-ID: <360230B4.B31B53E8@darmstadt.gmd.de> Date: Fri, 18 Sep 1998 12:06:44 +0200 From: Andreas Berger <aberger@darmstadt.gmd.de> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i586) MIME-Version: 1.0 To: Peter Sylvester <Peter.Sylvester@edelweb.fr> CC: ambarish@valicert.com, ietf-pkix@imc.org Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt References: <199809180856.KAA17797@emeriau.edelweb.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk I agree with this discussion and would like to add some thoughts: Peter Sylvester wrote: > > I actually think OCVP is a bigger thing than just making the hash > > of the issuer's PUBLIC key NULL. That whole topic should be > > addressed at one shot > > > I am *not* really talking about OCVP, I am talking about 'CertID', > a short way to identify a certificate. The syntax > for the identification should be flexible enough > > - not to require more than the original certificate in > order to construct the identification. The is a very good assumption. While the authority key *may* be available, it certainly isn´t always available. > - to allow identification of a certificate in a given context > ==> serial number for example or/and hash of cert The serial number is a little bit weaker but supported by other parts of X.509, PKIX and several mail protocols, using issuer/serial for identification of a certificate. So issuer/serial or issuer/certificate-hash look like valid combinations. It may be a good idea to be able add a subject public key hash if necessary. > - to allow the OCSP provider to find the source of > information provider. > ==> name of issuer may be necessary, hash of issuer name > may not be sufficient. So for identification of issuer we probably have a choice of issuer-name or issuer-hash, probably in combination with issuer-public-key or issuer-public-key-hash as an optional parameter. > - to ensure that the creator of the certificate really has > a copy of a cert. > ==> hash of cert for example, or serialnumber if authority > allocates them in a sparse way. > If we assume that the orginal version of OCSP where it was > possible to just have a cert did make sense, thus I do not > see why there is a need for the issuer public key extract > in the certID. At least it should be optional in some way. > > It seems useful to me to fix a syntax for CertID that > is sufficiently open for extensions without requiring > a new protocol version.. The removal of the certificate proper as a means to "identify" a certificate forced us to specify an extension to OCSP to do this (transport the certificate in the request - optional, or in the reply - optional). If the consensus is that OCSP should not be able to transport the certificate proper, I think we should at least open the possibility to transport a certitficate hash. That leads me back to the idea of making a lot of the identification parameters in "CertID" optional. But we will get serious interoperability issues. So either we build specific CertIDs with specific purposes in mind or we need some profiling (and probably a means for the responder to transport valid combinations back to the client). Andreas -- Fifty-three percent of Fortune 1000 executives think the Arch Deluxe is something that helps to run a computer. -- Jericho Communications Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA18216 for ietf-pkix-bks; Fri, 18 Sep 1998 01:56:54 -0700 (PDT) Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA18212 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 01:56:53 -0700 (PDT) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id LAA08690; Fri, 18 Sep 1998 11:02:54 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id LAA17532; Fri, 18 Sep 1998 11:02:54 +0200 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id LAA17802; Fri, 18 Sep 1998 11:02:53 +0200 Date: Fri, 18 Sep 1998 11:02:53 +0200 Message-Id: <199809180902.LAA17802@emeriau.edelweb.fr> To: ietf-pkix@imc.org, danjw1@pacbell.net Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt Sender: owner-ietf-pkix@imc.org Precedence: bulk > I thought the issue with this was that in a case of a request where the > certificate was sent in place of the certID, a response could not be > formed unless the responder already had the issuer cert (or at least > knew its key hash). This has been dealt with, since request now must > have a certID for each requested cert. Was there some additional issue > I wasn't aware of? The original text provided to USE a certificate and nothing else to form a request. This is no longer possible. CertID in its current form cannot be used as a replacement for a certificate in the case where the client does not have the issuer cert. The syntax for CertID has not been discussed in the context where this is the ONLY way to identify a cert. Peter Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA18176 for ietf-pkix-bks; Fri, 18 Sep 1998 01:50:30 -0700 (PDT) Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA18171 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 01:50:27 -0700 (PDT) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id KAA08440; Fri, 18 Sep 1998 10:56:25 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id KAA17394; Fri, 18 Sep 1998 10:56:24 +0200 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id KAA17797; Fri, 18 Sep 1998 10:56:24 +0200 Date: Fri, 18 Sep 1998 10:56:24 +0200 Message-Id: <199809180856.KAA17797@emeriau.edelweb.fr> To: ambarish@valicert.com Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@imc.org Precedence: bulk > > > > I actually think OCVP is a bigger thing than just making the hash > of the issuer's PUBLIC key NULL. That whole topic should be > addressed at one shot > I am *not* really talking about OCVP, I am talking about 'CertID', a short way to identify a certificate. The syntax for the identification should be flexible enough - not to require more than the original certificate in order to construct the identification. - to allow identification of a certificate in a given context ==> serial number for example or/and hash of cert - to allow the OCSP provider to find the source of information provider. ==> name of issuer may be necessary, hash of issuer name may not be sufficient. - to ensure that the creator of the certificate really has a copy of a cert. ==> hash of cert for example, or serialnumber if authority allocates them in a sparse way. If we assume that the orginal version of OCSP where it was possible to just have a cert did make sense, thus I do not see why there is a need for the issuer public key extract in the certID. At least it should be optional in some way. It seems useful to me to fix a syntax for CertID that is sufficiently open for extensions without requiring a new protocol version.. Peter Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA18121 for ietf-pkix-bks; Fri, 18 Sep 1998 01:43:45 -0700 (PDT) Received: from mail-gw.pacbell.net (mail-gw.pacbell.net [206.13.28.25]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA18117 for <ietf-pkix@imc.org>; Fri, 18 Sep 1998 01:43:44 -0700 (PDT) Received: from pacbell.net (ppp-206-170-3-162.okld03.pacbell.net [206.170.3.162]) by mail-gw.pacbell.net (8.8.8/8.7.1+antispam) with ESMTP id BAA19674; Fri, 18 Sep 1998 01:49:45 -0700 (PDT) Message-ID: <36021C9D.7B5FFABE@pacbell.net> Date: Fri, 18 Sep 1998 01:41:01 -0700 From: Dan Weinstein <danjw1@pacbell.net> X-Mailer: Mozilla 4.5b2 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org, Peter.Sylvester@edelweb.fr Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk >some remarks about the lastest OCSP draft: > >- It seems that the remarks about not knowing the public > key of an issuer are not addressed. > > It seems sufficient to ME to allow that the > hash of the issure private key MAY be a length 0 octet string, > something like that, or one might add the public > key of the OCSP responder instead. > > Thoughts? I thought the issue with this was that in a case of a request where the certificate was sent in place of the certID, a response could not be formed unless the responder already had the issuer cert (or at least knew its key hash). This has been dealt with, since request now must have a certID for each requested cert. Was there some additional issue I wasn't aware of? Dan Weinstein danjw1@pacbell.net Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA07834 for ietf-pkix-bks; Thu, 17 Sep 1998 22:42:05 -0700 (PDT) Received: from typhoon.dstc.qut.edu.au (root@typhoon.dstc.qut.edu.au [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA07821; Thu, 17 Sep 1998 22:42:01 -0700 (PDT) Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with ESMTP id PAA24765; Fri, 18 Sep 1998 15:48:00 +1000 (EST) Message-Id: <199809180548.PAA24765@typhoon.dstc.qut.edu.au> X-Mailer: exmh version 2.0.2 2/24/98 cc: Paul Hoffman / IMC <phoffman@imc.org>, ietf-pkix@imc.org Subject: Re: Testing the ASN.1 in Part 1 In-reply-to: Your message of "Tue, 15 Sep 1998 14:29:01 +1000." <199809150429.OAA08287@typhoon.dstc.qut.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Sep 1998 15:47:57 +1000 From: Dean Povey <povey@dstc.qut.edu.au> Sender: owner-ietf-pkix@imc.org Precedence: bulk > > >>Anyone who plans to get around to checking the ASN.1 after part 1 becomes >>an RFC: could you do it now instead? This would be a great help to us all. >>Thanks! >> More bugs in PKIX1ImplictXX The ASN.1 for PolicyConstraints is incorrect. In both the 88 and 93 versions it is specified as a SEQUENCE SIZE(1..MAX) OF SEQUENCE { ... }. This is inconsistent with the X.509 definition and it also doesn't make any sense for it to be a SEQUENCE OF. The definition of PolicyConstraints should be: PolicyConstraints ::= SEQUENCE { requireExplicitPolicy [0] SkipCerts OPTIONAL, inhibitPolicyMapping [1] SkipCerts OPTIONAL } Also the authorityInfoAccess OID is missing in the 88 module, it should be: id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } More as I find 'em :-). -- Dean Povey, | e-m: povey@dstc.edu.au | Cryptozilla: Research Scientist | ph: +61 7 3864 5120 | www.cryptozilla.org/ Security Unit, DSTC | fax: +61 7 3864 1282 | Oscar - PKI Toolkit: Brisbane, Australia | www: security.dstc.edu.au/ | oscar.dstc.qut.edu.au/ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26263 for ietf-pkix-bks; Thu, 17 Sep 1998 14:47:40 -0700 (PDT) Received: from atlantic.valicert.com (qmailr@old-atlantic.valicert.com [209.185.6.135]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA26259 for <ietf-pkix@imc.org>; Thu, 17 Sep 1998 14:47:39 -0700 (PDT) Received: (qmail 2737 invoked from network); 17 Sep 1998 21:53:34 -0000 Received: from ns.valicert.com (HELO valicert.com) (209.185.6.1) by 209.185.6.162 with SMTP; 17 Sep 1998 21:53:34 -0000 Message-ID: <360184DB.74788BAE@valicert.com> Date: Thu, 17 Sep 1998 14:53:31 -0700 From: Ambarish Malpani <ambarish@valicert.com> Organization: ValiCert, Inc. X-Mailer: Mozilla 4.5b2 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: fast review of draft-ietf-pkix-ocsp-06.txt References: <199809171636.SAA17487@emeriau.edelweb.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Peter, Great catches - comments follow: Peter Sylvester wrote: > > hello, > > some remarks about the lastest OCSP draft: > > - It seems that the remarks about not knowing the public > key of an issuer are not addressed. > > It seems sufficient to ME to allow that the > hash of the issure private key MAY be a length 0 octet string, > something like that, or one might add the public > key of the OCSP responder instead. > > Thoughts? > I actually think OCVP is a bigger thing than just making the hash of the issuer's PUBLIC key NULL. That whole topic should be addressed at one shot > > - the remark > > " Response extensions may be used to > convey additional information on assertions made by the responder > regarding the status of the certificate such as positive statement > about issuance, validity, etc." > > should be removed behind all possible responses since extensions > can also be used to indicate additional interpretations for > revoked, notknown. > > > - > The response "certRequired" is returned in cases where the server > > requires the client to supply the certificate data itself in order to > > construct a response. > > This paragraph should be removed > > etc for the ASN.1 response code > certRequired (4), --Must supply certificate Agreed - will be fixed. Thanks for catching this > > - A.1.1 : "Where privacy is a > requirement, OCSP transactions exchanged using HTTP SHOULD be protected > using either TLS or SSL." > > Shouldn't the SHOULD be a MAY ? > > one could also use a VPN for example Agreed. > > Or just add 'or by lower layer protection'. > > have fun. -- --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 1215 Terra Bella Ave. http://www.valicert.com Mountain View, CA 94043-1833 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23625 for ietf-pkix-bks; Thu, 17 Sep 1998 09:30:23 -0700 (PDT) Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23621 for <ietf-pkix@imc.org>; Thu, 17 Sep 1998 09:30:22 -0700 (PDT) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr with ESMTP id SAA27290 for <ietf-pkix@imc.org>; Thu, 17 Sep 1998 18:36:02 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id SAA11058 for <ietf-pkix@imc.org>; Thu, 17 Sep 1998 18:36:02 +0200 From: Peter Sylvester <Peter.Sylvester@edelweb.fr> Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id SAA17487 for ietf-pkix@imc.org; Thu, 17 Sep 1998 18:36:01 +0200 Date: Thu, 17 Sep 1998 18:36:01 +0200 Message-Id: <199809171636.SAA17487@emeriau.edelweb.fr> To: ietf-pkix@imc.org Subject: fast review of draft-ietf-pkix-ocsp-06.txt Sender: owner-ietf-pkix@imc.org Precedence: bulk hello, some remarks about the lastest OCSP draft: - It seems that the remarks about not knowing the public key of an issuer are not addressed. It seems sufficient to ME to allow that the hash of the issure private key MAY be a length 0 octet string, something like that, or one might add the public key of the OCSP responder instead. Thoughts? - the remark " Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc." should be removed behind all possible responses since extensions can also be used to indicate additional interpretations for revoked, notknown. - > The response "certRequired" is returned in cases where the server > requires the client to supply the certificate data itself in order to > construct a response. This paragraph should be removed etc for the ASN.1 response code certRequired (4), --Must supply certificate - A.1.1 : "Where privacy is a requirement, OCSP transactions exchanged using HTTP SHOULD be protected using either TLS or SSL." Shouldn't the SHOULD be a MAY ? one could also use a VPN for example Or just add 'or by lower layer protection'. have fun. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23589 for ietf-pkix-bks; Thu, 17 Sep 1998 09:22:26 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23585 for <ietf-pkix@imc.org>; Thu, 17 Sep 1998 09:22:25 -0700 (PDT) Received: id MAA26121; Thu, 17 Sep 1998 12:26:32 -0400 Received: by gateway id <S2S6YV9W>; Thu, 17 Sep 1998 12:23:18 -0400 Message-ID: <D789F71F24B4D111955D00A0C99B4F50AC9785@sothmxs01.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: ietf-pkix@imc.org, "'bgmiller@dc.jones.com'" <bgmiller@dc.jones.com> Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes Date: Thu, 17 Sep 1998 12:23:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk I'm flexible on the term and have passed that on to Santosh (awaiting his reply). I see nothing wrong with scope or realm and am open to suggestion. I agree that it would be good to select a term that doesn't have a predefined meaning in the IETF. It is important to keep the definition of the specific criteria for its use as a local matter so this mechanism can be used in different environments with different criteria for the 'hints' provided by the CA to relying parties, regardless of whether relying parties choose to examine those hints or not. That, we've been in agreement on thoughout this debate, but I'm quite agreeable to a different 'less loaded' term. > ---------- > From: bgmiller[SMTP:bgmiller@dc.jones.com] > Sent: September 16, 1998 10:26 PM > To: ietf-pkix@imc.org > Subject: Re: Storage of CA Certificates in LDAP and X.500 Directory > Attributes > > > > Paul Hoffman / IMC wrote: > > > I agree with David. The word "domain" has a specific meaning in the > IETF, > > and this definition doesn't match it. Could you use "realm" instead? Or > are > > there better words? > > How about "scope"? > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23104 for ietf-pkix-bks; Thu, 17 Sep 1998 08:38:23 -0700 (PDT) Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23100 for <ietf-pkix@imc.org>; Thu, 17 Sep 1998 08:38:22 -0700 (PDT) Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id IAA17795; Thu, 17 Sep 1998 08:44:19 -0700 (PDT) Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <SW42KV8H>; Thu, 17 Sep 1998 08:43:56 -0700 Message-ID: <418B8B7ACE69D111879B00805F6F281DFFF5B7@exccup-25006.mis.tandem.com> From: "Kurn, David" <david.kurn@compaq.com> To: "'bgmiller@dc.jones.com'" <bgmiller@dc.jones.com>, ietf-pkix@imc.org Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes Date: Thu, 17 Sep 1998 08:43:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk I think the actual choice of word here is not the issue. You can call it "Kingdom", but the flaw in the specification persists, since the last sentence implies that the word has a definition that depends upon the personal interpretation of the implementor. This doesn't make for portable programs. I think the reason the specification needs the word is so that the spec can give guidance about when to put a cross-cert in one bucket or in another bucket. And this, if I follow the recent conversations, has to do with advice about how to do path development. (I'm stepping out on shaky ground here). *IF* we wish to say to those writing path evaluation programs: "You should look in the first bucket (caCertificates) first, and then in the second bucket" then we can give some guidance about how to populate the two buckets, which could in effect would say: You should put certificates in the appropriate bucket according to your expectation about how to optimize the path development given that clients will look in the caCertificates first. Your choice will affect efficiency, not correctness. I go back to something I remember from learning about Object-Oriented programming .... don't ask "what is it", but rather "what does it do". David Kurn Compaq Computer Corp -----Original Message----- From: bgmiller [mailto:bgmiller@dc.jones.com] Sent: Wednesday, September 16, 1998 7:27 PM To: ietf-pkix@imc.org Subject: Re: Storage of CA Certificates in LDAP and X.500 Directory Attributes Paul Hoffman / IMC wrote: > I agree with David. The word "domain" has a specific meaning in the IETF, > and this definition doesn't match it. Could you use "realm" instead? Or are > there better words? How about "scope"? Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22458 for ietf-pkix-bks; Thu, 17 Sep 1998 07:04:25 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22454 for <ietf-pkix@imc.org>; Thu, 17 Sep 1998 07:04:24 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA14218; Thu, 17 Sep 1998 10:09:50 -0400 (EDT) Message-Id: <199809171409.KAA14218@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ocsp-06.txt Date: Thu, 17 Sep 1998 10:09:49 -0400 Sender: owner-ietf-pkix@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams Filename : draft-ietf-pkix-ocsp-06.txt Pages : 20 Date : 16-Sep-98 This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. An overview of the protocol is provided in section 3. Functional requirements are specified in section 4. Details of the protocol are in section 5. We cover security issues with the protocol in section 6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1 syntactic elements and appendix C specifies the mime types for the messages. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ocsp-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ocsp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980916113902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ocsp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ocsp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980916113902.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA29190 for ietf-pkix-bks; Wed, 16 Sep 1998 19:24:20 -0700 (PDT) Received: from dc.jones.com (dc.jones.com [206.156.0.9]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA29186 for <ietf-pkix@imc.org>; Wed, 16 Sep 1998 19:24:18 -0700 (PDT) Received: from dc.jones.com (cm0714h.jones.com [208.159.209.173]) by dc.jones.com (8.8.8/8.8.8) with ESMTP id WAA19170 for <ietf-pkix@imc.org>; Wed, 16 Sep 1998 22:27:11 -0400 (EDT) Message-ID: <3600735C.98A336F8@dc.jones.com> Date: Wed, 16 Sep 1998 22:26:37 -0400 From: bgmiller <bgmiller@dc.jones.com> Reply-To: bgmiller@dc.jones.com Organization: Jones Internet Channel X-Mailer: Mozilla 4.05 [en]C-JIC-DC (Win95; I) MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Storage of CA Certificates in LDAP and X.500 Directory Attributes References: <199809162243.PAA27828@mail.proper.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Paul Hoffman / IMC wrote: > I agree with David. The word "domain" has a specific meaning in the IETF, > and this definition doesn't match it. Could you use "realm" instead? Or are > there better words? How about "scope"? Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27832 for ietf-pkix-bks; Wed, 16 Sep 1998 15:43:37 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA27828 for <ietf-pkix@imc.org>; Wed, 16 Sep 1998 15:43:36 -0700 (PDT) Message-Id: <199809162243.PAA27828@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 16 Sep 1998 15:49:01 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attributes In-Reply-To: <418B8B7ACE69D111879B00805F6F281DFFF5AE@exccup-25006.mis.ta ndem.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk At 03:22 PM 9/16/98 -0700, Kurn, David wrote: >I still think the use of "domain" is very confusing, and should be removed >from the text. I agree with David. The word "domain" has a specific meaning in the IETF, and this definition doesn't match it. Could you use "realm" instead? Or are there better words? --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27652 for ietf-pkix-bks; Wed, 16 Sep 1998 15:16:39 -0700 (PDT) Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27648 for <ietf-pkix@imc.org>; Wed, 16 Sep 1998 15:16:38 -0700 (PDT) Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA23758; Wed, 16 Sep 1998 15:22:29 -0700 (PDT) Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <SW42KM98>; Wed, 16 Sep 1998 15:22:04 -0700 Message-ID: <418B8B7ACE69D111879B00805F6F281DFFF5AE@exccup-25006.mis.tandem.com> From: "Kurn, David" <david.kurn@compaq.com> To: "'Santosh Chokhani'" <chokhani@cygnacom.com>, ietf-pkix@imc.org Subject: RE: Storage of CA Certificates in LDAP and X.500 Directory Attrib utes Date: Wed, 16 Sep 1998 15:22:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk I still think the use of "domain" is very confusing, and should be removed from the text. -----Original Message----- From: Santosh Chokhani [mailto:chokhani@cygnacom.com] Sent: Wednesday, September 16, 1998 2:23 PM To: ietf-pkix@imc.org Subject: Storage of CA Certificates in LDAP and X.500 Directory Attributes Based on the pkix co-chair request, Sharon and I jointly propose the following text: "The cACertificate attribute of a CA's directory entry shall be used to store certificates issued to this CA by CAs in the same domain as this CA. If there are any self-issued certificates and they require publication, the caCertificate attribute shall be used to store them. The forward elements of the crossCertificatePair attribute of a CA's directory entry shall be used to store all certificates issued to this CA, which are not self-issued. Optionally, the reverse elements of the crossCertificatePair attribute, of a CA's directory entry may contain a subset of certificates issued by this CA to other CAs. When both the forward and the reverse elements are present in a single attribute value, issuer name in one certificate shall match the subject name in the other and vice versa, and the subject public key in one certificate shall be capable of verifying the digital signature on the other certificate and vice versa. When a reverse element is present, the forward element value and the reverse element value need not be stored in the same attribute value; in other words, they can be stored in either a single attribute value or two attribute values. In the case of V3 certificates, none of the above CA certificates shall include a basicConstraints extension with the cA value set to FALSE. The definition of domain is purely a matter of local policy. Santosh Chokhani CygnaCom Solutions, Inc. 7927 Jones Branch Drive, Suite 100 West McLean, VA. 22102 (703) 848-0883 (voice) (703) 848-0960 (fax) chokhani@cygancom.com http://www.cygnacom.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27294 for ietf-pkix-bks; Wed, 16 Sep 1998 14:18:03 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27290 for <ietf-pkix@imc.org>; Wed, 16 Sep 1998 14:18:00 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7T51TK>; Wed, 16 Sep 1998 17:22:56 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E1B1AAE@WUHER> From: Santosh Chokhani <chokhani@cygnacom.com> To: ietf-pkix@imc.org Subject: Storage of CA Certificates in LDAP and X.500 Directory Attributes Date: Wed, 16 Sep 1998 17:22:55 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Based on the pkix co-chair request, Sharon and I jointly propose the following text: "The cACertificate attribute of a CA's directory entry shall be used to store certificates issued to this CA by CAs in the same domain as this CA. If there are any self-issued certificates and they require publication, the caCertificate attribute shall be used to store them. The forward elements of the crossCertificatePair attribute of a CA's directory entry shall be used to store all certificates issued to this CA, which are not self-issued. Optionally, the reverse elements of the crossCertificatePair attribute, of a CA's directory entry may contain a subset of certificates issued by this CA to other CAs. When both the forward and the reverse elements are present in a single attribute value, issuer name in one certificate shall match the subject name in the other and vice versa, and the subject public key in one certificate shall be capable of verifying the digital signature on the other certificate and vice versa. When a reverse element is present, the forward element value and the reverse element value need not be stored in the same attribute value; in other words, they can be stored in either a single attribute value or two attribute values. In the case of V3 certificates, none of the above CA certificates shall include a basicConstraints extension with the cA value set to FALSE. The definition of domain is purely a matter of local policy. Santosh Chokhani CygnaCom Solutions, Inc. 7927 Jones Branch Drive, Suite 100 West McLean, VA. 22102 (703) 848-0883 (voice) (703) 848-0960 (fax) chokhani@cygancom.com http://www.cygnacom.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12601 for ietf-pkix-bks; Tue, 15 Sep 1998 10:46:56 -0700 (PDT) Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12597 for <ietf-pkix@imc.org>; Tue, 15 Sep 1998 10:46:55 -0700 (PDT) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA01587; Tue, 15 Sep 1998 10:50:19 -0700 (PDT) Received: from wford-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA14084; Tue, 15 Sep 1998 10:52:08 -0700 (PDT) Message-Id: <3.0.32.19980915134441.0129cf5c@mail.verisign.com> X-Sender: wford@mail.verisign.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 15 Sep 1998 13:52:32 -0700 To: ietf-pkix@imc.org From: Warwick Ford <wford@verisign.com> Subject: Schema Straw Poll Closure Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk Well, thank you all for the enthusiastic balloting and commenting. Steve and I have at last managed to synch up, and here is how we interpret the Straw Poll result. There was no clear concensus winner in either Option 1 or Option 2. There was significant support for both options, at least on the basis of installed product, plus various positions on technical grounds. We clearly need to accommodate the requirements of option 1 supporters by permitting the population of the cACertificate attribute with self-issued certificates and certificates issued by another CA to this CA within the context of a locally defined domain. In fairness to all, we feel we should also accommodate the requirement of option 2 supporters to have all certificates issued by CAs to this CA (which are placed in the subject CA entry at all), regardless of the definition of domain, populated in the crossCertificatePair attribute forward element. As secondary points, there appears to be consensus that population of the reverse element is always optional. Text regarding optional, mutual cross-certification also needs to be finalized but this will hopefully not be contentious. This resolution should allow relying parties to operate under either option successfully; the main negative in this resolution seems to be that, in option 1 environments, there would necessarily be some duplication of data in the directory. This essentially means a compromise that hopefully all parties can live with, although we know it will not go down in history as the most brilliant technical decision of all time. In the absence of violent objections, we propose that Sharon and Santosh jointly craft text that follows this resolution, and that we seek to close debate on this topic ASAP. Warwick --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006 wford@verisign.com; 301 Edgewater Pl, Suite 210, Wakefield, MA 01880 --------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11380 for ietf-pkix-bks; Tue, 15 Sep 1998 08:56:25 -0700 (PDT) Received: from firewall.globeset.com (root@firewall.globeset.com [207.239.133.67]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11376 for <ietf-pkix@imc.org>; Tue, 15 Sep 1998 08:56:24 -0700 (PDT) Received: from drought.globeset.com (trevor@drought.globeset.com [10.1.192.39]) by firewall.globeset.com (8.9.0/8.9.0) with ESMTP id LAA26296 for <ietf-pkix@imc.org>; Tue, 15 Sep 1998 11:02:08 -0500 (CDT) Received: (from trevor@localhost) by drought.globeset.com (8.7.6/8.7.3) id LAA27450; Tue, 15 Sep 1998 11:02:03 -0500 From: Trevor Sosebee <trevor@globeset.com> Date: Tue, 15 Sep 1998 11:02:01 -0500 (CDT) To: ietf-pkix@imc.org Subject: UTF8String definition in PKIX-3 X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13822.36613.678919.467432@drought> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@imc.org Precedence: bulk In PKIX-3, UTF8String is defined as UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING. I was wondering I someone could point me to the version of X.680 where UTF8String is defined. Thanks, Trevor Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA14487 for ietf-pkix-bks; Mon, 14 Sep 1998 21:23:34 -0700 (PDT) Received: from typhoon.dstc.qut.edu.au (root@typhoon.dstc.qut.edu.au [131.181.71.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA14482; Mon, 14 Sep 1998 21:23:30 -0700 (PDT) Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by typhoon.dstc.qut.edu.au (8.8.5/8.8.5) with ESMTP id OAA08287; Tue, 15 Sep 1998 14:29:04 +1000 (EST) Message-Id: <199809150429.OAA08287@typhoon.dstc.qut.edu.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Paul Hoffman / IMC <phoffman@imc.org> cc: ietf-pkix@imc.org Subject: Re: Testing the ASN.1 in Part 1 In-reply-to: Your message of "Mon, 14 Sep 1998 08:36:12 MST." <199809141530.IAA08890@mail.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Sep 1998 14:29:01 +1000 From: Dean Povey <povey@dstc.qut.edu.au> Sender: owner-ietf-pkix@imc.org Precedence: bulk >Anyone who plans to get around to checking the ASN.1 after part 1 becomes >an RFC: could you do it now instead? This would be a great help to us all. >Thanks! > *grr* I was putting this off :-) I am using the 88ish syntax PKIX1Explicit88 parses fine, but there are stuff ups in the imports in PKIX1Implicit88 To the IMPORTS section in PKIX1Implicit88 add the following: id-pkix, BMPString, UniversalString, UTF8String And delete the following two redundant definitions: id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } Other than that it looks like so far so good. I'll have to do some more work until this is fully tested. -- Dean Povey, | e-m: povey@dstc.edu.au | Cryptozilla: Research Scientist | ph: +61 7 3864 5120 | www.cryptozilla.org/ Security Unit, DSTC | fax: +61 7 3864 1282 | Oscar - PKI Toolkit: Brisbane, Australia | www: security.dstc.edu.au/ | oscar.dstc.qut.edu.au/ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09835 for ietf-pkix-bks; Mon, 14 Sep 1998 10:17:45 -0700 (PDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09830; Mon, 14 Sep 1998 10:17:43 -0700 (PDT) Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA43924; Mon, 14 Sep 1998 10:19:03 -0700 Received: from scv1.apple.com (scv1.apple.com) by mailgate.apple.com (mailgate.apple.com - SMTPRS 2.0.15) with ESMTP id <B0002256729@mailgate.apple.com>; Mon, 14 Sep 1998 10:18:56 -0700 Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.8.5/8.8.5) with ESMTP id KAA10684; Mon, 14 Sep 1998 10:18:55 -0700 Message-Id: <199809141718.KAA10684@scv1.apple.com> X-Mailer: Microsoft Outlook Express for Macintosh - 4.01 (295) Date: Mon, 14 Sep 1998 10:18:54 -0700 Subject: Re: Testing the ASN.1 in Part 1 From: "Aram Perez" <aram@apple.com> To: "Paul Hoffman / IMC" <phoffman@imc.org>, ietf-pkix@imc.org MIME-Version: 1.0 X-Priority: 3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Hi Paul, Check the web site of Open Systems Solutions (http://www.oss.com) They do free ASN.1 syntax checking for groups such as IETF. Regards, Aram Perez Apple Computer, Inc. >Greetings, all. I know that all this discussion of LDAP is fascinating, but >I'd like to come back to draft-ietf-pkix-ipki-part1 for a second. It is in >IESG last call, almost ready (we hope) to become an RFC. Tim has just made >minor tweaks to it (it is now -10.txt), and we're almost there. > >Has anyone tested the full ASN.1 in part 1 lately? Given the anti-ASN.1 >sentiment in the IETF, it would be Very Embarassing if we got an RFC and >had to revise it due to an ASN.1 error. Worse yet, it would be bad if there >was an error and two implementors did different things to get around it. > >Anyone who plans to get around to checking the ASN.1 after part 1 becomes >an RFC: could you do it now instead? This would be a great help to us all. >Thanks! > >--Paul Hoffman, Director >--Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09714 for ietf-pkix-bks; Mon, 14 Sep 1998 10:03:42 -0700 (PDT) Received: from atlantic.valicert.com (qmailr@old-atlantic.valicert.com [209.185.6.135]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA09709 for <ietf-pkix@imc.org>; Mon, 14 Sep 1998 10:03:41 -0700 (PDT) Received: (qmail 6298 invoked from network); 14 Sep 1998 17:09:19 -0000 Received: from ns.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 14 Sep 1998 17:09:19 -0000 Message-ID: <35FD4DD3.C7E6F4F4@valicert.com> Date: Mon, 14 Sep 1998 10:09:39 -0700 From: Ambarish Malpani <ambarish@valicert.com> Organization: ValiCert, Inc. X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Berger <aberger@darmstadt.gmd.de> CC: pkix <ietf-pkix@imc.org> Subject: Re: OCSP ASN.1 comments References: <35FD13B7.DE69F00D@darmstadt.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Hi Andreas, Thanks for the comment - it has already been fixed. Regards, Ambarish Andreas Berger wrote: > > Hi, > > I am forwarding here parts of a comment of Mr. Thomas Garnatz, Security > Networks GmbH: > > There is a context sensitive coding in ResponseData and ResponderID > > ResponseData ::= SEQUENCE { > version [0] EXPLICIT Version DEFAULT v1, > reponderID ResponderID, > ... > } > > ResponderID ::= CHOICE { > byName [0] Name, > byKey [1] KeyHash > } > > Since the version field is optional (i.e. not present for version 1) it > is not very easy to distinguish between version (explicit [0]) and > byName [0]. The suggested idea is to either remove the DEFAULT or not to > use [0] for byName. > > I hope I got the translation right and made some sense to the ASN.1 > gurus (myself not being one). > > Andreas Berger > -- > Fifty-three percent of Fortune 1000 executives think the > Arch Deluxe is something that helps to run a computer. > -- Jericho Communications -- --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 1215 Terra Bella Ave. http://www.valicert.com Mountain View, CA 94043-1833 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA08894 for ietf-pkix-bks; Mon, 14 Sep 1998 08:30:53 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA08890 for <ietf-pkix@imc.org>; Mon, 14 Sep 1998 08:30:52 -0700 (PDT) Message-Id: <199809141530.IAA08890@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 14 Sep 1998 08:36:12 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Testing the ASN.1 in Part 1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk Greetings, all. I know that all this discussion of LDAP is fascinating, but I'd like to come back to draft-ietf-pkix-ipki-part1 for a second. It is in IESG last call, almost ready (we hope) to become an RFC. Tim has just made minor tweaks to it (it is now -10.txt), and we're almost there. Has anyone tested the full ASN.1 in part 1 lately? Given the anti-ASN.1 sentiment in the IETF, it would be Very Embarassing if we got an RFC and had to revise it due to an ASN.1 error. Worse yet, it would be bad if there was an error and two implementors did different things to get around it. Anyone who plans to get around to checking the ASN.1 after part 1 becomes an RFC: could you do it now instead? This would be a great help to us all. Thanks! --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA07863 for ietf-pkix-bks; Mon, 14 Sep 1998 05:56:23 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA07859 for <ietf-pkix@imc.org>; Mon, 14 Sep 1998 05:56:15 -0700 (PDT) Received: from darmstadt.gmd.de (aberger@pc-turin [141.12.33.71]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id PAA27331 for <ietf-pkix@imc.org>; Mon, 14 Sep 1998 15:01:21 +0200 (MET DST) Message-ID: <35FD13B7.DE69F00D@darmstadt.gmd.de> Date: Mon, 14 Sep 1998 15:01:43 +0200 From: Andreas Berger <aberger@darmstadt.gmd.de> X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: pkix <ietf-pkix@imc.org> Subject: OCSP ASN.1 comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Hi, I am forwarding here parts of a comment of Mr. Thomas Garnatz, Security Networks GmbH: There is a context sensitive coding in ResponseData and ResponderID ResponseData ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, reponderID ResponderID, ... } ResponderID ::= CHOICE { byName [0] Name, byKey [1] KeyHash } Since the version field is optional (i.e. not present for version 1) it is not very easy to distinguish between version (explicit [0]) and byName [0]. The suggested idea is to either remove the DEFAULT or not to use [0] for byName. I hope I got the translation right and made some sense to the ASN.1 gurus (myself not being one). Andreas Berger -- Fifty-three percent of Fortune 1000 executives think the Arch Deluxe is something that helps to run a computer. -- Jericho Communications Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA06297 for ietf-pkix-bks; Sat, 12 Sep 1998 15:22:49 -0700 (PDT) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA06293 for <ietf-pkix@imc.org>; Sat, 12 Sep 1998 15:22:48 -0700 (PDT) Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id AAA01228; Sun, 13 Sep 1998 00:28:21 +0200 (CEST) Received: from stefans (t1o68p15.telia.com [62.20.138.15]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id AAA03222; Sun, 13 Sep 1998 00:28:10 +0200 (CEST) Message-Id: <3.0.32.19980913002508.00a62ae0@m1.403.telia.com> X-Sender: u40400192@m1.403.telia.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 13 Sep 1998 00:25:48 +0200 To: Mike Smith <mfsmith@zionsbank.com>, ietf-pkix@imc.org From: Stefan Santesson <stefan@accurata.se> Subject: Re: RE: New Extension Proposed: Method Of Authentication Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA06294 Sender: owner-ietf-pkix@imc.org Precedence: bulk Mike, First of all. I truly hope that I didn't offend you with my remark. I certainly didn't want that. Yes, the problem you raise is both real and relevant. I just don't share the same belief in automation through policy definition codings in certificate extensions. I do believe that it MAY work sufficient in a fairly closed environment where one organization has the control over interpretations and implementations. But international standard, no way. Actually I believe that the policy OID in certificates may serve automation just fine in real life. If trust automation is developing to be an competitive edge in a certain community, then CA:s will try to adopt to well known policies and indicate them in the certificates. So in that case there will just be a limited space of policy OID:s to consider. Whether this will happen or not is up to the market but the market sure has the tools needed if there is money to be made through interoperability. Over specifying things before the true need has emerged is always dangerous. And I'm sorry to say that we Europeans have some quite extensive experiences along that line. /Stefan At 10:11 AM 9/11/98 -0600, Mike Smith wrote: >OK, the quagmire consensus is taken for what it is. I first proposed enhancing automating some trust decisions using a new extension, then using the existing policy qualifier. The overwhelming response from people whose comments I respect is that we should consider the policy OID sufficient. > >If this is to be technological solution for automated processing, then we need to step backwards a few years and look at the definition of "to process" with regard to the actual CPS that the OID points towards. > >Maybe the old PKIX 1 needs to be restructured to retain its contents and menaing, but to specify a parsable structure and standardize (define rigidly) the terms used in the policies and practices or concept of operations (whatever people are using the OID to point towards). > >The goal here is not to reopen old wounds or pull people into yet another quagmire (my cletic genetics may predispose me to jumping inot bogs, however). The question that folks seem to be attemoting to address is the automation of trust domains. > >The feedback I get is not really "you are off track", but that "the problem is too big to solve", or that this group is incapable of solving this problem in a timely manner. > >I disagree. This group is comprised of the most experienced and, IMO, brightest technologists in the industry. > >So, I pose the question to the best and brightest: How do you suggest, then that we automate domain or trust processing? > >I think I know how we are going to operate across domains of trust in the finanical industry. I suggest that we in the IETF apply our great resources building AUTOMATED systems that have a high assurance of working together across the Internet. > >If, as some have suggested , I need to write a draft covering these issues, I am up for that (if Warwick and Stephen think it is worth the group's time). > >Michael > >>>> Stefan Santesson <stefan@accurata.se> 09/11 8:44 AM >>> >****************** InterScan Message (on zbc2) > >noname is scanned and no virus found >********************************************************* > ! >! > > > ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA06115 for ietf-pkix-bks; Sat, 12 Sep 1998 14:23:54 -0700 (PDT) Received: from mail.spyrus.com.au (fwuser@[203.37.128.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA06111 for <ietf-pkix@imc.org>; Sat, 12 Sep 1998 14:23:47 -0700 (PDT) Message-ID: <A1019E9C2D34D211A501006008C2045001BF66@MAIL> From: Charles Moore <cmoore@spyrus.com.au> To: "'Peter Lipp'" <Peter.Lipp@iaik.tu-graz.ac.at>, Paul Koning <pkoning@xedia.com>, mfsmith@zionsbank.com Cc: ietf-pkix@imc.org Subject: RE: RE: New Extension Proposed: Method Of Authentication Date: Sun, 13 Sep 1998 07:31:56 +1000 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk All, we ( Australian National Standards Group) have been working on a simular problem. I.e how does a relying party know what evidence of Identity that the RA/CA makes a statement about when performing the registration process. There are assocaited issues, but lets start with this one. We have a working draft that proposes the use of a policy qualifier as below: pkaf-policy-Identification CERT-POLICY-QUALIFIER ::= { POLICY-QUALIFIER-ID id-pkaf-policy-Identification QUALIFIER-TYPE Identification } Identification ::= BIT STRING { driversLicense (0), passport (1), creditCard (2), organisationIDBadge (3), governmentIDBadge (4), articlesOfIncorp (5), companySeal (6), notarizedDoc (7), biometricThumb (8), biometricVoice (9), biometricFace (10), biometricRetina (11) } We have not used A CP ( or any reference to a CPS) alone to do this as experience is that within a given policy there is no direct mapping to the level of identification needed. Identification is not the driver for a CP or CPS, but rather a qualifier of these. Hope this assists the discussion. Regards Charles Moore SPYRUS Pty Ltd Phone: +61 73 256 7465, Extension 101 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA23955 for ietf-pkix-bks; Fri, 11 Sep 1998 12:52:46 -0700 (PDT) Received: from iaik.tu-graz.ac.at (archimedes.iaik.tu-graz.ac.at [129.27.234.31]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA23951 for <ietf-pkix@imc.org>; Fri, 11 Sep 1998 12:52:44 -0700 (PDT) Received: from plipp [129.27.239.102] by iaik.tu-graz.ac.at (SMTPD32-4.06) id A0D22800C6; Fri, 11 Sep 1998 21:58:10 +03d00 From: "Peter Lipp" <Peter.Lipp@iaik.tu-graz.ac.at> To: "Paul Koning" <pkoning@xedia.com>, <mfsmith@zionsbank.com> Cc: <ietf-pkix@imc.org> Subject: RE: RE: New Extension Proposed: Method Of Authentication Date: Fri, 11 Sep 1998 21:59:08 +0200 Message-ID: <000001bdddbe$a311f630$0a03a8c0@plipp.iaik.tu-graz.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <199809111807.OAA28256@tonga.xedia.com> Sender: owner-ietf-pkix@imc.org Precedence: bulk > I very much doubt that a mapping from natural language legal > terminology to formal logic will be defined anytime in the next 10 > years. Come to think of it, thinking of Goedel makes me wonder if > it's even theoretically possible. But that would not be necessary. I could well imagine defining a set of attributes describing the most important elements of such statements like ... passport needed .... ... anything that looks like an ID with photo sufficient ... ... we don't check anything at all .... or things like that. The problem I see is in all cases the trust into the truthfulness of such statements - it does not help anybody if my machine can verify that indeed the CA claims to having seen a passport if I don't trust the CA not to lie in the first place. This needs checks by myself or trusted representatives in any case, and no formal logic will help. Peter Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23179 for ietf-pkix-bks; Fri, 11 Sep 1998 11:32:59 -0700 (PDT) Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA23175 for <ietf-pkix@imc.org>; Fri, 11 Sep 1998 11:32:58 -0700 (PDT) Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Fri, 11 Sep 1998 12:33:29 -0600 Message-Id: <s5f91899.098@zionsbank.com> X-Mailer: Novell GroupWise 4.1 Date: Fri, 11 Sep 1998 12:33:22 -0600 From: Mike Smith <mfsmith@zionsbank.com> To: pkoning@xedia.com Cc: stefan@accurata.se, ietf-pkix@imc.org Subject: Re: RE: New Extension Proposed: Method Of Authentication Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk I think you've got it. As far as being ahead of state of the art, I've been in meetings with many of the folks on this list several years ago when the same issues of parsing the CPS in order to automate were brought up. By the way, I was not suggesting parsing a free-form CPS, but structuring the CPS for automated processing, which might need then both a human and machine readable form or sections of the same CPS. The saying goes (Warren Miller, Ski Film producer): "If you don't do it now, You'll only be another year older when you do". Michael >>> Paul Koning <pkoning@xedia.com> 09/11 12:07 PM >>> >>>>> "Mike" == Mike Smith <mfsmith@zionsbank.com> writes: Mike> ...Maybe the old PKIX 1 needs to be restructured to retain its Mike> contents and menaing, but to specify a parsable structure and Mike> standardize (define rigidly) the terms used in the policies and Mike> practices or concept of operations (whatever people are using Mike> the OID to point towards). Mike> ...The feedback I get is not really "you are off track", but that Mike> "the problem is too big to solve", or that this group is Mike> incapable of solving this problem in a timely manner. Mike> I disagree. This group is comprised of the most experienced Mike> and, IMO, brightest technologists in the industry. Mike> So, I pose the question to the best and brightest: How do you Mike> suggest, then that we automate domain or trust processing? I think the question you pose is not a little, but vastly beyond the state of the art. As I understand it, the goal you're posing is: define a way for the CA to encode into the cert information that the relying party can use to decide whether the subject of that cert was authenticated by means strong enough to be satisfactory to the relying party. A somewhat analogous question (though not applicable to a particular cert) is whether the CA's CPS is strong enough for the relying party. It seems to me that this latter question is one you drop onto your company's lawyer to settle. It involves parsing natural language (well, anyway, legal language) to see what it means, and whether that meaning is satisfactory to your corporate requirements. I very much doubt that a mapping from natural language legal terminology to formal logic will be defined anytime in the next 10 years. Come to think of it, thinking of Goedel makes me wonder if it's even theoretically possible. The above would seem to be just as applicable to the cert subject authentication statement as it is to the CPS. After all, the authentication used in creating a particular cert is basically just the application of the CPS to that particular subject. paul Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA22902 for ietf-pkix-bks; Fri, 11 Sep 1998 11:03:49 -0700 (PDT) Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22898 for <ietf-pkix@imc.org>; Fri, 11 Sep 1998 11:03:48 -0700 (PDT) Received: from xedia.com by relay3.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfgke24932; Fri, 11 Sep 1998 14:07:44 -0400 (EDT) Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26501; Fri, 11 Sep 98 14:06:53 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA28256; Fri, 11 Sep 1998 14:07:42 -0400 Date: Fri, 11 Sep 1998 14:07:42 -0400 Message-Id: <199809111807.OAA28256@tonga.xedia.com> From: Paul Koning <pkoning@xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mfsmith@zionsbank.com Cc: stefan@accurata.se, ietf-pkix@imc.org Subject: Re: RE: New Extension Proposed: Method Of Authentication References: <s5f8f745.021@zionsbank.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-pkix@imc.org Precedence: bulk >>>>> "Mike" == Mike Smith <mfsmith@zionsbank.com> writes: Mike> ...Maybe the old PKIX 1 needs to be restructured to retain its Mike> contents and menaing, but to specify a parsable structure and Mike> standardize (define rigidly) the terms used in the policies and Mike> practices or concept of operations (whatever people are using Mike> the OID to point towards). Mike> ...The feedback I get is not really "you are off track", but that Mike> "the problem is too big to solve", or that this group is Mike> incapable of solving this problem in a timely manner. Mike> I disagree. This group is comprised of the most experienced Mike> and, IMO, brightest technologists in the industry. Mike> So, I pose the question to the best and brightest: How do you Mike> suggest, then that we automate domain or trust processing? I think the question you pose is not a little, but vastly beyond the state of the art. As I understand it, the goal you're posing is: define a way for the CA to encode into the cert information that the relying party can use to decide whether the subject of that cert was authenticated by means strong enough to be satisfactory to the relying party. A somewhat analogous question (though not applicable to a particular cert) is whether the CA's CPS is strong enough for the relying party. It seems to me that this latter question is one you drop onto your company's lawyer to settle. It involves parsing natural language (well, anyway, legal language) to see what it means, and whether that meaning is satisfactory to your corporate requirements. I very much doubt that a mapping from natural language legal terminology to formal logic will be defined anytime in the next 10 years. Come to think of it, thinking of Goedel makes me wonder if it's even theoretically possible. The above would seem to be just as applicable to the cert subject authentication statement as it is to the CPS. After all, the authentication used in creating a particular cert is basically just the application of the CPS to that particular subject. paul Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA22010 for ietf-pkix-bks; Fri, 11 Sep 1998 09:16:19 -0700 (PDT) Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA22006 for <ietf-pkix@imc.org>; Fri, 11 Sep 1998 09:16:18 -0700 (PDT) Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Fri, 11 Sep 1998 10:16:48 -0600 Message-Id: <s5f8f890.088@zionsbank.com> X-Mailer: Novell GroupWise 4.1 Date: Fri, 11 Sep 1998 10:16:37 -0600 From: Mike Smith <mfsmith@zionsbank.com> To: stefan@accurata.se, ietf-pkix@imc.org Subject: Re: RE: New Extension Proposed: Method Of Authentication Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk OK, the quagmire consensus is taken for what it is. I first proposed automating some trust decisions using a new extension, then using the existing policy qualifier. The overwhelming response from people whose comments I respect is that we should consider the policy OID sufficient. If this is to be the technological solution for automated processing, then we need to step backwards a few years and look at the definition of "to process" with regard to the actual CPS that the OID points towards. Maybe the old PKIX 1 needs to be restructured to retain its contents and meaning, but to specify a parsable structure and standardize (define rigidly) the terms used in the policies , practices or concept of operations (whatever people are using the OID to point towards). The goal here is not to reopen old wounds or pull people into yet another quagmire (my Celtic genetics may predispose me to jumping inot bogs, however). The question that folks seem to be attempting to address is the automation of trust domains. The feedback I get is not really "you are off track", but that "the problem is too big to solve", or that this group is incapable of solving this problem in a timely manner. I disagree. This group is comprised of the most experienced and, IMO, brightest technologists in the industry. So, I pose the question to the best and brightest: How do you suggest, then, that we automate domain or trust processing? I think I know how we are going to operate across domains of trust in the finanical industry. I suggest that we in the IETF apply our great resources building AUTOMATED systems that have a high assurance of working together across the Internet. If, as some have suggested , I need to write a draft covering these issues, I am up for that (if Warwick and Stephen think it is worth the group's time). Michael >>> Stefan Santesson <stefan@accurata.se> 09/11 8:44 AM >>> ****************** InterScan Message (on zbc2) noname is scanned and no virus found ********************************************************* Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21953 for ietf-pkix-bks; Fri, 11 Sep 1998 09:10:26 -0700 (PDT) Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA21948 for <ietf-pkix@imc.org>; Fri, 11 Sep 1998 09:10:25 -0700 (PDT) Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Fri, 11 Sep 1998 10:11:17 -0600 Message-Id: <s5f8f745.021@zionsbank.com> X-Mailer: Novell GroupWise 4.1 Date: Fri, 11 Sep 1998 10:11:04 -0600 From: Mike Smith <mfsmith@zionsbank.com> To: stefan@accurata.se, ietf-pkix@imc.org Subject: Re: RE: New Extension Proposed: Method Of Authentication Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk OK, the quagmire consensus is taken for what it is. I first proposed enhancing automating some trust decisions using a new extension, then using the existing policy qualifier. The overwhelming response from people whose comments I respect is that we should consider the policy OID sufficient. If this is to be technological solution for automated processing, then we need to step backwards a few years and look at the definition of "to process" with regard to the actual CPS that the OID points towards. Maybe the old PKIX 1 needs to be restructured to retain its contents and menaing, but to specify a parsable structure and standardize (define rigidly) the terms used in the policies and practices or concept of operations (whatever people are using the OID to point towards). The goal here is not to reopen old wounds or pull people into yet another quagmire (my cletic genetics may predispose me to jumping inot bogs, however). The question that folks seem to be attemoting to address is the automation of trust domains. The feedback I get is not really "you are off track", but that "the problem is too big to solve", or that this group is incapable of solving this problem in a timely manner. I disagree. This group is comprised of the most experienced and, IMO, brightest technologists in the industry. So, I pose the question to the best and brightest: How do you suggest, then that we automate domain or trust processing? I think I know how we are going to operate across domains of trust in the finanical industry. I suggest that we in the IETF apply our great resources building AUTOMATED systems that have a high assurance of working together across the Internet. If, as some have suggested , I need to write a draft covering these issues, I am up for that (if Warwick and Stephen think it is worth the group's time). Michael >>> Stefan Santesson <stefan@accurata.se> 09/11 8:44 AM >>> ****************** InterScan Message (on zbc2) noname is scanned and no virus found ********************************************************* Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21226 for ietf-pkix-bks; Fri, 11 Sep 1998 08:01:51 -0700 (PDT) Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA21222 for <ietf-pkix@imc.org>; Fri, 11 Sep 1998 08:01:49 -0700 (PDT) Received: from chromatix.com (whiteoak.chromatix.com [207.97.115.5]) by chromatix.com (8.8.8/8.8.8) with ESMTP id LAA27778; Fri, 11 Sep 1998 11:05:58 -0400 (EDT) (envelope-from dave@chromatix.com) Message-ID: <35F93C79.E50E1015@chromatix.com> Date: Fri, 11 Sep 1998 11:06:33 -0400 From: Dave Horvath <dave@chromatix.com> Organization: Chromatix Inc. X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX B.10.20 9000/780) MIME-Version: 1.0 To: Denis.Pinkas@bull.net CC: Santosh Chokhani <chokhani@cygnacom.com>, "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: Re: forward & reverse elements - population References: <51BF55C30B4FD1118B4900207812701E1B1A60@WUHER> <35F96A8E.6C3A@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Dennis, See comments below. Denis Pinkas wrote: > > Santosh, > > Here is my answer to your question. > > > Denis: > > > I agree with you. Clarification of the text is easy. > > ??? > > > However, I have a > > question. Must a certificate issued to a CA appear in the forward > > element, caCertificate or can it be missing altogether? > > "MUST" is the wrong verb. A certificate issued by another CA is not > mandated to be present at all. It MAY be present. > > Let me now re-phrase your question: May a certificate issued to a CA by > another CA appear in the forward element, caCertificate or can it be > missing altogether? > > My answer is the following: It may only appear in the forward element of > a crossCertificatePair. > > I was quite happy (and still am I !) with the original text. I still > wonder with the rational of the two buckets. > The problem with the original text is that it breaks the implementations that used the certificationAuthority-V2 object class. That object class stated the caCertificate was mandatory. This has been established and accepted, therefore the original text is not an option anymore. We have heard arguments from both sides for option 1 and option 2. Each of which have their own pros and cons. I suggest we stick with those two options and move forward. Furthermore, Santosh has submitted strong technical arguments for the two bucket approach. The two bucket approach allows you to logically distinguish between two types of CA Certs without mandating that a CA define its policies with respect to bucket population. If the CA publishes it in the "wrong" bucket it will NOT compromise security and it will NOT cause a denial of service, as long as clients look at both attributes. It lead to inefficient path construction in the worst case, but that's a given if you have a one bucket approach. Another issue is the duplication of certificates. After profiling at least one directory server we know that performance degrades after an entry reaches a certain size. In other words you can usually get excellent sub second response time out of a server ( in fact many responses per second ) if the entry stays small. As the entry grows in size, the response gets slower. We have tested with entries up to several megabytes in size and have proved this. Additionally, many companies still use small pipes for their network infrastructure, and those pipes can be easily saturated. We should make a conscious decision to attempt to minimize the amount of data a client will retrieve from a single entry while satisfying both option 1 and option 2 proponents. > Up to now, none of the arguments about the notion of "local domain" has > proven to be non-controversy. If the notion of local domain is important > (I still wonder about it), there might be a different way to look at the > issue. LDAPv2 allows to query any server that offers that interface, so > different set of queries could be considered: > > 1) Queries made to one or more local domain servers, > 2) Queries made to one or more public domain servers. > > As the name indicates it, local domain servers may not be publicly > accessible, e.g. protected by firewalls or some other access control > methods. Local domain servers would publish only what is relevant for > their notion of local domain. They must publish everything that is > relevant. > > Public domain servers would have no notion of "local domain". They must > publish everything certificate that is pertinent to a CA entry that they > publish. If entries for CA1, CA4 and CA5 are present, then all > certificates issued by these CAs must be present and all > cross-certificates, if any, between these CAs must also be present. > However, a cross-certificate issued by the CA 7 for the CA 1 would not > need to be present. Are you saying the schema/or the DIT structure will be different for a CA in a public directory vs a private directory? If so, I think we are going down a dangerous path. Given a globally unique DN why would you want to do this? Dave Horvath > > Denis > > > I think the text in terms of saying that the forward element need not be > > present in all cases is easy. > > > > > -----Original Message----- > > > From: Denis Pinkas [SMTP:Denis.Pinkas@bull.net] > > > Sent: Wednesday, September 09, 1998 8:44 PM > > > To: Santosh Chokhani > > > Cc: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > > Subject: Re: forward & reverse elements - population > > > > > > Santosh, > > > > > > Your new proposed text does not address my concern correctly. > > > > > > For a crossCertificatePair Attribute, either the forward element only > > > MAY be present, or the reverse element only MAY be present, or the > > > reverse and the forward elements may be both present. > > > > > > Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward > > > element > > > shall not be mandated to be present in a crossCertificatePair > > > Attribute. > > > > > > Denis > > > > > > > Sharon: > > > > > > > I can agree to the following text for the two option instead. > > > Please > > > > note that I have further clarified cross-certificate by tying the DN > > > and > > > > public keys. > > > > > > > > I think the following texts are consistent with and further > > > > clarifications of the two options. > > > > > > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1. > > > > > > > > NEW PROPOSED TEXT FOR OPTION 1 > > > > > > > > The cACertificate attribute, held in a particular CA's directory > > > entry, > > > > shall be used to store certificates issued to this CA by CAs in the > > > same > > > > domain as this CA. > > > > > > > > The forward element of the crossCertificatePair attribute, held in a > > > > particular CA's directory entry, shall be used to store certificates > > > > issued to this CA by CAs in other domains. Optionally, the reverse > > > > element of the crossCertificatePair attribute, held in a particular > > > CA's > > > > directory entry, may contain a subset of certificates issued by this > > > CA > > > > to other CAs. When both the forward and the reverse elements are > > > > present, issuer name in one certificate shall match the subject name > > > in > > > > the other and vice versa, and the subject public key in one > > > certificate > > > > shall be capable of verifying the digital signature on the other > > > > certificate and vice versa. > > > > > > > > In the case of V3 certificates, none of the above CA certificates > > > shall > > > > include a basicConstraints extension with the cA value set to FALSE. > > > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > > NEW PROPOSED TEXT FOR OPTION 2 > > > > > > > > The cACertificate attribute, held in a particular CA's directory > > > entry, > > > > shall be used to store certificates issued to this CA by CAs in the > > > same > > > > domain as this CA. > > > > > > > > The forward element of the crossCertificatePair attribute, held in a > > > > particular CA's directory entry, shall be used to store all > > > certificates > > > > issued to this CA. Optionally, the reverse element of the > > > > crossCertificatePair attribute, held in a particular CA's directory > > > > entry, may contain a subset of certificates issued by this CA to > > > other > > > > CAs. When both the forward and the reverse elements are present, > > > issuer > > > > name in one certificate shall match the subject name in the other > > > and > > > > vice versa, and the subject public key in one certificate shall be > > > > capable of verifying the digital signature on the other certificate > > > and > > > > vice versa. > > > > > > > > In the case of V3 certificates, none of the above CA certificates > > > shall > > > > include a basicConstraints extension with the cA value set to FALSE. > > > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > > > -----Original Message----- > > > > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > > > > Sent: Tuesday, September 08, 1998 5:46 PM > > > > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > > > > > > > > > > > > ---------- > > > > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > > > > Sent: September 8, 1998 10:05 AM > > > > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > > --stuff deleted > > > > > > > > > > > > > [] I agree. I do not have problem with the following > > > language. > > > > > > " A certificate issued to a CA by another shall be stored either > > > in > > > > > the > > > > > > caCertificate or forward component of crossCertificatePair > > > attribute > > > > > of > > > > > > the subject CA. Optionally, a subset of certificates issued by > > > a CA > > > > > can > > > > > > be stored in the reverse component of crossCertificatePair > > > attribute > > > > > of > > > > > > the issuing CA." > > > > > > > > > > > > Please note that to me subset includes none, some, or all. > > > If > > > > > > folks want further clarification, it is ok by me. > > > > > > > > > > > Santosh, the only issue I have with this text is that (at least > > > with > > > > > the > > > > > rationale behind option 2) any cert that appears in the > > > cACertificate > > > > > attribute of a given CA > > > > > entry, should also appear in the crossCertificatePair attribute in > > > the > > > > > same > > > > > CA entry. > > > > > What about deleting the reference to the cACertificate attribute > > > from > > > > > your > > > > > text and proposing this as new text just for the > > > crossCertificatePair > > > > > attribute? > > > > > > > > > > Both Jan and David have indicated reasons to keep the "pair" > > > together > > > > > in the > > > > > mutual case, so we should also consider adding the last paragraph > > > of > > > > > the > > > > > text David proposed for that. > > > > > > > > > > Here's what the resulting text proposal would look like: > > > > > > > > > > > " A certificate issued to a CA by another shall be stored in the > > > > > > forward component of crossCertificatePair attribute of > > > > > > the subject CA. Optionally, a subset of certificates issued by > > > a CA > > > > > can > > > > > > be stored in the reverse component of crossCertificatePair > > > attribute > > > > > of > > > > > > the issuing CA. When both elements are present in the same > > > value, > > > > > the > > > > > > value shall represent a mutual cross-certification of the two > > > CAs. " > > > > > > > > > > > If we can come to consensus on that attribute, then let's see what > > > we > > > > > can do > > > > > with the cACertificate attribute text. > > > > > > > > > > I agree with your view on what a subset is and I think that same > > > > > definition > > > > > would apply to the contents of the cACertificate attribute as a > > > subset > > > > > of > > > > > the crossCertificatePair forward elements in option 2. > > > > > > -- > > > Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net > > > Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 > > > 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 > > -- > Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net > Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 > 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 -- ================================================ _/_/_/ David J. Horvath _/ _/ _/ _/ Chromatix, Inc. _/ _/ _/ 10451 Twin Rivers Road, Suite 265 _/ _/_/ Columbia, MD 21044 _/ _/ _/_/ Phone: (301) 596-8466 | http://www.chromatix.com _/_/_/ _/ _/ Fax: (410) 997-4306 | dave@chromatix.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA21102 for ietf-pkix-bks; Fri, 11 Sep 1998 07:41:23 -0700 (PDT) Received: from mailc.telia.com (root@mailc.telia.com [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA21098 for <ietf-pkix@imc.org>; Fri, 11 Sep 1998 07:41:22 -0700 (PDT) Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id QAA00126 for <ietf-pkix@imc.org>; Fri, 11 Sep 1998 16:46:47 +0200 (MET DST) Received: from stefans (t2o68p33.telia.com [62.20.138.153]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id QAA11065 for <ietf-pkix@imc.org>; Fri, 11 Sep 1998 16:46:46 +0200 (CEST) Message-Id: <3.0.32.19980911164344.00996d60@m1.403.telia.com> X-Sender: u40400192@m1.403.telia.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 11 Sep 1998 16:44:21 +0200 To: <ietf-pkix@imc.org> From: Stefan Santesson <stefan@accurata.se> Subject: RE: New Extension Proposed: Method Of Authentication Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA21099 Sender: owner-ietf-pkix@imc.org Precedence: bulk This is really fascinating. When I read the proposal for a new extension I said to my self: Good this man i brave. I wonder how many seconds he will live before he is gunned down. Not because the idea is stupid. Just because of the obvious "quagmire" syndrome. I have recently studied one extensive trial to specify such extensions and I just want to join to the consensus here. - This is a quagmire and not suited for standardization (at least not within PKIX). - The policy OID solves the problem as far needed. And according to changing CPS:es. One CPS may change many times as long as it reflects the same policy. If security drops below policy requirements then a new policy OID has to be identified. So minimum security level is defined by policy and not by CPS. /Stefan At 01:48 PM 9/10/98 -0400, Phillip M Hallam-Baker wrote: > >> If we have standard identifiers, one byte each, provides 0 to 255 >> specific categories, with say, ten as internet standards. >> >> With initial authentication method, maybe we start with (decimal): >> 0 as anonymous, >> 1 as self-authenticated, >> 2 as driver license or government ID card >> 3 as passport >> 4 as military > >This is heading straight into the quagmire I spoke about... > >Decimal numbers is just about the worst approach since it means that >a central registry has to be kept - yet another task for IANA! and >the arbitrary limit of 255 sounds guaranteed to ensure that the >namespace will quickly become cluttered with ad hoc private >definitions being used on an 'experimental' basis. > >I don't see any value in the taxonomy presented. What is a 'military' >identification method? Is identification by the US army equivalent to >that of the Taleban in Afghanistan? > >The drivers license is particularly dubious. My UK drivers license >has no photograph and is valid until sometime after 2020. > >Are there CAs who actually want to specify their exact authorization >processes? Are such processes objectively definable? A commercial >CA does not define authorization procedures for every concievable >document they might accept in their CPS. The first time a US CA >decides on acceptable forms of authentication for a Monaco >corporation is likely to be when they get a purchase request. > > >If you want to take the matter further I suggest you write an >Internet Draft and see if the working group chairs want to >make it a work item. > > Phill > > ------------------------------------------------------------------- Stefan Santesson <stefan@accurata.se> Accurata Systemsäkerhet AB Lotsgatan 27 D Tel. +46-40 152211 216 42 Malmö Fax. +46-40 150790 Sweden Mobile +46-70 5247799 PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0 ------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16901 for ietf-pkix-bks; Fri, 11 Sep 1998 02:16:50 -0700 (PDT) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16896 for <ietf-pkix@imc.org>; Fri, 11 Sep 1998 02:16:46 -0700 (PDT) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id LAA13435; Fri, 11 Sep 1998 11:23:50 +0200 Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id LAA15724; Fri, 11 Sep 1998 11:23:51 +0200 (DFT) Message-ID: <35F96A8E.6C3A@bull.net> Date: Fri, 11 Sep 1998 11:23:10 -0700 From: Denis Pinkas <Denis.Pinkas@bull.net> Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) MIME-Version: 1.0 To: Santosh Chokhani <chokhani@cygnacom.com> CC: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: Re: forward & reverse elements - population References: <51BF55C30B4FD1118B4900207812701E1B1A60@WUHER> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Santosh, Here is my answer to your question. > Denis: > I agree with you. Clarification of the text is easy. ??? > However, I have a > question. Must a certificate issued to a CA appear in the forward > element, caCertificate or can it be missing altogether? "MUST" is the wrong verb. A certificate issued by another CA is not mandated to be present at all. It MAY be present. Let me now re-phrase your question: May a certificate issued to a CA by another CA appear in the forward element, caCertificate or can it be missing altogether? My answer is the following: It may only appear in the forward element of a crossCertificatePair. I was quite happy (and still am I !) with the original text. I still wonder with the rational of the two buckets. Up to now, none of the arguments about the notion of "local domain" has proven to be non-controversy. If the notion of local domain is important (I still wonder about it), there might be a different way to look at the issue. LDAPv2 allows to query any server that offers that interface, so different set of queries could be considered: 1) Queries made to one or more local domain servers, 2) Queries made to one or more public domain servers. As the name indicates it, local domain servers may not be publicly accessible, e.g. protected by firewalls or some other access control methods. Local domain servers would publish only what is relevant for their notion of local domain. They must publish everything that is relevant. Public domain servers would have no notion of "local domain". They must publish everything certificate that is pertinent to a CA entry that they publish. If entries for CA1, CA4 and CA5 are present, then all certificates issued by these CAs must be present and all cross-certificates, if any, between these CAs must also be present. However, a cross-certificate issued by the CA 7 for the CA 1 would not need to be present. Denis > I think the text in terms of saying that the forward element need not be > present in all cases is easy. > > > -----Original Message----- > > From: Denis Pinkas [SMTP:Denis.Pinkas@bull.net] > > Sent: Wednesday, September 09, 1998 8:44 PM > > To: Santosh Chokhani > > Cc: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > Subject: Re: forward & reverse elements - population > > > > Santosh, > > > > Your new proposed text does not address my concern correctly. > > > > For a crossCertificatePair Attribute, either the forward element only > > MAY be present, or the reverse element only MAY be present, or the > > reverse and the forward elements may be both present. > > > > Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward > > element > > shall not be mandated to be present in a crossCertificatePair > > Attribute. > > > > Denis > > > > > Sharon: > > > > > I can agree to the following text for the two option instead. > > Please > > > note that I have further clarified cross-certificate by tying the DN > > and > > > public keys. > > > > > > I think the following texts are consistent with and further > > > clarifications of the two options. > > > > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1. > > > > > > NEW PROPOSED TEXT FOR OPTION 1 > > > > > > The cACertificate attribute, held in a particular CA's directory > > entry, > > > shall be used to store certificates issued to this CA by CAs in the > > same > > > domain as this CA. > > > > > > The forward element of the crossCertificatePair attribute, held in a > > > particular CA's directory entry, shall be used to store certificates > > > issued to this CA by CAs in other domains. Optionally, the reverse > > > element of the crossCertificatePair attribute, held in a particular > > CA's > > > directory entry, may contain a subset of certificates issued by this > > CA > > > to other CAs. When both the forward and the reverse elements are > > > present, issuer name in one certificate shall match the subject name > > in > > > the other and vice versa, and the subject public key in one > > certificate > > > shall be capable of verifying the digital signature on the other > > > certificate and vice versa. > > > > > > In the case of V3 certificates, none of the above CA certificates > > shall > > > include a basicConstraints extension with the cA value set to FALSE. > > > > > > The definition of domain is purely a matter of local policy. > > > > > > NEW PROPOSED TEXT FOR OPTION 2 > > > > > > The cACertificate attribute, held in a particular CA's directory > > entry, > > > shall be used to store certificates issued to this CA by CAs in the > > same > > > domain as this CA. > > > > > > The forward element of the crossCertificatePair attribute, held in a > > > particular CA's directory entry, shall be used to store all > > certificates > > > issued to this CA. Optionally, the reverse element of the > > > crossCertificatePair attribute, held in a particular CA's directory > > > entry, may contain a subset of certificates issued by this CA to > > other > > > CAs. When both the forward and the reverse elements are present, > > issuer > > > name in one certificate shall match the subject name in the other > > and > > > vice versa, and the subject public key in one certificate shall be > > > capable of verifying the digital signature on the other certificate > > and > > > vice versa. > > > > > > In the case of V3 certificates, none of the above CA certificates > > shall > > > include a basicConstraints extension with the cA value set to FALSE. > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > -----Original Message----- > > > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > > > Sent: Tuesday, September 08, 1998 5:46 PM > > > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > > > > > > > > ---------- > > > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > > > Sent: September 8, 1998 10:05 AM > > > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > --stuff deleted > > > > > > > > > > > [] I agree. I do not have problem with the following > > language. > > > > > " A certificate issued to a CA by another shall be stored either > > in > > > > the > > > > > caCertificate or forward component of crossCertificatePair > > attribute > > > > of > > > > > the subject CA. Optionally, a subset of certificates issued by > > a CA > > > > can > > > > > be stored in the reverse component of crossCertificatePair > > attribute > > > > of > > > > > the issuing CA." > > > > > > > > > > Please note that to me subset includes none, some, or all. > > If > > > > > folks want further clarification, it is ok by me. > > > > > > > > > Santosh, the only issue I have with this text is that (at least > > with > > > > the > > > > rationale behind option 2) any cert that appears in the > > cACertificate > > > > attribute of a given CA > > > > entry, should also appear in the crossCertificatePair attribute in > > the > > > > same > > > > CA entry. > > > > What about deleting the reference to the cACertificate attribute > > from > > > > your > > > > text and proposing this as new text just for the > > crossCertificatePair > > > > attribute? > > > > > > > > Both Jan and David have indicated reasons to keep the "pair" > > together > > > > in the > > > > mutual case, so we should also consider adding the last paragraph > > of > > > > the > > > > text David proposed for that. > > > > > > > > Here's what the resulting text proposal would look like: > > > > > > > > > " A certificate issued to a CA by another shall be stored in the > > > > > forward component of crossCertificatePair attribute of > > > > > the subject CA. Optionally, a subset of certificates issued by > > a CA > > > > can > > > > > be stored in the reverse component of crossCertificatePair > > attribute > > > > of > > > > > the issuing CA. When both elements are present in the same > > value, > > > > the > > > > > value shall represent a mutual cross-certification of the two > > CAs. " > > > > > > > > > If we can come to consensus on that attribute, then let's see what > > we > > > > can do > > > > with the cACertificate attribute text. > > > > > > > > I agree with your view on what a subset is and I think that same > > > > definition > > > > would apply to the contents of the cACertificate attribute as a > > subset > > > > of > > > > the crossCertificatePair forward elements in option 2. > > > > -- > > Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net > > Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 > > 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA15497 for ietf-pkix-bks; Fri, 11 Sep 1998 00:54:12 -0700 (PDT) Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA15489 for <ietf-pkix@imc.org>; Fri, 11 Sep 1998 00:54:09 -0700 (PDT) Message-Id: <199809110919.KAA08686@ns0.zergo.com> Received: forwarded by SMTP 3.0.6. From: Graham Bland <gbland@zergo.com> Date: Fri, 11 Sep 1998 8:49:49 +0000 To: ietf-pkix@imc.org Subject: RE: RE: New Extension Proposed: Method O MIME-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: TFS Gateway /222000000/222041752/222002972/223090911/ Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id AAA15493 Sender: owner-ietf-pkix@imc.org Precedence: bulk I think this is impossible to achieve for the following reasons 1. 255 categories would be far too few, in practice they would expand to thousands. 2. With each category there are wide variations, drivers licences for example contain different details, have different validity periods, some have photos, some don't and they are issued by Governments (some of whom I would not trust). Are photocopies acceptable? Must the driving licence be presented in person or can it be posted? Need it be current? All these have a substantial bearing on the degree of trust I can place in a certificate. 3. It would take us years to agree on the categories and the meanings For these reasons this could not replace a CPS. Graham Bland > -----Original Message----- > From: mfsmith@zionsbank.com > Sent: 10 September 1998 18:06 > To: Ian Roberts; Graham Bland; Chris Wright; chokhani@cygnacom.com; > azb@llnl.gov; william.burr@nist.gov; BJUENEMAN@novell.com; > pbaker@verisign.com > Cc: ietf-pkix@imc.org > Subject: Re: RE: New Extension Proposed: Method O > > > -------------------------------------------------------------- > -------------- > Maybe "new" extension is too strong a phrase. How about > defining the policy > qulifiers to have some standard" meanings, then: > > reliance limit > licensure, licensing body > authentication method > etc. > > If we have standard identifiers, one byte each, provides 0 to > 255 specific > categories, with say, ten as internet standards. > > With initial authentication method, maybe we start with (decimal): > 0 as anonymous, > 1 as self-authenticated, > 2 as driver license or government ID card > 3 as passport > 4 as military > > then start with combinations including common attributes, > such as credit > bureau rating as of issuance, etc. > > I do understand that, while policy OIDs may be supported some largely > deployed systems do not support the policy qualifiers, but > the standards do, > so why don't we use them to improve our automation needs. > Any time we need > to rely on individ > uals obtaining, reading and being held accountable to a two > hundred page > contract (CPS), we limit its usability. > > Having standard definitions for the most common usages and > having these > signed as part of the cert by the issuer should facilitate > automatic policy > acceptance across those domains with multiple policies (if I > have accepted > all of the Verisig > n roots, then all of the categories of authentication are > accepted. If each > cert has the main characteristics of trust (initial authentication, CA > licensure, reliance liits, CPS location/OID, etc.), then I > should be able to > set my acceptanc > e on user selected criteria, > without re-reading the two hundred pages of each of the CAs > my company does > business with. > > Michael > > >>> Santosh Chokhani <chokhani@cygnacom.com> 09/09 1:25 PM >>> > The certificate policy is supposed to the represented in the > certificate > as an object identifier. The amendment to X.509 defines how the > applications process that field to determine if a certificate is > acceptable, including certificate policy and associated authentication > mechanism. > > X.509 amendment offer a rich set of capabilities in this area in terms > of what goes in a certificate, and how applications perform path > validation. > > > -----Original Message----- > > From: Tony Bartoletti [SMTP:azb@llnl.gov] > > Sent: Wednesday, September 09, 1998 3:12 PM > > To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith; > > william.burr@nist.gov; BJUENEMAN@novell.com > > Cc: ietf-pkix@imc.org > > Subject: RE: New Extension Proposed: Method Of Authentication > > > > At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote: > > >The subscriber authentication at the various stages (such > as initial > > >registration, registration after revocation, revocation request, > > normal > > >rekey, etc.) is supposed to be described in the certificate policy. > > >Thus, the certificate policy asserted points to the authentication > > >method. > > > > True, but this certainly places a limit upon the degree of > automation > > that can be employed in the future, at least until we have software > > that can read a CPS and base decisions upon it. No time soon. > > > > Granted, some 20 bits describing authentication method(s) would be > > contentious, but the very exercise would reveal much about where and > > how trust is really anchored, and the degree to which > automated agents > > could evolve. > > > > >There is NO need for another extension. > > > > Have enough work already? ;) > > > > ___tony___ > > > > >> -----Original Message----- > > >> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com] > > >> Sent: Wednesday, September 09, 1998 1:16 PM > > >> To: Mike Smith; william.burr@nist.gov; BJUENEMAN@novell.com > > >> Cc: ietf-pkix@imc.org > > >> Subject: RE: New Extension Proposed: Method Of Authentication > > >> > > >> > In using certificates, it is useful to know what form of > > >> > authentication is used by a CA to identify a new certificate > > >> > requester. A certificate extension seems the best > place to store > > > > >> > this information. > > >> > > >> This sounds to me like a trip into a quagmire. I don't think that > > >> it is possible to charaterize authentication mechanisms usefully > > >> in a set of binary flags. > > >> > > >> For example two CAs may be requiring presentation of a driving > > >> license for authentication, only one CA may be using a state of > > >> MA license with photo ID and another a UK driving license without > > >> photo ID. > > >> > > >> Even with documents such as passports there is considerable > > >> variation between countries in the strictness of their > proceedures. > > >> > > >> Then there are proceedural variations, is the applicant present > > >> in person or were the credentials merely faxed... > > >> > > >> > > >> Nor is the mechanism of authentication by itself particularly > > >> usefull unless there is an evaluation of the reliability of the > > >> party performing it. > > >> > > >> Of course one can start to characterise these characteristics > > >> as well but to do so merely throws up yet more information which > > >> might be relevant, factors which become increasingly subjective. > > >> > > >> > > >> This is a hard AI problem - establishing a shared vocabulary of > > >> terms which permits exchange of concepts whose semantics are > > >> not embedded in the communication mechanism or indeed any > > >> mechanism for which a formal description is available. > > >> > > >> Phill > > > > > > > > > > Tony Bartoletti LL > > SPI-NET GURU LL LL > > Computer Security Technology Center LL LL LL > > Lawrence Livermore National Lab LL LL LL > > PO Box 808, L - 303 LL LL LLLLLLLL > > Livermore, CA 94551-9900 LL LLLLLLLL > > email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ! > > > -- Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK Tel: + 44 (0) 1442 342 600 Fax: +44 (0) 1256 812 901 Website: http://www.zergo.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA24782 for ietf-pkix-bks; Thu, 10 Sep 1998 12:16:00 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA24777 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 12:15:55 -0700 (PDT) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA27185 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 15:21:19 -0400 (EDT) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA27171 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 15:21:17 -0400 (EDT) Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA00818 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 15:20:38 -0400 (EDT) Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000267235@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 15:21:10 -0400 Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BDDCCE.A3748CA0@avenger.missi.ncsc.mil>; Thu, 10 Sep 1998 15:21:09 -0400 Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-980910192109Z-33919@avenger.missi.ncsc.mil> From: "Fillingham, David W." <dwfilli@missi.ncsc.mil> To: "'Mike Smith'" <mfsmith@zionsbank.com>, "'chokhani@cygnacom.com'" <chokhani@cygnacom.com>, "'azb@llnl.gov'" <azb@llnl.gov>, "'william.burr@nist.gov'" <william.burr@nist.gov>, "'BJUENEMAN@novell.com'" <BJUENEMAN@novell.com>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com> Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: RE: RE: New Extension Proposed: Method Of Authentication Date: Thu, 10 Sep 1998 15:21:09 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk I agree with Phillip. My folder containing the debate on the meaning of the non-repudiation key usage bit contains 97 messages from people trying to define what that one bit is supposed to mean. Trying to convey security policies via a similar method strikes me as doomed from the start. Dave Fillingham >---------- >From: Phillip M Hallam-Baker[SMTP:pbaker@verisign.com] >Sent: Thursday, September 10, 1998 1:48 PM >To: Mike Smith; chokhani@cygnacom.com; azb@llnl.gov; william.burr@nist.gov; >BJUENEMAN@novell.com >Cc: ietf-pkix@imc.org >Subject: RE: RE: New Extension Proposed: Method Of Authentication > > >> If we have standard identifiers, one byte each, provides 0 to 255 >> specific categories, with say, ten as internet standards. >> >> With initial authentication method, maybe we start with (decimal): >> 0 as anonymous, >> 1 as self-authenticated, >> 2 as driver license or government ID card >> 3 as passport >> 4 as military > >This is heading straight into the quagmire I spoke about... > >Decimal numbers is just about the worst approach since it means that >a central registry has to be kept - yet another task for IANA! and >the arbitrary limit of 255 sounds guaranteed to ensure that the >namespace will quickly become cluttered with ad hoc private >definitions being used on an 'experimental' basis. > >I don't see any value in the taxonomy presented. What is a 'military' >identification method? Is identification by the US army equivalent to >that of the Taleban in Afghanistan? > >The drivers license is particularly dubious. My UK drivers license >has no photograph and is valid until sometime after 2020. > >Are there CAs who actually want to specify their exact authorization >processes? Are such processes objectively definable? A commercial >CA does not define authorization procedures for every concievable >document they might accept in their CPS. The first time a US CA >decides on acceptable forms of authentication for a Monaco >corporation is likely to be when they get a purchase request. > > >If you want to take the matter further I suggest you write an >Internet Draft and see if the working group chairs want to >make it a work item. > > Phill > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24098 for ietf-pkix-bks; Thu, 10 Sep 1998 10:43:18 -0700 (PDT) Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24094 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 10:43:17 -0700 (PDT) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA16666; Thu, 10 Sep 1998 10:46:17 -0700 (PDT) Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA12380; Thu, 10 Sep 1998 10:48:02 -0700 (PDT) From: "Phillip M Hallam-Baker" <pbaker@verisign.com> To: "Mike Smith" <mfsmith@zionsbank.com>, <chokhani@cygnacom.com>, <azb@llnl.gov>, <william.burr@nist.gov>, <BJUENEMAN@novell.com> Cc: <ietf-pkix@imc.org> Subject: RE: RE: New Extension Proposed: Method Of Authentication Date: Thu, 10 Sep 1998 13:48:20 -0400 Message-ID: <002001bddce3$3318eb80$9d07a8c0@pbaker-pc.verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <s5f7a303.014@zionsbank.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ietf-pkix@imc.org Precedence: bulk > If we have standard identifiers, one byte each, provides 0 to 255 > specific categories, with say, ten as internet standards. > > With initial authentication method, maybe we start with (decimal): > 0 as anonymous, > 1 as self-authenticated, > 2 as driver license or government ID card > 3 as passport > 4 as military This is heading straight into the quagmire I spoke about... Decimal numbers is just about the worst approach since it means that a central registry has to be kept - yet another task for IANA! and the arbitrary limit of 255 sounds guaranteed to ensure that the namespace will quickly become cluttered with ad hoc private definitions being used on an 'experimental' basis. I don't see any value in the taxonomy presented. What is a 'military' identification method? Is identification by the US army equivalent to that of the Taleban in Afghanistan? The drivers license is particularly dubious. My UK drivers license has no photograph and is valid until sometime after 2020. Are there CAs who actually want to specify their exact authorization processes? Are such processes objectively definable? A commercial CA does not define authorization procedures for every concievable document they might accept in their CPS. The first time a US CA decides on acceptable forms of authentication for a Monaco corporation is likely to be when they get a purchase request. If you want to take the matter further I suggest you write an Internet Draft and see if the working group chairs want to make it a work item. Phill Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23067 for ietf-pkix-bks; Thu, 10 Sep 1998 08:58:52 -0700 (PDT) Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA23063 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 08:58:51 -0700 (PDT) Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Thu, 10 Sep 1998 09:59:31 -0600 Message-Id: <s5f7a303.014@zionsbank.com> X-Mailer: Novell GroupWise 4.1 Date: Thu, 10 Sep 1998 09:59:21 -0600 From: Mike Smith <mfsmith@zionsbank.com> To: chokhani@cygnacom.com, azb@llnl.gov, william.burr@nist.gov, BJUENEMAN@novell.com, pbaker@verisign.com Cc: ietf-pkix@imc.org Subject: Re: RE: New Extension Proposed: Method Of Authentication Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk Maybe "new" extension is too strong a phrase. How about defining the policy qulifiers to have some standard" meanings, then: reliance limit licensure, licensing body authentication method etc. If we have standard identifiers, one byte each, provides 0 to 255 specific categories, with say, ten as internet standards. With initial authentication method, maybe we start with (decimal): 0 as anonymous, 1 as self-authenticated, 2 as driver license or government ID card 3 as passport 4 as military then start with combinations including common attributes, such as credit bureau rating as of issuance, etc. I do understand that, while policy OIDs may be supported some largely deployed systems do not support the policy qualifiers, but the standards do, so why don't we use them to improve our automation needs. Any time we need to rely on individuals obtaining, reading and being held accountable to a two hundred page contract (CPS), we limit its usability. Having standard definitions for the most common usages and having these signed as part of the cert by the issuer should facilitate automatic policy acceptance across those domains with multiple policies (if I have accepted all of the Verisign roots, then all of the categories of authentication are accepted. If each cert has the main characteristics of trust (initial authentication, CA licensure, reliance liits, CPS location/OID, etc.), then I should be able to set my acceptance on user selected criteria, without re-reading the two hundred pages of each of the CAs my company does business with. Michael >>> Santosh Chokhani <chokhani@cygnacom.com> 09/09 1:25 PM >>> The certificate policy is supposed to the represented in the certificate as an object identifier. The amendment to X.509 defines how the applications process that field to determine if a certificate is acceptable, including certificate policy and associated authentication mechanism. X.509 amendment offer a rich set of capabilities in this area in terms of what goes in a certificate, and how applications perform path validation. > -----Original Message----- > From: Tony Bartoletti [SMTP:azb@llnl.gov] > Sent: Wednesday, September 09, 1998 3:12 PM > To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith; > william.burr@nist.gov; BJUENEMAN@novell.com > Cc: ietf-pkix@imc.org > Subject: RE: New Extension Proposed: Method Of Authentication > > At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote: > >The subscriber authentication at the various stages (such as initial > >registration, registration after revocation, revocation request, > normal > >rekey, etc.) is supposed to be described in the certificate policy. > >Thus, the certificate policy asserted points to the authentication > >method. > > True, but this certainly places a limit upon the degree of automation > that can be employed in the future, at least until we have software > that can read a CPS and base decisions upon it. No time soon. > > Granted, some 20 bits describing authentication method(s) would be > contentious, but the very exercise would reveal much about where and > how trust is really anchored, and the degree to which automated agents > could evolve. > > >There is NO need for another extension. > > Have enough work already? ;) > > ___tony___ > > >> -----Original Message----- > >> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com] > >> Sent: Wednesday, September 09, 1998 1:16 PM > >> To: Mike Smith; william.burr@nist.gov; BJUENEMAN@novell.com > >> Cc: ietf-pkix@imc.org > >> Subject: RE: New Extension Proposed: Method Of Authentication > >> > >> > In using certificates, it is useful to know what form of > >> > authentication is used by a CA to identify a new certificate > >> > requester. A certificate extension seems the best place to store > > >> > this information. > >> > >> This sounds to me like a trip into a quagmire. I don't think that > >> it is possible to charaterize authentication mechanisms usefully > >> in a set of binary flags. > >> > >> For example two CAs may be requiring presentation of a driving > >> license for authentication, only one CA may be using a state of > >> MA license with photo ID and another a UK driving license without > >> photo ID. > >> > >> Even with documents such as passports there is considerable > >> variation between countries in the strictness of their proceedures. > >> > >> Then there are proceedural variations, is the applicant present > >> in person or were the credentials merely faxed... > >> > >> > >> Nor is the mechanism of authentication by itself particularly > >> usefull unless there is an evaluation of the reliability of the > >> party performing it. > >> > >> Of course one can start to characterise these characteristics > >> as well but to do so merely throws up yet more information which > >> might be relevant, factors which become increasingly subjective. > >> > >> > >> This is a hard AI problem - establishing a shared vocabulary of > >> terms which permits exchange of concepts whose semantics are > >> not embedded in the communication mechanism or indeed any > >> mechanism for which a formal description is available. > >> > >> Phill > > > > > > Tony Bartoletti LL > SPI-NET GURU LL LL > Computer Security Technology Center LL LL LL > Lawrence Livermore National Lab LL LL LL > PO Box 808, L - 303 LL LL LLLLLLLL > Livermore, CA 94551-9900 LL LLLLLLLL > email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22915 for ietf-pkix-bks; Thu, 10 Sep 1998 08:43:51 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA22911 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 08:43:50 -0700 (PDT) Message-Id: <199809101543.IAA22911@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 10 Sep 1998 08:49:00 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Fwd: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk This draft may interest people in the PKIX group. It is also available from <http://www.imc.org/draft-ietf-ipsec-pki-req>. --Paul Hoffman, Director --Internet Mail Consortium >To: IETF-Announce: ; >Cc: ipsec@tis.com >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-ipsec-pki-req-00.txt >Date: Thu, 10 Sep 1998 10:34:19 -0400 >Sender: cclark@ns.cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IP Security Protocol Working Group of the IETF. > > Title : PKI Requirements for IP Security > Author(s) : R. Thayer > Filename : draft-ietf-ipsec-pki-req-00.txt > Pages : 22 > Date : 09-Sep-98 > > The IP Security (IPSec) protocol set now being defined in the > IETF uses public key cryptography for authentication in it's key > management protocol. This document defines the requirements that > IPSec has for Public Key Infrastructure (PKI) protocols, formats, > and services. > > The key words 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and > 'MAY' in this document are to be interpreted as described in RFC > 2119. > > Please send comments on this document to the ipsec@tis.com > mailing list. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ipsec-pki-req-00.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-00.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-ipsec-pki-req-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <19980909162526.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-ipsec-pki-req-00.txt > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-00.txt> > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22538 for ietf-pkix-bks; Thu, 10 Sep 1998 08:14:28 -0700 (PDT) Received: from slack.lne.com (NoBody@slack.lne.com [140.174.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22534 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 08:14:26 -0700 (PDT) Received: (from ericm@localhost) by slack.lne.com (8.9.0/8.9.0) id IAA12666; Thu, 10 Sep 1998 08:19:50 -0700 From: Eric Murray <ericm@lne.com> Message-Id: <199809101519.IAA12666@slack.lne.com> Subject: Re: New Extension Proposed: Method Of Authentication To: pkoning@xedia.com (Paul Koning) Date: Thu, 10 Sep 1998 08:19:49 -0700 (PDT) Cc: azb@llnl.gov, ietf-pkix@imc.org In-Reply-To: <199809101321.JAA14290@tonga.xedia.com> from "Paul Koning" at Sep 10, 98 09:21:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Paul Koning writes: > > Incidentally, as an aside -- this discussion made me worry about the > potential for unrestrained growth of certificates. As someone > involved in building diskless (embedded) systems, megabyte-sized certs > worry me a lot. Me too. Our company also does embedded systems which need to accept and verify certs. Please keep your certs small if you really want them to be ubiquitous. I'd much rather see a URI and perhaps a hash in the cert instead of the entire CPS. -- Eric Murray N*Able Technologies www.nabletech.com (email: ericm at the sites lne.com or nabletech.com) PGP keyid:E03F65E5 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21461 for ietf-pkix-bks; Thu, 10 Sep 1998 06:17:21 -0700 (PDT) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21457 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 06:17:20 -0700 (PDT) Received: from xedia.com by relay5.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfgft03924; Thu, 10 Sep 1998 09:21:34 -0400 (EDT) Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA09439; Thu, 10 Sep 98 09:20:42 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA14290; Thu, 10 Sep 1998 09:21:30 -0400 Date: Thu, 10 Sep 1998 09:21:30 -0400 Message-Id: <199809101321.JAA14290@tonga.xedia.com> From: Paul Koning <pkoning@xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: azb@llnl.gov Cc: ietf-pkix@imc.org Subject: RE: New Extension Proposed: Method Of Authentication References: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> <000701bddc29$99814e40$9d07a8c0@pbaker-pc.verisign.com> <3.0.3.32.19980909162025.00a06390@poptop.llnl.gov> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ietf-pkix@imc.org Precedence: bulk >>>>> "Tony" == Tony Bartoletti <azb@llnl.gov> writes: >... Tony> Still, suppose the certificate did contain the CPS hash. Tony> Imagine that a client system, in the course of validating Tony> certificates, determines that a particular CPS has changed. Tony> That is, some of the certs point to the older CPS, and some to Tony> a brand new CPS. Assume further that it can (securely) Tony> retrieve both the older and newer CPS at will. It can still Tony> validate the older certs, but it can do nothing with the newer Tony> ones until a human steps in to read the new CPS, and then Tony> determine its sufficiency for the purpose(s) at hand. Tony> In terms of automation, "the bits stop here." I think that's as it should be. Whether a new CPS is sufficient for the purposes at hand, in any situation where someone cares enough to look at the CPS at all, is a question that undoubtedly involves lawyers, or even people involved in still less formal processes. Until and unless someone comes up with a mapping from legal english to formal logic (unlikely given Goedel's theorem) I believe the bits HAVE to stop where you said. Incidentally, as an aside -- this discussion made me worry about the potential for unrestrained growth of certificates. As someone involved in building diskless (embedded) systems, megabyte-sized certs worry me a lot. paul Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21325 for ietf-pkix-bks; Thu, 10 Sep 1998 06:02:10 -0700 (PDT) Received: from getafix.fcpl.co.in (Getafix.fcpl.co.in [196.1.104.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21320 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 06:02:03 -0700 (PDT) Received: from TinTins.fcpl.co.in ([196.1.104.84]) by getafix.fcpl.co.in (post.office MTA v2.0 0613 ID# 291-17719) with SMTP id AAA135 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 18:38:00 +0530 Message-ID: <000b01bddcbc$29a0ac40$546801c4@TinTins.fcpl.co.in> From: "Shailesh" <shailesh@fcpl.co.in> To: <ietf-pkix@imc.org> Subject: PKIX transports using HTTP Date: Thu, 10 Sep 1998 18:38:54 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-pkix@imc.org Precedence: bulk 1. What is more standard way of communicating PKIX messages on HTTP : Put them as a part of URL OR Put them in the "Entity (optional) part of the request and response" 2. What extensions of the HTTP or part of the core protocol talks about polling? How does one poll using HTTP? Thanks with best regards Shailesh Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21056 for ietf-pkix-bks; Thu, 10 Sep 1998 05:47:22 -0700 (PDT) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21051 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 05:47:17 -0700 (PDT) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id OAA01964; Thu, 10 Sep 1998 14:54:13 +0200 Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id OAA19716; Thu, 10 Sep 1998 14:54:06 +0200 (DFT) Message-ID: <35F84A56.32A2@bull.net> Date: Thu, 10 Sep 1998 14:53:26 -0700 From: Denis Pinkas <Denis.Pinkas@bull.net> Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) MIME-Version: 1.0 To: Eric Murray <ericm@lne.com> CC: ietf-pkix@imc.org Subject: Re: New Extension Proposed: Method Of Authentication References: <199809091924.MAA11040@slack.lne.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Eric Murray wrote: > Santosh Chokhani writes: > > The subscriber authentication at the various stages (such as initial > > registration, registration after revocation, revocation request, normal > > rekey, etc.) is supposed to be described in the certificate policy. > > Thus, the certificate policy asserted points to the authentication > > method. > > There is NO need for another extension. > I agree that putting the policy into an extension is a quagmire. > However, given that most CPSs will be on web sites, and those > CPSs can be changed at any time, should there be a way to > indicate which CPS is in effect at any given time during > the certificate's life? > Say Fred is issued a cert by Carl the CA. Carl signs Fred's > cert under the then-current CPS 1.2, which required Carl > to verify Fred's identity using dental charts. Sometime > later, Carl changes his CPS to version 1.3, which no longer requires > dental charts as a form of identification, but instead > accepts a state driver's license. > Fred would like to sign a contract to purchase a house. The lender > requires a high-quality signature, and a cert with only a state > driver's license as identification isn't good enough. How does Fred > indicate that his cert was issued under the older, more rigorous CPS? You are adressing an important issue. When you sign a contract, you usually look at the back of the page where there is either the full terms of the contract or a short form of them with a pointer to a full form. It is thus important to know whether you agree or not with these: if yes, you sign, if not you don't. The equivalent in electronic terms is to point to a security policy and sign it (i.e. add the security policy to the core of the signed message and sign the whole). Different pointers may be used. Here are two examples: an OID, a URL address. If the policy changes, the pointer must change. A hash of the policy has to be used to make sure which terms you were agreeing with. These terms will indicate which CAs are adequate to be used by the signers and which security policies from that CA will be adequate to be used, relative to these terms. > One way to deal with this is to revoke all certs issued under a > given CPS when it is changed. I'm not sure that that provides any assurance > that a given cert was issued under the current CPS though- a receiving > party would have to depend on the current CPS stating that such > is the policy. And it's obviously very undesireable from a CA standpoint. Indeed ! > Another way would be to require the CA to sign their CPSs and include > version numbers, and to include in the cert extension which points to > the CPS, the version number of the CPS which was in effect when the cert > was issued. This will prevent CAs from updating CPSs "out from > underneath" existing certs. That may or may not be a desired effect. :-( > I did a very quick read of the draft and didn't see anything that > handles this problem. But I have not been following the discussion very > much and have not studied the draft, so I could well have missed it. If > there's already something in the draft to deal with this, or this > subject has already been discussed on the list, please accept my > apologies. You did not missed it, the draft is silent on this kind of topic, but it would not be the right place anyway to place it. At the Chicago meeting, we talked about expanding the work to handle non repudiation in more details. If such an extension of the work happens, then we could possibly deal with this kind of topic. Denis > -- > Eric Murray N*Able Technologies www.nabletech.com > (email: ericm at the sites lne.com or nabletech.com) PGP keyid:E03F65E5 -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20901 for ietf-pkix-bks; Thu, 10 Sep 1998 05:19:37 -0700 (PDT) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20897 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 05:19:34 -0700 (PDT) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id OAA22350; Thu, 10 Sep 1998 14:26:25 +0200 Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id OAA19816; Thu, 10 Sep 1998 14:26:20 +0200 (DFT) Message-ID: <35F843D4.7FF4@bull.net> Date: Thu, 10 Sep 1998 14:25:40 -0700 From: Denis Pinkas <Denis.Pinkas@bull.net> Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) MIME-Version: 1.0 To: Mike Smith <mfsmith@zionsbank.com> CC: william.burr@nist.gov, BJUENEMAN@novell.com, ietf-pkix@imc.org Subject: Re: New Extension Proposed: Method Of Authentication References: <s5f6527f.038@zionsbank.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Mike Smith wrote: > > In using certificates, it is useful to know what form of > authentication is used by a CA to identify a new certificate > requester. A certificate extension seems the best place to store > this information. > > At one time, Bob Jeuneman prepared a paper proposing this extension > and detailing many categories, from anonymous, self-authenticated, > self authenticated with data verifired (or with credit account, etc.), > authenticated in person, in person with governement-issued picture ID, > multiple forms of government picture IDs with current credit reports > and corporate D&B, etc. > The current practice, I beleive, is to embed the authentication > mechanism in a CA operations or policy statement tha may or may not > be online for someone to peruse and make their own judgement. > Putting a clear indicator in the signed cert would help. > Comments? Bob? If we were going in that direction then we might need to indicate whether one or more of the following has been presented: a driving license, a passport, an ID card, a bill from an Electricity supplier, a bill from a Telephone company, a bill from a Water supplier, etc ... We already have (too) many extensions. The policy statement is enough. There is no need for a verifier to understand the details of the policy, but only to know whether the policy is acceptable for the application. Denis > Michael -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20886 for ietf-pkix-bks; Thu, 10 Sep 1998 05:16:33 -0700 (PDT) Received: from getafix.fcpl.co.in (Getafix.fcpl.co.in [196.1.104.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20879 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 05:16:12 -0700 (PDT) Received: from dynamo ([196.1.104.100]) by getafix.fcpl.co.in (post.office MTA v2.0 0613 ID# 291-17719) with SMTP id AAA142 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 17:52:05 +0530 Message-ID: <002b01bddcb6$078be850$646801c4@dynamo.fcpl.co.in> From: "Abhay Kulkarni" <abhay@fcpl.co.in> To: <ietf-pkix@imc.org> Subject: PKIX Certificate Management Protocols Date: Thu, 10 Sep 1998 17:54:53 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01BDDCE4.1D99E100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2110.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-pkix@imc.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0028_01BDDCE4.1D99E100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everybody, Where do we find extra information about how to use HTTP protocol as the = lower layer in the PKI certificate management protocol ? Thanks in advance. Regards. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Abhay Kulkarni Systems Engineer Frontier Computers Pvt. Ltd. EMail: abhay@fcpl.co.in Web: http://www.fcpl.co.in %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ------=_NextPart_000_0028_01BDDCE4.1D99E100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#fffbf0> <DIV><FONT color=3D#000000 size=3D2>Hello everybody,</FONT></DIV> <DIV><FONT size=3D2>Where do we find extra information about how to use = HTTP=20 protocol as the lower layer in the PKI certificate management protocol=20 ?</FONT></DIV> <DIV><FONT size=3D2>Thanks in advance.</FONT></DIV> <DIV><FONT size=3D2>Regards.</FONT></DIV> <DIV><FONT color=3D#000000 = size=3D2>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%<BR>Abhay=20 Kulkarni<BR>Systems Engineer<BR>Frontier Computers Pvt. = Ltd.<BR>EMail: <A=20 href=3D"mailto:abhay@fcpl.co.in">abhay@fcpl.co.in</A><BR>Web: <A=20 href=3D"http://www.fcpl.co.in">http://www.fcpl.co.in</A><BR>%%%%%%%%%%%%%= %%%%%%%%%%%%%%%%%%%%%</FONT></DIV></BODY></HTML> ------=_NextPart_000_0028_01BDDCE4.1D99E100-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20830 for ietf-pkix-bks; Thu, 10 Sep 1998 05:10:30 -0700 (PDT) Received: from gatekeeper.domus.com ([198.166.58.193]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA20826 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 05:10:28 -0700 (PDT) Received: from dns_int.domus.com by gatekeeper1.domus.com (8.6.13/200.19.1.1) id IAA27690; Thu, 10 Sep 1998 08:07:14 -0400 Received: (from smap@localhost) by dns_int.domus.com (8.6.8/8.6.6) id HAA24702 for <ietf-pkix@imc.org>; Thu, 10 Sep 1998 07:35:30 -0400 Received: from wpgate.domus.com(198.166.59.10) by dns_int.domus.com via smap (V1.3) id sma024700; Thu Sep 10 07:35:22 1998 Received: from DOMUS-Message_Server by wpgate.domus.com with Novell_GroupWise; Thu, 10 Sep 1998 08:07:25 -0400 Message-Id: <s5f788bd.052@wpgate.domus.com> X-Mailer: Novell GroupWise 4.1 Date: Thu, 10 Sep 1998 08:07:16 -0400 From: William Dziadyk <WDziadyk@domus.com> To: ietf-pkix@imc.org Subject: For Option 2 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk --------------------------------------------------------------------------------- William Dziadyk, PEng IT Security Services, DOMUS Software, Ottawa, Ontario, Canada (613) 230-6285 ext 342 ---- WDziadyk@DOMUS.com --------------------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA12866 for ietf-pkix-bks; Wed, 9 Sep 1998 23:54:28 -0700 (PDT) Received: from genius.tisl.soft.net (genius.tisl.soft.net [164.164.20.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA12861; Wed, 9 Sep 1998 23:54:22 -0700 (PDT) Received: from narayan ([32.97.253.98]) by genius.tisl.soft.net (AIX4.3/UCB 8.7/8.7) with ESMTP id MAA20198; Thu, 10 Sep 1998 12:25:52 -0530 (ist) Message-ID: <35F77875.E02C36B8@geocities.com> Date: Thu, 10 Sep 1998 12:27:57 +0530 From: Narayan Raghu <narry@geocities.com> X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: Paul Hoffman / IMC <phoffman@imc.org> CC: ietf-pkix@imc.org Subject: Re: New Extension Proposed: Method Of Authentication X-Priority: 3 (Normal) References: <000701bddc29$99814e40$9d07a8c0@pbaker-pc.verisign.com> <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> <199809092353.QAA27581@mail.proper.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Hello, Ultimately, it is the verifier of a certificate who decides if a certification authority is to be trusted. Hence, the onus is on him to verify the policies of the CA and decide whether to designate that CA as the trusted root. IF a CA changes it's policy, it could simply generate another keypair, which signes certificates verifed by the new method. That way, the verifier can decide whether to designate the new CA certificate as trusted root or not, depending upon the new policy of the CA. The verifier can thus choose to trust all those certified by the old CA Certificate/Keypair, since the old policy was acceptable. The key here is that we link a new CA policy with a mandatory new CA signing keypair. I dont think it's required to mention the verifying method in the certificate, since it's the certificate verifier's responsibility. narayan ibm bangalore india Paul Hoffman / IMC wrote: > > At 04:20 PM 9/9/98 -0700, Tony Bartoletti wrote: > >There are two significant shortcomings with the existing situation, > >nonetheless. First, as pointed out by Eric Murray, is that this > >"pointer to the certificate policy" is a weak link in a critical > >chain to the foundation of trust. > > Then don't validate certs with CPSs; only validate ones with OIDs that > you > understand. > > Remember, these policies are for CAs who you have already decided you > trust > to sign someone else's key. If you don't trust them not to change > their > CPS, why do you trust that they are even following the CPS you looked > up > once? Any reasonable CA who changes their CPS will keep the old one at > the > original URL and create a new CPS with a new URL, and put the new URL > in > certs that conform to the new policy. > > --Paul Hoffman, Director > --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27613 for ietf-pkix-bks; Wed, 9 Sep 1998 16:56:28 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27609 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 16:56:27 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ879>; Wed, 9 Sep 1998 20:00:03 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A6C@WUHER> From: Santosh Chokhani <chokhani@cygnacom.com> To: "'Tony Bartoletti'" <azb@llnl.gov>, Phillip M Hallam-Baker <pbaker@verisign.com>, Santosh Chokhani <chokhani@cygnacom.com>, Mike Smith <mfsmith@zionsbank.com>, william.burr@nist.gov, BJUENEMAN@novell.com, Eric Murray <ericm@lne.com> Cc: ietf-pkix@imc.org Subject: RE: New Extension Proposed: Method Of Authentication Date: Wed, 9 Sep 1998 20:00:00 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Tony: I think certificate policies are supposed to take care of this. Clients need not read CP or CPS. One may put CPS digest in an already defined extension in the certificate. > -----Original Message----- > From: Tony Bartoletti [SMTP:azb@llnl.gov] > Sent: Wednesday, September 09, 1998 7:20 PM > To: Phillip M Hallam-Baker; Santosh Chokhani; Mike Smith; > william.burr@nist.gov; BJUENEMAN@novell.com; Eric Murray > Cc: ietf-pkix@imc.org > Subject: RE: New Extension Proposed: Method Of Authentication > > At 03:39 PM 9/9/98 -0400, Phillip M Hallam-Baker wrote: > > > >> The subscriber authentication at the various stages (such as > initial > >> registration, registration after revocation, revocation request, > normal > >> rekey, etc.) is supposed to be described in the certificate policy. > >> Thus, the certificate policy asserted points to the authentication > >> method. > > > >True. What I interpreted the proposal to be however was an abstract > >syntax for describing certificate policy in a form that would allow > >automated evaluation. There is a big difference between putting a > >pointer to the certificate policy into a cert and attempting to > encode > >the certificate policy within the certificate itself. > > > >While such a facility would be 'nice to have' my experience is that > >it is a very hard AI problem, at least as hard as the problem of > >natural language understanding. > > Phill, > > I do understand, and would expect any attempt to address the stated > shortcomings via an extension (or any other method) to be a multi-year > effort:) > > There are two significant shortcomings with the existing situation, > nonetheless. First, as pointed out by Eric Murray, is that this > "pointer to the certificate policy" is a weak link in a critical > chain to the foundation of trust. I recall (two years ago!) this > very subject was debated on this list, with some calls to have the > cert contain a hash of the CPS in effect at the time of certificate > creation, so there could be no subtle (or not so subtle) rewording > of the CPS after the fact. Alas, no such provisions were included. > > Still, suppose the certificate did contain the CPS hash. Imagine > that a client system, in the course of validating certificates, > determines that a particular CPS has changed. That is, some of the > certs point to the older CPS, and some to a brand new CPS. Assume > further that it can (securely) retrieve both the older and newer CPS > at will. It can still validate the older certs, but it can do nothing > with the newer ones until a human steps in to read the new CPS, and > then determine its sufficiency for the purpose(s) at hand. > > In terms of automation, "the bits stop here." > > Its just an observation... > > ___tony___ > > >There is a project in the International Chamber of Commerce called > >ETerms which addresses the problem of providing a CPS repository > >and which has as a long term goal the establishment of a shared > >vocabulary of contract terms. > > > >This enterprise is best described as 'chock full o' lawyers'. Many > >of the issues being delt with involve subtle and obscure points > >of international law - such as the fact that the criteria for > >establishing constructive notice vary according to the jurisdiction. > > > >Significantly the E-Terms project is not attempting to establish a > >taxonomy of trade terms in common use. I don't think such a 'top > >down' approach is feasible. Instead what is being attempted is a > >convergence of the user community towards the use of a common > >vocabulary which is itself a product of the process. This is more > >of a bottom-up, evolutionary approach. > > > > Phill > > > > > > > > > > > > Tony Bartoletti LL > SPI-NET GURU LL LL > Computer Security Technology Center LL LL LL > Lawrence Livermore National Lab LL LL LL > PO Box 808, L - 303 LL LL LLLLLLLL > Livermore, CA 94551-9900 LL LLLLLLLL > email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27585 for ietf-pkix-bks; Wed, 9 Sep 1998 16:53:54 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA27581 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 16:53:53 -0700 (PDT) Message-Id: <199809092353.QAA27581@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 09 Sep 1998 16:58:57 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: RE: New Extension Proposed: Method Of Authentication In-Reply-To: <3.0.3.32.19980909162025.00a06390@poptop.llnl.gov> References: <000701bddc29$99814e40$9d07a8c0@pbaker-pc.verisign.com> <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk At 04:20 PM 9/9/98 -0700, Tony Bartoletti wrote: >There are two significant shortcomings with the existing situation, >nonetheless. First, as pointed out by Eric Murray, is that this >"pointer to the certificate policy" is a weak link in a critical >chain to the foundation of trust. Then don't validate certs with CPSs; only validate ones with OIDs that you understand. Remember, these policies are for CAs who you have already decided you trust to sign someone else's key. If you don't trust them not to change their CPS, why do you trust that they are even following the CPS you looked up once? Any reasonable CA who changes their CPS will keep the old one at the original URL and create a new CPS with a new URL, and put the new URL in certs that conform to the new policy. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27403 for ietf-pkix-bks; Wed, 9 Sep 1998 16:16:15 -0700 (PDT) Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27399 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 16:16:14 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id QAA10253; Wed, 9 Sep 1998 16:21:14 -0700 (PDT) Message-Id: <3.0.3.32.19980909162025.00a06390@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 09 Sep 1998 16:20:25 -0700 To: "Phillip M Hallam-Baker" <pbaker@verisign.com>, "Santosh Chokhani" <chokhani@cygnacom.com>, "Mike Smith" <mfsmith@zionsbank.com>, <william.burr@nist.gov>, <BJUENEMAN@novell.com>, Eric Murray <ericm@lne.com> From: Tony Bartoletti <azb@llnl.gov> Subject: RE: New Extension Proposed: Method Of Authentication Cc: <ietf-pkix@imc.org> In-Reply-To: <000701bddc29$99814e40$9d07a8c0@pbaker-pc.verisign.com> References: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk At 03:39 PM 9/9/98 -0400, Phillip M Hallam-Baker wrote: > >> The subscriber authentication at the various stages (such as initial >> registration, registration after revocation, revocation request, normal >> rekey, etc.) is supposed to be described in the certificate policy. >> Thus, the certificate policy asserted points to the authentication >> method. > >True. What I interpreted the proposal to be however was an abstract >syntax for describing certificate policy in a form that would allow >automated evaluation. There is a big difference between putting a >pointer to the certificate policy into a cert and attempting to encode >the certificate policy within the certificate itself. > >While such a facility would be 'nice to have' my experience is that >it is a very hard AI problem, at least as hard as the problem of >natural language understanding. Phill, I do understand, and would expect any attempt to address the stated shortcomings via an extension (or any other method) to be a multi-year effort:) There are two significant shortcomings with the existing situation, nonetheless. First, as pointed out by Eric Murray, is that this "pointer to the certificate policy" is a weak link in a critical chain to the foundation of trust. I recall (two years ago!) this very subject was debated on this list, with some calls to have the cert contain a hash of the CPS in effect at the time of certificate creation, so there could be no subtle (or not so subtle) rewording of the CPS after the fact. Alas, no such provisions were included. Still, suppose the certificate did contain the CPS hash. Imagine that a client system, in the course of validating certificates, determines that a particular CPS has changed. That is, some of the certs point to the older CPS, and some to a brand new CPS. Assume further that it can (securely) retrieve both the older and newer CPS at will. It can still validate the older certs, but it can do nothing with the newer ones until a human steps in to read the new CPS, and then determine its sufficiency for the purpose(s) at hand. In terms of automation, "the bits stop here." Its just an observation... ___tony___ >There is a project in the International Chamber of Commerce called >ETerms which addresses the problem of providing a CPS repository >and which has as a long term goal the establishment of a shared >vocabulary of contract terms. > >This enterprise is best described as 'chock full o' lawyers'. Many >of the issues being delt with involve subtle and obscure points >of international law - such as the fact that the criteria for >establishing constructive notice vary according to the jurisdiction. > >Significantly the E-Terms project is not attempting to establish a >taxonomy of trade terms in common use. I don't think such a 'top >down' approach is feasible. Instead what is being attempted is a >convergence of the user community towards the use of a common >vocabulary which is itself a product of the process. This is more >of a bottom-up, evolutionary approach. > > Phill > > > > > Tony Bartoletti LL SPI-NET GURU LL LL Computer Security Technology Center LL LL LL Lawrence Livermore National Lab LL LL LL PO Box 808, L - 303 LL LL LLLLLLLL Livermore, CA 94551-9900 LL LLLLLLLL email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26368 for ietf-pkix-bks; Wed, 9 Sep 1998 14:15:07 -0700 (PDT) Received: from relay1.eds.com (relay1.eds.com [199.228.142.73]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26364 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 14:15:05 -0700 (PDT) Received: from nnsa.eds.com (nnsa.eds.com [192.85.154.30] (may be forged)) by relay1.eds.com (8.8.8/8.8.8) with ESMTP id RAA03200 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 17:20:25 -0400 (EDT) Received: from usahm007.exmi01.exch.eds.com ([207.37.138.147]) by nnsa.eds.com (8.8.8/8.8.8) with ESMTP id RAA10704 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 17:19:54 -0400 (EDT) Received: by USAHM007 with Internet Mail Service (5.5.2232.9) id <S1N8LKJ3>; Wed, 9 Sep 1998 17:19:50 -0400 Message-ID: <92D60A12331ED2119F5300A02461F047B20386@USAHM009> From: "Corcoran, Dan" <dan.corcoran@eds.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: For Option 2 Date: Wed, 9 Sep 1998 17:19:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25592 for ietf-pkix-bks; Wed, 9 Sep 1998 12:38:45 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25588 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 12:38:32 -0700 (PDT) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA20000 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 15:43:40 -0400 (EDT) Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA19994 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 15:43:39 -0400 (EDT) Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA09823 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 15:42:59 -0400 (EDT) Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000265539@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; Wed, 09 Sep 1998 15:43:23 -0400 Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BDDC08.BD7E9300@avenger.missi.ncsc.mil>; Wed, 9 Sep 1998 15:44:33 -0400 Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-980909194432Z-33291@avenger.missi.ncsc.mil> From: "Fillingham, David W." <dwfilli@missi.ncsc.mil> To: "'Santosh Chokhani'" <chokhani@cygnacom.com>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, "'Mike Smith'" <mfsmith@zionsbank.com>, "'william.burr@nist.gov'" <william.burr@nist.gov>, "'BJUENEMAN@novell.com'" <BJUENEMAN@novell.com>, "'Tony Bartoletti'" <azb@llnl.gov> Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: RE: New Extension Proposed: Method Of Authentication Date: Wed, 9 Sep 1998 15:44:32 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Tony: I agree with Santosh and Phillip on this matter - I don't think an additional extension would help. The method of verifying a subscriber's identity is one element of a certificate policy that factors in the assurance of the binding between an identity and a public key - but only one. It seems we could go down a path of defining another extension for liability limits, which may be more important to many users, and another for technical security mechanisms (e.g., is the private key protected using hardware, or software), and another for "authorized certificate applications" (e.g., only good for Company X applications) and so on. I see no need to automatically read CPS documents - X.509 already specifies how the certificate policy extension should be processed. If a policy, including the subscriber I&A process, is acceptable to a relying party for a specific application, then the certificate processing application can accept the certificate asserting that policy. Some human being reads the policy, and makes this determination, based on the entire policy, and then asserts the policy as one that is "acceptable" for the application. If a public key system implementor wants to define a certificate policy based exclusively on the initial subscriber registration identification mechanism, they could do so. I don't think this would be a good idea, but it's certainly allowed by the standards, including the IETF Certificate Policy and CPS Framework, and to my mind, is preferable to defining another extension. Dave Fillingham >---------- >From: Tony Bartoletti[SMTP:azb@llnl.gov] >Sent: Wednesday, September 09, 1998 3:12 PM >To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith; >william.burr@nist.gov; BJUENEMAN@novell.com >Cc: ietf-pkix@imc.org >Subject: RE: New Extension Proposed: Method Of Authentication > >At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote: >>The subscriber authentication at the various stages (such as initial >>registration, registration after revocation, revocation request, normal >>rekey, etc.) is supposed to be described in the certificate policy. >>Thus, the certificate policy asserted points to the authentication >>method. > >True, but this certainly places a limit upon the degree of automation >that can be employed in the future, at least until we have software >that can read a CPS and base decisions upon it. No time soon. > >Granted, some 20 bits describing authentication method(s) would be >contentious, but the very exercise would reveal much about where and >how trust is really anchored, and the degree to which automated agents >could evolve. > >>There is NO need for another extension. > >Have enough work already? ;) > >___tony___ > >>> -----Original Message----- >>> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com] >>> Sent: Wednesday, September 09, 1998 1:16 PM >>> To: Mike Smith; william.burr@nist.gov; BJUENEMAN@novell.com >>> Cc: ietf-pkix@imc.org >>> Subject: RE: New Extension Proposed: Method Of Authentication >>> >>> > In using certificates, it is useful to know what form of >>> > authentication is used by a CA to identify a new certificate >>> > requester. A certificate extension seems the best place to store >>> > this information. >>> >>> This sounds to me like a trip into a quagmire. I don't think that >>> it is possible to charaterize authentication mechanisms usefully >>> in a set of binary flags. >>> >>> For example two CAs may be requiring presentation of a driving >>> license for authentication, only one CA may be using a state of >>> MA license with photo ID and another a UK driving license without >>> photo ID. >>> >>> Even with documents such as passports there is considerable >>> variation between countries in the strictness of their proceedures. >>> >>> Then there are proceedural variations, is the applicant present >>> in person or were the credentials merely faxed... >>> >>> >>> Nor is the mechanism of authentication by itself particularly >>> usefull unless there is an evaluation of the reliability of the >>> party performing it. >>> >>> Of course one can start to characterise these characteristics >>> as well but to do so merely throws up yet more information which >>> might be relevant, factors which become increasingly subjective. >>> >>> >>> This is a hard AI problem - establishing a shared vocabulary of >>> terms which permits exchange of concepts whose semantics are >>> not embedded in the communication mechanism or indeed any >>> mechanism for which a formal description is available. >>> >>> Phill >> >> > >Tony Bartoletti LL >SPI-NET GURU LL LL >Computer Security Technology Center LL LL LL >Lawrence Livermore National Lab LL LL LL >PO Box 808, L - 303 LL LL LLLLLLLL >Livermore, CA 94551-9900 LL LLLLLLLL >email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25538 for ietf-pkix-bks; Wed, 9 Sep 1998 12:34:48 -0700 (PDT) Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25534 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 12:34:47 -0700 (PDT) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id MAA29427; Wed, 9 Sep 1998 12:37:44 -0700 (PDT) Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA16381; Wed, 9 Sep 1998 12:39:30 -0700 (PDT) From: "Phillip M Hallam-Baker" <pbaker@verisign.com> To: "Santosh Chokhani" <chokhani@cygnacom.com>, "Mike Smith" <mfsmith@zionsbank.com>, <william.burr@nist.gov>, <BJUENEMAN@novell.com> Cc: <ietf-pkix@imc.org> Subject: RE: New Extension Proposed: Method Of Authentication Date: Wed, 9 Sep 1998 15:39:46 -0400 Message-ID: <000701bddc29$99814e40$9d07a8c0@pbaker-pc.verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> Sender: owner-ietf-pkix@imc.org Precedence: bulk > The subscriber authentication at the various stages (such as initial > registration, registration after revocation, revocation request, normal > rekey, etc.) is supposed to be described in the certificate policy. > Thus, the certificate policy asserted points to the authentication > method. True. What I interpreted the proposal to be however was an abstract syntax for describing certificate policy in a form that would allow automated evaluation. There is a big difference between putting a pointer to the certificate policy into a cert and attempting to encode the certificate policy within the certificate itself. While such a facility would be 'nice to have' my experience is that it is a very hard AI problem, at least as hard as the problem of natural language understanding. There is a project in the International Chamber of Commerce called ETerms which addresses the problem of providing a CPS repository and which has as a long term goal the establishment of a shared vocabulary of contract terms. This enterprise is best described as 'chock full o' lawyers'. Many of the issues being delt with involve subtle and obscure points of international law - such as the fact that the criteria for establishing constructive notice vary according to the jurisdiction. Significantly the E-Terms project is not attempting to establish a taxonomy of trade terms in common use. I don't think such a 'top down' approach is feasible. Instead what is being attempted is a convergence of the user community towards the use of a common vocabulary which is itself a product of the process. This is more of a bottom-up, evolutionary approach. Phill Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25446 for ietf-pkix-bks; Wed, 9 Sep 1998 12:20:41 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25442 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 12:20:40 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ8LG>; Wed, 9 Sep 1998 15:25:49 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A67@WUHER> From: Santosh Chokhani <chokhani@cygnacom.com> To: "'Tony Bartoletti'" <azb@llnl.gov>, Santosh Chokhani <chokhani@cygnacom.com>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Mike Smith <mfsmith@zionsbank.com>, william.burr@nist.gov, BJUENEMAN@novell.com Cc: ietf-pkix@imc.org Subject: RE: New Extension Proposed: Method Of Authentication Date: Wed, 9 Sep 1998 15:25:47 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk The certificate policy is supposed to the represented in the certificate as an object identifier. The amendment to X.509 defines how the applications process that field to determine if a certificate is acceptable, including certificate policy and associated authentication mechanism. X.509 amendment offer a rich set of capabilities in this area in terms of what goes in a certificate, and how applications perform path validation. > -----Original Message----- > From: Tony Bartoletti [SMTP:azb@llnl.gov] > Sent: Wednesday, September 09, 1998 3:12 PM > To: Santosh Chokhani; 'Phillip M Hallam-Baker'; Mike Smith; > william.burr@nist.gov; BJUENEMAN@novell.com > Cc: ietf-pkix@imc.org > Subject: RE: New Extension Proposed: Method Of Authentication > > At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote: > >The subscriber authentication at the various stages (such as initial > >registration, registration after revocation, revocation request, > normal > >rekey, etc.) is supposed to be described in the certificate policy. > >Thus, the certificate policy asserted points to the authentication > >method. > > True, but this certainly places a limit upon the degree of automation > that can be employed in the future, at least until we have software > that can read a CPS and base decisions upon it. No time soon. > > Granted, some 20 bits describing authentication method(s) would be > contentious, but the very exercise would reveal much about where and > how trust is really anchored, and the degree to which automated agents > could evolve. > > >There is NO need for another extension. > > Have enough work already? ;) > > ___tony___ > > >> -----Original Message----- > >> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com] > >> Sent: Wednesday, September 09, 1998 1:16 PM > >> To: Mike Smith; william.burr@nist.gov; BJUENEMAN@novell.com > >> Cc: ietf-pkix@imc.org > >> Subject: RE: New Extension Proposed: Method Of Authentication > >> > >> > In using certificates, it is useful to know what form of > >> > authentication is used by a CA to identify a new certificate > >> > requester. A certificate extension seems the best place to store > > >> > this information. > >> > >> This sounds to me like a trip into a quagmire. I don't think that > >> it is possible to charaterize authentication mechanisms usefully > >> in a set of binary flags. > >> > >> For example two CAs may be requiring presentation of a driving > >> license for authentication, only one CA may be using a state of > >> MA license with photo ID and another a UK driving license without > >> photo ID. > >> > >> Even with documents such as passports there is considerable > >> variation between countries in the strictness of their proceedures. > >> > >> Then there are proceedural variations, is the applicant present > >> in person or were the credentials merely faxed... > >> > >> > >> Nor is the mechanism of authentication by itself particularly > >> usefull unless there is an evaluation of the reliability of the > >> party performing it. > >> > >> Of course one can start to characterise these characteristics > >> as well but to do so merely throws up yet more information which > >> might be relevant, factors which become increasingly subjective. > >> > >> > >> This is a hard AI problem - establishing a shared vocabulary of > >> terms which permits exchange of concepts whose semantics are > >> not embedded in the communication mechanism or indeed any > >> mechanism for which a formal description is available. > >> > >> Phill > > > > > > Tony Bartoletti LL > SPI-NET GURU LL LL > Computer Security Technology Center LL LL LL > Lawrence Livermore National Lab LL LL LL > PO Box 808, L - 303 LL LL LLLLLLLL > Livermore, CA 94551-9900 LL LLLLLLLL > email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25432 for ietf-pkix-bks; Wed, 9 Sep 1998 12:19:09 -0700 (PDT) Received: from slack.lne.com (NoBody@slack.lne.com [140.174.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25428 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 12:19:07 -0700 (PDT) Received: (from ericm@localhost) by slack.lne.com (8.9.0/8.9.0) id MAA11040; Wed, 9 Sep 1998 12:24:19 -0700 From: Eric Murray <ericm@lne.com> Message-Id: <199809091924.MAA11040@slack.lne.com> Subject: Re: New Extension Proposed: Method Of Authentication To: chokhani@cygnacom.com (Santosh Chokhani) Date: Wed, 9 Sep 1998 12:24:18 -0700 (PDT) Cc: pbaker@verisign.com, mfsmith@zionsbank.com, william.burr@nist.gov, BJUENEMAN@novell.com, ietf-pkix@imc.org In-Reply-To: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> from "Santosh Chokhani" at Sep 9, 98 01:44:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Santosh Chokhani writes: > > The subscriber authentication at the various stages (such as initial > registration, registration after revocation, revocation request, normal > rekey, etc.) is supposed to be described in the certificate policy. > Thus, the certificate policy asserted points to the authentication > method. > > There is NO need for another extension. I agree that putting the policy into an extension is a quagmire. However, given that most CPSs will be on web sites, and those CPSs can be changed at any time, should there be a way to indicate which CPS is in effect at any given time during the certificate's life? Say Fred is issued a cert by Carl the CA. Carl signs Fred's cert under the then-current CPS 1.2, which required Carl to verify Fred's identity using dental charts. Sometime later, Carl changes his CPS to version 1.3, which no longer requires dental charts as a form of identification, but instead accepts a state driver's license. Fred would like to sign a contract to purchase a house. The lender requires a high-quality signature, and a cert with only a state driver's license as identification isn't good enough. How does Fred indicate that his cert was issued under the older, more rigorous CPS? One way to deal with this is to revoke all certs issued under a given CPS when it is changed. I'm not sure that that provides any assurance that a given cert was issued under the current CPS though- a receiving party would have to depend on the current CPS stating that such is the policy. And it's obviously very undesireable from a CA standpoint. Another way would be to require the CA to sign their CPSs and include version numbers, and to include in the cert extension which points to the CPS, the version number of the CPS which was in effect when the cert was issued. This will prevent CAs from updating CPSs "out from underneath" existing certs. That may or may not be a desired effect. I did a very quick read of the draft and didn't see anything that handles this problem. But I have not been following the discussion very much and have not studied the draft, so I could well have missed it. If there's already something in the draft to deal with this, or this subject has already been discussed on the list, please accept my apologies. -- Eric Murray N*Able Technologies www.nabletech.com (email: ericm at the sites lne.com or nabletech.com) PGP keyid:E03F65E5 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25299 for ietf-pkix-bks; Wed, 9 Sep 1998 12:07:59 -0700 (PDT) Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25295 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 12:07:58 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id MAA14051; Wed, 9 Sep 1998 12:13:05 -0700 (PDT) Message-Id: <3.0.3.32.19980909121219.0094d830@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 09 Sep 1998 12:12:19 -0700 To: Santosh Chokhani <chokhani@cygnacom.com>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Mike Smith <mfsmith@zionsbank.com>, william.burr@nist.gov, BJUENEMAN@novell.com From: Tony Bartoletti <azb@llnl.gov> Subject: RE: New Extension Proposed: Method Of Authentication Cc: ietf-pkix@imc.org In-Reply-To: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk At 01:44 PM 9/9/98 -0400, Santosh Chokhani wrote: >The subscriber authentication at the various stages (such as initial >registration, registration after revocation, revocation request, normal >rekey, etc.) is supposed to be described in the certificate policy. >Thus, the certificate policy asserted points to the authentication >method. True, but this certainly places a limit upon the degree of automation that can be employed in the future, at least until we have software that can read a CPS and base decisions upon it. No time soon. Granted, some 20 bits describing authentication method(s) would be contentious, but the very exercise would reveal much about where and how trust is really anchored, and the degree to which automated agents could evolve. >There is NO need for another extension. Have enough work already? ;) ___tony___ >> -----Original Message----- >> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com] >> Sent: Wednesday, September 09, 1998 1:16 PM >> To: Mike Smith; william.burr@nist.gov; BJUENEMAN@novell.com >> Cc: ietf-pkix@imc.org >> Subject: RE: New Extension Proposed: Method Of Authentication >> >> > In using certificates, it is useful to know what form of >> > authentication is used by a CA to identify a new certificate >> > requester. A certificate extension seems the best place to store >> > this information. >> >> This sounds to me like a trip into a quagmire. I don't think that >> it is possible to charaterize authentication mechanisms usefully >> in a set of binary flags. >> >> For example two CAs may be requiring presentation of a driving >> license for authentication, only one CA may be using a state of >> MA license with photo ID and another a UK driving license without >> photo ID. >> >> Even with documents such as passports there is considerable >> variation between countries in the strictness of their proceedures. >> >> Then there are proceedural variations, is the applicant present >> in person or were the credentials merely faxed... >> >> >> Nor is the mechanism of authentication by itself particularly >> usefull unless there is an evaluation of the reliability of the >> party performing it. >> >> Of course one can start to characterise these characteristics >> as well but to do so merely throws up yet more information which >> might be relevant, factors which become increasingly subjective. >> >> >> This is a hard AI problem - establishing a shared vocabulary of >> terms which permits exchange of concepts whose semantics are >> not embedded in the communication mechanism or indeed any >> mechanism for which a formal description is available. >> >> Phill > > Tony Bartoletti LL SPI-NET GURU LL LL Computer Security Technology Center LL LL LL Lawrence Livermore National Lab LL LL LL PO Box 808, L - 303 LL LL LLLLLLLL Livermore, CA 94551-9900 LL LLLLLLLL email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25087 for ietf-pkix-bks; Wed, 9 Sep 1998 11:49:37 -0700 (PDT) Received: from relay1.eds.com (relay1.eds.com [199.228.142.73]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25082 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 11:49:36 -0700 (PDT) From: randy.sanovic@gm.com Received: from nnsa.eds.com (nnsa.eds.com [192.85.154.30] (may be forged)) by relay1.eds.com (8.8.8/8.8.8) with ESMTP id OAA19121 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 14:54:51 -0400 (EDT) Received: from usabhmg01.mail.gm.com ([207.37.138.86]) by nnsa.eds.com (8.8.8/8.8.8) with SMTP id OAA04446 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 14:54:20 -0400 (EDT) Received: by usabhmg01.mail.gm.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 0525667A.006D0EAA ; Wed, 9 Sep 1998 14:51:11 -0500 X-Lotus-FromDomain: GM To: ietf-pkix@imc.org Message-ID: <0525667A.006CF616.00@usabhmg01.mail.gm.com> Date: Wed, 9 Sep 1998 14:51:15 -0500 Subject: For Option 2 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk For Option 2 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24576 for ietf-pkix-bks; Wed, 9 Sep 1998 10:59:45 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24572 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 10:59:44 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ8JL>; Wed, 9 Sep 1998 14:04:53 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A65@WUHER> From: Santosh Chokhani <chokhani@cygnacom.com> To: "'Kurn, David'" <david.kurn@compaq.com>, Santosh Chokhani <chokhani@cygnacom.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: RE: forward & reverse elements - population Date: Wed, 9 Sep 1998 14:04:50 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk You seem to have captured the essence. Please note that the preference could be reversed depending on the application need and/or the environment. You have to try a search to the end. I do not think in graphs like this there is an a priory way of encoding which links will lead to which paths. Depth first (or up to some depth) search is likely to be the PKI path development strategy in combination with judicious use of AKID, SKID, key usage, pathToName, and certificate policy matching rules. > -----Original Message----- > From: Kurn, David [SMTP:david.kurn@compaq.com] > Sent: Wednesday, September 09, 1998 1:51 PM > To: 'Santosh Chokhani'; 'Sharon Boeyen'; 'ietf-pkix@imc.org' > Subject: RE: forward & reverse elements - population > > Santosh > > Hmm.... I think I see. Perhaps the problem arises because of your use > of > the word domain. Consider your 2nd and 3rd paragraph rewritten to > omit the > word "domain", such as: > > The relying party will start with the assumption that the > subscriber with whom it is trying to form a key management > certificate > path or digital signature certificate verification path is > reachable > by starting with the entries in the caCertificate Attribute. > > If the above search fails, the > relying party will continue with the assumption that the > subscriber > with > whom it is trying to form a key management certificate path or > digital > signature certificate verification path is reachable by using > the > forward element of the crossCertificatePair attribute under > option 1 and forward element of the (crossCertificatePair - > caCertificate) under option 2 first. > > > > Does this capture your intent and avoid the word "domain"? > > Of course, I don't like my algorithm, because it appears to imply a > search > to the end before trying the other branch. > > David Kurn > > > > -----Original Message----- > > From: Santosh Chokhani [SMTP:chokhani@cygnacom.com] > > Sent: Wednesday, September 09, 1998 10:32 AM > > To: Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; > 'ietf-pkix@imc.org' > > Subject: RE: forward & reverse elements - population > > > > Let us say an application requires more communication within a > domain. > > > > Then the relying party will start with the assumption that the > > subscriber with whom it is trying to form a key management > certificate > > path or digital signature certificate verification path is also in > the > > same domain and hence will follow the caCertificate attribute link > > first. > > > > If the application requires more communication across the domain, > the > > relying party will start with the assumption that the subscriber > with > > whom it is trying to form a key management certificate path or > digital > > signature certificate verification path is in another domain and > hence > > will use forward element of the crossCertificatePair attribute under > > option 1 and forward element of the (crossCertificatePair - > > caCertificate) under option 2 first. > > > > If there is no bias in communication intra or inter domain, the > relying > > party has lost nothing and will always find a trust path, if there > is > > one. > > > <SNIP> Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24448 for ietf-pkix-bks; Wed, 9 Sep 1998 10:45:42 -0700 (PDT) Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24444 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 10:45:41 -0700 (PDT) Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA01170; Wed, 9 Sep 1998 10:50:49 -0700 (PDT) Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04M2FMK>; Wed, 9 Sep 1998 10:50:45 -0700 Message-ID: <418B8B7ACE69D111879B00805F6F281DFFF568@exccup-25006.mis.tandem.com> From: "Kurn, David" <david.kurn@compaq.com> To: "'Santosh Chokhani'" <chokhani@cygnacom.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: RE: forward & reverse elements - population Date: Wed, 9 Sep 1998 10:50:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk Santosh Hmm.... I think I see. Perhaps the problem arises because of your use of the word domain. Consider your 2nd and 3rd paragraph rewritten to omit the word "domain", such as: The relying party will start with the assumption that the subscriber with whom it is trying to form a key management certificate path or digital signature certificate verification path is reachable by starting with the entries in the caCertificate Attribute. If the above search fails, the relying party will continue with the assumption that the subscriber with whom it is trying to form a key management certificate path or digital signature certificate verification path is reachable by using the forward element of the crossCertificatePair attribute under option 1 and forward element of the (crossCertificatePair - caCertificate) under option 2 first. Does this capture your intent and avoid the word "domain"? Of course, I don't like my algorithm, because it appears to imply a search to the end before trying the other branch. David Kurn > -----Original Message----- > From: Santosh Chokhani [SMTP:chokhani@cygnacom.com] > Sent: Wednesday, September 09, 1998 10:32 AM > To: Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; 'ietf-pkix@imc.org' > Subject: RE: forward & reverse elements - population > > Let us say an application requires more communication within a domain. > > Then the relying party will start with the assumption that the > subscriber with whom it is trying to form a key management certificate > path or digital signature certificate verification path is also in the > same domain and hence will follow the caCertificate attribute link > first. > > If the application requires more communication across the domain, the > relying party will start with the assumption that the subscriber with > whom it is trying to form a key management certificate path or digital > signature certificate verification path is in another domain and hence > will use forward element of the crossCertificatePair attribute under > option 1 and forward element of the (crossCertificatePair - > caCertificate) under option 2 first. > > If there is no bias in communication intra or inter domain, the relying > party has lost nothing and will always find a trust path, if there is > one. > <SNIP> Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24302 for ietf-pkix-bks; Wed, 9 Sep 1998 10:39:26 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24298 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 10:39:24 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ820>; Wed, 9 Sep 1998 13:44:33 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A64@WUHER> From: Santosh Chokhani <chokhani@cygnacom.com> To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Mike Smith <mfsmith@zionsbank.com>, william.burr@nist.gov, BJUENEMAN@novell.com Cc: ietf-pkix@imc.org Subject: RE: New Extension Proposed: Method Of Authentication Date: Wed, 9 Sep 1998 13:44:32 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk The subscriber authentication at the various stages (such as initial registration, registration after revocation, revocation request, normal rekey, etc.) is supposed to be described in the certificate policy. Thus, the certificate policy asserted points to the authentication method. There is NO need for another extension. > -----Original Message----- > From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com] > Sent: Wednesday, September 09, 1998 1:16 PM > To: Mike Smith; william.burr@nist.gov; BJUENEMAN@novell.com > Cc: ietf-pkix@imc.org > Subject: RE: New Extension Proposed: Method Of Authentication > > > In using certificates, it is useful to know what form of > > authentication is used by a CA to identify a new certificate > > requester. A certificate extension seems the best place to store > > this information. > > This sounds to me like a trip into a quagmire. I don't think that > it is possible to charaterize authentication mechanisms usefully > in a set of binary flags. > > For example two CAs may be requiring presentation of a driving > license for authentication, only one CA may be using a state of > MA license with photo ID and another a UK driving license without > photo ID. > > Even with documents such as passports there is considerable > variation between countries in the strictness of their proceedures. > > Then there are proceedural variations, is the applicant present > in person or were the credentials merely faxed... > > > Nor is the mechanism of authentication by itself particularly > usefull unless there is an evaluation of the reliability of the > party performing it. > > Of course one can start to characterise these characteristics > as well but to do so merely throws up yet more information which > might be relevant, factors which become increasingly subjective. > > > This is a hard AI problem - establishing a shared vocabulary of > terms which permits exchange of concepts whose semantics are > not embedded in the communication mechanism or indeed any > mechanism for which a formal description is available. > > Phill Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24200 for ietf-pkix-bks; Wed, 9 Sep 1998 10:27:25 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24196 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 10:27:22 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ82Z>; Wed, 9 Sep 1998 13:32:31 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A62@WUHER> From: Santosh Chokhani <chokhani@cygnacom.com> To: "'Kurn, David'" <david.kurn@compaq.com>, Santosh Chokhani <chokhani@cygnacom.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: RE: forward & reverse elements - population Date: Wed, 9 Sep 1998 13:32:28 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Let us say an application requires more communication within a domain. Then the relying party will start with the assumption that the subscriber with whom it is trying to form a key management certificate path or digital signature certificate verification path is also in the same domain and hence will follow the caCertificate attribute link first. If the application requires more communication across the domain, the relying party will start with the assumption that the subscriber with whom it is trying to form a key management certificate path or digital signature certificate verification path is in another domain and hence will use forward element of the crossCertificatePair attribute under option 1 and forward element of the (crossCertificatePair - caCertificate) under option 2 first. If there is no bias in communication intra or inter domain, the relying party has lost nothing and will always find a trust path, if there is one. > -----Original Message----- > From: Kurn, David [SMTP:david.kurn@compaq.com] > Sent: Wednesday, September 09, 1998 1:12 PM > To: 'Santosh Chokhani'; 'Sharon Boeyen'; 'ietf-pkix@imc.org' > Subject: RE: forward & reverse elements - population > > Santosh > > I seem to sense a circularity of definition. If I interpret your > comment > correctly, you place a cert in the caCertificate attribute if it > belongs to > the same domain, and you can determine that it's in the same domain by > seeing if it's in the caCertificate attribute. Exactly how I would > use this > in a computer program is unclear. Perhaps you could sketch out some > program logic one would use. > > David > > > -----Original Message----- > > From: Santosh Chokhani [SMTP:chokhani@cygnacom.com] > > Sent: Wednesday, September 09, 1998 9:53 AM > > To: Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; > 'ietf-pkix@imc.org' > > Subject: RE: forward & reverse elements - population > > > > David: > > > > In both options 1 and 2, a relying party can determine which issuing > CAs > > are considered in the domain of the subject CA by looking at > > caCertificate attribute and the forward element of the > > crossCertificatePair attribute. > > > > In option 1, it is straightforward. > > > > In option 2, you have to subtract the caCertificate from the > > crossCertificatePair to get the two sets. > > > > These two domains are from the subject CA's perspective. It may or > may > > not be in the domain of the relying party. > > > > > -----Original Message----- > > > From: Kurn, David [SMTP:david.kurn@compaq.com] > > > Sent: Wednesday, September 09, 1998 12:16 PM > > > To: 'Santosh Chokhani'; 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > > Subject: RE: forward & reverse elements - population > > > > > > Santosh > > > > > > Sorry to ask what must be a very naive question. If, as you > suggest, > > > the > > > "definition of a domain is purely a matter of local policy", then > I > > > think > > > that the term "domain" is undefined for the purposes of a > standard. > > > If so, > > > then I find it difficult to define any algorhithm (not necessarily > > > computer > > > based) or any process by which anyone could determine whether a CA > is > > > in the > > > same or a different domain. > > > > > > Think, for example, of a general purpose application program (like > a > > > mail > > > client) trying to answer the question "is that CA inside or > outside of > > > my > > > domain". > > > > > > Back in my college days, my math professors made it painfully > clear > > > that if > > > you define a set, you must also provide a rule whereby you can > > > determine > > > whether a given element is inside or outside of that set. Without > > > such a > > > rule, the set is undefined. > > > > > > It may be that the definition of "domain" is elsewhere in the > > > document, but > > > I cannot find it. > > > > > > David Kurn > > > Compaq Computer Corp > > > Electronic Commerce Stuff > > > > > > > -----Original Message----- > > > > From: Santosh Chokhani [SMTP:chokhani@cygnacom.com] > > > > Sent: Wednesday, September 09, 1998 8:27 AM > > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org'; Santosh Chokhani > > > > Subject: RE: forward & reverse elements - population > > > > > > > > Yes. I agree. The following is the revised text. > > > > > > > > NEW PROPOSED TEXT FOR OPTION 1 > > > > > > > > The cACertificate attribute, held in a particular CA's directory > > > entry, > > > > shall be used to store certificates issued to this CA by CAs in > the > > > same > > > > domain as this CA. If there are any self-issued certificates > and > > > they > > > > require publication, the caCertificate attribute shall be used > to > > > store > > > > them. > > > > > > > > The forward element of the crossCertificatePair attribute, held > in a > > > > particular CA's directory entry, shall be used to store > certificates > > > > issued to this CA by CAs in other domains. Optionally, the > reverse > > > > element of the crossCertificatePair attribute, held in a > particular > > > CA's > > > > directory entry, may contain a subset of certificates issued by > this > > > CA > > > > to other CAs. When both the forward and the reverse elements > are > > > > present, issuer name in one certificate shall match the subject > name > > > in > > > > the other and vice versa, and the subject public key in one > > > certificate > > > > shall be capable of verifying the digital signature on the other > > > > certificate and vice versa. > > > > > > > > In the case of V3 certificates, none of the above CA > certificates > > > shall > > > > include a basicConstraints extension with the cA value set to > FALSE. > > > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > > NEW PROPOSED TEXT FOR OPTION 2 > > > > > > > > The cACertificate attribute, held in a particular CA's directory > > > entry, > > > > shall be used to store certificates issued to this CA by CAs in > the > > > same > > > > domain as this CA. If there are any self-issued certificates > and > > > they > > > > require publication, the caCertificate attribute shall be used > to > > > store > > > > them. > > > > > > > > The forward element of the crossCertificatePair attribute, held > in a > > > > particular CA's directory entry, shall be used to store all > > > certificates > > > > issued to this CA. Optionally, the reverse element of the > > > > crossCertificatePair attribute, held in a particular CA's > directory > > > > entry, may contain a subset of certificates issued by this CA to > > > other > > > > CAs. When both the forward and the reverse elements are > present, > > > issuer > > > > name in one certificate shall match the subject name in the > other > > > and > > > > vice versa, and the subject public key in one certificate shall > be > > > > capable of verifying the digital signature on the other > certificate > > > and > > > > vice versa. > > > > > > > > In the case of V3 certificates, none of the above CA > certificates > > > shall > > > > include a basicConstraints extension with the cA value set to > FALSE. > > > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > > > -----Original Message----- > > > > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > > > > Sent: Wednesday, September 09, 1998 11:02 AM > > > > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > I agree that the texts below are consistent with the original > > > intent > > > > > of the > > > > > 2 options and I also agree that they are clearer than the > original > > > > > texts > > > > > except, possibly for coverage of self issued certificates. > > > Shouldn't > > > > > we also > > > > > state explicitly that self issued certs are stored only in the > > > > > cACertificate > > > > > attribute for both options? > > > > > > > > > > > > > > > > ---------- > > > > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > > > > Sent: September 9, 1998 9:08 AM > > > > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org'; Santosh > Chokhani > > > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > > > Sharon: > > > > > > > > > > > > I can agree to the following text for the two option > instead. > > > > > Please > > > > > > note that I have further clarified cross-certificate by > tying > > > the DN > > > > > and > > > > > > public keys. > > > > > > > > > > > > I think the following texts are consistent with and further > > > > > > clarifications of the two options. > > > > > > > > > > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1. > > > > > > > > > > > And I option 2 :-) > > > > > > > > > > > NEW PROPOSED TEXT FOR OPTION 1 > > > > > > > > > > > > The cACertificate attribute, held in a particular CA's > directory > > > > > entry, > > > > > > shall be used to store certificates issued to this CA by CAs > in > > > the > > > > > same > > > > > > domain as this CA. > > > > > > > > > > > > The forward element of the crossCertificatePair attribute, > held > > > in a > > > > > > particular CA's directory entry, shall be used to store > > > certificates > > > > > > issued to this CA by CAs in other domains. Optionally, the > > > reverse > > > > > > element of the crossCertificatePair attribute, held in a > > > particular > > > > > CA's > > > > > > directory entry, may contain a subset of certificates issued > by > > > this > > > > > CA > > > > > > to other CAs. When both the forward and the reverse > elements > > > are > > > > > > present, issuer name in one certificate shall match the > subject > > > name > > > > > in > > > > > > the other and vice versa, and the subject public key in one > > > > > certificate > > > > > > shall be capable of verifying the digital signature on the > other > > > > > > certificate and vice versa. > > > > > > > > > > > > In the case of V3 certificates, none of the above CA > > > certificates > > > > > shall > > > > > > include a basicConstraints extension with the cA value set > to > > > FALSE. > > > > > > > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > > > > > > NEW PROPOSED TEXT FOR OPTION 2 > > > > > > > > > > > > The cACertificate attribute, held in a particular CA's > directory > > > > > entry, > > > > > > shall be used to store certificates issued to this CA by CAs > in > > > the > > > > > same > > > > > > domain as this CA. > > > > > > > > > > > > The forward element of the crossCertificatePair attribute, > held > > > in a > > > > > > particular CA's directory entry, shall be used to store all > > > > > certificates > > > > > > issued to this CA. Optionally, the reverse element of the > > > > > > crossCertificatePair attribute, held in a particular CA's > > > directory > > > > > > entry, may contain a subset of certificates issued by this > CA to > > > > > other > > > > > > CAs. When both the forward and the reverse elements are > > > present, > > > > > issuer > > > > > > name in one certificate shall match the subject name in the > > > other > > > > > and > > > > > > vice versa, and the subject public key in one certificate > shall > > > be > > > > > > capable of verifying the digital signature on the other > > > certificate > > > > > and > > > > > > vice versa. > > > > > > > > > > > > In the case of V3 certificates, none of the above CA > > > certificates > > > > > shall > > > > > > include a basicConstraints extension with the cA value set > to > > > FALSE. > > > > > > > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > > > > > > Sent: Tuesday, September 08, 1998 5:46 PM > > > > > > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > > > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------- > > > > > > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > > > > > > Sent: September 8, 1998 10:05 AM > > > > > > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > > > > > > > Subject: RE: forward & reverse elements - > population > > > > > > > > > > > > > > > --stuff deleted > > > > > > > > > > > > > > > > > [] I agree. I do not have problem with the > following > > > > > language. > > > > > > > > " A certificate issued to a CA by another shall be > stored > > > either > > > > > in > > > > > > > the > > > > > > > > caCertificate or forward component of > crossCertificatePair > > > > > attribute > > > > > > > of > > > > > > > > the subject CA. Optionally, a subset of certificates > issued > > > by > > > > > a CA > > > > > > > can > > > > > > > > be stored in the reverse component of > crossCertificatePair > > > > > attribute > > > > > > > of > > > > > > > > the issuing CA." > > > > > > > > > > > > > > > > Please note that to me subset includes none, > some, or > > > > > all. If > > > > > > > > folks want further clarification, it is ok by me. > > > > > > > > > > > > > > > Santosh, the only issue I have with this text is that (at > > > least > > > > > with > > > > > > > the > > > > > > > rationale behind option 2) any cert that appears in the > > > > > cACertificate > > > > > > > attribute of a given CA > > > > > > > entry, should also appear in the crossCertificatePair > > > attribute in > > > > > the > > > > > > > same > > > > > > > CA entry. > > > > > > > What about deleting the reference to the cACertificate > > > attribute > > > > > from > > > > > > > your > > > > > > > text and proposing this as new text just for the > > > > > crossCertificatePair > > > > > > > attribute? > > > > > > > > > > > > > > Both Jan and David have indicated reasons to keep the > "pair" > > > > > together > > > > > > > in the > > > > > > > mutual case, so we should also consider adding the last > > > paragraph > > > > > of > > > > > > > the > > > > > > > text David proposed for that. > > > > > > > > > > > > > > Here's what the resulting text proposal would look like: > > > > > > > > > > > > > > > " A certificate issued to a CA by another shall be > stored in > > > the > > > > > > > > forward component of crossCertificatePair attribute of > > > > > > > > the subject CA. Optionally, a subset of certificates > issued > > > by > > > > > a CA > > > > > > > can > > > > > > > > be stored in the reverse component of > crossCertificatePair > > > > > attribute > > > > > > > of > > > > > > > > the issuing CA. When both elements are present in the > same > > > > > value, > > > > > > > the > > > > > > > > value shall represent a mutual cross-certification of > the > > > two > > > > > CAs. " > > > > > > > > > > > > > > > If we can come to consensus on that attribute, then let's > see > > > what > > > > > we > > > > > > > can do > > > > > > > with the cACertificate attribute text. > > > > > > > > > > > > > > I agree with your view on what a subset is and I think > that > > > same > > > > > > > definition > > > > > > > would apply to the contents of the cACertificate attribute > as > > > a > > > > > subset > > > > > > > of > > > > > > > the crossCertificatePair forward elements in option 2. > > > > > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23916 for ietf-pkix-bks; Wed, 9 Sep 1998 10:11:15 -0700 (PDT) Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23912 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 10:11:01 -0700 (PDT) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA26409; Wed, 9 Sep 1998 10:13:52 -0700 (PDT) Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA05799; Wed, 9 Sep 1998 10:15:38 -0700 (PDT) From: "Phillip M Hallam-Baker" <pbaker@verisign.com> To: "Mike Smith" <mfsmith@zionsbank.com>, <william.burr@nist.gov>, <BJUENEMAN@novell.com> Cc: <ietf-pkix@imc.org> Subject: RE: New Extension Proposed: Method Of Authentication Date: Wed, 9 Sep 1998 13:15:46 -0400 Message-ID: <001f01bddc15$7bf63980$ee0110ac@pbaker-pc.verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <s5f6527f.038@zionsbank.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ietf-pkix@imc.org Precedence: bulk > In using certificates, it is useful to know what form of > authentication is used by a CA to identify a new certificate > requester. A certificate extension seems the best place to store > this information. This sounds to me like a trip into a quagmire. I don't think that it is possible to charaterize authentication mechanisms usefully in a set of binary flags. For example two CAs may be requiring presentation of a driving license for authentication, only one CA may be using a state of MA license with photo ID and another a UK driving license without photo ID. Even with documents such as passports there is considerable variation between countries in the strictness of their proceedures. Then there are proceedural variations, is the applicant present in person or were the credentials merely faxed... Nor is the mechanism of authentication by itself particularly usefull unless there is an evaluation of the reliability of the party performing it. Of course one can start to characterise these characteristics as well but to do so merely throws up yet more information which might be relevant, factors which become increasingly subjective. This is a hard AI problem - establishing a shared vocabulary of terms which permits exchange of concepts whose semantics are not embedded in the communication mechanism or indeed any mechanism for which a formal description is available. Phill Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23875 for ietf-pkix-bks; Wed, 9 Sep 1998 10:07:22 -0700 (PDT) Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23871 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 10:07:21 -0700 (PDT) Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA25223; Wed, 9 Sep 1998 10:12:27 -0700 (PDT) Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04M21Q3>; Wed, 9 Sep 1998 10:12:23 -0700 Message-ID: <418B8B7ACE69D111879B00805F6F281DFFF566@exccup-25006.mis.tandem.com> From: "Kurn, David" <david.kurn@compaq.com> To: "'Santosh Chokhani'" <chokhani@cygnacom.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: RE: forward & reverse elements - population Date: Wed, 9 Sep 1998 10:12:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Santosh I seem to sense a circularity of definition. If I interpret your comment correctly, you place a cert in the caCertificate attribute if it belongs to the same domain, and you can determine that it's in the same domain by seeing if it's in the caCertificate attribute. Exactly how I would use this in a computer program is unclear. Perhaps you could sketch out some program logic one would use. David > -----Original Message----- > From: Santosh Chokhani [SMTP:chokhani@cygnacom.com] > Sent: Wednesday, September 09, 1998 9:53 AM > To: Kurn, David; Santosh Chokhani; 'Sharon Boeyen'; 'ietf-pkix@imc.org' > Subject: RE: forward & reverse elements - population > > David: > > In both options 1 and 2, a relying party can determine which issuing CAs > are considered in the domain of the subject CA by looking at > caCertificate attribute and the forward element of the > crossCertificatePair attribute. > > In option 1, it is straightforward. > > In option 2, you have to subtract the caCertificate from the > crossCertificatePair to get the two sets. > > These two domains are from the subject CA's perspective. It may or may > not be in the domain of the relying party. > > > -----Original Message----- > > From: Kurn, David [SMTP:david.kurn@compaq.com] > > Sent: Wednesday, September 09, 1998 12:16 PM > > To: 'Santosh Chokhani'; 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > Subject: RE: forward & reverse elements - population > > > > Santosh > > > > Sorry to ask what must be a very naive question. If, as you suggest, > > the > > "definition of a domain is purely a matter of local policy", then I > > think > > that the term "domain" is undefined for the purposes of a standard. > > If so, > > then I find it difficult to define any algorhithm (not necessarily > > computer > > based) or any process by which anyone could determine whether a CA is > > in the > > same or a different domain. > > > > Think, for example, of a general purpose application program (like a > > mail > > client) trying to answer the question "is that CA inside or outside of > > my > > domain". > > > > Back in my college days, my math professors made it painfully clear > > that if > > you define a set, you must also provide a rule whereby you can > > determine > > whether a given element is inside or outside of that set. Without > > such a > > rule, the set is undefined. > > > > It may be that the definition of "domain" is elsewhere in the > > document, but > > I cannot find it. > > > > David Kurn > > Compaq Computer Corp > > Electronic Commerce Stuff > > > > > -----Original Message----- > > > From: Santosh Chokhani [SMTP:chokhani@cygnacom.com] > > > Sent: Wednesday, September 09, 1998 8:27 AM > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org'; Santosh Chokhani > > > Subject: RE: forward & reverse elements - population > > > > > > Yes. I agree. The following is the revised text. > > > > > > NEW PROPOSED TEXT FOR OPTION 1 > > > > > > The cACertificate attribute, held in a particular CA's directory > > entry, > > > shall be used to store certificates issued to this CA by CAs in the > > same > > > domain as this CA. If there are any self-issued certificates and > > they > > > require publication, the caCertificate attribute shall be used to > > store > > > them. > > > > > > The forward element of the crossCertificatePair attribute, held in a > > > particular CA's directory entry, shall be used to store certificates > > > issued to this CA by CAs in other domains. Optionally, the reverse > > > element of the crossCertificatePair attribute, held in a particular > > CA's > > > directory entry, may contain a subset of certificates issued by this > > CA > > > to other CAs. When both the forward and the reverse elements are > > > present, issuer name in one certificate shall match the subject name > > in > > > the other and vice versa, and the subject public key in one > > certificate > > > shall be capable of verifying the digital signature on the other > > > certificate and vice versa. > > > > > > In the case of V3 certificates, none of the above CA certificates > > shall > > > include a basicConstraints extension with the cA value set to FALSE. > > > > > > The definition of domain is purely a matter of local policy. > > > > > > NEW PROPOSED TEXT FOR OPTION 2 > > > > > > The cACertificate attribute, held in a particular CA's directory > > entry, > > > shall be used to store certificates issued to this CA by CAs in the > > same > > > domain as this CA. If there are any self-issued certificates and > > they > > > require publication, the caCertificate attribute shall be used to > > store > > > them. > > > > > > The forward element of the crossCertificatePair attribute, held in a > > > particular CA's directory entry, shall be used to store all > > certificates > > > issued to this CA. Optionally, the reverse element of the > > > crossCertificatePair attribute, held in a particular CA's directory > > > entry, may contain a subset of certificates issued by this CA to > > other > > > CAs. When both the forward and the reverse elements are present, > > issuer > > > name in one certificate shall match the subject name in the other > > and > > > vice versa, and the subject public key in one certificate shall be > > > capable of verifying the digital signature on the other certificate > > and > > > vice versa. > > > > > > In the case of V3 certificates, none of the above CA certificates > > shall > > > include a basicConstraints extension with the cA value set to FALSE. > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > -----Original Message----- > > > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > > > Sent: Wednesday, September 09, 1998 11:02 AM > > > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > > > Subject: RE: forward & reverse elements - population > > > > > > > > I agree that the texts below are consistent with the original > > intent > > > > of the > > > > 2 options and I also agree that they are clearer than the original > > > > texts > > > > except, possibly for coverage of self issued certificates. > > Shouldn't > > > > we also > > > > state explicitly that self issued certs are stored only in the > > > > cACertificate > > > > attribute for both options? > > > > > > > > > > > > > ---------- > > > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > > > Sent: September 9, 1998 9:08 AM > > > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org'; Santosh Chokhani > > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > Sharon: > > > > > > > > > > I can agree to the following text for the two option instead. > > > > Please > > > > > note that I have further clarified cross-certificate by tying > > the DN > > > > and > > > > > public keys. > > > > > > > > > > I think the following texts are consistent with and further > > > > > clarifications of the two options. > > > > > > > > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1. > > > > > > > > > And I option 2 :-) > > > > > > > > > NEW PROPOSED TEXT FOR OPTION 1 > > > > > > > > > > The cACertificate attribute, held in a particular CA's directory > > > > entry, > > > > > shall be used to store certificates issued to this CA by CAs in > > the > > > > same > > > > > domain as this CA. > > > > > > > > > > The forward element of the crossCertificatePair attribute, held > > in a > > > > > particular CA's directory entry, shall be used to store > > certificates > > > > > issued to this CA by CAs in other domains. Optionally, the > > reverse > > > > > element of the crossCertificatePair attribute, held in a > > particular > > > > CA's > > > > > directory entry, may contain a subset of certificates issued by > > this > > > > CA > > > > > to other CAs. When both the forward and the reverse elements > > are > > > > > present, issuer name in one certificate shall match the subject > > name > > > > in > > > > > the other and vice versa, and the subject public key in one > > > > certificate > > > > > shall be capable of verifying the digital signature on the other > > > > > certificate and vice versa. > > > > > > > > > > In the case of V3 certificates, none of the above CA > > certificates > > > > shall > > > > > include a basicConstraints extension with the cA value set to > > FALSE. > > > > > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > > > > NEW PROPOSED TEXT FOR OPTION 2 > > > > > > > > > > The cACertificate attribute, held in a particular CA's directory > > > > entry, > > > > > shall be used to store certificates issued to this CA by CAs in > > the > > > > same > > > > > domain as this CA. > > > > > > > > > > The forward element of the crossCertificatePair attribute, held > > in a > > > > > particular CA's directory entry, shall be used to store all > > > > certificates > > > > > issued to this CA. Optionally, the reverse element of the > > > > > crossCertificatePair attribute, held in a particular CA's > > directory > > > > > entry, may contain a subset of certificates issued by this CA to > > > > other > > > > > CAs. When both the forward and the reverse elements are > > present, > > > > issuer > > > > > name in one certificate shall match the subject name in the > > other > > > > and > > > > > vice versa, and the subject public key in one certificate shall > > be > > > > > capable of verifying the digital signature on the other > > certificate > > > > and > > > > > vice versa. > > > > > > > > > > In the case of V3 certificates, none of the above CA > > certificates > > > > shall > > > > > include a basicConstraints extension with the cA value set to > > FALSE. > > > > > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > > > > > Sent: Tuesday, September 08, 1998 5:46 PM > > > > > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > > > > > > > > > > > > > > > > ---------- > > > > > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > > > > > Sent: September 8, 1998 10:05 AM > > > > > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > > > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > > > > --stuff deleted > > > > > > > > > > > > > > > [] I agree. I do not have problem with the following > > > > language. > > > > > > > " A certificate issued to a CA by another shall be stored > > either > > > > in > > > > > > the > > > > > > > caCertificate or forward component of crossCertificatePair > > > > attribute > > > > > > of > > > > > > > the subject CA. Optionally, a subset of certificates issued > > by > > > > a CA > > > > > > can > > > > > > > be stored in the reverse component of crossCertificatePair > > > > attribute > > > > > > of > > > > > > > the issuing CA." > > > > > > > > > > > > > > Please note that to me subset includes none, some, or > > > > all. If > > > > > > > folks want further clarification, it is ok by me. > > > > > > > > > > > > > Santosh, the only issue I have with this text is that (at > > least > > > > with > > > > > > the > > > > > > rationale behind option 2) any cert that appears in the > > > > cACertificate > > > > > > attribute of a given CA > > > > > > entry, should also appear in the crossCertificatePair > > attribute in > > > > the > > > > > > same > > > > > > CA entry. > > > > > > What about deleting the reference to the cACertificate > > attribute > > > > from > > > > > > your > > > > > > text and proposing this as new text just for the > > > > crossCertificatePair > > > > > > attribute? > > > > > > > > > > > > Both Jan and David have indicated reasons to keep the "pair" > > > > together > > > > > > in the > > > > > > mutual case, so we should also consider adding the last > > paragraph > > > > of > > > > > > the > > > > > > text David proposed for that. > > > > > > > > > > > > Here's what the resulting text proposal would look like: > > > > > > > > > > > > > " A certificate issued to a CA by another shall be stored in > > the > > > > > > > forward component of crossCertificatePair attribute of > > > > > > > the subject CA. Optionally, a subset of certificates issued > > by > > > > a CA > > > > > > can > > > > > > > be stored in the reverse component of crossCertificatePair > > > > attribute > > > > > > of > > > > > > > the issuing CA. When both elements are present in the same > > > > value, > > > > > > the > > > > > > > value shall represent a mutual cross-certification of the > > two > > > > CAs. " > > > > > > > > > > > > > If we can come to consensus on that attribute, then let's see > > what > > > > we > > > > > > can do > > > > > > with the cACertificate attribute text. > > > > > > > > > > > > I agree with your view on what a subset is and I think that > > same > > > > > > definition > > > > > > would apply to the contents of the cACertificate attribute as > > a > > > > subset > > > > > > of > > > > > > the crossCertificatePair forward elements in option 2. > > > > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23614 for ietf-pkix-bks; Wed, 9 Sep 1998 09:48:09 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23601 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 09:48:05 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ81N>; Wed, 9 Sep 1998 12:53:13 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A61@WUHER> From: Santosh Chokhani <chokhani@cygnacom.com> To: "'Kurn, David'" <david.kurn@compaq.com>, Santosh Chokhani <chokhani@cygnacom.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: RE: forward & reverse elements - population Date: Wed, 9 Sep 1998 12:53:12 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk David: In both options 1 and 2, a relying party can determine which issuing CAs are considered in the domain of the subject CA by looking at caCertificate attribute and the forward element of the crossCertificatePair attribute. In option 1, it is straightforward. In option 2, you have to subtract the caCertificate from the crossCertificatePair to get the two sets. These two domains are from the subject CA's perspective. It may or may not be in the domain of the relying party. > -----Original Message----- > From: Kurn, David [SMTP:david.kurn@compaq.com] > Sent: Wednesday, September 09, 1998 12:16 PM > To: 'Santosh Chokhani'; 'Sharon Boeyen'; 'ietf-pkix@imc.org' > Subject: RE: forward & reverse elements - population > > Santosh > > Sorry to ask what must be a very naive question. If, as you suggest, > the > "definition of a domain is purely a matter of local policy", then I > think > that the term "domain" is undefined for the purposes of a standard. > If so, > then I find it difficult to define any algorhithm (not necessarily > computer > based) or any process by which anyone could determine whether a CA is > in the > same or a different domain. > > Think, for example, of a general purpose application program (like a > mail > client) trying to answer the question "is that CA inside or outside of > my > domain". > > Back in my college days, my math professors made it painfully clear > that if > you define a set, you must also provide a rule whereby you can > determine > whether a given element is inside or outside of that set. Without > such a > rule, the set is undefined. > > It may be that the definition of "domain" is elsewhere in the > document, but > I cannot find it. > > David Kurn > Compaq Computer Corp > Electronic Commerce Stuff > > > -----Original Message----- > > From: Santosh Chokhani [SMTP:chokhani@cygnacom.com] > > Sent: Wednesday, September 09, 1998 8:27 AM > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org'; Santosh Chokhani > > Subject: RE: forward & reverse elements - population > > > > Yes. I agree. The following is the revised text. > > > > NEW PROPOSED TEXT FOR OPTION 1 > > > > The cACertificate attribute, held in a particular CA's directory > entry, > > shall be used to store certificates issued to this CA by CAs in the > same > > domain as this CA. If there are any self-issued certificates and > they > > require publication, the caCertificate attribute shall be used to > store > > them. > > > > The forward element of the crossCertificatePair attribute, held in a > > particular CA's directory entry, shall be used to store certificates > > issued to this CA by CAs in other domains. Optionally, the reverse > > element of the crossCertificatePair attribute, held in a particular > CA's > > directory entry, may contain a subset of certificates issued by this > CA > > to other CAs. When both the forward and the reverse elements are > > present, issuer name in one certificate shall match the subject name > in > > the other and vice versa, and the subject public key in one > certificate > > shall be capable of verifying the digital signature on the other > > certificate and vice versa. > > > > In the case of V3 certificates, none of the above CA certificates > shall > > include a basicConstraints extension with the cA value set to FALSE. > > > > The definition of domain is purely a matter of local policy. > > > > NEW PROPOSED TEXT FOR OPTION 2 > > > > The cACertificate attribute, held in a particular CA's directory > entry, > > shall be used to store certificates issued to this CA by CAs in the > same > > domain as this CA. If there are any self-issued certificates and > they > > require publication, the caCertificate attribute shall be used to > store > > them. > > > > The forward element of the crossCertificatePair attribute, held in a > > particular CA's directory entry, shall be used to store all > certificates > > issued to this CA. Optionally, the reverse element of the > > crossCertificatePair attribute, held in a particular CA's directory > > entry, may contain a subset of certificates issued by this CA to > other > > CAs. When both the forward and the reverse elements are present, > issuer > > name in one certificate shall match the subject name in the other > and > > vice versa, and the subject public key in one certificate shall be > > capable of verifying the digital signature on the other certificate > and > > vice versa. > > > > In the case of V3 certificates, none of the above CA certificates > shall > > include a basicConstraints extension with the cA value set to FALSE. > > > > The definition of domain is purely a matter of local policy. > > > > > -----Original Message----- > > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > > Sent: Wednesday, September 09, 1998 11:02 AM > > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > > Subject: RE: forward & reverse elements - population > > > > > > I agree that the texts below are consistent with the original > intent > > > of the > > > 2 options and I also agree that they are clearer than the original > > > texts > > > except, possibly for coverage of self issued certificates. > Shouldn't > > > we also > > > state explicitly that self issued certs are stored only in the > > > cACertificate > > > attribute for both options? > > > > > > > > > > ---------- > > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > > Sent: September 9, 1998 9:08 AM > > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org'; Santosh Chokhani > > > > Subject: RE: forward & reverse elements - population > > > > > > > > Sharon: > > > > > > > > I can agree to the following text for the two option instead. > > > Please > > > > note that I have further clarified cross-certificate by tying > the DN > > > and > > > > public keys. > > > > > > > > I think the following texts are consistent with and further > > > > clarifications of the two options. > > > > > > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1. > > > > > > > And I option 2 :-) > > > > > > > NEW PROPOSED TEXT FOR OPTION 1 > > > > > > > > The cACertificate attribute, held in a particular CA's directory > > > entry, > > > > shall be used to store certificates issued to this CA by CAs in > the > > > same > > > > domain as this CA. > > > > > > > > The forward element of the crossCertificatePair attribute, held > in a > > > > particular CA's directory entry, shall be used to store > certificates > > > > issued to this CA by CAs in other domains. Optionally, the > reverse > > > > element of the crossCertificatePair attribute, held in a > particular > > > CA's > > > > directory entry, may contain a subset of certificates issued by > this > > > CA > > > > to other CAs. When both the forward and the reverse elements > are > > > > present, issuer name in one certificate shall match the subject > name > > > in > > > > the other and vice versa, and the subject public key in one > > > certificate > > > > shall be capable of verifying the digital signature on the other > > > > certificate and vice versa. > > > > > > > > In the case of V3 certificates, none of the above CA > certificates > > > shall > > > > include a basicConstraints extension with the cA value set to > FALSE. > > > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > > NEW PROPOSED TEXT FOR OPTION 2 > > > > > > > > The cACertificate attribute, held in a particular CA's directory > > > entry, > > > > shall be used to store certificates issued to this CA by CAs in > the > > > same > > > > domain as this CA. > > > > > > > > The forward element of the crossCertificatePair attribute, held > in a > > > > particular CA's directory entry, shall be used to store all > > > certificates > > > > issued to this CA. Optionally, the reverse element of the > > > > crossCertificatePair attribute, held in a particular CA's > directory > > > > entry, may contain a subset of certificates issued by this CA to > > > other > > > > CAs. When both the forward and the reverse elements are > present, > > > issuer > > > > name in one certificate shall match the subject name in the > other > > > and > > > > vice versa, and the subject public key in one certificate shall > be > > > > capable of verifying the digital signature on the other > certificate > > > and > > > > vice versa. > > > > > > > > In the case of V3 certificates, none of the above CA > certificates > > > shall > > > > include a basicConstraints extension with the cA value set to > FALSE. > > > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > > > > Sent: Tuesday, September 08, 1998 5:46 PM > > > > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > > > > > > > > > > > > ---------- > > > > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > > > > Sent: September 8, 1998 10:05 AM > > > > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > > --stuff deleted > > > > > > > > > > > > > [] I agree. I do not have problem with the following > > > language. > > > > > > " A certificate issued to a CA by another shall be stored > either > > > in > > > > > the > > > > > > caCertificate or forward component of crossCertificatePair > > > attribute > > > > > of > > > > > > the subject CA. Optionally, a subset of certificates issued > by > > > a CA > > > > > can > > > > > > be stored in the reverse component of crossCertificatePair > > > attribute > > > > > of > > > > > > the issuing CA." > > > > > > > > > > > > Please note that to me subset includes none, some, or > > > all. If > > > > > > folks want further clarification, it is ok by me. > > > > > > > > > > > Santosh, the only issue I have with this text is that (at > least > > > with > > > > > the > > > > > rationale behind option 2) any cert that appears in the > > > cACertificate > > > > > attribute of a given CA > > > > > entry, should also appear in the crossCertificatePair > attribute in > > > the > > > > > same > > > > > CA entry. > > > > > What about deleting the reference to the cACertificate > attribute > > > from > > > > > your > > > > > text and proposing this as new text just for the > > > crossCertificatePair > > > > > attribute? > > > > > > > > > > Both Jan and David have indicated reasons to keep the "pair" > > > together > > > > > in the > > > > > mutual case, so we should also consider adding the last > paragraph > > > of > > > > > the > > > > > text David proposed for that. > > > > > > > > > > Here's what the resulting text proposal would look like: > > > > > > > > > > > " A certificate issued to a CA by another shall be stored in > the > > > > > > forward component of crossCertificatePair attribute of > > > > > > the subject CA. Optionally, a subset of certificates issued > by > > > a CA > > > > > can > > > > > > be stored in the reverse component of crossCertificatePair > > > attribute > > > > > of > > > > > > the issuing CA. When both elements are present in the same > > > value, > > > > > the > > > > > > value shall represent a mutual cross-certification of the > two > > > CAs. " > > > > > > > > > > > If we can come to consensus on that attribute, then let's see > what > > > we > > > > > can do > > > > > with the cACertificate attribute text. > > > > > > > > > > I agree with your view on what a subset is and I think that > same > > > > > definition > > > > > would apply to the contents of the cACertificate attribute as > a > > > subset > > > > > of > > > > > the crossCertificatePair forward elements in option 2. > > > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23427 for ietf-pkix-bks; Wed, 9 Sep 1998 09:34:54 -0700 (PDT) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23423 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 09:34:53 -0700 (PDT) Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Wed, 9 Sep 1998 17:38:36 +0100 X-Mailer: exmh version 2.0.2 2/24/98 To: ietf-pkix@imc.org Subject: For Option 2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Sep 1998 17:38:35 +0100 Message-ID: <21781.905359115@isode.com> From: David Boyce <D.Boyce@isode.com> Sender: owner-ietf-pkix@imc.org Precedence: bulk Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23385 for ietf-pkix-bks; Wed, 9 Sep 1998 09:31:49 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23381 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 09:31:48 -0700 (PDT) Message-Id: <199809091631.JAA23381@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 09 Sep 1998 09:36:53 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: Re: New Extension Proposed: Method Of Authentication In-Reply-To: <s5f6527f.038@zionsbank.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk It seems to me that the certificate policies (section 4.2.1.5) is still the proper place for this. If we create a set of bits that says how the CA is authenticating, unless the statement in the new bits is *exactly* what the CA is using, they should not commit to those bits because someone later can say "but you said you were doing such-and-so". The CPS is under their control. Can you be specific about the advantage of what you are proposing versus the certificate policy? --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23254 for ietf-pkix-bks; Wed, 9 Sep 1998 09:18:59 -0700 (PDT) Received: from hpb.hc-sc.gc.ca (hpb.hc-sc.gc.ca [198.103.237.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23250 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 09:18:58 -0700 (PDT) From: Alan_Buffett@hc-sc.gc.ca Received: from intdns.hwc.ca (intdns.hc-sc.gc.ca [198.103.172.78]) by hpb.hc-sc.gc.ca (8.8.7/8.7.3) with ESMTP id MAA10130 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 12:23:46 -0400 (EDT) Received: from smta00.hc-sc.gc.ca (smta00.hc-sc.gc.ca [142.4.1.25]) by intdns.hwc.ca (8.8.5/8.7.3) with SMTP id MAA21732 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 12:23:44 -0400 (EDT) Received: by smta00.hc-sc.gc.ca(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 8525667A.005A117D ; Wed, 9 Sep 1998 12:23:47 -0400 X-Lotus-FromDomain: HWC To: ietf-pkix@imc.org Message-ID: <8525667A.005A035D.00@smta00.hc-sc.gc.ca> Date: Wed, 9 Sep 1998 12:23:30 -0400 Subject: For Option 2 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@imc.org Precedence: bulk Alan Buffett 09/09/98 12:23 PM Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23155 for ietf-pkix-bks; Wed, 9 Sep 1998 09:10:39 -0700 (PDT) Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23151 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 09:10:38 -0700 (PDT) Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.8.8/2.0.1) with ESMTP id JAA17200; Wed, 9 Sep 1998 09:15:41 -0700 (PDT) Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.1960.3) id <Q04M2DH3>; Wed, 9 Sep 1998 09:15:37 -0700 Message-ID: <418B8B7ACE69D111879B00805F6F281DFFF564@exccup-25006.mis.tandem.com> From: "Kurn, David" <david.kurn@compaq.com> To: "'Santosh Chokhani'" <chokhani@cygnacom.com>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: RE: forward & reverse elements - population Date: Wed, 9 Sep 1998 09:15:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Santosh Sorry to ask what must be a very naive question. If, as you suggest, the "definition of a domain is purely a matter of local policy", then I think that the term "domain" is undefined for the purposes of a standard. If so, then I find it difficult to define any algorhithm (not necessarily computer based) or any process by which anyone could determine whether a CA is in the same or a different domain. Think, for example, of a general purpose application program (like a mail client) trying to answer the question "is that CA inside or outside of my domain". Back in my college days, my math professors made it painfully clear that if you define a set, you must also provide a rule whereby you can determine whether a given element is inside or outside of that set. Without such a rule, the set is undefined. It may be that the definition of "domain" is elsewhere in the document, but I cannot find it. David Kurn Compaq Computer Corp Electronic Commerce Stuff > -----Original Message----- > From: Santosh Chokhani [SMTP:chokhani@cygnacom.com] > Sent: Wednesday, September 09, 1998 8:27 AM > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org'; Santosh Chokhani > Subject: RE: forward & reverse elements - population > > Yes. I agree. The following is the revised text. > > NEW PROPOSED TEXT FOR OPTION 1 > > The cACertificate attribute, held in a particular CA's directory entry, > shall be used to store certificates issued to this CA by CAs in the same > domain as this CA. If there are any self-issued certificates and they > require publication, the caCertificate attribute shall be used to store > them. > > The forward element of the crossCertificatePair attribute, held in a > particular CA's directory entry, shall be used to store certificates > issued to this CA by CAs in other domains. Optionally, the reverse > element of the crossCertificatePair attribute, held in a particular CA's > directory entry, may contain a subset of certificates issued by this CA > to other CAs. When both the forward and the reverse elements are > present, issuer name in one certificate shall match the subject name in > the other and vice versa, and the subject public key in one certificate > shall be capable of verifying the digital signature on the other > certificate and vice versa. > > In the case of V3 certificates, none of the above CA certificates shall > include a basicConstraints extension with the cA value set to FALSE. > > The definition of domain is purely a matter of local policy. > > NEW PROPOSED TEXT FOR OPTION 2 > > The cACertificate attribute, held in a particular CA's directory entry, > shall be used to store certificates issued to this CA by CAs in the same > domain as this CA. If there are any self-issued certificates and they > require publication, the caCertificate attribute shall be used to store > them. > > The forward element of the crossCertificatePair attribute, held in a > particular CA's directory entry, shall be used to store all certificates > issued to this CA. Optionally, the reverse element of the > crossCertificatePair attribute, held in a particular CA's directory > entry, may contain a subset of certificates issued by this CA to other > CAs. When both the forward and the reverse elements are present, issuer > name in one certificate shall match the subject name in the other and > vice versa, and the subject public key in one certificate shall be > capable of verifying the digital signature on the other certificate and > vice versa. > > In the case of V3 certificates, none of the above CA certificates shall > include a basicConstraints extension with the cA value set to FALSE. > > The definition of domain is purely a matter of local policy. > > > -----Original Message----- > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > Sent: Wednesday, September 09, 1998 11:02 AM > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > Subject: RE: forward & reverse elements - population > > > > I agree that the texts below are consistent with the original intent > > of the > > 2 options and I also agree that they are clearer than the original > > texts > > except, possibly for coverage of self issued certificates. Shouldn't > > we also > > state explicitly that self issued certs are stored only in the > > cACertificate > > attribute for both options? > > > > > > > ---------- > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > Sent: September 9, 1998 9:08 AM > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org'; Santosh Chokhani > > > Subject: RE: forward & reverse elements - population > > > > > > Sharon: > > > > > > I can agree to the following text for the two option instead. > > Please > > > note that I have further clarified cross-certificate by tying the DN > > and > > > public keys. > > > > > > I think the following texts are consistent with and further > > > clarifications of the two options. > > > > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1. > > > > > And I option 2 :-) > > > > > NEW PROPOSED TEXT FOR OPTION 1 > > > > > > The cACertificate attribute, held in a particular CA's directory > > entry, > > > shall be used to store certificates issued to this CA by CAs in the > > same > > > domain as this CA. > > > > > > The forward element of the crossCertificatePair attribute, held in a > > > particular CA's directory entry, shall be used to store certificates > > > issued to this CA by CAs in other domains. Optionally, the reverse > > > element of the crossCertificatePair attribute, held in a particular > > CA's > > > directory entry, may contain a subset of certificates issued by this > > CA > > > to other CAs. When both the forward and the reverse elements are > > > present, issuer name in one certificate shall match the subject name > > in > > > the other and vice versa, and the subject public key in one > > certificate > > > shall be capable of verifying the digital signature on the other > > > certificate and vice versa. > > > > > > In the case of V3 certificates, none of the above CA certificates > > shall > > > include a basicConstraints extension with the cA value set to FALSE. > > > > > > The definition of domain is purely a matter of local policy. > > > > > > NEW PROPOSED TEXT FOR OPTION 2 > > > > > > The cACertificate attribute, held in a particular CA's directory > > entry, > > > shall be used to store certificates issued to this CA by CAs in the > > same > > > domain as this CA. > > > > > > The forward element of the crossCertificatePair attribute, held in a > > > particular CA's directory entry, shall be used to store all > > certificates > > > issued to this CA. Optionally, the reverse element of the > > > crossCertificatePair attribute, held in a particular CA's directory > > > entry, may contain a subset of certificates issued by this CA to > > other > > > CAs. When both the forward and the reverse elements are present, > > issuer > > > name in one certificate shall match the subject name in the other > > and > > > vice versa, and the subject public key in one certificate shall be > > > capable of verifying the digital signature on the other certificate > > and > > > vice versa. > > > > > > In the case of V3 certificates, none of the above CA certificates > > shall > > > include a basicConstraints extension with the cA value set to FALSE. > > > > > > The definition of domain is purely a matter of local policy. > > > > > > > > > > > > > -----Original Message----- > > > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > > > Sent: Tuesday, September 08, 1998 5:46 PM > > > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > > > > > > > > ---------- > > > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > > > Sent: September 8, 1998 10:05 AM > > > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > > > > Subject: RE: forward & reverse elements - population > > > > > > > > > --stuff deleted > > > > > > > > > > > [] I agree. I do not have problem with the following > > language. > > > > > " A certificate issued to a CA by another shall be stored either > > in > > > > the > > > > > caCertificate or forward component of crossCertificatePair > > attribute > > > > of > > > > > the subject CA. Optionally, a subset of certificates issued by > > a CA > > > > can > > > > > be stored in the reverse component of crossCertificatePair > > attribute > > > > of > > > > > the issuing CA." > > > > > > > > > > Please note that to me subset includes none, some, or > > all. If > > > > > folks want further clarification, it is ok by me. > > > > > > > > > Santosh, the only issue I have with this text is that (at least > > with > > > > the > > > > rationale behind option 2) any cert that appears in the > > cACertificate > > > > attribute of a given CA > > > > entry, should also appear in the crossCertificatePair attribute in > > the > > > > same > > > > CA entry. > > > > What about deleting the reference to the cACertificate attribute > > from > > > > your > > > > text and proposing this as new text just for the > > crossCertificatePair > > > > attribute? > > > > > > > > Both Jan and David have indicated reasons to keep the "pair" > > together > > > > in the > > > > mutual case, so we should also consider adding the last paragraph > > of > > > > the > > > > text David proposed for that. > > > > > > > > Here's what the resulting text proposal would look like: > > > > > > > > > " A certificate issued to a CA by another shall be stored in the > > > > > forward component of crossCertificatePair attribute of > > > > > the subject CA. Optionally, a subset of certificates issued by > > a CA > > > > can > > > > > be stored in the reverse component of crossCertificatePair > > attribute > > > > of > > > > > the issuing CA. When both elements are present in the same > > value, > > > > the > > > > > value shall represent a mutual cross-certification of the two > > CAs. " > > > > > > > > > If we can come to consensus on that attribute, then let's see what > > we > > > > can do > > > > with the cACertificate attribute text. > > > > > > > > I agree with your view on what a subset is and I think that same > > > > definition > > > > would apply to the contents of the cACertificate attribute as a > > subset > > > > of > > > > the crossCertificatePair forward elements in option 2. > > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23089 for ietf-pkix-bks; Wed, 9 Sep 1998 09:03:17 -0700 (PDT) Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA23085 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 09:03:16 -0700 (PDT) Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Wed, 09 Sep 1998 10:03:43 -0600 Message-Id: <s5f6527f.038@zionsbank.com> X-Mailer: Novell GroupWise 4.1 Date: Wed, 09 Sep 1998 10:03:36 -0600 From: Mike Smith <mfsmith@zionsbank.com> To: william.burr@nist.gov, BJUENEMAN@novell.com Cc: ietf-pkix@imc.org Subject: New Extension Proposed: Method Of Authentication Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk In using certificates, it is useful to know what form of authentication is used by a CA to identify a new certificate requester. A certificate extension seems the best place to store this information. At one time, Bob Jeuneman prepared a paper proposing this extension and detailing many categories, from anonymous, self-authenticated, self authenticated with data verifired (or with credit account, etc.), authenticated in person, in person with governement-issued picture ID, multiple forms of government picture IDs with current credit reports and corporate D&B, etc. The current practice, I beleive, is to embed the authentication mechanism in a CA operations or policy statement tha may or may not be online for someone to peruse and make their own judgement. Putting a clear indicator in the signed cert would help. Comments? Bob? Michael Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23032 for ietf-pkix-bks; Wed, 9 Sep 1998 09:00:26 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23028 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 09:00:24 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ75P>; Wed, 9 Sep 1998 12:05:31 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A60@WUHER> From: Santosh Chokhani <chokhani@cygnacom.com> To: "'Denis.Pinkas@bull.net'" <Denis.Pinkas@bull.net>, Santosh Chokhani <chokhani@cygnacom.com> Cc: "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: RE: forward & reverse elements - population Date: Wed, 9 Sep 1998 12:05:30 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Denis: I agree with you. Clarification of the text is easy. However, I have a question. Must a certificate issued to a CA appear in the forward element, caCertificate or can it be missing altogether? I think the text in terms of saying that the forward element need not be present in all cases is easy. > -----Original Message----- > From: Denis Pinkas [SMTP:Denis.Pinkas@bull.net] > Sent: Wednesday, September 09, 1998 8:44 PM > To: Santosh Chokhani > Cc: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > Subject: Re: forward & reverse elements - population > > Santosh, > > Your new proposed text does not address my concern correctly. > > For a crossCertificatePair Attribute, either the forward element only > MAY be present, or the reverse element only MAY be present, or the > reverse and the forward elements may be both present. > > Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward > element > shall not be mandated to be present in a crossCertificatePair > Attribute. > > Denis > > > Sharon: > > > I can agree to the following text for the two option instead. > Please > > note that I have further clarified cross-certificate by tying the DN > and > > public keys. > > > > I think the following texts are consistent with and further > > clarifications of the two options. > > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1. > > > > NEW PROPOSED TEXT FOR OPTION 1 > > > > The cACertificate attribute, held in a particular CA's directory > entry, > > shall be used to store certificates issued to this CA by CAs in the > same > > domain as this CA. > > > > The forward element of the crossCertificatePair attribute, held in a > > particular CA's directory entry, shall be used to store certificates > > issued to this CA by CAs in other domains. Optionally, the reverse > > element of the crossCertificatePair attribute, held in a particular > CA's > > directory entry, may contain a subset of certificates issued by this > CA > > to other CAs. When both the forward and the reverse elements are > > present, issuer name in one certificate shall match the subject name > in > > the other and vice versa, and the subject public key in one > certificate > > shall be capable of verifying the digital signature on the other > > certificate and vice versa. > > > > In the case of V3 certificates, none of the above CA certificates > shall > > include a basicConstraints extension with the cA value set to FALSE. > > > > The definition of domain is purely a matter of local policy. > > > > NEW PROPOSED TEXT FOR OPTION 2 > > > > The cACertificate attribute, held in a particular CA's directory > entry, > > shall be used to store certificates issued to this CA by CAs in the > same > > domain as this CA. > > > > The forward element of the crossCertificatePair attribute, held in a > > particular CA's directory entry, shall be used to store all > certificates > > issued to this CA. Optionally, the reverse element of the > > crossCertificatePair attribute, held in a particular CA's directory > > entry, may contain a subset of certificates issued by this CA to > other > > CAs. When both the forward and the reverse elements are present, > issuer > > name in one certificate shall match the subject name in the other > and > > vice versa, and the subject public key in one certificate shall be > > capable of verifying the digital signature on the other certificate > and > > vice versa. > > > > In the case of V3 certificates, none of the above CA certificates > shall > > include a basicConstraints extension with the cA value set to FALSE. > > > > The definition of domain is purely a matter of local policy. > > > > > -----Original Message----- > > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > > Sent: Tuesday, September 08, 1998 5:46 PM > > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > > > > ---------- > > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > > Sent: September 8, 1998 10:05 AM > > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > > > Subject: RE: forward & reverse elements - population > > > > > > > --stuff deleted > > > > > > > > > [] I agree. I do not have problem with the following > language. > > > > " A certificate issued to a CA by another shall be stored either > in > > > the > > > > caCertificate or forward component of crossCertificatePair > attribute > > > of > > > > the subject CA. Optionally, a subset of certificates issued by > a CA > > > can > > > > be stored in the reverse component of crossCertificatePair > attribute > > > of > > > > the issuing CA." > > > > > > > > Please note that to me subset includes none, some, or all. > If > > > > folks want further clarification, it is ok by me. > > > > > > > Santosh, the only issue I have with this text is that (at least > with > > > the > > > rationale behind option 2) any cert that appears in the > cACertificate > > > attribute of a given CA > > > entry, should also appear in the crossCertificatePair attribute in > the > > > same > > > CA entry. > > > What about deleting the reference to the cACertificate attribute > from > > > your > > > text and proposing this as new text just for the > crossCertificatePair > > > attribute? > > > > > > Both Jan and David have indicated reasons to keep the "pair" > together > > > in the > > > mutual case, so we should also consider adding the last paragraph > of > > > the > > > text David proposed for that. > > > > > > Here's what the resulting text proposal would look like: > > > > > > > " A certificate issued to a CA by another shall be stored in the > > > > forward component of crossCertificatePair attribute of > > > > the subject CA. Optionally, a subset of certificates issued by > a CA > > > can > > > > be stored in the reverse component of crossCertificatePair > attribute > > > of > > > > the issuing CA. When both elements are present in the same > value, > > > the > > > > value shall represent a mutual cross-certification of the two > CAs. " > > > > > > > If we can come to consensus on that attribute, then let's see what > we > > > can do > > > with the cACertificate attribute text. > > > > > > I agree with your view on what a subset is and I think that same > > > definition > > > would apply to the contents of the cACertificate attribute as a > subset > > > of > > > the crossCertificatePair forward elements in option 2. > > -- > Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net > Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 > 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22846 for ietf-pkix-bks; Wed, 9 Sep 1998 08:41:31 -0700 (PDT) Received: from hpb.hc-sc.gc.ca (hpb.hc-sc.gc.ca [198.103.237.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22842 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 08:41:28 -0700 (PDT) From: Ross_Smith@hc-sc.gc.ca Received: from intdns.hwc.ca (intdns.hc-sc.gc.ca [198.103.172.78]) by hpb.hc-sc.gc.ca (8.8.7/8.7.3) with ESMTP id LAA05879 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 11:46:15 -0400 (EDT) Received: from smta00.hc-sc.gc.ca (smta00.hc-sc.gc.ca [142.4.1.25]) by intdns.hwc.ca (8.8.5/8.7.3) with SMTP id LAA17566 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 11:46:13 -0400 (EDT) Received: by smta00.hc-sc.gc.ca(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 8525667A.0056A364 ; Wed, 9 Sep 1998 11:46:19 -0400 X-Lotus-FromDomain: HWC To: ietf-pkix@imc.org Message-ID: <8525667A.00567CC1.00@smta00.hc-sc.gc.ca> Date: Wed, 9 Sep 1998 11:46:08 -0400 Subject: For Option 2 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@imc.org Precedence: bulk 09/09/98 11:46 AM Ross Smith Ross Smith Ross Smith 09/09/98 11:46 AM 09/09/98 11:46 AM Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22806 for ietf-pkix-bks; Wed, 9 Sep 1998 08:38:00 -0700 (PDT) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22800 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 08:37:57 -0700 (PDT) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id RAA29000; Wed, 9 Sep 1998 17:44:48 +0200 Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id RAA21158; Wed, 9 Sep 1998 17:44:51 +0200 (DFT) Message-ID: <35F720DC.42B3@bull.net> Date: Wed, 09 Sep 1998 17:44:12 -0700 From: Denis Pinkas <Denis.Pinkas@bull.net> Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) MIME-Version: 1.0 To: Santosh Chokhani <chokhani@cygnacom.com> CC: "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: Re: forward & reverse elements - population References: <51BF55C30B4FD1118B4900207812701E1B1A5C@WUHER> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Santosh, Your new proposed text does not address my concern correctly. For a crossCertificatePair Attribute, either the forward element only MAY be present, or the reverse element only MAY be present, or the reverse and the forward elements may be both present. Whether it is OPTION 1, OPTION 2 or whatever OPTION, the forward element shall not be mandated to be present in a crossCertificatePair Attribute. Denis > Sharon: > I can agree to the following text for the two option instead. Please > note that I have further clarified cross-certificate by tying the DN and > public keys. > > I think the following texts are consistent with and further > clarifications of the two options. > > I STILL AM STRONGLY IN FAVOR OF OPTION 1. > > NEW PROPOSED TEXT FOR OPTION 1 > > The cACertificate attribute, held in a particular CA's directory entry, > shall be used to store certificates issued to this CA by CAs in the same > domain as this CA. > > The forward element of the crossCertificatePair attribute, held in a > particular CA's directory entry, shall be used to store certificates > issued to this CA by CAs in other domains. Optionally, the reverse > element of the crossCertificatePair attribute, held in a particular CA's > directory entry, may contain a subset of certificates issued by this CA > to other CAs. When both the forward and the reverse elements are > present, issuer name in one certificate shall match the subject name in > the other and vice versa, and the subject public key in one certificate > shall be capable of verifying the digital signature on the other > certificate and vice versa. > > In the case of V3 certificates, none of the above CA certificates shall > include a basicConstraints extension with the cA value set to FALSE. > > The definition of domain is purely a matter of local policy. > > NEW PROPOSED TEXT FOR OPTION 2 > > The cACertificate attribute, held in a particular CA's directory entry, > shall be used to store certificates issued to this CA by CAs in the same > domain as this CA. > > The forward element of the crossCertificatePair attribute, held in a > particular CA's directory entry, shall be used to store all certificates > issued to this CA. Optionally, the reverse element of the > crossCertificatePair attribute, held in a particular CA's directory > entry, may contain a subset of certificates issued by this CA to other > CAs. When both the forward and the reverse elements are present, issuer > name in one certificate shall match the subject name in the other and > vice versa, and the subject public key in one certificate shall be > capable of verifying the digital signature on the other certificate and > vice versa. > > In the case of V3 certificates, none of the above CA certificates shall > include a basicConstraints extension with the cA value set to FALSE. > > The definition of domain is purely a matter of local policy. > > > -----Original Message----- > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > Sent: Tuesday, September 08, 1998 5:46 PM > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > Subject: RE: forward & reverse elements - population > > > > > > > > > ---------- > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > Sent: September 8, 1998 10:05 AM > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > > Subject: RE: forward & reverse elements - population > > > > > --stuff deleted > > > > > > > [] I agree. I do not have problem with the following language. > > > " A certificate issued to a CA by another shall be stored either in > > the > > > caCertificate or forward component of crossCertificatePair attribute > > of > > > the subject CA. Optionally, a subset of certificates issued by a CA > > can > > > be stored in the reverse component of crossCertificatePair attribute > > of > > > the issuing CA." > > > > > > Please note that to me subset includes none, some, or all. If > > > folks want further clarification, it is ok by me. > > > > > Santosh, the only issue I have with this text is that (at least with > > the > > rationale behind option 2) any cert that appears in the cACertificate > > attribute of a given CA > > entry, should also appear in the crossCertificatePair attribute in the > > same > > CA entry. > > What about deleting the reference to the cACertificate attribute from > > your > > text and proposing this as new text just for the crossCertificatePair > > attribute? > > > > Both Jan and David have indicated reasons to keep the "pair" together > > in the > > mutual case, so we should also consider adding the last paragraph of > > the > > text David proposed for that. > > > > Here's what the resulting text proposal would look like: > > > > > " A certificate issued to a CA by another shall be stored in the > > > forward component of crossCertificatePair attribute of > > > the subject CA. Optionally, a subset of certificates issued by a CA > > can > > > be stored in the reverse component of crossCertificatePair attribute > > of > > > the issuing CA. When both elements are present in the same value, > > the > > > value shall represent a mutual cross-certification of the two CAs. " > > > > > If we can come to consensus on that attribute, then let's see what we > > can do > > with the cACertificate attribute text. > > > > I agree with your view on what a subset is and I think that same > > definition > > would apply to the contents of the cACertificate attribute as a subset > > of > > the crossCertificatePair forward elements in option 2. -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22663 for ietf-pkix-bks; Wed, 9 Sep 1998 08:21:38 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22659 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 08:21:36 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ7VA>; Wed, 9 Sep 1998 11:26:44 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A5F@WUHER> From: Santosh Chokhani <chokhani@cygnacom.com> To: "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, Santosh Chokhani <chokhani@cygnacom.com> Subject: RE: forward & reverse elements - population Date: Wed, 9 Sep 1998 11:26:42 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Yes. I agree. The following is the revised text. NEW PROPOSED TEXT FOR OPTION 1 The cACertificate attribute, held in a particular CA's directory entry, shall be used to store certificates issued to this CA by CAs in the same domain as this CA. If there are any self-issued certificates and they require publication, the caCertificate attribute shall be used to store them. The forward element of the crossCertificatePair attribute, held in a particular CA's directory entry, shall be used to store certificates issued to this CA by CAs in other domains. Optionally, the reverse element of the crossCertificatePair attribute, held in a particular CA's directory entry, may contain a subset of certificates issued by this CA to other CAs. When both the forward and the reverse elements are present, issuer name in one certificate shall match the subject name in the other and vice versa, and the subject public key in one certificate shall be capable of verifying the digital signature on the other certificate and vice versa. In the case of V3 certificates, none of the above CA certificates shall include a basicConstraints extension with the cA value set to FALSE. The definition of domain is purely a matter of local policy. NEW PROPOSED TEXT FOR OPTION 2 The cACertificate attribute, held in a particular CA's directory entry, shall be used to store certificates issued to this CA by CAs in the same domain as this CA. If there are any self-issued certificates and they require publication, the caCertificate attribute shall be used to store them. The forward element of the crossCertificatePair attribute, held in a particular CA's directory entry, shall be used to store all certificates issued to this CA. Optionally, the reverse element of the crossCertificatePair attribute, held in a particular CA's directory entry, may contain a subset of certificates issued by this CA to other CAs. When both the forward and the reverse elements are present, issuer name in one certificate shall match the subject name in the other and vice versa, and the subject public key in one certificate shall be capable of verifying the digital signature on the other certificate and vice versa. In the case of V3 certificates, none of the above CA certificates shall include a basicConstraints extension with the cA value set to FALSE. The definition of domain is purely a matter of local policy. > -----Original Message----- > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > Sent: Wednesday, September 09, 1998 11:02 AM > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > Subject: RE: forward & reverse elements - population > > I agree that the texts below are consistent with the original intent > of the > 2 options and I also agree that they are clearer than the original > texts > except, possibly for coverage of self issued certificates. Shouldn't > we also > state explicitly that self issued certs are stored only in the > cACertificate > attribute for both options? > > > > ---------- > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > Sent: September 9, 1998 9:08 AM > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org'; Santosh Chokhani > > Subject: RE: forward & reverse elements - population > > > > Sharon: > > > > I can agree to the following text for the two option instead. > Please > > note that I have further clarified cross-certificate by tying the DN > and > > public keys. > > > > I think the following texts are consistent with and further > > clarifications of the two options. > > > > I STILL AM STRONGLY IN FAVOR OF OPTION 1. > > > And I option 2 :-) > > > NEW PROPOSED TEXT FOR OPTION 1 > > > > The cACertificate attribute, held in a particular CA's directory > entry, > > shall be used to store certificates issued to this CA by CAs in the > same > > domain as this CA. > > > > The forward element of the crossCertificatePair attribute, held in a > > particular CA's directory entry, shall be used to store certificates > > issued to this CA by CAs in other domains. Optionally, the reverse > > element of the crossCertificatePair attribute, held in a particular > CA's > > directory entry, may contain a subset of certificates issued by this > CA > > to other CAs. When both the forward and the reverse elements are > > present, issuer name in one certificate shall match the subject name > in > > the other and vice versa, and the subject public key in one > certificate > > shall be capable of verifying the digital signature on the other > > certificate and vice versa. > > > > In the case of V3 certificates, none of the above CA certificates > shall > > include a basicConstraints extension with the cA value set to FALSE. > > > > The definition of domain is purely a matter of local policy. > > > > NEW PROPOSED TEXT FOR OPTION 2 > > > > The cACertificate attribute, held in a particular CA's directory > entry, > > shall be used to store certificates issued to this CA by CAs in the > same > > domain as this CA. > > > > The forward element of the crossCertificatePair attribute, held in a > > particular CA's directory entry, shall be used to store all > certificates > > issued to this CA. Optionally, the reverse element of the > > crossCertificatePair attribute, held in a particular CA's directory > > entry, may contain a subset of certificates issued by this CA to > other > > CAs. When both the forward and the reverse elements are present, > issuer > > name in one certificate shall match the subject name in the other > and > > vice versa, and the subject public key in one certificate shall be > > capable of verifying the digital signature on the other certificate > and > > vice versa. > > > > In the case of V3 certificates, none of the above CA certificates > shall > > include a basicConstraints extension with the cA value set to FALSE. > > > > The definition of domain is purely a matter of local policy. > > > > > > > > > -----Original Message----- > > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > > Sent: Tuesday, September 08, 1998 5:46 PM > > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > > Subject: RE: forward & reverse elements - population > > > > > > > > > > > > > ---------- > > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > > Sent: September 8, 1998 10:05 AM > > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > > > Subject: RE: forward & reverse elements - population > > > > > > > --stuff deleted > > > > > > > > > [] I agree. I do not have problem with the following > language. > > > > " A certificate issued to a CA by another shall be stored either > in > > > the > > > > caCertificate or forward component of crossCertificatePair > attribute > > > of > > > > the subject CA. Optionally, a subset of certificates issued by > a CA > > > can > > > > be stored in the reverse component of crossCertificatePair > attribute > > > of > > > > the issuing CA." > > > > > > > > Please note that to me subset includes none, some, or > all. If > > > > folks want further clarification, it is ok by me. > > > > > > > Santosh, the only issue I have with this text is that (at least > with > > > the > > > rationale behind option 2) any cert that appears in the > cACertificate > > > attribute of a given CA > > > entry, should also appear in the crossCertificatePair attribute in > the > > > same > > > CA entry. > > > What about deleting the reference to the cACertificate attribute > from > > > your > > > text and proposing this as new text just for the > crossCertificatePair > > > attribute? > > > > > > Both Jan and David have indicated reasons to keep the "pair" > together > > > in the > > > mutual case, so we should also consider adding the last paragraph > of > > > the > > > text David proposed for that. > > > > > > Here's what the resulting text proposal would look like: > > > > > > > " A certificate issued to a CA by another shall be stored in the > > > > forward component of crossCertificatePair attribute of > > > > the subject CA. Optionally, a subset of certificates issued by > a CA > > > can > > > > be stored in the reverse component of crossCertificatePair > attribute > > > of > > > > the issuing CA. When both elements are present in the same > value, > > > the > > > > value shall represent a mutual cross-certification of the two > CAs. " > > > > > > > If we can come to consensus on that attribute, then let's see what > we > > > can do > > > with the cACertificate attribute text. > > > > > > I agree with your view on what a subset is and I think that same > > > definition > > > would apply to the contents of the cACertificate attribute as a > subset > > > of > > > the crossCertificatePair forward elements in option 2. > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22485 for ietf-pkix-bks; Wed, 9 Sep 1998 08:01:33 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA22479 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 08:01:31 -0700 (PDT) Received: id LAA08881; Wed, 9 Sep 1998 11:04:43 -0400 Received: by gateway id <S2S6XZC1>; Wed, 9 Sep 1998 11:01:41 -0400 Message-ID: <D789F71F24B4D111955D00A0C99B4F50AC9752@sothmxs01.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'Santosh Chokhani'" <chokhani@cygnacom.com> Subject: RE: forward & reverse elements - population Date: Wed, 9 Sep 1998 11:01:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk I agree that the texts below are consistent with the original intent of the 2 options and I also agree that they are clearer than the original texts except, possibly for coverage of self issued certificates. Shouldn't we also state explicitly that self issued certs are stored only in the cACertificate attribute for both options? > ---------- > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > Sent: September 9, 1998 9:08 AM > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org'; Santosh Chokhani > Subject: RE: forward & reverse elements - population > > Sharon: > > I can agree to the following text for the two option instead. Please > note that I have further clarified cross-certificate by tying the DN and > public keys. > > I think the following texts are consistent with and further > clarifications of the two options. > > I STILL AM STRONGLY IN FAVOR OF OPTION 1. > And I option 2 :-) > NEW PROPOSED TEXT FOR OPTION 1 > > The cACertificate attribute, held in a particular CA's directory entry, > shall be used to store certificates issued to this CA by CAs in the same > domain as this CA. > > The forward element of the crossCertificatePair attribute, held in a > particular CA's directory entry, shall be used to store certificates > issued to this CA by CAs in other domains. Optionally, the reverse > element of the crossCertificatePair attribute, held in a particular CA's > directory entry, may contain a subset of certificates issued by this CA > to other CAs. When both the forward and the reverse elements are > present, issuer name in one certificate shall match the subject name in > the other and vice versa, and the subject public key in one certificate > shall be capable of verifying the digital signature on the other > certificate and vice versa. > > In the case of V3 certificates, none of the above CA certificates shall > include a basicConstraints extension with the cA value set to FALSE. > > The definition of domain is purely a matter of local policy. > > NEW PROPOSED TEXT FOR OPTION 2 > > The cACertificate attribute, held in a particular CA's directory entry, > shall be used to store certificates issued to this CA by CAs in the same > domain as this CA. > > The forward element of the crossCertificatePair attribute, held in a > particular CA's directory entry, shall be used to store all certificates > issued to this CA. Optionally, the reverse element of the > crossCertificatePair attribute, held in a particular CA's directory > entry, may contain a subset of certificates issued by this CA to other > CAs. When both the forward and the reverse elements are present, issuer > name in one certificate shall match the subject name in the other and > vice versa, and the subject public key in one certificate shall be > capable of verifying the digital signature on the other certificate and > vice versa. > > In the case of V3 certificates, none of the above CA certificates shall > include a basicConstraints extension with the cA value set to FALSE. > > The definition of domain is purely a matter of local policy. > > > > > -----Original Message----- > > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > > Sent: Tuesday, September 08, 1998 5:46 PM > > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > > Subject: RE: forward & reverse elements - population > > > > > > > > > ---------- > > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > > Sent: September 8, 1998 10:05 AM > > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > > Subject: RE: forward & reverse elements - population > > > > > --stuff deleted > > > > > > > [] I agree. I do not have problem with the following language. > > > " A certificate issued to a CA by another shall be stored either in > > the > > > caCertificate or forward component of crossCertificatePair attribute > > of > > > the subject CA. Optionally, a subset of certificates issued by a CA > > can > > > be stored in the reverse component of crossCertificatePair attribute > > of > > > the issuing CA." > > > > > > Please note that to me subset includes none, some, or all. If > > > folks want further clarification, it is ok by me. > > > > > Santosh, the only issue I have with this text is that (at least with > > the > > rationale behind option 2) any cert that appears in the cACertificate > > attribute of a given CA > > entry, should also appear in the crossCertificatePair attribute in the > > same > > CA entry. > > What about deleting the reference to the cACertificate attribute from > > your > > text and proposing this as new text just for the crossCertificatePair > > attribute? > > > > Both Jan and David have indicated reasons to keep the "pair" together > > in the > > mutual case, so we should also consider adding the last paragraph of > > the > > text David proposed for that. > > > > Here's what the resulting text proposal would look like: > > > > > " A certificate issued to a CA by another shall be stored in the > > > forward component of crossCertificatePair attribute of > > > the subject CA. Optionally, a subset of certificates issued by a CA > > can > > > be stored in the reverse component of crossCertificatePair attribute > > of > > > the issuing CA. When both elements are present in the same value, > > the > > > value shall represent a mutual cross-certification of the two CAs. " > > > > > If we can come to consensus on that attribute, then let's see what we > > can do > > with the cACertificate attribute text. > > > > I agree with your view on what a subset is and I think that same > > definition > > would apply to the contents of the cACertificate attribute as a subset > > of > > the crossCertificatePair forward elements in option 2. > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21587 for ietf-pkix-bks; Wed, 9 Sep 1998 06:34:38 -0700 (PDT) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21583 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 06:34:36 -0700 (PDT) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id PAA17200 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 15:41:24 +0200 Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with SMTP id PAA20994 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 15:41:28 +0200 (DFT) Message-ID: <35F703F0.53AA@bull.net> Date: Wed, 09 Sep 1998 15:40:49 -0700 From: Denis Pinkas <Denis.Pinkas@bull.net> Reply-To: Denis.Pinkas@bull.net Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) MIME-Version: 1.0 To: IETF-PXIX <ietf-pkix@imc.org> Subject: For Option none Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk The straw poll is now obsolete since neither of the two original texts is acceptable as it is. Anyway since it was not a "vote", it was interresting to promote discussion on this topic and apparently that discussion has not yet ended ! Denis -- Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21260 for ietf-pkix-bks; Wed, 9 Sep 1998 06:03:20 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21256 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 06:03:19 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ7R4>; Wed, 9 Sep 1998 09:08:26 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E1B1A5C@WUHER> From: Santosh Chokhani <chokhani@cygnacom.com> To: "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, Santosh Chokhani <chokhani@cygnacom.com> Subject: RE: forward & reverse elements - population Date: Wed, 9 Sep 1998 09:08:23 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Sharon: I can agree to the following text for the two option instead. Please note that I have further clarified cross-certificate by tying the DN and public keys. I think the following texts are consistent with and further clarifications of the two options. I STILL AM STRONGLY IN FAVOR OF OPTION 1. NEW PROPOSED TEXT FOR OPTION 1 The cACertificate attribute, held in a particular CA's directory entry, shall be used to store certificates issued to this CA by CAs in the same domain as this CA. The forward element of the crossCertificatePair attribute, held in a particular CA's directory entry, shall be used to store certificates issued to this CA by CAs in other domains. Optionally, the reverse element of the crossCertificatePair attribute, held in a particular CA's directory entry, may contain a subset of certificates issued by this CA to other CAs. When both the forward and the reverse elements are present, issuer name in one certificate shall match the subject name in the other and vice versa, and the subject public key in one certificate shall be capable of verifying the digital signature on the other certificate and vice versa. In the case of V3 certificates, none of the above CA certificates shall include a basicConstraints extension with the cA value set to FALSE. The definition of domain is purely a matter of local policy. NEW PROPOSED TEXT FOR OPTION 2 The cACertificate attribute, held in a particular CA's directory entry, shall be used to store certificates issued to this CA by CAs in the same domain as this CA. The forward element of the crossCertificatePair attribute, held in a particular CA's directory entry, shall be used to store all certificates issued to this CA. Optionally, the reverse element of the crossCertificatePair attribute, held in a particular CA's directory entry, may contain a subset of certificates issued by this CA to other CAs. When both the forward and the reverse elements are present, issuer name in one certificate shall match the subject name in the other and vice versa, and the subject public key in one certificate shall be capable of verifying the digital signature on the other certificate and vice versa. In the case of V3 certificates, none of the above CA certificates shall include a basicConstraints extension with the cA value set to FALSE. The definition of domain is purely a matter of local policy. > -----Original Message----- > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > Sent: Tuesday, September 08, 1998 5:46 PM > To: 'ietf-pkix@imc.org'; 'Santosh Chokhani' > Subject: RE: forward & reverse elements - population > > > > > ---------- > > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > > Sent: September 8, 1998 10:05 AM > > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > > Subject: RE: forward & reverse elements - population > > > --stuff deleted > > > > > [] I agree. I do not have problem with the following language. > > " A certificate issued to a CA by another shall be stored either in > the > > caCertificate or forward component of crossCertificatePair attribute > of > > the subject CA. Optionally, a subset of certificates issued by a CA > can > > be stored in the reverse component of crossCertificatePair attribute > of > > the issuing CA." > > > > Please note that to me subset includes none, some, or all. If > > folks want further clarification, it is ok by me. > > > Santosh, the only issue I have with this text is that (at least with > the > rationale behind option 2) any cert that appears in the cACertificate > attribute of a given CA > entry, should also appear in the crossCertificatePair attribute in the > same > CA entry. > What about deleting the reference to the cACertificate attribute from > your > text and proposing this as new text just for the crossCertificatePair > attribute? > > Both Jan and David have indicated reasons to keep the "pair" together > in the > mutual case, so we should also consider adding the last paragraph of > the > text David proposed for that. > > Here's what the resulting text proposal would look like: > > > " A certificate issued to a CA by another shall be stored in the > > forward component of crossCertificatePair attribute of > > the subject CA. Optionally, a subset of certificates issued by a CA > can > > be stored in the reverse component of crossCertificatePair attribute > of > > the issuing CA. When both elements are present in the same value, > the > > value shall represent a mutual cross-certification of the two CAs. " > > > If we can come to consensus on that attribute, then let's see what we > can do > with the cACertificate attribute text. > > I agree with your view on what a subset is and I think that same > definition > would apply to the contents of the cACertificate attribute as a subset > of > the crossCertificatePair forward elements in option 2. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18469 for ietf-pkix-bks; Wed, 9 Sep 1998 02:18:24 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18465 for <ietf-pkix@imc.org>; Wed, 9 Sep 1998 02:18:12 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <SMGRLFPT>; Wed, 9 Sep 1998 19:22:05 +1000 Message-ID: <D1A949D4508DD1119C8100400533BEDC073861@DSG1> From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> To: "'Mike Smith '" <mfsmith@zionsbank.com>, "'fod@brd.ie '" <fod@brd.ie>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Phillip M Hallam-Baker '" <pbaker@verisign.com> Cc: "'dave@chromatix.com '" <dave@chromatix.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org> Subject: RE: OFF TOPIC ???? RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s) Date: Wed, 9 Sep 1998 19:22:02 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Thanks for the reply - comments in line. ---------- From: Phillip M Hallam-Baker To: Mike Smith; fod@brd.ie; Alan.Lloyd@OpenDirectory.com.au Cc: dave@chromatix.com; ietf-pkix@imc.org Sent: 9/9/98 1:50:46 AM Subject: OFF TOPIC ???? RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s) Ph: I'm having a lot of trouble following this discussion. It appears to have begun a discussion of the relative merits of X.500 vs LDAP server models. This does not appear to be something which is relevant to PKIX. LDAP is merely a protocol. It does not define a product. Arguments based on the 'scalability' of a client-server protocol are almost without exception irrelevant since scaling depends on server-server communication. The idea that the same protocol should serve both purposes is questionable at best. alan: LDAP is just a protocol! That statement is curious given that features in protocol impact the system services that are conveyed to and available from " the protocol". eg. Replicated/Master certfificates .. How does LDAP get the Master copy of a certficate when it needs that. If the certficate happens to be outside the "domain of interest" how does LDAP control the extent of a search re Chaining.. It can not. If one is trying to build large scale certficate based systems supported by directory services, then "the protocol" used will affect the trust and performance of the system services applied.. LDAP does not deal with distributed systems - it deals with client interfaces to seperate servers. Cert Matching Rules and LDAP (non X.500)servers? - ask the vendors. Ph:I fail to see how improved search capabilities will greatly assist for the purposes of PKIX unless the directories have the ability to break open, readand understand attributes embedded in certificates. If people believe that support for a specific (and specified) search mechanism would lead to an improvement in efficiency that is important to PKIX let us discuss thatspecific extension. alan: See X.500/9 certficate matching rules, see the draft I posted last week. Cert and CRL matching rules can, in fact are intended to assist the management and validation of certificates. They should be applied to this end. As said in my draft, it seems pointless trying to get a client to understand all the information and revocation designs of any CA that might exist on this planet. X.509 is part of X.500 and the application of X.509 to be scaleable depends on the use and features of a directory services. The emphasis to date on CA design has been.. information objects for CA functions that "may" use a directory. OCSP is symptomatic of this approach ie. no directory service is considered. This = special client software and special servers and special CA databases. Hardly an approach for the large scale of the internet, the use of distributed, scaleable EC services and simple clients. To build a generalised, efficient, scaleable certificate infrastructure, X.500 directory systems (not LDAP servers) are fundamental. With added matching rules and common CA information doctrines (as applied to their DIBs) the PKIX problem is very solveable. Ph: We need to remember that we are charterted as an IETF working group and weare not in a position to endorse a particular directory strategy. alan: Well if "we" are chartered to build a car and it wants to be used, by definition should we not be making sure that the roads and wheels are in place. (eg directory systems). ie. when anything is designed, assumptions or statements about underlying (scaleable) services should be made. Ph: If we want to be able to offload client work to a server of some kind we should first consider the requirements that motivate such an architectural approach and the trust implications of doing so before considering protocol extensions. Indeed a critical step would be deciding which protocol to base an implementation on. Alan: X.500 was designed to deal with this issue (see X.500 1993 cert and CRL matching rules). There is no direct extension to the protocol" its the addition of convey service requirements and modified directory matching rule support. As for trust - then there is no trust in multitudes of chaotic CA information designs and complex clients that cannot verify certs for specific application and originator/recipient contexts. Finally - it seems a lot of the work on PKIX has been made so complex because of the limitations in LDAP, LDAP servers and "non directory system" application, eg OCSP, eg, . Taking X.500 infrastructure away from X.509 is like taking the wheels off a car and then trying to fix the car's resulting problems. So IMHO - if the charter of this group is to build a certficate infrastructure for the internet - should we not follow industry trends with directories ie LDAP or DAP access to X.500 that incorporates X.509? And extend this as per dir-cert-stat draft to make it scaleable and efficient. Thoughts are welcome. regards alan Phill Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02151 for ietf-pkix-bks; Tue, 8 Sep 1998 22:11:59 -0700 (PDT) Received: from atlantic.valicert.com (qmailr@old-atlantic.valicert.com [209.185.6.135]) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA02147 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 22:11:57 -0700 (PDT) Received: (qmail 8338 invoked from network); 9 Sep 1998 05:17:13 -0000 Received: from ns.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 9 Sep 1998 05:17:13 -0000 Message-ID: <35F60F60.37C6098E@valicert.com> Date: Tue, 08 Sep 1998 22:17:20 -0700 From: Ambarish Malpani <ambarish@valicert.com> Organization: ValiCert, Inc. X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ed Posnak <ejp@xetex.com> CC: IETF PKIX <ietf-pkix@imc.org> Subject: Re: OCSP in Chicago References: <35F5A976.E3A03DCE@valicert.com> <35F5D996.DF96F76A@xetex.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Hi Ed, Please take a look at section 4.4.4 (Archive Cutoff). See if that addresses your concerns. 4.4.4 Archive Cutoff An OCSP responder MAY choose to retain revocation information beyond a certificates expiration. The date obtained by subtracting this retention interval value from the producedAt time in a response is defined as the certificates archive cutoff date. OCSP-enabled applications would use an OCSP archive cutoff date to contribute to a proof that a digital signature was (or was not) reliable on the date it was produced even if the certificate needed to validate the signature has long since expired. OCSP servers that provide support for such historical reference SHOULD include an archive cutoff date extension in responses. If included, this value SHALL be provided as an OCSP singleResponse extension identified by id-pkix-ocsp-archive-cutoff and of syntax GeneralizedTime: id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } archiveCutoff ::= GeneralizedTime To illustrate, if a server is operated with a 7-year retention interval policy and status was produced at time t1 then the value for archiveCutoff in the response would be (t1 - 7 years). Regards, Ambarish Ed Posnak wrote: > > Does the following still apply to a "Good" status? > > [from version 05] "... it is quite possible that an OCSP responder > returns the notRevoked state if a certificate was revoked, but has since > expired (equivalent to a serial number being dropped from the CRL). " > > If so, perhaps the above sentence shouldn't have been dropped from the > description? > > ejp -- --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 1215 Terra Bella Ave. http://www.valicert.com Mountain View, CA 94043-1833 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA29394 for ietf-pkix-bks; Tue, 8 Sep 1998 20:42:56 -0700 (PDT) Received: from 2gn.com (insectivora.unids.com [208.196.212.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA29390 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 20:42:55 -0700 (PDT) Received: from rodney (perm16-180.ij.net [209.4.16.180]) by 2gn.com (8.8.5/8.8.5) with SMTP id WAA25675; Tue, 8 Sep 1998 22:45:09 -0400 Message-Id: <199809090245.WAA25675@2gn.com> X-Sender: rodney@module-one.tillerman.nu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 08 Sep 1998 23:44:10 -0400 To: Pavel Krylov <versed@elvis.ru> From: Rodney Thayer <rodney@tillerman.nu> Subject: Re: depth Cc: ietf-pkix@imc.org In-Reply-To: <XFMail.980907213528.versed@elvis.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk In researching this for IPSec, I've heard a depth of approximately four being used, and of course a single root, and sporadic use of deeper trees, as far as 8. At 12:35 AM 9/8/98 +0400, you wrote: > >My question: > What depth of certificate tree is exist now?? Average value? > >Sharon, Santosh? > >--------------------------------------- >Pavel V.Krylov versed@elvis.ru > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA28554 for ietf-pkix-bks; Tue, 8 Sep 1998 18:18:59 -0700 (PDT) Received: from ns1.auntmimi.net ([209.19.106.141]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA28550 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 18:18:58 -0700 (PDT) Received: from mail.xetex.com (1Cust101.tnt2.sfo3.da.uu.net [153.37.7.101]) by ns1.auntmimi.net (8.8.6/8.7.3) with SMTP id TAA21059; Tue, 8 Sep 1998 19:55:22 -0700 (PDT) Received: from xetex.com by mail.xetex.com (SMI-8.6/SMI-SVR4) id SAA08850; Tue, 8 Sep 1998 18:20:05 -0700 Message-ID: <35F5D996.DF96F76A@xetex.com> Date: Tue, 08 Sep 1998 18:27:51 -0700 From: Ed Posnak <ejp@xetex.com> Organization: Xetex Corporation X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Ambarish Malpani <ambarish@valicert.com> CC: IETF PKIX <ietf-pkix@imc.org> Subject: Re: OCSP in Chicago References: <35F5A976.E3A03DCE@valicert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Does the following still apply to a "Good" status? [from version 05] "... it is quite possible that an OCSP responder returns the notRevoked state if a certificate was revoked, but has since expired (equivalent to a serial number being dropped from the CRL). " If so, perhaps the above sentence shouldn't have been dropped from the description? ejp Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA26952 for ietf-pkix-bks; Tue, 8 Sep 1998 15:01:14 -0700 (PDT) Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA26948 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 15:01:13 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id PAA24508 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 15:05:56 -0700 (PDT) Message-Id: <4.1.0.52.19980908180708.009c44a0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.52 (Beta) Date: Tue, 08 Sep 1998 18:07:20 -0400 To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> From: Russ Housley <housley@spyrus.com> Subject: For Option 1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26881 for ietf-pkix-bks; Tue, 8 Sep 1998 14:57:32 -0700 (PDT) Received: from atlantic.valicert.com (atlantic.valicert.com [209.185.6.135] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA26871 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 14:57:31 -0700 (PDT) Received: (qmail 1104 invoked from network); 8 Sep 1998 22:02:24 -0000 Received: from ns.valicert.com (HELO valicert.com) (209.185.6.1) by mail.valicert.com with SMTP; 8 Sep 1998 22:02:24 -0000 Message-ID: <35F5A976.E3A03DCE@valicert.com> Date: Tue, 08 Sep 1998 15:02:30 -0700 From: Ambarish Malpani <ambarish@valicert.com> Organization: ValiCert, Inc. X-Mailer: Mozilla 4.5b1 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IETF PKIX <ietf-pkix@imc.org> Subject: OCSP in Chicago Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk Hi All, For the benefit of those who were not in Chicago, it was resolved that the symbol for notRevoked be changed to good. We have put in the following explanation of the good state: The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the producedAt time is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc.). Regards, Ambarish -- --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 1215 Terra Bella Ave. http://www.valicert.com Mountain View, CA 94043-1833 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26782 for ietf-pkix-bks; Tue, 8 Sep 1998 14:46:42 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA26778 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 14:46:40 -0700 (PDT) Received: id RAA25638; Tue, 8 Sep 1998 17:49:05 -0400 Received: by gateway id <S2S6XV8N>; Tue, 8 Sep 1998 17:46:02 -0400 Message-ID: <D789F71F24B4D111955D00A0C99B4F50AC974B@sothmxs01.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'Santosh Chokhani'" <chokhani@cygnacom.com> Subject: RE: forward & reverse elements - population Date: Tue, 8 Sep 1998 17:46:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk > ---------- > From: Santosh Chokhani[SMTP:chokhani@cygnacom.com] > Sent: September 8, 1998 10:05 AM > To: 'Sharon Boeyen'; 'ietf-pkix@imc.org' > Subject: RE: forward & reverse elements - population > --stuff deleted > > > [] I agree. I do not have problem with the following language. > " A certificate issued to a CA by another shall be stored either in the > caCertificate or forward component of crossCertificatePair attribute of > the subject CA. Optionally, a subset of certificates issued by a CA can > be stored in the reverse component of crossCertificatePair attribute of > the issuing CA." > > Please note that to me subset includes none, some, or all. If > folks want further clarification, it is ok by me. > Santosh, the only issue I have with this text is that (at least with the rationale behind option 2) any cert that appears in the cACertificate attribute of a given CA entry, should also appear in the crossCertificatePair attribute in the same CA entry. What about deleting the reference to the cACertificate attribute from your text and proposing this as new text just for the crossCertificatePair attribute? Both Jan and David have indicated reasons to keep the "pair" together in the mutual case, so we should also consider adding the last paragraph of the text David proposed for that. Here's what the resulting text proposal would look like: > " A certificate issued to a CA by another shall be stored in the > forward component of crossCertificatePair attribute of > the subject CA. Optionally, a subset of certificates issued by a CA can > be stored in the reverse component of crossCertificatePair attribute of > the issuing CA. When both elements are present in the same value, the > value shall represent a mutual cross-certification of the two CAs. " > If we can come to consensus on that attribute, then let's see what we can do with the cACertificate attribute text. I agree with your view on what a subset is and I think that same definition would apply to the contents of the cACertificate attribute as a subset of the crossCertificatePair forward elements in option 2. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25829 for ietf-pkix-bks; Tue, 8 Sep 1998 13:02:56 -0700 (PDT) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA25825 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 13:02:55 -0700 (PDT) Received: from mailext02.compaq.com by mailext02.compaq.com via smail with esmtp id <m0zGRZ9-0007GRC@mailext02.compaq.com> for <ietf-pkix@imc.org>; Tue, 8 Sep 98 12:28:31 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.9 built 21-jan-98) Received: from mail.compaq.com([207.18.199.32]) by mailext02.compaq.com with SMTP (peer mailint02.compaq.com[207.18.199.35]) id rcv009876; Tue, 8 Sep 1998 12:28:31 -0500 (CDT) Received: from exchou-conn01.im.hou.compaq.com(really [172.18.22.253]) by mail.compaq.com via sendmail with esmtp id <m0zGRYi-0005BsC@mail.compaq.com> for <ietf-pkix@imc.org>; Tue, 8 Sep 98 12:28:04 -0500 (CDT) (/\##/\ Smail3.1.30.16 #30.10 built 18-dec-97) Received: by EXCHOU-CONN01.im.hou.compaq.com with Internet Mail Service (5.5.1960.3) id <SQ38VL6L>; Tue, 8 Sep 1998 12:29:54 -0500 Message-ID: <895FABD47F78D011863400805FBEBA8E0319E7A7@EXCHOU-CA0301.im.hou.compaq.com> From: "Fuerst, Neal" <Neal.Fuerst@COMPAQ.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: FOR Option 2 Date: Tue, 8 Sep 1998 11:05:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Thanks. Neal Fuerst Information Security Analyst Compaq Computer Corporation E-Mail: neal.fuerst@compaq.com Phone: 281.518.8072 Pager: 713.509.4586 Entrust validation string: OMCO-KGMF-KQZN "No matter how paranoid you are, you're not paranoid enough." Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25472 for ietf-pkix-bks; Tue, 8 Sep 1998 12:31:56 -0700 (PDT) Received: from docws001.shl.com (docws001.shl.com [159.249.56.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25468 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 12:31:55 -0700 (PDT) Received: from napmsnoc02.shl.com (napmsnoc02.shl.com [159.249.47.179]) by docws001.shl.com (8.7.3/8.7.3) with SMTP id OAA10756 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 14:21:38 -0500 Received: by napmsnoc02.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BDDB25.6EC159C0@napmsnoc02.shl.com>; Tue, 8 Sep 1998 12:37:25 -0700 Message-ID: <c=US%a=MCI%p=SHL%l=DALFW03-980908193704Z-53756@napmsnoc02.shl.com> From: "PACHL, Jan" <jpachl@shl.com> To: "'David Boyce'" <D.Boyce@isode.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: RE: forward & reverse elements - population Date: Tue, 8 Sep 1998 12:37:04 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk in response to: >From: David Boyce[SMTP:D.Boyce@isode.com] >"PACHL, Jan" writes: >>If the forward and the reverse element are never both present in the >>same pair (=either one is present or the other, but never both, in any >>given pair), what is the point of having the attribute defined as >>"pair"? >>In that case it would make better sense to have two separate attributes >>instead -- "forward certificate" and "reverse certificate". > >Well, we are trying to work with the defined X.509 attributes, so >creating new ones which duplicate existing definitions will just muddy >things further. I agree, though, that things might have been >different. > Yes, I agree we should work with the defined attributes. Presumably the crossCertificationPair attribute was defined as a pair (and not as two separate attributes) for a good reason. Jan Pachl >SHL Systemhouse Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25463 for ietf-pkix-bks; Tue, 8 Sep 1998 12:31:26 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25459 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 12:31:25 -0700 (PDT) Received: from mrohub2.mro.dec.com (mrohub2.mro.dec.com [16.34.192.32]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with ESMTP id PAA00906 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 15:36:08 -0400 (EDT) Received: by mrohub2.mro.dec.com with Internet Mail Service (5.5.1960.3) id <SQZT8L16>; Tue, 8 Sep 1998 15:36:09 -0400 Message-ID: <D107B66CF5B9D111BA2A0000F86630AB8D822A@ogoexc1.ogo.dec.com> From: Daya Puls <Daya.Puls@digital.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: For Option 2 Date: Tue, 8 Sep 1998 15:36:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Daya Puls, CISSP Intelligent Infrastructure Security Architect COMPAQ, IM Security 40 Old Bolton Road, OGO1-2/V12, Stow, MA 01775-1299 Fon: 978-496-9560, Fax: 978-496-9191, Eml: daya.puls@digital.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25403 for ietf-pkix-bks; Tue, 8 Sep 1998 12:22:07 -0700 (PDT) Received: from 2keys.ca (cr318128-a.rchrd1.on.wave.home.com [24.112.92.155]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25399 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 12:22:06 -0700 (PDT) From: rpierce@2keys.ca Received: (from rpierce@localhost) by 2keys.ca (8.8.7/8.8.7) id LAA16441 for ietf-pkix@imc.org; Tue, 8 Sep 1998 11:23:54 -0400 Message-Id: <199809081523.LAA16441@2keys.ca> Subject: For Option 2 To: ietf-pkix@imc.org (IETF PKIX) Date: Tue, 8 Sep 1998 15:23:54 +0000 () Content-Type: text Sender: owner-ietf-pkix@imc.org Precedence: bulk Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24057 for ietf-pkix-bks; Tue, 8 Sep 1998 10:11:58 -0700 (PDT) Received: from lion.harrisbank.com (lion.harrisbank.com [204.148.73.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA24053 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 10:11:54 -0700 (PDT) From: Dimitri.Vekris@bmo.com Received: by lion.harrisbank.com id AA24091 (SMTP Gateway 3.0 for ietf-pkix@imc.org) Tue, 8 Sep 1998 12:17:07 -0500 Received: by lion.harrisbank.com (Internal Mail Agent-1); Tue, 8 Sep 1998 12:17:07 -0500 To: ietf-pkiximcorg <ietf-pkix@imc.org> Subject: For Option 2 Message-Id: <0056090002874024000002L942*@MHS> Date: Tue, 8 Sep 1998 12:09:50 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23614 for ietf-pkix-bks; Tue, 8 Sep 1998 09:16:50 -0700 (PDT) Received: from smtp-gw.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23610 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 09:16:49 -0700 (PDT) Received: from mailhost.BayNetworks.COM ([141.251.211.49]) by smtp-gw.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id MAA11637 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 12:21:27 -0400 (EDT) Received: from ns2.corpeast.Baynetworks.com (ns2.corpeast.baynetworks.com [192.32.72.17]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with SMTP id SAA01073 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 18:20:50 +0200 (MET DST) Received: from bl-mail2.corpeast.BayNetworks.com (bl-mail2-nf0) by ns2.corpeast.Baynetworks.com (4.1/BNET-97/04/29-S) id AA00939; Tue, 8 Sep 98 12:20:50 EDT for ietf-pkix@imc.org Received: from dgiglio.corpeast.baynetworks.com (bne-cnc-126.corpeast.baynetworks.com [132.245.134.126]) by bl-mail2.corpeast.BayNetworks.com (Post.Office MTA v3.5.1 release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 12:20:46 -0400 Message-Id: <3.0.32.19980908122045.00f2f688@bl-mail2.corpeast.baynetworks.com> X-Sender: dgiglio@bl-mail2.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 08 Sep 1998 12:20:47 -0400 To: ietf-pkix@imc.org From: David_Giglio@baynetworks.com (David Giglio) Subject: For option 2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk ___________________________________________________________________ David Giglio - Senior Product Manager Bay Networks, Inc. Access Server Div. M/S BL8-05 dgiglio@baynetworks.com 5 Federal Street 978-916-4234 Office Billerica, MA 01821 978-916-4782 Fax Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23274 for ietf-pkix-bks; Tue, 8 Sep 1998 08:46:11 -0700 (PDT) Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23270 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 08:46:10 -0700 (PDT) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA04410; Tue, 8 Sep 1998 08:49:02 -0700 (PDT) Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA13627; Tue, 8 Sep 1998 08:50:48 -0700 (PDT) From: "Phillip M Hallam-Baker" <pbaker@verisign.com> To: "Mike Smith" <mfsmith@zionsbank.com>, <fod@brd.ie>, <Alan.Lloyd@OpenDirectory.com.au> Cc: <dave@chromatix.com>, <ietf-pkix@imc.org> Subject: OFF TOPIC ???? RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s) Date: Tue, 8 Sep 1998 11:50:46 -0400 Message-ID: <004d01bddb40$7194a9c0$ee0110ac@pbaker-pc.verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <s5f398ef.030@zionsbank.com> Importance: Normal Sender: owner-ietf-pkix@imc.org Precedence: bulk I'm having a lot of trouble following this discussion. It appears to have begun a discussion of the relative merits of X.500 vs LDAP server models. This does not appear to be something which is relevant to PKIX. LDAP is merely a protocol. It does not define a product. Arguments based on the 'scalability' of a client-server protocol are almost without exception irrelevant since scaling depends on server-server communication. The idea that the same protocol should serve both purposes is questionable at best. I fail to see how improved search capabilities will greatly assist for the purposes of PKIX unless the directories have the ability to break open, read and understand attributes embedded in certificates. If people believe that support for a specific (and specified) search mechanism would lead to an improvement in efficiency that is important to PKIX let us discuss that specific extension. We need to remember that we are charterted as an IETF working group and we are not in a position to endorse a particular directory strategy. If we want to be able to offload client work to a server of some kind we should first consider the requirements that motivate such an architectural approach and the trust implications of doing so before considering protocol extensions. Indeed a critical step would be deciding which protocol to base an implementation on. Phill Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23228 for ietf-pkix-bks; Tue, 8 Sep 1998 08:43:19 -0700 (PDT) Received: from lion.harrisbank.com (lion.harrisbank.com [204.148.73.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA23224 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 08:43:17 -0700 (PDT) From: Dimitri.Vekris@bmo.com Received: by lion.harrisbank.com id AA18645 (SMTP Gateway 3.0 for ietf-pkix@imc.org) Tue, 8 Sep 1998 10:48:27 -0500 Received: by lion.harrisbank.com (Internal Mail Agent-1); Tue, 8 Sep 1998 10:48:27 -0500 To: ietf-pkiximcorg <ietf-pkix@imc.org> Subject: For Option 2 Message-Id: <0056090002871633000002L932*@MHS> Date: Tue, 8 Sep 1998 10:41:10 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23117 for ietf-pkix-bks; Tue, 8 Sep 1998 08:34:16 -0700 (PDT) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23113 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 08:34:14 -0700 (PDT) Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Tue, 8 Sep 1998 16:38:15 +0100 X-Mailer: exmh version 2.0.2 2/24/98 To: "PACHL, Jan" <jpachl@shl.com> cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: Re: forward & reverse elements - population In-reply-to: Your message of "Tue, 08 Sep 1998 08:58:19 CDT." <c=US%a=MCI%p=SHL%l=DALFW03-980908135819Z-50946@dalmsdoc01.shl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Sep 1998 16:38:15 +0100 Message-ID: <20698.905269095@isode.com> From: David Boyce <D.Boyce@isode.com> Sender: owner-ietf-pkix@imc.org Precedence: bulk "PACHL, Jan" writes: >If the forward and the reverse element are never both present in the >same pair (=either one is present or the other, but never both, in any >given pair), what is the point of having the attribute defined as >"pair"? >In that case it would make better sense to have two separate attributes >instead -- "forward certificate" and "reverse certificate". Well, we are trying to work with the defined X.509 attributes, so creating new ones which duplicate existing definitions will just muddy things further. I agree, though, that things might have been different. >I can see some (limited?) use for populating both forward and reverse in >the same pair, to record mutual certification. Not primarily for path >discovery, but for answering other questions about certification >relationships. Yes. What I was trying to do was begin to pin down what it means when both elements are present in the same value, and conscious mutual certification seems an appropriate use. I suppose PKIX could specify that conforming CAs should not populate both elements in a value, but that applications processing the values for path development should not assume only one element is present. I note that the X.509 certificatePairExactMatch matching rule doesn't appear to cater for specifying 'values matching a forward certificate assertion which have no reverse certificate', or vice versa. Consequently, it may not be possible (using that Matching Rule, at least) to obtain ONLY the forward certificates. David. -- David Boyce Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND I'net: d.boyce@isode.com Isode's WWW: http://www.isode.com/ X.400: I=d;S=boyce;P=isode;A=mailnet;C=fi; Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23093 for ietf-pkix-bks; Tue, 8 Sep 1998 08:32:20 -0700 (PDT) Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23089 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 08:32:18 -0700 (PDT) Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Tue, 8 Sep 1998 16:36:44 +0100 X-Mailer: exmh version 2.0.2 2/24/98 To: Sharon Boeyen <sharon.boeyen@entrust.com> cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: Re: forward & reverse elements - population In-reply-to: Your message of "Mon, 07 Sep 1998 20:01:30 EDT." <D789F71F24B4D111955D00A0C99B4F50AC9748@sothmxs01.entrust.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Sep 1998 16:36:43 +0100 Message-ID: <20692.905269003@isode.com> From: David Boyce <D.Boyce@isode.com> Sender: owner-ietf-pkix@imc.org Precedence: bulk Sharon Boeyen writes: >3 - One more issue raised by David Boyce's proposed text was population of >the crossCertificatePair attribute in the case where certification between >two CAs is mutual. The syntax of the crossCertificatePair attribute is such >that a single value of the attribute is one of the following: >- only a forward element >- only a reverse element >- both a forward and reverse. > >I wonder though when one would be interested in retrieving a value that had >both forward and reverse present? Does anyone have an example of a >requirement for this? I can think of one example where population of both elements could be helpful for path development: the case when a strong bind request is received which contains just a signature, so that a certificate path has to be developed locally in order to verify the signature. If during this development, a mutual certificate pair is encountered, it might act as a hint that this is a good way to develop a certification path in the opposite direction for use when responding to the bind (assuming the responder intends to supply a certificate path in its response). Without this hint, building this path would be harder. > When doing path discovery, regardless of the >algorithm, wouldn't you be interested in one of the forward or reverse only >for a given operation? If that is true then wouldn't it be better not to >populate both forward and reverse in a single value but even in the case of >mutual certification, spread these certificates over different values of the >attribute? The reason I'm wondering about this is that the smallest unit of >information that LDAP can return is a whole attribute value (can't pull only >a forward or only a reverse from a single value). I'm trying to come up any >reason for wanting the two together in the mutual case and having trouble >coming up with a requirement. Again, when we get to the point of using >LDAPv3 and more complex filtering capabilities, we may get to a point where >we can retrieve single certs from the crossCertificatePair attribute, but if >both forward and reverse are populated in the same attribute value, you'll >get both certs. Views? I don't think that LDAPv3 will give you any finer-grained control over what is returned either. It would require transporting less than a whole value of an attribute, and it's hard to see how this would be something LDAPv3 would want to define. For path development purposes, I agree it's a pity to have to transport the reverse certificate with the forward, only to discard it because it's of no interest; but there it is. Some may feel that this bandwidth issue is enough to rule out populating both elements. It doesn't actively get in the way of path development, however, and there may be a meaningful population of both elements. David. -- David Boyce Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND I'net: d.boyce@isode.com Isode's WWW: http://www.isode.com/ X.400: I=d;S=boyce;P=isode;A=mailnet;C=fi; Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22703 for ietf-pkix-bks; Tue, 8 Sep 1998 07:57:32 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22699 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 07:57:31 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04610; Tue, 8 Sep 1998 11:02:10 -0400 (EDT) Message-Id: <199809081502.LAA04610@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-10.txt Date: Tue, 08 Sep 1998 11:02:09 -0400 Sender: owner-ietf-pkix@imc.org Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Certificate and CRL Profile Author(s) : R. Housley, W. Ford, T. Polk, D. Solo Filename : draft-ietf-pkix-ipki-part1-10.txt Pages : 129 Date : 04-Sep-98 This is the tenth draft of the Internet Public Key Infrastructure X.509 Certificate and CRL Profile. This draft is the result of Working Group Last Call, and includes modifications to reflect the group's final comments. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119. Please send comments on this document to the ietf-pkix@tandem.com mail list. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ipki-part1-10.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-10.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ipki-part1-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980904152252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ipki-part1-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ipki-part1-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980904152252.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22660 for ietf-pkix-bks; Tue, 8 Sep 1998 07:50:40 -0700 (PDT) Received: from hpb.hc-sc.gc.ca (hpb.hc-sc.gc.ca [198.103.237.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22656 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 07:50:38 -0700 (PDT) From: Jean_Bernatchez@hc-sc.gc.ca Received: from intdns.hwc.ca (intdns.hc-sc.gc.ca [198.103.172.78]) by hpb.hc-sc.gc.ca (8.8.7/8.7.3) with ESMTP id KAA05514 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 10:55:00 -0400 (EDT) Received: from smta00.hc-sc.gc.ca (smta00.hc-sc.gc.ca [142.4.1.25]) by intdns.hwc.ca (8.8.5/8.7.3) with SMTP id KAA11820 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 10:54:45 -0400 (EDT) Received: by smta00.hc-sc.gc.ca(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 85256679.0051E875 ; Tue, 8 Sep 1998 10:54:39 -0400 X-Lotus-FromDomain: HWC To: ietf-pkix@imc.org Message-ID: <85256679.0051E05C.00@smta00.hc-sc.gc.ca> Date: Tue, 8 Sep 1998 10:55:28 -0400 Subject: For Option 2 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@imc.org Precedence: bulk Jean Bernatchez 09/08/98 10:55 AM Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22068 for ietf-pkix-bks; Tue, 8 Sep 1998 07:00:36 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22063 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 07:00:32 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ5Q8>; Tue, 8 Sep 1998 10:05:31 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E16D248@WUHER> From: Santosh Chokhani <chokhani@cygnacom.com> To: "'Sharon Boeyen'" <sharon.boeyen@entrust.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: RE: forward & reverse elements - population Date: Tue, 8 Sep 1998 10:05:30 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk comments in-line. > -----Original Message----- > From: Sharon Boeyen [SMTP:sharon.boeyen@entrust.com] > Sent: Monday, September 07, 1998 8:02 PM > To: 'ietf-pkix@imc.org' > Subject: forward & reverse elements - population > > Three related issues: > > 1 - raised by Denis - need to clarify how one way certification of a > CA to > another CA is represented in the crossCertificationPair attribute (as > opposed to bilateral) > > Denis - would adding some text along the lines of that proposed by > David > Boyce (that at least one of the forward or reverse elements must be > present > in a value of the crossCertificatePair attribute) satisfy that? > > 2 - raised by Santosh - population of the reverse element of the > crossCertificatePair attribute not to be mandated. > > Santosh, I tend to agree with this. I'm curious whether you (and > others) > think we can mandate, especially in a schema spec, that the forward > certificates be published by the subject CA either? Is a schema spec > really > the place to dictate CA behaviour? Or should the schema spec provide > the > tools to be used for publishing the certs, should the CA decide to > publish > them. > [] I agree. I do not have problem with the following language. " A certificate issued to a CA by another shall be stored either in the caCertificate or forward component of crossCertificatePair attribute of the subject CA. Optionally, a subset of certificates issued by a CA can be stored in the reverse component of crossCertificatePair attribute of the issuing CA." Please note that to me subset includes none, some, or all. If folks want further clarification, it is ok by me. > In the case of option 2, if we mandate neither, the > crossCertificatePair > attribute would contain all the certificates of the forward and > reverse > types that this CA has decided to publish. The content of the > cACertificate > attribute would still be a subset of the content of the > crossCertificatePair > attribute plus self issued certificates. This would result in a > situation > where some certificates would be published only in the issuing CAs > entry, > some only in the subject CAs entry and others in both. But in all > cases a > relying party would be able to find them in the crossCertificatePair > attribute and if the relying party understood the CAs definition of > domain > they could take advantage of the subset published in that CAs > cACertificate > attribute. > > Do you think this reflects the real business needs or do you think we > need > to mandate that the subject CA publish forward certificates issued for > it? I > lean toward not mandating either, but can go along with either > approach on > this one. > > 3 - One more issue raised by David Boyce's proposed text was > population of > the crossCertificatePair attribute in the case where certification > between > two CAs is mutual. The syntax of the crossCertificatePair attribute is > such > that a single value of the attribute is one of the following: > - only a forward element > - only a reverse element > - both a forward and reverse. > > I wonder though when one would be interested in retrieving a value > that had > both forward and reverse present? Does anyone have an example of a > requirement for this? When doing path discovery, regardless of the > algorithm, wouldn't you be interested in one of the forward or reverse > only > for a given operation? If that is true then wouldn't it be better not > to > populate both forward and reverse in a single value but even in the > case of > mutual certification, spread these certificates over different values > of the > attribute? The reason I'm wondering about this is that the smallest > unit of > information that LDAP can return is a whole attribute value (can't > pull only > a forward or only a reverse from a single value). I'm trying to come > up any > reason for wanting the two together in the mutual case and having > trouble > coming up with a requirement. Again, when we get to the point of using > LDAPv3 and more complex filtering capabilities, we may get to a point > where > we can retrieve single certs from the crossCertificatePair attribute, > but if > both forward and reverse are populated in the same attribute value, > you'll > get both certs. Views? > > > > > ------------------ > Sharon Boeyen > Entrust Technologies > > mailto:sharon.boeyen@entrust.com Tel: (613) 247-3181 > http://www.entrust.com Fax: (613) 247-3690 > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22025 for ietf-pkix-bks; Tue, 8 Sep 1998 06:55:51 -0700 (PDT) Received: from itsfw.CSE-CST.GC.CA (itsfw.cse.dnd.ca [131.136.196.7]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA22020 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 06:55:50 -0700 (PDT) From: jplachance@cse-cst.gc.ca Received: id JAA06138; Tue, 8 Sep 1998 09:57:04 -0400 Received: by gateway id <NWL91ZG3>; Tue, 8 Sep 1998 09:54:53 -0400 Message-ID: <C3222395B150D11185B300A0C9045CB90C3123@mailserverb.its.cse.dnd.ca> To: ietf-pkix@imc.org Subject: For Option 2 Date: Tue, 8 Sep 1998 10:03:01 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk To whom it may concern, For Option 2. Regards, J.P. Lachance Senior Systems Engineer PMO GOC PKI Communications Security Establishement Tel: 613-991-7504 Fax: 613-991-7455 Internet: jplachance@cse-cst.gc.ca Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22008 for ietf-pkix-bks; Tue, 8 Sep 1998 06:53:13 -0700 (PDT) Received: from docws001.shl.com (docws001.shl.com [159.249.56.252]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA22004 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 06:53:11 -0700 (PDT) Received: from dalmsdoc01.shl.com (dalmsdoc01.shl.com [159.249.142.247]) by docws001.shl.com (8.7.3/8.7.3) with SMTP id IAA57036 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 08:42:50 -0500 Received: by dalmsdoc01.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BDDB06.D7033400@dalmsdoc01.shl.com>; Tue, 8 Sep 1998 08:58:25 -0500 Message-ID: <c=US%a=MCI%p=SHL%l=DALFW03-980908135819Z-50946@dalmsdoc01.shl.com> From: "PACHL, Jan" <jpachl@shl.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>, "'Sharon Boeyen'" <sharon.boeyen@entrust.com> Subject: RE: forward & reverse elements - population Date: Tue, 8 Sep 1998 08:58:19 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk If the forward and the reverse element are never both present in the same pair (=either one is present or the other, but never both, in any given pair), what is the point of having the attribute defined as "pair"? In that case it would make better sense to have two separate attributes instead -- "forward certificate" and "reverse certificate". I can see some (limited?) use for populating both forward and reverse in the same pair, to record mutual certification. Not primarily for path discovery, but for answering other questions about certification relationships. Jan Pachl SHL Systemhouse >From: Sharon Boeyen[SMTP:sharon.boeyen@entrust.com] >[ ... ] > >3 - One more issue raised by David Boyce's proposed text was population of >the crossCertificatePair attribute in the case where certification between >two CAs is mutual. The syntax of the crossCertificatePair attribute is such >that a single value of the attribute is one of the following: >- only a forward element >- only a reverse element >- both a forward and reverse. > >I wonder though when one would be interested in retrieving a value that had >both forward and reverse present? Does anyone have an example of a >requirement for this? When doing path discovery, regardless of the >algorithm, wouldn't you be interested in one of the forward or reverse only >for a given operation? If that is true then wouldn't it be better not to >populate both forward and reverse in a single value but even in the case of >mutual certification, spread these certificates over different values of the >attribute? The reason I'm wondering about this is that the smallest unit of >information that LDAP can return is a whole attribute value (can't pull only >a forward or only a reverse from a single value). I'm trying to come up any >reason for wanting the two together in the mutual case and having trouble >coming up with a requirement. Again, when we get to the point of using >LDAPv3 and more complex filtering capabilities, we may get to a point where >we can retrieve single certs from the crossCertificatePair attribute, but if >both forward and reverse are populated in the same attribute value, you'll >get both certs. Views? > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21745 for ietf-pkix-bks; Tue, 8 Sep 1998 06:07:58 -0700 (PDT) Received: from itsfw.CSE-CST.GC.CA (itsfw.cse.dnd.ca [131.136.196.7]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA21741 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 06:07:57 -0700 (PDT) From: tjcasar@its.cse.dnd.ca Received: id JAA05475; Tue, 8 Sep 1998 09:09:56 -0400 Received: by gateway id <NWL91ZFR>; Tue, 8 Sep 1998 09:07:45 -0400 Message-ID: <D151573E3DC6CF11AAAD00A0C90428FD296876@mailserver.cse.dnd.ca> To: ietf-pkix@imc.org Subject: For Option 2 Date: Tue, 8 Sep 1998 09:07:44 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21325 for ietf-pkix-bks; Tue, 8 Sep 1998 05:17:25 -0700 (PDT) Received: from fin.gc.ca (cis-pec.fin.gc.ca [198.103.32.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21321 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 05:17:23 -0700 (PDT) From: DeRosenroll.Michael@tbs-sct.gc.ca Received: from connfax.fin.gc.ca ([172.17.22.10]) by sonic.fin.gc.ca with ESMTP id <19735>; Tue, 8 Sep 1998 08:20:39 -0400 Received: by CONNFAX with Internet Mail Service (5.5.1960.3) id <SQ2M0LBH>; Tue, 8 Sep 1998 08:22:19 -0400 Message-ID: <B103B7FE19C3D011900200805F19428E013BAA37@server5.tbs-sct.gc.ca> To: ietf-pkix@imc.org Subject: For option 2 Date: Mon, 7 Sep 1998 09:34:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20854 for ietf-pkix-bks; Tue, 8 Sep 1998 04:13:26 -0700 (PDT) Received: from apollo.fedworld.gov (apollo.fedworld.gov [192.239.92.203]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20850 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 04:13:24 -0700 (PDT) Received: from jdiduro.fedworld.gov ([208.232.200.69] (may be forged)) by apollo.fedworld.gov (8.8.6 (PHNE_14041)/8.8.6) with SMTP id HAA01052 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 07:17:43 -0400 (EDT) Message-Id: <4.0.2.19980908072326.0443e530@192.239.92.203> X-Sender: jdiduro@192.239.92.203 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 08 Sep 1998 07:23:34 -0400 To: ietf-pkix@imc.org From: "John A. DiDuro" <jdiduro@apollo.fedworld.gov> Subject: for Option 2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20761 for ietf-pkix-bks; Tue, 8 Sep 1998 04:07:11 -0700 (PDT) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA20755 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 04:07:09 -0700 (PDT) Received: by WUHER with Internet Mail Service (5.0.1458.49) id <SF7TZ537>; Tue, 8 Sep 1998 07:12:08 -0400 Message-ID: <51BF55C30B4FD1118B4900207812701E186603@WUHER> From: Jeremy Bingham <jbingham@cygnacom.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: For Option 2 Date: Tue, 8 Sep 1998 07:12:07 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA08715 for ietf-pkix-bks; Tue, 8 Sep 1998 01:20:27 -0700 (PDT) Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA08709 for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 01:20:26 -0700 (PDT) Received: from ben ([195.121.86.74]) by smtp03.wxs.nl (Netscape Messaging Server 3.54) with SMTP id AAA16EA for <ietf-pkix@imc.org>; Tue, 8 Sep 1998 10:25:05 +0200 Message-ID: <35F4EA2C.64AC@wxs.nl> Date: Tue, 08 Sep 1998 10:26:20 +0200 From: Ton van Lieshout <ton.van.lieshout@wxs.nl> Reply-To: ton.van.lieshout@wxs.nl Organization: Point Information Systems B.V. X-Mailer: Mozilla 3.01C-WXS-16 (Win95; I) MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: FOR OPTION 2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@imc.org Precedence: bulk As an Entrust prtner, we vote for option 2. Ton van Lieshout Technical Director Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA29595 for ietf-pkix-bks; Mon, 7 Sep 1998 23:01:20 -0700 (PDT) Received: from security.no ([193.71.64.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA29591 for <ietf-pkix@imc.org>; Mon, 7 Sep 1998 23:01:17 -0700 (PDT) Received: by gateway.security.no id <26882>; Tue, 8 Sep 1998 07:01:48 +0100 Message-Id: <98Sep8.070148gmt+0100.26882@gateway.security.no> From: =?iso-8859-1?Q?Svein_L=F8seth?= <slo@security.no> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: For Option 2 Date: Tue, 8 Sep 1998 07:05:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAA29592 Sender: owner-ietf-pkix@imc.org Precedence: bulk --------------------------------------------------------------------------------------------------------------------------- Svein Løseth Tlf.: +47-22 95 86 83 Network Security AS Fax: +47-22 60 44 27 Gaustadalléen 21 Dir. Line: +47-22 95 85 48 N-0371 OSLO GSM: +47-91 77 09 63 NORWAY http://www.security.no Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26304 for ietf-pkix-bks; Mon, 7 Sep 1998 17:02:27 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA26299 for <ietf-pkix@imc.org>; Mon, 7 Sep 1998 17:02:26 -0700 (PDT) Received: id UAA07858; Mon, 7 Sep 1998 20:04:33 -0400 Received: by gateway id <S2S6XSHF>; Mon, 7 Sep 1998 20:01:31 -0400 Message-ID: <D789F71F24B4D111955D00A0C99B4F50AC9748@sothmxs01.entrust.com> From: Sharon Boeyen <sharon.boeyen@entrust.com> To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: forward & reverse elements - population Date: Mon, 7 Sep 1998 20:01:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ietf-pkix@imc.org Precedence: bulk Three related issues: 1 - raised by Denis - need to clarify how one way certification of a CA to another CA is represented in the crossCertificationPair attribute (as opposed to bilateral) Denis - would adding some text along the lines of that proposed by David Boyce (that at least one of the forward or reverse elements must be present in a value of the crossCertificatePair attribute) satisfy that? 2 - raised by Santosh - population of the reverse element of the crossCertificatePair attribute not to be mandated. Santosh, I tend to agree with this. I'm curious whether you (and others) think we can mandate, especially in a schema spec, that the forward certificates be published by the subject CA either? Is a schema spec really the place to dictate CA behaviour? Or should the schema spec provide the tools to be used for publishing the certs, should the CA decide to publish them. In the case of option 2, if we mandate neither, the crossCertificatePair attribute would contain all the certificates of the forward and reverse types that this CA has decided to publish. The content of the cACertificate attribute would still be a subset of the content of the crossCertificatePair attribute plus self issued certificates. This would result in a situation where some certificates would be published only in the issuing CAs entry, some only in the subject CAs entry and others in both. But in all cases a relying party would be able to find them in the crossCertificatePair attribute and if the relying party understood the CAs definition of domain they could take advantage of the subset published in that CAs cACertificate attribute. Do you think this reflects the real business needs or do you think we need to mandate that the subject CA publish forward certificates issued for it? I lean toward not mandating either, but can go along with either approach on this one. 3 - One more issue raised by David Boyce's proposed text was population of the crossCertificatePair attribute in the case where certification between two CAs is mutual. The syntax of the crossCertificatePair attribute is such that a single value of the attribute is one of the following: - only a forward element - only a reverse element - both a forward and reverse. I wonder though when one would be interested in retrieving a value that had both forward and reverse present? Does anyone have an example of a requirement for this? When doing path discovery, regardless of the algorithm, wouldn't you be interested in one of the forward or reverse only for a given operation? If that is true then wouldn't it be better not to populate both forward and reverse in a single value but even in the case of mutual certification, spread these certificates over different values of the attribute? The reason I'm wondering about this is that the smallest unit of information that LDAP can return is a whole attribute value (can't pull only a forward or only a reverse from a single value). I'm trying to come up any reason for wanting the two together in the mutual case and having trouble coming up with a requirement. Again, when we get to the point of using LDAPv3 and more complex filtering capabilities, we may get to a point where we can retrieve single certs from the crossCertificatePair attribute, but if both forward and reverse are populated in the same attribute value, you'll get both certs. Views? ------------------ Sharon Boeyen Entrust Technologies mailto:sharon.boeyen@entrust.com Tel: (613) 247-3181 http://www.entrust.com Fax: (613) 247-3690 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA25807 for ietf-pkix-bks; Mon, 7 Sep 1998 15:26:02 -0700 (PDT) Received: from aum.proper.com (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA25803 for <ietf-pkix@imc.org>; Mon, 7 Sep 1998 15:26:01 -0700 (PDT) Message-Id: <199809072226.PAA25803@mail.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 07 Sep 1998 15:30:57 -0700 To: ietf-pkix@imc.org From: Paul Hoffman / IMC <phoffman@imc.org> Subject: RE: PKIX freeware library coming soon (fwd) In-Reply-To: <199809072249.AAA24035@cs.pub.ro> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@imc.org Precedence: bulk At 12:49 AM 9/8/98 +0200, Monica Pietrosanu-Ene wrote: >Any recent news related to that freeware library? >I searched the MIT site and I didn't find anything related to that implementation. It should be available by the end of August, isn't it? There is a new mailing list to discuss the library. Please see <http://www.imc.org/imc-pfl/> for more information on the mailing list and the library. I've been told that the folks making the library are almost-almost ready to release the first version (they can't turn the page on their calendars to September until they do...). At that point, the new mailing list for the library should become active. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA16002 for ietf-pkix-bks; Mon, 7 Sep 1998 11:55:40 -0700 (PDT) Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA15998 for <ietf-pkix@imc.org>; Mon, 7 Sep 1998 11:55:39 -0700 (PDT) From: Lynn.Wheeler@firstdata.com Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id PAA27888; Mon, 7 Sep 1998 15:00:41 -0400 (EDT) Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id PAA11891; Mon, 7 Sep 1998 15:00:39 -0400 (EDT) Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 85256678.006834C0 ; Mon, 7 Sep 1998 14:58:12 -0400 X-Lotus-FromDomain: FDC To: Mike Smith <mfsmith@zionsbank.com> cc: fod@brd.ie, Alan.Lloyd@OpenDirectory.com.au, dave@chromatix.com, ietf-pkix@imc.org Message-ID: <88256678.0067D844.00@lnsunr02.firstdata.com> Date: Mon, 7 Sep 1998 11:59:43 -0700 Subject: Re: Relational vs Directory Repository Models (was RE: path development complexity s) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk and with an intelligent repository, along with assumptions about knowing every use to contain risk/liability exposures and provide timely status ... and a nudge in the protocol here & there ... it becomes account authority instead of certification authority client gets even thinner ... and account authority provides enhanced value transaction (most of the certificates are redundant/superfluous). Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA07642 for ietf-pkix-bks; Mon, 7 Sep 1998 10:30:30 -0700 (PDT) Received: from relay2.elvis.ru (ss10.elvis.ru [194.190.192.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA07638 for <ietf-pkix@imc.org>; Mon, 7 Sep 1998 10:30:28 -0700 (PDT) Received: by relay2.elvis.ru (8.8.5/1.25) id VAA29408; Mon, 7 Sep 1998 21:35:28 +0400 (MSK DST) Message-ID: <XFMail.980907213528.versed@elvis.ru> X-Mailer: XFMail 1.3 [p0] on Solaris X-Priority: 3 (Normal) Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 07 Sep 1998 21:35:28 +0400 (MSK DST) From: Pavel Krylov <versed@elvis.ru> To: "ietf-pkix@imc.org" <ietf-pkix@imc.org> Subject: depth Sender: owner-ietf-pkix@imc.org Precedence: bulk My question: What depth of certificate tree is exist now?? Average value? Sharon, Santosh? --------------------------------------- Pavel V.Krylov versed@elvis.ru Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA07055 for ietf-pkix-bks; Mon, 7 Sep 1998 10:23:19 -0700 (PDT) Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA07051 for <ietf-pkix@imc.org>; Mon, 7 Sep 1998 10:23:18 -0700 (PDT) Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 07 Sep 1998 11:23:47 -0600 Message-Id: <s5f3c243.014@zionsbank.com> X-Mailer: Novell GroupWise 4.1 Date: Mon, 07 Sep 1998 11:23:32 -0600 From: Mike Smith <mfsmith@zionsbank.com> To: Alan.Lloyd@OpenDirectory.com.au Cc: ietf-pkix@imc.org Subject: Re: Re relational - and Dirs and all that Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk Thanks for the remedial lesson. We also tend towards business objects in design and implmentation. I too, think that these hybrid systems are the direction of the future. michael Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06891 for ietf-pkix-bks; Mon, 7 Sep 1998 09:57:29 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06886 for <ietf-pkix@imc.org>; Mon, 7 Sep 1998 09:57:20 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <SMGRLFKM>; Tue, 8 Sep 1998 03:01:18 +1000 Message-ID: <D1A949D4508DD1119C8100400533BEDC07380E@DSG1> From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> To: "'mfsmith@zionsbank.com'" <mfsmith@zionsbank.com> Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org> Subject: Re relational - and Dirs and all that Date: Tue, 8 Sep 1998 03:01:12 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA06888 Sender: owner-ietf-pkix@imc.org Precedence: bulk Alan: Mike the amazing thing is I am in Charlotte US and working remote to Aus. I had to repaste the text as I got an error? in the long distance server? Comments in line marked Alan. Quick response from so far away, I am still amazed at this Internet technology, even though I've been relying on it daily, since the early '80s. :) Alan: I have been relying on since 9.00 AM this morning :-) Mike: With an X500 model, then one would have to create the directory service agents (DSA) to actually process the requests. My limited understanding of how these work makes it complex indeed to process through multiple layers from one DSA to another (using DAP to cahin to other "directories"). Alan: Directories are distributed, object oriented, named based transaction systems. They operate on distributed naming contexts with objects such as people (that have certs) and CAs that have certs. Directories to us are the foundation for new forms distributed information engineering. (However, LDAP servers (non X.500 ones) do not do distribution - so watch out for the scaling issues with those things). Most think LDAP servers are the only forms of directories and because they have distribution issues - it means that all directories have distribution issues - X.500 (which can have LDAP access) does not have these, therefore the information solution space is wider than LDAP server only systems. Mike: Server side logic, whether stored procedures, external routines or objects from an Application Server, seems less complex for development of client server applications with thin clients, since the variety of tools and supporting technology is so available. My "take" on X500 models is that the directory system was designed for thin servers and thin cleints (thinner clients with the original LDAP, fatter clients (almost DAP) with the current LDAP models). Now, the discussion seems to be on how fat (huge) and intelligent (brilliant) to make the clients. Alan: Thin and fat seems can get mixed up these days. There is the stacks - LDAP is about 230kb and DAP which is about 130kb. LDAP on bigger searches becomes less efficient and DAP has features that deal with master/copy entries and controlling chaining ie. DAP has twice (scaleable) the functionality than LDAP. In terms of "processing" above the stack - LDAP clients do more because they have to chase referrals (no chaining in the servers) and with the LDAP servers (non X.500 ones) if one wants to authenticate users one has to replicate everything to everywhere. ie. what LDAP does not do that X.500 does.. Humans have to. Mike: As you have discovered, a relational DBMS can perform all of the functions of the X.500 requirements and a whole lot more. Alan: But X.500 deals correctly with object oriented engineering, distributed name based systems and scaling. There is a difference. DBMSs deal with data management with integrity (as well as many other things)they (RDBs) do not distribute or scale in the same way- X.500 is about protected distributed object oriented engineering. We have put the both together (RDBs and X.500) - in fact we have made commercial RDBMs extremely fast and distributed object oriented system that is conformant to X.500 (with LDAP access and provides LDAP server interconnectivity). Mike: As a business-focused technologist, I also like the easier integration of an RDBMS-engined repository with the RDBMS' that are used to run the business (I know some Directory schemes output data to RDBMS - some may even allow two-way communication). I like the idea of searching multiple RDBMS sources in one query instead of chaining DSA to DSA - I also think the logic can be more comprehensive. By comprehensive, let's say against a rule set that can contain more than one decision matrix, maybe with some knowledge-based intelligence acquired from yet another DBMS. I can envision a central-responder repository model that "handles" simple requests for path building that get as complex as necessary across hierarchical, cross-certified, policy mapped, Web of trust, personal trust, bilaterally agreed relationships AND others yet to be defined. Alan: I am a very business focussed technologist and believe that OO distributed systems are required and that these will integrate with RDBs where appropriate (eg. Legacy systems or where relational requirements extend beyond those as affored with OO/RDB systems (like our directory). We provide a range of tools for RDBs and LDIF interchange and integration. Mike: Relationship management becomes the central repository's concern, not that of the relying party. The relying party needs a business relationship with the central repository, or their CA (issuer) does. Contracts and agreements amongst the players need to exist for a central system to work, but there are business models that can support highly complex relationship structures. Alan: Some - repeat some of this can be designed with directories and OO structures. Mike: I tend to think of how to incorporate a workable PKI into an electronic commerce scenario that may involve business relationships with thousands of companies, hundreds of financial institutions and their millions of customers. Alan: We do - in fact we scale to these requirements. Mike: In all probability, this means working with many PKI systems and models and their varied implementations. I do not see a system accepting "all" certificates coming into it. Having said that, though, in business, its always risk vs. reward and if someone wishes to reward (and indemnify) me enough to honor self-authenticated or other "weak" certificates, maybe I'll need to incorporate that into my model as well. Mike: I do not see basing a business solely on a directory, no matter its integrity or "globalness". I do not even see basing a directory service business solely on an X.500 directory. Alan: Some do now - the trend is to have distributed systems and basing these on scaleable - mutually authenticated OO - X.500 technologies. However, this does not mean that some centralised RDB applications wont exist - they will in our view become "directory enabled" so they can interwork with WEB/RDB/OO(X.500)business information infrastructures that support a range of authenticated role based people and applications. This is the new approach to business information system modelling - and this also includes multi - distributed CA/PKI functions. I do find business uses for directory-structured systems, but find the duplication of data and differing and costly development environment (ASN.1 vs C++, ProC, SQL, Java, or whatever) annoying. I look towards enterprise services for customers and employees that incorporates PKI - not to PKI as something totally separate. Alan: Absolutely So, that's the origin of my comments on relational "vs." directory. I really think that there should be a synthesis, not an opposition. Since both LDAP and X.500 and X.509 (with version 3) are independent of the directory model and technology, Alan: Dont quite agree - X.509 will not go far without X.500. if we think "outside the X.500 box", then we can use the strengths of the X.500 directory model and add on some strenghts in logic processing from the tools in the RDBMS world. Alan: We did and we have and we do - see Integrated Information Infrastructures. I will send a paper off list. That way, one can support LDAP, DAP, Java Applets, integrated client applications, or whatever development technology becomes available across IP to meet constantly changing business requirements. Alan: Agree Alan: Regards alan Michael Snip.. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA06469 for ietf-pkix-bks; Mon, 7 Sep 1998 09:01:23 -0700 (PDT) Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA06465 for <ietf-pkix@imc.org>; Mon, 7 Sep 1998 09:01:21 -0700 (PDT) Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 07 Sep 1998 10:01:30 -0600 Message-Id: <s5f3aefa.078@zionsbank.com> X-Mailer: Novell GroupWise 4.1 Date: Mon, 07 Sep 1998 10:01:25 -0600 From: Mike Smith <mfsmith@zionsbank.com> To: fod@brd.ie, Alan.Lloyd@OpenDirectory.com.au Cc: dave@chromatix.com, ietf-pkix@imc.org Subject: Re: RE: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s) Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk Quick response from so far away, I am still amazed at this Internet technology, even though I've been relying on it daily, since the early '80s. :) With an X500 model, then one would have to create the directory service agents (DSA) to actually process the requests. My limited understanding of how these work makes it complex indeed to process through multiple layers from one DSA to another (using DAP to cahin to other "directories"). Server side logic, whether stored procedures, external routines or objects from an Application Server, seems less complex for development of client server applications with thin clients, since the variety of tools and supporting technology is so available. My "take" on X500 models is that the directory system was designed for thin servers and thin cleints (thinner clients with the original LDAP, fatter clients (almost DAP) with the current LDAP models). Now, the discussion seems to be on how fat (huge) and intelligent (brilliant) to make the clients. As you have discovered, a relational DBMS can perform all of the functions of the X.500 requirements and a whole lot more. As a business-focused technologist, I also like the easier integration of an RDBMS-engined repository with the RDBMS' that are used to run the business (I know some Directory schemes output data to RDBMS - some may even allow two-way communication). I like the idea of searching multiple RDBMS sources in one query instead of chaining DSA to DSA - I also think the logic can be more comprehensive. By comprehensive, let's say against a rule set that can contain more than one decision matrix, maybe with some knowledge-based intelligence acquired from yet another DBMS. I can envision a central-responder repository model that "handles" simple requests for path building that get as complex as necessary across hierarchical, cross-certified, policy mapped, Web of trust, personal trust, bilaterally agreed relationships AND others yet to be defined. Relationship management becomes the central repository's concern, not that of the relying party. The relying party needs a business relationship with the central repository, or their CA (issuer) does. Contracts and agreements amongst the players need to exist for a central system to work, but there are business models that can support highly complex relationship structures. I tend to think of how to incorporate a workable PKI into an electronic commerce scenario that may involve business relationships with thousands of companies, hundreds of financial institutions and their millions of customers. In all probability, this means working with many PKI systems and models and their varied implementations. I do not see a system accepting "all" certificates coming into it. Having said that, though, in business, its always risk vs. reward and if someone wishes to reward (and indemnify) me enough to honor self-authenticated or other "weak" certificates, maybe I'll need to incorporate that into my model as well. I do not see basing a business solely on a directory, no matter its integrity or "globalness". I do not even see basing a directory service business solely on an X.500 directory. I do find business uses for directory-structured systems, but find the duplication of data and differing and costly development environment (ASN.1 vs C++, ProC, SQL, Java, or whatever) annoying. I look towards enterprise services for customers and employees that incorporates PKI - not to PKI as something totally separate. So, that's the origin of my comments on relational "vs." directory. I really think that there should be a synthesis, not an opposition. Since both LDAP and X.500 and X.509 (with version 3) are independent of the directory model and technology, if we think "outside the X.500 box", then we can use the strengths of the X.500 directory model and add on some strenghts in logic processing from the tools in the RDBMS world. That way, one can support LDAP, DAP, Java Applets, integrated client applications, or whatever development technology becomes available across IP to meet constantly changing business requirements. Michael >>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 09/07 9:15 AM >>> Mike - I am not sure if I understand your response as it mixes technology statements. So comments in line. ---------- From: Mike Smith To: fod@brd.ie; Alan.Lloyd@OpenDirectory.com.au Cc: dave@chromatix.com; ietf-pkix@imc.org Sent: 9/8/98 12:27:08 AM Subject: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s) Some of you have heard this before from me and others, but, maybe it's worth repeating at this time. AL: Its new to me so thanks. Complexity of the problem of path building requires a more robust/intelligent repository. AL: Agree Think out of the directory model and consider a relational database behind the LDAP responder. Per cert request times may be slower, but the ability to work with multiple business (trust) models and supply ALL of the necessary certs (in one query) for the most complex path validation scenario outweighs (and maybe outperforms) a series of client-side processing and LDAP requests. AL: This is an implementation issue - we use a Patented SQL design under our X.500 LDAP product and its fast including distributed (multi server) operations. One always scales the hardware, processing, process and DB and network to do the job anyway. The business logic for multiple trust models would reside on the host. The LDAP request could be parsed, the business (trust) rules selected according to either or both the relying party's and sender's trust requirements. AL: Host - is this a server or a mainframe - this is a sizing issue? Perhaps a view of the system should be: a)A distributed X.500 system with high performance (even though it uses SQL RDBMS ) to give it industry strength and integrity. b) LDAP or DAP (DAP is for the lucky few that want to control the scope of directory chaining to get a cert path and getting Master cert from CA entries:-) ) access by the client software - with the presented cert and the domain in which validation is required information. Note: yet another weakness in LDAP will show up with trust/scope of cert path processing...Somehow LDAP and LDAP servers just dont seem to mix with X.509, certpath processing and CAs... c) A CA that populates its portion of The interconnected DIB with CA certs, CRLs, etc and validation information. d)Trusted CA utilities that run/execute on the CA "server" or "host" to manage the CA's validation "environment". The RDBMS and its server-side business logic can even chain requests to other CA directories if necessary. AL: Yes - there is nothing to stop a directory request to retrieve something with a Search/Matching rule into subordinate objects below the CA entry in question - via alias or cross referencing to other CAs DIBs - but this is a bit messy re Search and Trust management. But very achieveable with a few extensions to Results Correlation processing or CA Utilities. Of course, my perspective is that the business logic and trust requirements come from the CA, not the end-user. If the trust model rule making is placed on the end user, then one would need to design a pretty fat, customer customizable client software piece. AL: Agree and totally agree. The way things were turning out with client cert validation software is like LDAP clients have - more code in them than in a DSA. Simply because they incorporated (lesser) distribution handling functions - eg. referrals, replication management, etc - than X.500 DSAs in fact do. Fat unwieldy clients are symptomatic of what happens if one has no distributed (server) system, information and service based model to work with. regards alan PS - the draft for dir cert stat will be formally circulated next week. Michael >>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 09/07 7:55 AM >>> Thanks Frank - Its nice to see some reality re this issue. My draft submitted re dir cert stat. point one is we all need a scaleable directory infrastructure for any CA system to work and point two is we dont need CA information designs that act as a maze for megabytes of client software to find the "way out".. As said I think CAs must provide a validation service based on the cert presented and the domain of the client requesting validation. We seem to have gone down the track of inventing a X.509 CA model (and directory objects) for the sake of a CA on what it wants to do with certificate management - as the first part of the system design. As opposed to a CA model that provides a simple client with a validation service, which really is the second part of the system design. For chasing cert paths - Names in the certficates should do - plus the context (ie. the requestor) of the validation. And the CA should do the rest. The directory service and its matching rules proposed in the dir cert stat doc are the foundation of this. All thoughts on this area are welcome. regards alan ---------- From: Frank O'Dwyer To: Alan Lloyd Cc: Dave Horvath; ietf-pkix@imc.org Sent: 9/5/98 9:44:06 PM Subject: Re: path development complexity (was Re: What the straw poll mean s) Alan Lloyd wrote: > I have a few views in that certs must be supported by mutually > authenticated distributed X.500 directory systems otherwise 509 based > systems just wont scale and provide the commercial utilitity as > demanded by global EC directed organisations. Not having this foundation > - one just drops into all sorts of operational cost, scaling and > efficiency holes. What I am talking about is not the underlying retrieval efficiency, but rather the cost of total wrong-turns in the overall search, e.g: 10:15 Developing a path to verify certificate for "Joe's Server, NY" 10:15 Retrieving cross-certificates for "Keys R Us" 10:16 Retrieving cross-certificates for "Keys R Us Too" 10:17 Retrieving cross-certificates for "Barcelona CA" 10:18 Retrieving cross-certificates for "Spanish Bank" CARRIER LOST Users just love that browser "stop" button, and so any verification process that can't complete in a second or so is broken (my opinion). Throwing a meatier directory and/or caches (as someone else suggested) at it doesn't help if finding just one path involves trawling the world for hundreds of names. That is why I think it would be better if the certificates themselves contained positive guidance as to where to go next, or if cross-cert scenarios that lead to vague searches could be identified and discouraged. For example, maybe name constraints could be used as clues to guide path building. As things stand, content like basic constraints just tells you where *not* to search. That seems to leave building in heuristics, and hoping that working down from your trusted root(s) and/or up from the end-entity cert(s), you somehow meet in the middle and terminate in some reasonable time -- something that is by no means guaranteed. Maybe I have missed something obvious here - but I think this could, given time, turn out to be a showstopper scalability issue if it is not addressed early. Cheers, Frank O'Dwyer. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06115 for ietf-pkix-bks; Mon, 7 Sep 1998 08:12:09 -0700 (PDT) Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06109 for <ietf-pkix@imc.org>; Mon, 7 Sep 1998 08:12:02 -0700 (PDT) Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <SMGRLFKB>; Tue, 8 Sep 1998 01:16:00 +1000 Message-ID: <D1A949D4508DD1119C8100400533BEDC073803@DSG1> From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> To: "'fod@brd.ie '" <fod@brd.ie>, "'Mike Smith '" <mfsmith@zionsbank.com> Cc: "'dave@chromatix.com '" <dave@chromatix.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org> Subject: RE: Relational vs Directory Repository Models (was RE: pathdevelo pment complexity s) Date: Tue, 8 Sep 1998 01:15:58 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@imc.org Precedence: bulk Mike - I am not sure if I understand your response as it mixes technology statements. So comments in line. ---------- From: Mike Smith To: fod@brd.ie; Alan.Lloyd@OpenDirectory.com.au Cc: dave@chromatix.com; ietf-pkix@imc.org Sent: 9/8/98 12:27:08 AM Subject: Relational vs Directory Repository Models (was RE: pathdevelopment complexity s) Some of you have heard this before from me and others, but, maybe it's worth repeating at this time. AL: Its new to me so thanks. Complexity of the problem of path building requires a more robust/intelligent repository. AL: Agree Think out of the directory model and consider a relational database behind the LDAP responder. Per cert request times may be slower, but the ability to work with multiple business (trust) models and supply ALL of the necessary certs (in one query) for the most complex path validation scenario outweighs (and maybe outperforms) a series of client-side processing and LDAP requests. AL: This is an implementation issue - we use a Patented SQL design under our X.500 LDAP product and its fast including distributed (multi server) operations. One always scales the hardware, processing, process and DB and network to do the job anyway. The business logic for multiple trust models would reside on the host. The LDAP request could be parsed, the business (trust) rules selected according to either or both the relying party's and sender's trust requirements. AL: Host - is this a server or a mainframe - this is a sizing issue? Perhaps a view of the system should be: a)A distributed X.500 system with high performance (even though it uses SQL RDBMS ) to give it industry strength and integrity. b) LDAP or DAP (DAP is for the lucky few that want to control the scope of directory chaining to get a cert path and getting Master cert from CA entries:-) ) access by the client software - with the presented cert and the domain in which validation is required information. Note: yet another weakness in LDAP will show up with trust/scope of cert path processing...Somehow LDAP and LDAP servers just dont seem to mix with X.509, certpath processing and CAs... c) A CA that populates its portion of The interconnected DIB with CA certs, CRLs, etc and validation information. d)Trusted CA utilities that run/execute on the CA "server" or "host" to manage the CA's validation "environment". The RDBMS and its server-side business logic can even chain requests to other CA directories if necessary. AL: Yes - there is nothing to stop a directory request to retrieve something with a Search/Matching rule into subordinate objects below the CA entry in question - via alias or cross referencing to other CAs DIBs - but this is a bit messy re Search and Trust management. But very achieveable with a few extensions to Results Correlation processing or CA Utilities. Of course, my perspective is that the business logic and trust requirements come from the CA, not the end-user. If the trust model rule making is placed on the end user, then one would need to design a pretty fat, customer customizable client software piece. AL: Agree and totally agree. The way things were turning out with client cert validation software is like LDAP clients have - more code in them than in a DSA. Simply because they incorporated (lesser) distribution handling functions - eg. referrals, replication management, etc - than X.500 DSAs in fact do. Fat unwieldy clients are symptomatic of what happens if one has no distributed (server) system, information and service based model to work with. regards alan PS - the draft for dir cert stat will be formally circulated next week. Michael >>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 09/07 7:55 AM >>> Thanks Frank - Its nice to see some reality re this issue. My draft submitted re dir cert stat. point one is we all need a scaleable directory infrastructure for any CA system to work and point two is we dont need CA information designs that act as a maze for megabytes of client software to find the "way out".. As said I think CAs must provide a validation service based on the cert presented and the domain of the client requesting validation. We seem to have gone down the track of inventing a X.509 CA model (and directory objects) for the sake of a CA on what it wants to do with certificate management - as the first part of the system design. As opposed to a CA model that provides a simple client with a validation service, which really is the second part of the system design. For chasing cert paths - Names in the certficates should do - plus the context (ie. the requestor) of the validation. And the CA should do the rest. The directory service and its matching rules proposed in the dir cert stat doc are the foundation of this. All thoughts on this area are welcome. regards alan ---------- From: Frank O'Dwyer To: Alan Lloyd Cc: Dave Horvath; ietf-pkix@imc.org Sent: 9/5/98 9:44:06 PM Subject: Re: path development complexity (was Re: What the straw poll mean s) Alan Lloyd wrote: > I have a few views in that certs must be supported by mutually > authenticated distributed X.500 directory systems otherwise 509 based > systems just wont scale and provide the commercial utilitity as > demanded by global EC directed organisations. Not having this foundation > - one just drops into all sorts of operational cost, scaling and > efficiency holes. What I am talking about is not the underlying retrieval efficiency, but rather the cost of total wrong-turns in the overall search, e.g: 10:15 Developing a path to verify certificate for "Joe's Server, NY" 10:15 Retrieving cross-certificates for "Keys R Us" 10:16 Retrieving cross-certificates for "Keys R Us Too" 10:17 Retrieving cross-certificates for "Barcelona CA" 10:18 Retrieving cross-certificates for "Spanish Bank" CARRIER LOST Users just love that browser "stop" button, and so any verification process that can't complete in a second or so is broken (my opinion). Throwing a meatier directory and/or caches (as someone else suggested) at it doesn't help if finding just one path involves trawling the world for hundreds of names. That is why I think it would be better if the certificates themselves contained positive guidance as to where to go next, or if cross-cert scenarios that lead to vague searches could be identified and discouraged. For example, maybe name constraints could be used as clues to guide path building. As things stand, content like basic constraints just tells you where *not* to search. That seems to leave building in heuristics, and hoping that working down from your trusted root(s) and/or up from the end-entity cert(s), you somehow meet in the middle and terminate in some reasonable time -- something that is by no means guaranteed. Maybe I have missed something obvious here - but I think this could, given time, turn out to be a showstopper scalability issue if it is not addressed early. Cheers, Frank O'Dwyer. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05809 for ietf-pkix-bks; Mon, 7 Sep 1998 07:27:40 -0700 (PDT) Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA05805 for <ietf-pkix@imc.org>; Mon, 7 Sep 1998 07:27:39 -0700 (PDT) Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Mon, 07 Sep 1998 08:27:27 -0600 Message-Id: <s5f398ef.030@zionsbank.com> X-Mailer: Novell GroupWise 4.1 Date: Mon, 07 Sep 1998 08:27:08 -0600 From: Mike Smith <mfsmith@zionsbank.com> To: fod@brd.ie, Alan.Lloyd@OpenDirectory.com.au Cc: dave@chromatix.com, ietf-pkix@imc.org Subject: Relational vs Directory Repository Models (was RE: path development complexity s) Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-ietf-pkix@imc.org Precedence: bulk Some of you have heard this before from me and others, but, maybe it's worth repeating at this time. Complexity of the problem of path building requires a more robust/intelligent repository. Think out of the directory model and consider a relational database behind the LDAP responder. Per cert request times may be slower, but the ability to work with multiple business (trust) models and supply ALL of the necessary certs (in one query) for the most complex path validation scenario outweighs (and maybe outperforms) a series of client-side processing and LDAP requests. The business logic for multiple trust models would reside on the host. The LDAP request could be parsed, the business (trust) rules selected according to either or both the relying party's and sender's trust requirements. The RDBMS and its server-side business logic can even chain requests to other CA directories if necessary. Of course, my perspective is that the business logic and trust requirements come from the CA, not the end-user. If the trust model rule making is placed on the end user, then one would need to design a pretty fat, customer customizable client software piece. Michael >>> Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> 09/07 7:55 AM >>> Thanks Frank - Its nice to see some reality re this issue. My draft submitted re dir cert stat. point one is we all need a scaleable directory infrastructure for any CA system to work and point two is we dont need CA information designs that act as a maze for megabytes of client software to find the "way out".. As said I think CAs must provide a validation service based on the cert presented and the domain of the client requesting validation. We seem to have gone down the track of inventing a X.509 CA model (and directory objects) for the sake of a CA on what it wants to do with certificate management - as the first part of the system design. As opposed to a CA model that provides a simple client with a validation service, which really is the second part of the system design. For chasing cert paths - Names in the certficates should do - plus the context (ie. the requestor) of the validation. And the CA should do the rest. The directory service and its matching rules proposed in the dir cert stat doc are the foundation of this. All thoughts on this area are welcome. regards alan ---------- From: Frank O'Dwyer To: Alan Lloyd Cc: Dave Horvath; ietf-pkix@imc.org Sent: 9/5/98 9:44:06 PM Subject: Re: path development complexity (was Re: What the straw poll mean s) Alan Lloyd wrote: > I have a few views in that certs must be supported by mutually > authenticated distributed X.500 directory systems otherwise 509 based > systems just wont scale and provide the commercial utilitity as > demanded by global EC directed organisations. Not having this foundation > - one just drops into all sorts of operational cost, scaling and > efficiency holes. What I am talking about is not the underlying retrieval efficiency, but rather the cost of total wrong-turns in the overall search, e.g: 10:15 Developing a path to verify certificate for "Joe's Server, NY" 10:15 Retrieving cross-certificates for "Keys R Us" 10:16 Retrieving cross-certificates for "Keys R Us Too" 10:17 Retrieving cross-certificates for "Barcelona CA" 10:18 Retrieving cross-certificates for "Spanish Bank" CARRIER LOST Users just love that browser "stop" button, and so any verification process that can't complete in a second or so is broken (my opinion). Throwing a meatier directory and/or caches (as someone else suggested) at it doesn't help if finding just one path involves trawling the world for hundreds of names. That is why I think it would be better if the certificates themselves contained positive guidance as to where to go next, or if cross-cert scenarios that lead to vague searches could be identified and discouraged. For example, maybe name constraints could be used as clues to guide path building. As things stand, content like basic constraints just tells you where *not* to search. That seems to leave building in heuristics, and hoping that working down from your trusted root(s) and/or up from the end-entity cert(s), you somehow meet in the middle and terminate in some reasonable time -- something that is by no means guaranteed. Maybe I have missed something obvious here - but I think this could, given time, turn out to be a showstopper scalability issue if it is not addressed early. Cheers, Frank O'Dwyer. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA05623 for ietf-pkix-bks; Mon, 7 Sep 1998 06:56:10 -0700 (PDT) Received: from maild.telia.com (root@maild.telia.com [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA05618 for <ietf-pkix@imc.org>; Mon, 7 Sep 1998 06:56:06 -0700 (PDT) Received: from d1o65.telia.com (root@d1o65.telia.com [62.20.132.241]) by maild.telia.com (8.8.8/8.8.8) with ESMTP id QAA03923; Mon, 7 Sep 1998 16:01:01 +0200 (CEST) Received: from stefans (t2o65p95.telia.com [62.20.132.215]) by d1o65.telia.com (8.8.8/8.8.5) with SMTP id QAA03606; Mon, 7 Sep 1998 16:00:42 +0200 (CEST) Message-Id: <3.0.32.19980907155744.00a55170@m1.403.telia.com> X-Sender: u40400192@m1.403.telia.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 07 Sep 1998 15:58:39 +0200 To: "Aram Perez" <aram@apple.com>, bob jueneman <bjueneman@novell.com> From: Stefan Santesson <stefan@accurata.se> Subject: Re: Digital signature and non-repudiation key usage bits Cc: ietf-pkix@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA05620 Sender: owner-ietf-pkix@imc.org Precedence: bulk Hi Aram, Some comments follow. At 10:17 AM 9/4/98 -0700, Aram Perez wrote: >Bob and Stefan: > >>At 06:42 PM 9/2/98 -0600, Bob Jueneman wrote: >><snip> >>>>I suggest that we stick to the standardized definitions of the key usage >>>>bits and leave >>>>policy issues out of a common certificate profile. >>> >>>If there were any sense of the community as to what these definitions really >>>mean, or ought to mean, we would probably not be having this discussion. >>>Otherwise I would agree with you. >>>> >>>>non-repudiation is according to standard selected by the NR bit, not NR in >>>>combination with DS bit. Inclusion of the DS bit means that DS mechanisms >>>>other than non-repudiation are allowed for the key. > >Is non-repudiation a mechanism or a service? Sorry for my careless language. Non-repudiation is a service and that service is not defined by the CA. However the CA may indicate that the certificate is aimed to support that service. > >>> >>>I believe that is exactly the issue. Are you suggesting that NR plus DS >>should not >>>be allowed? Why? >> >>No I do not. I do suggest that such decision is up to local policy. But >>there will be some policies where this combination will not be allowed, but >>I think you agree to that. > >My problem with this is that to provide "digital" non-repudiation, you have to >"sign" something with a digital signature. I understand that the key usage field >is very overloaded, so I'll probably have to live with it, but I do not agree or >like it. Yes and no. It is clear that X509 has mixed two levels. The mechanism level and the service level. Looking back in the mirror that might have been a bad mix. What's even worse is that the service bit NR in some cases is used as an alternative to DS. To accomplish this the standard has been forced to define both bits to a combined service/mechanism bit. I.e. NR is selecting use of digital signatures and DS is selecting services other than non-repudiation. This is causing the messy debate and could be used as an argument for a defect report. However considering the standard as it is, can we use it? Yes I think so, even if it's not perfect. > >> >>The important thing is that I suggest that the NR bit and DS bit has >>separate meaning and that they should be set independently to specify DS, >>NR or both. >> >>The vague definition of the NR bit is a problem, I agree to that. > >YES!! > >> >>If I were to define some distinguishing property of the NR bit that would be: >> >> Non repudiation denotes services constructed in such way that: >> 1) The signature provides proof of the integrity and >> origin of data - both in an unforgeable relationship - which can be >> verified by any third party at any time.[X.509 / ISO 9594-8] >> 2) The signature is applied to a message where the signatory is capable >> of, and required to, accept responsibility for the message content >> before signing. > >But NR is set in the certificate (i.e. the public key) and does not tell you >whether the signatory (who is using the private key) actually was capable of >accepting responsibility. Yes you are right, it doesn't. And it shouldn't. Since the CA isn't the provider of that service the certificate will tell nothing about the service in which the certificate is used. The key usage bit is a requirement stated by the CA for staying with it's liabilities, not a promise that the requirements will be met. > >> 3) The signatory's liability for signing the message can be concluded >> from the signed message itself, possibly within a well known and agreed >> context that can be verified by any third party at any time. >> >>This definitions rules out any signed logon ticket or other data >>authentication mechanisms where the signature says "this message wasn't >>changed" instead of "I take full responsibility for the message content". > >You do not need a digital signature to tell you "this message wasn't changed". >CRCs, LRCs, checksums, etc have been used for this longer that I've been alive. >You use digital signature when you want to know "this message wasn't changed" >AND "this message came from the reported sender". > Agreed. I guess my point still stands. >> >>But since this is not defined by