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