From ???@??? Sat Jan 03 13:53:47 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id NAA18717 for ; Thu, 1 Jan 1998 13:11:20 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 1 Jan 1998 14:13:53 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id NAA21671; Thu, 1 Jan 1998 13:08:32 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 10651 for IETF-PKIX@LISTS.TANDEM.COM; Thu, 1 Jan 1998 13:07:38 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id NAA02067 for ; Thu, 1 Jan 1998 13:07:37 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id NAA08453; Thu, 1 Jan 1998 13:07:06 -0800 (PST) Received: from wford-pc by mentat.verisign.com (8.8.5/BCH1.0) id NAA22451; Thu, 1 Jan 1998 13:07:02 -0800 (PST) X-Sender: wford@mail.verisign.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.32.19980101153437.009fbd10@mail.verisign.com> Date: Thu, 1 Jan 1998 15:57:43 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Warwick Ford Subject: Re: [IETF-PKIX] Dave's Critical Proposal To: IETF-PKIX@LISTS.TANDEM.COM Status: Dave: At 02:35 PM 12/31/97 -0500, David P. Kemp wrote: >Warwick (and Bob), > You are correct; I did not make a distinction between "recognize" >and "support". A hypothetical implementation might recognize a particular >extension but not, for some reason, claim for compliance purposes to >support it. Would the following rule be more suitable? > > "If an implementation claims PKIX-compliant support for a particular > extension, where the scope of "support" is specified in the > extension definition, then when processing that extension the value > of the critical flag SHALL be ignored." > > >In the case of certificatePolicies, "recognize" or "support" means that >the application must support both the certificatePolicies extension >{ id-ce 32 } itself and at least one of the policies (specified by >the policyIdentifier field) contained in the extension. No, I don't think this solves the whole problem. I think John is right in pointing out a design weakness in X.509, with respect to the definition of the Certificate Policies extension. Fact of the matter is that "Critical Certificate Policies" extension and "Noncritical Certificate Policies" extension really should be two different extension types, since they have quite different semantics. Use of the criticality indicator to signify different behaviour is not a good thing. In fact, there is an even bigger problem ... I have run across scenarios where you might want to have both a "Critical Certificate Policies" extension and a "Noncritical Certificate Policies" extension in the one cert, and that, of course, is not permitted. In retrospect, I feel we should have defined two extension types (they can both have the same syntax) -- say, "Certificate Policies Restriction" and "Supported Certificate Policies". I am unsure, however, if it would be a good thing to try to fix this in X.509 at this stage. (I can certainly raise this as a new defect at the January X.500 meeting if the PKIX group thinks this a good idea.) Warwick ------------- >> From: John Pawling >> >> Dave, >> >> X.509, Sec 12.4.3, certificate check, bullet 6 states: >> "d) If the certificate policies extension is present and is flagged >> critical, compute the intersection of the policies in that extension and the >> authority-constrained-policy-set and put the result as the new value of >> authority-constrained-policy-set. Check that the intersection of >> authority-constrained-policy-set and user-constrained-policy-set is non-empty." >> >> If certificate-processing software followed your proposed rule, then it >> wouldn't be allowed to use the value of the certificate policies extension >> critical flag as part of the certification path validation process specified >> in X.509, Sec 12.4.3. Therefore, your statement is contradictory to X.509 >> and should not be added to PKIX I. > > >I submit that this contradiction is a red flag that a design inconsistency >exists in X.509. > >A CA has three options with respect to including a particular extension in >a certificate: not present, non-critical, and critical. > >An application has two options: claim support for an extension or not claim >support. > >The processing of a particular extension by an application may have the >following outcomes: > > | Application: > Cert: | Not supported Supported > |----------------|------------- > absent | N/A | N/A > | | > non-critical | Ignore | Process > | | > critical | Reject cert | Process > > >The path validation procedure described in section 12.4.3 introduces >a third column to processing model: > > |--------------- > absent | N/A > | > non-critical | Process-A > | > critical | Process-B > > >The use of a single flag for two independent purposes (managing >compatibility with non-supporting applications, and selecting different >processing in supporting applications) sounds like a mistake. > >Is there really a need for the phrase "and is flagged critical" to be >included in certificate checks paragraph d)? If not, it should be >removed from X.509. > >If there is an operational requirement for both certificatePolicies >that are used as input to authority-constrained-policy-set, and >policies that are present in a cert but not used as input to a-c-p-s, >then two different extensions should be defined to specify the two >different processing procedures. My suspicion is that there is no such >operational requirement. > > --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From ???@??? Sat Jan 03 13:54:11 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA24492 for ; Sat, 3 Jan 1998 12:26:47 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sat, 3 Jan 1998 13:29:20 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA16338; Sat, 3 Jan 1998 12:23:26 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 10913 for IETF-PKIX@LISTS.TANDEM.COM; Sat, 3 Jan 1998 12:22:48 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id MAA05617 for ; Sat, 3 Jan 1998 12:22:47 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id MAA23647; Sat, 3 Jan 1998 12:22:14 -0800 (PST) Received: from mmyers-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA26064; Sat, 3 Jan 1998 12:22:11 -0800 (PST) X-Sender: mmyers@mail (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.32.19980103121150.007af100@mail> Date: Sat, 3 Jan 1998 12:22:14 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: mmyers@VERISIGN.COM Subject: Re: [IETF-PKIX] OCSP Change Request To: IETF-PKIX@LISTS.TANDEM.COM Status: Steve, At 12:56 PM 12/31/97 +0000, Stephen Farrell wrote: >Hi Mike, > >> >1. The standard response message should include a MessageId field. This >> >allows the client to reference a response previously received which >> >contains a path deemed unacceptable by the OCSP client. Note that this >> >does not affect caching of responses. (A HREF would also suffice.) >> >> A MessageId field sounds like a useful request extension. It would however >> predictably extend the complexity of an OCSP server such it must maintain >> this state information in addition to, for example, nonce information. > >I agree that MessageId is a request extension, but would like it to >be a standard part of the response. I can see that it introduces some >state into a server which supports the request extension, however, >that statefulness is required in order to produce a "next" path >for the same request. Would it be sufficient for your needs that MessageID be present in the response if present in the request? > >> >2. The standard response should include the base64 encoding of the entire >> >path and set of CRLs used to verify the certificate. There is very little >> >overhead involved as the OCSP server must possess all the relevant >> >items. >> >> I agree the OCSP server may have this information on hand, but its >> inclusion in the default case would be overkill for environments with >> well-defined trust paths. Also, I hadn't seen OCSP as an alternate CRL >> retrieval mechanism. In some instances OCSP deployment, there may not be >> any CRLs to send back. > >I guess we're assuming different environments. I'd like that the >OCSP server and its clients needn't necessarily share well-defined >trust paths. > >How about if the standard response were to contain the full certification >path used by the OCSP server with a way of using the extension mechanism >for the client to ask for a copy of the CRLs used? I would expect in most instances the full certification path would be redundant information. SSL and SMIME clients already have means of receiving (and do receive) this information as an aspect of those security protocols. What value is there in receiving what I already have stored on my machine? I would like to look at some details of how this is actually going to work in practice first. How do you see chaining working? Are cross certificates involved? How is each signature in the chain validated? > >> >3. A request extension should be defined which means "give me the next >> >path for response <>". The response should contain an >> >alternate certification path (+ CRLs) for the initial request. Of course the >> >second response contains a different MessageId so that iteration is >> >supported. Again this response can be cached without problems. (Or >> >nothing is needed if a HREF is present.) >> >> Might I ask that a draft of this proposed use of OCSP extensibility be >> drawn up, roughly in line with the briefing of this approach to extensions >> as discussed in D.C.? > >Fair enough. I'll try to do that in the next week or so. OK. > >Meanwhile, I think it'd be worthwhile addressing the issue below on >the list. > >> >In addition I'd note that the OCSP server should be chosen by (e.g. >> >configured into) the OCSP client. Using a cert extension to name the OCSP >> >server seems to open up security holes - e.g. it would allow the OCSP server >> >to masquerade as a CA to any of its clients.. >> >> The contents of the certificate would be trusted to the extent the >> signature on the certificate is trusted. > >I guess I basically don't like the situation where a certificate >contains the location of the OCSP server - it seems too much like making >the OCSP server into a root CA for the client (unless the OCSP server >actually is a root CA for the client, which is maybe what you had in >mind). An OCSP server is simply another means of acquiring the same information we would otherwise acquire via CRLs, albeit in a more timely fashion. It is to a large degree equivalent to a URL in CRLDistributionPoints locating a CRL on a particular Web server. > >How do you actually see this working? Do you in fact expect that certs >will contain the location of the OCSP server? If so, how does a client >know that it should trust the named OCSP server? Maybe I'm just >misreading the draft, but I'd like to see this spelt out. The use of AuthorityInfoAccess in end-entity certificate maps to the well-defined notion of CRLDistributionPoints. Now, if one doesn't trust the CRLDistributionPoints asserted by the issuer of a certificate, one is free to configure one's client to acquire this same information elsewhere. Similarly, if one doesn't trust the AuthorityInfoAccess content a CA places into a certificate, local configuration of the client can override. Mike From ???@??? Sun Jan 04 21:47:42 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id UAA07146 for ; Sun, 4 Jan 1998 20:36:56 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sun, 4 Jan 1998 21:39:31 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id UAA15162; Sun, 4 Jan 1998 20:34:08 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 11296 for IETF-PKIX@LISTS.TANDEM.COM; Sun, 4 Jan 1998 20:34:21 -0800 Received: from brickbat8.mindspring.com (brickbat8.mindspring.com [207.69.200.11]) by Tandem.com (8.8.8/2.0.1) with ESMTP id UAA17128 for ; Sun, 4 Jan 1998 20:34:18 -0800 (PST) Received: from mindspring.com (ACCS-AS49-DP09.NWRK.grid.net [206.80.177.202]) by brickbat8.mindspring.com (8.8.5/8.8.5) with ESMTP id XAA26043; Sun, 4 Jan 1998 23:34:13 -0500 (EST) X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <34B0035F.35157DB8@mindspring.com> Date: Sun, 4 Jan 1998 16:47:12 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Dwight Arthur Subject: Re: [IETF-PKIX] NO SUBJECT Comments: cc: Mack Hicks , Russ Housley To: IETF-PKIX@LISTS.TANDEM.COM Status: On trust and cross certification: I believe that there is a persistent misperception among technologists in this field that an RP will trust someone because of the certificate(s) that person can produce. On the contrary I would suggest that in many cases the RP represents an enterprise that causes a certificate to be granted because of a pre-existing relationship of trust. In other words, trust leads to certificates, certificates do not lead to trust. If my enterprise operates a system which we have agreed to make accessible to you, it is because we already have some reason to trust you, such as a contractual relationship with your employer, or collateral that you have deposited with us, or maybe a line of credit that you have identified and we have verified. The certificate plays an important role: it allows my system to validate your identity at the time that you access it, and allows you to create "digital signatures" as lasting verifiable indications that you commit yourself and/or your enterprise to various transactions. In order to achieve these benefits without the overhead and expense of personally issuing certificates to everyone I trust, I will rely in some cases on CAs operated by others to issue the certificates. To be able to validate these certificates, I may require some relationship with the external CA that may require cross-certification (although there may be other simpler ways such as bilateral exchange of keys). BUT IN NO CASE does the fact that I cross certify an external CA make me willing to trust any and all certs issued by that CA. All it does is that when I receive a signature from someone I am inclined to trust, it provides me with a path for validation of the signture, a method to determine that the private key is apparently free of compromise to this point, and perhaps a pointer into a directory from which other relevant data might be retrieved. What will, however, be quite useful in the future will be a certificate granted by my trade association, or by the CPA firm that audits the organization that operates the CA, or maybe some other body stating that the CA's CPS meets my trade association's requirements for accreditation at some level and that the CPA's scheduled and unscheduled audits demonstrate an acceptable degree of operational compliance with the policies specified in the CPS. If I find this certificate revoked I will definitely consider withholding trust from holders of certificates issued by the disaccredited (discredited ?) CA. Despite the fact that I have good reason (other than the cert) to trust the subject party, the discreditation (?) may signal that the cert is no longer a reliable indicator that the person holding it is in fact the person I trust. Question: it the CPA-to-CA certificate a cross-certificate under the recently circulated definitions of terms? I do not recall any mention of accreditation. -Dwight Arthur On 12/19/97, Russ Housley wrote: > Mack: > > I understand your issues, and in the banking community, there may be very > limited corss certification. > > I was simply trying to point out that the issuance of a cross certificate > from CA_a to CA_b need not cause every certificate issued by CA_b become > valid to the community that consider CA_a to be a trusted root. If there > is an easily identified subset of CA_b's community and CA_a trusts CA_b > correctly validate the membership in that subset, then cross certification > is an appropriate mechanism. Trust is the center of this issue. You > correctly point out that bankers like to minimize the number of people (and > orgianizations) that they need to trust. It greatly simplifies the risk > analysis and risk management. > > Russ > > At 01:43 PM 12/17/97 -0800, Mack Hicks wrote: > >For: IETF-PKIX Mailing list > > > >From: "Russ Housley" > > > >> Mike: > >> > >>This is not necessarily so. The use of extensions can limit the scope of > >>the "tree" that becomes valid as a result of cross-certification. For > >>example, name constraints could result in a small subset of the > >>certificates issued by a CA being considered valid in the context path that > >>includes a cross certificate. > >> > >>Russ > > > >Russ, > > > >I have to voice my agreement with Mike that cross-certification > >is not manageable (technical banking term - "scary".)) > > > >An example, the trusted relationships between UNIX nodes. One can > >make the point that the Rhost kind of trust is similar to the > >cross-certification model. Rhost type of trust has done nothing > >but get lots of people into lots and lots of trouble. > > > >Cross certification may look OK to field commanders in military > >applications. Ya know -"Well that's Sam's group - he and I > >played hockey together - Let's trust those guys." > > > >Some people think banks trust each other through their Am Bnks Ass > >number (like on the checks). Anyone who has gotten a bounced check > >knows this is not the case. Knowing the "naming" and "addressing" > >(name constraints!) does not increase the level of trust. > > > >Keeping naming constraints current - or even manageable - is the > >full time task for lots of people in the mainframe world. > >Keeping that trust (usually in one place - like RACF or ACF2) > >is a full time job that often goes horribly wrong. > > > > > >So, for financial transactions, we are left with on-line status > >verification. Is there any bank out there that wants to cross > >certify? With whom? > > > >- - - - - - - - - - - - - > >Mack Hicks (415) 278-7230 -- Interactive Banking Division > >425 1st St m/s3671, SF CA 94105 > > From ???@??? Sun Jan 04 19:35:30 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id TAA05130 for ; Sun, 4 Jan 1998 19:13:56 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sun, 4 Jan 1998 20:16:29 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id TAA11470; Sun, 4 Jan 1998 19:10:35 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 11176 for IETF-PKIX@LISTS.TANDEM.COM; Sun, 4 Jan 1998 19:09:55 -0800 Received: from hpb.hc-sc.gc.ca (hpb.hc-sc.gc.ca [198.103.237.4]) by Tandem.com (8.8.8/2.0.1) with ESMTP id SAA09373 for ; Sun, 4 Jan 1998 18:59:53 -0800 (PST) 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 VAA03693 for ; Sun, 4 Jan 1998 21:59:22 -0500 (EST) Received: from smta01.hc-sc.gc.ca (smta01.hc-sc.gc.ca [142.4.99.231]) by intdns.hwc.ca (8.8.5/8.7.3) with SMTP id VAA19520 for ; Sun, 4 Jan 1998 21:59:21 -0500 (EST) Received: by smta01.hc-sc.gc.ca(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 85256583.00107AF8 ; Sun, 4 Jan 1998 22:00:00 -0500 X-Lotus-FromDomain: HWC Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: <85256583.00101D4F.00@smta01.hc-sc.gc.ca> Date: Sun, 4 Jan 1998 21:57:40 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Alan_Buffett@HC-SC.GC.CA To: IETF-PKIX@LISTS.TANDEM.COM Status: Alan Buffett 01/04/98 09:57 PM subscribe From ???@??? Mon Jan 05 11:35:34 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id FAA20575 for ; Mon, 5 Jan 1998 05:23:17 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 5 Jan 1998 06:25:50 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id FAA10236; Mon, 5 Jan 1998 05:19:13 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 11508 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 5 Jan 1998 05:19:21 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id FAA00929 for ; Mon, 5 Jan 1998 05:19:20 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id FAA04126; Mon, 5 Jan 1998 05:18:48 -0800 (PST) Received: from wford-pc by mentat.verisign.com (8.8.5/BCH1.0) id FAA03538; Mon, 5 Jan 1998 05:18:46 -0800 (PST) X-Sender: wford@mail.verisign.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.32.19980105080906.009e2b10@mail.verisign.com> Date: Mon, 5 Jan 1998 08:09:08 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Warwick Ford Subject: Re: [IETF-PKIX] NO SUBJECT To: IETF-PKIX@LISTS.TANDEM.COM Status: Dwight: In my score-keeping on the terminology issue, I have thus far seen support for at least two totally different interpretations of the term "cross-certification", then several different shades of meaning beyond that. I would contend that "cross-certification" is NOT a well-defined term and suggest we move to (and clearly define) more precise terms such as "CA-certification" and "inter-domain certification". I was giving the list another few days after the break to make sure that all inputs are in, before making a concrete proposal. Regards, Warwick At 04:47 PM 1/4/98 -0500, Dwight Arthur wrote: >On trust and cross certification: > >I believe that there is a persistent misperception among technologists >in this field that an RP will trust someone because of the >certificate(s) that person can produce. On the contrary I would suggest >that in many cases the RP represents an enterprise that causes a >certificate to be granted because of a pre-existing relationship of >trust. In other words, trust leads to certificates, certificates do not >lead to trust. > >If my enterprise operates a system which we have agreed to make >accessible to you, it is because we already have some reason to trust >you, such as a contractual relationship with your employer, or >collateral that you have deposited with us, or maybe a line of credit >that you have identified and we have verified. > >The certificate plays an important role: it allows my system to validate >your identity at the time that you access it, and allows you to create >"digital signatures" as lasting verifiable indications that you commit >yourself and/or your enterprise to various transactions. In order to >achieve these benefits without the overhead and expense of personally >issuing certificates to everyone I trust, I will rely in some cases on >CAs operated by others to issue the certificates. To be able to validate >these certificates, I may require some relationship with the external CA >that may require cross-certification (although there may be other >simpler ways such as bilateral exchange of keys). > >BUT IN NO CASE does the fact that I cross certify an external CA make me >willing to trust any and all certs issued by that CA. All it does is >that when I receive a signature from someone I am inclined to trust, it >provides me with a path for validation of the signture, a method to >determine that the private key is apparently free of compromise to this >point, and perhaps a pointer into a directory from which other relevant >data might be retrieved. > >What will, however, be quite useful in the future will be a certificate >granted by my trade association, or by the CPA firm that audits the >organization that operates the CA, or maybe some other body stating that >the CA's CPS meets my trade association's requirements for accreditation >at some level and that the CPA's scheduled and unscheduled audits >demonstrate an acceptable degree of operational compliance with the >policies specified in the CPS. If I find this certificate revoked I will >definitely consider withholding trust from holders of certificates >issued by the disaccredited (discredited ?) CA. Despite the fact that I >have good reason (other than the cert) to trust the subject party, the >discreditation (?) may signal that the cert is no longer a reliable >indicator that the person holding it is in fact the person I trust. > >Question: it the CPA-to-CA certificate a cross-certificate under the >recently circulated definitions of terms? I do not recall any mention of >accreditation. > >-Dwight Arthur > > > >On 12/19/97, Russ Housley wrote: >> Mack: >> >> I understand your issues, and in the banking community, there may be very >> limited corss certification. >> >> I was simply trying to point out that the issuance of a cross certificate >> from CA_a to CA_b need not cause every certificate issued by CA_b become >> valid to the community that consider CA_a to be a trusted root. If there >> is an easily identified subset of CA_b's community and CA_a trusts CA_b >> correctly validate the membership in that subset, then cross certification >> is an appropriate mechanism. Trust is the center of this issue. You >> correctly point out that bankers like to minimize the number of people (and >> orgianizations) that they need to trust. It greatly simplifies the risk >> analysis and risk management. >> >> Russ >> >> At 01:43 PM 12/17/97 -0800, Mack Hicks wrote: >> >For: IETF-PKIX Mailing list >> > >> >From: "Russ Housley" >> > >> >> Mike: >> >> >> >>This is not necessarily so. The use of extensions can limit the scope of >> >>the "tree" that becomes valid as a result of cross-certification. For >> >>example, name constraints could result in a small subset of the >> >>certificates issued by a CA being considered valid in the context path that >> >>includes a cross certificate. >> >> >> >>Russ >> > >> >Russ, >> > >> >I have to voice my agreement with Mike that cross-certification >> >is not manageable (technical banking term - "scary".)) >> > >> >An example, the trusted relationships between UNIX nodes. One can >> >make the point that the Rhost kind of trust is similar to the >> >cross-certification model. Rhost type of trust has done nothing >> >but get lots of people into lots and lots of trouble. >> > >> >Cross certification may look OK to field commanders in military >> >applications. Ya know -"Well that's Sam's group - he and I >> >played hockey together - Let's trust those guys." >> > >> >Some people think banks trust each other through their Am Bnks Ass >> >number (like on the checks). Anyone who has gotten a bounced check >> >knows this is not the case. Knowing the "naming" and "addressing" >> >(name constraints!) does not increase the level of trust. >> > >> >Keeping naming constraints current - or even manageable - is the >> >full time task for lots of people in the mainframe world. >> >Keeping that trust (usually in one place - like RACF or ACF2) >> >is a full time job that often goes horribly wrong. >> > >> > >> >So, for financial transactions, we are left with on-line status >> >verification. Is there any bank out there that wants to cross >> >certify? With whom? >> > >> >- - - - - - - - - - - - - >> >Mack Hicks (415) 278-7230 -- Interactive Banking Division >> >425 1st St m/s3671, SF CA 94105 >> > > > --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From ???@??? Mon Jan 05 11:35:35 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id HAA23300 for ; Mon, 5 Jan 1998 07:10:07 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 5 Jan 1998 08:12:50 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id HAA16657; Mon, 5 Jan 1998 07:08:08 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 11616 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 5 Jan 1998 07:08:20 -0800 Received: from openroute.com (marconi.proteon.com [128.185.123.116] (may be forged)) by Tandem.com (8.8.8/2.0.1) with SMTP id GAA10993 for ; Mon, 5 Jan 1998 06:58:19 -0800 (PST) Received: from banacek.proteon.com by openroute.com (SMI-8.6/SMI-SVR4) id JAA04261; Mon, 5 Jan 1998 09:58:05 -0500 Received: by banacek.proteon.com (4.1/SMI-4.1) id AA26352; Mon, 5 Jan 98 09:58:13 EST X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <9801051458.AA26352@banacek.proteon.com> Date: Mon, 5 Jan 1998 09:58:13 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Gina DePlanche Subject: [IETF-PKIX] X509 newcomer To: IETF-PKIX@LISTS.TANDEM.COM Status: Hi! I work for a router company and I am researching using X509 certificates in our box. I am just starting to learn about X.509 certificates. I have read the draft draft-ietf-pkix-ipki-part1-06.txt. I have the ITU-T recommendation for X509 and Amendment 4. I have a couple of questions I was hoping someone on this list could answer. 1. The draft states it is part of a multipart standard. What/where are the other parts? Are there any other specifications for using certificates? 2. Are there any white papers/drafts/specs/books out there that I can read which would give me an understanding of the operational procedures for using X509 certificates? 3. Any other information a beginner should know? Thank you very much for any information you can provide. - Gina -- Gina M. DePlanche | OpenROUTE Networks, Inc. gmd@openroute.com | A subsidiary of Proteon, Inc. (508) 898-2800 x2541 | 9 Technology Drive, Westborough, MA Fax: (508) 836-5347 | 01581-1799 MailStop #23 From ???@??? Mon Jan 05 12:28:13 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA30855 for ; Mon, 5 Jan 1998 12:09:57 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 5 Jan 1998 13:12:42 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA12059; Mon, 5 Jan 1998 12:07:22 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 11825 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 5 Jan 1998 12:07:18 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id MAA08641 for ; Mon, 5 Jan 1998 12:07:17 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Mon, 05 Jan 1998 12:14:41 -0700 X-Mailer: Novell GroupWise 4.1 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Message-ID: Date: Mon, 5 Jan 1998 09:55:13 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] PKIX Part 1: more clarity needed on AltNames Comments: To: paulh@IMC.ORG To: IETF-PKIX@LISTS.TANDEM.COM Status: Paul, I think that the only reasonable vieww would be to assume that the CA is binding the public key to the gestalt, i.e., the totality, of all of the attributes contained in the certificate, including the DN and any alt names. If we start trying to pick apart different meanings for this, that and the other attrbute when used in combination with other attributes, the combinatoric explosion of semantic possibilities will quickly become impossible to deal with. So I believe that the CA is certifying each name individually, AND as a group. Remember, it is perfectly possible, meaningful, and correct, for the CA to issue multiple certificates to the same DN, and/or the same alt name, for various purposes. What the legal implications of a digital signature issued by "groupmailbox@foo.com" might be would be a different issue. Bob > >>My guess would be that >>the CA is vouching for the binding between each name in a certificate >>and the remaining contents of the certificate. > >Each name individually, or as a group? "The rest of this cert applies to >either the DN xxx,yyy or the email address foo@bar.com" or "The rest of >this cert applies to DN xxx,yyy, but only when also thought of as >foo@bar.com"? > >>It's probably a >>distinction without a difference to ask whether the CA is vouching for >>a binding between name A and name B - if both are bound to the same >>public key, (in the same cert or in separate otherwise identical certs) >>then they are implicitly equally valid, and it doesn't make much sense >>to ask which name is "definitive". > >To me, this means "each name individually". I'm fine with this answer (and >with the other), but neither is clearly stated in the doc. > >I can see a reason why "as a group" could be a logical choice. You might >issue one cert for the combination of a DN of "o=FooCo, cn=Chris Smith" and >a subjectAltName of "groupmailbox@foo.com", and a different cert for DN of >"o=FooCo, cn=Kim Tong" and a subjectAltName of "groupmailbox@foo.com". Or, >the DNs might be the same (with an ou and no cn) but with different >subjectAltNames. > >--Paul Hoffman, Director >--Internet Mail Consortium From ???@??? Mon Jan 05 14:34:44 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA32105 for ; Mon, 5 Jan 1998 12:57:40 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 5 Jan 1998 14:00:24 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA16054; Mon, 5 Jan 1998 12:55:12 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 11913 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 5 Jan 1998 12:55:03 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id MAA16493 for ; Mon, 5 Jan 1998 12:55:01 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Mon, 05 Jan 1998 13:52:47 -0700 X-Mailer: Novell GroupWise 4.1 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Message-ID: Date: Mon, 5 Jan 1998 13:52:05 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] NO SUBJECT Comments: To: wford@VERISIGN.COM To: IETF-PKIX@LISTS.TANDEM.COM Status: Warwick, I certainly agree with the need to clarify the terminology. To my way of thinking, one of the most important distinctions between an interdomain cross-certificate and an "ordinary" certificate lies in the potential one-to-many relationship of the subject to the issuer that significantly complicates the certificate retrieval mechanism, by requiring both bottom-up and top-down processing. Since I may not have a correct understanding of the model, let me at least describe what I am envisioning: A stand-alone, hierarchical domain exists that consists of a top-level CA, one or more subordinate CAs whose certificates are either signed by the top-level CA or by a higher-level subordinate CA, and a multiplicity of end-user's whose certificates are signed by a subordinate CA. Although not absolutely necessary, I am envisioning that the public key of the top-level CA will be incorporated in a self-signed certificate for compatibility of distribution as well as to allow the inclusion of various attributes (e.g., expiration dates, DNs, etc.) in a standard form. Given an end-user's certificate, it is possible to at least identify the name of the issuing CA by looking at the issuerName field of the end-user's certificate. Hopefully the location of that certificate can also be derived, at least indirectly if not directly. By applying this mechanism recursively, it is possible to climb the chain of certificates up to the top-level CA, whose self-signed certificate serves as a 'stopper" to stop the search. If the top-level CA's public key is included in the cache of trusted keys for that application, then the chain is validated, if not, punt. Within the hierarchy, certificates have a one to many relationship between the issuer and multiple subjects. But cross-domain certificates introduce the possibility that a given subject's public key may be signed by multiple issuers, i.e., though the creation of a multiplicity of certificates which include the public key of that top-level CA within that domain. Since an X.509 certificate cannot contain multiple issuers, and even if it could there would be no effective way to coordinate the issuance of such a multiple issuer certificate, the tree-climbing algorithm for certificate retrieval effectively breaks at this point. Instead, the introduction of a cross-domain certificate provides an alternative means of distributing trusted root keys to relying parties within a particular community of interest -- one that is more flexible and extensible than merely including the root keys in code, for example. In effect, this provides a mechanism for implementing Dwight Arthur's view of the world -- a community of relying parties, perhaps influenced or dictated by an organization's IT department, distributes a single trusted root key for that particular community through an out-of-band mechanism. That particular domain makes up a hierarchy, although in the case of a single user who operates his own CA, the hierarchy has a depth of one level. Those end users whose chain of certificates can be verified by checking the chain up to the top-level trusted CA (modulo whatever policy OID and other path validation mechanisms may be imposed) can assumed to be trusted by anyone whose has chosen or implemented that top-level CA as their trusted root. End users who may be issued certificates under the aegis of another top-level CA, but one that is trusted by the relying party (or more likely, by the relying party's IT department as a function of organization policy, including contractual or other agreements) can be automatically accepted if some CA in the relying party's hierarchy (usually, but not necessarily, the top level CA in the domain) cross-certifies the other domain though the issuance of a certificate which includes the public key of the foreign domain's top-level CA. >From a certificate processing standpoint, the ultimate end-user's certificate is still processed from the bottom up, all the way to the self-signed certificate that represents the top-level CA in the foreign domain. But as a result of the cross-domain certification, and perhaps as a result of preprocessing all of the cross-domain certificates issued by the relying party's own top-level CA, the foreign CA's public key can now be considered trusted, just as though it had been conveyed directly via a secure out-of-band mechanism. In addition, all of the existing policy OID and other constraint mechanisms can be imposed to control the extent to which transitive trust extends to subordinate CAs and their end-users. That's at least what I mean by cross-certification. I'm not quite sure whether that is what other people have implied by the term. In particular, my use of the term cross-certification does NOT mean the simple certification of subordinate CA by a higher-level CA in a simple hierarchy. Bob Robert R. Jueneman Security Architect Novell, Inc. Network Services Division 122 East 1700 South Provo, UT 84604 801/861-7387 bjueneman@novell.com "If you are trying to get to the moon, climbing a tree, although a step in the right direction, will not prove to be very helpful." "The most dangerous strategy is to cross the chasm in two leaps." >>> Warwick Ford 01/05 6:09 AM >>> Dwight: In my score-keeping on the terminology issue, I have thus far seen support for at least two totally different interpretations of the term "cross-certification", then several different shades of meaning beyond that. I would contend that "cross-certification" is NOT a well-defined term and suggest we move to (and clearly define) more precise terms such as "CA-certification" and "inter-domain certification". I was giving the list another few days after the break to make sure that all inputs are in, before making a concrete proposal. Regards, Warwick At 04:47 PM 1/4/98 -0500, Dwight Arthur wrote: >On trust and cross certification: > >I believe that there is a persistent misperception among technologists >in this field that an RP will trust someone because of the >certificate(s) that person can produce. On the contrary I would suggest >that in many cases the RP represents an enterprise that causes a >certificate to be granted because of a pre-existing relationship of >trust. In other words, trust leads to certificates, certificates do not >lead to trust. > >If my enterprise operates a system which we have agreed to make >accessible to you, it is because we already have some reason to trust >you, such as a contractual relationship with your employer, or >collateral that you have deposited with us, or maybe a line of credit >that you have identified and we have verified. > >The certificate plays an important role: it allows my system to validate >your identity at the time that you access it, and allows you to create >"digital signatures" as lasting verifiable indications that you commit >yourself and/or your enterprise to various transactions. In order to >achieve these benefits without the overhead and expense of personally >issuing certificates to everyone I trust, I will rely in some cases on >CAs operated by others to issue the certificates. To be able to validate >these certificates, I may require some relationship with the external CA >that may require cross-certification (although there may be other >simpler ways such as bilateral exchange of keys). > >BUT IN NO CASE does the fact that I cross certify an external CA make me >willing to trust any and all certs issued by that CA. All it does is >that when I receive a signature from someone I am inclined to trust, it >provides me with a path for validation of the signture, a method to >determine that the private key is apparently free of compromise to this >point, and perhaps a pointer into a directory from which other relevant >data might be retrieved. > >What will, however, be quite useful in the future will be a certificate >granted by my trade association, or by the CPA firm that audits the >organization that operates the CA, or maybe some other body stating that >the CA's CPS meets my trade association's requirements for accreditation >at some level and that the CPA's scheduled and unscheduled audits >demonstrate an acceptable degree of operational compliance with the >policies specified in the CPS. If I find this certificate revoked I will >definitely consider withholding trust from holders of certificates >issued by the disaccredited (discredited ?) CA. Despite the fact that I >have good reason (other than the cert) to trust the subject party, the >discreditation (?) may signal that the cert is no longer a reliable >indicator that the person holding it is in fact the person I trust. > >Question: it the CPA-to-CA certificate a cross-certificate under the >recently circulated definitions of terms? I do not recall any mention of >accreditation. > >-Dwight Arthur > > > >On 12/19/97, Russ Housley wrote: >> Mack: >> >> I understand your issues, and in the banking community, there may be very >> limited corss certification. >> >> I was simply trying to point out that the issuance of a cross certificate >> from CA_a to CA_b need not cause every certificate issued by CA_b become >> valid to the community that consider CA_a to be a trusted root. If there >> is an easily identified subset of CA_b's community and CA_a trusts CA_b >> correctly validate the membership in that subset, then cross certification >> is an appropriate mechanism. Trust is the center of this issue. You >> correctly point out that bankers like to minimize the number of people (and >> orgianizations) that they need to trust. It greatly simplifies the risk >> analysis and risk management. >> >> Russ >> >> At 01:43 PM 12/17/97 -0800, Mack Hicks wrote: >> >For: IETF-PKIX Mailing list >> > >> >From: "Russ Housley" >> > >> >> Mike: >> >> >> >>This is not necessarily so. The use of extensions can limit the scope of >> >>the "tree" that becomes valid as a result of cross-certification. For >> >>example, name constraints could result in a small subset of the >> >>certificates issued by a CA being considered valid in the context path that >> >>includes a cross certificate. >> >> >> >>Russ >> > >> >Russ, >> > >> >I have to voice my agreement with Mike that cross-certification >> >is not manageable (technical banking term - "scary".)) >> > >> >An example, the trusted relationships between UNIX nodes. One can >> >make the point that the Rhost kind of trust is similar to the >> >cross-certification model. Rhost type of trust has done nothing >> >but get lots of people into lots and lots of trouble. >> > >> >Cross certification may look OK to field commanders in military >> >applications. Ya know -"Well that's Sam's group - he and I >> >played hockey together - Let's trust those guys." >> > >> >Some people think banks trust each other through their Am Bnks Ass >> >number (like on the checks). Anyone who has gotten a bounced check >> >knows this is not the case. Knowing the "naming" and "addressing" >> >(name constraints!) does not increase the level of trust. >> > >> >Keeping naming constraints current - or even manageable - is the >> >full time task for lots of people in the mainframe world. >> >Keeping that trust (usually in one place - like RACF or ACF2) >> >is a full time job that often goes horribly wrong. >> > >> > >> >So, for financial transactions, we are left with on-line status >> >verification. Is there any bank out there that wants to cross >> >certify? With whom? >> > >> >- - - - - - - - - - - - - >> >Mack Hicks (415) 278-7230 -- Interactive Banking Division >> >425 1st St m/s3671, SF CA 94105 >> > > > --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From ???@??? Mon Jan 05 16:59:49 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id QAA05485 for ; Mon, 5 Jan 1998 16:57:24 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 5 Jan 1998 17:59:57 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id QAA05575; Mon, 5 Jan 1998 16:53:42 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 12094 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 5 Jan 1998 16:53:45 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id QAA29031 for ; Mon, 5 Jan 1998 16:53:43 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id QAA17509; Mon, 5 Jan 1998 16:53:11 -0800 (PST) Received: from wford-pc by mentat.verisign.com (8.8.5/BCH1.0) id QAA07772; Mon, 5 Jan 1998 16:53:07 -0800 (PST) X-Sender: wford@mail.verisign.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.32.19980105194339.009f8680@mail.verisign.com> Date: Mon, 5 Jan 1998 19:43:42 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Warwick Ford Subject: Re: [IETF-PKIX] NO SUBJECT Comments: To: Bob Jueneman To: IETF-PKIX@LISTS.TANDEM.COM Status: Bob: This is another interesting (and unquestionably useful) view on the meaning of "cross-certification". It is different to what I had been referring to as "inter-domain certification" because, to my mind, inter-domain certification might end up with a hierarchical structure or might not. It is now clear that there are at least 3 quite different problems being addressed, all of them being declared as the "cross-certification" problem, but that there is no "cross-certification" panacea. I therefore suggest we retire the term "cross-certification" for the moment and focus on the various problems and the characteristics of their solutions. I believe the "problems" identified thus far are: (a) The mechanical problem of having one CA issue a cert for another CA (regardless of domain, PKI structure, etc.). This is the problem solved by the CMP CrossCert transaction or similar enrollment protocols. As pointed out by Denis Pinkas, this is probably best called "CA-certification" for consistency with the X.509 term "CA-certificate". (b) The problem of establishing a link between two domains (typically two organizations) whereby a CA in one domain issues a certificate for the cert-signing key of a CA in another domain. This raises the issues of assessment of trustworthiness, establishment of binding agreements, liability apportionment, X.509 protection mechanisms such as name constraints and policy-mapping, transitivity (on to further domains), etc. (I have been using the term "inter-domain certification" for this.) (c) The problem of finding a cert chain given that, in the general case, the overall structure of CAs comprises hierarchies, with inter-hierarchy links. This raises the issues of availability of information from directories, and the capabilities of certificate-using products to perform the necessary searching and traversal. I do not believe the (b) and (c) problem domains generally lead to a common solution, nor that there is a particularly strong need to seek such a common solution. For example, when a CA in domain A issues a certificate for a CA in domain B, the result could still be a hierarchy (if A is certifying the TLCA of B, and A is the only domain that does so), in which case the advantages of hierarchical cert-finding are still apparent. Conversely, within one domain, one might have a basic hierarchical structure but allow (for chain-shortening, performance purposes) certification links across the hierarchy (both the Fed Govt and Canadian Govt architectures have recognized the potential need for this). Warwick At 01:52 PM 1/5/98 -0700, Bob Jueneman wrote: >Warwick, > >I certainly agree with the need to clarify the terminology. > > >To my way of thinking, one of the most important distinctions between an >interdomain cross-certificate and an "ordinary" certificate lies in the >potential one-to-many relationship of the subject to the issuer that >significantly complicates the certificate retrieval mechanism, by requiring >both bottom-up and top-down processing. > >Since I may not have a correct understanding of the model, let me at least >describe what I am envisioning: > >A stand-alone, hierarchical domain exists that consists of a top-level CA, >one or more subordinate CAs whose certificates are either signed by the >top-level CA or by a higher-level subordinate CA, and a multiplicity of >end-user's whose certificates are signed by a subordinate CA. > >Although not absolutely necessary, I am envisioning that the public key of >the top-level CA will be incorporated in a self-signed certificate for >compatibility of distribution as well as to allow the inclusion of various >attributes (e.g., expiration dates, DNs, etc.) in a standard form. > >Given an end-user's certificate, it is possible to at least identify the >name of the issuing CA by looking at the issuerName field of the end-user's >certificate. Hopefully the location of that certificate can also be derived, >at least indirectly if not directly. By applying this mechanism >recursively, it is possible to climb the chain of certificates up to the >top-level CA, whose self-signed certificate serves as a 'stopper" to stop >the search. If the top-level CA's public key is included in the cache of >trusted keys for that application, then the chain is validated, if not, >punt. > >Within the hierarchy, certificates have a one to many relationship between >the issuer and multiple subjects. But cross-domain certificates introduce >the possibility that a given subject's public key may be signed by multiple >issuers, i.e., though the creation of a multiplicity of certificates which >include the public key of that top-level CA within that domain. > >Since an X.509 certificate cannot contain multiple issuers, and even if it >could there would be no effective way to coordinate the issuance of such a >multiple issuer certificate, the tree-climbing algorithm for certificate >retrieval effectively breaks at this point. > >Instead, the introduction of a cross-domain certificate provides an >alternative means of distributing trusted root keys to relying parties >within a particular community of interest -- one that is more flexible and >extensible than merely including the root keys in code, for example. > >In effect, this provides a mechanism for implementing Dwight Arthur's view >of the world -- a community of relying parties, perhaps influenced or >dictated by an organization's IT department, distributes a single trusted >root key for that particular community through an out-of-band mechanism. >That particular domain makes up a hierarchy, although in the case of a >single user who operates his own CA, the hierarchy has a depth of one level. > >Those end users whose chain of certificates can be verified by checking the >chain up to the top-level trusted CA (modulo whatever policy OID and other >path validation mechanisms may be imposed) can assumed to be trusted by >anyone whose has chosen or implemented that top-level CA as their trusted >root. > >End users who may be issued certificates under the aegis of another >top-level CA, but one that is trusted by the relying party (or more likely, >by the relying party's IT department as a function of organization policy, >including contractual or other agreements) can be automatically accepted if >some CA in the relying party's hierarchy (usually, but not necessarily, the >top level CA in the domain) cross-certifies the other domain though the >issuance of a certificate which includes the public key of the foreign >domain's top-level CA. > >>From a certificate processing standpoint, the ultimate end-user's >certificate is still processed from the bottom up, all the way to the >self-signed certificate that represents the top-level CA in the foreign >domain. But as a result of the cross-domain certification, and perhaps as a >result of preprocessing all of the cross-domain certificates issued by the >relying party's own top-level CA, the foreign CA's public key can now be >considered trusted, just as though it had been conveyed directly via a >secure out-of-band mechanism. > >In addition, all of the existing policy OID and other constraint mechanisms >can be imposed to control the extent to which transitive trust extends to >subordinate CAs and their end-users. > >That's at least what I mean by cross-certification. I'm not quite sure >whether that is what other people have implied by the term. In particular, >my use of the term cross-certification does NOT mean the simple >certification of subordinate CA by a higher-level CA in a simple hierarchy. > >Bob --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From ???@??? Tue Jan 06 11:14:55 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id SAA07279 for ; Mon, 5 Jan 1998 18:08:07 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 5 Jan 1998 19:11:00 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id SAA10696; Mon, 5 Jan 1998 18:02:23 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 12282 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 5 Jan 1998 18:02:32 -0800 Received: from ntdev.signet.org.au (ntdev.signet.org.au [139.130.64.197]) by Tandem.com (8.8.8/2.0.1) with ESMTP id SAA10011 for ; Mon, 5 Jan 1998 18:02:27 -0800 (PST) Received: by NTDEV with Internet Mail Service (5.5.1960.3) id ; Tue, 6 Jan 1998 12:02:26 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Message-ID: <816AD21B9485D111A3DA00C06C5771711AB2@NTDEV> Date: Tue, 6 Jan 1998 12:02:22 +1000 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Charles Moore Subject: Re: [IETF-PKIX] NO SUBJECT To: IETF-PKIX@LISTS.TANDEM.COM Status: I am not sure why things have to be made more complicated than needed. A) First Separate out the technical issues from the policy issues. B) Address the technical issues here, leave the policy issues for the policy/business decisions. With the above, cross certification at least with the current standard is straight forward. All of the discussed uses of cross-certificates are ok, it all depends on the policy under which the cross-certificate is certified. So 1. Leave the technical definition as is 2. Let the certificate policy make statements about the rules and meanings of any cross-certificate. Let the policy have flexibility to support what people what to put labels on such as inter-domain certification or other terms. > -----Original Message----- > From: Warwick Ford [SMTP:wford@VERISIGN.COM] > Sent: Tuesday, January 06, 1998 10:44 AM > To: IETF-PKIX@LISTS.TANDEM.COM > Subject: Re: [IETF-PKIX] NO SUBJECT > > Bob: > > This is another interesting (and unquestionably useful) view on the > meaning > of "cross-certification". It is different to what I had been > referring to > as "inter-domain certification" because, to my mind, inter-domain > certification might end up with a hierarchical structure or might not. > > It is now clear that there are at least 3 quite different problems > being > addressed, all of them being declared as the "cross-certification" > problem, > but that there is no "cross-certification" panacea. I therefore > suggest we > retire the term "cross-certification" for the moment and focus on the > various problems and the characteristics of their solutions. [Charles Moore] One problem, but many policies, and there are more than these. > I believe the "problems" identified thus far are: > > (a) The mechanical problem of having one CA issue a cert for another > CA > (regardless of domain, PKI structure, etc.). This is the problem > solved by > the CMP CrossCert transaction or similar enrollment protocols. As > pointed > out by Denis Pinkas, this is probably best called "CA-certification" > for > consistency with the X.509 term "CA-certificate". [Charles Moore] It is just cross-certification, nothing more. Whether CMP crossCerts messages are useful for this or any other Xcert is a different issue. > (b) The problem of establishing a link between two domains (typically > two > organizations) whereby a CA in one domain issues a certificate for the > cert-signing key of a CA in another domain. This raises the issues of > assessment of trustworthiness, establishment of binding agreements, > liability apportionment, X.509 protection mechanisms such as name > constraints and policy-mapping, transitivity (on to further domains), > etc. > (I have been using the term "inter-domain certification" for this.) [Charles Moore] Its the same as above just that the policies on cross certification are different > (c) The problem of finding a cert chain given that, in the general > case, > the overall structure of CAs comprises hierarchies, with > inter-hierarchy > links. This raises the issues of availability of information from > directories, and the capabilities of certificate-using products to > perform > the necessary searching and traversal. [Charles Moore] I believe this is a orthogonal problem that applies to all cases. > I do not believe the (b) and (c) problem domains generally lead to a > common > solution, [Charles Moore] I am not sure I understand, they both can produce a solution, but in all cases there is a need to know the policies/rules > nor that there is a particularly strong need to seek such a > common solution. [Charles Moore] If this means common code/rules I agree in the specific and also the general case. > For example, when a CA in domain A issues a certificate > for a CA in domain B, the result could still be a hierarchy (if A is > certifying the TLCA of B, and A is the only domain that does so), in > which > case the advantages of hierarchical cert-finding are still apparent. > Conversely, within one domain, one might have a basic hierarchical > structure but allow (for chain-shortening, performance purposes) > certification links across the hierarchy (both the Fed Govt and > Canadian > Govt architectures have recognized the potential need for this). [Charles Moore] I am not sure I understand the specific relevance, the PKI will have many different structures, the technical services such as cross-certification must support ( and I believe it does) any structure. Some of the structures will have advantages over others in given situations. From ???@??? Tue Jan 06 11:15:24 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id FAA24975 for ; Tue, 6 Jan 1998 05:43:33 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 6 Jan 1998 06:46:31 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id FAA11524; Tue, 6 Jan 1998 05:40:08 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 12434 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 6 Jan 1998 05:39:47 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id FAA03218 for ; Tue, 6 Jan 1998 05:39:46 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id FAA22888; Tue, 6 Jan 1998 05:39:01 -0800 (PST) Received: from wford-pc by mentat.verisign.com (8.8.5/BCH1.0) id FAA22578; Tue, 6 Jan 1998 05:38:58 -0800 (PST) X-Sender: wford@mail.verisign.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.32.19980106082851.009f6150@mail.verisign.com> Date: Tue, 6 Jan 1998 08:28:53 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Warwick Ford Subject: Re: [IETF-PKIX] NO SUBJECT To: IETF-PKIX@LISTS.TANDEM.COM Status: Charles: At 12:02 PM 1/6/98 +1000, Charles Moore wrote: >So >1. Leave the technical definition as is Could you please clarify exactly what "technical definition" you are referring to? What document is it in? Do you mean bullet (g) in the PKIX Profile which says "cross-certification: Two CAs exchange the information necessary to establish cross-certificates between those CAs" ... kinda circular, maybe? Warwick --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From ???@??? Tue Jan 06 11:15:37 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA32442 for ; Tue, 6 Jan 1998 10:45:08 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 6 Jan 1998 10:47:24 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA28105; Tue, 6 Jan 1998 09:40:53 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 12540 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 6 Jan 1998 09:40:54 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id JAA03447 for ; Tue, 6 Jan 1998 09:40:53 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 06 Jan 1998 10:40:22 -0700 X-Mailer: Novell GroupWise 4.1 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Message-ID: Date: Tue, 6 Jan 1998 10:40:05 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: [IETF-PKIX] Cross-certification issues and terminology Comments: To: wford@VERISIGN.COM To: IETF-PKIX@LISTS.TANDEM.COM Status: Warwick, Separating the (cross-)certificate issuance issues from the certificate retrieval issues is probably useful, although both problems will have to be solved sooner or later. I also agree that there may be a requirement for a cross-certificate within a simple hierarchy (i.e., with a single domain), for performance or other reasons. And I haven't even begun to think through the CRL and other issues involved in cross-domain certification -- I hope that you have, and that it works. But first let me ask your opinion regarding the creation of a cross-domain certificate. I haven't read the CMP proposal in any detail, but I'm not sure that I understand why any protocol is particularly needed in this case. If I as a CA want to issue a certificate to a TLCA (or in fact to any CA), do I necessarily need that CA's permission to do so? I think not, although it might be polite to inform them of what I am doing. (In most cases, of course, this would only happen after a contractual agreement, so this is probably just a rhetorical point.) So why do I need a protocol? Can't I just pick up the self-signed certificate via a trusted out-of-band, i.e., manual, process (which I would need to do in any case), extract the public key, and include that key in my newly minted certificate? (Regardless of whether a public key is created by an end-user, or by a CA, or even by the issuing CA, some sort of trusted, out-of-band process is always required prior to the binding, to ensure that the subject is who they claim to be, and to provide proof of possession of the corresponding private key.) Is the supposition behind CMP that a TLCA in one domain would request that they be issued a certificate by a CA in another domain? That doesn't seem very likely or reasonable. So I think that I must misperceive the intent of CMP -- perhaps it is only intended to address how subordinate CAs request a certificate from a higher level (within the hierarchy) CA? On another point, you comment that inter-domain certification might end up with a [linked] hierarchical structure, or might not. I assume that you mean that a CA in one domain might unilaterally issue a certificate to a CA in another domain, not necessarily the TLCA in that domain. I can see that that might happen, and might actually be quite useful -- MISSI might certify a subordinate CA within its domain, let's say the Utah National Guard, and the State of Utah might also certify that CA under the provisions of the Utah Digital Signature Act. Rather than provoke a constitutional crisis over the primacy of federal vs. state powers, a first come, first served rule might be applied, and Utah would cross-certify the Utah National Guard CA directly, bypassing higher-level CAs in the MISSI hierarchy. (It might well be that Utah would either require a higher standard of performance for their licensed CAs than MISSI would necessarily provide, or that the State simply wouldn't have the resources to audit and otherwise ensure compliance with the Utah Act for other MISSI CAs. So although they might certify the Utah National Guard CA, they would not certify MISSI itself, nor the other CAs under the MISSI hierarchy.) Let me see if I understand how the certificate validation process works in this case. And I will conveniently ignore the issue of how the certificates are actually located, whether they are all in one ubiquitous directory, or have to be retrieved from various sites is a small detail, at least for now. So consider the case where a relying party has loaded the root key of the Utah TLCA, and wants to only deal with CAs that are licensed under the Utah Act. A purchase order is received, signed by the Supply Officer of Bravo Company, First Chemical Weapons Battalion, Utah National Guard, whose certificate is issued by the UNG CA directly (for the sake of argument). If the relying party's software just climbs the certificate tree blindly, it would tend to look for the next level certificate, which let's say is issued by the US Army CA to the Utah National Guard. But climbing that particular tree isn't going to be useful, because Utah hasn't certified the MISSI TLCA. So somehow the relying party's software has to know that it should preload and verify the Utah certificate which certifies the Utah National Guard CA's certificate. Then, when the RP's software encounters the UNG's certificate, it can exclaim "Eureka! I already have verified this public key, and so everything is hunky-dory." That's OK in concept, but God is in the niggling details: 1. How does the RP software know that that particular cross-certificate is going to be needed? Does it have to preload and verify every certificate issued by Utah? That might not be too bad in the case of Utah, but what if it were New York or Illinois? The software might have to maintain thousands of keys in its stack. 2. It isn't sufficient to just (pre-)validate the public key of the Utah National Guard -- presumably the RP software has to keep track of all of the policy OID and other constraints that might be applied, from the Utah TLCA on down, and then check that the end-user certificate issued by the UNG satisfies those criteria. I am increasingly beginning to believe that it will be necessary to store prevalidated certificates in a locally-trusted working directory. Whether the most efficient implementation of the search argument for finding a certificate in the directory should be the DN of the subject, or perhaps a hash of the public key, remains to be determined. How this should impact OCSP, and/or how nonrepudiation should best be provided in this environment also requires further study, I believe. Bob >Bob: > >This is another interesting (and unquestionably useful) view on the meaning >of "cross-certification". It is different to what I had been referring to >as "inter-domain certification" because, to my mind, inter-domain >certification might end up with a hierarchical structure or might not. > >It is now clear that there are at least 3 quite different problems being >addressed, all of them being declared as the "cross-certification" problem, >but that there is no "cross-certification" panacea. I therefore suggest we >retire the term "cross-certification" for the moment and focus on the >various problems and the characteristics of their solutions. > >I believe the "problems" identified thus far are: > >(a) The mechanical problem of having one CA issue a cert for another CA >(regardless of domain, PKI structure, etc.). This is the problem solved by >the CMP CrossCert transaction or similar enrollment protocols. As pointed >out by Denis Pinkas, this is probably best called "CA-certification" for >consistency with the X.509 term "CA-certificate". > >(b) The problem of establishing a link between two domains (typically two >organizations) whereby a CA in one domain issues a certificate for the >cert-signing key of a CA in another domain. This raises the issues of >assessment of trustworthiness, establishment of binding agreements, >liability apportionment, X.509 protection mechanisms such as name >constraints and policy-mapping, transitivity (on to further domains), etc. >(I have been using the term "inter-domain certification" for this.) > >(c) The problem of finding a cert chain given that, in the general case, >the overall structure of CAs comprises hierarchies, with inter-hierarchy >links. This raises the issues of availability of information from >directories, and the capabilities of certificate-using products to perform >the necessary searching and traversal. > >I do not believe the (b) and (c) problem domains generally lead to a common >solution, nor that there is a particularly strong need to seek such a >common solution. For example, when a CA in domain A issues a certificate >for a CA in domain B, the result could still be a hierarchy (if A is >certifying the TLCA of B, and A is the only domain that does so), in which >case the advantages of hierarchical cert-finding are still apparent. >Conversely, within one domain, one might have a basic hierarchical >structure but allow (for chain-shortening, performance purposes) >certification links across the hierarchy (both the Fed Govt and Canadian >Govt architectures have recognized the potential need for this). > >Warwick Robert R. Jueneman Security Architect Novell, Inc. Network Services Division 122 East 1700 South Provo, UT 84604 801/861-7387 bjueneman@novell.com "If you are trying to get to the moon, climbing a tree, although a step in the right direction, will not prove to be very helpful." "The most dangerous strategy is to cross a chasm in two leaps." From ???@??? Tue Jan 06 11:15:39 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA32713 for ; Tue, 6 Jan 1998 10:57:13 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 6 Jan 1998 10:59:40 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA29376; Tue, 6 Jan 1998 09:53:49 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 12574 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 6 Jan 1998 09:53:56 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id JAA05724 for ; Tue, 6 Jan 1998 09:53:55 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id JAA26993; Tue, 6 Jan 1998 09:52:58 -0800 (PST) Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA01762; Tue, 6 Jan 1998 09:52:54 -0800 (PST) X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 References: <3.0.32.19980106082851.009f6150@mail.verisign.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms84D075A92C99EBFE39EC9336" Message-ID: <34B27241.B46C56A0@verisign.com> Date: Tue, 6 Jan 1998 13:04:49 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Phillip Hallam-Baker Organization: VeriSign Inc. Subject: [IETF-PKIX] Patent on use of CRLs etc To: IETF-PKIX@LISTS.TANDEM.COM Status: Do we need to include a reference to US Patent 5699431 in the PKIX drafts? It appears it might cover much of the PKIX CRL infrastructure including partitioned CRLs. Is this likely to cause difficulty with the IESG? Phill Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Attachment converted: Lutefisk:smime.p7s 20 (????/----) (0001DE20) From ???@??? Tue Jan 06 11:15:39 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA32461 for ; Tue, 6 Jan 1998 10:48:48 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 6 Jan 1998 11:51:44 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA04434; Tue, 6 Jan 1998 10:46:06 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 12706 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 6 Jan 1998 10:46:07 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id KAA15866 for ; Tue, 6 Jan 1998 10:46:05 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 06 Jan 1998 11:44:41 -0700 X-Mailer: Novell GroupWise 4.1 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Message-ID: Date: Tue, 6 Jan 1998 11:44:15 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] Patent on use of CRLs etc Comments: To: pbaker@VERISIGN.COM To: IETF-PKIX@LISTS.TANDEM.COM Status: I couldn't read your attachment. Could you provide a short summary of the patent? Who was it issued to? Bob Robert R. Jueneman Security Architect Novell, Inc. Network Services Division 122 East 1700 South Provo, UT 84604 801/861-7387 bjueneman@novell.com "If you are trying to get to the moon, climbing a tree, although a step in the right direction, will not prove to be very helpful." "The most dangerous strategy is to cross a chasm in two leaps." >>> Phillip Hallam-Baker 01/06 11:04 AM >>> Do we need to include a reference to US Patent 5699431 in the PKIX drafts? It appears it might cover much of the PKIX CRL infrastructure including partitioned CRLs. Is this likely to cause difficulty with the IESG? Phill From ???@??? Tue Jan 06 11:46:05 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id LAA00988 for ; Tue, 6 Jan 1998 11:30:39 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 6 Jan 1998 12:33:34 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id LAA08249; Tue, 6 Jan 1998 11:28:29 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 12786 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 6 Jan 1998 11:28:31 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id LAA23134 for ; Tue, 6 Jan 1998 11:28:29 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id LAA28901; Tue, 6 Jan 1998 11:27:57 -0800 (PST) Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA06855; Tue, 6 Jan 1998 11:27:52 -0800 (PST) X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 References: <3.0.32.19980106082851.009f6150@mail.verisign.com> <34B27241.B46C56A0@verisign.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAD987FE0D2E77A695420AB7C" Message-ID: <34B28884.BA7DC827@verisign.com> Date: Tue, 6 Jan 1998 14:39:48 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Phillip Hallam-Baker Organization: VeriSign Inc. Subject: Re: [IETF-PKIX] Patent on use of CRLs etc To: IETF-PKIX@LISTS.TANDEM.COM Status: Also note patent 5687235. Phill PS The patent I applied for covering motherhood, apple pie and the American way was rejected as 'having no conceivable application' Phillip Hallam-Baker wrote: > > Do we need to include a reference to US Patent 5699431 in the > PKIX drafts? > > It appears it might cover much of the PKIX CRL infrastructure > including partitioned CRLs. > > Is this likely to cause difficulty with the IESG? > > Phill Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Attachment converted: Lutefisk:smime.p7s 21 (????/----) (0001DE22) From ???@??? Tue Jan 06 11:46:06 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id LAA01024 for ; Tue, 6 Jan 1998 11:37:24 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 6 Jan 1998 12:40:21 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id LAA08971; Tue, 6 Jan 1998 11:35:40 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 12822 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 6 Jan 1998 11:35:42 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id LAA24484 for ; Tue, 6 Jan 1998 11:35:41 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id LAA29048; Tue, 6 Jan 1998 11:35:08 -0800 (PST) Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA07195; Tue, 6 Jan 1998 11:35:04 -0800 (PST) X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3C9ABE28DDC40939FC51F175" Message-ID: <34B28A36.7359141A@verisign.com> Date: Tue, 6 Jan 1998 14:47:02 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Phillip Hallam-Baker Organization: VeriSign Inc. Subject: Re: [IETF-PKIX] Patent on use of CRLs etc To: IETF-PKIX@LISTS.TANDEM.COM Status: Bob Jueneman wrote: > > I couldn't read your attachment. Could you provide a short summary of the > patent? Who was it issued to? The Nortel and Novell Patents are both on the IBM patent server: http://patent.womplex.ibm.com/details?patent_number=5699431 http://patent.womplex.ibm.com/details?patent_number=5687235 Phill Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Attachment converted: Lutefisk:smime.p7s 22 (????/----) (0001DE23) From ???@??? Tue Jan 06 12:49:37 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA02266 for ; Tue, 6 Jan 1998 12:21:41 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 6 Jan 1998 13:24:37 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA13049; Tue, 6 Jan 1998 12:19:19 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 12936 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 6 Jan 1998 12:19:20 -0800 Received: from ntdev.signet.org.au (ntdev.signet.org.au [139.130.64.197]) by Tandem.com (8.8.8/2.0.1) with ESMTP id MAA00558 for ; Tue, 6 Jan 1998 12:09:12 -0800 (PST) Received: from DEVELOP ([203.37.128.25]) by ntdev.signet.org.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id CM2X2MSQ; Wed, 7 Jan 1998 06:09:21 +1000 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0012_01BD1B32.BE75FC40"; micalg=SHA-1 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 Message-ID: <001e01bd1ade$f0326ba0$198025cb@develop.signet.org.au> Date: Wed, 7 Jan 1998 06:08:59 +1000 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Charles Moore Subject: Re: [IETF-PKIX] NO SUBJECT To: IETF-PKIX@LISTS.TANDEM.COM Status: -----Original Message----- From: Warwick Ford To: IETF-PKIX@LISTS.TANDEM.COM Date: Wednesday, 7 January 1998 0:12 Subject: Re: [IETF-PKIX] NO SUBJECT :Charles: : :At 12:02 PM 1/6/98 +1000, Charles Moore wrote: :>So :>1. Leave the technical definition as is : :Could you please clarify exactly what "technical definition" you are :referring to? What document is it in? : :Do you mean bullet (g) in the PKIX Profile which says "cross-certification: :Two CAs exchange the information necessary to establish cross-certificates :between those CAs" ... kinda circular, maybe? The X.509 standard, has more than sufficient definition to meet our technical objective, in both syntax, normative and non-normative text. How this mechanism can be used, does not need to be, and should not be in PKIX, standardised as it is dependent on certificate policy. : :Warwick : :--------------------------------------------------------------------- :Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 : wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 :--------------------------------------------------------------------- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Attachment converted: Lutefisk:smime.p7s 23 (????/----) (0001DE33) From ???@??? Tue Jan 06 14:57:38 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id OAA05309 for ; Tue, 6 Jan 1998 14:27:56 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 6 Jan 1998 15:30:53 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id OAA23563; Tue, 6 Jan 1998 14:25:44 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 13102 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 6 Jan 1998 14:25:46 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id OAA23910 for ; Tue, 6 Jan 1998 14:25:43 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id OAA02406; Tue, 6 Jan 1998 14:25:11 -0800 (PST) Received: from wford-pc by mentat.verisign.com (8.8.5/BCH1.0) id OAA16017; Tue, 6 Jan 1998 14:25:07 -0800 (PST) X-Sender: wford@mail.verisign.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.32.19980106164239.009829d0@mail.verisign.com> Date: Tue, 6 Jan 1998 17:15:09 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Warwick Ford Subject: Re: [IETF-PKIX] Cross-certification issues and terminology To: IETF-PKIX@LISTS.TANDEM.COM Status: Bob: At 10:40 AM 1/6/98 -0700, Bob Jueneman wrote: >But first let me ask your opinion regarding the creation of a cross-domain >certificate. I haven't read the CMP proposal in any detail, but I'm not >sure that I understand why any protocol is particularly needed in this case. > >If I as a CA want to issue a certificate to a TLCA (or in fact to any CA), >do I necessarily need that CA's permission to do so? I think not, although >it might be polite to inform them of what I am doing. (In most cases, of >course, this would only happen after a contractual agreement, so this is >probably just a rhetorical point.) So why do I need a protocol? Can't I >just pick up the self-signed certificate via a trusted out-of-band, i.e., >manual, process (which I would need to do in any case), extract the public >key, and include that key in my newly minted certificate? (Regardless of >whether a public key is created by an end-user, or by a CA, or even by the >issuing CA, some sort of trusted, out-of-band process is always required >prior to the binding, to ensure that the subject is who they claim to be, >and to provide proof of possession of the corresponding private key.) Well, I don't think you want to go around issuing certificates for other CAs' public keys without their permission. Firstly, it is unwise since you would have no basis of assurances re future validity, revocation notification, etc. Secondly you could arguably be treading into intellectual property violation waters. Therefore, I think that we should be espousing that CA-certificates ALWAYS be issued only within a contractual agreement. As to the need for a protocol... Technically, all you need is an agreed format for representing a certificate-signing request ... the most obvious approach is to use exactly the same format (and surrounding protocol, if required) as when an end-entity enrolls with a CA. The Microsoft Certificate Server, for example, uses PKCS#10 for representing the information sent from a subject CA to issuing CA to have a CA-certificate issued. CMP is essentially the same -- the "CrossCert" transaction is just a minor variant of the end-entity certificate-signing request. >Is the supposition behind CMP that a TLCA in one domain would request that >they be issued a certificate by a CA in another domain? That doesn't seem >very likely or reasonable. So I think that I must misperceive the intent of >CMP -- perhaps it is only intended to address how subordinate CAs request a >certificate from a higher level (within the hierarchy) CA? I believe CMP provides nothing more than a protocol for one CA issuing a certificate to another CA, regardless, of domain or structure. This is why Denis and I prefer the term "CA-certification" for what CMP does. CMP does nothing to help solve the "hard problems" of cross-certification. >On another point, you comment that inter-domain certification might end up >with a [linked] hierarchical structure, or might not. > >I assume that you mean that a CA in one domain might unilaterally issue a >certificate to a CA in another domain, not necessarily the TLCA in that >domain. I can see that that might happen, and might actually be quite useful Yes, and your subsequent example is quite valid. Raises some good points .... Warwick --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From ???@??? Tue Jan 06 14:57:40 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id OAA05819 for ; Tue, 6 Jan 1998 14:47:35 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 6 Jan 1998 15:50:31 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id OAA25358; Tue, 6 Jan 1998 14:45:01 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 13164 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 6 Jan 1998 14:45:04 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id OAA27899 for ; Tue, 6 Jan 1998 14:44:57 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id OAA02807; Tue, 6 Jan 1998 14:44:26 -0800 (PST) Received: from wford-pc by mentat.verisign.com (8.8.5/BCH1.0) id OAA17140; Tue, 6 Jan 1998 14:44:22 -0800 (PST) X-Sender: wford@mail.verisign.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.32.19980106173423.0099c440@mail.verisign.com> Date: Tue, 6 Jan 1998 17:34:25 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Warwick Ford Subject: Re: [IETF-PKIX] NO SUBJECT To: IETF-PKIX@LISTS.TANDEM.COM Status: Charles: At 06:08 AM 1/7/98 +1000, Charles Moore wrote: >:Could you please clarify exactly what "technical definition" you are >:referring to? What document is it in? > >The X.509 standard, has more than sufficient definition to meet our >technical objective, in both syntax, normative and non-normative text. Unfortunately X.509 does not define "cross-certification" in an unambiguous or particularly helpful way. We would not be pursuing this thread if it did. Warwick --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From ???@??? Tue Jan 06 15:56:58 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id PAA06817 for ; Tue, 6 Jan 1998 15:21:11 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 6 Jan 1998 16:24:07 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id PAA28545; Tue, 6 Jan 1998 15:18:29 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 13262 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 6 Jan 1998 15:18:35 -0800 Received: from sentry.isrc.qut.edu.au (qmailr@sentry.isrc.qut.edu.au [131.181.97.10]) by Tandem.com (8.8.8/2.0.1) with SMTP id PAA02514 for ; Tue, 6 Jan 1998 15:08:29 -0800 (PST) Received: (qmail 11320 invoked from network); 6 Jan 1998 23:08:26 -0000 Received: from unknown (HELO isrc.qut.edu.au) (gaskell@131.181.6.10) by 131.181.6.1 with SMTP; 6 Jan 1998 23:08:26 -0000 Received: from localhost (gaskell@localhost) by isrc.qut.edu.au (8.8.6/8.8.6) with SMTP id JAA01077 for ; Wed, 7 Jan 1998 09:08:25 +1000 (EST) X-Authentication-Warning: primrose.isrc.qut.edu.au: gaskell owned process doing -bs X-Sender: gaskell@primrose.isrc.qut.edu.au MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 7 Jan 1998 09:08:24 +1000 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Gary Gaskell Subject: Re: [IETF-PKIX] Cross-certification issues and terminology To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: <3.0.32.19980106164239.009829d0@mail.verisign.com> Status: Gents, [Firstly, apologies if this does not contribute in a constructive way to your discussion, as I haven't read _all_ of the preceding discussions. Hopefully it will contribute ;-) ] 1. I don't think we can say, "X.509 says it all", as that is why you are all working PKIX in the first place. PKIX must take some lead if this is ever to be deployed; 2. Cross certification is very important and I anticipate that the use of cross certification will be a primary issue in the successful deployment of PKIX. Why: a. because governments will never get organised soon enough, for a hierarchy to work; b. Because an imposed heirarchy would be too rigid; c. An organisation wants to be in control of who their employees trust and deal with >From point c above, I think we can draw the main reason for the design and deployment of cross CA certs. If we mandate contracts are written and signed, we could be putting an onerous burden on an organisation in the set up of their IT infrastructure. IMO points a and b are what detract significantly from Australia PKAF work. The scenario that I'm thinking of goes like: Organisation Acme has an IT system where its employees can only interact with people in other organisations if Acme has cross signed the CA public keys of other organisations. This gives Acme more control and a way of enforcing their business policy. As they may change their preferred supplier daily, a contractual basis for cross signing may be too much. And I presume we could leave it to the organisation (e.g. Acme) to check a central (government or private) directory service for cert revocations, and then add them to their own CRL. IE. The norm for a cert path check may be: a. retrieve cert b. check its CA's signature c. check that my organisation has a cross cert for this other organisation d. check my organisation's CRL. If not if appears that my organisation has not approved business interactions with the other organisation. I think this could also be expanded to cross signing the public keys of a node in a hierarchy. If there was to be one true hierarchy, then the organisation can control which parts of it are trustworthy by the organisations people. I hope this in some way contributes to your debate. Cheers, Gary On Tue, 6 Jan 1998, Warwick Ford wrote: >Bob: > >At 10:40 AM 1/6/98 -0700, Bob Jueneman wrote: >>But first let me ask your opinion regarding the creation of a cross-domain >>certificate. I haven't read the CMP proposal in any detail, but I'm not >>sure that I understand why any protocol is particularly needed in this case. >> >>If I as a CA want to issue a certificate to a TLCA (or in fact to any CA), >>do I necessarily need that CA's permission to do so? I think not, although >>it might be polite to inform them of what I am doing. (In most cases, of >>course, this would only happen after a contractual agreement, so this is >>probably just a rhetorical point.) So why do I need a protocol? Can't I >>just pick up the self-signed certificate via a trusted out-of-band, i.e., >>manual, process (which I would need to do in any case), extract the public >>key, and include that key in my newly minted certificate? (Regardless of >>whether a public key is created by an end-user, or by a CA, or even by the >>issuing CA, some sort of trusted, out-of-band process is always required >>prior to the binding, to ensure that the subject is who they claim to be, >>and to provide proof of possession of the corresponding private key.) > >Well, I don't think you want to go around issuing certificates for other >CAs' public keys without their permission. Firstly, it is unwise since you >would have no basis of assurances re future validity, revocation >notification, etc. Secondly you could arguably be treading into >intellectual property violation waters. Therefore, I think that we should >be espousing that CA-certificates ALWAYS be issued only within a >contractual agreement. > >As to the need for a protocol... Technically, all you need is an agreed >format for representing a certificate-signing request ... the most obvious >approach is to use exactly the same format (and surrounding protocol, if >required) as when an end-entity enrolls with a CA. The Microsoft >Certificate Server, for example, uses PKCS#10 for representing the >information sent from a subject CA to issuing CA to have a CA-certificate >issued. CMP is essentially the same -- the "CrossCert" transaction is just >a minor variant of the end-entity certificate-signing request. > >>Is the supposition behind CMP that a TLCA in one domain would request that >>they be issued a certificate by a CA in another domain? That doesn't seem >>very likely or reasonable. So I think that I must misperceive the intent of >>CMP -- perhaps it is only intended to address how subordinate CAs request a >>certificate from a higher level (within the hierarchy) CA? > >I believe CMP provides nothing more than a protocol for one CA issuing a >certificate to another CA, regardless, of domain or structure. This is why >Denis and I prefer the term "CA-certification" for what CMP does. CMP does >nothing to help solve the "hard problems" of cross-certification. > >>On another point, you comment that inter-domain certification might end up >>with a [linked] hierarchical structure, or might not. >> >>I assume that you mean that a CA in one domain might unilaterally issue a >>certificate to a CA in another domain, not necessarily the TLCA in that >>domain. I can see that that might happen, and might actually be quite useful > >Yes, and your subsequent example is quite valid. Raises some good points .... > >Warwick > > > >--------------------------------------------------------------------- >Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 > wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 >--------------------------------------------------------------------- > Cheers, Gary ----------------------------------------------------------- Gary Gaskell Manager Secure Network Laboratory Phone (07) 3864 1190 Information Security Research Centre Fax (07) 3221 2384 Queensland University of Technology ----------------------------------------------------------- From ???@??? Tue Jan 06 15:57:00 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id PAA06841 for ; Tue, 6 Jan 1998 15:27:52 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 6 Jan 1998 16:30:48 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id PAA29241; Tue, 6 Jan 1998 15:26:15 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 13306 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 6 Jan 1998 15:26:21 -0800 Received: from ntdev.signet.org.au (ntdev.signet.org.au [139.130.64.197]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA05557 for ; Tue, 6 Jan 1998 15:26:16 -0800 (PST) Received: by NTDEV with Internet Mail Service (5.5.1960.3) id ; Wed, 7 Jan 1998 09:26:22 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Message-ID: <816AD21B9485D111A3DA00C06C5771711AB5@NTDEV> Date: Wed, 7 Jan 1998 09:26:18 +1000 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Charles Moore Subject: Re: [IETF-PKIX] NO SUBJECT To: IETF-PKIX@LISTS.TANDEM.COM Status: > -----Original Message----- > From: Warwick Ford [SMTP:wford@VERISIGN.COM] > Sent: Wednesday, January 07, 1998 8:34 AM > To: IETF-PKIX@LISTS.TANDEM.COM > Subject: Re: [IETF-PKIX] NO SUBJECT > > Charles: > > At 06:08 AM 1/7/98 +1000, Charles Moore wrote: > >:Could you please clarify exactly what "technical definition" you are > >:referring to? What document is it in? > > > >The X.509 standard, has more than sufficient definition to meet our > >technical objective, in both syntax, normative and non-normative > text. > > Unfortunately X.509 does not define "cross-certification" in an > unambiguous > or particularly helpful way. We would not be pursuing this thread if > it did. [Charles Moore] Ok, whats the problem. Are you sure we are separating definition ( specification) from issues relating to the use of the specification. Please explain the ambiguity from a specification perspective (not the use of the specification). All of the discussion I have followed to date has been on how one might use this specification to meet one-or-more policies, all good discussion, but not related to ambiguity of specification. Do you want to standardise on a specific use of cross-certificates ( ie a standard policy statement, one or more) and if so why? > Warwick > > --------------------------------------------------------------------- > Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 > wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 > --------------------------------------------------------------------- From ???@??? Tue Jan 06 16:23:53 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id QAA08076 for ; Tue, 6 Jan 1998 16:12:43 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 6 Jan 1998 17:15:34 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id QAA03542; Tue, 6 Jan 1998 16:09:34 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 13464 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 6 Jan 1998 16:09:35 -0800 Received: from ntdev.signet.org.au (ntdev.signet.org.au [139.130.64.197]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA12831 for ; Tue, 6 Jan 1998 15:59:29 -0800 (PST) Received: from DEVELOP ([203.37.128.25]) by ntdev.signet.org.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id CM2X2MTY; Wed, 7 Jan 1998 09:59:39 +1000 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_002B_01BD1B52.EA258E80"; protocol="application/x-pkcs7-signature"; micalg=SHA-1 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 Message-ID: <003201bd1aff$1b6c58b0$198025cb@develop.signet.org.au> Date: Wed, 7 Jan 1998 09:59:16 +1000 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Charles Moore Subject: Re: [IETF-PKIX] Cross-certification issues and terminology To: IETF-PKIX@LISTS.TANDEM.COM Status: -----Original Message----- From: Gary Gaskell To: IETF-PKIX@LISTS.TANDEM.COM Date: Wednesday, 7 January 1998 9:43 Subject: Re: [IETF-PKIX] Cross-certification issues and terminology :Gents, : :[Firstly, apologies if this does not contribute in a constructive way to :your discussion, as I haven't read _all_ of the preceding discussions. :Hopefully it will contribute ;-) ] : :1. I don't think we can say, "X.509 says it all", as that is why you are :all working PKIX in the first place. PKIX must take some lead if this is :ever to be deployed; : Snip :I hope this in some way contributes to your debate. It adds to the usage examples of Xcerts, but I still do not see problem with the defintion of a Xcert in X.509. I believe the discussion should be about what we are trying to standardise in PKIX, I dont belive we should be trying to standardise on a particular use of Xcerts ( as the the deployment experience of large scale PKI's is just too imature at this time). : :Cheers, : :Gary : :On Tue, 6 Jan 1998, Warwick Ford wrote: : Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Attachment converted: Lutefisk:smime.p7s 26 (????/----) (0001DE3F) From ???@??? Wed Jan 07 19:35:51 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id SAA15865 for ; Wed, 7 Jan 1998 18:46:44 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 7 Jan 1998 19:49:31 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id SAA13730; Wed, 7 Jan 1998 18:45:20 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 14077 for IETF-PKIX@LISTS.TANDEM.COM; Wed, 7 Jan 1998 18:45:20 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id SAA02669 for ; Wed, 7 Jan 1998 18:45:18 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Wed, 07 Jan 1998 17:55:58 -0700 X-Mailer: Novell GroupWise 4.1 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Message-ID: Date: Tue, 6 Jan 1998 17:43:10 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] Cross-certification issues and terminology Comments: To: wford@VERISIGN.COM To: IETF-PKIX@LISTS.TANDEM.COM Status: Warwick, Thanks for taking the time to continue this highly interesting discussion. >> >>If I as a CA want to issue a certificate to a TLCA (or in fact to any CA), >>do I necessarily need that CA's permission to do so? I think not, although >>it might be polite to inform them of what I am doing. (In most cases, of >>course, this would only happen after a contractual agreement, so this is >>probably just a rhetorical point.) [snip] > >Well, I don't think you want to go around issuing certificates for other >CAs' public keys without their permission. Firstly, it is unwise since you >would have no basis of assurances re future validity, revocation >notification, etc. Secondly you could arguably be treading into >intellectual property violation waters. Therefore, I think that we should >be espousing that CA-certificates ALWAYS be issued only within a >contractual agreement. Hmm. I'm not entirely sure that I agree. What is the moral or legal, as opposed to technical, difference between my creating a certificate which incorporates the public key of a TLCA, e.g., VeriSign, or any other CA, vs. directly loading the very same public key or self-signed certificate into my trusted cache? If you recall, you were the one who convinced me of the elegance of the policy OID constraint approach to certificate chaining, pointing out that it allowed the user himself, (or his IT organization) to create a certificate which effectively serves as his own local (unpublished) TLCA and cross-certifies other CAs, without requiring access to some kind of a local database of trusted CAs to validate each certificate. A suitable trusted smart card, a la Fortessa, containing a trusted public key or self-signed certifcate, could feasibly implement the relying party's trust policy without requiring a trusted operating system host. This way the RP has only his own public key to trust, and the IT organization doesn't have to run around the country or the world populating new trusted TLCA keys into client software every time a new CA pops up or a key is replaced. They merely post new certificates on an untrusted directory or repository, to be downloaded as needed. A closed user group might be a different matter. But even in the case of SET, what is to prevent me as a relying party from creating my own certificate which cross-certifies the SET hierarchy? If all I am doing is selling dollar dish rags, I might be willing to accept a SET certificate, a Verisign certificate, a MISSI certificate, (or even a PGP certificate or whatever), and take the byusiness risk that one of those CAs or hierarchies has a less- han sterling reputation. It is arguably better than using nothing at all, e.g., a telephone crecit card number. In particularly, I DON'T think that I have to go out and negotiate a contract with each one of those CAs before I create such a cross-certificate, or equivalently load a self-signed certificate into my trusted cache. That is essentially the fundamental assumption basis for an open PKI architecture. PUBLISHING such a certificate outside of my close circle of friends might be quite a different matter, of course. But there my concern would be whether by publishing such a certificate I might be making myself liable for that other CA's operational screw-ups, etc. I would look at the CA's Cetification Practice Statement and other indicia before decding whether or not to trust the ongoing CRL and other policy matters, just as I would before loading their root key into my cache. In any case I can make that decision for myself -- I don't need and don't want a standard to preclude my options (although I doubt that was what you had in mind). I am not persuaded by the intellectual property argument, either, but I would like to hear an attorney like Michael Baum put forth a cogent legal theory along those lines. To my way of thinking, I am not publishing any copywrited or trademarked work at all, except to the extent that I incorporate the public key contained in the CA's certificate. Since the public nature of the public key is its raison d'etre, and since the CA's certificate cannot be used except by incorporating the public key in the relying party's cache of trusted keys one way or the other, I don't see how I have infringed or diminished their copyright, the CA's trademark, or their good name in any way. I understand that VeriSign includes a copyright notice within their certificates, but I have tended to regard this as a chicken soup, "it cant' hurt" type of preventative medicine cop out. If there is a real legal issue lurking there somewhere, I'd like to know about it, as I believe it might apply by extension to the use of that certificate by any relying party. I don't think that was VeriSign's intent. Regards, Bob From ???@??? Wed Jan 07 11:27:08 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id GAA29587 for ; Wed, 7 Jan 1998 06:20:10 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 7 Jan 1998 07:22:55 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id GAA14372; Wed, 7 Jan 1998 06:13:29 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 13738 for IETF-PKIX@LISTS.TANDEM.COM; Wed, 7 Jan 1998 06:12:52 -0800 Received: from kekec.e5.ijs.si (klobucar@kekec.e5.ijs.si [193.138.1.2]) by Tandem.com (8.8.8/2.0.1) with SMTP id GAA00439 for ; Wed, 7 Jan 1998 06:02:16 -0800 (PST) Received: by kekec.e5.ijs.si id AA18124 (5.67b/IDA-1.5 for ietf-pkix@lists.tandem.com); Wed, 7 Jan 1998 15:01:22 +0100 X-Mailer: ELM [version 2.4 PL0] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-ID: <199801071401.AA18124@kekec.e5.ijs.si> Date: Wed, 7 Jan 1998 15:01:21 +0100 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Tomaz Klobucar Subject: Re: [IETF-PKIX] Dave's Critical Proposal To: IETF-PKIX@LISTS.TANDEM.COM Status: Although there was a long discussion about certificate policies on this list I am still a bit bemused, especially about recognizing and supporting certificate policies extensions (critical or non-critical). I would appreciate if someone could explain the following case. Let us suppose that a CA has published two policies for signing bills in certain company. One is used for bills where amount is less than 1000$ and does not specify how private keys must be protected. The other policy specifies rules for keys which can be used to sign bills over 1000$. These keys must be stored on smartcards. The CA then issues certificates where one of this certificate policies is flagged critical. Should signing applications and applications for validating signatures which claim to support these policies check the amount in each bill during signing procedure or signature validation? Must applications be able to verify if the signing key is properly stored? Regards, Tomaz From ???@??? Wed Jan 07 19:35:54 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id TAA16900 for ; Wed, 7 Jan 1998 19:27:10 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 7 Jan 1998 20:29:54 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id TAA15661; Wed, 7 Jan 1998 19:23:13 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 14201 for IETF-PKIX@LISTS.TANDEM.COM; Wed, 7 Jan 1998 19:23:14 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id TAA05924 for ; Wed, 7 Jan 1998 19:23:13 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Wed, 07 Jan 1998 19:45:21 -0700 X-Mailer: Novell GroupWise 4.1 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Message-ID: Date: Wed, 7 Jan 1998 10:28:18 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] Dave's Critical Proposal Comments: To: klobucar@E5.IJS.SI To: IETF-PKIX@LISTS.TANDEM.COM Status: >>> Tomaz> Klobucar 01/07 7:01 AM >>> >Although there was a long discussion about certificate policies on this list >I am still a bit bemused, especially about recognizing and supporting >certificate policies extensions (critical or non-critical). I would >appreciate if someone could explain the following case. Let us suppose >that a CA has published two policies for signing bills in certain company. >One is used for bills where amount is less than 1000$ and does not specify >how private keys must be protected. The other policy specifies >rules for keys which can be used to sign bills over 1000$. These keys must be >stored on smartcards. The CA then issues certificates where one of this >certificate policies is flagged critical. Should signing applications and >applications for validating signatures which claim to support these policies >check the amount in each bill during signing procedure or signature >validation? Must applications be able to verify if the signing key is properly >stored? > >Regards, Tomaz Tomaz, let me take a crack at this. Others may jump in if they disagree. First of all , when you say that the CA has published policies for signing bills, I assume that what you really mean is that the Controller or other management official within the company has decided what the policy must be, and that the CA and others are directed to implement that policy, whether the CA is internal to the company or outsourced. The CA therefore will issue certificates with either of two flavors of policy OIDs -- either "gold" for high value transactions, or "brown" for low value transactions. More likely, there will be a "gold" OID and no OID. The rule for the relying party's software is simple. The application which processes bills has to look at the amount involved, and then decide whether the appropriate evidence exists to approve the transaction. So far, this has NOTHING to do with the certificate infrastructure -- this is a requirement laid on the application software and the software developers/purchasers by the Controller, not by the certificate policy. Assuming that the transaction amount is over $1000, the application has to instruct the crypto API as to what kind of digital signatures to accept, i.e., what kind of certificates are acceptable. The crypto API could reference a local database of acceptable certificates, of course, but I believe that your question assumed the use of the PKIX/X.509 infrastructure without any trusted databases. The way I would solve that problem if I were implementing the code would be to provide two different contexts or API calls, one of which would specify one self-signed certificate, and one of which would specify another. The first self-signed certificate, effectively issued by the MIS department responsible for overseeing the implementation of the controller's policy, would contain a "gold" policy OID constraint which is marked Critical, and would cross-certify the normal corporate CA's root key, or perhaps some external CA's certificate. By virtue of the policy OID constraint, only certificates containing a matching policy OID would be deemed acceptable, whether issued by the top level corporate CA or some subordinate CA. Importantly, however, the certificate of the end-user who is signing the bill would (must) contain the matching policy OID. Because the original policy OID constraint was marked Critical, the relying party's software would be forced to check that all of the certificates in the chain contained the appropriate policy OID attribute. The other self-signed certificate would either contain a "brown" policy OID constraint, which might or might not be marked Critical, or more likely it would not contain a policy OID constraint at all. By dynamically switching between these two contexts on a transaction by transaction basis, the relying party's software can ensure that for a given transaction, the right kind of digital signature/certificate chain was used, and ergo the right kind of protection was being given for the private key. But the other portion of your question addressed the enforcement of the policy at the time of signing, and that is a different question entirely. When the CA binds the end-user's public key in a certificate, then in the case of a "gold" policy OID, the CA is duty bound to ensure that only those key storage devices which conform to the policy can be used to generate, store, or access the corresponding private keys. How the CA determines and/or ensures that fact is its own business, but is presumably specified as part of the overall policy which is referenced by the policy OID. In most cases this will probably involve a representation by the end-user to the CA that the key in question is properly stored, never accessed in the clear, etc., and that may suffice -- especially if misrepresenting the facts to the CA is grounds for firing the employee! Ultimately, as the infrastructure evolves, devices such as smart cards, and even software implementations, may protect the keys in such a way as to prevent their disclosure outside of the minimum acceptable environment. So now the user -- the one who is signing the bills originally -- either has two keys, a good one and a not so good one, or they only have one or the other, perhaps depending on their status in the company. If they only have one key, of course there isn't much of a problem. If someone tries to sign a transaction over $1000 and doesn't have the right kind of key, the transaction won't validate at the other end, and after couple of such instances he won't do that again, or else. If he has two keys, and the signing application is supposed to be sufficiently intelligent to switch between the two keys based on the amount of the transaction, that is more complicated. The two context solution could still be used, in this case switching between the two signing keys. But this is still sort of a scout's honor type of solution -- the enforcement is done by the verifying application based on the policy OID in the certificate, and not by the signing application where it probably ought to be done. That is why, in one of my previous messages, I urged that the constraints in the certificate be interpreted by the SIGNING application as well, prior to using the corresponding private key to sign something. That would prevent the signing application from using an encryption key instead of a signing key, for example. And if the policy OID constraint is marked critical, the signing application ought to be in an appropriate context before using that key. So, for example, if the application sees an amount that is over $1000, it would switch contexts, examine the certificate that goes with the key that is about to be used for signing, and either accept or reject that particular signing operation accordingly. I hope this answers your question. Regards, Bob Robert R. Jueneman Security Architect Novell, Inc. Network Services Division 122 East 1700 South Provo, UT 84604 801/861-7387 bjueneman@novell.com "If you are trying to get to the moon, climbing a tree, although a step in the right direction, will not prove to be very helpful." "The most dangerous strategy is to cross a chasm in two leaps." From ???@??? Wed Jan 07 13:47:18 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA05691 for ; Wed, 7 Jan 1998 12:06:36 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 7 Jan 1998 13:09:34 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA14125; Wed, 7 Jan 1998 12:03:02 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 13878 for IETF-PKIX@LISTS.TANDEM.COM; Wed, 7 Jan 1998 12:03:01 -0800 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id MAA01356 for ; Wed, 7 Jan 1998 12:02:59 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA09698 for ; Wed, 7 Jan 1998 15:02:58 -0500 (EST) Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA09694 for ; Wed, 7 Jan 1998 15:02:57 -0500 (EST) Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id OAA03628 for ; Wed, 7 Jan 1998 14:53:27 -0500 Received: from avenger.missi.ncsc.mil (unverified [144.51.58.206]) by mimesweeper.missi.ncsc.mil (Integralis SMTPRS 2.02) with SMTP id ; Wed, 07 Jan 1998 14:56:32 -0500 Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BD1B7C.7127A480@avenger.missi.ncsc.mil>; Wed, 7 Jan 1998 14:56:32 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 7 Jan 1998 14:56:31 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "Arsenault, Al W." Subject: [IETF-PKIX] Is PKIX Patent-free? To: IETF-PKIX@LISTS.TANDEM.COM Status: (Thanks to Bill Burr and his folks at NIST who "discovered" this in their Federal PKI working group efforts.) Folks, I'm not a lawyer, and I don't play one on TV, either, so I'm hoping that there is no problem with this, but... There are (at least) two US patents that may be of interest to PKIX. Both are owned by Silvio Micali. One, patent #5,420,927, issued May 30, 1995, and entitled "Method for certifying public keys in a digital signature", claims to cover a method of using registration agents to identify users, validate their public keys, send their keys on to a certification authority for inclusion in a certificate, confirm that the user possesses the private key that goes with the public key, etc. The other, patent # 5,666,416, issued September 9, 1997, and entitled "Certificate revocation system", claims to cover a method of having a CA determine whether a certificate is valid; pass a message stating such to another party, and having that party respond to queries from others with information about the validity of the certificate. The "invention" covered by this patent "...obviates use of certification revocation lists communicated between the certifying authority and the directory. " Is there someone on the list who can say with certainty that PKIX parts 1 and 3 do not infringe on the first of these patents, and that OCSP does not infringe on the other one? Thanks for any information, Al Arsenault - speaking only for myself. My opinions do not necessarily reflect those of my employer. P.S. URLs for these patents are http://patent.womplex.ibm.com/details?patent_number=5420927 and http://patent.womplex.ibm.com/details?patent_number=5666416 From ???@??? Wed Jan 07 19:35:53 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id TAA16648 for ; Wed, 7 Jan 1998 19:20:02 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 7 Jan 1998 20:22:46 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id TAA15439; Wed, 7 Jan 1998 19:19:31 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 14165 for IETF-PKIX@LISTS.TANDEM.COM; Wed, 7 Jan 1998 19:19:26 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id TAA05482 for ; Wed, 7 Jan 1998 19:19:24 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Wed, 07 Jan 1998 19:58:16 -0700 X-Mailer: Novell GroupWise 4.1 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Message-ID: Date: Wed, 7 Jan 1998 14:12:20 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] Is PKIX Patent-free? Comments: To: awarsen@MISSI.NCSC.MIL To: IETF-PKIX@LISTS.TANDEM.COM Status: At least with respect to the second patent that Al mentioned, before someone automatically concludes that Dr. Micali's patent is valid, they ought to go back through the PEM archives for the dialogue between Sead Muftic and myself, probably in the 1995 time period, where we were discussing something very similar to what that patent appears to cover. Likewise, I'm a little surprised by the registration agent patent. I thought that was a pretty well developed concept in the DMS architecture, as well as being pretty obvious. but I haven't examined the claims in detail, so maybe there is more there than meets the eye. It isn't clear to me how careful a job was done of looking at unpatented prior art prior to issuing several of these patents. Before I shelled out a lot of money for licenses in this area, I might talk to a good attorney about the possibility of attacking the validity of these patent(s). At the same time, I don't mean to suggest that any kind of inappropriate behavior occurred on Dr. Micali's part -- lots of cases in the past have involved two or more inventors coming up with essentially the same invention independently, at more or less the same time, in response to a common perceived need. Bob >(Thanks to Bill Burr and his folks at NIST who "discovered" this in >their Federal PKI working group efforts.) > >Folks, > > I'm not a lawyer, and I don't play one on TV, either, so I'm hoping >that there is no problem with this, but... > > There are (at least) two US patents that may be of interest to PKIX. >Both are owned by Silvio Micali. > > One, patent #5,420,927, issued May 30, 1995, and entitled "Method for >certifying public keys in a digital signature", claims to cover a method >of using registration agents to identify users, validate their public >keys, send their keys on to a certification authority for inclusion in a >certificate, confirm that the user possesses the private key that goes >with the public key, etc. > > The other, patent # 5,666,416, issued September 9, 1997, and entitled >"Certificate revocation system", claims to cover a method of having a CA >determine whether a certificate is valid; pass a message stating such to >another party, and having that party respond to queries from others with >information about the validity of the certificate. The "invention" >covered by this patent "...obviates use of certification revocation >lists communicated between the certifying authority and the directory. " > > Is there someone on the list who can say with certainty that PKIX parts >1 and 3 do not infringe on the first of these patents, and that OCSP >does not infringe on the other one? > > Thanks for any information, > > > Al Arsenault > - speaking only for myself. My opinions do not necessarily reflect >those of my employer. > >P.S. URLs for these patents are > > http://patent.womplex.ibm.com/details?patent_number=5420927 > >and > > http://patent.womplex.ibm.com/details?patent_number=5666416 Robert R. Jueneman Security Architect Novell, Inc. Network Services Division 122 East 1700 South Provo, UT 84604 801/861-7387 bjueneman@novell.com "If you are trying to get to the moon, climbing a tree, although a step in the right direction, will not prove to be very helpful." "The most dangerous strategy is to cross a chasm in two leaps." From ???@??? Wed Jan 07 15:04:03 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id OAA09773 for ; Wed, 7 Jan 1998 14:53:04 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 7 Jan 1998 15:56:02 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id OAA27070; Wed, 7 Jan 1998 14:49:07 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 13978 for IETF-PKIX@LISTS.TANDEM.COM; Wed, 7 Jan 1998 14:48:55 -0800 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by Tandem.com (8.8.8/2.0.1) with ESMTP id OAA29134 for ; Wed, 7 Jan 1998 14:48:52 -0800 (PST) Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id RAA25255 for ; Wed, 7 Jan 1998 17:47:52 -0500 (EST) X-Sender: kent@po1.bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Date: Wed, 7 Jan 1998 17:46:05 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Stephen Kent Subject: Re: [IETF-PKIX] cross certification To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: <34B0035F.35157DB8@mindspring.com> Status: Dwight & Warwick, I'd like to add another view to the cross certification discussion. Certificates don't necessarily imply trust. They are primarily mechanisms to support identification (although explicit authorization is also an option), and this identification is often used as an input to an access control decision. So, when I certify a CA in another administrative domain, the simple connotation is that I am relying on (trusting?) that CA to identify subjects within that domain. Having relied upon that CA for that function, I can then proceed to make access control decisions based on the subject identities from this other administrative domain. If one embeds authorization info into the certs and uses that for access control, then life is more complex and certification policy extensions may also be used to help control the authorization range afforded to the cross-certified CA. As Tina Turner so aptly said, "what's trust got to do with it?" Steve From ???@??? Thu Jan 08 09:58:49 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id CAA27960 for ; Thu, 8 Jan 1998 02:30:22 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 8 Jan 1998 03:33:09 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id CAA03986; Thu, 8 Jan 1998 02:29:26 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 14384 for IETF-PKIX@LISTS.TANDEM.COM; Thu, 8 Jan 1998 02:29:20 -0800 Received: from marcellus.cost.se (Marcellus.cost.se [195.100.88.66]) by Tandem.com (8.8.8/2.0.1) with ESMTP id CAA06189 for ; Thu, 8 Jan 1998 02:19:15 -0800 (PST) Received: from jimmie (Jimmie.cost.se [195.100.88.21]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id LAA25910 for ; Thu, 8 Jan 1998 11:16:32 +0100 (MET) X-Sender: nada@mail.cost.se X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.3.32.19980108112219.00afea50@mail.cost.se> Date: Thu, 8 Jan 1998 11:22:19 +0100 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Nada Kapidzic Cicovic Subject: [IETF-PKIX] request for change of CertRepContent To: IETF-PKIX@LISTS.TANDEM.COM Status: I wonder if this is the right time to request a change in ipki3cmp format of the certification response message (being in the final call stage), but it seems to be lacking one very useful information: CRLs needed to verify certificates contained in the message. The inclusion of CRLs would enable certificate verification software to verify certificates without extra access to CRL repositories. The field can be made optional, so that CAs are not required to keep CRLs after publishing them, but in case they do keep CRLs this field may be used to make certificate validation process faster. The suggested format of CertRepContent is the following: CertRepContent ::= SEQUENCE { caPubs [0] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, -> crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL, -- CRLs corresponding to caPubs and certificates in response response SEQUENCE OF CertResponse } Any comments? Regards, Nada ______________________________________________________________ Nada Kapidzic Cicovic COST - Computer Security Technologies CST AB (subsidiary of Entegrity Solutions Corporation) office: + 46 (0)8 477 77 37 mobile: + 46 (0)70 495 09 03 fax: + 46 (0)8 477 77 31 e-mail: nada@cost.se or nada@entegrity.com address: Finlandsgatan 60, 164 74 Kista, Sweden From ???@??? Thu Jan 08 09:58:50 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id GAA00444 for ; Thu, 8 Jan 1998 06:02:12 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 8 Jan 1998 07:05:00 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id FAA12349; Thu, 8 Jan 1998 05:59:56 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 14484 for IETF-PKIX@LISTS.TANDEM.COM; Thu, 8 Jan 1998 05:59:50 -0800 Received: from marcellus.cost.se (Marcellus.cost.se [195.100.88.66]) by Tandem.com (8.8.8/2.0.1) with ESMTP id FAA19534 for ; Thu, 8 Jan 1998 05:49:48 -0800 (PST) Received: from antwan.cost.se (Antwan.cost.se [195.100.88.28]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id OAA27019 for ; Thu, 8 Jan 1998 14:47:03 +0100 (MET) Received: from cost.se by antwan.cost.se (SMI-8.6/SMI-SVR4) id OAA28274; Thu, 8 Jan 1998 14:51:37 +0100 X-Mailer: exmh version 2.0delta 6/3/97 Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-ID: <199801081351.OAA28274@antwan.cost.se> Date: Thu, 8 Jan 1998 14:51:37 +0100 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Tomas Gustavsson Subject: [IETF-PKIX] Management protocols and base64 encoding To: IETF-PKIX@LISTS.TANDEM.COM Status: In draft-ieft-pkix-ipki3cmp-06.txt there is specified how messages should be transported over email and http. For http is says: Content-Type: application/pkixcmp <> while it is base64 encoded for email. I would like to allow base64 encoding also for http based transports. One reason for this is that with some windows based web servers we have had problems returning binary data undamaged from cgi programs. It is not very hard to make automatic detection if the received data is base64 encoded or not. Anyone else has any feelings about this? Regards, Tomas Gustavsson Computer Security Technologies CST AB (subsidiary of Entegrity Solutions Corp.) Email: tomasg@cost.se Tel: +46 8 477 7740 Fax: +46 8 477 7731 From ???@??? Sun Jan 11 22:09:26 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id HAA06347 for ; Fri, 9 Jan 1998 07:40:36 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 9 Jan 1998 08:43:27 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id HAA20271; Fri, 9 Jan 1998 07:38:24 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 14785 for IETF-PKIX@LISTS.TANDEM.COM; Fri, 9 Jan 1998 07:37:36 -0800 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id HAA27283 for ; Fri, 9 Jan 1998 07:37:34 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA20279 for ; Fri, 9 Jan 1998 10:37:28 -0500 (EST) Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA20275 for ; Fri, 9 Jan 1998 10:37:28 -0500 (EST) Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id KAA07486 for ; Fri, 9 Jan 1998 10:34:20 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id KAA24494; Fri, 9 Jan 1998 10:35:28 -0500 X-Sun-Charset: US-ASCII Message-ID: <199801091535.KAA24494@argon.ncsc.mil> Date: Fri, 9 Jan 1998 10:35:28 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "David P. Kemp" Subject: Re: [IETF-PKIX] Cross-certification issues and terminology To: IETF-PKIX@LISTS.TANDEM.COM Status: > From: Bob Jueneman > > If you recall, you [Warwick] were the one who convinced me of the elegance of the > policy OID constraint approach to certificate chaining, pointing out that it > allowed the user himself, (or his IT organization) to create a certificate > which effectively serves as his own local (unpublished) TLCA and > cross-certifies other CAs, without requiring access to some kind of a local > database of trusted CAs to validate each certificate. A suitable trusted > smart card, a la Fortessa, containing a trusted public key or self-signed > certifcate, could feasibly implement the relying party's trust policy > without requiring a trusted operating system host. > > This way the RP has only his own public key to trust, and the IT > organization doesn't have to run around the country or the world populating > new trusted TLCA keys into client software every time a new CA pops up or a > key is replaced. They merely post new certificates on an untrusted directory > or repository, to be downloaded as needed. I quite agree, and am surprised that this approach to PKI organization has not been more widely publicized, or documented (as an informational appendix or RFC, not as normative text) in PKIX. Bob, this is the clearest statement I've seen yet of the advantages of the "domain administrator" (or "local TLCA") model - may I quote you? We have been grappling with the problem of reconciling three PKI models into a coherent concept of operations for a PKI to serve Federal Government users: * single-rooted heirarchy (DMS / MISSI v1), * heirarchies interdomain-certified at the root level (IPsec/ANX, MISSI v2) * single-level certification with each user configuring a list of "trusted" CAs (the current web browser model) The local-TLCA model, if supported by commercial product vendors, would satisfy the needs of individual users to choose who they trust (and also make trust decisions more explicit by requiring the user to issue a cert to each CA in the list, and allow finer granularity of control, if desired, by including name and policy constraints in the user-generated certs). It would also satisfy the needs of organizations to inject some assurance into the PKI management process, and allow control of some functions to be delegated to lower levels while retaining control over other functions (such as organizational messaging, high-value contracts, etc) at the organizational level. Dave Kemp From ???@??? Sun Jan 11 22:09:48 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA11060 for ; Fri, 9 Jan 1998 10:50:01 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 9 Jan 1998 11:53:01 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA05239; Fri, 9 Jan 1998 10:45:29 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 14881 for IETF-PKIX@LISTS.TANDEM.COM; Fri, 9 Jan 1998 10:45:19 -0800 Received: from mtigwc03.worldnet.att.net (mtigwc03.worldnet.att.net [204.127.131.34]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA27033 for ; Fri, 9 Jan 1998 10:35:17 -0800 (PST) Received: from default ([12.64.8.91]) by mtigwc03.worldnet.att.net (post.office MTA v2.0 0613 ) with SMTP id AAA19124 for ; Fri, 9 Jan 1998 18:34:45 +0000 X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <34B66D67.BC@acm.org> Date: Fri, 9 Jan 1998 10:33:11 -0800 Reply-To: enos@acm.org Sender: "IETF X.509-based public key infrastructure mailing list" From: Walter Enos Subject: [IETF-PKIX] (pure) Java implementations of PKIX? To: IETF-PKIX@LISTS.TANDEM.COM Status: Are any Java implementations available today, or are implementations planned to be available once the standard is finalized? I haven't seen any vendor announcements yet- can anyone shed some light on this for me? Thanks! Walter __________________ Walter Enos 904 Los Robles Avenue Palo Alto, CA 94306 email: enos@acm.org From ???@??? Sun Jan 11 22:10:08 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA13315 for ; Fri, 9 Jan 1998 12:22:00 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 9 Jan 1998 13:24:44 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA12506; Fri, 9 Jan 1998 12:15:15 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 14983 for IETF-PKIX@LISTS.TANDEM.COM; Fri, 9 Jan 1998 12:15:00 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id MAA14094 for ; Fri, 9 Jan 1998 12:14:58 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id MAA22643; Fri, 9 Jan 1998 12:14:26 -0800 (PST) Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA29541; Fri, 9 Jan 1998 12:14:22 -0800 (PST) X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 References: <199801081351.OAA28274@antwan.cost.se> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2EC84A68F587EE1BC575DE64" Message-ID: <34B687DE.9FACE82A@verisign.com> Date: Fri, 9 Jan 1998 15:26:06 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Phillip Hallam-Baker Organization: VeriSign Inc. Subject: Re: [IETF-PKIX] Management protocols and base64 encoding To: IETF-PKIX@LISTS.TANDEM.COM Status: Tomas Gustavsson wrote: > > In draft-ieft-pkix-ipki3cmp-06.txt there is specified how messages should be > transported over email and http. For http is says: > > Content-Type: application/pkixcmp > <> > > while it is base64 encoded for email. I would like to allow base64 encoding > also for http based transports. One reason for this is that with some windows > based web servers we have had problems returning binary data undamaged from > cgi programs. It is not very hard to make automatic detection if the received > data is base64 encoded or not. I really don't think that the spec should attempt to vary the HTTP specification. HTTP permits base64 encoding but does not require clients to be able to interpret it. We designed HTTP to be 8-bit clean and have been extreemly definite about keeping it that way. If your server cannot provide an 8-bit clean communication with a plug in application that is a bug that is your responsibility. The purpose of IETF standards is to standardize communications over the network where it is very difficult to change infrastructure. Mangling a spec to provide backwards compatibility with internal infrastructure that can be upgraded by the person with the problem has never been accepted as important. It appears that your problem is using CGI which was developed as a solution for UNIX based systems on a Windows platform. The only reason CGI was invented was because UNIX support for shared libraries was incomplete at the time. Phill Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Attachment converted: Lutefisk:smime.p7s 27 (????/----) (0001DE9D) From ???@??? Sun Jan 11 22:10:22 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA13565 for ; Fri, 9 Jan 1998 12:29:09 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 9 Jan 1998 13:31:58 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA13276; Fri, 9 Jan 1998 12:24:57 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 15021 for IETF-PKIX@LISTS.TANDEM.COM; Fri, 9 Jan 1998 12:24:30 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id MAA15586 for ; Fri, 9 Jan 1998 12:24:16 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id MAA22791; Fri, 9 Jan 1998 12:23:35 -0800 (PST) Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA00032; Fri, 9 Jan 1998 12:23:33 -0800 (PST) X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB9159B7130F685503DA27F2C" Message-ID: <34B68A14.F0521512@verisign.com> Date: Fri, 9 Jan 1998 15:35:32 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Phillip Hallam-Baker Organization: VeriSign Inc. Subject: Re: [IETF-PKIX] Is PKIX Patent-free? To: IETF-PKIX@LISTS.TANDEM.COM Status: Bob Jueneman wrote: [details of Silvios patents deleted] Since you are Novell Bob, perhaps you could find out about the intention and interpretation of the Novell patent? http://patent.womplex.ibm.com/details?patent_number=5687235 5687235 : Certificate revocation performance optimization INVENTORS: Perlman; Radia J., Acton, MA Reed; Edwards E., Lindon, UT Carter; Tammy G., Pleasant Grove, UT ASSIGNEES: Novell, Inc., Orem, UT ISSUED: Nov. 11, 1997 FILED: Oct. 26, 1995 ABSTRACT: The present invention is an improved certificate revocation process that improves the efficiency of an authentication exchange in a public key distributed network system. Specifically, the present invention includes a novel revocation service (RS) that, in response to a unique request from a server node, selects certain revoked certificates from a current CRL to include in its reply so as to consume minimal system bandwidth It would also be handy if someone from Entrust or Nortel could give some information about their intentions concerning their CRL distribution points patent. Needless to say this is all going to have to be sorted out before the IESG accepts the PKIX standards. Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Attachment converted: Lutefisk:smime.p7s 28 (????/----) (0001DE9E) From ???@??? Mon Jan 12 00:27:58 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id AAA04838 for ; Mon, 12 Jan 1998 00:05:05 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 12 Jan 1998 01:08:00 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id AAA23469; Mon, 12 Jan 1998 00:03:49 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 15464 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 12 Jan 1998 00:02:13 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id AAA09983 for ; Mon, 12 Jan 1998 00:02:12 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Mon, 12 Jan 1998 01:01:38 -0700 X-Mailer: Novell GroupWise 4.1 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Message-ID: Date: Sun, 11 Jan 1998 23:56:12 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Robert Jueneman Subject: Re: [IETF-PKIX] Cross-certification issues and terminology Comments: To: dpkemp@MISSI.NCSC.MIL To: IETF-PKIX@LISTS.TANDEM.COM Status: >> From: Bob Jueneman >> >> If you recall, you [Warwick] were the one who convinced me of the elegance of the >> policy OID constraint approach to certificate chaining, pointing out that it >> allowed the user himself, (or his IT organization) to create a certificate >> which effectively serves as his own local (unpublished) TLCA and >> cross-certifies other CAs, without requiring access to some kind of a local >> database of trusted CAs to validate each certificate. A suitable trusted >> smart card, a la Fortessa, containing a trusted public key or self-signed >> certificate, could feasiblely implement the relying party's trust policy >> without requiring a trusted operating system host. >> >> This way the RP has only his own public key to trust, and the IT >> organization doesn't have to run around the country or the world populating >> new trusted TLCA keys into client software every time a new CA pops up or a >> key is replaced. They merely post new certificates on an untrusted directory >> or repository, to be downloaded as needed. > > >I quite agree, and am surprised that this approach to PKI organization >has not been more widely publicized, or documented (as an informational >appendix or RFC, not as normative text) in PKIX. Bob, this is the >clearest statement I've seen yet of the advantages of the "domain >administrator" (or "local TLCA") model - may I quote you? In general, I assume that anything posted to a _public _ list such as this is said on the record, and as such may be quoted without explicit permission. But thanks for the courtesy of asking. > >We have been grappling with the problem of reconciling three PKI models >into a coherent concept of operations for a PKI to serve Federal Government >users: > * single-rooted hierarchy (DMS / MISSI v1), > * heirarchies interdomain-certified at the root level (IPsec/ANX, MISSI v2) > * single-level certification with each user configuring a list of > "trusted" CAs (the current web browser model) > >The local-TLCA model, if supported by commercial product vendors, would >satisfy the needs of individual users to choose who they trust (and >also make trust decisions more explicit by requiring the user to issue >a cert to each CA in the list, and allow finer granularity of control, >if desired, by including name and policy constraints in the >user-generated certs). > >It would also satisfy the needs of organizations to inject some >assurance into the PKI management process, and allow control of some >functions to be delegated to lower levels while retaining control over >other functions (such as organizational messaging, high-value >contracts, etc) at the organizational level. > >Dave Kemp I think that I have described a further extension to this general paradigm, certainly in person at a Federal PKI meeting and on some legal lists, but I don't recall whether I discussed it on the PKIX list. So let me elaborate somewhat. I am increasingly convinced that despite whatever benefits might accrue from the official licensing of CAs a la the Utah Digital Signature Act, it is not likely to extend or scale very well. Although I currently live in Utah, I would not claim that it was the hub of the universe with respect to electronic commerce. I therefore doubt that there will be a huge rush for every CA in the world to sign up as a Utah-licensed CA. The same is probably true of Florida, Washington, Illinois, and the other states which Utah-like legislation, much less the "minimalist" states such as California, Massachusetts, etc. What might happen, however, is that some of those states, some governmental agencies, and perhaps some industry associations, might either formally or informally publish a set of reasonable set of criteria for what constitutes a reasonable set of operational practices for a CA. (The ABA Information Security committee -- the group that wrote the Digital Signature Guidelines -- is presently addressing a set of Guidelines for CA accreditation that may eventually form the basis for such an effort.) Assuming that some reasonably small set of criteria are developed, _and_ assuming that those same organizations develop some form of auditing and/or other on-going oversight is put into place, it is my hope that these accrediting agencies can from the basis for an international PKI trust infrastructure. Although I am not an attorney, I believe that the differences in the various legal systems throughout the world, together with national sovereignty issues, are too great as to ever allow a prescriptive set of standards to be put into place. So instead of an international set of "thou-shalt" laws or regulations being passed, the basis for mutual trust will be much closer to the way that a bond rating organization such as Standard and Poors operates. In other words, the accrediting agency will issue a non-liability bearing memorandum of opinion about a CA's practices, and based on that opinion and the recognition that the CA is at least a bona fide organization, individual relying parties (or relying organizations) will decide for themselves whether that CA's certificate form an adequate basis of trust for certain classes of transactions, or not. Now, how would this system operate in an individual-TLCA paradigm (to use your terminology -- as good as any I've seen)? Well, suppose I had three different types of transactions I might want to decide whether to accept as a relying party. Maybe one is a routine e-mail attribution, not unlike what is presumably intended by those who use PGP to sign their contributions. They don't intend that their utterances be interpreted as a legally binding contract, and I as a relying party don't view that way either, except to make sure that someone isn't playing games and impersonating someone else. My second type of transaction might be intra- and intercorporate business correspondence -- not formal purchase orders, bids, or other "EDI" transactions -- just normal business correspondence that is routinely signed to convey good faith in negotiations. Although not common, such "transactions" have the potential to end up in court is there is ever a serious disagreement about the intent of the parties. another example of the level of transaction might be to digitally sign a tax return, to file an insurance claim, etc. Finally, there is the really serious applications, e.g., for selling your house, signing your will, or other big ticket items. For businesses, perhaps this level of transaction is the over-$100,000 (or maybe over $1 million) type of transaction. Now, having analyzed my security/reliance requirements and reduced them down to perhaps overly-simplistic essence, I might create three different unpublished,, self-signed, TLCA certificates, each containing a unique policy OID (unique to and known only by me). I'll refer to those policies as my Red, White, and Blue policies. Now then, once I have reviewed the legal and technical aspects of say VeriSign's Certificate Practice Statement in detail, I might conclude that both their Class 1 and their Class 2 certificates satisfy my Red policy, that their Class 3 certificate satisfies my White policy, but that they don't yet have a class that would satisfy my Blue category. I could then cross certify VeriSign's certificates (unilaterally, without necessarily contracting with VeriSign for this purpose), using policy mapping plus a critical policy OID constraint to control which of VeriSign's certificates I would accept. Likewise, I might decide that Utah's licensed CAs would satisfy my Blue criteria. But going beyond the current status quo, sometime next year, Utah might decide that the Washington State, Florida, MISSI, and German Government CA's satisfy the criteria for a Utah licensed CA, and Utah might cross-certify those other CAs, either unilaterally or bilaterally, again using policy mapping. Maybe they make up a series of policies, say Pearl, Ruby, and Diamond. And some other CA rating agency make up some other criteria, say Classic/Green/Brass, Gold, and Platinum, etc., etc. Assuming the various rating agencies invest the necessary legal and technical effort into comparing the various policies and coming up with some simplifying ratings, I would hope that I could eventually chain from my own personal "Red" policy criteria to Utah's "Ruby" to MISSI's Gold policy, etc. I may be asking a lot for the creation of these policy rating efforts, but I think it is a lot more reasonable and feasible than having various CA's actually undertake some level of liability for some other CAs actions, much less some state agency or industry association. In any case, assuming that these approximate correspondences can ultimately be established, the use of an individual TLCA plus policy mapping and policy constraints certainly appears to offer the necessary controls necessary to implement a more or less automatic, lights-out approach to certificate validation. By switching contexts as to which self-signed TLCA certificate is acceptable for a given type of transaction (perhaps based on the transaction amount), all of the rest of the certificate validation process should be capable of being completely automated and deterministic. At least that is the challenge. Now, I believe that what we ought to do is hold up the detailed text to a critical examination along these lines, and ask the nitty-gritty operational questions. For example, I haven't discussed the role of policy parameters, and whether some form of mapping is needed there. How, for example, do we compare two reliance limit policy parameters if one is in US dollars and the other is in French francs? I'm sure there is more work to be done, but I think this is a good starting point. And by the way, I tend to believe that these kinds of examples _do_ belong in the PKIX document. Too often, I believe, we tend to take out these kinds of how-we-got-there steps, and only present the bare bones conclusions. All too often, that tends to make those who look at these issues later reinvent the wheel, sometimes in a surprisingly different shape. Bob From ???@??? Mon Jan 12 00:28:00 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id AAA04864 for ; Mon, 12 Jan 1998 00:12:16 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 12 Jan 1998 01:15:11 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id AAA23665; Mon, 12 Jan 1998 00:09:01 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 15476 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 12 Jan 1998 00:08:41 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id AAA10002 for ; Mon, 12 Jan 1998 00:02:16 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Mon, 12 Jan 1998 01:01:38 -0700 X-Mailer: Novell GroupWise 4.1 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Message-ID: Date: Mon, 12 Jan 1998 00:13:33 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Robert Jueneman Subject: Re: [IETF-PKIX] Is PKIX Patent-free? Comments: To: pbaker@VERISIGN.COM To: IETF-PKIX@LISTS.TANDEM.COM Status: I'm not entirely sure what you are asking, perhaps because I am rather ignorant of what the IESG's position is vis a vis patents and standards. Does the IESG insist on standards avoiding any existing patents? In that case, what do they do about RSA, etc? Does the IESG expect some company (Novell, Nortel, etc.) to take on the burden of examining some protocol and issuing a statement that said protocol does not infringe on their patent? I am reasonably certain that the IESG doesn't get involved in negotiating license agreements, so I would assume that they wouldn't ask for a company to waive its patent rights. Maybe we ought to hear from the Area Director on this issue. Bob >Bob Jueneman wrote: > >[details of Silvios patents deleted] > >Since you are Novell Bob, perhaps you could find out about the intention >and interpretation of the Novell patent? > >http://patent.womplex.ibm.com/details?patent_number=5687235 >5687235 : Certificate revocation performance optimization > >INVENTORS: > Perlman; Radia J., Acton, MA > Reed; Edwards E., Lindon, UT > Carter; Tammy G., Pleasant Grove, UT >ASSIGNEES: > Novell, Inc., Orem, UT >ISSUED: > Nov. 11, 1997 > > FILED: > Oct. 26, 1995 > >ABSTRACT: The present invention is an improved certificate revocation >process that improves the efficiency of an authentication exchange in a >public key distributed network system. Specifically, the present >invention includes a novel revocation service (RS) that, in response to >a unique request from a server node, selects certain revoked >certificates from a current CRL to include in its reply so as to consume >minimal system bandwidth > > >It would also be handy if someone from Entrust or Nortel could give some >information about their intentions concerning their CRL distribution >points patent. > > >Needless to say this is all going to have to be sorted out before the >IESG accepts the PKIX standards. From ???@??? Mon Jan 12 10:49:24 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id FAA12825 for ; Mon, 12 Jan 1998 05:10:45 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 12 Jan 1998 06:13:40 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id FAA05803; Mon, 12 Jan 1998 05:10:22 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 15662 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 12 Jan 1998 05:10:02 -0800 Received: from marcellus.cost.se ([195.100.88.66]) by Tandem.com (8.8.8/2.0.1) with ESMTP id EAA29329 for ; Mon, 12 Jan 1998 04:59:59 -0800 (PST) Received: from jimmie (Jimmie.cost.se [195.100.88.21]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id NAA07110 for ; Mon, 12 Jan 1998 13:57:12 +0100 (MET) X-Sender: nada@mail.cost.se X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.3.32.19980112140306.00b30b30@mail.cost.se> Date: Mon, 12 Jan 1998 14:03:06 +0100 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Nada Kapidzic Cicovic Subject: [IETF-PKIX] mandatory PasswordBasedMac To: IETF-PKIX@LISTS.TANDEM.COM Status: I have one more comment on the completeness of ipki3cmp document. In section "B2. Algorithm Use Profile", PasswordBasedMac is specified as mandatory algorithm for PKI message protection. As far as I understand, the reason for specifying mandatory algorithms is for easier interoperability between complying implementations. However, PasswordBasedMac (as specified in section "3.1.3 PKI Message Protection") is parametrized with a one-way-hash function and a MAC. For one-way-hash, SHA-1 is recommended, but for MAC different alternatives are given. Shouldn't the specification of mandatory algorithms make clear which algorithms should be used in place of the mentioned two parameters in PasswordBasedMac? What would be the preferable alternatives? Regards, Nada ______________________________________________________________ Nada Kapidzic Cicovic COST - Computer Security Technologies CST AB (subsidiary of Entegrity Solutions Corporation) office: + 46 (0)8 477 77 37 mobile: + 46 (0)70 495 09 03 fax: + 46 (0)8 477 77 31 e-mail: nada@cost.se or nada@entegrity.com address: Finlandsgatan 60, 164 74 Kista, Sweden From ???@??? Mon Jan 12 10:49:25 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA18765 for ; Mon, 12 Jan 1998 09:08:00 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 12 Jan 1998 10:10:57 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA20022; Mon, 12 Jan 1998 09:03:20 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 15764 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 12 Jan 1998 09:02:44 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by Tandem.com (8.8.8/2.0.1) with ESMTP id IAA22915 for ; Mon, 12 Jan 1998 08:52:41 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA18315; Mon, 12 Jan 1998 11:52:37 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <199801121652.LAA18315@ns.ietf.org> Date: Mon, 12 Jan 1998 11:52:32 -0500 Reply-To: Internet-Drafts@ns.ietf.org Sender: "IETF X.509-based public key infrastructure mailing list" From: Internet-Drafts@ns.ietf.org Subject: [IETF-PKIX] I-D ACTION:draft-ietf-pkix-ipki2opp-06.txt Comments: To: IETF-Announce@ns.ietf.org To: IETF-PKIX@LISTS.TANDEM.COM Status: 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) : T. Howes, S. Boeyen, P. Richard Filename : draft-ietf-pkix-ipki2opp-06.txt Pages : 12 Date : 09-Jan-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. 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-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki2opp-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: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ipki2opp-06.txt". NOTE: The mail server at ds.internic.net 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: <19980112114130.I-D@ietf.org> [This attachment must be fetched by mail. Open the stationery below and send the resulting message to get the attachment.] Attachment converted: Lutefisk:Get [IETF-PKIX] I-D ACTION-dr 1 (EuSn/CSOm) (0001DEA9) Content-Type: Message/External-body; name="draft-ietf-pkix-ipki2opp-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" [This attachment must be fetched by ftp. ÊOpen the document below to ask your ftp client to fetch it.] Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki2opp-06 (AURL/Arch) (0001DEAA) Content-Type: text/plain Content-ID: <19980112114130.I-D@ietf.org> From ???@??? Mon Jan 12 17:14:07 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id PAA28558 for ; Mon, 12 Jan 1998 15:37:12 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 12 Jan 1998 16:40:20 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id PAA25028; Mon, 12 Jan 1998 15:33:11 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 15911 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 12 Jan 1998 15:32:46 -0800 Received: from mail.mailbridge.net (securegate.orc.com [208.205.144.50]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA04521 for ; Mon, 12 Jan 1998 15:22:43 -0800 (PST) Received: from orc.com ([208.205.144.18]) by mail.mailbridge.net (Netscape Messaging Server 3.01) with ESMTP id AAA26273; Mon, 12 Jan 1998 18:17:32 -0500 X-Mailer: Mozilla 4.03 (Macintosh; U; 68K) MIME-Version: 1.0 References: <199712301828.NAA29494@jekyll.piermont.com> Content-Type: multipart/mixed; boundary="------------A775DE7DC2E8593804398C2F" Message-ID: <34BA9A55.230F382D@orc.com> Date: Mon, 12 Jan 1998 18:33:57 -0400 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Ronald Ogle Organization: Operational Research Consultants Inc. Subject: Re: [IETF-PKIX] Certificate Directories and Spam Comments: To: perry@PIERMONT.COM To: IETF-PKIX@LISTS.TANDEM.COM Status: Well, I don't know about that. You may be familiar with Caller ID on the telephone. With Caller ID, you can send the caller to a message stating that you will not answer the phone unless he/she publishes his/her phone number to your Caller ID service. Abstract this idea out to e-mail. If the e-mail sender does not sign the e-mail, then an e-mail is sent back stating that the recipient will not except unsigned e-mail. Also, you could have a filter based on the signature that would reject or at least but the e-mail in a location that was unobtrusive. So just like an unwanted phone call, an unwanted e-mail can now go into the perverbial bit bucket without human intervention. Perry E. Metzger wrote: > Andrew Csinger writes: > > Although somewhat off-topic, I think it's important to note in passing > > that > > > > PKI is ultimately the solution to the > > problem of SPAM, > > Not likely. Just because you can then verify that one of > Spamford Wallace's 7000 aliases sent the mail message doesn't mean it > does you any good to know where it came from. > > Perry Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ronald Ogle Content-Disposition: attachment; filename="vcard.vcf" Attachment converted: Lutefisk:vcard.vcf 3 (TEXT/R*ch) (0001DEBE) From ???@??? Tue Jan 13 11:08:06 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA21490 for ; Tue, 13 Jan 1998 08:34:56 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 13 Jan 1998 09:38:07 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id IAA19676; Tue, 13 Jan 1998 08:31:26 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 16078 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 13 Jan 1998 08:30:26 -0800 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by Tandem.com (8.8.8/2.0.1) with ESMTP id IAA11392 for ; Tue, 13 Jan 1998 08:30:24 -0800 (PST) Received: from [128.89.30.24] (ARA21.BBN.COM [128.89.30.21]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id LAA10221 for ; Tue, 13 Jan 1998 11:29:03 -0500 (EST) X-Sender: kent@po1.bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Date: Tue, 13 Jan 1998 11:29:03 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Stephen Kent Subject: Re: [IETF-PKIX] Is PKIX Patent-free? To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: Status: Bob, It is the IESG's position hat standards shouldm whenever possible, avoid the use of encumbered technology. So, for example, there was a big deal getting RSA to agree to allow R&D and educational use of the algorithm in PEM, long ago. More recently, the IESG insistend that the TLS WG make Diffie-Hellman and DSA the default algorithms for SSL, specifically to avoid RSA patent problems. So, the answers to your first question is that the IESG does want WGs to avoid use of patented technology if at all possible. If patented technology is incorporated into an IETF standard, then there must be a formal statement from the patent holders about non-discrimnatory licensing and non-onerous fees, or the IESG will reject the standard. Thus it is important that these issues be resolved prior to IESG submission. With regard to your second question, no, it is not incumbent on companies to review all IETF I-Ds and advise the IESG of possible patent overlaps. However, it is expected that WG members participating in the development of a standards, and who are aware of patents held by their company (or themeslves), will make the WG aware of such intellectual property issues in the course of standards development. At this point I am seriously considering asking the authors to delete portions of the relevent documents for which there may be patent problems, so that the documents can proceed to IESG approval. Steve From ???@??? Tue Jan 13 11:08:17 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA22988 for ; Tue, 13 Jan 1998 09:35:18 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 13 Jan 1998 10:38:27 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA25856; Tue, 13 Jan 1998 09:34:59 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 16179 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 13 Jan 1998 09:34:33 -0800 Received: from darkstar.bos.platsol.com (darkstar.bos.platsol.com [130.200.200.82]) by Tandem.com (8.8.8/2.0.1) with ESMTP id JAA23489 for ; Tue, 13 Jan 1998 09:34:27 -0800 (PST) Received: from hl_30.bos.platsol.com ([130.200.200.30]) by darkstar.bos.platsol.com (8.8.7/8.8.7) with SMTP id MAA01067 for ; Tue, 13 Jan 1998 12:34:22 -0500 X-Sender: hal@darkstar.bos.platsol.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) References: <199712301828.NAA29494@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.1.32.19980113123406.00738f00@darkstar.bos.platsol.com> Date: Tue, 13 Jan 1998 12:34:06 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Hal Lockhart Subject: Re: [IETF-PKIX] Certificate Directories and Spam To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: <34BA9A55.230F382D@orc.com> Status: At 06:33 PM 1/12/98 -0400, Ronald Ogle wrote: >Well, I don't know about that. You may be familiar with Caller ID on the >telephone. With Caller ID, you can send the caller to a message stating that >you will not answer the phone unless he/she publishes his/her phone number to >your Caller ID service. Abstract this idea out to e-mail. If the e-mail sender >does not sign the e-mail, then an e-mail is sent back stating that the recipient >will not except unsigned e-mail. Also, you could have a filter based on the >signature that would reject or at least but the e-mail in a location that was >unobtrusive. So just like an unwanted phone call, an unwanted e-mail can now go >into the perverbial bit bucket without human intervention. I am afraid I must agree with Perry. I don't think this approach will work for long or work for most people. Basically, you will have to either list who you will receive from (inclusion), or who you will NOT receive from (exclusion). In either case, you will soon be administering large unmanagable lists. Further, inclusion will exclude mail you really want. For example, I have frequently been contacted by old friends and acquaintences who saw my posting somewhere, or got my address from a mutual friend. Or consider the common case of starting a side discussion with another subscriber to a mailing list. Exclusion just puts you in the same old game of continous catch up with the spammers. As Perry points out, there is no reason to believe that they will not be able to obtain digital identities (certs) for their many and varied pseudonyms with the same level of assurance as your friends will get for their real identities. I am increasingly becoming convinced that any successful strategy against spam will have to be economic in nature. Other steps may temporarily slow them down, but are at best stopgap. >Perry E. Metzger wrote: > >> Andrew Csinger writes: >> > Although somewhat off-topic, I think it's important to note in passing >> > that >> > >> > PKI is ultimately the solution to the >> > problem of SPAM, >> >> Not likely. Just because you can then verify that one of >> Spamford Wallace's 7000 aliases sent the mail message doesn't mean it >> does you any good to know where it came from. Hal ================================================================= Harold W. Lockhart Jr. Platinum Solutions Inc. Chief Technical Architect 8 New England Executive Park Email: hal@platsol.com Burlington, MA 01803 USA Voice: (781)273-6406 Fax: (781)229-2969 ================================================================= From ???@??? Tue Jan 13 12:08:51 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA26781 for ; Tue, 13 Jan 1998 12:00:35 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 13 Jan 1998 12:02:59 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA03845; Tue, 13 Jan 1998 10:56:06 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 16278 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 13 Jan 1998 10:55:34 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA09855 for ; Tue, 13 Jan 1998 10:55:32 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id KAA05756; Tue, 13 Jan 1998 10:55:00 -0800 (PST) Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA11410; Tue, 13 Jan 1998 10:54:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Message-ID: <01bd2056$6e9867c0$9d07a8c0@pbaker-pc.verisign.com> Date: Tue, 13 Jan 1998 14:07:02 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Phillip M Hallam-Baker Subject: Re: [IETF-PKIX] Is PKIX Patent-free? Comments: To: Robert Jueneman To: IETF-PKIX@LISTS.TANDEM.COM Status: >I'm not entirely sure what you are asking, perhaps because I am rather >ignorant of what the IESG's position is vis a vis patents and standards. > >Does the IESG insist on standards avoiding any existing patents? In that >case, what do they do about RSA, etc? In general the IESG is very reluctant to approave any standard that does not meet their deffinition of 'open'. In particular they will in general insist that a specification be implementable using patent free technology wherever possible, PEM was a rare case in which they considered the RSA/Diffie Helleman patent essential. In any case whenever a protocol is encumbered in some way by a protocol they insist on an intellectual property statement and an undertaking to license the patent according to non discriminatory terms. >Does the IESG expect some company (Novell, Nortel, etc.) to take on the >burden of examining some protocol and issuing a statement that said protocol >does not infringe on their patent? The IESG cannot make such a requirement, but it does very much frown upon companies who are aware of pending patent claims failing to report them while being actively involved in the development of a specification. Of course there are many reasons for filing a patent besides wanting to exercise it. Many patents are filed in the US simply to stop the PTO issuing a patent to some smart Alex ten years later. >I am reasonably certain that the IESG doesn't get involved in negotiating >license agreements, so I would assume that they wouldn't ask for a company >to waive its patent rights. Bad assumption. They tend to simply insist that any patent encumbered technology be deleted from the draft prior to approving it. In IETF terms this is equivalent to 'Go straight to editing session, do not pass Go, do not collect $200'. It is not unusual for the alternatives to be offered in the form 'delete this from the spec or undertake to not enforce the patent on any party excepting a party which attempts to prevent you from using the patented property'. This is 'negotiation' of a form but a rather one sided one in that it consists of a unilateral ultimatum. Jeff Schiller, the security area director recently issued a series of similar ultimatums to the PGP and S/MIME groups where there were unsolved questions of intellectual property in the trademark area. This is why I raised the issue on the list. Until it is resolved we cannot get any of the drafts affected issued as RFCs. Phill From ???@??? Fri Jan 16 10:51:09 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id OAA29853 for ; Tue, 13 Jan 1998 14:07:03 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 13 Jan 1998 15:10:13 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id OAA22686; Tue, 13 Jan 1998 14:03:18 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 16384 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 13 Jan 1998 14:02:36 -0800 Received: from mail.mailbridge.net (securegate.orc.com [208.205.144.50]) by Tandem.com (8.8.8/2.0.1) with ESMTP id OAA13886 for ; Tue, 13 Jan 1998 14:02:32 -0800 (PST) Received: from orc.com ([208.205.144.18]) by mail.mailbridge.net (Netscape Messaging Server 3.01) with ESMTP id AAA29882 for ; Tue, 13 Jan 1998 16:57:25 -0500 X-Mailer: Mozilla 4.03 (Macintosh; U; 68K) MIME-Version: 1.0 References: <199801091535.KAA24494@argon.ncsc.mil> Content-Type: multipart/mixed; boundary="------------CD6412CDC35514AB7C26F989" Message-ID: <34BBD90E.69C6889B@orc.com> Date: Tue, 13 Jan 1998 17:13:52 -0400 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Ronald Ogle Organization: Operational Research Consultants Inc. Subject: Re: [IETF-PKIX] Cross-certification issues and terminology To: IETF-PKIX@LISTS.TANDEM.COM Status: David P. Kemp wrote: > > From: Bob Jueneman > > > > If you recall, you [Warwick] were the one who convinced me of the elegance of the > > policy OID constraint approach to certificate chaining, pointing out that it > > allowed the user himself, (or his IT organization) to create a certificate > > which effectively serves as his own local (unpublished) TLCA and > > cross-certifies other CAs, without requiring access to some kind of a local > > database of trusted CAs to validate each certificate. A suitable trusted > > smart card, a la Fortessa, containing a trusted public key or self-signed > > certifcate, could feasibly implement the relying party's trust policy > > without requiring a trusted operating system host. > ....... > We have been grappling with the problem of reconciling three PKI models > into a coherent concept of operations for a PKI to serve Federal Government > users: > * single-rooted heirarchy (DMS / MISSI v1), > * heirarchies interdomain-certified at the root level (IPsec/ANX, MISSI v2) > * single-level certification with each user configuring a list of > "trusted" CAs (the current web browser model) > Wouldn't there also be a case for inter-domain certification (point 2) at other subordinate "chained" CA levels and not just at the root level? For example, if you have a "Federal Root CA" that signs all other Government CAs, in this case the DoD CA, wouldn't you want the DoD CA to be able to inter-domain certify with other CA Roots instead of requiring the inter-domain certification to take place at the Federal Root CA. Just my opinion. Ron Ogle Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ronald Ogle Content-Disposition: attachment; filename="vcard.vcf" Attachment converted: Lutefisk:vcard.vcf 4 (TEXT/R*ch) (0001E0CA) From ???@??? Fri Jan 16 10:51:21 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id PAA32596 for ; Tue, 13 Jan 1998 15:52:35 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 13 Jan 1998 16:55:37 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id PAA04172; Tue, 13 Jan 1998 15:49:27 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 16486 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 13 Jan 1998 15:49:01 -0800 Received: from road-warrior-177.mit.edu (ROAD-WARRIOR-177.MIT.EDU [18.177.3.178]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA04987 for ; Tue, 13 Jan 1998 15:38:59 -0800 (PST) Received: from mit.edu (localhost [127.0.0.1]) by road-warrior-177.mit.edu (8.8.7/8.8.4) with ESMTP id SAA01181; Tue, 13 Jan 1998 18:38:51 -0500 X-Mailer: Mozilla 4.04 [en] (X11; U; Linux 2.0.30 i586) MIME-Version: 1.0 References: <01bd2056$6e9867c0$9d07a8c0@pbaker-pc.verisign.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms93D30E58A29AFEF427738210" Message-ID: <34BBFB08.8A2DB5DD@mit.edu> Date: Tue, 13 Jan 1998 18:38:48 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology Subject: Re: [IETF-PKIX] Is PKIX Patent-free? To: IETF-PKIX@LISTS.TANDEM.COM Status: Phillip M Hallam-Baker wrote: > >Does the IESG expect some company (Novell, Nortel, etc.) to take on the > >burden of examining some protocol and issuing a statement that said > protocol > >does not infringe on their patent? > > The IESG cannot make such a requirement, but it does very much frown > upon companies who are aware of pending patent claims failing to > report them while being actively involved in the development of a > specification. Indeed it is poor form for an individual to make contributions to a working group and after the group has adopted those recommendations, announce that the proposal is encumbered by that individual or the individuals company (and the individual was aware of the encumbrance at the time of suggestion). In other words, when you make a contribution to a WG, it is exactly that, a *contribution*. Some believe that because the patent application process is secret, that information about pending patents does not have to be revealed. This just isn't so. Although the patent process is secret, it is completely reasonable for the IETF to say "If you want to contribute a technology to a working group effort, then you must disclosure your interest." If you don't wish to disclose your interest, you don't have to make the suggestion! As for unilateral statements. I do not make decisions in a vacuum. I poled people individually at the Munich meeting to get the sense of the community about encumbered vs. unencumbered technologies (where a viable alternative was available). We then asked the plenary. The consensus was clear, the IETF favors unencumbered technologies. This is not an arbitrary decision of the IESG! -Jeff > > Of course there are many reasons for filing a patent besides wanting to > exercise it. Many patents are filed in the US simply to stop the PTO > issuing a patent to some smart Alex ten years later. > > >I am reasonably certain that the IESG doesn't get involved in negotiating > >license agreements, so I would assume that they wouldn't ask for a company > >to waive its patent rights. > > Bad assumption. > > They tend to simply insist that any patent encumbered technology > be deleted from the draft prior to approving it. In IETF terms this is > equivalent to 'Go straight to editing session, do not pass Go, do not > collect $200'. > > It is not unusual for the alternatives to be offered in the form 'delete > this from the spec or undertake to not enforce the patent on > any party excepting a party which attempts to prevent you from > using the patented property'. > > This is 'negotiation' of a form but a rather one sided one in that it > consists of a unilateral ultimatum. Jeff Schiller, the security area > director recently issued a series of similar ultimatums to the PGP > and S/MIME groups where there were unsolved questions of > intellectual property in the trademark area. > > This is why I raised the issue on the list. Until it is resolved we > cannot get any of the drafts affected issued as RFCs. > > Phill Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Attachment converted: Lutefisk:smime.p7s 29 (????/----) (0001E0CB) From ???@??? Fri Jan 16 10:51:32 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id XAA11825 for ; Tue, 13 Jan 1998 23:56:49 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 14 Jan 1998 00:59:49 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id XAA08525; Tue, 13 Jan 1998 23:56:31 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 16670 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 13 Jan 1998 23:55:53 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id XAA05376 for ; Tue, 13 Jan 1998 23:55:49 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Wed, 14 Jan 1998 00:55:12 -0700 X-Mailer: Novell GroupWise 4.1 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Message-ID: Date: Wed, 14 Jan 1998 00:09:20 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Robert Jueneman Subject: Re: [IETF-PKIX] Is PKIX Patent-free? Comments: To: kent@BBN.COM To: IETF-PKIX@LISTS.TANDEM.COM Status: Steve, thanks for the clarification. Unfortunately, I was unaware of the Novell patent that might or might not be involved in this particular instance, and so I can't even answer from a technical perspective whether or not the cited Novell patent might apply to the proposed standard, and if so how or to what degree. Until we can answer that question, of course, it is rather premature to discuss R&D or educational use, much less licensing terms. On the other hand, discriminatory and/or onerous terms are probably not the ideal way to win friends in this industry, so it is a pretty good bet that we wouldn't do that. Of course, I'm not an attorney, much less an intellectual property attorney, nor am I authorized to commit the company, etc., etc. So the answer, unfortunately, is that I will have to get back to you if you and/or the IESG feels that this is a substantive issue. Bob >>> Stephen Kent 01/13/98 09:29AM >>> Bob, It is the IESG's position hat standards shouldm whenever possible, avoid the use of encumbered technology. So, for example, there was a big deal getting RSA to agree to allow R&D and educational use of the algorithm in PEM, long ago. More recently, the IESG insistend that the TLS WG make Diffie-Hellman and DSA the default algorithms for SSL, specifically to avoid RSA patent problems. So, the answers to your first question is that the IESG does want WGs to avoid use of patented technology if at all possible. If patented technology is incorporated into an IETF standard, then there must be a formal statement from the patent holders about non-discrimnatory licensing and non-onerous fees, or the IESG will reject the standard. Thus it is important that these issues be resolved prior to IESG submission. With regard to your second question, no, it is not incumbent on companies to review all IETF I-Ds and advise the IESG of possible patent overlaps. However, it is expected that WG members participating in the development of a standards, and who are aware of patents held by their company (or themeslves), will make the WG aware of such intellectual property issues in the course of standards development. At this point I am seriously considering asking the authors to delete portions of the relevent documents for which there may be patent problems, so that the documents can proceed to IESG approval. Steve From ???@??? Fri Jan 16 10:53:07 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id HAA27717 for ; Thu, 15 Jan 1998 07:55:54 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 15 Jan 1998 08:58:53 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id HAA15844; Thu, 15 Jan 1998 07:53:48 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 16858 for IETF-PKIX@LISTS.TANDEM.COM; Thu, 15 Jan 1998 07:51:41 -0800 Received: from marconi (marconi.proteon.com [128.185.123.116] (may be forged)) by Tandem.com (8.8.8/2.0.1) with SMTP id HAA16874 for ; Thu, 15 Jan 1998 07:41:34 -0800 (PST) Received: from banacek.proteon.com by marconi (SMI-8.6/SMI-SVR4) id KAA13031; Thu, 15 Jan 1998 10:41:31 -0500 Received: by banacek.proteon.com (4.1/SMI-4.1) id AA14700; Thu, 15 Jan 98 10:41:42 EST X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <9801151541.AA14700@banacek.proteon.com> Date: Thu, 15 Jan 1998 10:41:41 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Gina DePlanche Subject: [IETF-PKIX] Looking for advise To: IETF-PKIX@LISTS.TANDEM.COM Status: Folks, Thank you to everyone who has given me pointers on reading material to get started. It has proven very helpful. I was looking to get some advice from the group to be sure I have everything I need. My company produces an edge router. From the reading I've done, it looks to me that I need to implement LDAP into our router and use it to verify the X.509 certificates received from remote peers. Is this too simplistic a view, or is this really all I need? If so, do I use RFC1778 or 1777? (I think it's 1778 but want to confirm) A couple of other questions I have: 1. How does my router get a certificate for local peers? Can it be done dynamically via the add operation of a ModifyRequest? 2. I am assuming the IP address and public key of a CA can be configured by the user. Is this correct? 3. Are there public CAs available for testing purposes? 4. Will there be many changes between LDAPv2 and LDAPv3? 5. Is there a workshop for X.509 compliant equipment to test for interoperability? (For example, There is an interoperability workshop for the PPP related protocols) Thanks in advance for the help! - Gina -- Gina M. DePlanche | OpenROUTE Networks, Inc. gmd@openroute.com | A subsidiary of Proteon, Inc. (508) 898-2800 x2541 | 9 Technology Drive, Westborough, MA Fax: (508) 836-5347 | 01581-1799 MailStop #23 From ???@??? Fri Jan 16 10:53:18 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA28950 for ; Thu, 15 Jan 1998 08:40:44 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 15 Jan 1998 09:43:44 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id IAA20003; Thu, 15 Jan 1998 08:36:05 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 16940 for IETF-PKIX@LISTS.TANDEM.COM; Thu, 15 Jan 1998 08:35:25 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id IAA25549 for ; Thu, 15 Jan 1998 08:35:22 -0800 (PST) Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD21A8.78419C30@mail.entrust.com>; Thu, 15 Jan 1998 11:26:49 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD21A8.78465720" Message-ID: Date: Thu, 15 Jan 1998 11:26:47 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Peter Whittaker Subject: Re: [IETF-PKIX] Looking for advise To: IETF-PKIX@LISTS.TANDEM.COM Status: Good questions. One quick note: you don't need LDAP at all to build a PKI. That LDAP is used in many PKIs has to do with its desirable characteristics as an access protocol into the directories that are used to support those PKIs. In those cases, LDAP is used only to obtain verification materials, such as certificates and revocation lists; it is not a necessary part of verification itself. > I was looking to get some advice from the group to be sure I >have everything I need. My company produces an edge router. From the >reading I've done, it looks to me that I need to implement LDAP into our >router and use it to verify the X.509 certificates received from remote >peers. Is this too simplistic a view, or is this really all I need? If >so, do I use RFC1778 or 1777? (I think it's 1778 but want to confirm) Do you need to use LDAP? No, not necessarily, that depends on how your system works.... > > A couple of other questions I have: > 1. How does my router get a certificate for local peers? This depends on the protocols used to establish connectios with local peers. If you are using GSSAPI, then the initial handshake transfers the certificate; this is the case with SPKM-1 and SPKM-2. Other protocols (such as IPSEC?) have different methods. > Can it be done dynamically via the add operation of a ModifyRequest? I wouldn't think so. I'm assuming that you are thinking of using LDAP to talk to a directory, and not to talk to another router. If so, then you would use a base object search and request that the appropriate attribute(s) (probably userCertificate) be returned. If you were thinking of using the LDAP modify request to write the certificate to the peer router, well, I wouldn't, because then the router has to implement an LDAP server side as well as client, and that's more work than you need. If your context establishment protocol does not include certificate exchange, you'll need to define a mechanism, one more efficient than LDAP. > 2. I am assuming the IP address and public key of a CA can be >configured by the user. Is this correct? Again, the answer is "that depends". That depends on your PKI model and trust architecture. You may not have a CA at all (PGP trust model). Or your software may have been configured with the IP address of the CA, and the CA gave your software a copy of its public key as part of initialization of your PKI identity (Entrust model, one possible IPKI model). In the latter case, if the peer router was certified by your CA, and your context establishment protocol provided for certificate exchange, then you'd only need a directory access protocol to obtain the revocation lists published by your CA, and then only if you used revocation lists. > 3. Are there public CAs available for testing purposes? Various groups, too numerous to mention, have established auto-responders and other infrastructure elements in support of testing their specifications. If you want to obtain certificates, there are many sources, some of which were recently mentioned in cert-talk: http://www.entrust.com/webca/index.htm http://www.darmstadt.gmd.de/ice-tel http://www.secude.com/trustfactory/ http://www.verisign.com/ To subscribe to cert-talk, see the attached message with subject "Announcing cert-talk". Since you are doing router work, I assume your interest is IPSEC. You might try contacting some IPSEC people. Their mailing list is at > 4. Will there be many changes between LDAPv2 and LDAPv3? Many changes. LDAPv3 does not mandate LDAPv2 support, and there isn't backwards compatibility. Your need for LDAPv3 vs LDAPv2 depends on what you are trying to do. Note that the PKIX group has created a profile for using LDAPv2 for repository (directory) access in an IPKI environment. An LDAPv3 profile will be forthcoming. In either case, you would need to become conversant with both protocols, but first you need to know why and whether you need LDAP at all. > 5. Is there a workshop for X.509 compliant equipment to test for >interoperability? (For example, There is an interoperability workshop for >the PPP related protocols) See the answer to question 3. At the risk of being accused of advertising, check out the Entrust web site for information on the Entrust/IPSEC Negotiator Toolkit. It may have some of the capabilities you desire. pww > >Peter Whittaker Entrust Key Validation Sequence: 7ORS-NGND-P6ZX >System Architect, SI mailto:pww@entrust.com Phone: +1 613 247 3485 >Entrust Technologies http://www.entrust.com Fax: +1 613 247 3401 > > From: "Thane E. Plambeck" To: "smime-dev@rsa.com" Cc: "IETF-PKIX@LISTS.TANDEM.COM" , "set-discuss@lists.Commerce.Net" Subject: Announcing the cert-talk X.509 mailing list Date: Wed, 10 Dec 1997 12:49:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Announcing cert-talk X.509 Digital Certificate Discussion List * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * CHARTER: The cert-talk mailing list is a public, unmoderated forum devoted to practical technical issues surrounding the use of X.509 certificates in public-key cryptography applications. SUBJECT MATTER: Topics of interest on cert-talk include, but are not limited to: * Practical problems and tools related to certificate manipulation: Import and export of certificates into applications Data extraction from certificates Certificate extension handling Compatibility of certificates across applications Revocation schemes Certificate storage schemes and APIs Distinguished name manipulation Certificate profiles and trust attributes Chain formation Signing and verification * Use of (and problems with) X.509 certificates with other public key technologies and networking standards such as: Secure Sockets Layer (SSL) and IETF TLS S/MIME secure electronic mail PKCS consortium standards SET (Secure Electronic Transactions) SKIP LDAP HOW DO I SUBSCRIBE TO CERT-TALK? The easiest method is to visit the URL http://mail.structuredarts.com/cert-talk/ Alternatively, send mail to the email address cert-talk-request@structuredarts.com with the body of the message containing the single word SUBSCRIBE You need not put any text in the subject of your message. Please do not send requests to the cert-talk list itself. ONCE I AM SUBSCRIBED, HOW TO I SEND MAIL TO CERT-TALK? Any mail addressed to will be sent to all members of the cert-talk mailing list. HOW DO I UNSUBSCRIBE FROM CERT-TALK? The easiest method is to visit the URL http://mail.structuredarts.com/cert-talk/ Alternatively, to remove your name from the cert-talk list send mail to the address cert-talk-request@structuredarts.com with the message body being the single word UNSUBSCRIBE. You need not put any text in the body of your message. Please do not send requests to the cert-talk list itself. FOR MORE INFORMATION: http://mail.structuredarts.com/cert-talk/ MAINTAINER: Structured Arts Computing Corporation 20111 Stevens Creek Blvd, Suite 145 Cupertino, California 95014-2345 http://www.structuredarts.com/ cert-talk-owner@structuredarts.com From ???@??? Fri Jan 16 10:53:08 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA28942 for ; Thu, 15 Jan 1998 08:39:07 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 15 Jan 1998 09:42:07 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id IAA20164; Thu, 15 Jan 1998 08:38:11 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 16956 for IETF-PKIX@LISTS.TANDEM.COM; Thu, 15 Jan 1998 08:37:33 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id IAA25837 for ; Thu, 15 Jan 1998 08:37:31 -0800 (PST) Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD21A8.D6BD1460@mail.entrust.com>; Thu, 15 Jan 1998 11:29:27 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BD21A8.D6C1F660" Message-ID: Date: Thu, 15 Jan 1998 11:29:26 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Peter Whittaker Subject: Re: [IETF-PKIX] Looking for advise To: IETF-PKIX@LISTS.TANDEM.COM Status: > >Sorry, I forgot the IPSEC ML address. >Good questions. One quick note: you don't need LDAP at all to build a PKI. >That LDAP is used in many PKIs has to do with its desirable characteristics >as an access protocol into the directories that are used to support those >PKIs. In those cases, LDAP is used only to obtain verification materials, >such as certificates and revocation lists; it is not a necessary part of >verification itself. > > I was looking to get some advice from the group to be sure I >have everything I need. My company produces an edge router. From the >reading I've done, it looks to me that I need to implement LDAP into our >router and use it to verify the X.509 certificates received from remote >peers. Is this too simplistic a view, or is this really all I need? If >so, do I use RFC1778 or 1777? (I think it's 1778 but want to confirm) > >Do you need to use LDAP? No, not necessarily, that depends on how your >system works.... > > A couple of other questions I have: > 1. How does my router get a certificate for local peers? > >This depends on the protocols used to establish connectios with local peers. >If you are using GSSAPI, then the initial handshake transfers the >certificate; this is the case with SPKM-1 and SPKM-2. Other protocols (such >as IPSEC?) have different methods. > > Can it be done dynamically via the add operation of a ModifyRequest? > >I wouldn't think so. I'm assuming that you are thinking of using LDAP to >talk to a directory, and not to talk to another router. If so, then you >would use a base object search and request that the appropriate attribute(s) >(probably userCertificate) be returned. > >If you were thinking of using the LDAP modify request to write the >certificate to the peer router, well, I wouldn't, because then the router has >to implement an LDAP server side as well as client, and that's more work than >you need. > >If your context establishment protocol does not include certificate exchange, >you'll need to define a mechanism, one more efficient than LDAP. > > 2. I am assuming the IP address and public key of a CA can be >configured by the user. Is this correct? > >Again, the answer is "that depends". That depends on your PKI model and >trust architecture. You may not have a CA at all (PGP trust model). Or your >software may have been configured with the IP address of the CA, and the CA >gave your software a copy of its public key as part of initialization of your >PKI identity (Entrust model, one possible IPKI model). In the latter case, >if the peer router was certified by your CA, and your context establishment >protocol provided for certificate exchange, then you'd only need a directory >access protocol to obtain the revocation lists published by your CA, and then >only if you used revocation lists. > > 3. Are there public CAs available for testing purposes? > >Various groups, too numerous to mention, have established auto-responders and >other infrastructure elements in support of testing their specifications. If >you want to obtain certificates, there are many sources, some of which were >recently mentioned in cert-talk: > > http://www.entrust.com/webca/index.htm > http://www.darmstadt.gmd.de/ice-tel > http://www.secude.com/trustfactory/ > http://www.verisign.com/ > >To subscribe to cert-talk, see the attached message with subject "Announcing >cert-talk". > >Since you are doing router work, I assume your interest is IPSEC. You might >try contacting some IPSEC people. Their mailing list is at >mailto:ipsec-request@tis.com > > 4. Will there be many changes between LDAPv2 and LDAPv3? > >Many changes. LDAPv3 does not mandate LDAPv2 support, and there isn't >backwards compatibility. > >Your need for LDAPv3 vs LDAPv2 depends on what you are trying to do. Note >that the PKIX group has created a profile for using LDAPv2 for repository >(directory) access in an IPKI environment. An LDAPv3 profile will be >forthcoming. > >In either case, you would need to become conversant with both protocols, but >first you need to know why and whether you need LDAP at all. > > 5. Is there a workshop for X.509 compliant equipment to test for >interoperability? (For example, There is an interoperability workshop for >the PPP related protocols) > >See the answer to question 3. > >At the risk of being accused of advertising, check out the Entrust web site >for information on the Entrust/IPSEC Negotiator Toolkit. It may have some of >the capabilities you desire. > >pww > > > >Peter Whittaker Entrust Key Validation Sequence: 7ORS-NGND-P6ZX >System Architect, SI mailto:pww@entrust.com Phone: +1 613 247 3485 >Entrust Technologies http://www.entrust.com Fax: +1 613 247 3401 > > > From: "Thane E. Plambeck" To: "smime-dev@rsa.com" Cc: "IETF-PKIX@LISTS.TANDEM.COM" , "set-discuss@lists.Commerce.Net" Subject: Announcing the cert-talk X.509 mailing list Date: Wed, 10 Dec 1997 12:49:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Announcing cert-talk X.509 Digital Certificate Discussion List * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * CHARTER: The cert-talk mailing list is a public, unmoderated forum devoted to practical technical issues surrounding the use of X.509 certificates in public-key cryptography applications. SUBJECT MATTER: Topics of interest on cert-talk include, but are not limited to: * Practical problems and tools related to certificate manipulation: Import and export of certificates into applications Data extraction from certificates Certificate extension handling Compatibility of certificates across applications Revocation schemes Certificate storage schemes and APIs Distinguished name manipulation Certificate profiles and trust attributes Chain formation Signing and verification * Use of (and problems with) X.509 certificates with other public key technologies and networking standards such as: Secure Sockets Layer (SSL) and IETF TLS S/MIME secure electronic mail PKCS consortium standards SET (Secure Electronic Transactions) SKIP LDAP HOW DO I SUBSCRIBE TO CERT-TALK? The easiest method is to visit the URL http://mail.structuredarts.com/cert-talk/ Alternatively, send mail to the email address cert-talk-request@structuredarts.com with the body of the message containing the single word SUBSCRIBE You need not put any text in the subject of your message. Please do not send requests to the cert-talk list itself. ONCE I AM SUBSCRIBED, HOW TO I SEND MAIL TO CERT-TALK? Any mail addressed to will be sent to all members of the cert-talk mailing list. HOW DO I UNSUBSCRIBE FROM CERT-TALK? The easiest method is to visit the URL http://mail.structuredarts.com/cert-talk/ Alternatively, to remove your name from the cert-talk list send mail to the address cert-talk-request@structuredarts.com with the message body being the single word UNSUBSCRIBE. You need not put any text in the body of your message. Please do not send requests to the cert-talk list itself. FOR MORE INFORMATION: http://mail.structuredarts.com/cert-talk/ MAINTAINER: Structured Arts Computing Corporation 20111 Stevens Creek Blvd, Suite 145 Cupertino, California 95014-2345 http://www.structuredarts.com/ cert-talk-owner@structuredarts.com From ???@??? Fri Jan 16 10:53:49 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id PAA07111 for ; Thu, 15 Jan 1998 15:50:07 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 15 Jan 1998 16:53:05 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id PAA02747; Thu, 15 Jan 1998 15:48:17 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 17170 for IETF-PKIX@LISTS.TANDEM.COM; Thu, 15 Jan 1998 15:47:36 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id PAA19045 for ; Thu, 15 Jan 1998 15:37:32 -0800 (PST) Received: tid SAA18705; Thu, 15 Jan 1998 18:32:13 -0500 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD21E3.6734FAA0@mail.entrust.com>; Thu, 15 Jan 1998 18:28:40 -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 Message-ID: Date: Thu, 15 Jan 1998 18:28:39 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Sharon Boeyen Subject: [IETF-PKIX] Re patent 5699431 & PKIX To: IETF-PKIX@LISTS.TANDEM.COM Status: U.S. patent 5699431 is on the topic of crl distribution points and as such is related to PKIX. CRL distribution points are an optional item in the PKIX certificate and crl profiles and I don't believe there is, or should be, anything on distribution points which is mandated by any part of the PKIX specifications. The patent was just issued in December and an intellectual property statement for submission to standards bodies, as required, is nearly complete. We do plan to make the technology covered by the patent available fairly and equitably. Apologies for the delay, however we believed that the disclosure was required at issuance, not application and that is why it is only being done now. Is there an IETF procedure or requirements specification related to this process so we can ensure that we follow it correctly? ------------------ Sharon Boeyen Entrust Technologies mailto:boeyen@entrust.com Tel: (613) 247-3181 http://www.entrust.com Fax: (613) 247-3690 Orchestrating Enterprise Security From ???@??? Fri Jan 16 10:53:58 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id RAA10125 for ; Thu, 15 Jan 1998 17:56:49 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 15 Jan 1998 18:59:49 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id RAA16288; Thu, 15 Jan 1998 17:57:16 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 17262 for IETF-PKIX@LISTS.TANDEM.COM; Thu, 15 Jan 1998 17:56:40 -0800 Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by Tandem.com (8.8.8/2.0.1) with ESMTP id RAA15939 for ; Thu, 15 Jan 1998 17:56:38 -0800 (PST) Received: from om.proper.com (om.proper.com [165.227.249.115]) by mail.proper.com (8.8.7/8.7.3) with SMTP id RAA21041 for ; Thu, 15 Jan 1998 17:52:13 -0800 (PST) X-Sender: paulh@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.5.32.19980115175515.007cd100@mail.imc.org> Date: Thu, 15 Jan 1998 17:55:15 -0800 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Paul Hoffman / IMC Subject: Re: [IETF-PKIX] Re patent 5699431 & PKIX To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: Status: RFC 2026 (aka BCP 9) has all the detail on this. Section 10.3.1, step 6, says: The contributor represents that he has disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the contributor. Section 10.3.2 specifies what kind of patent information must be made available before something can move onto standards track. If a company is known to have an applicable patent but has not come up with a patent statement, that company can hold up the process of getting the document on standards track (nudge, nudge). --Paul Hoffman, Director --Internet Mail Consortium From ???@??? Mon Jan 19 10:33:42 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id TAA17005 for ; Fri, 16 Jan 1998 19:58:36 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 16 Jan 1998 21:01:39 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id TAA22532; Fri, 16 Jan 1998 19:51:29 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 17442 for IETF-PKIX@LISTS.TANDEM.COM; Fri, 16 Jan 1998 19:49:49 -0800 Received: from davinci.netaxis.COM (davinci.netaxis.com [198.69.103.4]) by Tandem.com (8.8.8/2.0.1) with ESMTP id TAA12068 for ; Fri, 16 Jan 1998 19:39:46 -0800 (PST) Received: from earthlink.net (1Cust170.tnt26.atl2.da.uu.net [208.255.221.170]) by davinci.netaxis.COM (8.8.8/8.7.3) with SMTP id WAA28078; Fri, 16 Jan 1998 22:29:20 -0500 (EST) Received: from login_0120.cbec1ker.net (mail.cbec1ker.net[204.16.25.203]) by cbec1ker.net (8.8.5/8.7.3) with SMTP id XAA02133 for friendz@cbec1ker.net; Thu, 15 January 1998 22:43:02 -0700 (EDT) X-PMFLAGS: 20724340.54 X-UIDL: 20720340_206230.502 Message-ID: <43318271_77626514> Date: Fri, 16 Jan 1998 22:29:20 -0500 Reply-To: friendz@cbec1ker.net.wovenword.com Sender: "IETF X.509-based public key infrastructure mailing list" Comments: Authenticated Sender is From: go07@GO071D.NET.wovenword.com Subject: [IETF-PKIX] DEREGULATION OF THE U.S ELECTRIC UTILITY Comments: To: ur@on34.net To: IETF-PKIX@LISTS.TANDEM.COM Status: DEREGULATION OF THE U.S ELECTRIC UTILITY INDUSTRY IS CREATING A $215 BILLION FINANCIAL OPPORTUNITY FOR YOU! Imagine Utility Savings of 20% - 40%! now imagine being a marketer of those savings and earning a recurring monthly commission on the Utility usage of consumers throughout the country... <<<<< Call 1-800-358-2754 for 24 hr, 1 min message >>>>> __________________________________________________ Effective Jan '98, Electric Utility Monopolies will be dissolved on a State-by-State basis opening a $215 "Billion Dollar" industry to free-market competition. We need independent "Electric Power Marketers" in all 50 States especially California and the Northeast. Build a leveraged, recurring income in as little as 10-15 hours/week. full training and support; minimal start-up; lucrative. New Ground- Floor Opportunity with established international networking giant. Capitalize now on projected $10 Billion in annual revenue. People made millions with deregulation of the Telecommunications Industry. The Electric Utility Industry will be three times the opportunity. <<< Call 1-800-358-2754 for 24 hr, 1 min message >>> (Please do not reply via e-mail. Call our Voicemail and leave your name, telephone number and the best time to call and we will contact you as soon as possible) To be removed, call the above number and SPELL your email address stating you would like to be removed from future mailings. From ???@??? Mon Jan 19 10:33:49 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA08926 for ; Sun, 18 Jan 1998 10:02:46 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sun, 18 Jan 1998 11:05:52 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA24348; Sun, 18 Jan 1998 10:02:20 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 17653 for IETF-PKIX@LISTS.TANDEM.COM; Sun, 18 Jan 1998 10:00:33 -0800 Received: from POST.TANDEM.COM (post.mis.tandem.com [130.252.223.47]) by Tandem.com (8.8.8/2.0.1) with SMTP id KAA16253 for ; Sun, 18 Jan 1998 10:00:30 -0800 (PST) Received: by POST.TANDEM.COM (4.14/4.5) id AA7993; 18 Jan 98 10:05:31 -0800 Message-ID: <199801181005.AA7993@POST.TANDEM.COM> Date: Sun, 18 Jan 1998 10:03:00 -0800 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Jean Pawluk Subject: [IETF-PKIX] IETF-PKIX membership check Comments: cc: smptgate@Tandem.COM To: IETF-PKIX@LISTS.TANDEM.COM Status: In the never-ending battle to get the IETF-PKIX list up to date, I am sending this message to check the current membership data. Is anyone forwarding to a remailer using an old membership list? I remove people from this list and verify that they are gone, yet we still are receiving mail messages here saying that mail cannot be delivered to the people who have been removed. Well that is no surprise, except they have not been on this list for at least 6 weeks, so we are wondering if anyone was using remailers. Thanks Jeanne From ???@??? Mon Jan 19 10:34:10 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id HAA08876 for ; Mon, 19 Jan 1998 07:49:16 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 19 Jan 1998 08:52:25 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id HAA11811; Mon, 19 Jan 1998 07:47:45 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 17800 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 19 Jan 1998 07:47:42 -0800 Received: from darkstar.bos.platsol.com (darkstar.bos.platsol.com [130.200.200.82]) by Tandem.com (8.8.8/2.0.1) with ESMTP id HAA01826 for ; Mon, 19 Jan 1998 07:47:34 -0800 (PST) Received: from hl_30.bos.platsol.com ([130.200.200.30]) by darkstar.bos.platsol.com (8.8.7/8.8.7) with SMTP id KAA23586 for ; Mon, 19 Jan 1998 10:47:29 -0500 X-Sender: hal@darkstar.bos.platsol.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.1.32.19980119104600.0078fdb8@darkstar.bos.platsol.com> Date: Mon, 19 Jan 1998 10:46:00 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Hal Lockhart Subject: Re: [IETF-PKIX] Re patent 5699431 & PKIX To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: Status: At 06:28 PM 1/15/98 -0500, Sharon Boeyen wrote: >U.S. patent 5699431 is on the topic of crl distribution points and as >such is related to PKIX. > >CRL distribution points are an optional item in the PKIX certificate and >crl profiles and I don't believe there is, or should be, anything on >distribution points which is mandated by any part of the PKIX >specifications. I think it is important for some competent, disinterested party to look into this as soon as possible. I have not seen the patent, but I know that initial patents in a new field are usually worded quite broadly. The discussion in December on OCSP convinced me that, at least in the abstract, OCSP and traditional CRLs may be viewed as endpoints on a spectrum of configuration options for CRL distribution points. I hope no one will interpret this comment to mean that I suspect bad faith on the part of Entrust, quite the opposite. Hal ================================================================= Harold W. Lockhart Jr. Platinum Solutions Inc. Chief Technical Architect 8 New England Executive Park Email: hal@platsol.com Burlington, MA 01803 USA Voice: (781)273-6406 Fax: (781)229-2969 ================================================================= From ???@??? Tue Jan 20 14:33:24 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id HAA12635 for ; Tue, 20 Jan 1998 07:50:58 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 20 Jan 1998 08:54:15 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id HAA07757; Tue, 20 Jan 1998 07:46:20 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 17993 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 20 Jan 1998 07:45:33 -0800 Received: from webserver.interclear.co.uk (www.interclear.net [193.130.149.201]) by Tandem.com (8.8.8/2.0.1) with ESMTP id HAA07029 for ; Tue, 20 Jan 1998 07:35:25 -0800 (PST) Received: from jcp.co.uk ([10.1.1.106]) by webserver.interclear.co.uk (Netscape Mail Server v2.02) with ESMTP id AAA1227; Tue, 20 Jan 1998 15:37:24 +0000 X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <34C4C3B5.F42A1421@jcp.co.uk> Date: Tue, 20 Jan 1998 15:33:09 +0000 Reply-To: neil@comcan.demon.co.uk Sender: "IETF X.509-based public key infrastructure mailing list" From: Neil Hopcroft Subject: [IETF-PKIX] PolicyConstraints Extension To: IETF-PKIX@LISTS.TANDEM.COM Status: Looking at section 4.2.1.12 of PKIX Part 1 the ASN1 given appears not to be complete, and, on further investigation there appears also to be a problem with the coding in appendix A ("PolicyConstraints Syntax" not "PolicyConstraintsSyntax"), also, should there be some kind of reference to CertPolicySet? I have attempted to find some archives for this list but the reference to the FTP site on the IETF page is broken. Thanks for you help Neil From ???@??? Wed Jan 21 10:47:48 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA17448 for ; Wed, 21 Jan 1998 08:43:35 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 21 Jan 1998 09:46:48 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id IAA12342; Wed, 21 Jan 1998 08:40:46 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 18172 for IETF-PKIX@LISTS.TANDEM.COM; Wed, 21 Jan 1998 08:39:46 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id IAA01320 for ; Wed, 21 Jan 1998 08:39:40 -0800 (PST) Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD2660.02E3A070@mail.entrust.com>; Wed, 21 Jan 1998 11:30:44 -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 Message-ID: Date: Wed, 21 Jan 1998 11:30:42 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Carlisle Adams Subject: Re: [IETF-PKIX] request for change of CertRepContent To: IETF-PKIX@LISTS.TANDEM.COM Status: Hi Nada, >---------- >From: Nada Kapidzic Cicovic[SMTP:nada@COST.SE] >Sent: Thursday, January 08, 1998 5:22 AM >To: IETF-PKIX@LISTS.TANDEM.COM >Subject: [IETF-PKIX] request for change of CertRepContent > >I wonder if this is the right time to request a change in ipki3cmp format >of the certification response message (being in the final call stage), but >it seems to be lacking one very useful information: CRLs needed to verify >certificates contained in the message. > >The inclusion of CRLs would enable certificate verification software to >verify certificates without extra access to CRL repositories. The field can >be made optional, so that CAs are not required to keep CRLs after >publishing them, but in case they do keep CRLs this field may be used to >make certificate validation process faster. > >The suggested format of CertRepContent is the following: > > CertRepContent ::= SEQUENCE { > caPubs [0] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL, > -> crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL, > -- CRLs corresponding to caPubs and certificates in response > response SEQUENCE OF CertResponse > } > >Any comments? Given that extra certificates can also be carried in the extraCerts field of the PKIMessage structure, I'm not sure that CertRepContent is the ideal place to carry the CRL (if it is carried). My strong preference would be to carry it in the generalInfo field of the PKIHeader (recall that this is an optional sequence of InfoTypeAndValue and that one of the InfoTypeAndValue contents defined in Section 3.3.18 is CurrentCRL). -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- From ???@??? Wed Jan 21 10:47:48 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA17929 for ; Wed, 21 Jan 1998 08:55:21 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 21 Jan 1998 09:58:35 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id IAA13495; Wed, 21 Jan 1998 08:53:47 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 18208 for IETF-PKIX@LISTS.TANDEM.COM; Wed, 21 Jan 1998 08:54:06 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id IAA03882 for ; Wed, 21 Jan 1998 08:54:05 -0800 (PST) Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD2662.2A725B70@mail.entrust.com>; Wed, 21 Jan 1998 11:46:09 -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 Message-ID: Date: Wed, 21 Jan 1998 11:46:08 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Carlisle Adams Subject: Re: [IETF-PKIX] mandatory PasswordBasedMac To: IETF-PKIX@LISTS.TANDEM.COM Status: Hi Nada, >---------- >From: Nada Kapidzic Cicovic[SMTP:nada@COST.SE] >Sent: Monday, January 12, 1998 8:03 AM >To: IETF-PKIX@LISTS.TANDEM.COM >Subject: [IETF-PKIX] mandatory PasswordBasedMac > >I have one more comment on the completeness of ipki3cmp document. > >In section "B2. Algorithm Use Profile", PasswordBasedMac is specified as >mandatory algorithm for PKI message protection. As far as I understand, the >reason for specifying mandatory algorithms is for easier interoperability >between complying implementations. However, PasswordBasedMac (as specified >in section "3.1.3 PKI Message Protection") is parametrized with a >one-way-hash function and a MAC. For one-way-hash, SHA-1 is recommended, >but for MAC different alternatives are given. > >Shouldn't the specification of mandatory algorithms make clear which >algorithms should be used in place of the mentioned two parameters in >PasswordBasedMac? What would be the preferable alternatives? Good point (thanks for noticing this)! Yes, a particular OWF and MAC should be mandated for interoperability purposes. Unless there are any strong objections, I think the most sensible choices would be SHA-1 for the OWF (since it's already mandated as part of MSG_SIG_ALG) and Triple-DES-MAC [PKCS11] for the MAC (since 3-DES (3-key, EDE, CBC) is already mandated for SYM_PENC_ALG and PROT_SYM_ALG). I will add this to Appendix B2. Thanks again! -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- From ???@??? Wed Jan 21 12:21:32 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA22787 for ; Wed, 21 Jan 1998 12:08:59 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 21 Jan 1998 13:12:07 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA01232; Wed, 21 Jan 1998 12:05:28 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 18367 for IETF-PKIX@LISTS.TANDEM.COM; Wed, 21 Jan 1998 12:05:46 -0800 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by Tandem.com (8.8.8/2.0.1) with ESMTP id MAA10144 for ; Wed, 21 Jan 1998 12:05:44 -0800 (PST) Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id PAA19844; Wed, 21 Jan 1998 15:04:39 -0500 (EST) X-Sender: kent@po1.bbn.com Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Message-ID: Date: Wed, 21 Jan 1998 15:06:28 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Stephen Kent Subject: [IETF-PKIX] late meeting minutes Comments: To: Dixie Walker To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: <34BE2855.89ED4E87@ietf.org> Status: TimesPKIX WG Meeting Minutes (12/8+10/97) Approximately 360 attendees participated in the two PKIX WG session at the 40th IETF. Several of the PKIX I-Ds have been through working group last call and have moved on to the IESG for review, but a few issues remain and must be resolved prior to IESG approval and IETF last call. Part 1 (Certificate/CRL Profile) This draft completed WG last call, but a few issues remain to be resolved. Issues relating to use of algorithm OIDs and some ASN.1 errors have been resolved, and the authors have avoided inclusion of some legal language that was previously proposed. Unresolved issues: - There is disagreement about wildcarding in names (e.g., DNS and RFC 822). A small group met to resolve this issue after the (2nd) meeting. That group suggested disallowing use of asterisks in these name forms as a means of conveying the notion that the name was a place-holder for a set of names. Instead, a new document will be created to describe name form conventions, on a per-application context basis, with explicitly declared semantics, in support of the requirements that motivated use of wildcard name forms. - We are using '88 ASN.1, but BMP string is a new ASN.1 construct, so this is a technical matter (but does not affect bit on the wire format). - There is a related issue is use of UTF8, a new ('98 ASN.1) character set encoding, an alternative to BMP. This appears to be an issue at the IESG last call level of approval, but is not an issue among PKIX members. - For key usage, we propose to stay with what X.509 says, despite disagreements over whether it is the "right" interpretation. - Should CRLDistributionPoint be critical, non-critical, or at the discretion of the CA? Currently, it cannot be marked critical, but this can cause problems. The concern is that if marked critical, then a client without support for this would reject the certificate, even if the user was willing to ignore this extension, as required by X.509. Not resolved. Part 2 (split into LDAP, FTP, HTTP, OCSP) No problems with FTP or HTTP. LDAP v2 profile completed both last calls and is to be forwarded to IESG for approval. We agree to add a new work item to deal with v3, since current LDAP use in PKIX is based on v2. There was a suggestion to add a work item to develop a minimal schema for PKIX use of LDAP. This is a possible overlap with the LDAP WG, so coordination is required. Later during the week the LDAP WG chair was contacted and it was determined that creation of a schema for use with PKIX was within the purview of the PKIX WG. See slides for additional details. Part 3 (Certificate Management Protocol) No issues here other than the character set concerns raised under Part 1. Certificate Request Syntax (PKCS7/10 focus) A proposal was made to move work on this to S/MIME WG, and Schiller and Housley (S/MIME WG chair) have no objections. However, this work is not S/MIME-specific and several PKIX and S/MIME WG members believe that this work item should remain in PKIX, as it is more general. The fundamental question is whether CRS is a completely separate protocol, focused on S/MIME, or if it is a profile for Part 3. This was subsequently resolved [see below]. A straw poll of attendees showed a plurality of attendees in favor of keeping the work item in this WG, and only a single vote in favor of moving it to S/MIME. The S/MIME WG, meeting two days later, concurred with this and did not recommend adoption of CRS within that WG, assuming that PKIX would reconcile CRS/CMP differences and include a specification for securely transporting commonly-agreed certificate management messages over CMS (i.e., son of PKCS 7). At the second PKIX WG meeting, a compromise approach was announced, aimed at reconciling differences between CRS and CMP. In essence, a common certificate request message syntax was agreed upon, and CMP will adopt this syntax as the certificate request payload type within that protocol (replacing the current certificate request payload format). CRS also will be revised to reference that syntax. This new, harmonized certificate request format will appear as a separate RFC. It is not anticipated that this will delay the progression of CMP to proposed standard, since it is simply a protocol syntax change for alignment purposes, plus a splitting of one document into two in the interest of facilitating future developments. CRS will continue to progress, specifying the mapping of certificate management messages onto CMS and providing the vehicle for producing and RFC (or RFCs) that document agreed common formats for other certificate management messages (i.e., messages other than certificate request). Time-Stamping and Notary Protocols These are new, potential work items, discussed on a preliminary basis in Munich. Two presentations: Rob Zuccherato (Entrust) on time stamping and notary functions, and Stuart Haber (Surety) on time stamping. See slides for additional details. Entrust- Time stamping service described here deals exclusively with establishing existence of data (really a hash of data) at a point in time. Basic notary service for data demonstrates that a requester posses data (not just a hash of the data) at a given time. A certificate notary service requires validation of a certificate chain for the requester, including CRLs and ARLs. There is also a fancy data notarization service, encompassing data validity, and a combined service of data possession and validity. Some folks note that validation of data (and certificates) is outside the scope of what real world notaries do in the U.S. (but Latin Notaires do have broader functions). Surety- Stuart provided an overview of time stamping problem and solution space, with a focus on the hash tree technology developed (patented) and offered by Surety as a service. The current Surety service offers a 1 second granularity, At least one WG member argued that the notary and time stamping functions are not completely PKI-specific, and we should try to avoid duplication of efforts like the PKIX/SPKI situation. Another member noted that there is a new I-D for time stamping via NTP, that raises possible overlap concerns as well. One possible outcome is a split of time stamping vs. notary functions. Certificate path validation, a part of the described notary service, does make sense for PKIX, consistent with X.509 validation procedures. A straw poll during the second PKIX meeting showed a strong sentiment that this WG amend its charter to include development of a standard for time stamping, but there was not strong support for adding a work item to develop notary functions (other than certificate path validation). Thus an extension of the WG charter will be proposed to the IESG in order to address time stamping. OCSP Mike Myers provided a status review for this I-D, and responded to comments that have appeared on the WG list over the last few weeks. A number of modifications will be made as a result of these comments Mike described a schedule for revisions and (new) comments to bring OCSP to WG last call in time for the next (LA) IETF meeting. Included in the revisions will be a better characterization of the contexts in which OCSP are expected to operate, since that range of environments has grown since OCSP was initially designed. To better accommodate this diversity, a document structure was proposed that establishes a base OCSP document and syntax and one or more supplementary texts that build upon the base syntax, as noted above. From ???@??? Thu Jan 22 11:01:43 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id BAA11376 for ; Thu, 22 Jan 1998 01:58:52 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 22 Jan 1998 03:02:05 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id BAA21338; Thu, 22 Jan 1998 01:53:39 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 18564 for IETF-PKIX@LISTS.TANDEM.COM; Thu, 22 Jan 1998 01:53:56 -0800 Received: from marcellus.cost.se ([195.100.88.66]) by Tandem.com (8.8.8/2.0.1) with ESMTP id BAA11885 for ; Thu, 22 Jan 1998 01:43:54 -0800 (PST) Received: from jimmie (Jimmie.cost.se [195.100.88.21]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id KAA03868; Thu, 22 Jan 1998 10:40:57 +0100 (MET) X-Sender: nada@mail.cost.se X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.3.32.19980122104706.00b48100@mail.cost.se> Date: Thu, 22 Jan 1998 10:47:06 +0100 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Nada Kapidzic Cicovic Subject: Re: [IETF-PKIX] mandatory PasswordBasedMac To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: Status: At 11:46 1/21/98 -0500, Carlisle Adams wrote: >Hi Nada, > >>---------- >>From: Nada Kapidzic Cicovic[SMTP:nada@COST.SE] >>Sent: Monday, January 12, 1998 8:03 AM >>To: IETF-PKIX@LISTS.TANDEM.COM >>Subject: [IETF-PKIX] mandatory PasswordBasedMac >> >>I have one more comment on the completeness of ipki3cmp document. >> >>In section "B2. Algorithm Use Profile", PasswordBasedMac is specified as >>mandatory algorithm for PKI message protection. As far as I understand, the >>reason for specifying mandatory algorithms is for easier interoperability >>between complying implementations. However, PasswordBasedMac (as specified >>in section "3.1.3 PKI Message Protection") is parametrized with a >>one-way-hash function and a MAC. For one-way-hash, SHA-1 is recommended, >>but for MAC different alternatives are given. >> >>Shouldn't the specification of mandatory algorithms make clear which >>algorithms should be used in place of the mentioned two parameters in >>PasswordBasedMac? What would be the preferable alternatives? > >Good point (thanks for noticing this)! Yes, a particular OWF and MAC >should be mandated for interoperability purposes. > >Unless there are any strong objections, I think the most sensible >choices would be SHA-1 for the OWF (since it's already mandated as part >of MSG_SIG_ALG) and Triple-DES-MAC [PKCS11] for the MAC (since 3-DES >(3-key, EDE, CBC) is already mandated for SYM_PENC_ALG and >PROT_SYM_ALG). Well, HMAC-SHA-1 is also a valid and presumably much faster alternative to Triple-DES-MAC. If SHA-1 is mandatory for OWF, then HMAC-SHA-1 can be a natural choice for the MAC. BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does anybody have a pointer to some document specifying it? Regards, Nada > >I will add this to Appendix B2. Thanks again! > > >-------------------------------------------- >Carlisle Adams >Entrust Technologies >cadams@entrust.com >-------------------------------------------- > ______________________________________________________________ Nada Kapidzic Cicovic COST - Computer Security Technologies CST AB (subsidiary of Entegrity Solutions Corporation) office: + 46 (0)8 477 77 37 mobile: + 46 (0)70 495 09 03 fax: + 46 (0)8 477 77 31 e-mail: nada@cost.se or nada@entegrity.com address: Finlandsgatan 60, 164 74 Kista, Sweden From ???@??? Thu Jan 22 11:01:44 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id CAA12146 for ; Thu, 22 Jan 1998 02:37:23 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 22 Jan 1998 03:40:34 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id CAA22926; Thu, 22 Jan 1998 02:32:46 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 18630 for IETF-PKIX@LISTS.TANDEM.COM; Thu, 22 Jan 1998 02:33:04 -0800 Received: from marcellus.cost.se ([195.100.88.66]) by Tandem.com (8.8.8/2.0.1) with ESMTP id CAA14420 for ; Thu, 22 Jan 1998 02:23:02 -0800 (PST) Received: from jimmie (Jimmie.cost.se [195.100.88.21]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id LAA04013 for ; Thu, 22 Jan 1998 11:20:05 +0100 (MET) X-Sender: nada@mail.cost.se X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.3.32.19980122112614.00b47970@mail.cost.se> Date: Thu, 22 Jan 1998 11:26:14 +0100 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Nada Kapidzic Cicovic Subject: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: Carlisle, Thanks for replying to my previous messages. I the meantime I found one more strangeness in ipki3cmp: In 4.6.1 One-way request-response scheme of cross-certification, it is stated that all messages in this scheme (request/response/confirm) will be protected with a MAC based on a shared authentication code. However, Appendix B7 states that protection bits on these messages are to be calculated using MSG_SIG_ALG. I suppose that the proper way of protection of cross-certification messages is the one described in B7, and that section 4.6.1 should be modified accordingly. My additional question on second sentence in B7 is: why is publication of cross-certificate responsibility of requesting CA, and not of the issuing CA as in any other case? Regards, Nada From ???@??? Thu Jan 22 11:02:04 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA22132 for ; Thu, 22 Jan 1998 09:15:04 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 22 Jan 1998 10:18:07 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA14535; Thu, 22 Jan 1998 09:12:40 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 18765 for IETF-PKIX@LISTS.TANDEM.COM; Thu, 22 Jan 1998 09:12:16 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id JAA27005 for ; Thu, 22 Jan 1998 09:12:10 -0800 (PST) Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD272D.BAE17030@mail.entrust.com>; Thu, 22 Jan 1998 12:03: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 Message-ID: Date: Thu, 22 Jan 1998 12:03:18 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Carlisle Adams Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: Hi Nada, >---------- >From: Nada Kapidzic Cicovic[SMTP:nada@COST.SE] >Sent: Thursday, January 22, 1998 5:26 AM >To: IETF-PKIX@LISTS.TANDEM.COM >Subject: [IETF-PKIX] cross-certification > >Carlisle, > >Thanks for replying to my previous messages. I the meantime I found one >more strangeness in ipki3cmp: > >In 4.6.1 One-way request-response scheme of cross-certification, it is >stated that all messages in this scheme (request/response/confirm) will be >protected with a MAC based on a shared authentication code. >However, Appendix B7 states that protection bits on these messages are to >be calculated using MSG_SIG_ALG. > >I suppose that the proper way of protection of cross-certification messages >is the one described in B7, and that section 4.6.1 should be modified >accordingly. Actually, it's the other way around: 4.6.1 is correct and B7 should be modified to MSG_MAC_ALG. Thanks again for your careful reading. >My additional question on second sentence in B7 is: why is publication of >cross-certificate responsibility of requesting CA, and not of the issuing >CA as in any other case? Certainly, the certificate could be published by either side. However, a basic premise in this document is that the issuing CA (i.e., the one that actually creates and signs the certificate) has final authority over the certificate contents. Thus, an EE can put anything in the cert. template, but the CA is free to make any modifications that it likes. The same is true for the cross certification exchange. Note, though, that for this particular case it may be of slightly more importance that the requester fully approve of all the contents of the certificate before it gets published. It seemed to me that the simplest way to ensure this was to specify in no uncertain terms that the requester is the one responsible for publishing. -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- From ???@??? Thu Jan 22 11:54:57 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id LAA25408 for ; Thu, 22 Jan 1998 11:22:24 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Thu, 22 Jan 1998 12:25:40 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id LAA26288; Thu, 22 Jan 1998 11:16:01 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 18853 for IETF-PKIX@LISTS.TANDEM.COM; Thu, 22 Jan 1998 11:16:12 -0800 Received: from gatekeeper.bankamerica.com (gatekeeper.bankamerica.com [165.32.204.3]) by Tandem.com (8.8.8/2.0.1) with ESMTP id LAA22074 for ; Thu, 22 Jan 1998 11:16:11 -0800 (PST) Received: from iwww.bankamerica.com (iwww.bankamerica.com [165.32.203.11]) by gatekeeper.bankamerica.com (8.8.8/8.8.8) with ESMTP id LAA30439 for ; Thu, 22 Jan 1998 11:27:39 -0800 (PST) Received: from smtpsw01 (smtpsw01.bankamerica.com [165.32.203.30]) by iwww.bankamerica.com (8.8.5/8.8.5) with SMTP id LAA17207 for ; Thu, 22 Jan 1998 11:14:39 -0800 (PST) Alternate-recipient: Allowed Disclose-recipients: Prohibited Content-return: Allowed Content-identifier: 06BC834C79B42220 MIME-version: 1.0 Content-type: TEXT/PLAIN Conversion: Allowed Original-encoded-information-types: IA5-Text Priority: normal X400-Content-type: P2-1988 ( 22 ) X400-MTS-identifier: [/c=US/admd=attmail/; 06BC834C79B42220-attmail] X400-Originator: Mack.Hicks@BankAmerica.com X400-Recipients: non-disclosure; Message-ID: <01229811172500541000@bankamerica.com> Date: Thu, 22 Jan 1998 11:17:22 -0800 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Mack Hicks Subject: [IETF-PKIX] PKIX Part IV - CPCPSF - Number scheme Comments: To: Return requested To: IETF-PKIX@LISTS.TANDEM.COM Status: For: IETF-PKIX Mailing list As part of the NACHA Demonstrator for CA interoperability, the participant banks are putting together their Certificate Practice Stmts. During this process, some people noted that the IETF PKIX Part IV - CPCPSF is being often being used as an outline. For example, the American Bar Association ISC is using the "same numbering scheme" in their documents (or so I was so informed.) This is really good news. Relying parties could then look at a CP and CPS by examining known paragraphs for information regarding such things as key size and authentication mechanisms. My question: Is the numbering being used from the PART IV itself or from the suggested outline? Your CPCPSF numbering seems to be "slightly" different. Since Part IV is not a standard, but a reference doc (sorry - I have forgotten the exact name) - should there be a recommendation within PKIX that CP's and CPS's follow the numbering scheme? PS: NACHA Demonstrator - - - - - - - - - - - - - Mack Hicks (415) 278-7230 -- Interactive Banking Division 425 1st St m/s3671, SF CA 94105 From ???@??? Fri Jan 23 10:08:08 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id GAA21060 for ; Fri, 23 Jan 1998 06:08:12 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 23 Jan 1998 07:11:25 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id FAA10858; Fri, 23 Jan 1998 05:58:35 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 18987 for IETF-PKIX@LISTS.TANDEM.COM; Fri, 23 Jan 1998 05:58:31 -0800 Received: from cryptomathic.dk (cryptomathic.cryptomathic.dk [194.239.238.251]) by Tandem.com (8.8.8/2.0.1) with ESMTP id FAA28687 for ; Fri, 23 Jan 1998 05:48:24 -0800 (PST) Received: from cryptomathic.dk (midgaard.cryptomathic.dk [194.239.238.139]) by cryptomathic.dk (8.8.5/8.8.5) with ESMTP id OAA21360 for ; Fri, 23 Jan 1998 14:48:01 +0100 X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <34C89FCB.D4098528@cryptomathic.dk> Date: Fri, 23 Jan 1998 14:48:59 +0100 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Jakob Bjerre Jensen Subject: [IETF-PKIX] PKIX information flow ... To: IETF-PKIX@LISTS.TANDEM.COM Status: Dear PKIX-list. I have some questions, which I hope someone can answer: Consider the PKI-scenario consiting of 1. CA 2. RAs 3. a repository/directory 4. some End Entities Having read PKIX: Infrastructure Certificate Management Protocols, PKI Operational Protocols- LDAPv2 and RFC 1777 (LDAP) I am under the impression, that information flowing between the instances in such a PKI is done through the ASN.1 structure PKIMessage ::= SEQUENCE { header PKIHeader, body PKIBody, protection [0] PKIProtection OPTIONAL, extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL } and that information flowing between the repository/directory and end entities alternatively could be done through LDAPv2. Is this correct? Next: Does someone have experience with PKIX with information flow building on the above PKIMessage structure and/or LDAP (directory <--> end entities) ? - Jakob From ???@??? Fri Jan 23 10:08:11 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA25818 for ; Fri, 23 Jan 1998 09:22:59 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 23 Jan 1998 10:26:14 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA25441; Fri, 23 Jan 1998 09:17:31 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 19077 for IETF-PKIX@LISTS.TANDEM.COM; Fri, 23 Jan 1998 09:17:12 -0800 Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by Tandem.com (8.8.8/2.0.1) with ESMTP id JAA23586 for ; Fri, 23 Jan 1998 09:07:09 -0800 (PST) Received: by exchsvr1.entegrity.com with Internet Mail Service (5.0.1457.3) id ; Fri, 23 Jan 1998 09:10:00 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BD27DE.AEE2BD00" Message-ID: Date: Fri, 23 Jan 1998 09:09:59 -0800 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "Kesselman, Glenn A" Subject: [IETF-PKIX] Please add me to the mailing list To: IETF-PKIX@LISTS.TANDEM.COM Status: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BD27DE.AEE2BD00 Content-Type: text/plain Glenn A. Kesselman Director of Western Regional Sales Entegrity Solutions Corp. 2077 Gateway Place, Suite 200 San Jose, CA 95110 Voice: (408) 487-8600 ext. 117 Fax: (408) 487-8610 glenn@entegrity.com http://www.entegrity.com ------ =_NextPart_001_01BD27DE.AEE2BD00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Glenn A. = Kesselman          &nb= sp;           &nb= sp;           &nb= sp;     
Director of Western Regional Sales =
Entegrity Solutions Corp.
2077 Gateway Place, Suite 200
San Jose, CA = 95110           &= nbsp;           &= nbsp;           &= nbsp;        
Voice: (408) 487-8600 ext. = 117 
Fax: (408) 487-8610
glenn@entegrity.com      &n= bsp;       
http://www.entegrity.com

------ =_NextPart_001_01BD27DE.AEE2BD00-- From ???@??? Fri Jan 23 15:51:31 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id PAA02776 for ; Fri, 23 Jan 1998 15:38:55 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Fri, 23 Jan 1998 16:42:04 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id PAA04450; Fri, 23 Jan 1998 15:37:40 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 19185 for IETF-PKIX@LISTS.TANDEM.COM; Fri, 23 Jan 1998 15:37:42 -0800 Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by Tandem.com (8.8.8/2.0.1) with ESMTP id PAA06698; Fri, 23 Jan 1998 15:27:32 -0800 (PST) Received: from smtp.best.com (dynamic32.pm07.sf3d.best.com [209.24.235.160]) by proxy4.ba.best.com (8.8.8/8.8.BEST) with SMTP id PAA23197; Fri, 23 Jan 1998 15:16:25 -0800 (PST) Message-ID: <199801232316.PAA23197@proxy4.ba.best.com> Date: Fri, 23 Jan 1998 15:37:42 -0800 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: RPK New Zealand Ltd Subject: [IETF-PKIX] Announcement: RPK InvisiMail released on 12 Jan, 1998 To: IETF-PKIX@LISTS.TANDEM.COM Status: You have received this message because at some time during the past two years you have requested to be put on the RPK New Zealand Ltd. company mailing list. (We're the Fast Public Key Encryption company). If you wish to be removed from the list, please forward this message to remove@rpkusa.com -------------------------------- RPK New Zealand Ltd. in a joint venture with Virtually Online Ltd. has released RPK InvisiMail, a standards-based e-mail security application for use with Internet mail software (SMTP/POP3). The product offers the strongest encryption available anywhere in the world. Since it was built outside the United States, it is also available all over the world with strong encryption. RPK InvisiMail is also the easiest product of its type to setup and use which makes it quite unique. You can learn more about this product by reading the press release below or by visiting the web site at www.InvisiMail.com. We are also offering FREE downloads of the RPK InvisiMail Intro product. Please give it a try and pass it along to anyone you like. -------------------------------- For Immediate Release Contact: Sal Cataldi, Cataldi PR +1 212.941.9464, scataldi@earthlink.net, www.InvisiMail.com RPK InvisiMail(tm), secure Internet e-mail with globally available strong encryption for Microsoft, Netscape platforms SAN FRANCISCO, Jan. 12, 1998 - InvisiMail Ltd (www.InvisiMail.com) announced today immediate worldwide availability of RPK(tm) InvisiMail(tm), a standards-based e-mail security add-in for Microsoft, Netscape and other POP3/SMTP Internet e-mail clients and gateway servers. Tested and certified by the International Computer Security Association (www.ncsa.com), RPK InvisiMail automatically and transparently encrypts e-mail messages and attachments, authenticates the sender and verifies the contents of each message have not been changed in transit. RPK InvisiMail is globally available with high strength encryption. InvisiMail and the underlying RPK encryption algorithm were developed outside the United States. Therefore, InvisiMail is not subject to restrictive U.S. export policies. RPK InvisiMail is as easy to set up and use as anti-virus software, and just as important. While Microsoft and Netscape battle each other with incompatible and difficult to use security offerings, InvisiMail seamlessly integrates with ALL popular POP3/SMTP e-mail products including Netscape, Microsoft, Eudora, Pegasus, Calypso -- more than any other solution available today -- making it the preferred e-mail security product for multi-platform use, worldwide. All InvisiMail users can send the FREE InvisiMail Intro version to anyone worldwide, providing compatibility without requiring others to purchase anything, making InvisiMail unique among e-mail security offerings. "Most people don't realize that their e-mail can be forged, altered or read by anyone, any time, without any evidence," said Jack Oswald, President and CEO of RPK Ltd. "Without products like RPK InvisiMail, communications on the Internet are untrustworthy." InvisiMail uses the RPK Fast Public Key Encryptonite(tm) Engine, the strongest cryptography available worldwide today. RPK is dramatically faster than the well-known RSA algorithm, yet just as secure. RPK has been analyzed by world class cryptographers who have issued reports on the security and integrity of the technology. "InvisiMail is the easiest, fastest, most transparent e-mail security product I have seen," said Kevin Shannon, President of net*Gain, a specialist in launching Internet companies. "This is the product we've all been waiting for." As part of its official launch, InvisiMail Professional is available FREE to all New Zealand residents for ninety days. RPK InvisiMail is available in two desktop versions: Intro (FREE) and Professional (introductory price $29.95). RPK InvisiMail Enterprise Gateway Server will be available Q2 1998. InvisiMail can be downloaded from: www.InvisiMail.com. All trademarks and registered trademarks are those of their respective companies. *** From ???@??? Mon Jan 26 09:20:20 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id NAA03691 for ; Sat, 24 Jan 1998 13:51:01 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sat, 24 Jan 1998 14:54:16 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id NAA07462; Sat, 24 Jan 1998 13:50:40 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 19497 for IETF-PKIX@LISTS.TANDEM.COM; Sat, 24 Jan 1998 13:50:48 -0800 Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by Tandem.com (8.8.8/2.0.1) with ESMTP id NAA10747 for ; Sat, 24 Jan 1998 13:40:46 -0800 (PST) Received: from relay2.server.ibm.com (relay2.server.ibm.com [9.14.2.99]) by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id QAA71602 for ; Sat, 24 Jan 1998 16:40:53 -0500 Received: from US.IBM.COM (d04lms03.raleigh.ibm.com [9.37.164.195]) by relay2.server.ibm.com (8.8.7/8.7) with SMTP id QAA29596 for ; Sat, 24 Jan 1998 16:37:56 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU045 id 5040300011606270; Sat, 24 Jan 1998 16:38:13 -0500 MIME-Version: 1.0 Content-Type: text/plain Message-ID: <5040300011606270000002L002*@MHS> Date: Sat, 24 Jan 1998 16:38:13 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: D26NM061/26/M/IBM Subject: [IETF-PKIX] David Hemsath/Austin/IBM is out of the office. To: IETF-PKIX@LISTS.TANDEM.COM Status: I am out of the office from 01/24/98, returning 02/02/98. You will receive only this notification of my absence prior to my return, at which time I will respond. From ???@??? Mon Jan 26 09:20:19 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA02216 for ; Sat, 24 Jan 1998 12:53:47 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sat, 24 Jan 1998 13:57:04 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA05100; Sat, 24 Jan 1998 12:52:29 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 19413 for IETF-PKIX@LISTS.TANDEM.COM; Sat, 24 Jan 1998 12:51:32 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id MAA07899 for ; Sat, 24 Jan 1998 12:51:31 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id MAA06451; Sat, 24 Jan 1998 12:50:58 -0800 (PST) Received: from wford-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA08040; Sat, 24 Jan 1998 12:50:58 -0800 (PST) X-Sender: wford@mail.verisign.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.32.19980124153957.00688d24@mail.verisign.com> Date: Sat, 24 Jan 1998 16:03:19 -0800 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Warwick Ford Subject: Re: [IETF-PKIX] Is PKIX Patent-free? To: IETF-PKIX@LISTS.TANDEM.COM Status: Given Jeff's comments below, perhaps it is an appropriate time to invite all individuals/corporations participating in the PKIX work to inform us of any other patent filings or patents granted that might impact any of the PKIX projects. We can do without more surprises down the track. Warwick At 06:38 PM 1/13/98 -0500, Jeffrey I. Schiller wrote: >Indeed it is poor form for an individual to make contributions to a >working group and after the group has adopted those recommendations, >announce that the proposal is encumbered by that individual or the >individuals company (and the individual was aware of the encumbrance at >the time of suggestion). In other words, when you make a contribution to >a WG, it is exactly that, a *contribution*. > >Some believe that because the patent application process is secret, that >information about pending patents does not have to be revealed. This >just isn't so. Although the patent process is secret, it is completely >reasonable for the IETF to say "If you want to contribute a technology >to a working group effort, then you must disclosure your interest." If >you don't wish to disclose your interest, you don't have to make the >suggestion! > --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From ???@??? Mon Jan 26 09:20:25 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id WAA16331 for ; Sat, 24 Jan 1998 22:26:46 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sat, 24 Jan 1998 23:30:02 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id WAA25136; Sat, 24 Jan 1998 22:26:28 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 19651 for IETF-PKIX@LISTS.TANDEM.COM; Sat, 24 Jan 1998 22:26:33 -0800 Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by Tandem.com (8.8.8/2.0.1) with ESMTP id WAA06560 for ; Sat, 24 Jan 1998 22:16:31 -0800 (PST) Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id BAA21066 for ; Sun, 25 Jan 1998 01:16:30 -0500 (EST) Received: from lnsunr02.firstdata.com ([192.168.247.16]) by mailgw.FirstData.com with SMTP id BAA00544 for ; Sun, 25 Jan 1998 01:16:29 -0500 (EST) Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 85256597.002CA1DF ; Sun, 25 Jan 1998 01:16:44 -0500 X-Lotus-FromDomain: FDC Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: <88256597.00224B07.00@lnsunr02.firstdata.com> Date: Sat, 24 Jan 1998 22:14:34 -0800 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Lynn.Wheeler@FIRSTDATA.COM Subject: [IETF-PKIX] another characteristic of online validation. To: IETF-PKIX@LISTS.TANDEM.COM Status: Mack Hicks wrote: > I have to voice my agreement with Mike that cross-certification > is not manageable (technical banking term - "scary".)) > > An example, the trusted relationships between UNIX nodes. One can > make the point that the Rhost kind of trust is similar to the > cross-certification model. Rhost type of trust has done nothing > but get lots of people into lots and lots of trouble. > > Cross certification may look OK to field commanders in military > applications. Ya know -"Well that's Sam's group - he and I > played hockey together - Let's trust those guys." > > Some people think banks trust each other through their Am Bnks Ass > number (like on the checks). Anyone who has gotten a bounced check > knows this is not the case. Knowing the "naming" and "addressing" > (name constraints!) does not increase the level of trust. > > Keeping naming constraints current - or even manageable - is the > full time task for lots of people in the mainframe world. > Keeping that trust (usually in one place - like RACF or ACF2) > is a full time job that often goes horribly wrong. > > > So, for financial transactions, we are left with on-line status > verification. Is there any bank out there that wants to cross > certify? With whom? > > - - - - - - - - - - - - - > Mack Hicks (415) 278-7230 -- Interactive Banking Division > 425 1st St m/s3671, SF CA 94105 another characteristic we've been exploring with x9.59 and aads is the question of systemic risk introduced by inserting a dependency on some other agency when completing a transaction. imagine a financial institution with triple redundant implementation at three harden sites spread around the country ... and now having to go out over the internet and finding some CA operating in somebody's closet in order to complete a transaction. How many people would like to have "whether or not their paycheck got deposted in their bank account" dependent on if a http "hit" was succesful or not. for some of the discussion see http://www.garlic.com/~lynn/ From ???@??? Mon Jan 26 09:20:28 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA05448 for ; Sun, 25 Jan 1998 12:52:47 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sun, 25 Jan 1998 13:56:04 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA18644; Sun, 25 Jan 1998 12:52:02 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 19811 for IETF-PKIX@LISTS.TANDEM.COM; Sun, 25 Jan 1998 12:51:49 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id MAA10353 for ; Sun, 25 Jan 1998 12:51:48 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id MAA12460; Sun, 25 Jan 1998 12:51:15 -0800 (PST) Received: from wford-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id MAA29025; Sun, 25 Jan 1998 12:51:15 -0800 (PST) X-Sender: wford@mail.verisign.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.32.19980125145841.00766b5c@mail.verisign.com> Date: Sun, 25 Jan 1998 16:03:37 -0800 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Warwick Ford Subject: [IETF-PKIX] Cross Certification - Terminology To: IETF-PKIX@LISTS.TANDEM.COM Status: The thread on cross-certification terminology did not achieve much except to confirm that many people have different views on what "cross-certification" means and what needs to be done to address the subject area. We shall clearly not resolve all the issues here quickly, but there were some valuable contributions to start from. However, we need immediately to clarify or fix the usage of the term in PKIX 1 and CMP, since that is causing lots of confusion in the outside world. I see two simple alternatives, and feel we should adopt one of them before these documents are published as proposed standards: (a) Replace the term "cross-certificate" in PKIX 1 and CMP by the X.509-defined term "CA-certificate"; or (b) Explicitly define the term "cross-certificate" to be the same as the term "CA-certificate" (as defined in X.509). I know that not everyone agrees with (b). For that reason, I propose we do (a), but am willing to open this up to one last round of opinions. Warwick --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From ???@??? Mon Jan 26 09:20:29 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id RAA11857 for ; Sun, 25 Jan 1998 17:06:05 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sun, 25 Jan 1998 18:09:21 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id RAA26154; Sun, 25 Jan 1998 17:02:04 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 19929 for IETF-PKIX@LISTS.TANDEM.COM; Sun, 25 Jan 1998 17:01:39 -0800 Received: from fuji.iwsc.com (fuji.iwsc.com [209.75.25.17]) by Tandem.com (8.8.8/2.0.1) with ESMTP id QAA21551 for ; Sun, 25 Jan 1998 16:51:37 -0800 (PST) Received: from Default ([206.18.112.149]) by fuji.iwsc.com (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-41765U5000L500S0) with SMTP id AAA35300 for ; Sun, 25 Jan 1998 18:49:23 -0600 X-Mailer: NetMailer v1.0 (http://www.alphasoftware.com/netmailer) [C.R-DAA9AA49881DC41320E70E27CE1] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <199801260051.QAA21551@Tandem.com> Date: Sun, 25 Jan 1998 16:51:37 -0800 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. Comments: RFC822 error: Incorrect or incomplete address field found and ignored. Comments: RFC822 error: Incorrect or incomplete address field found and ignored. Comments: RFC822 error: Mail origin cannot be determined. Comments: RFC822 error: Original tag data was -> Brian Franks <> From: Undetermined origin c/o LISTSERV administrator Subject: [IETF-PKIX] Search Engines To: IETF-PKIX@LISTS.TANDEM.COM Status: I saw your web site on the internet. I work for a company that submits web sites to search engines. We can submit your web site to over 250 of the worlds best search engines for only $39.95! If you would like to put your web site in the fast lane and get more hits, call our 800# or see our web page for more information. Sincerely, Brian Franks NetWorld (800) 484-2621 X5568 From ???@??? Mon Jan 26 09:20:30 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id SAA13108 for ; Sun, 25 Jan 1998 18:00:44 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Sun, 25 Jan 1998 19:04:04 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id SAA28277; Sun, 25 Jan 1998 18:00:43 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 20031 for IETF-PKIX@LISTS.TANDEM.COM; Sun, 25 Jan 1998 18:00:45 -0800 Received: from ntdev.signet.org.au (ntdev.signet.org.au [139.130.64.197]) by Tandem.com (8.8.8/2.0.1) with ESMTP id SAA25433 for ; Sun, 25 Jan 1998 18:00:38 -0800 (PST) Received: from DEVELOP ([203.37.128.25]) by ntdev.signet.org.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id C53BLR1Y; Mon, 26 Jan 1998 12:01:16 +1000 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0005_01BD2A51.EBBCD2E0" 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 Message-ID: <000a01bd29fe$1ec7e250$198025cb@develop.signet.org.au> Date: Mon, 26 Jan 1998 11:59:55 +1000 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Charles Moore Subject: Re: [IETF-PKIX] Cross Certification - Terminology To: IETF-PKIX@LISTS.TANDEM.COM Status: -----Original Message----- From: Warwick Ford To: IETF-PKIX@LISTS.TANDEM.COM Date: Monday, 26 January 1998 7:25 Subject: [IETF-PKIX] Cross Certification - Terminology :The thread on cross-certification terminology did not achieve much except :to confirm that many people have different views on what :"cross-certification" means and what needs to be done to address the :subject area. We shall clearly not resolve all the issues here quickly, :but there were some valuable contributions to start from. : :However, we need immediately to clarify or fix the usage of the term in :PKIX 1 and CMP, since that is causing lots of confusion in the outside :world. Is it? : I see two simple alternatives, and feel we should adopt one of them :before these documents are published as proposed standards: : :(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the :X.509-defined term "CA-certificate"; or : :(b) Explicitly define the term "cross-certificate" to be the same as the :term "CA-certificate" (as defined in X.509). : :I know that not everyone agrees with (b). For that reason, I propose we do :(a), but am willing to open this up to one last round of opinions. If we must, I would suggest the following: Cross-Certificates CAs may cross-certify each other, that is each issue the other a certificate and combine the two certificates in a single directory attribute called a crossCertificatePair. This crossCertificatePair attribute, supports chains of trust that run in both directions and implement trust models that begin at the CA which issued the users certificate, rather than trust models where trust originates from a common ãrootä. A crossCertificatePair, includes two certificates, forward and reverse. The subject of the forward certificate is the issuer of the reverse certificate and vice-versa. Cross certificates provide a simple technical mechanism that may support a number of different policies, such policies are not subject to standardisation within PKIX. : :Warwick : :--------------------------------------------------------------------- :Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 : wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 :--------------------------------------------------------------------- : Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Attachment converted: Lutefisk:smime.p7s 33 (????/----) (0001E315) From ???@??? Mon Jan 26 09:20:33 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id BAA24497 for ; Mon, 26 Jan 1998 01:15:49 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 02:19:09 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id BAA14534; Mon, 26 Jan 1998 01:15:38 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 20262 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 01:15:40 -0800 Received: from marcellus.cost.se ([195.100.88.66]) by Tandem.com (8.8.8/2.0.1) with ESMTP id BAA20202 for ; Mon, 26 Jan 1998 01:05:38 -0800 (PST) Received: from jimmie (Jimmie.cost.se [195.100.88.21]) by marcellus.cost.se (8.8.5/8.7.5) with SMTP id KAA10216 for ; Mon, 26 Jan 1998 10:02:36 +0100 (MET) X-Sender: nada@mail.cost.se X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.3.32.19980126100847.00a6c3a0@mail.cost.se> Date: Mon, 26 Jan 1998 10:08:47 +0100 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Nada Kapidzic Cicovic Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: Status: At 12:03 1/22/98 -0500, you wrote: >Hi Nada, > >>---------- >>From: Nada Kapidzic Cicovic[SMTP:nada@COST.SE] >>Sent: Thursday, January 22, 1998 5:26 AM >>To: IETF-PKIX@LISTS.TANDEM.COM >>Subject: [IETF-PKIX] cross-certification >> >>Carlisle, >> .... >>My additional question on second sentence in B7 is: why is publication of >>cross-certificate responsibility of requesting CA, and not of the issuing >>CA as in any other case? > >Certainly, the certificate could be published by either side. However, >a basic premise in this document is that the issuing CA (i.e., the one >that actually creates and signs the certificate) has final authority >over the certificate contents. Thus, an EE can put anything in the >cert. template, but the CA is free to make any modifications that it >likes. The same is true for the cross certification exchange. Note, >though, that for this particular case it may be of slightly more >importance that the requester fully approve of all the contents of the >certificate before it gets published. It seemed to me that the simplest >way to ensure this was to specify in no uncertain terms that the >requester is the one responsible for publishing. > My concern is that requesting CA will not have enough privileges to publish the cross-certificate into issuing CA's directory. (This certificate should be published in issuing CA's directory, since it is intended to be used by end-entities in issuing CA's domain when verifying certificates from requester CA's domain.) Therefore, it seems more natural to have cross-certificate published by its issuer. Regards, Nada > >-------------------------------------------- >Carlisle Adams >Entrust Technologies >cadams@entrust.com >-------------------------------------------- > ______________________________________________________________ Nada Kapidzic Cicovic COST - Computer Security Technologies CST AB (subsidiary of Entegrity Solutions Corporation) office: + 46 (0)8 477 77 37 mobile: + 46 (0)70 495 09 03 fax: + 46 (0)8 477 77 31 e-mail: nada@cost.se or nada@entegrity.com address: Finlandsgatan 60, 164 74 Kista, Sweden From ???@??? Mon Jan 26 09:20:36 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id CAA25517 for ; Mon, 26 Jan 1998 02:02:25 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 03:05:46 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id CAA17409; Mon, 26 Jan 1998 02:02:09 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 20431 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 02:02:09 -0800 Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by Tandem.com (8.8.8/2.0.1) with ESMTP id BAA24062 for ; Mon, 26 Jan 1998 01:51:52 -0800 (PST) Received: from ntl11.research.kpn.com by research.kpn.com (PMDF V5.1-8 #18053) with SMTP id <01ISTW93N9LA000692@research.kpn.com> for ietf-pkix@tandem.com; Mon, 26 Jan 1998 10:52:57 +0200 Received: by ntl11.research.kpn.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD2A48.5E434240@ntl11.research.kpn.com>; Mon, 26 Jan 1998 10:51:34 +0100 MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Message-ID: Date: Mon, 26 Jan 1998 10:51:33 +0100 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "Hamming, J.E." Subject: [IETF-PKIX] Question To: IETF-PKIX@LISTS.TANDEM.COM Status: how do i remove myself from this list? From ???@??? Mon Jan 26 09:20:38 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id EAA29267 for ; Mon, 26 Jan 1998 04:35:13 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 05:38:23 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id EAA23428; Mon, 26 Jan 1998 04:34:28 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 20571 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 04:34:28 -0800 Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by Tandem.com (8.8.8/2.0.1) with ESMTP id EAA03021 for ; Mon, 26 Jan 1998 04:24:22 -0800 (PST) Received: by ntsiaexch.office with Internet Mail Service (5.0.1458.49) id ; Mon, 26 Jan 1998 13:24:46 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain X-MIME-Autoconverted: from quoted-printable to 8bit by Tandem.com id EAA03022 Message-ID: <8160937F4F4CD111A93E00805FC1752910EDC9@ntsiaexch.office> Date: Mon, 26 Jan 1998 13:24:45 +0100 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Santoni Adriano Subject: [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of "application" To: IETF-PKIX@LISTS.TANDEM.COM X-MIME-Autoconverted: from 8bit to quoted-printable by talia.mis.tandem.com id EAA23428 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sparky.wovenword.com id EAA29267 Status: Hi all. Sorry if this question has been asked before. Regarding the following excerpt from draft-ietf-pkix-ipki-part4-02... 4.1.3 Community and Applicability [cut] This subcomponent also contains: * A list of applications for which the issued certificates are suitable. * A list of applications for which use of the issued certificates is restricted. (This list implicitly prohibits all other uses for the certificates.) ...anybody wants to explain if the term "application" here means: * some specific software product (e.g. Netscape Navigator, Lotus Domino, etc.) * a generic software system category that accomplish some category of business needs (e.g. home banking, software publishing, digital signature of disk files, etc.) TIA to all volunteers, Adriano Ing. Adriano Santoni Direzione Rete - Servizio Progettazione Rete Logica Societˆ Interbancaria per l'Automazione - SIA S.p.A. Viale Certosa, 218 - I-20156 MIlano Vox: +39 2 3005 277 Fax: +39 2 38003333 Email: santoni@sia.it Website: http://www.sia.it From ???@??? Mon Jan 26 09:20:39 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id FAA30496 for ; Mon, 26 Jan 1998 05:23:27 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 06:26:48 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id FAA25319; Mon, 26 Jan 1998 05:23:25 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 20679 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 05:23:25 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id FAA05674 for ; Mon, 26 Jan 1998 05:13:24 -0800 (PST) Received: tid IAA20101; Mon, 26 Jan 1998 08:08:34 -0500 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD2A31.174F02A0@mail.entrust.com>; Mon, 26 Jan 1998 08:04:56 -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 Message-ID: Date: Mon, 26 Jan 1998 08:04:54 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Sharon Boeyen Subject: Re: [IETF-PKIX] Cross Certification - Terminology To: IETF-PKIX@LISTS.TANDEM.COM Status: I believe that removing the term cross-certification will do nothing more than add confusion to the situation. At the RSA conference last week, for example, I attended numerous sessions where the term cross-certification was used repeatedly and not once did I hear a question asking for clarification. We will only muddy the waters now if we try to change the term, or even worse, people reading our documents may interpret that PKIX doesn't address cross-certification. ------------------ Sharon Boeyen Entrust Technologies mailto:boeyen@entrust.com Tel: (613) 247-3181 http://www.entrust.com Fax: (613) 247-3690 Orchestrating Enterprise Security >---------- >From: Warwick Ford[SMTP:wford@VERISIGN.COM] >Sent: January 25, 1998 7:03 PM >To: IETF-PKIX@LISTS.TANDEM.COM >Subject: [IETF-PKIX] Cross Certification - Terminology > >The thread on cross-certification terminology did not achieve much except >to confirm that many people have different views on what >"cross-certification" means and what needs to be done to address the >subject area. We shall clearly not resolve all the issues here quickly, >but there were some valuable contributions to start from. > >However, we need immediately to clarify or fix the usage of the term in >PKIX 1 and CMP, since that is causing lots of confusion in the outside >world. I see two simple alternatives, and feel we should adopt one of them >before these documents are published as proposed standards: > >(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the >X.509-defined term "CA-certificate"; or > >(b) Explicitly define the term "cross-certificate" to be the same as the >term "CA-certificate" (as defined in X.509). > >I know that not everyone agrees with (b). For that reason, I propose we do >(a), but am willing to open this up to one last round of opinions. > >Warwick > >--------------------------------------------------------------------- >Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 > wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 >--------------------------------------------------------------------- > From ???@??? Mon Jan 26 09:20:40 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id FAA31233 for ; Mon, 26 Jan 1998 05:47:33 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 06:50:52 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id FAA26706; Mon, 26 Jan 1998 05:47:20 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 20745 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 05:47:21 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id FAA07491 for ; Mon, 26 Jan 1998 05:37:19 -0800 (PST) Received: tid IAA21343; Mon, 26 Jan 1998 08:33:12 -0500 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD2A34.8848A490@mail.entrust.com>; Mon, 26 Jan 1998 08:29:34 -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 Message-ID: Date: Mon, 26 Jan 1998 08:29:32 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Sharon Boeyen Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: Cross-certification can certainly occur either uni-laterally or bi-laterally. If CA A issues a cross cert for CA B, that cross cert can be published : a) by CA A as a forward cross-certificate in the cross-certificates attribute of CA A's entry; b) by CA B as a reverse cross-certificate in the cross-certificates attribute of CA B's entry; c) or both If the cross-certification is bi-lateral the reverse would apply to the cross-certificate issued by CA B for CA A. CA A should control what gets published/or not in its entry and CA B control what gets published/or not in its entry. Nada is correct that in no case should we expect that CA A have write permission to CA B's entry or vice versa. I do expect that some of these directory specific issues will get addressed in the PKIX LDAP schema specification that we agreed to pursue at the December meeting. For instance, we would want to make sure that cross-certificates are placed in the cross-certificates attribute and not the CA-certificate attribute. Another reason to maintain the term cross-certification and not confuse matters further. ------------------ Sharon Boeyen Entrust Technologies mailto:boeyen@entrust.com Tel: (613) 247-3181 http://www.entrust.com Fax: (613) 247-3690 Orchestrating Enterprise Security >---------- >From: Nada Kapidzic Cicovic[SMTP:nada@COST.SE] >Sent: January 26, 1998 4:08 AM >To: IETF-PKIX@LISTS.TANDEM.COM >Subject: Re: [IETF-PKIX] cross-certification > >At 12:03 1/22/98 -0500, you wrote: >>Hi Nada, >> >>>---------- >>>From: Nada Kapidzic Cicovic[SMTP:nada@COST.SE] >>>Sent: Thursday, January 22, 1998 5:26 AM >>>To: IETF-PKIX@LISTS.TANDEM.COM >>>Subject: [IETF-PKIX] cross-certification >>> >>>Carlisle, >>> >.... > >>>My additional question on second sentence in B7 is: why is publication of >>>cross-certificate responsibility of requesting CA, and not of the issuing >>>CA as in any other case? >> >>Certainly, the certificate could be published by either side. However, >>a basic premise in this document is that the issuing CA (i.e., the one >>that actually creates and signs the certificate) has final authority >>over the certificate contents. Thus, an EE can put anything in the >>cert. template, but the CA is free to make any modifications that it >>likes. The same is true for the cross certification exchange. Note, >>though, that for this particular case it may be of slightly more >>importance that the requester fully approve of all the contents of the >>certificate before it gets published. It seemed to me that the simplest >>way to ensure this was to specify in no uncertain terms that the >>requester is the one responsible for publishing. >> > >My concern is that requesting CA will not have enough privileges to publish >the cross-certificate into issuing CA's directory. (This certificate should >be published in issuing CA's directory, since it is intended to be used by >end-entities in issuing CA's domain when verifying certificates from >requester CA's domain.) > >Therefore, it seems more natural to have cross-certificate published by its >issuer. > >Regards, > >Nada > > >> >>-------------------------------------------- >>Carlisle Adams >>Entrust Technologies >>cadams@entrust.com >>-------------------------------------------- >> >______________________________________________________________ > >Nada Kapidzic Cicovic >COST - Computer Security Technologies CST AB >(subsidiary of Entegrity Solutions Corporation) >office: + 46 (0)8 477 77 37 >mobile: + 46 (0)70 495 09 03 >fax: + 46 (0)8 477 77 31 >e-mail: nada@cost.se or nada@entegrity.com >address: Finlandsgatan 60, 164 74 Kista, Sweden > From ???@??? Mon Jan 26 09:20:41 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id GAA32258 for ; Mon, 26 Jan 1998 06:36:38 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 07:39:51 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id GAA29609; Mon, 26 Jan 1998 06:32:31 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 20889 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 06:32:30 -0800 Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by Tandem.com (8.8.8/2.0.1) with ESMTP id GAA11995 for ; Mon, 26 Jan 1998 06:22:28 -0800 (PST) Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by thehub.knight-hub.com (8.8.8/8.8.8) with ESMTP id JAA16072 for ; Mon, 26 Jan 1998 09:22:26 -0500 Received: by WUHER with Internet Mail Service (5.0.1458.49) id ; Mon, 26 Jan 1998 09:18:27 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain X-MIME-Autoconverted: from quoted-printable to 8bit by Tandem.com id GAA11997 Message-ID: <51BF55C30B4FD1118B4900207812701E031B76@WUHER> Date: Mon, 26 Jan 1998 09:18:25 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Santosh Chokhani Subject: Re: [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of "application" To: IETF-PKIX@LISTS.TANDEM.COM X-MIME-Autoconverted: from 8bit to quoted-printable by talia.mis.tandem.com id GAA29609 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sparky.wovenword.com id GAA32258 Status: Example of Application in this case are: electronic mail, retail transactions, contracts, travel order, etc. I hope these examples clarify the term applications. > -----Original Message----- > From: Santoni Adriano [SMTP:santoni@SIA.IT] > Sent: Monday, January 26, 1998 7:25 AM > To: IETF-PKIX@LISTS.TANDEM.COM > Subject: [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of > "application" > > Hi all. Sorry if this question has been asked before. > > Regarding the following excerpt from draft-ietf-pkix-ipki-part4-02... > > 4.1.3 Community and Applicability > > [cut] > > This subcomponent also contains: > > * A list of applications for which the issued > certificates > are suitable. > > * A list of applications for which use of > the > issued > certificates is restricted. (This list implicitly > prohibits > all other uses for the certificates.) > > ...anybody wants to explain if the term "application" here means: > > * some specific software product (e.g. Netscape Navigator, Lotus > Domino, etc.) > * a generic software system category that accomplish some > category > of business needs (e.g. home banking, software publishing, digital > signature of disk files, etc.) > > TIA to all volunteers, > Adriano > > Ing. Adriano Santoni > Direzione Rete - Servizio Progettazione Rete Logica > Societˆ Interbancaria per l'Automazione - SIA S.p.A. > Viale Certosa, 218 - I-20156 MIlano > > Vox: +39 2 3005 277 > Fax: +39 2 38003333 > Email: santoni@sia.it > Website: http://www.sia.it From ???@??? Mon Jan 26 09:20:42 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id GAA32260 for ; Mon, 26 Jan 1998 06:36:39 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 07:40:12 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id GAA29715; Mon, 26 Jan 1998 06:33:28 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 20890 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 06:33:27 -0800 Received: from csai.telecomitalia.it (remo.csai.telecomitalia.it [151.99.133.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id GAA12071 for ; Mon, 26 Jan 1998 06:23:23 -0800 (PST) Received: from Mailhub by csai.telecomitalia.it with ESMTP id PAA26550 for ; Mon, 26 Jan 1998 15:09:01 +0100 (NFT) Received: from MailClients by Mailserver with SMTP id PAA18354 for ; Mon, 26 Jan 1998 15:21:34 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01BD2A6E.46B247E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Message-ID: <01bd2a65$e4eddfe0$56340a0a@Esposito.rmspina1> Date: Mon, 26 Jan 1998 15:22:55 +0100 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Antonio Esposito Subject: [IETF-PKIX] unsubscribe To: IETF-PKIX@LISTS.TANDEM.COM Status:
unsubscribe
From ???@??? Mon Jan 26 09:20:43 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id GAA32499 for ; Mon, 26 Jan 1998 06:38:57 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 07:42:31 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id GAA29874; Mon, 26 Jan 1998 06:35:16 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 20939 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 06:35:15 -0800 Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by Tandem.com (8.8.8/2.0.1) with ESMTP id GAA13147 for ; Mon, 26 Jan 1998 06:35:05 -0800 (PST) Received: by ntsiaexch.office with Internet Mail Service (5.0.1458.49) id ; Mon, 26 Jan 1998 15:35:32 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain X-MIME-Autoconverted: from quoted-printable to 8bit by Tandem.com id GAA13175 Message-ID: <8160937F4F4CD111A93E00805FC1752910EDCF@ntsiaexch.office> Date: Mon, 26 Jan 1998 15:35:30 +0100 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Santoni Adriano Subject: [IETF-PKIX] R: [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of "applica tion" To: IETF-PKIX@LISTS.TANDEM.COM X-MIME-Autoconverted: from 8bit to quoted-printable by talia.mis.tandem.com id GAA29874 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sparky.wovenword.com id GAA32499 Status: So you confirm my 2nd interpretation. Thank you. Adriano > -----Messaggio originale----- > Da: Santosh Chokhani [SMTP:chokhani@CYGNACOM.COM] > Inviato: luned“ 26 gennaio 1998 15.18 > A: IETF-PKIX@LISTS.TANDEM.COM > Oggetto: Re: [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning > of "application" > > Example of Application in this case are: electronic mail, retail > transactions, contracts, travel order, etc. I hope these examples > clarify the term applications. > > > -----Original Message----- > > From: Santoni Adriano [SMTP:santoni@SIA.IT] > > Sent: Monday, January 26, 1998 7:25 AM > > To: IETF-PKIX@LISTS.TANDEM.COM > > Subject: [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of > > "application" > > > > Hi all. Sorry if this question has been asked before. > > > > Regarding the following excerpt from > draft-ietf-pkix-ipki-part4-02... > > > > 4.1.3 Community and Applicability > > > > [cut] > > > > This subcomponent also contains: > > > > * A list of applications for which the issued > > certificates > > are suitable. > > > > * A list of applications for which use of > > the > > issued > > certificates is restricted. (This list > implicitly > > prohibits > > all other uses for the certificates.) > > > > ...anybody wants to explain if the term "application" here means: > > > > * some specific software product (e.g. Netscape Navigator, > Lotus > > Domino, etc.) > > * a generic software system category that accomplish some > > category > > of business needs (e.g. home banking, software publishing, digital > > signature of disk files, etc.) > > > > TIA to all volunteers, > > Adriano > > > > Ing. Adriano Santoni > > Direzione Rete - Servizio Progettazione Rete Logica > > Societˆ Interbancaria per l'Automazione - SIA S.p.A. > > Viale Certosa, 218 - I-20156 MIlano > > > > Vox: +39 2 3005 277 > > Fax: +39 2 38003333 > > Email: santoni@sia.it > > Website: http://www.sia.it From ???@??? Mon Jan 26 09:20:43 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id GAA32516 for ; Mon, 26 Jan 1998 06:42:16 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 07:45:41 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id GAA00445; Mon, 26 Jan 1998 06:41:54 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 20999 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 06:41:52 -0800 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id GAA14068 for ; Mon, 26 Jan 1998 06:41:46 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id JAA08379 for ; Mon, 26 Jan 1998 09:41:46 -0500 (EST) Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id JAA08375 for ; Mon, 26 Jan 1998 09:41:45 -0500 (EST) Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id JAA27979 for ; Mon, 26 Jan 1998 09:38:39 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id JAA03399; Mon, 26 Jan 1998 09:39:39 -0500 X-Sun-Charset: ISO-8859-1 Message-ID: <199801261439.JAA03399@argon.ncsc.mil> Date: Mon, 26 Jan 1998 09:39:39 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "David P. Kemp" Subject: Re: [IETF-PKIX] Cross Certification - Terminology To: IETF-PKIX@LISTS.TANDEM.COM Status: > From: Charles Moore > > If we must, I would suggest the following: > > Cross-Certificates > CAs may cross-certify each other, that is each issue the other a certificate > and combine the two certificates in a single directory attribute called a > crossCertificatePair. This crossCertificatePair attribute, supports chains > of trust that run in both directions and implement trust models that begin > at the CA which issued the users certificate, rather than trust models where > trust originates from a common “root”. A crossCertificatePair, includes two > certificates, forward and reverse. The subject of the forward certificate > is the issuer of the reverse certificate and vice-versa. Inter-domain certification is not necessarily bilateral, i.e. it does not always result in a crossCertificatePair. I favor Warwick's option (a): (a) Replace the term "cross-certificate" in PKIX 1 and CMP by the X.509-defined term "CA-certificate" From ???@??? Mon Jan 26 09:20:44 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA02021 for ; Mon, 26 Jan 1998 08:13:36 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 09:17:10 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id IAA08676; Mon, 26 Jan 1998 08:11:37 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 21303 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 08:11:36 -0800 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id IAA27411 for ; Mon, 26 Jan 1998 08:11:33 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA12540 for ; Mon, 26 Jan 1998 11:11:32 -0500 (EST) Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA12536 for ; Mon, 26 Jan 1998 11:11:32 -0500 (EST) Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id LAA28695 for ; Mon, 26 Jan 1998 11:08:27 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id LAA03425; Mon, 26 Jan 1998 11:09:26 -0500 X-Sun-Charset: US-ASCII Message-ID: <199801261609.LAA03425@argon.ncsc.mil> Date: Mon, 26 Jan 1998 11:09:26 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "David P. Kemp" Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: Sharon, If CA A issues a certificate for CA B, what criteria are used to decide if it is a cross-certificate or a CA-certificate? Defining the distinction to be "if it's published in a cross-certificate directory attribute, then it's a cross-certificate" seems tautological - if there is no other distinction then there is no need for the two different types of directory attributes. It seems clear to me that the distinction must be based on Tim Moses' concepts of "subject community" and "relying party community" - if those communities are identical then the cert is a CA cert, if the resulting communities are not identical then it is a cross-cert. But that just shifts the problem from defining "cross-certificate" to defining "subject community". If we could come up with a simple and consensus-agreed definition which could be quickly inserted into CMP, that would be ideal. Can you write such a definition? (I can't.) In the meantime, I agree with you that there appears to be a meaningful difference between a CA-cert and a cross-cert, even if we can't define what it is. For that reason, I agree that it would be undesirable to change "cross-certificate" to "CA-certificate" in PKIX documents. Option (a) was better than option (b), but doing nothing is better still. Dave Kemp > From: Sharon Boeyen > > Cross-certification can certainly occur either uni-laterally or > bi-laterally. > > If CA A issues a cross cert for CA B, that cross cert can be published > : > a) by CA A as a forward cross-certificate in the cross-certificates > attribute of CA A's entry; > b) by CA B as a reverse cross-certificate in the cross-certificates > attribute of CA B's entry; > c) or both > If the cross-certification is bi-lateral the reverse would apply to the > cross-certificate issued by CA B for CA A. > > CA A should control what gets published/or not in its entry and CA B > control what gets published/or not in its entry. Nada is correct that in > no case should we expect that CA A have write permission to CA B's entry > or vice versa. > > I do expect that some of these directory specific issues will get > addressed in the PKIX LDAP schema specification that we agreed to pursue > at the December meeting. For instance, we would want to make sure that > cross-certificates are placed in the cross-certificates attribute and > not the CA-certificate attribute. > > Another reason to maintain the term cross-certification and not confuse > matters further. > > ------------------ > Sharon Boeyen > Entrust Technologies From ???@??? Mon Jan 26 09:20:32 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id BAA24249 for ; Mon, 26 Jan 1998 01:06:15 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 02:09:29 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id BAA13898; Mon, 26 Jan 1998 01:03:30 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 20244 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 01:03:29 -0800 Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.17]) by Tandem.com (8.8.8/2.0.1) with ESMTP id AAA19439 for ; Mon, 26 Jan 1998 00:53:22 -0800 (PST) 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 JAA18384 for ; Mon, 26 Jan 1998 09:07:46 +0100 Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (8.7.5/8.7.3) with SMTP id JAA31634 for ; Mon, 26 Jan 1998 09:12:58 +0100 X-Mailer: Mozilla 3.01 [fr] (Win16; I) MIME-Version: 1.0 References: <000a01bd29fe$1ec7e250$198025cb@develop.signet.org.au> Content-Type: text/plain Message-ID: <34CCC410.6E8C@bull.net> Date: Mon, 26 Jan 1998 09:12:48 -0800 Reply-To: Denis.Pinkas@bull.net Sender: "IETF X.509-based public key infrastructure mailing list" From: Denis Pinkas Organization: Bull Subject: Re: [IETF-PKIX] Cross Certification - Terminology To: IETF-PKIX@LISTS.TANDEM.COM X-MIME-Autoconverted: from 8bit to quoted-printable by talia.mis.tandem.com id BAA13898 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sparky.wovenword.com id BAA24249 Status: Warwick Ford wrote: :The thread on cross-certification terminology did not achieve much except :to confirm that many people have different views on what :"cross-certification" means and what needs to be done to address the :subject area. We shall clearly not resolve all the issues here quickly, :but there were some valuable contributions to start from. : :However, we need immediately to clarify or fix the usage of the term in :PKIX 1 and CMP, since that is causing lots of confusion in the outside :world. : : I see two simple alternatives, and feel we should adopt one of them :before these documents are published as proposed standards: : :(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the :X.509-defined term "CA-certificate"; or This seems reasonable. However, seeing how would look the text (only for the sections where the word is used) would be nice before a complete new draft is re-issued. :(b) Explicitly define the term "cross-certificate" to be the same as the :term "CA-certificate" (as defined in X.509). : :I know that not everyone agrees with (b). For that reason, I propose we do :(a), but am willing to open this up to one last round of opinions. Charles Moore wrote: > If we must, I would suggest the following: > > Cross-Certificates > CAs may cross-certify each other, I fear you are re-opening an issue that I thought to be closed. Cross-certification is one way, not necessarilly bi-lateral. > that is each issue the other a certificate > and combine the two certificates in a single directory attribute called a > crossCertificatePair. This crossCertificatePair attribute, supports chains > of trust that run in both directions and implement trust models that begin > at the CA which issued the users certificate, rather than trust models where > trust originates from a common ãrootä. A crossCertificatePair, includes two > certificates, forward and reverse. The subject of the forward certificate > is the issuer of the reverse certificate and vice-versa. I do not agree with the above. Warwick is pretty right when he says "many people have different views on what "cross-certification" means. :-) Denis -- *** Please note that the E-mail address has changed ! Update it. *** Denis Pinkas Bull S.A. E-mail : 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 From ???@??? Mon Jan 26 10:03:55 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA04556 for ; Mon, 26 Jan 1998 09:55:54 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 10:59:16 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA18573; Mon, 26 Jan 1998 09:51:40 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 21472 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 09:51:38 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id JAA15499 for ; Mon, 26 Jan 1998 09:51:36 -0800 (PST) Received: tid MAA19122; Mon, 26 Jan 1998 12:46:50 -0500 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD2A57.F6F98170@mail.entrust.com>; Mon, 26 Jan 1998 12:43:13 -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 Message-ID: Date: Mon, 26 Jan 1998 12:43:10 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Carlisle Adams Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: Hi Dave, Let's try this... >---------- >From: David P. Kemp[SMTP:dpkemp@MISSI.NCSC.MIL] >Sent: Monday, January 26, 1998 11:09 AM >To: IETF-PKIX@LISTS.TANDEM.COM >Subject: Re: [IETF-PKIX] cross-certification > >Sharon, > >If CA A issues a certificate for CA B, what criteria are used to >decide if it is a cross-certificate or a CA-certificate? > >Defining the distinction to be "if it's published in a >cross-certificate directory attribute, then it's a cross-certificate" >seems tautological - if there is no other distinction then there is no >need for the two different types of directory attributes. Agreed; this is hardly a useful definition. >It seems clear to me that the distinction must be based on Tim Moses' >concepts of "subject community" and "relying party community" - >if those communities are identical then the cert is a CA cert, >if the resulting communities are not identical then it is a cross-cert. >But that just shifts the problem from defining "cross-certificate" >to defining "subject community". Here is a proposal. Subject: a subject of a CA is an entity that is identified by the subject field of a certificate issued by that CA. Relying Party: a relying party of a CA is an entity that validates certificate chains using the public key of that CA as an end-point (i.e., a trust anchor). Given these definitions, I would argue that if the "subject community" and the "relying party community" are identical, then the cert is not simply a certificate in which the subject and issuer are CAs, but a "self-signed CA cert" in which the subject and issuer are the *same* CA (since only a single CA can have this property). If the communities are not identical (as is the case by definition when the subject and issuer CAs are distinct), then the cert is a "cross-certificate". This is really the definition of cross-certification implied by PKIX-1 and CMP ("any case of issuance of a certificate by one CA for another", as Warwick put it), primarily because this is the definition implied by X.509 itself where terms like CA-Certificate, CertificationPath, CertificatePair, and CrossCertificates are all used in the same context (that of constructing chains of certificates from a relying party to a subject through an arbitrary set of distinct CAs). See for example Warwick's book "Computer Communications Security", p.389. See also Menezes, et al, "Handbook of Applied Cryptography", p.572, where CA-certificate and cross-certificate are defined synonymously. The point here is that *any* two CAs have different subject and relying communities, regardless of whether they are in the same organizational structure or different organizational structures, regardless of whether they exist in the same hierarchy or different hierarchies or no hierarchies at all. Therefore, if they engage in unilateral or mutual certification, the result is a cross-certificate (or a pair of cross-certificates). >If we could come up with a simple and consensus-agreed definition >which could be quickly inserted into CMP, that would be ideal. >Can you write such a definition? (I can't.) Comments on the above? >In the meantime, I agree with you that there appears to be a meaningful >difference between a CA-cert and a cross-cert, even if we can't define >what it is. For that reason, I agree that it would be undesirable >to change "cross-certificate" to "CA-certificate" in PKIX documents. >Option (a) was better than option (b), but doing nothing is better >still. If by "CA-cert" in the previous paragraph you mean "what goes into the CA-certificate attribute for CA X's directory entry", then I think it only makes sense for this to be CA X's self-signed certificate. -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- From ???@??? Mon Jan 26 09:51:49 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id JAA04295 for ; Mon, 26 Jan 1998 09:44:47 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 10:48:21 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id JAA17341; Mon, 26 Jan 1998 09:39:11 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 21436 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 09:39:02 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id JAA13004 for ; Mon, 26 Jan 1998 09:39:01 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id JAA21014; Mon, 26 Jan 1998 09:38:29 -0800 (PST) Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA23849; Mon, 26 Jan 1998 09:38:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Message-ID: <01bd2a82$f2489500$9d07a8c0@pbaker-pc.verisign.com> Date: Mon, 26 Jan 1998 12:50:53 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Phillip M Hallam-Baker Subject: Re: [IETF-PKIX] Cross Certification - Terminology To: IETF-PKIX@LISTS.TANDEM.COM Status: >I believe that removing the term cross-certification will do nothing >more than add confusion to the situation. At the RSA conference last >week, for example, I attended numerous sessions where the term >cross-certification was used repeatedly and not once did I hear a >question asking for clarification That is not necessarily a good thing. I have been to conferences at which the term 'Object Oriented' has been used by almost every speaker, in most cases as a synonym for 'modern'. The purpose of a specification is to make the most precise statement possible about a protocol. Terms that have been discovered by marketing tend to rapidly become meaningless. Phill From ???@??? Mon Jan 26 10:48:33 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA05069 for ; Mon, 26 Jan 1998 10:12:42 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 11:16:15 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA20485; Mon, 26 Jan 1998 10:09:38 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 21552 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 10:09:34 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA18947 for ; Mon, 26 Jan 1998 10:09:33 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id KAA21678; Mon, 26 Jan 1998 10:09:01 -0800 (PST) Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA25669; Mon, 26 Jan 1998 10:08:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Message-ID: <01bd2a87$2767af60$9d07a8c0@pbaker-pc.verisign.com> Date: Mon, 26 Jan 1998 13:21:00 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Phillip M Hallam-Baker Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: >Sharon, > >If CA A issues a certificate for CA B, what criteria are used to >decide if it is a cross-certificate or a CA-certificate? > >Defining the distinction to be "if it's published in a >cross-certificate directory attribute, then it's a cross-certificate" >seems tautological - if there is no other distinction then there is no >need for the two different types of directory attributes. Agreed >It seems clear to me that the distinction must be based on Tim Moses' >concepts of "subject community" and "relying party community" - >if those communities are identical then the cert is a CA cert, >if the resulting communities are not identical then it is a cross-cert. >But that just shifts the problem from defining "cross-certificate" >to defining "subject community". Where are these communities defined? The subject community could potentially be defined in the certificate (e.g. *.cnn.com), its the relying party community that is fuzzy. Regardless, I really don't think that the problem lies there. The problem is that 'cross certification' is a property of the trust graph, not the individual links that compose it. If the graph is acyclic then no cross certification is going on, if it is cyclic then there is. This does not mean that there is a difference between a CA certificate and a cross certificate however. Both are simply a type of certificate that makes a claim to delegate trust in some sense 'I trust X and all Y's that X trusts'. If we were to define a cross certificate as a CA-certificate that is a part of a cycle then the type of a particular certificate would change simply by the issuing of a certificate that completed a cycle. E.G if Alice CA-certifies Bob and Bob CA-certifies Carol and these are the only certificates existing then they are simply CA-certificates, they could even fit into the PEM model. But should Carol or Bob decide to CA-certify Alice all the certificates suddenly become 'Cross certificates'. This is clearly nonsense but I believe the root of the problem is the attempt to make a distinction where none exists. Either a party is making the statement 'trust this person as a CA' or they are not. Issuing a CA cert involves liability and that is so regardless of whether the certificate is called a CA-cert, a cross-certificate or for that matter a PGP key signing. There is a whole litterature on preventing deadlock in communications networks that is in effect addressing the same issue. Deadlock is a global property of networks, not a property of individual arcs or nodes. Much confusion was caused until that realisation was made. It is important to remember that what is left out of a specification can be just as important as what is left in. Phill From ???@??? Mon Jan 26 13:34:56 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id NAA09906 for ; Mon, 26 Jan 1998 13:24:16 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 14:27:30 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id NAA09390; Mon, 26 Jan 1998 13:19:31 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 21868 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 13:17:48 -0800 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id NAA22527 for ; Mon, 26 Jan 1998 13:17:45 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA26225 for ; Mon, 26 Jan 1998 16:17:44 -0500 (EST) Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA26221 for ; Mon, 26 Jan 1998 16:17:43 -0500 (EST) Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id QAA01627 for ; Mon, 26 Jan 1998 16:04:34 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id QAA03615; Mon, 26 Jan 1998 16:05:32 -0500 X-Sun-Charset: US-ASCII Message-ID: <199801262105.QAA03615@argon.ncsc.mil> Date: Mon, 26 Jan 1998 16:05:32 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "David P. Kemp" Subject: Re: [IETF-PKIX] Cross Certification - Terminology To: IETF-PKIX@LISTS.TANDEM.COM Status: Consider the following two certification graphs, each with three End Entities: CA0 (1) (2) \ CA1 CA1 ----> CA2 / \ / / \ E1 CA2 E1 E2 E3 / \ E2 E3 Graph (1) purports to be a single-rooted heirarchy where E1, E2 and E3 all begin verifying at the self-signed cert of CA1. CA2 has a CA-certificate issued by CA1. Graph (2) purports to represent unilateral cross-certification, where E1 trusts CA1's self-signed cert, and E2 and E3 trust CA0's self-signed cert. (CA0 is introduced solely to allow CA2 to be a non-root in both graphs.) CA2 has a CA-certificate, which in this case is also a cross-certificate, issued by CA1. Note to Phill: in this example both graphs are acyclic. As much as I'd like to believe that there is a difference between CA-certification within an organization/heirarchy and cross-certification across unrelated organizations, I am unable to discern any difference between the two graphs. Today, in graph 2, E2 and E3 trust root CA0. Tomorrow, E2 might trust CA0 while E3 chooses to trust CA1. The next day, they might both trust only CA1. Next week, each might trust both CA0 and CA1. Any scheme which labels a cert issued by CA1 to CA2 depending on the independent and dynamic trust decisions made by CA2's subjects seems to stand on shaky ground. And Carlisle's proposal also implies that all CA-certification fits his definition of cross-certification. So I guess we're coming around to Warwick's option (b). From ???@??? Mon Jan 26 10:48:34 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA05101 for ; Mon, 26 Jan 1998 10:16:57 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 11:20:17 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA21134; Mon, 26 Jan 1998 10:14:41 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 21594 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 10:14:31 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA19999 for ; Mon, 26 Jan 1998 10:14:30 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id KAA21759; Mon, 26 Jan 1998 10:13:58 -0800 (PST) Received: from wford-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA25933; Mon, 26 Jan 1998 10:13:56 -0800 (PST) X-Sender: wford@mail.verisign.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.32.19980126132625.00769ce4@mail.verisign.com> Date: Mon, 26 Jan 1998 13:26:25 -0800 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Warwick Ford Subject: Re: [IETF-PKIX] Cross Certification - Terminology Comments: To: boeyen@entrust.com To: IETF-PKIX@LISTS.TANDEM.COM Status: Sharon: Well I, for one, asked many people who mentioned cross-certification for clarification and, as with our experience on this list, was not overly surprised to find that they were quite often talking about different things. The waters are muddy now. We have no choice but to either define the term or drop it. Do I take it you are voting for my (b) option? Warwick At 08:04 AM 1/26/98 -0500, Sharon Boeyen wrote: >I believe that removing the term cross-certification will do nothing >more than add confusion to the situation. At the RSA conference last >week, for example, I attended numerous sessions where the term >cross-certification was used repeatedly and not once did I hear a >question asking for clarification. We will only muddy the waters now if >we try to change the term, or even worse, people reading our documents >may interpret that PKIX doesn't address cross-certification. >------------------ >Sharon Boeyen >Entrust Technologies > >mailto:boeyen@entrust.com Tel: (613) 247-3181 >http://www.entrust.com Fax: (613) 247-3690 > Orchestrating Enterprise Security > > >>---------- >>From: Warwick Ford[SMTP:wford@VERISIGN.COM] >>Sent: January 25, 1998 7:03 PM >>To: IETF-PKIX@LISTS.TANDEM.COM >>Subject: [IETF-PKIX] Cross Certification - Terminology >> >>The thread on cross-certification terminology did not achieve much except >>to confirm that many people have different views on what >>"cross-certification" means and what needs to be done to address the >>subject area. We shall clearly not resolve all the issues here quickly, >>but there were some valuable contributions to start from. >> >>However, we need immediately to clarify or fix the usage of the term in >>PKIX 1 and CMP, since that is causing lots of confusion in the outside >>world. I see two simple alternatives, and feel we should adopt one of them >>before these documents are published as proposed standards: >> >>(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the >>X.509-defined term "CA-certificate"; or >> >>(b) Explicitly define the term "cross-certificate" to be the same as the >>term "CA-certificate" (as defined in X.509). >> >>I know that not everyone agrees with (b). For that reason, I propose we do >>(a), but am willing to open this up to one last round of opinions. >> >>Warwick >> >>--------------------------------------------------------------------- >>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 >> wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 >>--------------------------------------------------------------------- >> > > --------------------------------------------------------------------- Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 --------------------------------------------------------------------- From ???@??? Mon Jan 26 14:21:36 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id OAA10930 for ; Mon, 26 Jan 1998 14:07:30 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 15:10:59 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id NAA13123; Mon, 26 Jan 1998 13:58:15 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 21948 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 13:56:50 -0800 Received: from ntdev.signet.org.au (ntdev.signet.org.au [139.130.64.197]) by Tandem.com (8.8.8/2.0.1) with ESMTP id NAA29286 for ; Mon, 26 Jan 1998 13:56:43 -0800 (PST) Received: from DEVELOP ([203.37.128.25]) by ntdev.signet.org.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id C53BLRH7; Tue, 27 Jan 1998 07:57:38 +1000 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0058_01BD2AF9.09B2AD90" 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 Message-ID: <006101bd2aa5$3afafe60$198025cb@develop.signet.org.au> Date: Tue, 27 Jan 1998 07:56:13 +1000 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Charles Moore Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: -----Original Message----- snip-- . For instance, we would want to make sure that :cross-certificates are placed in the cross-certificates attribute and :not the CA-certificate attribute. Agree : :Another reason to maintain the term cross-certification and not confuse :matters further. : Agree. Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Attachment converted: Lutefisk:smime.p7s 35 (????/----) (0001E31B) From ???@??? Mon Jan 26 15:07:56 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id OAA11923 for ; Mon, 26 Jan 1998 14:40:27 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 15:43:48 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id OAA17026; Mon, 26 Jan 1998 14:33:17 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 22087 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 14:31:44 -0800 Received: from ntdev.signet.org.au (ntdev.signet.org.au [139.130.64.197]) by Tandem.com (8.8.8/2.0.1) with ESMTP id OAA06221 for ; Mon, 26 Jan 1998 14:31:38 -0800 (PST) Received: from DEVELOP ([203.37.128.25]) by ntdev.signet.org.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id C53BLR21; Tue, 27 Jan 1998 08:32:32 +1000 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0076_01BD2AFD.E9AB92F0" 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 Message-ID: <007b01bd2aaa$1aeae310$198025cb@develop.signet.org.au> Date: Tue, 27 Jan 1998 08:31:06 +1000 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Charles Moore Subject: Re: [IETF-PKIX] Cross Certification - Terminology To: IETF-PKIX@LISTS.TANDEM.COM Status: -----Original Message----- From: David P. Kemp To: IETF-PKIX@LISTS.TANDEM.COM Date: Tuesday, 27 January 1998 1:15 Subject: Re: [IETF-PKIX] Cross Certification - Terminology :> From: Charles Moore :> :> If we must, I would suggest the following: :> :> Cross-Certificates :> CAs may cross-certify each other, that is each issue the other a certificate :> and combine the two certificates in a single directory attribute called a :> crossCertificatePair. This crossCertificatePair attribute, supports chains :> of trust that run in both directions and implement trust models that begin :> at the CA which issued the users certificate, rather than trust models where :> trust originates from a common "root". A crossCertificatePair, includes two :> certificates, forward and reverse. The subject of the forward certificate :> is the issuer of the reverse certificate and vice-versa. : : :Inter-domain certification is not necessarily bilateral, i.e. it does :not always result in a crossCertificatePair. The relevant definition is CertificatePair ::= SEQUENCE { forward [0] Certificate OPTIONAL, reverse [1] Certificate OPTIONAL} I believe that there are optionals here, the specification does not force a particular solution. snip. Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Attachment converted: Lutefisk:smime.p7s 36 (????/----) (0001E31D) From ???@??? Tue Jan 27 21:04:42 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id PAA12694 for ; Mon, 26 Jan 1998 15:12:24 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 16:15:58 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id PAA21332; Mon, 26 Jan 1998 15:11:19 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 22210 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 15:09:54 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id PAA14125 for ; Mon, 26 Jan 1998 15:09:53 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Mon, 26 Jan 1998 16:09:22 -0700 X-Mailer: Novell GroupWise 5.2 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by Tandem.com id PAA14127 Message-ID: Date: Mon, 26 Jan 1998 16:08:49 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] Is PKIX Patent-free? Comments: To: wford@VERISIGN.COM To: IETF-PKIX@LISTS.TANDEM.COM Status: >Given Jeff's comments below, perhaps it is an appropriate time to invite >all individuals/corporations participating in the PKIX work to inform us of >any other patent filings or patents granted that might impact any of the >PKIX projects. We can do without more surprises down the track. >Warwick Other organizations I am aware of address this problem by assigning _)corporate_ membership in the group, and by signing a document which clearly spells out what the intellectual property rights of the "contributing" organization are vs. the rights of other members of the group, or the public. The IETF, on the other hand, defines "membership" very loosely, if at all, and the contributions are generally viewed as being those of the individual, not the corporation. It therefore seems difficult to assign the responsibility for patent clearance, licensing, etc., to the individual contributors, who may be quite ill-suited to that role. I do agree that it would be poor form for someone to knowingly, much less deliberately, submit a contribution which later (surprise!) is revealed to be encumbered by a patent. On the other hand, I suspect that 99% of the contributors to this list are not patent experts, and in many if not most cases, may have little or no knowledge of the patents currently held by their employer. Certainly I was unaware of the Novell patent in this area (CRL processing) until I heard about it from Phillip Halem-Baker, despite the fact that two of the inventors sit not more than 100 feet from me -- the patent originated prior to my joining Novell. And I haven't had the time (or inclination, to be candid) to research the patent vs. the proposed standard (to which I have contributed only occasional comments) to see whether the proposed standard infringes or not. Another issue is the extent to which a "contribution" is more or less complete and intact, vs. the more normal kinds of evolving commentary and dialogue. In the case of a more or less complete contribution, I would normally expect that a company has reviewed the general concept to determine whether they have any intellectual property issues, prior to publicly disclosing what might be an invention. But in the case of a continued technical dialogue, I think it would be quite rare to get a IP review prior to making a suggestion that might ultimately be included in a proposed standard. Of course another whole issue entirely is whether the IETF, and more particularly the IESG, does the public good or ill by what I perceive to be a rather blatant anti-intellectual property bias. In other words, does deliberately crafting or modifying standards to avoid infringing on the valid inventions of others in the field tend to reward innovation and invention, or discourage it? The world-wide system of patent protection is based on the assumption that by providing the creator of an invention the right to make a reasonable return on his work for a limited amount of time, the public will ultimately benefit from their labors, and hence the public good will be enhanced. It would be interesting to know whether the IETF and particularly the IESG share this assumption. Bob (Speaking strictly for myself, and not necessarily for any past, present, or future employers, and/or any other organizations with which I may be associated) > >At 06:38 PM 1/13/98 -0500, Jeffrey I. Schiller wrote: >>Indeed it is poor form for an individual to make contributions to a >>working group and after the group has adopted those recommendations, >>announce that the proposal is encumbered by that individual or the >>individuals company (and the individual was aware of the encumbrance at >>the time of suggestion). In other words, when you make a contribution to >>a WG, it is exactly that, a *contribution*. >> >>Some believe that because the patent application process is secret, that >>information about pending patents does not have to be revealed. This >>just isn't so. Although the patent process is secret, it is completely >>reasonable for the IETF to say "If you want to contribute a technology >>to a working group effort, then you must disclosure your interest." If >>you don't wish to disclose your interest, you don't have to make the >>suggestion! >> > >--------------------------------------------------------------------- >Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140 > wford@verisign.com; Tel: (617)492 2816 x225; Fax: (617)661 0716 >--------------------------------------------------------------------- Robert R. Jueneman Security Architect Novell, Inc. Network Services Division 122 East 1700 South Provo, UT 84604 801/861-7387 bjueneman@novell.com "If you are trying to get to the moon, climbing a tree, although a step in the right direction, will not prove to be very helpful." "The most dangerous strategy is to cross a chasm in two jumps." From ???@??? Tue Jan 27 21:04:44 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id QAA14436 for ; Mon, 26 Jan 1998 16:20:18 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 17:23:38 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id QAA27271; Mon, 26 Jan 1998 16:14:33 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 22334 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 16:13:05 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id QAA24964 for ; Mon, 26 Jan 1998 16:13:01 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Mon, 26 Jan 1998 17:12:30 -0700 X-Mailer: Novell GroupWise 5.2 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by Tandem.com id QAA24970 Message-ID: Date: Mon, 26 Jan 1998 17:11:32 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] cross-certification Comments: To: dpkemp@MISSI.NCSC.MIL To: IETF-PKIX@LISTS.TANDEM.COM Status: Dave, >Sharon, > >If CA A issues a certificate for CA B, what criteria are used to >decide if it is a cross-certificate or a CA-certificate? > >Defining the distinction to be "if it's published in a >cross-certificate directory attribute, then it's a cross-certificate" >seems tautological - if there is no other distinction then there is no >need for the two different types of directory attributes. Agreed. Certificate definitions should certainly not depend on the container used to hold them! > >It seems clear to me that the distinction must be based on Tim Moses' >concepts of "subject community" and "relying party community" - >if those communities are identical then the cert is a CA cert, >if the resulting communities are not identical then it is a cross-cert. >But that just shifts the problem from defining "cross-certificate" >to defining "subject community". > >If we could come up with a simple and consensus-agreed definition >which could be quickly inserted into CMP, that would be ideal. >Can you write such a definition? (I can't.) How's this: 1. A [CA] certificate is a subordinate [CA] certificate (e.g., within a subject community or hierarchy) if the certificate containing the distinguished name of the entity listed in the subject attribute was issued by the same CA (distinguished name) whose distinguished name appears in the issuer attribute in the same certificate. 2. A Top-Level Certification Authority certificate is by definition a self-signed certificate, i.e., one in which the issuer and subject distinguished names are identical. A TLCA normally issues certificates to subordinate CAs and/or end-entities which contain the TLCA's name as the issuer. 3. A cross-certificate is a certificate issued to a end-entity (CA or end-user) which is neither a subordinate certificate as defined by (1), nor a TLCA certificate as defined by (2). I.e., the name of the issuing CA in the certificate in question is _not_ the same as that contained in the issuer attribute of any certificates issued to the subject entity by the TLCA in that hierarchy. Bob > >In the meantime, I agree with you that there appears to be a meaningful >difference between a CA-cert and a cross-cert, even if we can't define >what it is. For that reason, I agree that it would be undesirable >to change "cross-certificate" to "CA-certificate" in PKIX documents. >Option (a) was better than option (b), but doing nothing is better >still. Option (a) would be better than (b), since most of the discussion in the PKIX documents seems to revolve around the issuance of subordinate CA certificate rather than what I would call a true cross-certificate. But doing nothing would simply prolong the agony. Bob > >Dave Kemp > > > >> From: Sharon Boeyen >> >> Cross-certification can certainly occur either uni-laterally or >> bi-laterally. >> >> If CA A issues a cross cert for CA B, that cross cert can be published >> : >> a) by CA A as a forward cross-certificate in the cross-certificates >> attribute of CA A's entry; >> b) by CA B as a reverse cross-certificate in the cross-certificates >> attribute of CA B's entry; >> c) or both >> If the cross-certification is bi-lateral the reverse would apply to the >> cross-certificate issued by CA B for CA A. >> >> CA A should control what gets published/or not in its entry and CA B >> control what gets published/or not in its entry. Nada is correct that in >> no case should we expect that CA A have write permission to CA B's entry >> or vice versa. >> >> I do expect that some of these directory specific issues will get >> addressed in the PKIX LDAP schema specification that we agreed to pursue >> at the December meeting. For instance, we would want to make sure that >> cross-certificates are placed in the cross-certificates attribute and >> not the CA-certificate attribute. >> >> Another reason to maintain the term cross-certification and not confuse >> matters further. >> >> ------------------ >> Sharon Boeyen >> Entrust Technologies From ???@??? Tue Jan 27 21:04:48 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id RAA16697 for ; Mon, 26 Jan 1998 17:49:56 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Mon, 26 Jan 1998 18:53:13 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id RAA04587; Mon, 26 Jan 1998 17:46:48 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 22448 for IETF-PKIX@LISTS.TANDEM.COM; Mon, 26 Jan 1998 17:45:15 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id RAA08882 for ; Mon, 26 Jan 1998 17:45:13 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Mon, 26 Jan 1998 18:44:43 -0700 X-Mailer: Novell GroupWise 5.2 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by Tandem.com id RAA08884 Message-ID: Date: Mon, 26 Jan 1998 18:44:04 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] mandatory PasswordBasedMac Comments: To: nada@COST.SE To: IETF-PKIX@LISTS.TANDEM.COM Status: Unless there is a really good reason, I would prefer to use HMAC-SHA-1 rather than triple-DES MAC for password protection. Although the use of triple-DES for password authentication may be approved for export from the US, proving beyond a reasonable doubt that that is all that it is used for may pose substantial difficulties. In addition, the use of triple-DES may also cause significant _import_ restrictions, e.g., into France, Russia, and some other countries. As a general principle, we should not be using an encryption algorithm, especially a symmetric algorithm, when a safer, less controversial algorithm is available and more than adequate for the purpose. Bob Robert R. Jueneman Security Architect Novell, Inc. Network Services Division 122 East 1700 South Provo, UT 84604 801/861-7387 bjueneman@novell.com "If you are trying to get to the moon, climbing a tree, although a step in the right direction, will not prove to be very helpful." "The most dangerous strategy is to cross a chasm in two jumps." >>> Nada Kapidzic Cicovic 01/22 2:47 AM >>> At 11:46 1/21/98 -0500, Carlisle Adams wrote: >Hi Nada, > >>---------- >>From: Nada Kapidzic Cicovic[SMTP:nada@COST.SE] >>Sent: Monday, January 12, 1998 8:03 AM >>To: IETF-PKIX@LISTS.TANDEM.COM >>Subject: [IETF-PKIX] mandatory PasswordBasedMac >> >>I have one more comment on the completeness of ipki3cmp document. >> >>In section "B2. Algorithm Use Profile", PasswordBasedMac is specified as >>mandatory algorithm for PKI message protection. As far as I understand, the >>reason for specifying mandatory algorithms is for easier interoperability >>between complying implementations. However, PasswordBasedMac (as specified >>in section "3.1.3 PKI Message Protection") is parametrized with a >>one-way-hash function and a MAC. For one-way-hash, SHA-1 is recommended, >>but for MAC different alternatives are given. >> >>Shouldn't the specification of mandatory algorithms make clear which >>algorithms should be used in place of the mentioned two parameters in >>PasswordBasedMac? What would be the preferable alternatives? > >Good point (thanks for noticing this)! Yes, a particular OWF and MAC >should be mandated for interoperability purposes. > >Unless there are any strong objections, I think the most sensible >choices would be SHA-1 for the OWF (since it's already mandated as part >of MSG_SIG_ALG) and Triple-DES-MAC [PKCS11] for the MAC (since 3-DES >(3-key, EDE, CBC) is already mandated for SYM_PENC_ALG and >PROT_SYM_ALG). Well, HMAC-SHA-1 is also a valid and presumably much faster alternative to Triple-DES-MAC. If SHA-1 is mandatory for OWF, then HMAC-SHA-1 can be a natural choice for the MAC. BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does anybody have a pointer to some document specifying it? Regards, Nada > >I will add this to Appendix B2. Thanks again! > > >-------------------------------------------- >Carlisle Adams >Entrust Technologies >cadams@entrust.com >-------------------------------------------- > ______________________________________________________________ Nada Kapidzic Cicovic COST - Computer Security Technologies CST AB (subsidiary of Entegrity Solutions Corporation) office: + 46 (0)8 477 77 37 mobile: + 46 (0)70 495 09 03 fax: + 46 (0)8 477 77 31 e-mail: nada@cost.se or nada@entegrity.com address: Finlandsgatan 60, 164 74 Kista, Sweden From ???@??? Tue Jan 27 21:04:56 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id GAA02844 for ; Tue, 27 Jan 1998 06:13:24 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 07:16:46 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id GAA06799; Tue, 27 Jan 1998 06:09:36 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 22865 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 06:08:11 -0800 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id FAA02465 for ; Tue, 27 Jan 1998 05:58:09 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA07454 for ; Tue, 27 Jan 1998 08:58:08 -0500 (EST) Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA07449 for ; Tue, 27 Jan 1998 08:58:07 -0500 (EST) Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id IAA05221 for ; Tue, 27 Jan 1998 08:55:01 -0500 Received: from avenger.missi.ncsc.mil (unverified [144.51.53.206]) by mimesweeper.missi.ncsc.mil (Integralis SMTPRS 2.04) with SMTP id ; Tue, 27 Jan 1998 08:58:03 -0500 Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BD2B01.AD6C75D0@avenger.missi.ncsc.mil>; Tue, 27 Jan 1998 08:58:04 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 27 Jan 1998 08:58:03 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "Fillingham, David W." Subject: Re: [IETF-PKIX] PKIX Part IV - CPCPSF - Number scheme To: IETF-PKIX@LISTS.TANDEM.COM Status: Mack: I definitely agree with you that it is "good news" that the NACHA CA Demonstrators are taking advantage of the PKIX Part IV Policy Framework to generate comparable policies! This is precisely what the document was written for - and it's great to see it being used as you describe! I believe Section 5 of the Part IV document addresses your concern. It says... 5. PRACTICES AND POLICY SPECIFICATION OUTLINE This section contains a possible outline for a practices and policy specification, intended to serve as a checklist or (with some further development) a standard template for use by certificate policy or CPS writers. Such a common outline will facilitate: (a) Comparison of two certificate policies during cross-certification (for the purpose of equivalency mapping). (b) Comparison of a CPS with a certificate policy definition to ensure that the CPS faithfully implements the policy. (c) Comparison of two CPSs. It then goes on to provide a suggested numbered outline. I think the intent is that policies and CPS documents follow the Section 5 outline - but if we can get the bulk of the CA community writing their policies with the policy elements in the right order, then I think we'll have made significant progress! Not sure where the PKIX would make a recommendation to do so, other than in the PKIX Part IV document itself - and the recommendation is already there. Thanks for your interest in, and support of, the IETF PKIX Policy Framework! Dave Fillingham >---------- >From: Mack Hicks[SMTP:Mack.Hicks@BANKAMERICA.COM] >Sent: Thursday, January 22, 1998 2:17 PM >To: IETF-PKIX@LISTS.TANDEM.COM >Subject: [IETF-PKIX] PKIX Part IV - CPCPSF - Number scheme > >For: IETF-PKIX Mailing list > >As part of the NACHA Demonstrator for CA interoperability, >the participant banks are putting together their Certificate Practice >Stmts. During this process, some people noted that the >IETF PKIX Part IV - CPCPSF is being often being used as an outline. >For example, the American Bar Association ISC is using the "same >numbering scheme" in their documents (or so I was so informed.) > >This is really good news. >Relying parties could then look at a CP and CPS by examining known >paragraphs for information regarding such things as key size and >authentication mechanisms. > >My question: > > Is the numbering being used from the PART IV itself or from the > suggested outline? > Your CPCPSF numbering seems to be "slightly" different. > > Since Part IV is not a standard, but a reference doc (sorry - I have > forgotten the exact name) - should there be a recommendation within > PKIX that CP's and CPS's follow the numbering scheme? > >PS: NACHA Demonstrator > >- - - - - - - - - - - - - >Mack Hicks (415) 278-7230 -- Interactive Banking Division >425 1st St m/s3671, SF CA 94105 > From ???@??? Tue Jan 27 21:04:59 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id HAA04595 for ; Tue, 27 Jan 1998 07:25:52 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 08:29:15 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id HAA11883; Tue, 27 Jan 1998 07:25:30 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 22970 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 07:24:01 -0800 Received: from darkstar.bos.platsol.com (darkstar.bos.platsol.com [130.200.200.82]) by Tandem.com (8.8.8/2.0.1) with ESMTP id HAA11845 for ; Tue, 27 Jan 1998 07:23:57 -0800 (PST) Received: from hl_30.bos.platsol.com ([130.200.200.30]) by darkstar.bos.platsol.com (8.8.7/8.8.7) with SMTP id KAA02167 for ; Tue, 27 Jan 1998 10:23:50 -0500 X-Sender: hal@darkstar.bos.platsol.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.1.32.19980127102242.0074b334@darkstar.bos.platsol.com> Date: Tue, 27 Jan 1998 10:22:42 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Hal Lockhart Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: Status: At 05:11 PM 1/26/98 -0700, Bob Jueneman wrote: >How's this: > >1. A [CA] certificate is a subordinate [CA] certificate (e.g., within a subject community or hierarchy) if the certificate containing the distinguished name of the entity listed in the subject attribute was issued by the same CA (distinguished name) whose distinguished name appears in the issuer attribute in the same certificate. > >2. A Top-Level Certification Authority certificate is by definition a self-signed certificate, i.e., one in which the issuer and subject distinguished names are identical. A TLCA normally issues certificates to subordinate CAs and/or end-entities which contain the TLCA's name as the issuer. > >3. A cross-certificate is a certificate issued to a end-entity (CA or end-user) which is neither a subordinate certificate as defined by (1), nor a TLCA certificate as defined by (2). I.e., the name of the issuing CA in the certificate in question is _not_ the same as that contained in the issuer attribute of any certificates issued to the subject entity by the TLCA in that hierarchy. I like these (assuming the correction that cross-certs can only be issued to CA's as suggested by Denis). They are unambigious and seem to get at the "what is a domain?" issue in a concrete way that avoids all the politics and religion. However, this now brings us to the engineering problem that somebody tried to discuss a week or two back. Namely: how do we find all the certs we need? If the cross cert is required to point to a cert in our chain, we are all set, but what if the relationship is more indirect? Stealing David's pictures: CA0 (2) \ CA1 ----> CA2 / / \ E1 E2 E3 Assuming E1 has the CA1 cert, this case is easy, but CA0 (3) \ CA1 ----> CA1a ----> CA2 / / \ E1 E2 E3 This requires a combination of bottom-up and top-down processing. This is further complicated if we have to protect against loops. Hal ================================================================= Harold W. Lockhart Jr. Platinum Solutions Inc. Chief Technical Architect 8 New England Executive Park Email: hal@platsol.com Burlington, MA 01803 USA Voice: (781)273-6406 Fax: (781)229-2969 ================================================================= From ???@??? Tue Jan 27 21:05:00 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id HAA04833 for ; Tue, 27 Jan 1998 07:31:55 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 08:35:18 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id HAA12601; Tue, 27 Jan 1998 07:31:16 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 22994 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 07:29:49 -0800 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id HAA13031 for ; Tue, 27 Jan 1998 07:29:47 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA10911 for ; Tue, 27 Jan 1998 10:29:46 -0500 (EST) Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA10902 for ; Tue, 27 Jan 1998 10:29:45 -0500 (EST) Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id KAA06002 for ; Tue, 27 Jan 1998 10:26:40 -0500 Received: from avenger.missi.ncsc.mil (unverified [144.51.53.206]) by mimesweeper.missi.ncsc.mil (Integralis SMTPRS 2.04) with SMTP id ; Tue, 27 Jan 1998 10:29:39 -0500 Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BD2B0E.793DC630@avenger.missi.ncsc.mil>; Tue, 27 Jan 1998 10:29:39 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 27 Jan 1998 10:29:38 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "Arsenault, Al W." Subject: Re: [IETF-PKIX] cross-certification Comments: To: "Denis.Pinkas@bull.net" To: IETF-PKIX@LISTS.TANDEM.COM Status: Intellectually, I believe that there is a difference between a "CA-certificate" issued to a CA in the same hierarchy, and a "cross-certificate" issued to a CA (maybe a Root CA/TopLevelCA/whatever) in another hierarchy. For example: at the RSA Conference two weeks ago, John Ryan of Entrust announced that the Government of Canada (which uses Entrust) and the Government of Singapore (which also uses Entrust) will soon cross-certify. It seems to me that that's a valid use of the term - it strikes me that: Scenario A: the Top-Level CA of the Government of Canada issues a CA-certificate to a subordinate CA for Revenue Canada, or some other government department Scenario B: the Top-Level CA of the Government of Canada issues a cross-certificate to the Top-Level CA of the Government of Singapore, permitting validation of communications among some end-users supported by the two governments under certain conditions are two different things, that ought to be recognized as such. While it may or may not be directly reflected in the certificate, the degree of control exerted by the issuing CA over the certificate's recipient is very different, and relying parties should be able to take this into account. So, how do we define this? Let's start with Denis' suggestion: >Cross-certificate: A CA-certificate issued by one CA for another CA that >is either in a different naming hierarchy and/or in a different >organizational structure. I think this is okay, but I'd rather see "organizational structure" replaced with "domain", which I think is a much more flexible term. Bob Jueneman wrote: 1. A [CA] certificate is a subordinate [CA] certificate (e.g., within a subject community or hierarchy) if the certificate containing the distinguished name of the entity listed in the subject attribute was issued by the same CA (distinguished name) whose distinguished name appears in the issuer attribute in the same certificate. I'm not sure I fully understand this (I went so far as to try diagramming the sentence), but it seems to only allow two-level hierarchies; e.g., a Top-Level CA and then one subordinate CA. It seems to fall apart if you try to build (Top-Level CA, CA, subordinate CA) structures. Bob: is there anything you can do to clarify this? Al Arsenault - speaking only for myself. My views do not necessarily reflect those of my employer. > From ???@??? Tue Jan 27 21:05:44 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id QAA18792 for ; Tue, 27 Jan 1998 16:46:01 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 17:49:37 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id QAA08798; Tue, 27 Jan 1998 16:44:47 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 25450 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 16:44:27 -0800 Received: from nile.spyrus.com (prometheus.spyrus.com [209.66.65.49]) by Tandem.com (8.8.8/2.0.1) with ESMTP id QAA04837 for ; Tue, 27 Jan 1998 16:44:21 -0800 (PST) Received: from rhousley_laptop.spyrus.com (RHOUSLEY_LAPTOP [209.66.65.102]) by nile.spyrus.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id DX58XSHV; Tue, 27 Jan 1998 16:48:16 -0800 X-Sender: rhousley@nile.spyrus.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.1.32.19980127110601.006c4e98@nile.spyrus.com> Date: Tue, 27 Jan 1998 11:06:01 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Russ Housley Subject: Re: [IETF-PKIX] Cross Certification - Terminology To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: <3.0.32.19980125145841.00766b5c@mail.verisign.com> Status: >I see two simple alternatives, and feel we should adopt one of them >before these documents are published as proposed standards: > >(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the >X.509-defined term "CA-certificate"; or > >(b) Explicitly define the term "cross-certificate" to be the same as the >term "CA-certificate" (as defined in X.509). I prefer (a). Russ From ???@??? Tue Jan 27 21:05:06 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA05891 for ; Tue, 27 Jan 1998 08:17:50 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 09:21:25 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id IAA16276; Tue, 27 Jan 1998 08:17:41 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 23160 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 08:16:09 -0800 Received: from darkstar.bos.platsol.com (darkstar.bos.platsol.com [130.200.200.82]) by Tandem.com (8.8.8/2.0.1) with ESMTP id IAA20062 for ; Tue, 27 Jan 1998 08:16:07 -0800 (PST) Received: from hl_30.bos.platsol.com ([130.200.200.30]) by darkstar.bos.platsol.com (8.8.7/8.8.7) with SMTP id LAA13155 for ; Tue, 27 Jan 1998 11:16:03 -0500 X-Sender: hal@darkstar.bos.platsol.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.1.32.19980127111452.0074c670@darkstar.bos.platsol.com> Date: Tue, 27 Jan 1998 11:14:52 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Hal Lockhart Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: Status: At 10:29 AM 1/27/98 -0500, Arsenault, Al W. wrote: >Bob Jueneman wrote: > >>1. A [CA] certificate is a subordinate [CA] certificate (e.g., within a >>subject community or hierarchy) if the certificate containing the >>distinguished name of the entity listed in the subject attribute was >>issued by the same CA (distinguished name) whose distinguished name >>appears in the issuer attribute in the same certificate. > >I'm not sure I fully understand this (I went so far as to try >diagramming the sentence), but it seems to only allow two-level >hierarchies; e.g., a Top-Level CA and then one subordinate CA. It seems >to fall apart if you try to build (Top-Level CA, CA, subordinate CA) >structures. Bob: is there anything you can do to clarify this? I grant the wording is hard to follow, but the idea is simple. Just ask the question" Is the issuer attribute a back pointer? If yes, its hierarchical, if no, its a cross-cert. Hal ================================================================= Harold W. Lockhart Jr. Platinum Solutions Inc. Chief Technical Architect 8 New England Executive Park Email: hal@platsol.com Burlington, MA 01803 USA Voice: (781)273-6406 Fax: (781)229-2969 ================================================================= From ???@??? Tue Jan 27 21:05:07 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA06422 for ; Tue, 27 Jan 1998 08:37:54 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 09:41:29 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id IAA18200; Tue, 27 Jan 1998 08:37:33 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 23232 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 08:36:04 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id IAA23514 for ; Tue, 27 Jan 1998 08:36:01 -0800 (PST) Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD2B16.8654A110@mail.entrust.com>; Tue, 27 Jan 1998 11:27:17 -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 Message-ID: Date: Tue, 27 Jan 1998 11:27:16 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Carlisle Adams Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: Hi Al, >---------- >From: Arsenault, Al W.[SMTP:awarsen@MISSI.NCSC.MIL] >Sent: Tuesday, January 27, 1998 10:29 AM >To: IETF-PKIX@LISTS.TANDEM.COM >Subject: Re: [IETF-PKIX] cross-certification > > Scenario A: the Top-Level CA of the Government of Canada issues a >CA-certificate to a subordinate CA for Revenue Canada, or some other >government department > > Scenario B: the Top-Level CA of the Government of Canada issues a >cross-certificate to the Top-Level CA of the Government of Singapore, >permitting validation of communications among some end-users supported >by the two governments under certain conditions > >are two different things, that ought to be recognized as such. While it >may or may not be directly reflected in the certificate, the degree of >control exerted by the issuing CA over the certificate's recipient is >very different, and relying parties should be able to take this into >account. I agree that these seem intuitively to be two different things and that it would be nice to recognize them as such. However, as you rightly point out, the difference may not be directly reflected in the certificate. In other words, there may be nothing whatsoever in the bare syntax of the certificates that allows you to make the distinction in an automated way. It seems to me that it might be a somewhat fruitless exercise to take things that can't be distinguished by the bits-on-the-wire and try to give them different names. As odd as it may seem to some, I think that these are both examples of cross-certification because in each case there are two distinct CAs involved (and I think that looking at things in terms of "subject communities" and "relying party communities" makes this clear). Agreed: using the term "cross-certificate" for both cases fails to distinguish between Scenario A and Scenario B. However, the term "CA-certificate" fails to distinguish between Scenario A above and a self-signed certificate. When reasoning about and implementing path validation logic, distinguishing the latter seems (to me) to be more important than distinguishing the former. Thus, I'd be more inclined to give the latter different names than to give the former different names. >So, how do we define this? Let's start with Denis' suggestion: > >>Cross-certificate: A CA-certificate issued by one CA for another CA that >>is either in a different naming hierarchy and/or in a different >>organizational structure. > >I think this is okay, but I'd rather see "organizational structure" >replaced with "domain", which I think is a much more flexible term. I kind of agree, but I fear that it's so much more flexible a term that for most practical purposes, it's really undefined... :-) -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- From ???@??? Tue Jan 27 21:05:08 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id IAA06913 for ; Tue, 27 Jan 1998 08:54:08 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 09:57:44 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id IAA19859; Tue, 27 Jan 1998 08:54:11 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 23298 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 08:54:04 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id IAA27201 for ; Tue, 27 Jan 1998 08:54:01 -0800 (PST) Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD2B19.0C745810@mail.entrust.com>; Tue, 27 Jan 1998 11:45:21 -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 Message-ID: Date: Tue, 27 Jan 1998 11:45:20 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Carlisle Adams Subject: Re: [IETF-PKIX] mandatory PasswordBasedMac To: IETF-PKIX@LISTS.TANDEM.COM Status: Hi Bob, Nada, >---------- >From: Bob Jueneman[SMTP:BJUENEMAN@NOVELL.COM] >Sent: Monday, January 26, 1998 8:44 PM >To: IETF-PKIX@LISTS.TANDEM.COM >Subject: Re: [IETF-PKIX] mandatory PasswordBasedMac > >Unless there is a really good reason, I would prefer to use HMAC-SHA-1 rather >than triple-DES MAC for password protection. > >Although the use of triple-DES for password authentication may be approved >for export from the US, proving beyond a reasonable doubt that that is all >that it is used for may pose substantial difficulties. In addition, the use >of triple-DES may also cause significant _import_ restrictions, e.g., into >France, Russia, and some other countries. > >As a general principle, we should not be using an encryption algorithm, >especially a symmetric algorithm, when a safer, less controversial algorithm >is available and more than adequate for the purpose. This seems to be two votes in favor of HMAC-SHA-1 and no disagreements so far. I don't mind specifying this as the mandatory parameter in PasswordBasedMac, but let me repeat Nada's question: >BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does >anybody have a pointer to some document specifying it? I need this as soon as possible (i.e., within the next day or two). If an OID doesn't exist, should PKIX define one? -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- From ???@??? Tue Jan 27 21:05:35 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id NAA14507 for ; Tue, 27 Jan 1998 13:53:45 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 14:57:08 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id NAA20024; Tue, 27 Jan 1998 13:50:12 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 24524 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 13:50:06 -0800 Received: from nexus.sac.net (nexus.sac.net [208.146.161.1]) by Tandem.com (8.8.8/2.0.1) with SMTP id NAA27948 for ; Tue, 27 Jan 1998 13:39:29 -0800 (PST) Received: (qmail 29208 invoked from network); 27 Jan 1998 21:39:25 -0000 Received: from localhost.sac.net (HELO ginkgo.sac.net) (127.0.0.1) by localhost.sac.net with SMTP; 27 Jan 1998 21:39:25 -0000 X-Sender: eric@mail.sac.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Message-ID: <3.0.3.32.19980127101404.03326e04@mail.sac.net> Date: Tue, 27 Jan 1998 10:14:04 -0800 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Eric Hughes Subject: Re: [IETF-PKIX] Is PKIX Patent-free? To: IETF-PKIX@LISTS.TANDEM.COM In-Reply-To: Status: >>>> Certainly I was unaware of the Novell patent in this area (CRL processing) until I heard about it from Phillip Halem-Baker, despite the fact that two of the inventors sit not more than 100 feet from me -- the patent originated prior to my joining Novell. <<<<<<<< Do you have a patent number for this? TIA. Eric From ???@??? Tue Jan 27 21:05:11 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA09147 for ; Tue, 27 Jan 1998 10:22:26 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 11:25:47 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA27654; Tue, 27 Jan 1998 10:18:23 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 23450 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 10:18:14 -0800 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA14770 for ; Tue, 27 Jan 1998 10:18:12 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA17276 for ; Tue, 27 Jan 1998 13:18:11 -0500 (EST) Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA17272 for ; Tue, 27 Jan 1998 13:18:11 -0500 (EST) Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id NAA07358 for ; Tue, 27 Jan 1998 13:15:06 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id NAA04107; Tue, 27 Jan 1998 13:16:04 -0500 X-Sun-Charset: US-ASCII Message-ID: <199801271816.NAA04107@argon.ncsc.mil> Date: Tue, 27 Jan 1998 13:16:04 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "David P. Kemp" Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: > From: Hal Lockhart > > I grant the wording is hard to follow, but the idea is simple. Just ask > the question" Is the issuer attribute a back pointer? If yes, its > hierarchical, if no, its a cross-cert. > > Hal I thought it sounded simple too, until I drew the diagram and realized that the issuer field in the subordinate CA's certificate didn't solve anything - it's always a back pointer to something. Start with top-level CAs 0 and 1 again, or call them "Canada" and "Singapore": CA0 "Canada" \ CA1 "Singapore" ----> CA2 "IBM" / / \ E1 E2 E3 The problem is that CA2 has two certificates with the same public key and possibly the same subject name (IBM), but with different issuer names. Each Relying Party can choose which of CA0 or CA1 to use as a trust anchor when validating E3's cert; for each choice there is an available cert with CA2 as the subject and a valid back-pointing issuer field. You have to invoke politics to determine which domain IBM belongs to, and therefore which cert is the cross-cert. There doesn't seem to be any way around that. One possible solution is for both Singapore and Candada to agree that CA2's real name is "C=CA, O=IBM". Any cert with CA2 as the subject which didn't follow name subordination would be defined as a cross-cert. But it doesn't seem useful to go through the process of labelling a particular certificate as a cross-cert if there is no difference in the path validation procedure as a result of assigning that label. I'm starting to believe that if the term "cross-certification" is used to mean anything more limited and specific than "CA-certification", then the description of the difference belongs *only* in Part 4. For purposes of Part 1 and Part 3, they are synonymous unless someone can come up with a concrete example where the difference has an observable effect on 1) certificate contents, 2) path validation rules, or 3) management protocol operations. This is, in fact, a Good Thing. It means that X.509/PKIX is general enough to support the political/operational act of "cross-certification" without requiring any special-purpose syntax or protocol operations. From ???@??? Tue Jan 27 21:05:12 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA09418 for ; Tue, 27 Jan 1998 10:37:08 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 11:40:21 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA29778; Tue, 27 Jan 1998 10:36:13 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 23497 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 10:36:08 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id KAA18862 for ; Tue, 27 Jan 1998 10:36:06 -0800 (PST) Received: tid NAA14610; Tue, 27 Jan 1998 13:30:34 -0500 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD2B27.3D035770@mail.entrust.com>; Tue, 27 Jan 1998 13:26:56 -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 Message-ID: Date: Tue, 27 Jan 1998 13:26:54 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Carlisle Adams Subject: [IETF-PKIX] FW: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: Hi, Sorry, I meant for this to go to everyone, not just to Bob. >---------- >From: Carlisle Adams >Sent: Tuesday, January 27, 1998 12:01 PM >To: 'Bob Jueneman' >Subject: RE: [IETF-PKIX] cross-certification > >Hi Bob, > >---------- >From: Bob Jueneman[SMTP:BJUENEMAN@novell.com] >Sent: Monday, January 26, 1998 5:00 PM >To: Carlisle Adams; IETF-PKIX@LISTS.TANDEM.COM >Subject: Re: [IETF-PKIX] cross-certification > >Carlisle, for the record I continue to have a problem with what appears to be >the basic premise regarding unilateral cross-certification, i.e., that it >necessarily needs to be requested by the subject of the certificate at all. >But perhaps I am not reading the text correctly. > >You are reading the text correctly. But that basic premise is there for a >very simple reason. If the subject is not involved in this decision (i.e., >if the issuer decides entirely on its own to create a cross-certificate for >that subject) AND if the issuer is the one responsible for publishing the >cross-certificate once its created, then there is no need for a protocol. >There is nothing whatsoever in that exercise that needs to be specified in >CMP. > >What we're trying to cover is the case in which the subject *does* ask for >the cross-certificate. In this situation, there needs to be a protocol >specified (so that the subject knows *how* to ask, and the issuer knows how >to respond). > >If my IT organization decides to bestow corporate trust on some TLCA, and >does so by means of a unilateral cross-certificate (outside of the TLCA's >hierarchy), I don't expect the TLCA being so recognized to initiate or even >participate in the creation of the certificate, either by participation in a >protocol or through any legal or business arrangements, necesarily. > >And for that reason, I'm not sure why it would make sense to depart from the >general pattern of haivng the CA who issues the certificate be responsible >for publishing it. Surely the issuing CA would still be responsbile for >publishing any6 CRLs, so why be inconsistent? > >Again, you and Nada agree here and I'm not hearing opposing views from the >list. Therefore, I will relax the constraint that the subject (the >requester) is the one who publishes. As it turns out, the better solution is >already accommodated in the protocol: if the requester cares who publishes >(and where), then it should use the PKIPublicationInfo parameter. I will add >a note to the effect that if this optional parameter is omitted in the >request, then the issuer is the one who publishes the resulting certificate. > > >-------------------------------------------- >Carlisle Adams >Entrust Technologies >cadams@entrust.com >-------------------------------------------- > > > From ???@??? Tue Jan 27 21:05:13 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA09445 for ; Tue, 27 Jan 1998 10:41:17 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 11:44:52 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA00053; Tue, 27 Jan 1998 10:38:42 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 23480 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 10:38:34 -0800 Received: from zionsbank.com (mail.zionsbank.com [207.14.144.36]) by Tandem.com (8.8.8/2.0.1) with SMTP id KAA17010 for ; Tue, 27 Jan 1998 10:28:25 -0800 (PST) Received: from ZionsData-Message_Server by zionsbank.com with Novell_GroupWise; Tue, 27 Jan 1998 11:28:57 -0700 X-Mailer: Novell GroupWise 4.1 Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Message-ID: Date: Tue, 27 Jan 1998 11:28:29 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Mike Smith Subject: Re: [IETF-PKIX] cross-certification Comments: To: BJUENEMAN@NOVELL.COM Comments: cc: S670MDL@zionsbank.com, S814FSB@zionsbank.com, S814JZF@zionsbank.com To: IETF-PKIX@LISTS.TANDEM.COM Status: Bob (et al) : My understanding of cross certificates is kind of basic: If I am a CA and wish to incorporate the certificates issued by another CA into my trust domain, then I would execute a contract with that CA then issue a CA-certificate to that CA. I would impose some limitation on levels of issuers below the contracted CA and no trust for CAs above or without contract. This would bring all of "my" certificate subscribers (including those of the cross-certified CAs) still to me to validate certs for relying on those certs issued by a CA to whom I have issued an issuer cert. The draw back in this scenario is that I do not have any contractual business relationship with those subscribers of the CA I brought into my "trust" domain, so I assume liability to my reliant party community for the identity and usage of those certs. Hopefully, my contract with the cross-certified CA indemnifies me sufficiently from their errors (or fraud). The schemes for "cross-certifying" that some vendors have implemented where a "lateral" cross cert is issued for a CA outside my "hierarchy" of trust (do not end at the same root as mine) are more "scary" when they also bring in all the "lateral" cross-certifications of those CAs as well. I have a hard time recognizing with whom I need contracts and indemnity with. IIt may be just the one CA relationship who will indemnify me from all of the errors, omissions and fraud of all of their cross-certified CAs (and their's and so on) that they bring to my domain of trust. I think that a workable situation might be with correspondent Ca contracts for identity of the other CA's clients just in order to establish a new contract and business realtionship with each individual on whose identity I need to rely. I can have correspondent CA relationships established and certificate status or CRL checks with those correspondents without automatically bringing in all of their subscribers without establishing those subscriber buisiness relationships. These correspondnet relationships do not entail merging the domains of trust (or CRLs, ARLs, etc.) and are backed by the correspondent contracts. I know this is a different model than that of a "Public" CA wishing to enable its subscribers to communicate with other CA's subscribers. My current focus is on design and implementation of a "Corporate" PKI within an extranet environment over the public nets to do commerce. With this different focus, my comments may be particular to the corporate, eComemrce model and not the public infrastructure. In the corporate model, I need business agreements with those I do business with. If I have a contract with you as a CA, then I need recourse against you for problems caused by "your" customers. If I need to do business with "your" customers and you do not wish to indemnify me, then I need to establish a relatinship with them myself. Do you concur? michael >>> Bob Jueneman 01/26/98 05:11PM >>> Dave, >Sharon, > >If CA A issues a certificate for CA B, what criteria are used to >decide if it is a cross-certificate or a CA-certificate? > >Defining the distinction to be "if it's published in a >cross-certificate directory attribute, then it's a cross-certificate" >seems tautological - if there is no other distinction then there is no >need for the two different types of directory attributes. Agreed. Certificate definitions should certainly not depend on the container used to hold them! > >It seems clear to me that the distinction must be based on Tim Moses' >concepts of "subject community" and "relying party community" - >if those communities are identical then the cert is a CA cert, >if the resulting communities are not identical then it is a cross-cert. >But that just shifts the problem from defining "cross-certificate" >to defining "subject community". > >If we could come up with a simple and consensus-agreed definition >which could be quickly inserted into CMP, that would be ideal. >Can you write such a definition? (I can't.) How's this: 1. A [CA] certificate is a subordinate [CA] certificate (e.g., within a subject community or hierarchy) if the certificate containing the distinguished name of the entity listed in the subject attribute was issued by the same CA (distinguished name) whose distinguished name appears in the issuer attribute in the same certificate. 2. A Top-Level Certification Authority certificate is by definition a self-signed certificate, i.e., one in which the issuer and subject distinguished names are identical. A TLCA normally issues certificates to subordinate CAs and/or end-entities which contain the TLCA's name as the issuer. 3. A cross-certificate is a certificate issued to a end-entity (CA or end-user) which is neither a subordinate certificate as defined by (1), nor a TLCA certificate as defined by (2). I.e., the name of the issuing CA in the certificate in question is _not_ the same as that contained in the issuer attribute of any certificates issued to the subject entity by the TLCA in that hierarchy. Bob > >In the meantime, I agree with you that there appears to be a meaningful >difference between a CA-cert and a cross-cert, even if we can't define >what it is. For that reason, I agree that it would be undesirable >to change "cross-certificate" to "CA-certificate" in PKIX documents. >Option (a) was better than option (b), but doing nothing is better >still. Option (a) would be better than (b), since most of the discussion in the PKIX documents seems to revolve around the issuance of subordinate CA certificate rather than what I would call a true cross-certificate. But doing nothing would simply prolong the agony. Bob > >Dave Kemp > > > >> From: Sharon Boeyen >> >> Cross-certification can certainly occur either uni-laterally or >> bi-laterally. >> >> If CA A issues a cross cert for CA B, that cross cert can be published >> : >> a) by CA A as a forward cross-certificate in the cross-certificates >> attribute of CA A's entry; >> b) by CA B as a reverse cross-certificate in the cross-certificates >> attribute of CA B's entry; >> c) or both >> If the cross-certification is bi-lateral the reverse would apply to the >> cross-certificate issued by CA B for CA A. >> >> CA A should control what gets published/or not in its entry and CA B >> control what gets published/or not in its entry. Nada is correct that in >> no case should we expect that CA A have write permission to CA B's entry >> or vice versa. >> >> I do expect that some of these directory specific issues will get >> addressed in the PKIX LDAP schema specification that we agreed to pursue >> at the December meeting. For instance, we would want to make sure that >> cross-certificates are placed in the cross-certificates attribute and >> not the CA-certificate attribute. >> >> Another reason to maintain the term cross-certification and not confuse >> matters further. >> >> ------------------ >> Sharon Boeyen >> Entrust Technologies From ???@??? Tue Jan 27 21:05:15 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA09691 for ; Tue, 27 Jan 1998 10:48:51 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 11:52:27 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA01295; Tue, 27 Jan 1998 10:48:12 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 23612 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 10:47:56 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id KAA21989 for ; Tue, 27 Jan 1998 10:47:52 -0800 (PST) Received: tid NAA16274; Tue, 27 Jan 1998 13:43:48 -0500 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD2B29.1618CEE0@mail.entrust.com>; Tue, 27 Jan 1998 13:40:10 -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 Message-ID: Date: Tue, 27 Jan 1998 13:40:08 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Carlisle Adams Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: Hi, It seems the indenting didn't show up properly last time, so it might be hard for others to distinguish what Bob said from what I said. Let's try this again... >---------- >From: Carlisle Adams >Sent: Tuesday, January 27, 1998 12:01 PM >To: 'Bob Jueneman' >Subject: RE: [IETF-PKIX] cross-certification > >Hi Bob, > >---------- >From: Bob Jueneman[SMTP:BJUENEMAN@novell.com] >Sent: Monday, January 26, 1998 5:00 PM >To: Carlisle Adams; IETF-PKIX@LISTS.TANDEM.COM >Subject: Re: [IETF-PKIX] cross-certification > >Carlisle, for the record I continue to have a problem with what appears to be >the basic premise regarding unilateral cross-certification, i.e., that it >necessarily needs to be requested by the subject of the certificate at all. >But perhaps I am not reading the text correctly. > >You are reading the text correctly. But that basic premise is there for a >very simple reason. If the subject is not involved in this decision (i.e., >if the issuer decides entirely on its own to create a cross-certificate for >that subject) AND if the issuer is the one responsible for publishing the >cross-certificate once its created, then there is no need for a protocol. >There is nothing whatsoever in that exercise that needs to be specified in >CMP. > >What we're trying to cover is the case in which the subject *does* ask for >the cross-certificate. In this situation, there needs to be a protocol >specified (so that the subject knows *how* to ask, and the issuer knows how >to respond). > >If my IT organization decides to bestow corporate trust on some TLCA, and >does so by means of a unilateral cross-certificate (outside of the TLCA's >hierarchy), I don't expect the TLCA being so recognized to initiate or even >participate in the creation of the certificate, either by participation in a >protocol or through any legal or business arrangements, necesarily. > >And for that reason, I'm not sure why it would make sense to depart from the >general pattern of haivng the CA who issues the certificate be responsible >for publishing it. Surely the issuing CA would still be responsbile for >publishing any6 CRLs, so why be inconsistent? > >Again, you and Nada agree here and I'm not hearing opposing views from the >list. Therefore, I will relax the constraint that the subject (the >requester) is the one who publishes. As it turns out, the better solution is >already accommodated in the protocol: if the requester cares who publishes >(and where), then it should use the PKIPublicationInfo parameter. I will add >a note to the effect that if this optional parameter is omitted in the >request, then the issuer is the one who publishes the resulting certificate. > > >-------------------------------------------- >Carlisle Adams >Entrust Technologies >cadams@entrust.com >-------------------------------------------- > > > From ???@??? Tue Jan 27 21:05:14 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA09680 for ; Tue, 27 Jan 1998 10:46:18 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 11:49:50 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA00472; Tue, 27 Jan 1998 10:42:10 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 23548 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 10:42:01 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id KAA20251 for ; Tue, 27 Jan 1998 10:41:59 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 27 Jan 1998 11:41:29 -0700 X-Mailer: Novell GroupWise 5.2 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by Tandem.com id KAA20252 Message-ID: Date: Tue, 27 Jan 1998 11:40:15 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] mandatory PasswordBasedMac Comments: To: carlisle.adams@ENTRUST.COM To: IETF-PKIX@LISTS.TANDEM.COM Status: >Hi Bob, Nada, > >>---------- >>From: Bob Jueneman[SMTP:BJUENEMAN@NOVELL.COM] >>Sent: Monday, January 26, 1998 8:44 PM >>To: IETF-PKIX@LISTS.TANDEM.COM >>Subject: Re: [IETF-PKIX] mandatory PasswordBasedMac >> >>Unless there is a really good reason, I would prefer to use HMAC-SHA-1 rather >>than triple-DES MAC for password protection. >> >>Although the use of triple-DES for password authentication may be approved >>for export from the US, proving beyond a reasonable doubt that that is all >>that it is used for may pose substantial difficulties. In addition, the use >>of triple-DES may also cause significant _import_ restrictions, e.g., into >>France, Russia, and some other countries. >> >>As a general principle, we should not be using an encryption algorithm, >>especially a symmetric algorithm, when a safer, less controversial algorithm >>is available and more than adequate for the purpose. > >This seems to be two votes in favor of HMAC-SHA-1 and no disagreements >so far. I don't mind specifying this as the mandatory parameter in >PasswordBasedMac, but let me repeat Nada's question: > >>BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does >>anybody have a pointer to some document specifying it? > >I need this as soon as possible (i.e., within the next day or two). If >an OID doesn't exist, should PKIX define one? I don't know the OID, but I believe that one was defined for SET, if someone has that spec. Bob From ???@??? Tue Jan 27 21:05:16 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id KAA09932 for ; Tue, 27 Jan 1998 10:52:12 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 11:55:22 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id KAA01761; Tue, 27 Jan 1998 10:51:05 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 23650 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 10:50:54 -0800 Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by Tandem.com (8.8.8/2.0.1) with ESMTP id KAA22901 for ; Tue, 27 Jan 1998 10:50:50 -0800 (PST) Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.0) id KAA10212; Tue, 27 Jan 1998 10:50:15 -0800 (PST) Received: from verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id KAA16584; Tue, 27 Jan 1998 10:50:11 -0800 (PST) X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms001232D1613ACB962487A3BA" Message-ID: <34CE2F4F.BADED7A8@verisign.com> Date: Tue, 27 Jan 1998 14:02:39 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Phillip Hallam-Baker Organization: VeriSign Inc. Subject: Re: [IETF-PKIX] Is PKIX Patent-free? To: IETF-PKIX@LISTS.TANDEM.COM Status: >On the other hand, I suspect that 99% of the contributors to this list >are not patent experts, and in many if not most cases, may have little >or no knowledge of the patents currently held by their employer. I don't know that Novell made any concerted effort to get its version of CRL processing adopted as an IETF standard. The real problem is when the patent authors are involved, allowing of course for the problem that a person may no longer work for the assignee but still be bound by an NDA. > The world-wide system of patent protection is based on the assumption >that by providing the creator of an invention the right to make a >reasonable return on his work for a limited amount of time, the >public will ultimately benefit from their labors, and hence the >public good will be enhanced. That may be the *World* approach to patent law, the US approach is very different. The term 'intellectual property' tends to be interpreted in terms of 'rights' with a sort of 'land rush' mentality in which the first (white) person to stake a claim gets to take the Indian's land. Unlike other patent offices the US PTO does not have an outside review period. as a result it has allowed a number of ludicrous patent grants, the term 'patently obvious' frequently comming to mind. It does not even manage to check its own issued patents for prior art, let alone the current litterature. The consensus view of patents in the IETF would most likely be that they are a form of government taxation on invention akin to a compulsory lottery. Most are forced to participate, to grab patents so that they can trade them with other people who have patents they need access to. This is why I was asking what people intend to do with their patents, the IESG has a history of playing hardball. Not letting a standard pass until the patent holders reliquish their rights being a common one. Have a look at the 'Intelecutal Property' statements on the IETF home page. Phill Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Attachment converted: Lutefisk:smime.p7s 37 (????/----) (0001E31F) From ???@??? Tue Jan 27 21:05:18 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id LAA10474 for ; Tue, 27 Jan 1998 11:19:22 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 12:22:57 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id LAA05209; Tue, 27 Jan 1998 11:17:51 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 23920 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 11:17:41 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id LAA00275 for ; Tue, 27 Jan 1998 11:17:37 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 27 Jan 1998 12:17:07 -0700 X-Mailer: Novell GroupWise 5.2 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by Tandem.com id LAA00282 Message-ID: Date: Tue, 27 Jan 1998 12:16:36 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] cross-certification Comments: To: awarsen@MISSI.NCSC.MIL To: IETF-PKIX@LISTS.TANDEM.COM Status: I think we are getting somewhere, but there seem to be three separate problems to be addressed: 1. Proper understanding trust relationships being discussed, 2. Representing that trust relatiionship in some meaningful, parseable, and hopefully concise English definition, and 3. Figuring out what to do about the nasty problems of certificate retrieval and public key validation in a mesh network. >Intellectually, I believe that there is a difference between a >"CA-certificate" issued to a CA in the same hierarchy, and a >"cross-certificate" issued to a CA (maybe a Root CA/TopLevelCA/whatever) >in another hierarchy. Quite so. and the difference, of course, is who is doing the issuing, and who the relying parties are. My primary interest (AKA bias, AKA blind spot?) in the use of cross-certificates is to support a model which allows a user or her IT organization to simply represent which independent hierarchical domains of trust they choose to give credence to. So my primary mental model is a bottom-up, followed by multiple top-down models, controlled and modulated as required by policyOID and/or other validation path constraints. I would be quite wary of ANY certification authority (other than my own) which cross-certifies some other CA hierarchy, unless they can assure me that they have applied the same policy mapping and other CPS constraints to that other hierarchy, and can assure me that they are equivalent. I have no problem if the Government of Canada wishes to instruct those users over which it has either moral or legal authority, e.g., government employees within the Ministry of Defence, that they should trust the certificates issued by the Government of Singapore as effectively the equivalent of the certificates issued by the Government of Canada. It is certainly their right to do so. However, it would be quite another thing to assert that if I decide to trust the certificate issued by the Government of Canada, I must or at least should trust the certificate issued by the Government of Singapore. I don't have anything against Singapore, particularly, but they obviously have a much different legal system than what I am used to, and they are sufficiently far away both in distance in culture that I would not even think of extending to them the same degree of trust I would give Canada, a country which I have visited multiple times, and whose citizens, culture, and legal system I am quite familiar with. This is the obvious problem with transitive trust, writ large when it comes to cross-certification. > >For example: at the RSA Conference two weeks ago, John Ryan of Entrust >announced that the Government of Canada (which uses Entrust) and the >Government of Singapore (which also uses Entrust) will soon >cross-certify. It seems to me that that's a valid use of the term - it >strikes me that: > > Scenario A: the Top-Level CA of the Government of Canada issues a >CA-certificate to a subordinate CA for Revenue Canada, or some other >government department > > Scenario B: the Top-Level CA of the Government of Canada issues a >cross-certificate to the Top-Level CA of the Government of Singapore, >permitting validation of communications among some end-users supported >by the two governments under certain conditions > >are two different things, that ought to be recognized as such. While it >may or may not be directly reflected in the certificate, the degree of >control exerted by the issuing CA over the certificate's recipient is >very different, and relying parties should be able to take this into >account. > Agreed. > >So, how do we define this? Let's start with Denis' suggestion: > >>Cross-certificate: A CA-certificate issued by one CA for another CA that >>is either in a different naming hierarchy and/or in a different >>organizational structure. > >I think this is okay, but I'd rather see "organizational structure" >replaced with "domain", which I think is a much more flexible term. Naming hierarchy is obviously much too narrow. If I decide that I like Verisign's policies relating to their Class 3 certificates used for web servers and code signing, I may decide to trust all of their Class 3 certificate, regardless of the lack of any name constraints or other relationship. Likewise, organizational structure doesn't work, for there isn't any organization in common. The issue is more one of policy, and perhaps contractual agreements. "Domain" comes closer, but tends to imply a more rigid degree of authoritative control, a la DMS, that is probably warranted in the commercial environment. So far I haven't come up with a one-word English description. [Maybe we should adopt, and if necessary bastardize, the German word "bund," loosely meaning "association," but without the legal meaning that association might have in English. But please, all you German linguists, don't jump all over me. It's probably a bad idea.] ]> >Bob Jueneman wrote: > >1. A [CA] certificate is a subordinate [CA] certificate (e.g., within a >subject community or hierarchy) if the certificate containing the >distinguished name of the entity listed in the subject attribute was >issued by the same CA (distinguished name) whose distinguished name >appears in the issuer attribute in the same certificate. > >I'm not sure I fully understand this (I went so far as to try >diagramming the sentence), but it seems to only allow two-level >hierarchies; e.g., a Top-Level CA and then one subordinate CA. It seems >to fall apart if you try to build (Top-Level CA, CA, subordinate CA) >structures. Bob: is there anything you can do to clarify this? Sorry, Al. I wrote that one about three times, and had some trouble understanding it myself. But I was not trying to differentiate between a CA and a subordinate CA, but only between subordinate certificates vs. TLCA and cross-certificates. So from my point of view your structure is wrong -- it should be TLCA, subordinate CA, subordinate CA.. What I was trying to do in economical language was to define what all of us would understand is meant by a certificate being in a given hierarchy, decended from a TLCA. The essense of the hierarchy is the chaining relationship between the name of issuer of a certificate and the issuer name that is recorded in the certificate itself. They are obviously the same in the case of a certificate issued by a higher level CA to a subordinate CA in the same hierarchy, whereas they are not the same in the case of a cross-certificate. This becomes clearer if you think about starting at the bottom with an end-user certificate and climbing the tree for that chain. In a single hierarchy, there is a one to many relationship between issuers and subjects, but for any given subject, there is only one issuer. Given a certificate for some subordinate entity (CA or end-user), I should be able to extract the issuer name from that certificate, look up that distinguished name in a directory or other repository and thereby find the CA's own certificate, issued by the next higher level CA. And applying that procedure recursively, I should be able to climb the tree from the bottom up, until I come to a self-signed certificate which is issued by the TLCA. Presumably this is not the case for a cross-certified certificate. It occurs to me that this may be a major difference between what I am assuming and what I understand (perhaps incorrectly) that some others may be doing. If instead of looking up the issuer name in the directory, we looked up the subject name in the subjexct's own directory, and if ALL of the issuers of all of the certificates for that subject were to deposit their certificates in that directory, perhaps keyed somehow by the domain or TLCA of the various issuer hierarchies, then instead of following the subject/issuer chain in the certificate, we could follow the various chains in the _directory_, instead. But that would require that the subject of all certificates be responsible for publishing their own certificates, even if they had no relationship to the issuer of the certificate. I explicitly DON'T want to assume that level of cooperation, because I want my local IT group to be able to cross-certify some public CA's root key (or for that matter, some subordinate CA's key, or even an end-user's key, if necessary for efficiency's sake) without ANY involvement by that CA (or end-user) at all. On the other hand, I AM willing to assume that I operate my own local (or virtual) and perhaps TRUSTED (by me) directory, and that all of the certificates created by my own TLCA are deposited in that directory. Within MY hierarchy, anchored at the top by a TLCA I trust, and within my directory, all of the certificates appear to be perfectly normal. The subject to issuer names chain correctly, and even the issuer names plus serial numbers are correct. And within the single hierarchy of the end-user whose certificate is being validated, the certificates also appear normal, and chain correctly. The difficulty comes in knowing when to hop off of one chain and onto another, i.e., recognizing that a cross-certificate exists in the absence of the normal issuer plus serial number chaining. I therefore proposed the following algorithm for validating a certificate across two hierarchies, the relying party's domain and the subject's domain.: For simplicity, let's assume that the subject has provided an entire chain of certificates along with his digital signature, leading back to his own TLCA, but that I the relyuing party have not directly included that TLCA's key in my cache of trusted root keys. (If the subject has not provided the entire chain, then it may be necessary to find the various certificates within the subject's hierarchy/directory, or from some other repository, hinted at somehow. But this is a more or less irrelevant detail for the present argument.) 1. Given the subject's name, I look for a certificate corresponding to that name in my own directory, perhaps aided by a hint such as a hash of the public key. If I find a certificate for that subject name and key, I know that the subject's certificate is valid because I previously put it in my trusted directory, but I can also climb the certificate tree within my own hierarchy/directory and revalidate the chain if I wish. In either case the validation process has concluded successfully. 2. If I don't find the subject's name and public key in my hierarchy/directory, I must extract the issuer name from the certificate provided to me. Then, using that issuer name as a subject name, I repeat step (1), first looking in _my_ hierarchy/directory to see if I have already processed a cross-certificate for that CA. If I have, I can stop and the validation is successful; if not, I must continue up the _subject's_ certificate chain. 3. If I encounter a self-signed certificate in the subject's chain of certificates, signifying a TLCA for the subject's hierarchy, and I cannot find a corresponding subject name and key in my own hierarchy/directory, then the validation process has failed for lack of a common or cross-certified root key. Note that this process does not require that I go all the way up to the subject's TLCA before stopping. I can cross-certify some intermediate CA in the process, if necessary for efficiency, or perhaps because I trust that CA, but not necessarily other CA's higher up in that CA's chain. (I previously described a scenario involving the Utah National Guard, which might be certified by both the State of Utah and the Department of Defense. As a resident of Utah I might trust the Utah NG, but not the entire DOD chain of CAs.) It might be worth making another observation, to the effect that the above algorithm does NOT support transitive cross-certification. I first look in my own hierarchy, and if I don't find a certificate I climb the subject's hierarchy. At no time will I encounter a cross-certificate issued by some intermediate party. So if my IT organization issues a cross-certificate to the Government of Canada, I would accept all of the CAs and end-users certified by Canada, but I would never encounter a cross-certificate issued by Canada to Singapore. If I encountered an end-user's certificate from Singapore, I would end up checking my hierarchy and the Singapore hierarchy, but I would never encounter the Canadian cross-cert. I believe that is appropriate behavior, since transitive cross-certification seems altogether too scary. Hal Lockhardt said: >However, this now brings us to the engineering problem that somebody tried >to discuss a week or two back. Namely: how do we find all the certs we >need? If the cross cert is required to point to a cert in our chain, we >are all set, but what if the relationship is more indirect? Stealing >David's pictures: > > CA0 > (2) \ > CA1 ----> CA2 > / / \ > E1 E2 E3 > >Assuming E1 has the CA1 cert, this case is easy, but > > CA0 > (3) \ > CA1 ----> CA1a ----> CA2 > / / \ > E1 E2 E3 > >This requires a combination of bottom-up and top-down processing. This is >further complicated if we have to protect against loops. I believe that the above algorithm solves this problem, and is loop free in the case of well-formed hierarchies. If either of the two domains does in fact contain a loop, then either standard traverse-marking or counter technicques can be used to terminate processing. Finally, to respond to Denis point: >> 3. A cross-certificate is a certificate issued to a end-entity (CA or end-user) > >Bob, > >If you take a look at part 3,section 3.5, we have "cross-certification: >An requesting CA provides to a responding CA ..." this means that the >end-entity CANNOT be an end-user. > I would respectfully suggest that it is the quoted definition and/or the protocol that is broken, not the cross-certificate model. Although perhaps appropriate in the limited context (which I would argue was really addressing subordinate CA certificates, and not cross-certificates), in the general cross-certification case I reject the notion that there is necessarily any requesting/responding relationship between CAs at all. Therefore I as the cross-certifiying CA am perfectly free to certify any entity's name and public key I choose, whether a CA or an end-user, within my own hierarchy/directory/domain. Sorry for the length of this -- comments came in faster than I could type! Bob Robert R. Jueneman Security Architect Novell, Inc. Network Services Division 122 East 1700 South Provo, UT 84604 801/861-7387 bjueneman@novell.com "If you are trying to get to the moon, climbing a tree, although a step in the right direction, will not prove to be very helpful." "The most dangerous strategy is to cross a chasm in two jumps." From ???@??? Tue Jan 27 21:05:28 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id LAA11255 for ; Tue, 27 Jan 1998 11:51:36 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 12:54:59 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id LAA08841; Tue, 27 Jan 1998 11:51:05 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 24089 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 11:50:53 -0800 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id LAA07478 for ; Tue, 27 Jan 1998 11:50:50 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id OAA21273 for ; Tue, 27 Jan 1998 14:50:49 -0500 (EST) Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id OAA21269 for ; Tue, 27 Jan 1998 14:50:48 -0500 (EST) Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id OAA08136 for ; Tue, 27 Jan 1998 14:47:43 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id OAA04132; Tue, 27 Jan 1998 14:48:42 -0500 X-Sun-Charset: US-ASCII Message-ID: <199801271948.OAA04132@argon.ncsc.mil> Date: Tue, 27 Jan 1998 14:48:42 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "David P. Kemp" Subject: Re: [IETF-PKIX] mandatory PasswordBasedMac To: IETF-PKIX@LISTS.TANDEM.COM Status: > From: Bob > > > From: Carlisle > > > >This seems to be two votes in favor of HMAC-SHA-1 and no disagreements > >so far. I don't mind specifying this as the mandatory parameter in > >PasswordBasedMac, but let me repeat Nada's question: > > > >>BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does > >>anybody have a pointer to some document specifying it? > > > >I need this as soon as possible (i.e., within the next day or two). If > >an OID doesn't exist, should PKIX define one? > > I don't know the OID, but I believe that one was defined for SET, if > someone has that spec. > > Bob The IANA has registered OIDs for HMAC mechanisms as used by IPSEC: ftp://ftp.isi.edu/in-notes/iana/assignments/smi-numbers iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8) isakmpOakley(1) HMAC-md5(1) [1.3.6.1.5.5.8.1.1] iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8) isakmpOakley(1) HMAC-SHA(2) [1.3.6.1.5.5.8.1.2] The reference in the IANA document [Thayer] is missing, but it refers to the IPSEC document roadmap, which in turn references "The Use of HMAC-SHA-1-96 within ESP and AH", ftp://ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-01.txt which in turn references RFC 2104 "HMAC: Keyed Hashing for Message Authentication", the actual algorithm description. Note that these OIDs refer to a truncated HMAC where only the first 96 bits of the outer hash output are used - this truncation is described as a security advantage (it wasn't done solely to cram the MAC into the IPSEC packets). From ???@??? Tue Jan 27 21:05:28 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id LAA11498 for ; Tue, 27 Jan 1998 11:57:32 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 13:01:08 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id LAA09568; Tue, 27 Jan 1998 11:57:00 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 24120 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 11:56:52 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id LAA09179 for ; Tue, 27 Jan 1998 11:56:50 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 27 Jan 1998 12:56:19 -0700 X-Mailer: Novell GroupWise 5.2 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by Tandem.com id LAA09184 Message-ID: Date: Tue, 27 Jan 1998 12:55:15 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] cross-certification Comments: To: dpkemp@MISSI.NCSC.MIL To: IETF-PKIX@LISTS.TANDEM.COM Status: Dave, you've made some insightful comments. I'll therefore elaborate on my lengthy> message to >Al and Hal. > >>>> "David P. Kemp" 01/27 11:16 AM >>> >> From: Hal Lockhart >> >> I grant the wording is hard to follow, but the idea is simple. Just ask >> the question" Is the issuer attribute a back pointer? If yes, its >> hierarchical, if no, its a cross-cert. >> >> Hal > > >I thought it sounded simple too, until I drew the diagram and realized >that the issuer field in the subordinate CA's certificate didn't solve >anything - it's always a back pointer to something. > >Start with top-level CAs 0 and 1 again, or call them "Canada" and >"Singapore": > > CA0 "Canada" > \ > CA1 "Singapore" ----> CA2 "IBM" > / / \ > E1 E2 E3 > > >The problem is that CA2 has two certificates with the same public key >and possibly the same subject name (IBM), but with different issuer >names. Each Relying Party can choose which of CA0 or CA1 to use as >a trust anchor when validating E3's cert; for each choice there is an >available cert with CA2 as the subject and a valid back-pointing >issuer field. The key verb in that paragraph is the "has" in the first sentence. I agree that somewhere in the universe there exist the two certificates you mention, but I also believe that there is a significant difference in the state of knowledge of the relying parties who are "in" (trust) the Canada domain vs. the Singapore domain. If you buy my argument that unilateral cross-certification _may_ at least, be completely transparent and even oblivious to the CA and end-users within the domain that is being cross-certified, then to use your example, IBM and the users E2 and E3 may be completely ignorant of the Singapore domain, or any corss-certification between Singapore and Canada. In particular, if user E2 sends an S/MIME message to the PKIX list and includes E2's complete certificate chain, then that chain will contain certificates for E2, IBM, and Canada, period. If E3 is the relying party, there is obviously no problem, for E3 has a common root in Canada (and also a common subordinate CA, IBM, for that matter). But if E1 is the relying party, things are different. E1 knows about Singapore, but she doesn't know anything about Canada. When she tries to find and validate E2's certificate in the Singapoore hierarchy, she doesn't find it, so she has to climb _E2's_ chain, leading to IBM. Then, using my suggested algorithm she finds that Singapore has cross-certified IBM, and so the validation is successful. > >You have to invoke politics to determine which domain IBM belongs to, >and therefore which cert is the cross-cert. There doesn't seem to be >any way around that. >One possible solution is for both Singapore and Candada to agree that >CA2's real name is "C=CA, O=IBM". Any cert with CA2 as the subject >which didn't follow name subordination would be defined as a cross-cert. >But it doesn't seem useful to go through the process of labelling a >particular certificate as a cross-cert if there is no difference in >the path validation procedure as a result of assigning that label. "Politics" in this case is the simple "eye-of-the-beholder" rule. Although two certificates exist for IBM, and therefore there might be some ambiguity, there is no ambiguity at all as to which domain E2 and E3 belong to, as that is determined by the issuer and serial number. Since that points to one and only one certificate, and since that certificate in turn has an issuer and serial number, which domain E2 and E3 belong to is crystal clear -- Canada. It doesn't, and shouldn't, have anything to do with country of origin or other naming conventions. (Entrust might have been a better example than IBM -- clearly Entrust might have a branch office in Singapore that might nonetheless be a member of the Canadian hierarchy.) > >I'm starting to believe that if the term "cross-certification" is used >to mean anything more limited and specific than "CA-certification", >then the description of the difference belongs *only* in Part 4. > >For purposes of Part 1 and Part 3, they are synonymous unless someone >can come up with a concrete example where the difference has an >observable effect on 1) certificate contents, 2) path validation rules, >or 3) management protocol operations. This is, in fact, a Good Thing. >It means that X.509/PKIX is general enough to support the >political/operational act of "cross-certification" without requiring >any special-purpose syntax or protocol operations. You may have a point here. I believe that: 1. There is no observable difference in the certificate contents per se (one certificate at a time, at least), so X.509 would not seem to be impacted. That's obviously good. 2. There is a considerable difference in the relying party's path validation rules. Those rules will presumably need to be rewritten to handle the two independent hierarchy/directory/domain case as I previously described, assuming others accept this approach. 3. I'm not sure that I completely buy Carlisle's argument about need, likelyhood, or even the desirability of one CA requesting a cross-certificate from another CA, as it still requires out-of-band validation of the correctness or the attributes and proof-of-possession of the private key, but if the process which works for subordinate CAs also works for cross-certificates I am not opposed to it being included in the certificate management protocols. Thanks for all the fish, guys. This has been a fun discussion. Bob From ???@??? Tue Jan 27 21:05:31 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA12248 for ; Tue, 27 Jan 1998 12:23:53 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 13:27:29 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA12491; Tue, 27 Jan 1998 12:23:21 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 24200 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 12:23:12 -0800 Received: from tanglaptop215.mit.edu (TANGLAPTOP215.MIT.EDU [18.186.2.197]) by Tandem.com (8.8.8/2.0.1) with ESMTP id MAA12577 for ; Tue, 27 Jan 1998 12:13:11 -0800 (PST) Received: from mit.edu (localhost [127.0.0.1]) by tanglaptop215.mit.edu (8.8.7/8.8.4) with ESMTP id PAA00574; Tue, 27 Jan 1998 15:13:09 -0500 X-Mailer: Mozilla 4.04 [en] (X11; U; Linux 2.0.30 i586) MIME-Version: 1.0 References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8145C7876186167CDDD9ECCA" Message-ID: <34CE3FD2.28EA23C9@mit.edu> Date: Tue, 27 Jan 1998 15:13:06 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology Subject: Re: [IETF-PKIX] Is PKIX Patent-free? To: IETF-PKIX@LISTS.TANDEM.COM Status: Bob Jueneman wrote: > > It would be interesting to know whether the IETF and particularly the > IESG share this assumption. The IESG only reflects the consensus of the IETF as a whole. Time and time again we have polled the plenary (the best method we have to gauge the "sense" of the IETF) on issues important to the IETF. We also have the POISED working group, which defines the standards process, which also deals with this issue. Personal opinions of individual IESG members can influence discussions (we are only human), however on important policy matters we are tasked to go with the community perspective making use of our best technical judgment. It is my experience that the sense of the community is formed in a large part by how patent holders in this space have behaved in the past. Let me propose that we terminate this discussion here. If people feel one way or the other about IETF intellectual property policies, the place to raise it is in the POISED working group. -Jeff Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Attachment converted: Lutefisk:smime.p7s 38 (????/----) (0001E321) From ???@??? Tue Jan 27 21:05:32 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA12499 for ; Tue, 27 Jan 1998 12:33:29 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 13:36:52 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA13315; Tue, 27 Jan 1998 12:32:26 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 24304 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 12:32:22 -0800 Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id MAA16324 for ; Tue, 27 Jan 1998 12:32:21 -0800 (PST) Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 27 Jan 1998 13:31:51 -0700 X-Mailer: Novell GroupWise 5.2 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by Tandem.com id MAA16325 Message-ID: Date: Tue, 27 Jan 1998 13:31:40 -0700 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Bob Jueneman Subject: Re: [IETF-PKIX] mandatory PasswordBasedMac Comments: To: dpkemp@MISSI.NCSC.MIL To: IETF-PKIX@LISTS.TANDEM.COM Status: > >The IANA has registered OIDs for HMAC mechanisms as used by IPSEC: > > ftp://ftp.isi.edu/in-notes/iana/assignments/smi-numbers > >iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8) >isakmpOakley(1) HMAC-md5(1) [1.3.6.1.5.5.8.1.1] >iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8) >isakmpOakley(1) HMAC-SHA(2) [1.3.6.1.5.5.8.1.2] > >The reference in the IANA document [Thayer] is missing, but it refers >to the IPSEC document roadmap, which in turn references "The Use of >HMAC-SHA-1-96 within ESP and AH", > > ftp://ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-01.txt > >which in turn references RFC 2104 "HMAC: Keyed Hashing for Message >Authentication", the actual algorithm description. > >Note that these OIDs refer to a truncated HMAC where only the first >96 bits of the outer hash output are used - this truncation is described >as a security advantage (it wasn't done solely to cram the MAC into >the IPSEC packets). As usual when adopting a standard intended for one purpose for another completely different one, you need to be careful to ensure that the standards are meeting the same needs. Although I haven't followed the use of HMAC in IPSEC, I would have serious reservations about the use of ANY hash algorithm that is only 96 bits long, unless I had wralked though all of the possible attack scenarios very carefully. The problem, of course, is that a Birthday Problem attack on a 96 bit hash only requires on the order of 2^48 calculations to defeat it. Although there may be a security advantage in doing some truncation (e.g., to protect against attempts to extract the secret salt), 96 bits is far too short for comfort. If we can't find anything else, we should write up and use a varient of HMAC that is somewhere between 128 and 140 bits long, I believe. Bob Robert R. Jueneman Security Architect Novell, Inc. Network Services Division 122 East 1700 South Provo, UT 84604 801/861-7387 bjueneman@novell.com "If you are trying to get to the moon, climbing a tree, although a step in the right direction, will not prove to be very helpful." "The most dangerous strategy is to cross a chasm in two jumps." From ???@??? Tue Jan 27 21:04:54 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id EAA00387 for ; Tue, 27 Jan 1998 04:39:58 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 05:43:21 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id EAA02795; Tue, 27 Jan 1998 04:39:35 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 22689 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 04:38:09 -0800 Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.17]) by Tandem.com (8.8.8/2.0.1) with ESMTP id EAA26583 for ; Tue, 27 Jan 1998 04:28:02 -0800 (PST) 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 NAA15643 for ; Tue, 27 Jan 1998 13:28:37 +0100 Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (8.7.5/8.7.3) with SMTP id NAA31858 for ; Tue, 27 Jan 1998 13:27:39 +0100 X-Mailer: Mozilla 3.01 [fr] (Win16; I) MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <34CE5145.29AE@bull.net> Date: Tue, 27 Jan 1998 13:27:33 -0800 Reply-To: Denis.Pinkas@bull.net Sender: "IETF X.509-based public key infrastructure mailing list" From: Denis Pinkas Organization: Bull Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: Bob Jueneman wrote: > >If we could come up with a simple and consensus-agreed definition > >which could be quickly inserted into CMP, that would be ideal. > >Can you write such a definition? (I can't.) > > How's this: (...) > 3. A cross-certificate is a certificate issued to a end-entity (CA or end-user) Bob, If you take a look at part 3,section 3.5, we have "cross-certification: An requesting CA provides to a responding CA ..." this means that the end-entity CANNOT be an end-user. Denis -- *** Please note that the E-mail address has changed ! Update it. *** Denis Pinkas Bull S.A. E-mail : 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 From ???@??? Tue Jan 27 21:05:34 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id NAA14261 for ; Tue, 27 Jan 1998 13:46:17 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 14:49:40 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id NAA19508; Tue, 27 Jan 1998 13:44:28 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 24525 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 13:44:00 -0800 Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.146]) by Tandem.com (8.8.8/2.0.1) with SMTP id NAA28799 for ; Tue, 27 Jan 1998 13:43:58 -0800 (PST) Received: tid QAA04462; Tue, 27 Jan 1998 16:38:32 -0500 Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD2B41.7F21C4B0@mail.entrust.com>; Tue, 27 Jan 1998 16:34:54 -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 Message-ID: Date: Tue, 27 Jan 1998 16:34:52 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: Carlisle Adams Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: Hi Bob, One comment... >---------- >From: Bob Jueneman[SMTP:BJUENEMAN@NOVELL.COM] >Sent: Tuesday, January 27, 1998 2:16 PM >To: IETF-PKIX@LISTS.TANDEM.COM >Subject: Re: [IETF-PKIX] cross-certification > >If instead of looking up the issuer name in the directory, we looked up the >subject name in the subjexct's own directory, and if ALL of the issuers of >all of the certificates for that subject were to deposit their certificates >in that directory, perhaps keyed somehow by the domain or TLCA of the various >issuer hierarchies, then instead of following the subject/issuer chain in >the certificate, we could follow the various chains in the _directory_, >instead. > >But that would require that the subject of all certificates be responsible >for publishing their own certificates, even if they had no relationship to >the issuer of the certificate. > >I explicitly DON'T want to assume that level of cooperation, because I want >my local IT group to be able to cross-certify some public CA's root key (or >for that matter, some subordinate CA's key, or even an end-user's key, if >necessary for efficiency's sake) without ANY involvement by that CA (or >end-user) at all. Note that a cross-certificate can be published by the subject in the "forward" parameter of a CertificatePair in the subject's directory entry AND / OR can be published by the issuer in the "reverse" parameter of a CertificatePair in the issuer's directory entry. It is not actually necessary to force issuers to be the publishers of cross-certificates in their own entries, or to force subjects to be the publishers of cross-certificates in their own entries. Either scenario can be used and, in fact, publishing in BOTH places (when possible and appropriate) will allow greater flexibility in the path construction / validation logic. In other words, the path processing logic should not make an assumption about where cross-certificates will be found (i.e., only subject's entry or only issuer's entry). It should be able to look in both places before giving up. -------------------------------------------- Carlisle Adams Entrust Technologies cadams@entrust.com -------------------------------------------- From ???@??? Tue Jan 27 21:05:35 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id NAA14275 for ; Tue, 27 Jan 1998 13:49:15 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 14:52:45 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id NAA19842; Tue, 27 Jan 1998 13:48:08 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 24545 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 13:48:02 -0800 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by Tandem.com (8.8.8/2.0.1) with ESMTP id NAA29549 for ; Tue, 27 Jan 1998 13:48:01 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA24378 for ; Tue, 27 Jan 1998 16:48:00 -0500 (EST) Received: from depot.missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA24374 for ; Tue, 27 Jan 1998 16:47:59 -0500 (EST) Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id QAA08987 for ; Tue, 27 Jan 1998 16:42:06 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id QAA04165; Tue, 27 Jan 1998 16:43:05 -0500 X-Sun-Charset: US-ASCII Message-ID: <199801272143.QAA04165@argon.ncsc.mil> Date: Tue, 27 Jan 1998 16:43:05 -0500 Reply-To: "IETF X.509-based public key infrastructure mailing list" Sender: "IETF X.509-based public key infrastructure mailing list" From: "David P. Kemp" Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: > From: "Bob Jueneman" > > Although two certificates exist for IBM, and therefore there might be > some ambiguity, there is no ambiguity at all as to which domain E2 and > E3 belong to, as that is determined by the issuer and serial number. > Since that points to one and only one certificate, and since that > certificate in turn has an issuer and serial number, which domain E2 > and E3 belong to is crystal clear -- Canada. Nope. The issuer/serialNumber can uniquely identify a particular cert belonging to (say) E2, but it does not uniquely identify either the issuer's (IBM's) cert or E2's domain. E2 belongs to whatever domain he chooses. If E2 has a cert issued by IBM, and IBM has two certs (issued by Singapore and Canada) both of which are available to E2 and which have the same subject name and public key, then E2 can configure his S/MIME user agent to 1) generate cert paths starting at either root when sending messages, and 2) trust any number of roots (Canada, Singapore, VeriSign, Entrust, GTE, Thawte, etc) when validating received messages. E3 can make a similar choice of domain membership, and it does not have to be the same as E2's. There may be external administrative restrictions on how E2 and E3 configure their domain membership, but nothing in PKIX forces them to belong to, say, Canada. > Thanks for all the fish, guys. This has been a fun discussion. Likewise. From ???@??? Tue Jan 27 21:04:54 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id EAA00876 for ; Tue, 27 Jan 1998 04:57:23 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 06:00:46 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id EAA03468; Tue, 27 Jan 1998 04:57:07 -0800 (PST) Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 22719 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 04:55:39 -0800 Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.17]) by Tandem.com (8.8.8/2.0.1) with ESMTP id EAA27575 for ; Tue, 27 Jan 1998 04:45:35 -0800 (PST) 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 NAA16688 for ; Tue, 27 Jan 1998 13:46:06 +0100 Received: from dese22.frcl.bull.fr (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (8.7.5/8.7.3) with SMTP id NAA29128 for ; Tue, 27 Jan 1998 13:45:15 +0100 X-Mailer: Mozilla 3.01 [fr] (Win16; I) MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <34CE5565.1F79@bull.net> Date: Tue, 27 Jan 1998 13:45:09 -0800 Reply-To: Denis.Pinkas@bull.net Sender: "IETF X.509-based public key infrastructure mailing list" From: Denis Pinkas Organization: Bull Subject: Re: [IETF-PKIX] cross-certification To: IETF-PKIX@LISTS.TANDEM.COM Status: Carlisle Adams wrote: (text deleted) > Relying Party: a relying party of a CA is an entity that validates > certificate chains using the public key of that CA as an end-point > (i.e., a trust anchor). If we were going to need and keep that definition, then I would prefer the following wording: Relying Party: a relying party of a CA is an entity that validates certificate chains using one or more self-signed certificates of that CA as an end-point (i.e., a trust anchor). (text deleted) An intuitive difference between a CA-certificate and a cross-certificate is that a CA-certificate is a certificate simply stating that this is a certificate issued by one CA for another CA, whereas a cross-certificate implies that at the time the certificate is generated, the two CAs have loose relationships. This may mean that they are in different naming hierarchies and/or different organizational structures. Let me make a try and put a Euro (instead of a cent) into the balance :-) Cross-certificate: A CA-certificate issued by one CA for another CA that is either in a different naming hierarchy and/or in a different organizational structure. Denis -- *** Please note that the E-mail address has changed ! Update it. *** Denis Pinkas Bull S.A. E-mail : 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 From ???@??? Tue Jan 27 21:05:37 1998 Return-Path: Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id OAA14785 for ; Tue, 27 Jan 1998 14:10:32 -0800 Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 15:14:09 -0700 Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id OAA21640; Tue, 27 Jan 1998 14:04:29 -0800 (PST) Received: from LIST