From owner-ietf-pkix@imc.org Thu Jun 1 01:15:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05979 for ; Thu, 1 Jun 2000 01:15:51 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA03183; Wed, 31 May 2000 22:07:00 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 31 May 2000 22:06:50 -0700 Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA03143 for ; Wed, 31 May 2000 22:06:48 -0700 (PDT) Received: from tot-tq.proxy.aol.com (tot-tq.proxy.aol.com [152.163.201.1]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id BAA05648 for ; Thu, 1 Jun 2000 01:13:39 -0400 (EDT) Received: from djs300y (AC9C79B2.ipt.aol.com [172.156.121.178]) by tot-tq.proxy.aol.com (8.10.0/8.10.0) with ESMTP id e515DcJ12396 for ; Thu, 1 Jun 2000 01:13:38 -0400 (EDT) Date: Thu, 1 Jun 2000 01:13:38 -0400 (EDT) Message-ID: <01a001bfcb88$1afad460$0100a8c0@djs300y> From: "Dennis Solomon" To: Subject: Legal Assistance MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Apparently-From: Solomondj@aol.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA03144 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit EMAIL: ietf-pkix@imc.org Dear Friends, I am in need of an excellent intellectual property litigator to recover my rights and damages related to the theft of my trade secrets by the principals of Microvision, Inc., NASDAQ: MVIS. I believe I am the first and original inventor of the virtual retinal display, and filed papers with the U.S. Patent Office over one year prior to the first filing by Microvision. The principals I later discovered were doing business with the small electronics firm where I was conducting my experiments. They were later paid over $200,000 by them. The present market value of the technology in over $200,000,000. The details may be found at my new website: www.citizenslaw.net Thank you. Dennis djs@citizenslaw.net Dennis J. Solomon P.O. Box 289 Yarmouth Port, MA 02675 From owner-ietf-pkix@imc.org Thu Jun 1 05:26:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17973 for ; Thu, 1 Jun 2000 05:26:23 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA14304; Thu, 1 Jun 2000 02:15:04 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jun 2000 02:14:15 -0700 Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14260 for ; Thu, 1 Jun 2000 02:14:13 -0700 (PDT) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id TAA16230; Thu, 1 Jun 2000 19:21:26 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd00Q4mO; Thu Jun 1 19:21:05 2000 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id TAA17337; Thu, 1 Jun 2000 19:21:05 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdpqC0x_; Thu Jun 1 19:20:47 2000 Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id TAA06118; Thu, 1 Jun 2000 19:20:46 +1000 (EST) Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 19:20:16 +1000 Message-ID: <73388857A695D31197EF00508B08F2988A3BC3@ntmsg0131.corpmail.telstra.com.au> From: "Manger, James H" To: "'Ed Gerck'" Cc: ietf-pkix@imc.org Subject: RE: TSA Response serialNumber Field Date: Thu, 1 Jun 2000 19:20:07 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Ed, The TSTInfo ASN.1 type has a field labelled "accuracy" that "represents the time deviation around the UTC time contained in GeneralizedTime" (quoting from the draft) [a misleading label & poorly worded sentence]. Its function is to indicate how close the stated time is likely to be to UTC. The field is meant to be useful to a relying party when they compare the time in the timestamp to any other time (e.g. a deadline, a revocation date in a CRL, validity dates in a certificate, another timestamp). I think the field should be labelled "uncertainty" and I suspect you would label it "reliability". A TSA would determine the value of the field from historical measurements of how much adjustment was required when synchronising with other clocks, perhaps factoring in the clock drift specification from the manufacture (e.g. +/-3 milliseconds/day) plus a safety margin (to err on the conservative side). Now, given that the "accuracy" field actually conveys uncertainty, do I really need to know the accuracy as well? How would a comparison work if you knew the uncertainty and accuracy? -----Original Message----- From: Ed Gerck [ mailto:egerck@nma.com] Sent: Wednesday, 31 May 2000 13:42 .. Now, if by "accuracy" above you mean uncertainty then I would have to ask about their accuracies, since the time values may have very low uncertainty and still be as far apart as apples and speedboats. So, to the original question: "How do I do it [compare the stamps]?" The answer must be (for what was provided): insufficient data. From owner-ietf-pkix@imc.org Thu Jun 1 13:23:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27909 for ; Thu, 1 Jun 2000 13:23:02 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA04604; Thu, 1 Jun 2000 10:11:25 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jun 2000 10:10:59 -0700 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04566 for ; Thu, 1 Jun 2000 10:10:57 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 13:19:20 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04BFE3@panda.chrysalis-its.com> To: Denis.Pinkas@bull.net Cc: ietf-pkix@imc.org Subject: RE: Rationale for Nonce in Time Stamp Protocol Date: Thu, 1 Jun 2000 13:18:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA04567 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Saying only "or" instead of "and/or" would be fine with me. Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent: Wednesday, May 31, 2000 10:52 AM To: FRousseau@chrysalis-its.com Cc: ietf-pkix@imc.org Subject: Re: Rationale for Nonce in Time Stamp Protocol François, > Salut Denis, > > I agree with both the word change and the proposed pointer. > > However, I still think that leaving the term "timeliness" in Section 2.2 > could be misinterpreted to mean that a requesting entity MUST reject a > totally valid response because of possible delays in the intervening network > elements and/or a drifting of this requesting entity own local time > reference. > > According to Section 2.2, what would a requesting entity be required to do > if he/she receives a time stamp token with the right hash value and nonce, > however the time included in the response is before or very much later than > his/her own local trusted time reference? The current sentence is: ... by verifying *either* the time included in the response against a local trusted time reference, if one is available, *and/or* the value of the nonce (large random number with a high probability that it is generated by the client only once) included in the response against the value included in the request. Instead of "and/or", we could say "or". Would this solve your concern ? Denis From owner-ietf-pkix@imc.org Thu Jun 1 15:43:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01989 for ; Thu, 1 Jun 2000 15:43:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA06619; Thu, 1 Jun 2000 12:28:39 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jun 2000 12:28:29 -0700 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06587 for ; Thu, 1 Jun 2000 12:28:28 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVH00IJ7QEEMV@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 1 Jun 2000 12:35:03 -0700 (PDT) Date: Thu, 01 Jun 2000 12:34:57 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: "Manger, James H" Cc: ietf-pkix@imc.org Message-id: <3936BAE1.ECCBB0DD@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <73388857A695D31197EF00508B08F2988A3BC3@ntmsg0131.corpmail.telstra.com.au> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit "Manger, James H" wrote: > Ed, > > The TSTInfo ASN.1 type has a field labelled "accuracy" that "represents the > time deviation around the UTC time contained in GeneralizedTime" (quoting > from the draft) [a misleading label & poorly worded sentence]. Its function > is to indicate how close the stated time is likely to be to UTC. The field > is meant to be useful to a relying party when they compare the time in the > timestamp to any other time (e.g. a deadline, a revocation date in a CRL, > validity dates in a certificate, another timestamp). I think the field > should be labelled "uncertainty" and I suspect you would label it > "reliability". I would label it "uncertainty" -- so we are in agreement on this change, but would rewrite the quote also. I initially suggest: "uncertainty" -- represents the time deviation around the UTC time contained in GeneralizedTime, with high reliability. which, btw, explains why I would NOT name it "reliability" [1]. The draft must also define "high reliability" and the allowed statistics (see [1] and my comments below). Using this definition, we may say that with a reliability of 95% the UTC time lies between [To - 1.2] and [To + 1.2] s -- when we are given an uncertainty of 2.4 s and consider "high reliability" defined as 95% for a gaussian distribution. With gaussian distributions, this directly means that the standard deviation is 1.2 s [2]. Clearly, just saying "uncertainty = 2.4 s" is not enough, without the reliability. If the reliability would be 99% then the standard deviation for the *same* uncertainty of 2.4 s would be 0.8 s [2]. About "high reliability" in my suggested definition change -- I know that defining high reliability may be tricky (and soon, outdated) -- but this can be done well by reference. The draft could define a parameter called "reliability level" (for example) which the TSA associates to a statistic distribution and sets as high as it can put its money to it ;-) -- for example, 99,9997% [2]. This limit will also provide a useful parameter to estimate the quality of service, to calculate risks, to estimate insurance costs, etc. Note that the TSA bears a risk not only in setting the reliability level but also in declaring that its data follows a statistic distribution -- for example, if we use gaussian statistics to model the stock market there is a tail that significantly exceeds that expected from Gaussian statistics, where the 1929 and 1987 stock market crashes were each about a 10 sigma event (ie, 10 times than the standard deviation), which would only happen once in the lifetime of the planet under Gaussian statistics [2]. It is also interesting to note that even if "high reliability" is 70% it might still be useful if the uncertainty is low enough -- and the price. It is a one sigma event [2]. > Now, given that the "accuracy" field actually conveys uncertainty, do I > really need to know the accuracy as well? How would a comparison work if > you knew the uncertainty and accuracy? ;-) let's make clear which is which, first. We have four quantitites: 1. accuracy: that rather arbitrary fine precision that the TSA sets for its timestamp ordering purposes. 2. uncertainty: set and guaranteed by the TSA, as given above. 3. reliability: set and guaranteed by the TSA, as given above. 4. statistics: set and guaranteed by the TSA, as given above. Thus, just having uncertainty and even accuracy does not allow you to compare time between two different TSAs for which you know nothing about their reliability nor about their statistics (as was the case in that example [3]) So, how would a comparison work for two timestamps T1 and T2, each one from a different TSA -- with different accuracies, uncertainties, reliabilities and statistics? For each timestamp, you have the uncertainty AND the reliability as given by each TSA. You would use a statistical model that both TSAs agree with (eg, gaussian) with each value in respective full accuracy and compute the probability that T1 >= T2. If this probability is larger than 50%, then T1 >- T2, otherwise it is T1 < T2. Let me build an example using data from Michaels': T1. Stamp from TSA_1: 20000529053138.34509878Z. accuracy = 8 digits uncertainty = 1 s reliability = 95% statistics: gauss T2. Stamp from TSA_2: 20000529053138.876Z. accuracy = 3 digits uncertainty = 1.5 s reliability = 99% statistics: gauss How do I do it [compare the stamps]? Even though the uncertainties are different, the sigmas are the same for each case, as we see from [2]. The sigma is 0.5 s and we see that T2 - T1 > sigma. Thus we may directly compare T1 with T2 and say that T2 > T1. Otherwise, we would need to calculate using the appropriate gaussian statistics for each. Now, if we had (with an added "9" in the timestamp for ordering purposes): T1'. Stamp from TSA_1: 20000529053138.345098789Z. accuracy = 8 digits uncertainty = 1 s reliability = 95% statistics: gauss then we could NOT say that T1' > T1 even if we take into account that they came from the same TSA. We could only say that the TSA issued T1' AFTER issuing T1. Further, if we had: T2'. Stamp from TSA_2: 20000529053138.345098789Z. accuracy = 3 digits uncertainty = 1.5 s reliability = 99% statistics: gauss then we could say nothing about T2' being issued before or after T1, much less whether T1' > T1 or not. Cheers, Ed Gerck [1] When estimating the mean of a normal distribution, the sample average provides a point estimate or best guess about the value of the mean. However, this estimate is almost surely not exactly correct. A confidence interval provides a range of values around that estimate to show how precise the estimate is. The reliability level (also called confidence level) associated with the interval, usually 90%, 95%, or 99%, is the percentage of times in repeated sampling that the intervals will contain the true value of the unknown parameter. See [2]. [2] A gaussian distribution with a standard deviation value "sigma" has, approximately: 69% of all events within one sigma, 95% of all events within two sigma, 99% of all events within three sigma. Nearly 100% (exactly: 99,9997%) of all events are covered in the range of six sigma -- in other words: out of an amount of 1 Million events only 3 events are outside the range of six sigma. [3] > -----Original Message----- > From: Ed Gerck [ mailto:egerck@nma.com] > Sent: Wednesday, 31 May 2000 13:42 > > .. > Now, if by "accuracy" above you mean uncertainty then I would have to > ask about their accuracies, since the time values may have very low > uncertainty > and still be as far apart as apples and speedboats. > > So, to the original question: "How do I do it [compare the stamps]?" > The answer must be (for what was provided): insufficient data. From owner-ietf-pkix@imc.org Thu Jun 1 15:54:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02146 for ; Thu, 1 Jun 2000 15:54:50 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA07005; Thu, 1 Jun 2000 12:42:26 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jun 2000 12:42:24 -0700 Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06975 for ; Thu, 1 Jun 2000 12:42:24 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirsx16707; Thu, 1 Jun 2000 19:50:12 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA06534; Thu, 1 Jun 00 15:46:42 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA04330; Thu, 1 Jun 2000 15:50:10 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14646.48754.723416.282742@xedia.com> Date: Thu, 1 Jun 2000 15:50:10 -0400 (EDT) To: egerck@nma.com Cc: James.H.Manger@team.telstra.com, ietf-pkix@imc.org Subject: Re: TSA Response serialNumber Field References: <73388857A695D31197EF00508B08F2988A3BC3@ntmsg0131.corpmail.telstra.com.au> <3936BAE1.ECCBB0DD@nma.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Whenever someone creates a discussion like this where "reliability" and "accuracy" (or, similarly, "accuracy" and "tolerance" or "accuracy" and "precision") are used with the intent of describing quite *different* things, alarms go off. I find that such discussions tend to be difficult if not impossible to understand, and it isn't at all clear whether the conclusions are meaningful. Take the case discussed here. Since we're dealing with variables having some statistical distribution (though very likely *not* one of the mathematically tractable ones statisticians like to work with) it is clear that any bounds specified have some probability associated with them. If I specify bounds such that the probability of being outside those bounds is high, I suppose one might speak of this as "low reliability". I'd rather not, because to me reliability is a term that describes the lack of brokenness. (Or do you want to say that specifying overly optimistic bounds means you're broken? I guess I could go for that...) If we had a well defined distribution of the random variable, we could talk about mean and standard deviation. But I don't believe we do; in particular I do know that it is a mistake to think that the distribution is Normal. Also, consider the intended usage. One major reason we want to have TSAs is so we can timestamp information with legally convincing timestamps. In other words, we want to be able to answer the question "did T1 occur before T2" well enough that we can stand up in court and give that answer. Not just here on this list... :-) This gives me a criterion for chosing the bounds I would advertise in a timestamp: they are chosen reasonably tightly, but such that I am willing to stand up in court and testify to the effect that an event timestamped as [t - a .. t + a] did indeed occur within a of UTC t. In other words, I pick "a" large enough that I am not worried about the likelihood of being shown wrong when I make that testimony. Does that mean that I'm implicitly setting "reliability" as Ed uses the term, to the value "high enough for legal work"? paul From owner-ietf-pkix@imc.org Thu Jun 1 17:16:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03991 for ; Thu, 1 Jun 2000 17:16:13 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA08523; Thu, 1 Jun 2000 13:59:06 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jun 2000 13:58:56 -0700 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08492 for ; Thu, 1 Jun 2000 13:58:55 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVH00LGXTURLO@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 1 Jun 2000 13:49:39 -0700 (PDT) Date: Thu, 01 Jun 2000 13:49:33 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: Paul Koning Cc: James.H.Manger@team.telstra.com, ietf-pkix@imc.org Message-id: <3936CC5D.C8F444E3@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <73388857A695D31197EF00508B08F2988A3BC3@ntmsg0131.corpmail.telstra.com.au> <3936BAE1.ECCBB0DD@nma.com> <14646.48754.723416.282742@xedia.com> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Paul Koning wrote: > Whenever someone creates a discussion like this where "reliability" > and "accuracy" (or, similarly, "accuracy" and "tolerance" or > "accuracy" and "precision") are used with the intent of describing > quite *different* things, alarms go off. ;-) My alarms too -- especially when such terms are used to mean quite *different* things than usage in the corresponding technical field. > If we had a well defined distribution of the random variable, we could > talk about mean and standard deviation. But I don't believe we do; in > particular I do know that it is a mistake to think that the > distribution is Normal. That is up to each TSA to specify, according to my suggestion. And I recall that it always makes sense to talk about "mean" and "standard deviation" for *any* distribution of like things (apples with apples) -- even if the distribution is not Normal (Gauss). > Also, consider the intended usage. One major reason we want to have > TSAs is so we can timestamp information with legally convincing > timestamps. In other words, we want to be able to answer the question > "did T1 occur before T2" well enough that we can stand up in court and > give that answer. Not just here on this list... :-) > That is why we need: (i) to call a dodo a dodo, (ii) to make sure that we are comparing dodos to dodos and not to platipus. Of course, this WG is free to create all sorts of names and concepts de novo, as well as to rename the entire corpus of engineering and law. I suggest this is not in our best interest, though. BTW, just taking a look at the new IETF "glossary" should convince us that we may have already gone too far in our solipsistic phantasies as we start to rename that which we ourselves named ;-) > This gives me a criterion for chosing the bounds I would advertise in > a timestamp: they are chosen reasonably tightly, but such that I am > willing to stand up in court and testify to the effect that an event > timestamped as [t - a .. t + a] did indeed occur within a of UTC t. > In other words, I pick "a" large enough that I am not worried about > the likelihood of being shown wrong when I make that testimony. > > Does that mean that I'm implicitly setting "reliability" as Ed and engineering textbooks > uses > the term, to the value "high enough for legal work"? well, that means you *wish* to do so -- and you may not suceed if the other side can show with *equal* reliability that you are wrong. Perhaps, even less than equal would suffice -- reasonable doubt is enough. To exemplify why the concept of reliability is important, and quite disticnt from uncertainty and accuracy, pls read my former email when I wrote: Clearly, just saying "uncertainty = 2.4 s" is not enough, without the reliability. If the reliability would be 99% then the standard deviation for the *same* uncertainty of 2.4 s would be 0.8 s [2]. (and not 1.2 s) Cheers, Ed Gerck From owner-ietf-pkix@imc.org Thu Jun 1 17:23:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04170 for ; Thu, 1 Jun 2000 17:23:39 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA08832; Thu, 1 Jun 2000 14:08:02 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jun 2000 14:08:01 -0700 Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08802 for ; Thu, 1 Jun 2000 14:08:00 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirtd20806; Thu, 1 Jun 2000 21:15:49 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA07615; Thu, 1 Jun 00 17:12:19 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id RAA04622; Thu, 1 Jun 2000 17:15:48 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14646.53892.318970.319672@xedia.com> Date: Thu, 1 Jun 2000 17:15:48 -0400 (EDT) To: egerck@nma.com Cc: James.H.Manger@team.telstra.com, ietf-pkix@imc.org Subject: Re: TSA Response serialNumber Field References: <73388857A695D31197EF00508B08F2988A3BC3@ntmsg0131.corpmail.telstra.com.au> <3936BAE1.ECCBB0DD@nma.com> <14646.48754.723416.282742@xedia.com> <3936CC5D.C8F444E3@nma.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit >>>>> "Ed" == Ed Gerck writes: Ed> Paul Koning wrote: >> If we had a well defined distribution of the random variable, we >> could talk about mean and standard deviation. But I don't believe >> we do; in particular I do know that it is a mistake to think that >> the distribution is Normal. Ed> That is up to each TSA to specify, according to my suggestion. Ed> And I recall that it always makes sense to talk about "mean" and Ed> "standard deviation" for *any* distribution of like things Ed> (apples with apples) -- even if the distribution is not Normal Ed> (Gauss). Well, I never got very far in that area of Math. Here's why I brought up the issue: Suppose we define that the timestamp will contain the mean and standard deviation. What will that actually tell you? If you know the distribution (e.g., Normal) you can answer the question "with 0.999999 confidence, what are the bounds". With an unknown distribution, you cannot do that. So clearly standard deviation is not useful. That leaves two possibilities: a. What I suggested before: mean plus bound chosen so the confidence is "very high". b. Mean plus bound plus confidence value -- preferably with the recommendation that the confidence value should be a number quite close to 1. (I don't think I want to do business with a TSA that reports intervals with "confidence 0.68"...) paul From owner-ietf-pkix@imc.org Thu Jun 1 18:32:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05905 for ; Thu, 1 Jun 2000 18:32:53 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA09738; Thu, 1 Jun 2000 15:16:14 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jun 2000 15:16:04 -0700 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09708 for ; Thu, 1 Jun 2000 15:16:03 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVH001A5XWT6F@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 1 Jun 2000 15:17:18 -0700 (PDT) Date: Thu, 01 Jun 2000 15:17:11 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: Paul Koning Cc: James.H.Manger@team.telstra.com, ietf-pkix@imc.org Message-id: <3936E0E7.AC7B6DF7@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <73388857A695D31197EF00508B08F2988A3BC3@ntmsg0131.corpmail.telstra.com.au> <3936BAE1.ECCBB0DD@nma.com> <14646.48754.723416.282742@xedia.com> <3936CC5D.C8F444E3@nma.com> <14646.53892.318970.319672@xedia.com> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Paul Koning wrote: > > Ed> That is up to each TSA to specify, according to my suggestion. > Ed> And I recall that it always makes sense to talk about "mean" and > Ed> "standard deviation" for *any* distribution of like things > Ed> (apples with apples) -- even if the distribution is not Normal > Ed> (Gauss). > > Suppose we define that the timestamp will contain the mean and > standard deviation. What will that actually tell you? > > If you know the distribution (e.g., Normal) you can answer the > question "with 0.999999 confidence, what are the bounds". With an > unknown distribution, you cannot do that. So clearly standard > deviation is not useful. Let me recall that you can indeed compare reliability values by using the standard deviation for statistics other than gaussian (normal). This shows why it is useful to include the *four* types of information I suggested for the TSA (and not just that "accuracy" -- which is a meaningless number by itself, and misleadingly named as it was): 1. accuracy: that rather arbitrary fine precision that the TSA sets for its timestamp ordering purposes. 2. uncertainty: set and guaranteed by the TSA, as given above. 3. reliability: set and guaranteed by the TSA, as given above. 4. statistics: set and guaranteed by the TSA, as given above. For example ([2] in my posting before), in the case of gaussian statistics, 95% reliability corresponds to an uncertainty which is twice the standard deviation. On these matters, to save cyber trees, I looked for some references on the web that could help provide some examples for each concept. I found the ones below, which can be helpful (I am sure there are many others): http://bjmath.com/bjmath/Stats/sd.htm http://bjmath.com/bjmath/Stats/sd.htm http://bjmath.com/bjmath/Stats/confide.htm > That leaves two possibilities: > > a. What I suggested before: mean plus bound chosen so the confidence > is "very high". these numbers cannot be taken out of the blue yonder, but must be based on a sound and objective basis -- mean, bound and confidence cannot be arbitrary. Further, "very high" confidence (ie, reliability) may indeed mean 60% in some cases and this may be as good as 99% in other cases -- as I exemplified in my previous posting with 95% and 99%. > b. Mean plus bound plus confidence value -- preferably with the > recommendation that the confidence value should be a number quite > close to 1. (I don't think I want to do business with a TSA that > reports intervals with "confidence 0.68"...) > Would it surprise you to know that a confidence (reliability) level of 68% for an uncertainty of 0.2 s is much better than 99% for an uncertainty of 1 s, in terms of gauss distributions? Further, without specifying to which statistical distribution the value (mean), the uncertainty (bound) and the reliability (confidence) apply to, the TSA is essentially selling snake oil. Let's keep this in mind -- statistics is quite useless unless the terms are well defined, as politics exemplifies all the time ;-) As another example, I wish to recall the case of that guy who drowned in a lake that had one inch depth on average -- he fell in a 40 ft deep hole. Cheers, Ed Gerck From owner-ietf-pkix@imc.org Thu Jun 1 20:07:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07442 for ; Thu, 1 Jun 2000 20:07:38 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA10983; Thu, 1 Jun 2000 16:54:59 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jun 2000 16:54:49 -0700 Received: from goose.prod.itd.earthlink.net (goose.prod.itd.earthlink.net [207.217.120.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA10953 for ; Thu, 1 Jun 2000 16:54:49 -0700 (PDT) Received: from winnt (2Cust53.tnt6.sfo1.da.uu.net [63.17.204.181]) by goose.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id RAA09927; Thu, 1 Jun 2000 17:02:20 -0700 (PDT) From: "William Lattin" To: "Ed Gerck" , "Paul Koning" Cc: , Subject: RE: TSA Response serialNumber Field Date: Thu, 1 Jun 2000 17:03:23 -0700 Message-ID: <000201bfcc25$f7b9abe0$b5cc113f@winnt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3936E0E7.AC7B6DF7@nma.com> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Another place to look for the treatment of time accuracy and deviation is RFC 1305 - NTP has attempted to deal with these very issues (albeit for NTP purposes :-)). NTP introduces the concept of dispersion (see Appendix H) which, I believe, addresses the issues being discussed. Bill > -----Original Message----- > From: Ed Gerck [mailto:egerck@nma.com] > Sent: Thursday, June 01, 2000 15:17 > To: Paul Koning > Cc: James.H.Manger@team.telstra.com; ietf-pkix@imc.org > Subject: Re: TSA Response serialNumber Field > > > > > Paul Koning wrote: > > > > > Ed> That is up to each TSA to specify, according to my suggestion. > > Ed> And I recall that it always makes sense to talk about "mean" and > > Ed> "standard deviation" for *any* distribution of like things > > Ed> (apples with apples) -- even if the distribution is not Normal > > Ed> (Gauss). > > > > Suppose we define that the timestamp will contain the mean and > > standard deviation. What will that actually tell you? > > > > If you know the distribution (e.g., Normal) you can answer the > > question "with 0.999999 confidence, what are the bounds". With an > > unknown distribution, you cannot do that. So clearly standard > > deviation is not useful. > > Let me recall that you can indeed compare reliability values by using the > standard deviation for statistics other than gaussian (normal). > This shows > why it is useful to include the *four* types of information I > suggested for the > TSA (and not just that "accuracy" -- which is a meaningless number by > itself, and misleadingly named as it was): > > 1. accuracy: that rather arbitrary fine precision that the TSA sets for > its timestamp ordering purposes. > > 2. uncertainty: set and guaranteed by the TSA, as given above. > > 3. reliability: set and guaranteed by the TSA, as given above. > > 4. statistics: set and guaranteed by the TSA, as given above. > > For example ([2] in my posting before), in the case of gaussian > statistics, > 95% reliability corresponds to an uncertainty which is twice the standard > deviation. > > On these matters, to save cyber trees, I looked for some > references on the web > that could help provide some examples for each concept. I found > the ones below, > which can be helpful (I am sure there are many others): > http://bjmath.com/bjmath/Stats/sd.htm http://bjmath.com/bjmath/Stats/sd.htm http://bjmath.com/bjmath/Stats/confide.htm > That leaves two possibilities: > > a. What I suggested before: mean plus bound chosen so the confidence > is "very high". these numbers cannot be taken out of the blue yonder, but must be based on a sound and objective basis -- mean, bound and confidence cannot be arbitrary. Further, "very high" confidence (ie, reliability) may indeed mean 60% in some cases and this may be as good as 99% in other cases -- as I exemplified in my previous posting with 95% and 99%. > b. Mean plus bound plus confidence value -- preferably with the > recommendation that the confidence value should be a number quite > close to 1. (I don't think I want to do business with a TSA that > reports intervals with "confidence 0.68"...) > Would it surprise you to know that a confidence (reliability) level of 68% for an uncertainty of 0.2 s is much better than 99% for an uncertainty of 1 s, in terms of gauss distributions? Further, without specifying to which statistical distribution the value (mean), the uncertainty (bound) and the reliability (confidence) apply to, the TSA is essentially selling snake oil. Let's keep this in mind -- statistics is quite useless unless the terms are well defined, as politics exemplifies all the time ;-) As another example, I wish to recall the case of that guy who drowned in a lake that had one inch depth on average -- he fell in a 40 ft deep hole. Cheers, Ed Gerck From owner-ietf-pkix@imc.org Fri Jun 2 01:18:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14150 for ; Fri, 2 Jun 2000 01:18:17 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA11397; Thu, 1 Jun 2000 22:09:43 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jun 2000 22:09:33 -0700 Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA11365 for ; Thu, 1 Jun 2000 22:09:31 -0700 (PDT) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id PAA11291 for ; Fri, 2 Jun 2000 15:16:42 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdEbHnZ_; Fri Jun 2 15:16:19 2000 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id PAA10036 for ; Fri, 2 Jun 2000 15:16:19 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0GAIId; Fri Jun 2 15:14:03 2000 Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA13703 for ; Fri, 2 Jun 2000 15:14:03 +1000 (EST) Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 15:13:32 +1000 Message-ID: <73388857A695D31197EF00508B08F2988A3BC6@ntmsg0131.corpmail.telstra.com.au> From: "Manger, James H" To: "'ietf-pkix@imc.org'" Subject: RE: TSA Response serialNumber Field Date: Fri, 2 Jun 2000 15:13:25 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Thanks Ed, I was ignoring the incorrect labelling of the uncertainty field (hoping the next draft would fix it). I was assuming the quoted uncertainty was 1 standard deviation (hoping the next draft would explicitly state this). I was assuming the mapping between number of standard deviations and confidence level was vaguely independent of the exact distribution, at least independent enough for practical timestamping purposes, so I could use the mapping that the normal distribution gives. I knew there were some theoretical bounds on this mapping, though I could not remember the specifics. I was also assuming that converting from one confidence level to another was possible (e.g. if uncertainty for 68% confidence level is quoted just double the uncertainty to get a 95% confidence level). After finding a statistics text book.. Chebyshev's inequality says the probability of being further than n standard deviations from the mean is always less than or equal to 1 / n^2, regardless of the distribution. Pr(|x - mean| >= n.sd) <= 1/n^2 [I think there are some distribution that don't have a finite standard deviation so Chebyshev's inequality does not hold. I hope this does not apply to practical distribution for TSA time measurements.] Hence the probability that a sample is not within [mean - n.sd, mean + n.sd] is: n normal upper bound 1 32% <= 100% 2 5% <= 25% 3 0.3% <= 11% Now I can repeat my calculations from my previous e-mail using Cebyshev's inequality instead of a normal distribution. Instead of calculating the probability that T2 occurred after T1 the calculation gives an upper bound on this probability. In that example the upper bound turns out to be 100% which is useless. This highlights the problem with using Cebyshev's inequality. It gives a very weak bound, particularly as you get further from the mean (use a higher confidence level). Back to the timestamp standard.. For comparing a timestamp to another clock we need time, uncertainty, confidence level and distribution. Put the time and uncertainty in the timestamp (as now), put the confidence level in the standard and the distribution in the TSA's policy document [in future, if required, a policy qualifier or extension could be added to describe the distribution in the actual timestamp]. The standard could state that the uncertainty field is a given number of standard deviations (e.g. 2) or a given confidence interval (e.g. 95%). Previous I suggested the former, but (after reading this thread) I can see advantages with the latter, though I would be happy either way. Suggested text (after changing the field name from 'accuracy' to 'uncertainty'): "The 'uncertainty' value represents the time deviation, in seconds, between the 'genTime' value and UTC at a 95% confidence level. That is, there is a 95% chance that the 'genTime' value is within +/-'uncertainty' seconds of UTC. If the time measurement has a Normal (Gaussian) Distribution the 'uncertainty' value is approximately 2 standard deviations." If a relying party is happy with a 95% confidence interval it does not need to know the exact distribution. If a relying party wants a better confidence level than the standard specifies (e.g. 99.7% instead of 95%) it has a couple of choices: (1) assume, say, a normal distribution and adjust the uncertainty accordingly (e.g. multiple by 3/2); or (2) use Chebyshev's inequality to get an upper bound of the required adjustment [can Chebyshev's inequality be reformulated for this, i.e. for confidence levels (e.g. 95%) instead of standard deviations (e.g. 2 sd)?]; or (3) determine the actual distribution from the TSA's policy document and adjust the uncertainty by the amount appropriate to that distribution. We can leave the choice to the relying party. From owner-ietf-pkix@imc.org Fri Jun 2 02:54:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25672 for ; Fri, 2 Jun 2000 02:54:11 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA17427; Thu, 1 Jun 2000 23:45:06 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jun 2000 23:44:51 -0700 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA17382 for ; Thu, 1 Jun 2000 23:44:50 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVI00L7WLPOHR@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 1 Jun 2000 23:51:25 -0700 (PDT) Date: Thu, 01 Jun 2000 23:51:28 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: William Lattin Cc: Paul Koning , James.H.Manger@team.telstra.com, ietf-pkix@imc.org Message-id: <39375970.9A1843CA@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <000201bfcc25$f7b9abe0$b5cc113f@winnt> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit William Lattin wrote: > Another place to look for the treatment of time accuracy and deviation is > RFC 1305 - NTP has attempted to deal with these very issues (albeit for NTP > purposes :-)). NTP introduces the concept of dispersion (see Appendix H) > which, I believe, addresses the issues being discussed. No. Appendix H has to do with corrections for delays and offsets in NTP communication paths -- roundtrip delay, synch dispersion, etc. The TSAs timestamps we are talking about have nothing to do with this model -- the timestamps here represent static numbers for which communication delay and synch dispersion is irrelevant after they are issued by the TSA (and before they are issued we as r-ps do not care -- it is the TSA's business). So, not only the issues are different but also the consequences. To our case, what is relevant is a simple question. What does a TSA need to inform together with a timestamp to a relying-party so that the r-p can rely on that timestamp for: (i) a value by itself; (ii) comparison between timestamps from that TSA; and (iii) comparison between timestamps from different TSAs. My suggestion was that the TSDA needs to inform four quantities besides the timestamp itself to the r-p, at least. Otherwise the information may not allow (i), or (ii, or (iii). Cheers, Ed Gerck From owner-ietf-pkix@imc.org Fri Jun 2 02:59:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25737 for ; Fri, 2 Jun 2000 02:59:41 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA17783; Thu, 1 Jun 2000 23:48:43 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 1 Jun 2000 23:48:41 -0700 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA17751 for ; Thu, 1 Jun 2000 23:48:41 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVI00MBGLXZ2N@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 1 Jun 2000 23:56:23 -0700 (PDT) Date: Thu, 01 Jun 2000 23:56:27 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: "Manger, James H" Cc: "'ietf-pkix@imc.org'" Message-id: <39375A9B.313951F8@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <73388857A695D31197EF00508B08F2988A3BC6@ntmsg0131.corpmail.telstra.com.au> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit James: We are in violent agreement. Cheers, Ed Gerck "Manger, James H" wrote: > Thanks Ed, > > I was ignoring the incorrect labelling of the uncertainty field (hoping the > next draft would fix it). I was assuming the quoted uncertainty was 1 > standard deviation (hoping the next draft would explicitly state this). > > I was assuming the mapping between number of standard deviations and > confidence level was vaguely independent of the exact distribution, at least > independent enough for practical timestamping purposes, so I could use the > mapping that the normal distribution gives. I knew there were some > theoretical bounds on this mapping, though I could not remember the > specifics. I was also assuming that converting from one confidence level to > another was possible (e.g. if uncertainty for 68% confidence level is quoted > just double the uncertainty to get a 95% confidence level). > > After finding a statistics text book.. > > Chebyshev's inequality says the probability of being further than n standard > deviations from the mean is always less than or equal to 1 / n^2, regardless > of the distribution. > Pr(|x - mean| >= n.sd) <= 1/n^2 > > [I think there are some distribution that don't have a finite standard > deviation so Chebyshev's inequality does not hold. I hope this does not > apply to practical distribution for TSA time measurements.] > > Hence the probability that a sample is not within [mean - n.sd, mean + n.sd] > is: > n normal upper bound > 1 32% <= 100% > 2 5% <= 25% > 3 0.3% <= 11% > > Now I can repeat my calculations from my previous e-mail using Cebyshev's > inequality instead of a normal distribution. Instead of calculating the > probability that T2 occurred after T1 the calculation gives an upper bound > on this probability. In that example the upper bound turns out to be 100% > which is useless. This highlights the problem with using Cebyshev's > inequality. It gives a very weak bound, particularly as you get further > from the mean (use a higher confidence level). > > Back to the timestamp standard.. > > For comparing a timestamp to another clock we need time, uncertainty, > confidence level and distribution. Put the time and uncertainty in the > timestamp (as now), put the confidence level in the standard and the > distribution in the TSA's policy document [in future, if required, a policy > qualifier or extension could be added to describe the distribution in the > actual timestamp]. > > The standard could state that the uncertainty field is a given number of > standard deviations (e.g. 2) or a given confidence interval (e.g. 95%). > Previous I suggested the former, but (after reading this thread) I can see > advantages with the latter, though I would be happy either way. Suggested > text (after changing the field name from 'accuracy' to 'uncertainty'): > "The 'uncertainty' value represents the time deviation, in seconds, > between the 'genTime' value and UTC at a 95% confidence level. That is, > there is a 95% chance that the 'genTime' value is within +/-'uncertainty' > seconds of UTC. If the time measurement has a Normal (Gaussian) > Distribution the 'uncertainty' value is approximately 2 standard > deviations." > > If a relying party is happy with a 95% confidence interval it does not need > to know the exact distribution. If a relying party wants a better > confidence level than the standard specifies (e.g. 99.7% instead of 95%) it > has a couple of choices: > (1) assume, say, a normal distribution and adjust the uncertainty > accordingly (e.g. multiple by 3/2); or > (2) use Chebyshev's inequality to get an upper bound of the required > adjustment [can Chebyshev's inequality be reformulated for this, i.e. for > confidence levels (e.g. 95%) instead of standard deviations (e.g. 2 sd)?]; > or > (3) determine the actual distribution from the TSA's policy document and > adjust the uncertainty by the amount appropriate to that distribution. > We can leave the choice to the relying party. From owner-ietf-pkix@imc.org Fri Jun 2 04:14:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26269 for ; Fri, 2 Jun 2000 04:14:01 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA23986; Fri, 2 Jun 2000 01:03:58 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jun 2000 01:03:47 -0700 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA23937 for ; Fri, 2 Jun 2000 01:03:46 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id KAA22160; Fri, 2 Jun 2000 10:11:28 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 2 Jun 2000 10:11:28 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id KAA11152; Fri, 2 Jun 2000 10:11:26 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id KAA06562; Fri, 2 Jun 2000 10:11:25 +0200 (MET DST) Date: Fri, 2 Jun 2000 10:11:25 +0200 (MET DST) Message-Id: <200006020811.KAA06562@emeriau.edelweb.fr> To: pkoning@xedia.com, egerck@nma.com Subject: Re: TSA Response serialNumber Field Cc: James.H.Manger@team.telstra.com, ietf-pkix@imc.org Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > That is up to each TSA to specify, according to my suggestion. And > I recall that it always makes sense to talk about "mean" and "standard > deviation" for *any* distribution of like things (apples with apples) > -- even if the distribution is not Normal (Gauss). I wonder how the note of the post office etc would look like (flame waring on): Dear user of a time stamp : We are giving you this time stamp, you know, we do our best (95%) to have a good time, but well, it might happen that, so we just tell 95% and then well, if you don't need it better than 1 second, then it is 99% but still there is something left, so we are really sorry, but we can't tell you more, and obviously we do not know how a relying party may interprete this anyway. You know, the background of this is that unfortunately the machine that is reading the atomic clock and the atomic clock are made by unperfect material, it's similar like the 3 of 5687 nails don't have the right size. Actually we look after the values from time to time, so next time, please remember that we highly recommend to arrive at the airport two hours before the plane leaves... A relying party (for example a fiscal authority that verifies whether you met the deadline): - Your declaration is due before midnight. - You've got a time stamp that is shortly (n hours) after midnight ==> no technical decision is made, - A clerk is inspecting your declaration, your previous declarations etc; whether you pay correctly etc., an explanation from you why you think you are late, etc. the clerk obviously has seen the info at the TV which just explained that a huge thunderstorm has destroyed one third of the electric network of the country just during that night. - The cleark acts or doesn't act according the rule that each rule has an exception. > > BTW, just taking a look at the new IETF "glossary" should convince us > that we may have already gone too far in our solipsistic phantasies as we > start to rename that which we ourselves named ;-) Fortunately the dodo in question is marked OPTIONAL, so a TSA doesn't have to implement it at all. One might consider to look back at the Subject of this thread or should one call it threat :-) The question was whether the actual text of requiring a strict monotonically increasing serial could be replaced by something else or not in order to allow unique identification, and whether or whether not ordering among time stamps of one TSA is defined. PS From owner-ietf-pkix@imc.org Fri Jun 2 10:41:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03364 for ; Fri, 2 Jun 2000 10:41:39 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA14238; Fri, 2 Jun 2000 07:29:56 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jun 2000 07:29:08 -0700 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14198 for ; Fri, 2 Jun 2000 07:29:07 -0700 (PDT) From: tgindin@us.ibm.com Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA56378; Fri, 2 Jun 2000 10:35:15 -0400 Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay01.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id KAA104256; Fri, 2 Jun 2000 10:37:00 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568F2.005047BE ; Fri, 2 Jun 2000 10:36:52 -0400 X-Lotus-FromDomain: IBMUS To: "Manger, James H" cc: "'ietf-pkix@imc.org'" Message-ID: <852568F2.0050472B.00@D51MTA04.pok.ibm.com> Date: Fri, 2 Jun 2000 10:36:50 -0400 Subject: RE: TSA Response serialNumber Field Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe One can recast Chebyshev's inequality from Pr(|x - mean| >= n * sd) <= 1/n**2 to Pr(|x - mean| >= (sd / (1 - c)**.5)) <= (1 - c) or Pr(|x - mean| < (sd / (1 - c)**.5)) > c Where c is just 1 - 1/n**2. If c can be described as a confidence level, this answers your question 2) below. I am not sure that one would describe c here as a confidence level, but I think it's reasonable to say that if one has probability > C that a measurement actually lies within a range R, then one has at least confidence C that the measurement lies within that range. Tom Gindin "Manger, James H" on 06/02/2000 01:13:25 AM To: "'ietf-pkix@imc.org'" cc: Subject: RE: TSA Response serialNumber Field Thanks Ed, (snip) If a relying party is happy with a 95% confidence interval it does not need to know the exact distribution. If a relying party wants a better confidence level than the standard specifies (e.g. 99.7% instead of 95%) it has a couple of choices: (1) assume, say, a normal distribution and adjust the uncertainty accordingly (e.g. multiple by 3/2); or (2) use Chebyshev's inequality to get an upper bound of the required adjustment [can Chebyshev's inequality be reformulated for this, i.e. for confidence levels (e.g. 95%) instead of standard deviations (e.g. 2 sd)?]; or (3) determine the actual distribution from the TSA's policy document and adjust the uncertainty by the amount appropriate to that distribution. We can leave the choice to the relying party. From owner-ietf-pkix@imc.org Fri Jun 2 10:55:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03629 for ; Fri, 2 Jun 2000 10:55:37 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA14639; Fri, 2 Jun 2000 07:43:19 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jun 2000 07:43:17 -0700 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14578 for ; Fri, 2 Jun 2000 07:41:57 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 07:44:28 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2D7A456@seine.valicert.com> From: Boulos Dib To: "'denis.bider@siol.net'" Cc: ietf-pkix@imc.org Subject: RE: Microsoft Date: Fri, 2 Jun 2000 07:44:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Denis, I take it you need to understand how IIS and Outlook perform certification path validation which includes certificate status checking. If you need to learn more path validation in general, RFC2459 is the official document. PKIX uses the term validation not verification and RFC2459 section 6 defines the details of certification path validation. I am not an expert on the internals of IIS and Outlook, but I understand that they both use Microsoft's CryptoAPI (CAPI) certificate functions. CAPI includes a number of APIs to deal with certificates, certificate stores, and what CAPI calls "Certificate Verification Functions" which use Certificate Revocation Lists (CRLs) and Certificate Trust Lists (CTLs). There is also a way for third party vendors (i.e. Validation Authorities) to plug-in their own implementation of certain APIs to extend the validation to use other protocols such as Online Certificate Status Protocol (OCSP). Check out http://www.valicert.com for information about Email, Web Browser and Web server validators. Microsoft's CryptoAPI documentation is available online on MSDN http://msdn.microsoft.com/library/psdk/crypto/portalapi_3351.htm I hope the above helps to get you started. Boulos. -----Original Message----- From: denis.bider@siol.net [mailto:denis.bider@siol.net] Sent: Wednesday, May 31, 2000 6:42 PM To: ietf-pkix@imc.org Subject: Microsoft Hello, I am developing a certificate-generating application that will be employed in a Microsoft-based environment. I am looking from someone in Microsoft who has the technical insight about how certificate verification has been implemented in IIS, and perhaps also Microsoft Outlook. Is there, perhaps, someone who is reading this list who would know something about this, or someone who would have the appropriate contacts? If so, I would be much obliged if you could send me an email. Kind regards, denis bider From owner-ietf-pkix@imc.org Fri Jun 2 11:47:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05599 for ; Fri, 2 Jun 2000 11:47:09 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA17798; Fri, 2 Jun 2000 08:31:44 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jun 2000 08:30:09 -0700 Received: from ahmler2.mail.eds.com (ahmler2.mail.eds.com [192.85.154.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17642; Fri, 2 Jun 2000 08:30:08 -0700 (PDT) Received: from ahmlir1.mail.eds.com (ahmlir1-2.mail.eds.com [192.85.154.25]) by ahmler2.mail.eds.com (8.9.3/8.9.3) with ESMTP id LAA23107; Fri, 2 Jun 2000 11:38:02 -0400 (EDT) Received: from ahmlir1.mail.eds.com (localhost [127.0.0.1]) by ahmlir1.mail.eds.com (8.9.3/8.9.3) with ESMTP id LAA07798; Fri, 2 Jun 2000 11:37:31 -0400 (EDT) Received: from usahm006.exmi01.exch.eds.com (usahm006.exmi01.exch.eds.com [207.37.138.146]) by ahmlir1.mail.eds.com (8.9.3/8.9.3) with ESMTP id LAA06614; Fri, 2 Jun 2000 11:36:17 -0400 (EDT) Received: by usahm006.exmi01.exch.eds.com with Internet Mail Service (5.5.2651.32) id ; Fri, 2 Jun 2000 11:36:14 -0400 Message-ID: <3DF5A09BFF4FD2119A2400A02461F0DB0461BAEC@usahm012.exmi01.exch.eds.com> From: "Golod, Alex" To: "'ietf-pkix-request@imc.org'" , "'ietf-pkix@imc.org'" Subject: Would like to subscribe Date: Fri, 2 Jun 2000 11:36:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.32) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFCCA8.48BBF8D6" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFCCA8.48BBF8D6 Content-Type: text/plain; charset="iso-8859-1" Hello, PKI is my area of interest. I would like to subscribe. Please, let me know if I need to do something else to get there. Thanks, Alex Golod (248) 265-6048 <> ------_=_NextPart_000_01BFCCA8.48BBF8D6 Content-Type: application/octet-stream; name="Golod, Alex.vcf" Content-Disposition: attachment; filename="Golod, Alex.vcf" BEGIN:VCARD VERSION:2.1 N:Golod;Aleksander FN:Golod, Alex ORG:EDS;GLOBAL DELIV I.SOLUTIONS TEL;WORK;VOICE:001 248 265 6048 TEL;WORK;VOICE:8 365 6048 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;AUTHENTICATION/ENCRYPTION SECURI 266112;4198=0D=0A800 TOWER DR=0D=0A;TROY;M= I;48098;US LABEL;WORK;ENCODING=QUOTED-PRINTABLE:AUTHENTICATION/ENCRYPTION SECURI 266112=0D=0A4198=0D=0A800 TOWER DR=0D=0A= =0D=0ATROY, MI 48098=0D=0AUS EMAIL;PREF;INTERNET:alex.golod@exmi01.exch.eds.com REV:20000518T131425Z END:VCARD ------_=_NextPart_000_01BFCCA8.48BBF8D6-- From owner-ietf-pkix@imc.org Fri Jun 2 13:32:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08029 for ; Fri, 2 Jun 2000 13:32:48 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA22144; Fri, 2 Jun 2000 10:06:23 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jun 2000 10:06:03 -0700 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22110 for ; Fri, 2 Jun 2000 10:06:02 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVJ00IHQE0LY1@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Fri, 2 Jun 2000 10:02:45 -0700 (PDT) Date: Fri, 02 Jun 2000 10:02:49 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: Peter Sylvester Cc: pkoning@xedia.com, James.H.Manger@team.telstra.com, ietf-pkix@imc.org Message-id: <3937E8B9.B546BDDB@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200006020811.KAA06562@emeriau.edelweb.fr> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Peter Sylvester wrote: > The question was whether the actual text of requiring a strict monotonically > increasing serial could be replaced by something else or not in order > to allow unique identification, and whether or whether not ordering > among time stamps of one TSA is defined. But the specs were broken, as it is rather obvious now, and what was supposed to be a timestamp was actually a nothing. I guess your examples would be much worse if the TSA did NOT inform the reliability level and did NOT inform the expected distribution, because in such a case instead of saying -- "gee, we may be wrong 5% of the time", the TSA would be saying "gee, we do not know what we are saying". BTW, the only *minor* quibble I still have with Manger is that I do not favor a set reliability level in the standard but we should be making that a variable to be specified by the TSA. The main reason for this is not only to avoid fast obsolescence but also to provide room for improvement. I will not copy again my other arguments, but they are in the archives. Cheers, Ed Gerck PS: I enjoyed your "Dear user of a time stamp " declaration and I have a similar one for digital certificates -- and this is EXACTLY what I am trying to avoid by calling attention to the fact that just supplying what WAS going to be supplied was simply not enough -- as it is clear now after much effort, I suppose. > > > PS From owner-ietf-pkix@imc.org Fri Jun 2 16:29:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12605 for ; Fri, 2 Jun 2000 16:29:47 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA24889; Fri, 2 Jun 2000 13:18:44 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 2 Jun 2000 13:18:37 -0700 Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24859 for ; Fri, 2 Jun 2000 13:18:36 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 16:26:02 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B10305FDAC@sothmxs06.entrust.com> From: Tim Moses To: "'ietf-pkix@imc.org'" Subject: Criticality marking of the policy mappings extension Date: Fri, 2 Jun 2000 16:26:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Colleagues - I have just reviewed the path processing procedure specified in the certificate and CRL profile Internet draft. I have the following observations. Let's start with very minor ones ... 1. In 6.1.3 (b) it says "If certificate i is not self-issued, verify that the subject name is within one of the permitted_subtrees for X.500 distinguished names, ...". This rule applies to end-user certificates, as well as CA certificates. So, perhaps it should be explicitly stated that a null subject is within all permitted_subtrees, including a null one. 2. There appears to be something missing from 6.1.3 (d) (3). It reads ... "The two nodes at depth i-1 that are marked with an to the resulting tree will cause the node at depth i-2 that is marked with a Y to be deleted." 3. Sub-paras (1) and (2) of 6.1.4 (g) should be indented. 4. Para 6.1.4 (m) should say "If pathLengthConstraint is present in the basic constraints extension of the certificate ..." 5. The reference at the very end of 6.1.4 should be to para 6.1.3, not 6.1.2. 6. The extended path validation described in Para 6.2 deals with the case of multiple trust anchors. In this case it says: "Limitations in the trust path for any particular key may be incorporated into the self-signed certificate's extensions. In this way, the self-signed certificates permit the path validation module to automatically incorporate local security policy and requirements." Setting aside the questions of whether this is a good thing or a bad thing and whether or not it is consistent with X.509. I wonder whether it is appropriate to have different behaviour depending upon the number of trust anchors. 7. The final comment relates to the criticality marking on the policy mappings extension. If an (admittedly non-conformant) client were to encounter a PKIX certificate with a non-critical policy mappings extension, then it could accept the path, when the issuer of the certificate intended it to reject the path. Consider this example. A CA issues a certificate to another CA. The certificate policies extension identifies Policy A, and the non-critical policy mappings extension maps Policy A to Policy B. The other CA issues a certificate under Policy A. The intention of the first CA is that the certificate user would reject this certificate. But, a client that understood certificate policies, but not policy mapping would accept the certificate. Therefore, it should be permissible to mark the policy mappings extension critical. But, this is disallowed by Para 4.2.1.6, which requires the extension to be marked non-critical. The 2000 version of X.509 allows and recommends that the policy mappings extension be marked critical. So, the PKIX profile should make the same recommendation. ---------------------------------------------------------------------------- ----------- Tim Moses Tel: 613.247.3183 From owner-ietf-pkix@imc.org Sun Jun 4 14:12:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09128 for ; Sun, 4 Jun 2000 14:12:09 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA29620; Sun, 4 Jun 2000 11:00:57 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 4 Jun 2000 10:59:40 -0700 Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29580 for ; Sun, 4 Jun 2000 10:59:37 -0700 (PDT) Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id TAA08632 for ; Sun, 4 Jun 2000 19:54:46 +0200 From: Sender: "denis bider" To: Subject: Report - certificate validation in IE5, Outlook, IIS4, Netscape 4.72 Date: Sun, 4 Jun 2000 20:08:21 +0200 Message-ID: <000501bfce4f$df1421c0$0201010a@1div0.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hello, a while ago I sent to this list an enquiry regarding Microsoft's certificate validation code in IIS4. I have now resolved the problem that was the reason for my enquiry. Since the solution to the problem produced some interesting insight into how certificate chains are handled in IE5 and Outlook / IIS4 and Netscape, and since the behavior in question should be covered by RFC2459, but does not seem to be, I am forwarding my findings to you. I produced my own certificate generating utility, the intention of which was to generate certificates which could be used by IE5 to login into an SSL-protected web site running on IIS4. My problem was that, although IE5 claimed my root-cert/subject-cert certificate chain to be valid, and although Outlook properly signed and verified messages signed by these certificates, IIS4 rejected all attempts to use the subject certificate for SSL client authentication. Also, when the subject certificate was imported into Netscape, Netscape didn't even show it as an elligible choice for SSL client authentication. To sum it up, the problem was that there was a glitch in my code that caused the subject-DN in root-cert to be slightly different from the issuer-DN in the subject-cert. It seems that the certificate verification code in IE5 and Outlook2000 is somewhat easy-going, since both of these products validated the pair of certificates as valid (they performed cert-chain validation solely on the grounds of the key identifier in the Authority Key Identifier extension, they did not compare the sub-cert-issuerDN to the root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand, seem to have a more stringent policy, since they both rejected these certificates. denis bider From owner-ietf-pkix@imc.org Sun Jun 4 14:19:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09155 for ; Sun, 4 Jun 2000 14:19:52 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA29860; Sun, 4 Jun 2000 11:10:00 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 4 Jun 2000 11:09:59 -0700 Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29830 for ; Sun, 4 Jun 2000 11:09:57 -0700 (PDT) Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id UAA08660 for ; Sun, 4 Jun 2000 20:05:08 +0200 From: Sender: "denis bider" To: Subject: Correct approach to certificate validation? Date: Sun, 4 Jun 2000 20:18:43 +0200 Message-ID: <000601bfce51$51752dd0$0201010a@1div0.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Now, based on my previous message, my question for this workgroup: Which of these approaches is correct? - the approach of IE5 and Outlook, which, if an Authority Key Identifier extension is present, does not perform a comparison of the issuer-DN in the subject-cert to the subject-DN of the root-cert? - or the approach of Netscape and IIS4, which, even if an Authority Key Identifier extension is present, DOES still perform a comparison of the subject-cert-issuer-DN to the root-cert-subject-DN? Regards, denis bider PS. I would like to thank Ace Swerling from Microsoft Consulting Services for the fact that he bothered to look into my problem, and especially to Peter Williams from Valicert who devoted much of his time to help me solve this issue. I appreciate your feedback very much. -----Original Message----- From: denis bider [mailto:denis@denisbider.com] On Behalf Of denis.bider@siol.net Sent: Sunday, June 04, 2000 20:08 To: 'ietf-pkix@imc.org' Subject: Report - certificate validation in IE5, Outlook, IIS4, Netscape 4.72 Hello, a while ago I sent to this list an enquiry regarding Microsoft's certificate validation code in IIS4. I have now resolved the problem that was the reason for my enquiry. Since the solution to the problem produced some interesting insight into how certificate chains are handled in IE5 and Outlook / IIS4 and Netscape, and since the behavior in question should be covered by RFC2459, but does not seem to be, I am forwarding my findings to you. I produced my own certificate generating utility, the intention of which was to generate certificates which could be used by IE5 to login into an SSL-protected web site running on IIS4. My problem was that, although IE5 claimed my root-cert/subject-cert certificate chain to be valid, and although Outlook properly signed and verified messages signed by these certificates, IIS4 rejected all attempts to use the subject certificate for SSL client authentication. Also, when the subject certificate was imported into Netscape, Netscape didn't even show it as an elligible choice for SSL client authentication. To sum it up, the problem was that there was a glitch in my code that caused the subject-DN in root-cert to be slightly different from the issuer-DN in the subject-cert. It seems that the certificate verification code in IE5 and Outlook2000 is somewhat easy-going, since both of these products validated the pair of certificates as valid (they performed cert-chain validation solely on the grounds of the key identifier in the Authority Key Identifier extension, they did not compare the sub-cert-issuerDN to the root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand, seem to have a more stringent policy, since they both rejected these certificates. denis bider From owner-ietf-pkix@imc.org Mon Jun 5 05:37:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27440 for ; Mon, 5 Jun 2000 05:37:25 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA05120; Mon, 5 Jun 2000 02:28:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jun 2000 02:27:22 -0700 Received: from krdl.org.sg (IDENT:root@rodin.krdl.org.sg [192.122.139.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA05065 for ; Mon, 5 Jun 2000 02:27:20 -0700 (PDT) Received: from mailhost.krdl.org.sg (mailhost [192.122.134.30]) by krdl.org.sg (8.9.3/8.9.3) with ESMTP id RAA09940 for ; Mon, 5 Jun 2000 17:43:48 +0800 Received: from phantom.krdl.org.sg (phantom [192.122.136.237]) by mailhost.krdl.org.sg (8.9.3/8.9.3) with SMTP id RAA02470 for ; Mon, 5 Jun 2000 17:34:29 +0800 (SGT) Received: by phantom.krdl.org.sg (SMI-8.6/SMI-SVR4) id RAA00918; Mon, 5 Jun 2000 17:33:18 +0800 From: lux@krdl.org.sg (A.Lakshminarayanan) Message-Id: <200006050933.RAA00918@phantom.krdl.org.sg> Subject: WTLS Certificate format.... To: ietf-pkix@imc.org Date: Mon, 5 Jun 2000 17:33:17 +0800 (SGT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi, I am looking for specs on the WTLS Certificate format. Is it publicly available? Is it similar to the format specified by the PKIX working group? Are there any similarities? Cheers Lux Kent Ridge Digital Labs Singapore From owner-ietf-pkix@imc.org Mon Jun 5 06:48:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27806 for ; Mon, 5 Jun 2000 06:48:06 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA08466; Mon, 5 Jun 2000 03:39:05 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jun 2000 03:38:55 -0700 Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08435 for ; Mon, 5 Jun 2000 03:38:53 -0700 (PDT) From: amir.herzberg@il.ibm.com Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id MAA69202 for ; Mon, 5 Jun 2000 12:46:26 +0200 Received: from d12mta05.de.ibm.com (d12mta05_cs0 [9.165.222.239]) by d12relay01.de.ibm.com (8.8.8m3/NCO v2.07) with SMTP id MAA229242 for ; Mon, 5 Jun 2000 12:46:26 +0200 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12568F5.003B2CAC ; Mon, 5 Jun 2000 12:46:20 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: lux@krdl.org.sg (A.Lakshminarayanan) cc: ietf-pkix@imc.org Message-ID: Date: Mon, 5 Jun 2000 13:48:52 +0300 Subject: Re: WTLS Certificate format.... Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Lux asked, > I am looking for specs on the WTLS Certificate format. Is it > publicly available? Is it similar to the format specified by the PKIX > working group? Are there any similarities? Look at http://www.wapforum.org/what/technical.htm Do `find` for WTLS. btw, some other security stuff as well at that page. I think the format takes a lot from PKIX but judge for yourself... Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com From owner-ietf-pkix@imc.org Mon Jun 5 07:37:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28876 for ; Mon, 5 Jun 2000 07:37:09 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA09616; Mon, 5 Jun 2000 04:28:19 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jun 2000 04:28:15 -0700 Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA09584 for ; Mon, 5 Jun 2000 04:28:11 -0700 (PDT) Received: (qmail 20431 invoked from network); 5 Jun 2000 11:30:11 -0000 Received: from unknown (HELO sibs.pt) (195.138.0.90) by mail0.sibs.pt with SMTP; 5 Jun 2000 11:30:11 -0000 Message-ID: <393B90DA.D09A0005@sibs.pt> Date: Mon, 05 Jun 2000 12:36:58 +0100 From: Pedro Miguel Pereira Borges Reply-To: borges@sibs.pt Organization: SIBS X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Attribute Certificate Request References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi all, I'm currently reading the "An Internet Attribute Certificate Profile for Authorization" draft... However, there is a question that I would like to see answered: is there a definition (ASN.1 or not) of what an attribute certificate request should contain like there is one for the "normal" X.509 ID certificates ? Thanks in advance, Pedro Borges From owner-ietf-pkix@imc.org Mon Jun 5 09:19:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01733 for ; Mon, 5 Jun 2000 09:19:17 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA11797; Mon, 5 Jun 2000 06:08:39 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jun 2000 06:08:28 -0700 Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11764 for ; Mon, 5 Jun 2000 06:08:26 -0700 (PDT) Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA42690; Mon, 5 Jun 2000 15:16:23 +0200 Message-ID: <393BA827.6487CB21@bull.net> Date: Mon, 05 Jun 2000 15:16:23 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: tgindin@us.ibm.com, "Manger, James H" CC: "'ietf-pkix@imc.org'" Subject: Re: TSA Response serialNumber Field References: <852568F2.0050472B.00@D51MTA04.pok.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit I have not followed all the rational for using or not using Chebyshev's inequality and since a relying party will NOT be happy with a 95% confidence (nor 99,99%), I propose that we all look back at the definition we have in the current document. " By adding the XXXX value to the GeneralizedTime, an upper limit of the time at which the timestamp has been created by the TSA can be obtained. In the same way, by subtracting the XXXX to the GeneralizedTime, a lower limit of the time at which the timestamp has been created by the TSA can be obtained." The single remaining question is how do you call XXXX, while sticking to THIS definition. It is currently called "accuracy". If this term is not adequate, please make a proposal. I would like to close this issue soon. Denis > One can recast Chebyshev's inequality from > Pr(|x - mean| >= n * sd) <= 1/n**2 > to > Pr(|x - mean| >= (sd / (1 - c)**.5)) <= (1 - c) > or > Pr(|x - mean| < (sd / (1 - c)**.5)) > c > > Where c is just 1 - 1/n**2. > > If c can be described as a confidence level, this answers your > question 2) below. I am not sure that one would describe c here as a > confidence level, but I think it's reasonable to say that if one has > probability > C that a measurement actually lies within a range R, then one > has at least confidence C that the measurement lies within that range. > > Tom Gindin > > "Manger, James H" on 06/02/2000 01:13:25 > AM > > To: "'ietf-pkix@imc.org'" > cc: > Subject: RE: TSA Response serialNumber Field > > Thanks Ed, > > (snip) > > If a relying party is happy with a 95% confidence interval it does not need > to know the exact distribution. If a relying party wants a better > confidence level than the standard specifies (e.g. 99.7% instead of 95%) it > has a couple of choices: > (1) assume, say, a normal distribution and adjust the uncertainty > accordingly (e.g. multiple by 3/2); or > (2) use Chebyshev's inequality to get an upper bound of the required > adjustment [can Chebyshev's inequality be reformulated for this, i.e. for > confidence levels (e.g. 95%) instead of standard deviations (e.g. 2 sd)?]; > or > (3) determine the actual distribution from the TSA's policy document and > adjust the uncertainty by the amount appropriate to that distribution. > We can leave the choice to the relying party. From owner-ietf-pkix@imc.org Mon Jun 5 12:10:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05342 for ; Mon, 5 Jun 2000 12:10:45 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16450; Mon, 5 Jun 2000 08:56:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jun 2000 08:56:25 -0700 Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16400 for ; Mon, 5 Jun 2000 08:56:23 -0700 (PDT) Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Mon, 05 Jun 00 17:17:30 +0100 X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2 Received: by BJEX1 with Internet Mail Service (5.5.2448.0) id ; Mon, 5 Jun 2000 16:58:42 +0100 Message-ID: <608D67882786D211B1070090271E4CB990AC1F@BJEX1> From: "Alan Shepherd" To: "'ietf-pkix@imc.org'" Subject: RE: Protocol Action: Diffie-Hellman Proof-of-Possession Algorithm s to Proposed Standard Date: Mon, 5 Jun 2000 16:58:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-WSS-ID: 15250D1099050-01-01 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Please forgive me if this is a terribly naive question, but I would like to know what problems arise if a public key is certified erroneously. I can not see what security problems arise through this and would very much appreciate someone wiser explaining it! Thanks for you help. Alan > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: 31 May 2000 14:03 > Cc: RFC Editor; RFC Editor; RFC Editor > Subject: Protocol Action: Diffie-Hellman Proof-of-Possession > Algorithms > to Proposed Standard > > > > > The IESG has approved the Internet-Draft 'Diffie-Hellman > Proof-of-Possession Algorithms' as a > Proposed Standard. This document is the product of the Public-Key > Infrastructure (X.509) Working Group. The IESG contact persons are > Jeffrey Schiller and Marcus Leech. > > > > Technical Summary > > One of the important requirements in cryptographic protocols is the > ability for an entity to prove they have possession of a particular > key. In particular, Certifying Authorities prior to the > issuance of a > certificate, need to prove that the entity for which the certificate > will be issued in fact does have the private key that corresponds to > the public key which is included in the certificate. > > The traditional approach used with public key encryption > systems such > as the RSA system is to have the challenger require the entity > holding a given private key to sign a challenge string. > > However the Diffie-Hellman (DH) algorithm does not directly lend > itself to providing such signatures, as it is at heart a key > agreement algorithm. This document describes two methods for > producing a signature from a Diffie-Hellman key pair. > > Working Group Summary > > Consensus was reached on the approach used in this document. > > Protocol Quality > > Jeffrey I. Schiller reviewed this document for the IESG. Furthermore > the PKIX Working Group contains members with significant > cryptographic experience who also have reviewed this document. > > Note to RFC Editor: > > There were some word-wrapping problems introduced in Appendix A of > the document that need to be corrected: > > Appendix A: > > OLD: > DH-Sign DEFINITIONS IMPLICIT TAGS ::= > > BEGIN > --EXPORTS ALL > -- The types and values defined in this module are exported for use > in > -- the other ASN.1 modules. Other applications may use them for > their > -- own purposes. > > NEW/FIXED: > DH-Sign DEFINITIONS IMPLICIT TAGS ::= > > BEGIN > --EXPORTS ALL > -- The types and values defined in this module are exported for use > -- in the other ASN.1 modules. Other applications may use them > -- for their own purposes. > ------------------------------------------------------------------------------------------ This message is for the named person’s use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. From owner-ietf-pkix@imc.org Mon Jun 5 15:49:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09360 for ; Mon, 5 Jun 2000 15:49:36 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA22766; Mon, 5 Jun 2000 12:39:47 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jun 2000 12:38:40 -0700 Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22720 for ; Mon, 5 Jun 2000 12:38:38 -0700 (PDT) Received: by balinese.baltimore.ie; id UAA15998; Mon, 5 Jun 2000 20:46:48 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma015990; Mon, 5 Jun 00 20:45:57 +0100 Received: from baltimore.ie ([192.168.20.133]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id UAA18903; Mon, 5 Jun 2000 20:45:54 +0100 Message-ID: <393C03A8.A0F228B4@baltimore.ie> Date: Mon, 05 Jun 2000 20:46:48 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: borges@sibs.pt CC: ietf-pkix@imc.org Subject: Re: Attribute Certificate Request References: <393B90DA.D09A0005@sibs.pt> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Pedro, Since the use cases for ACs aren't as well understood as for public key certificates, there is, as yet, no equivalent to CMP/CMC for AC requests. I would expect that, in future, we might get around to writing one. Meanwhile, there is draft-ietf-pkix-laap-00.txt which describes an alternative to LDAP for AC retrieval, though this deliberately doesn't try to provide the equivalent of a CMP certification request. Regards, Stephen. Pedro Miguel Pereira Borges wrote: > > Hi all, > > I'm currently reading the "An Internet Attribute Certificate Profile > for Authorization" draft... > However, there is a question that I would like to see answered: is > there a definition (ASN.1 or not) of what an attribute certificate request > should contain like there is one for the "normal" X.509 ID certificates ? > > Thanks in advance, > > Pedro Borges -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-pkix@imc.org Mon Jun 5 16:41:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10129 for ; Mon, 5 Jun 2000 16:41:41 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA23700; Mon, 5 Jun 2000 13:32:25 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jun 2000 13:32:21 -0700 Received: from keyon.ch ([194.148.57.155]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA23670 for ; Mon, 5 Jun 2000 13:32:19 -0700 (PDT) Received: (qmail 19391 invoked from network); 5 Jun 2000 20:45:29 -0000 Received: from www.keyon.ch (194.148.57.155) by www.keyon.ch with QMTP; 5 Jun 2000 20:45:29 -0000 Received: (qmail 888 invoked from network); 5 Jun 2000 20:39:06 -0000 Received: from ebe.keyon.ch (HELO ebe) (192.168.0.12) by homer.keyon.ch with SMTP; 5 Jun 2000 20:39:06 -0000 From: "Rene G. Eberhard (keyon)" To: "A.Lakshminarayanan" , Subject: RE: WTLS Certificate format.... Date: Mon, 5 Jun 2000 22:41:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200006050933.RAA00918@phantom.krdl.org.sg> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > Hi, > > I am looking for specs on the WTLS Certificate format. Is it > publicly available? Is it similar to the format specified by the PKIX > working group? Are there any similarities? Take a look at http://www.wapforum.org/what/technical.htm and read the latest WTLS document. You may also take a look at www.freecerts.com which offers free WAP certificates for testing purposes. We also offer a public accessible WTLS secured WAPGateway for testing purposes. We run our keyon / WTLSGateway with kannel as WAP Gateway on our internet server at 194.148.57.155. The Nokia 7110 will connect secure just fine and you can download the root certificate at www.freecerts.com. Note that you cannot "escape" our web server but you can display the security parameters of the connection which is quite interesting. This does also work with the Nokia 1.3b 7110 simulator btw. I hope your firewall (if there's any) supports UDP maskerading for accessing our services.... Kind regards Rene Eberhard -- Rene G. Eberhard keyon Herrenberg 35, CH-8640 Rapperswil, Switzerland Phone +41 (0)55 220 71 63, Fax +41 (0)55 220 71 61 www.keyon.ch - applying security to your e-business Get your WAP certificate for free: www.freecerts.com From owner-ietf-pkix@imc.org Mon Jun 5 18:05:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11438 for ; Mon, 5 Jun 2000 18:05:12 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA25184; Mon, 5 Jun 2000 14:54:14 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jun 2000 14:54:02 -0700 Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25149 for ; Mon, 5 Jun 2000 14:54:01 -0700 (PDT) Received: from rhousley_laptop.spyrus.com (russ-35.spyrus.com [207.212.35.226]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id PAA09465; Mon, 5 Jun 2000 15:01:38 -0700 (PDT) Message-Id: <4.2.0.58.20000605130421.00a52160@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 05 Jun 2000 13:09:05 -0400 To: From: Russ Housley Subject: Re: Report - certificate validation in IE5, Outlook, IIS4, Netscape 4.72 Cc: In-Reply-To: <000501bfce4f$df1421c0$0201010a@1div0.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Denis: I do not belive that RFC 2459 is silent on this subject. See 6.1, path processing action (a) (4). Russ At 08:08 PM 06/04/2000 +0200, denis.bider@siol.net wrote: >Hello, > >a while ago I sent to this list an enquiry regarding Microsoft's certificate >validation code in IIS4. I have now resolved the problem that was the reason >for my enquiry. Since the solution to the problem produced some interesting >insight into how certificate chains are handled in IE5 and Outlook / IIS4 >and Netscape, and since the behavior in question should be covered by >RFC2459, but does not seem to be, I am forwarding my findings to you. > >I produced my own certificate generating utility, the intention of which was >to generate certificates which could be used by IE5 to login into an >SSL-protected web site running on IIS4. My problem was that, although IE5 >claimed my root-cert/subject-cert certificate chain to be valid, and >although Outlook properly signed and verified messages signed by these >certificates, IIS4 rejected all attempts to use the subject certificate for >SSL client authentication. Also, when the subject certificate was imported >into Netscape, Netscape didn't even show it as an elligible choice for SSL >client authentication. > >To sum it up, the problem was that there was a glitch in my code that caused >the subject-DN in root-cert to be slightly different from the issuer-DN in >the subject-cert. It seems that the certificate verification code in IE5 and >Outlook2000 is somewhat easy-going, since both of these products validated >the pair of certificates as valid (they performed cert-chain validation >solely on the grounds of the key identifier in the Authority Key Identifier >extension, they did not compare the sub-cert-issuerDN to the >root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand, >seem to have a more stringent policy, since they both rejected these >certificates. > >denis bider From owner-ietf-pkix@imc.org Mon Jun 5 21:17:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13211 for ; Mon, 5 Jun 2000 21:17:19 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA01134; Mon, 5 Jun 2000 18:04:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jun 2000 18:04:15 -0700 Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA01034 for ; Mon, 5 Jun 2000 18:04:13 -0700 (PDT) Received: from [171.78.60.24] ([171.78.60.24]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id VAA22779; Mon, 5 Jun 2000 21:11:52 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <27FF4FAEA8CDD211B97E00902745CBE235E2A9@seine.valicert.com> References: <27FF4FAEA8CDD211B97E00902745CBE235E2A9@seine.valicert.com> Date: Mon, 5 Jun 2000 19:16:09 -0400 To: Peter Williams From: Stephen Kent Subject: RE: SubjectAltName verification Cc: "'Denis Pinkas'" , ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Peter, >Denis, > >The mandatory operational policy element >that was advocated by one co-chair based >off of your suggestion is potentially >very damaging to the current Internet PKI, >as we who built what individual users can >use, know it. Please reconsider your text, given >how others may apply it, carefully. The claim that this text would be "{very damaging to the current Internet PKI" is an overstatement, at best. See below for details. > >Based on Al's and Steve's replies >to my deliberately contentious policy >scenario, we can now apply the interpretive >principles established as community standards. That >exercise showed clearly that naming verification >policy is not only now mandatory on PKIX CAs, but >which policies are conforming is determined by PKIX. >The conformance testing procedure is unspecified >in the text, but none the less it evidently >exists - as a subjective process. I think most people have an informal understanding of what it means to verify information in a cert, even allowing for latitude in a CA's policy on the extent and nature of the verification. I agree that we can debate the details of this forever, especially considering past experience with analogous topics on this list. > >Lets apply >the principles to VeriSign's branded services, to >see the ramifications. > >Some or all of VeriSign's Class 1 offering >of its Public Certification Service(s) is/are >apparently no longer PKIX-conforming, if one applies >the conformance principles now proposed by Steve. It >was conforming, last week. (A "national" >ie governmental CA service to residents also suddenly >became non-conforming last week, also, because >of other subtle tweaks) VeriSign Class 1 certs have been non-conforming in several respects in the past, e.g., the insertion of e-mail addresses into CN attributes. Maybe this, and other practices have ceased; I don't know. Are you seriously saying that that Class 1 certs from VeriSign would be completely PKIX compliant if only we paid not attention to the procedures used to verify the accuracy of their contents? Maybe. But, if so, what are they worth (vs. what do they cost)? > >Goto a formal certificate repository >https://digitalid.verisign.com/services/client/index.html >and perform the instructions. Type in >peterw@valicert.com, and see (apparently) >that a certificate is recorded, with "pending" >status. The common name is "No Such Agency" >and an unverified email address exists >in the name form selected by VeriSign. That sounds like a good example of what one would NOT want in a certificate. Are you sure you're arguing against my position :-)? Still, you seem to have jumped to a conclusion, based on just this example. > >To be fair to VeriSign, I have not completed >all procedures. To complete, someone >must send a challenge-response pin sent >to peterw@valicert.com to VeriSign to >verify that such email account-name exists. >(This is apparently a non-conforming >verification event.) Says who? The point I, and several others are trying to make, is that it is negligent for a CA to include data in a cert without making some effort to verify that data, either directly or via some RA(s). Also, if sending the challenge to the e-mail address does not complete the registration procedure, but rather the recipient must respond, then that does represent some effort at verification. It's not perfect, but it is a credible effort for a low assurance certificate, IF the Subject name or Subject alt name is an e-mail address. If it's some pseudo DN, then NO, this does not count as verification. >The resulting certificate binds one legally >to certain digital signatures, according >to the governing policy. Personally I'm not comfortable with that, because the level of verification is pretty low, but that's just my opinion, and it's one reason I'm not a VeriSign Class 1 certificate holder. (Another reason is that it doesn't seem to be a very useful thing to have, i.e., I don't seem to have much use for one of those certs, personally.) > >VeriSign PCS's Class 1 Service is apparently >(suddenly) no longer conforming with PKIX, under >any interpretion of the new mandatory >policy language concerning name field >verification > >This seems an excessive impact of your >suggestion. I, as one of its co-designers, would >like to include VeriSign PCS's current Class 1 >offering within the PKIX family of conforming CAs. There may be other reasons that it is non-conforming, e.g., other attributes for which VeriSign makes no effort to verify the data, but what you cited above would not rule it out based on the proposed text (if the other constraints I cited above were not violated). Steve From owner-ietf-pkix@imc.org Mon Jun 5 23:08:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15763 for ; Mon, 5 Jun 2000 23:08:35 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA21106; Mon, 5 Jun 2000 19:51:38 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jun 2000 19:51:23 -0700 Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA21014 for ; Mon, 5 Jun 2000 19:51:22 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Jun 2000 18:58:33 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Mon, 5 Jun 2000 19:06:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Content-Class: urn:content-classes:message Subject: RE: Correct approach to certificate validation? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCF5B.E53BE647" Date: Mon, 5 Jun 2000 19:06:58 -0700 Message-ID: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/OUXENZWU7kKKKSiGW3PjfnPmrlwBBTGGg From: "Trevor Freeman" To: Cc: X-OriginalArrivalTime: 06 Jun 2000 02:06:59.0099 (UTC) FILETIME=[E59E3EB0:01BFCF5B] Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------_=_NextPart_001_01BFCF5B.E53BE647 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Denis, We have found that enforcing name chaining in path construction, causes more problems than it solves. We therefore have reverted to using the name as just a hint, rather than a critical factor and will as you have found, use a certificate signed with the right key as a valid parent in that chain. This applies to intermediate as well as self signed certificates. We have seen customer scenarios where you need to deliberately build certificates which don't chain on names so enforcing name chaining would cause problems.=20 I know this is at odds with RFC2459, but as this behaviour does not in our view cause a security problem, but does make the overall process more robust, we have and will continue to opt for the more robust solution.=20 I have also posted previously on the list that mandating name chaining, in addition to signatures and policy chaining is a bad idea. Trevor -----Original Message----- From: denis.bider@siol.net [mailto:denis.bider@siol.net] Sent: Sunday, June 04, 2000 11:19 AM To: ietf-pkix@imc.org Subject: Correct approach to certificate validation? Now, based on my previous message, my question for this workgroup: Which of these approaches is correct? - the approach of IE5 and Outlook, which, if an Authority Key Identifier extension is present, does not perform a comparison of the issuer-DN in the subject-cert to the subject-DN of the root-cert? - or the approach of Netscape and IIS4, which, even if an Authority Key Identifier extension is present, DOES still perform a comparison of the subject-cert-issuer-DN to the root-cert-subject-DN? Regards, denis bider PS. I would like to thank Ace Swerling from Microsoft Consulting Services for the fact that he bothered to look into my problem, and especially to Peter Williams from Valicert who devoted much of his time to help me solve this issue. I appreciate your feedback very much. -----Original Message----- From: denis bider [mailto:denis@denisbider.com] On Behalf Of denis.bider@siol.net Sent: Sunday, June 04, 2000 20:08 To: 'ietf-pkix@imc.org' Subject: Report - certificate validation in IE5, Outlook, IIS4, Netscape 4.72 Hello, a while ago I sent to this list an enquiry regarding Microsoft's certificate validation code in IIS4. I have now resolved the problem that was the reason for my enquiry. Since the solution to the problem produced some interesting insight into how certificate chains are handled in IE5 and Outlook / IIS4 and Netscape, and since the behavior in question should be covered by RFC2459, but does not seem to be, I am forwarding my findings to you. I produced my own certificate generating utility, the intention of which was to generate certificates which could be used by IE5 to login into an SSL-protected web site running on IIS4. My problem was that, although IE5 claimed my root-cert/subject-cert certificate chain to be valid, and although Outlook properly signed and verified messages signed by these certificates, IIS4 rejected all attempts to use the subject certificate for SSL client authentication. Also, when the subject certificate was imported into Netscape, Netscape didn't even show it as an elligible choice for SSL client authentication. To sum it up, the problem was that there was a glitch in my code that caused the subject-DN in root-cert to be slightly different from the issuer-DN in the subject-cert. It seems that the certificate verification code in IE5 and Outlook2000 is somewhat easy-going, since both of these products validated the pair of certificates as valid (they performed cert-chain validation solely on the grounds of the key identifier in the Authority Key Identifier extension, they did not compare the sub-cert-issuerDN to the root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand, seem to have a more stringent policy, since they both rejected these certificates. denis bider ------_=_NextPart_001_01BFCF5B.E53BE647 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

Hi Denis,
We have found that enforcing name chaining in path = construction, causes more problems than it solves. We therefore have = reverted to using the name as just a hint, rather than a critical factor = and will as you have found, use a certificate signed with the right key = as a valid parent in that chain. This applies to intermediate as well as = self signed certificates. We have seen customer scenarios where you need = to deliberately build certificates which don't chain on names so = enforcing name chaining would cause problems.

I know this is at odds with RFC2459, but as this = behaviour does not in our view cause a security problem, but does make = the overall process more robust, we have and will continue to opt for = the more robust solution.

I have also posted previously on the list that = mandating name chaining, in addition to signatures and policy chaining = is a bad idea.

Trevor

-----Original Message-----
From: denis.bider@siol.net [mailto:denis.bider@siol.net]
Sent: Sunday, June 04, 2000 11:19 AM
To: ietf-pkix@imc.org
Subject: Correct approach to certificate = validation?


Now, based on my previous message, my question for = this workgroup:

Which of these approaches is correct?
  - the approach of IE5 and Outlook, which, if = an Authority Key Identifier
extension is present, does not perform a comparison = of the issuer-DN in the
subject-cert to the subject-DN of the = root-cert?
  - or the approach of Netscape and IIS4, which, = even if an Authority Key
Identifier extension is present, DOES still perform a = comparison of the
subject-cert-issuer-DN to the = root-cert-subject-DN?

Regards,

denis bider

PS. I would like to thank Ace Swerling from Microsoft = Consulting Services
for the fact that he bothered to look into my = problem, and especially to
Peter Williams from Valicert who devoted much of his = time to help me solve
this issue. I appreciate your feedback very = much.


 -----Original Message-----
From:   denis bider [mailto:denis@denisbider.com]&nbs= p; On Behalf Of
denis.bider@siol.net
Sent:   Sunday, June 04, 2000 20:08
To:     = 'ietf-pkix@imc.org'
Subject:        = Report - certificate validation in IE5, Outlook, IIS4, Netscape
4.72

Hello,

a while ago I sent to this list an enquiry regarding = Microsoft's certificate
validation code in IIS4. I have now resolved the = problem that was the reason
for my enquiry. Since the solution to the problem = produced some interesting
insight into how certificate chains are handled in = IE5 and Outlook / IIS4
and Netscape, and since the behavior in question = should be covered by
RFC2459, but does not seem to be, I am forwarding my = findings to you.

I produced my own certificate generating utility, the = intention of which was
to generate certificates which could be used by IE5 = to login into an
SSL-protected web site running on IIS4. My problem = was that, although IE5
claimed my root-cert/subject-cert certificate chain = to be valid, and
although Outlook properly signed and verified = messages signed by these
certificates, IIS4 rejected all attempts to use the = subject certificate for
SSL client authentication. Also, when the subject = certificate was imported
into Netscape, Netscape didn't even show it as an = elligible choice for SSL
client authentication.

To sum it up, the problem was that there was a glitch = in my code that caused
the subject-DN in root-cert to be slightly different = from the issuer-DN in
the subject-cert. It seems that the certificate = verification code in IE5 and
Outlook2000 is somewhat easy-going, since both of = these products validated
the pair of certificates as valid (they performed = cert-chain validation
solely on the grounds of the key identifier in the = Authority Key Identifier
extension, they did not compare the sub-cert-issuerDN = to the
root-cert-subjectDN). IIS4 and Netscape Communicator, = on the other hand,
seem to have a more stringent policy, since they both = rejected these
certificates.

denis bider

------_=_NextPart_001_01BFCF5B.E53BE647-- From owner-ietf-pkix@imc.org Mon Jun 5 23:29:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15830 for ; Mon, 5 Jun 2000 23:29:08 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA25051; Mon, 5 Jun 2000 20:20:09 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jun 2000 20:20:04 -0700 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA25000 for ; Mon, 5 Jun 2000 20:20:03 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVP00GA6QU60D@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Mon, 5 Jun 2000 20:25:18 -0700 (PDT) Date: Mon, 05 Jun 2000 20:25:38 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: Denis Pinkas Cc: "'ietf-pkix@imc.org'" Message-id: <393C6F32.C7B0BEF8@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <852568F2.0050472B.00@D51MTA04.pok.ibm.com> <393BA827.6487CB21@bull.net> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Denis Pinkas wrote: > I propose that we all look back > at the definition we have in the current document. > > " By adding the XXXX value to the GeneralizedTime, an upper limit of > the time at which the timestamp has been created by the TSA can be > obtained. In the same way, by subtracting the XXXX to the > GeneralizedTime, a lower limit of the time at which the timestamp > has been created by the TSA can be obtained." > > The single remaining question is how do you call XXXX, while > sticking to THIS definition. It is currently called "accuracy". If > this term is not adequate, please make a proposal. I would like to > close this issue soon. > Dennis: The question is not so much what it is called (even though it would be nice to use an already accepted name for it) but that THIS definition is broken. Pls see the former emails. So, one should not stick to THIS definition. Cheers, Ed Gerck From owner-ietf-pkix@imc.org Tue Jun 6 02:17:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28948 for ; Tue, 6 Jun 2000 02:17:21 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA08992; Mon, 5 Jun 2000 23:08:16 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 5 Jun 2000 23:08:07 -0700 Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA08958 for ; Mon, 5 Jun 2000 23:08:05 -0700 (PDT) From: amir.herzberg@il.ibm.com Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA265246; Tue, 6 Jun 2000 08:15:44 +0200 Received: from d12mta05.de.ibm.com (d12mta05_cs0 [9.165.222.239]) by d12relay01.de.ibm.com (8.8.8m3/NCO v2.07) with SMTP id IAA210996; Tue, 6 Jun 2000 08:15:44 +0200 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12568F6.00226433 ; Tue, 6 Jun 2000 08:15:38 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: "Trevor Freeman" cc: denis.bider@siol.net, ietf-pkix@imc.org Message-ID: Date: Tue, 6 Jun 2000 09:11:21 +0300 Subject: RE: Correct approach to certificate validation? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Trevor says, > We have found that enforcing name chaining in path construction, causes > more problems than it solves. We therefore have reverted to using the > name as just a hint, rather than a critical factor and will as you have > I know this is at odds with RFC2459, but as this behaviour does not in > our view cause a security problem, but does make the overall process > more robust, we have and will continue to opt for the more robust I agree. Names are just one of the potential attributes for the holder of the secret key certified; they should not be used for chaining decisions. Also the use of names for access control is dangerous, as the policy makers may not realize that the names are not necessarily secure and they must depend on the proper chain of trust. Best, Amir Herzberg From owner-ietf-pkix@imc.org Tue Jun 6 04:39:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29915 for ; Tue, 6 Jun 2000 04:39:30 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA15918; Tue, 6 Jun 2000 01:25:24 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jun 2000 01:25:14 -0700 Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA15883 for ; Tue, 6 Jun 2000 01:25:11 -0700 (PDT) Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA15078; Tue, 6 Jun 2000 10:33:14 +0200 Message-ID: <393CB74A.5F138132@bull.net> Date: Tue, 06 Jun 2000 10:33:14 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Trevor Freeman CC: denis.bider@siol.net, ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > Hi Denis, Now there are two Denis on the list. Don't be confused, the one above is not me ! :-) It seems that we are starting a very interesting threat. > We have found that enforcing name chaining in path construction, > causes more problems than it solves. We therefore have reverted to > using the name as just a hint, rather than a critical factor and > will as you have found, use a certificate signed with the right > key as a valid parent in that chain. To be more precise, do you mean that you are using the authority key identifier extension ? This extension provides a means of identifying the public key corresponding to the private key used to sign a certificate. The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate chain building. If this is what you use, this means that you use a field that must be present but does not need to be understood, since this extension is marked NON critical. If your implementation relies on that field, which options of that field are you using (since this is a sequence of three optional fields) ? If I misunderstood what you are using, please clarify. > This applies to intermediate > as well as self signed certificates. We have seen customer > scenarios where you need to deliberately build certificates which > don't chain on names so enforcing name chaining would cause > problems. It is true that enforcing name constraints within certificates themselves provides limitations and causes problems. Enforcing name chaining outside the certificates is much morer flexible ... and should be recognized as a valid additional check in the "son-of-RFC2459". > I know this is at odds with RFC2459, but as this behaviour does > not in our view cause a security problem, but does make the > overall process more robust, we have and will continue to opt for > the more robust solution. It seems to early at this stage to conclude that there are no security problems with such an approach (there are not enough information at this stage to make any conclusion). Just a remainder. The basic principle is the following: it is not because a CA certificate exists that it should be trusted. Denis > I have also posted previously on the list that mandating name > chaining, in addition to signatures and policy chaining is a bad > idea. > > Trevor > > -----Original Message----- > From: denis.bider@siol.net [mailto:denis.bider@siol.net] > Sent: Sunday, June 04, 2000 11:19 AM > To: ietf-pkix@imc.org > Subject: Correct approach to certificate validation? > > Now, based on my previous message, my question for this workgroup: > > Which of these approaches is correct? > - the approach of IE5 and Outlook, which, if an Authority Key > Identifier > extension is present, does not perform a comparison of the > issuer-DN in the > subject-cert to the subject-DN of the root-cert? > - or the approach of Netscape and IIS4, which, even if an > Authority Key > Identifier extension is present, DOES still perform a comparison > of the > subject-cert-issuer-DN to the root-cert-subject-DN? > > Regards, > > denis bider > > PS. I would like to thank Ace Swerling from Microsoft Consulting > Services > for the fact that he bothered to look into my problem, and > especially to > Peter Williams from Valicert who devoted much of his time to help > me solve > this issue. I appreciate your feedback very much. > > -----Original Message----- > From: denis bider [mailto:denis@denisbider.com] On Behalf Of > denis.bider@siol.net > Sent: Sunday, June 04, 2000 20:08 > To: 'ietf-pkix@imc.org' > Subject: Report - certificate validation in IE5, Outlook, > IIS4, Netscape > 4.72 > > Hello, > > a while ago I sent to this list an enquiry regarding Microsoft's > certificate > validation code in IIS4. I have now resolved the problem that was > the reason > for my enquiry. Since the solution to the problem produced some > interesting > insight into how certificate chains are handled in IE5 and Outlook > / IIS4 > and Netscape, and since the behavior in question should be covered > by > RFC2459, but does not seem to be, I am forwarding my findings to > you. > > I produced my own certificate generating utility, the intention of > which was > to generate certificates which could be used by IE5 to login into > an > SSL-protected web site running on IIS4. My problem was that, > although IE5 > claimed my root-cert/subject-cert certificate chain to be valid, > and > although Outlook properly signed and verified messages signed by > these > certificates, IIS4 rejected all attempts to use the subject > certificate for > SSL client authentication. Also, when the subject certificate was > imported > into Netscape, Netscape didn't even show it as an elligible choice > for SSL > client authentication. > > To sum it up, the problem was that there was a glitch in my code > that caused > the subject-DN in root-cert to be slightly different from the > issuer-DN in > the subject-cert. It seems that the certificate verification code > in IE5 and > Outlook2000 is somewhat easy-going, since both of these products > validated > the pair of certificates as valid (they performed cert-chain > validation > solely on the grounds of the key identifier in the Authority Key > Identifier > extension, they did not compare the sub-cert-issuerDN to the > root-cert-subjectDN). IIS4 and Netscape Communicator, on the other > hand, > seem to have a more stringent policy, since they both rejected > these > certificates. > > denis bider From owner-ietf-pkix@imc.org Tue Jun 6 05:22:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00128 for ; Tue, 6 Jun 2000 05:22:46 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA18055; Tue, 6 Jun 2000 02:13:10 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jun 2000 02:13:02 -0700 Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18023 for ; Tue, 6 Jun 2000 02:13:00 -0700 (PDT) Received: from m1.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id SAA22192 for ; Tue, 6 Jun 2000 18:20:44 +0900 (JST) (envelope-from takiguti@fjh.se.fujitsu.co.jp) Received: from nic10.fjh.se.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-0006-Fujitsu Domain Master) id SAA29009; Tue, 6 Jun 2000 18:20:43 +0900 (JST) Received: from clapton (clapton.fjh.se.fujitsu.co.jp [10.131.201.91]) by nic10.fjh.se.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA04083 for ; Tue, 6 Jun 2000 18:20:42 +0900 (JST) Date: Tue, 06 Jun 2000 18:20:42 +0900 From: TAKIGUCHI Naruhito To: ietf-pkix@imc.org Subject: certificate policies extension in RFC2459 and son of RFC2459 Message-Id: <20000606180010.AFBC.TAKIGUTI@fjh.se.fujitsu.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00 (beta 17) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi, all. It seems to me that there is an inconsistency between RFC2459 and son of RFC2459 about verifying the certificate policies extension. In RFC2459, if the certificate policies extension is marked as non-critical, it is not processed. But in son of RFC2459, the certificate policies extension is processed regardless of its critical flag. For example, consider there is a certificate path such below, and the acceptable policy set is (A). In RFC2459, this path's validation processing will succeed. But in son of RFC2459, this path's validation processing will be failed. +------------------------+ | root CA cert | | | | critical policy(A) | +------------------------+ | +------------------------+ | end entity cert | | | | non-critical policy(B) | +------------------------+ And, son of RFC2459 requires that certificate must have a certificate policies extension? Thus, son of RFC2459 doesn't have compatibility with a certificate which was issued based on RFC2459? Do I misunderstand? Could anyone advice me? Thanks in advance. ----- Naruhito TAKIGUCHI FUJITSU HOKURIKU SYSTEMS LTD. From owner-ietf-pkix@imc.org Tue Jun 6 09:45:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01988 for ; Tue, 6 Jun 2000 09:45:37 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA00797; Tue, 6 Jun 2000 06:05:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jun 2000 06:05:18 -0700 Received: from exchng-fairfax.pec.com (exchng-fairfax.pec.com [204.254.216.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA00764 for ; Tue, 6 Jun 2000 06:05:18 -0700 (PDT) Received: by EXCHNG-FAIRFAX with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Jun 2000 08:55:38 -0400 Message-ID: <5023FFCA43D8D311A8360008C7F450FD012440D1@EXCHNG-FAIRFAX> From: AFlyak To: "'ietf-pkix@imc.org'" Subject: Subscribe Date: Tue, 6 Jun 2000 08:55:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCFB6.82FC6A80" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFCFB6.82FC6A80 Content-Type: text/plain ------_=_NextPart_001_01BFCFB6.82FC6A80 Content-Type: text/html Subscribe ------_=_NextPart_001_01BFCFB6.82FC6A80-- From owner-ietf-pkix@imc.org Tue Jun 6 10:22:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07750 for ; Tue, 6 Jun 2000 10:22:22 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA02120; Tue, 6 Jun 2000 07:06:35 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jun 2000 07:06:28 -0700 Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02090 for ; Tue, 6 Jun 2000 07:06:27 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Jun 2000 10:14:12 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B101715958@sothmxs06.entrust.com> From: Carlisle Adams To: "'Alan Shepherd'" Cc: "'ietf-pkix@imc.org'" Subject: RE: Protocol Action: Diffie-Hellman Proof-of-Possession Algorithm s to Proposed Standard Date: Tue, 6 Jun 2000 10:14:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi Alan, I make no claim to be "someone wiser", but I will point out that proof-of-possession threads have been both long and numerous on this list in the past. The basic principle is that POP is not primarily done to avoid security problems. A basic underlying assumption in any certificate-using environment is that the entity bound to the certificate actually holds the corresponding private key. POP ensures that this assumption is valid (at least at the time of certificate creation). If I can't assume that you hold the private key, why in the world would I use your certificate? If I have no fundamental reason to use your certificate, why does the certificate (and, through generalization, the PKI) exist? POP is done by a CA (or occasionally as part of an operational protocol between parties) to try and ensure that certificates have some meaning and value and are not just worthless strings of bits. If a particular security problem can be avoided in some cases by doing POP, that's just a useful side benefit. Carlisle. > ---------- > From: Alan Shepherd[SMTP:Alan.Shepherd@protek.com] > Sent: Monday, June 05, 2000 11:58 AM > To: 'ietf-pkix@imc.org' > Subject: RE: Protocol Action: Diffie-Hellman Proof-of-Possession > Algorithm s to Proposed Standard > > Please forgive me if this is a terribly naive question, but I would like > to > know what problems arise if a public key is certified erroneously. I can > not see what security problems arise through this and would very much > appreciate someone wiser explaining it! > > Thanks for you help. > > Alan > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: 31 May 2000 14:03 > > Cc: RFC Editor; RFC Editor; RFC Editor > > Subject: Protocol Action: Diffie-Hellman Proof-of-Possession > > Algorithms > > to Proposed Standard > > > > > > > > > > The IESG has approved the Internet-Draft 'Diffie-Hellman > > Proof-of-Possession Algorithms' as a > > Proposed Standard. This document is the product of the Public-Key > > Infrastructure (X.509) Working Group. The IESG contact persons are > > Jeffrey Schiller and Marcus Leech. > > > > > > > > Technical Summary > > > > One of the important requirements in cryptographic protocols is the > > ability for an entity to prove they have possession of a particular > > key. In particular, Certifying Authorities prior to the > > issuance of a > > certificate, need to prove that the entity for which the certificate > > will be issued in fact does have the private key that corresponds to > > the public key which is included in the certificate. > > > > The traditional approach used with public key encryption > > systems such > > as the RSA system is to have the challenger require the entity > > holding a given private key to sign a challenge string. > > > > However the Diffie-Hellman (DH) algorithm does not directly lend > > itself to providing such signatures, as it is at heart a key > > agreement algorithm. This document describes two methods for > > producing a signature from a Diffie-Hellman key pair. > > > > Working Group Summary > > > > Consensus was reached on the approach used in this document. > > > > Protocol Quality > > > > Jeffrey I. Schiller reviewed this document for the IESG. Furthermore > > the PKIX Working Group contains members with significant > > cryptographic experience who also have reviewed this document. > > > > Note to RFC Editor: > > > > There were some word-wrapping problems introduced in Appendix A of > > the document that need to be corrected: > > > > Appendix A: > > > > OLD: > > DH-Sign DEFINITIONS IMPLICIT TAGS ::= > > > > BEGIN > > --EXPORTS ALL > > -- The types and values defined in this module are exported for use > > in > > -- the other ASN.1 modules. Other applications may use them for > > their > > -- own purposes. > > > > NEW/FIXED: > > DH-Sign DEFINITIONS IMPLICIT TAGS ::= > > > > BEGIN > > --EXPORTS ALL > > -- The types and values defined in this module are exported for use > > -- in the other ASN.1 modules. Other applications may use them > > -- for their own purposes. > > > > -------------------------------------------------------------------------- > ---------------- > This message is for the named person's use only. It may contain > confidential, proprietary or legally privileged information. No > confidentiality or privilege is waived or lost by any mistransmission. If > you receive this message in error, please immediately delete it and all > copies of it from your system, destroy any hard copies of it and notify > the sender. You must not, directly or indirectly, use, disclose, > distribute, print, or copy any part of this message if you are not the > intended recipient. PROTEK Network Management Group and each of its > subsidiaries reserve the right to monitor all e-mail communications > through its networks. Any views expressed in this message are those of > the individual sender, except where the message states otherwise and the > sender is authorised to state them to be the views of any such entity. > > > > From owner-ietf-pkix@imc.org Tue Jun 6 14:26:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16312 for ; Tue, 6 Jun 2000 14:26:08 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA11562; Tue, 6 Jun 2000 11:14:10 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jun 2000 11:13:52 -0700 Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11523 for ; Tue, 6 Jun 2000 11:13:51 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id OAA12643 for ; Tue, 6 Jun 2000 14:15:00 -0400 (EDT) Message-Id: <200006061815.OAA12639@roadblock.missi.ncsc.mil> Date: Tue, 6 Jun 2000 14:19:35 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Correct approach to certificate validation? To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0LuwLJjq80ZHj0Whgd4ZSQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Trevor, Could you describe a customer scenario which requires deliberate non-chaining of names? I can't envision any circumstance where a CA 1) does not have a certificate containing the CA's signing key and a subject name for the CA, or 2) cannot populate the issuer and signature-value fields of certificates it issues with values matching the subject name and public key from its own cert. Enforcing name chaining during path construction does not cause problems; it highlights existing problems. When a system continues to function in an environment with errors over which it has no control (transmission bit errors, for example), it is called "robust". But when a system continues to function normally in the face of correctable errors without providing any indication of a problem, "oblivious" is a better term than "robust". Like fixing an engine problem by removing the offending indicator lamp from the dashboard. I agree that ignoring name chaining errors during path construction or validation does not cause a "security" problem, using a sufficiently limited definition of security. But the real security of a system depends on (among other things) correct administration, and anything which promotes sloppy administration promotes sloppy security. I therefore disagree that applications should ignore the path validation requirements of X.509: "a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked." This name chaining requirement wasn't inserted willy-nilly into RFC 2459, it has been a fundamental part of an International Standard for twelve years. Saying "we don't like this requirement, so we are going to ignore it" is undoubtedly an option for a company with the market cap of MSFT. But customers for whom standards conformance is a checklist item should be fully informed that you have chosen not to conform to either X.509 or RFC 2459. Dave > From: "Trevor Freeman" > > Hi Denis, > We have found that enforcing name chaining in path construction, causes > more problems than it solves. We therefore have reverted to using the > name as just a hint, rather than a critical factor and will as you have > found, use a certificate signed with the right key as a valid parent in > that chain. This applies to intermediate as well as self signed > certificates. We have seen customer scenarios where you need to > deliberately build certificates which don't chain on names so enforcing > name chaining would cause problems. From owner-ietf-pkix@imc.org Tue Jun 6 23:47:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24580 for ; Tue, 6 Jun 2000 23:47:47 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA17933; Tue, 6 Jun 2000 20:31:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jun 2000 20:30:01 -0700 Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA17819 for ; Tue, 6 Jun 2000 20:30:00 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Jun 2000 20:15:43 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 6 Jun 2000 20:00:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD02C.86E28F9E" Subject: RE: Correct approach to certificate validation? Date: Tue, 6 Jun 2000 20:00:24 -0700 Message-ID: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/P5fPg0KFETdn6Ti6T1E20UgYt4wAQ+O0g From: "Trevor Freeman" To: "David P. Kemp" Cc: X-OriginalArrivalTime: 07 Jun 2000 03:00:26.0390 (UTC) FILETIME=[87B9C360:01BFD02C] Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD02C.86E28F9E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi David, I am afraid I don't see it necessary to eradicate every little imperfection because it is there. To err is human, and people make mistakes. People also have a wide list of requires which you may or may not agree with, but it does not mean that it is less real to them.=20 So I don't see this as an error, simple a different point of view, and we will obviously disagree on this point. At the end of the day it is up to any product vendor to make the call as to what is\is not in their product, regardless what is in the standard. It is up to the market place to decide. History certainly tells us that customers like robustness in a product. If you can cite a specific issue, then we will obviously reconsider, but I don't find punishing minor infractions of administrators a compelling case. Trevor -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]=20 Sent: Tuesday, June 06, 2000 11:20 AM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, Could you describe a customer scenario which requires deliberate non-chaining of names? I can't envision any circumstance where a CA 1) does not have a certificate containing the CA's signing key and a subject name for the CA, or 2) cannot populate the issuer and signature-value fields of certificates it issues with values matching the subject name and public key from its own cert. Enforcing name chaining during path construction does not cause problems; it highlights existing problems. When a system continues to function in an environment with errors over which it has no control (transmission bit errors, for example), it is called "robust". But when a system continues to function normally in the face of correctable errors without providing any indication of a problem, "oblivious" is a better term than "robust". Like fixing an engine problem by removing the offending indicator lamp from the dashboard. I agree that ignoring name chaining errors during path construction or validation does not cause a "security" problem, using a sufficiently limited definition of security. But the real security of a system depends on (among other things) correct administration, and anything which promotes sloppy administration promotes sloppy security. I therefore disagree that applications should ignore the path validation requirements of X.509: "a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked." This name chaining requirement wasn't inserted willy-nilly into RFC 2459, it has been a fundamental part of an International Standard for twelve years. Saying "we don't like this requirement, so we are going to ignore it" is undoubtedly an option for a company with the market cap of MSFT. But customers for whom standards conformance is a checklist item should be fully informed that you have chosen not to conform to either X.509 or RFC 2459. Dave > From: "Trevor Freeman" >=20 > Hi Denis,=20 > We have found that enforcing name chaining in path construction, causes > more problems than it solves. We therefore have reverted to using the > name as just a hint, rather than a critical factor and will as you have > found, use a certificate signed with the right key as a valid parent in > that chain. This applies to intermediate as well as self signed > certificates. We have seen customer scenarios where you need to > deliberately build certificates which don't chain on names so enforcing > name chaining would cause problems. ------_=_NextPart_001_01BFD02C.86E28F9E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

Hi David,
I am afraid I don't see it necessary to eradicate every little = imperfection because it is there. To err is human, and people make = mistakes. People also have a wide list of requires which you may or may = not agree with, but it does not mean that it is less real to them.
So I don't see this as an error, simple a different point of view, and = we will obviously disagree on this point.
At the end of the day it is up to any product vendor to make the call as = to what is\is not in their product, regardless what is in the standard. = It is up to the market place to decide. History certainly tells us that = customers like robustness in a product.
If you can cite a specific issue, then we will obviously reconsider, but = I don't find punishing minor infractions of administrators a compelling = case.
Trevor

 -----Original Message-----
From:   David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent:   Tuesday, June 06, 2000 11:20 AM
To:     ietf-pkix@imc.org
Subject:        RE: Correct approach = to certificate validation?

Trevor,

Could you describe a customer scenario which requires deliberate
non-chaining of names?  I can't envision any circumstance where = a
CA 1) does not have a certificate containing the CA's signing key
and a subject name for the CA, or 2) cannot populate the issuer and
signature-value fields of certificates it issues with values = matching
the subject name and public key from its own cert.

Enforcing name chaining during path construction does not cause
problems; it highlights existing problems.  When a system = continues
to function in an environment with errors over which it has no = control
(transmission bit errors, for example), it is called = "robust".  But
when a system continues to function normally in the face of = correctable
errors without providing any indication of a problem, = "oblivious" is a
better term than "robust".  Like fixing an engine problem = by removing
the offending indicator lamp from the dashboard.

I agree that ignoring name chaining errors during path construction
or validation does not cause a "security" problem, using a = sufficiently
limited definition of security.  But the real security of a = system
depends on (among other things) correct administration, and anything
which promotes sloppy administration promotes sloppy security.
I therefore disagree that applications should ignore the path
validation requirements of X.509:

  "a) Check that the signature verifies, that dates are valid, = that
      the certificate subject and certificate = issuer names chain
      correctly, and that the certificate has = not been revoked."

This name chaining requirement wasn't inserted willy-nilly into RFC
2459, it has been a fundamental part of an International Standard = for
twelve years. Saying "we don't like this requirement, so we are = going
to ignore it" is undoubtedly an option for a company with the = market
cap of MSFT.  But customers for whom standards conformance is a
checklist item should be fully informed that you have chosen not
to conform to either X.509 or RFC 2459.

Dave



> From: "Trevor Freeman" = <trevorf@Exchange.Microsoft.com>
>
> Hi Denis,
> We have found that enforcing name chaining in path construction, = causes
> more problems than it solves. We therefore have reverted to using = the
> name as just a hint, rather than a critical factor and will as you = have
> found, use a certificate signed with the right key as a valid = parent in
> that chain. This applies to intermediate as well as self signed
> certificates. We have seen customer scenarios where you need to
> deliberately build certificates which don't chain on names so = enforcing
> name chaining would cause problems.

------_=_NextPart_001_01BFD02C.86E28F9E-- From owner-ietf-pkix@imc.org Tue Jun 6 23:53:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24619 for ; Tue, 6 Jun 2000 23:53:33 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA18130; Tue, 6 Jun 2000 20:32:54 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jun 2000 20:32:53 -0700 Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA18097 for ; Tue, 6 Jun 2000 20:32:52 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Jun 2000 20:27:51 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 6 Jun 2000 19:42:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD029.F8666240" Subject: RE: Correct approach to certificate validation? Date: Tue, 6 Jun 2000 19:42:06 -0700 Message-ID: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/PkgXOegneKI+lRJ+EziTFYwDm3QAln9VQ From: "Trevor Freeman" To: "Denis Pinkas" Cc: , X-OriginalArrivalTime: 07 Jun 2000 02:42:08.0015 (UTC) FILETIME=[F90B09F0:01BFD029] Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD029.F8666240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We use AKI, but don't require it, as the field can be calculated on the fly so to speak. I am not linking the enforcement of name constrains with the enforcement of name chaining in any. We will enforce name constraints as this is a security issue, we don't enforce name chaining.=20 We trust the CA because we have built a chain of certificate to a trusted root, with valid policy and name constraints. -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]=20 Sent: Tuesday, June 06, 2000 1:33 AM To: Trevor Freeman Cc: denis.bider@siol.net; ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? > Hi Denis, Now there are two Denis on the list. Don't be confused, the one above is not me ! :-) It seems that we are starting a very interesting threat. > We have found that enforcing name chaining in path construction, > causes more problems than it solves. We therefore have reverted to > using the name as just a hint, rather than a critical factor and > will as you have found, use a certificate signed with the right > key as a valid parent in that chain.=20 To be more precise, do you mean that you are using the authority key identifier extension ? This extension provides a means of identifying the public key corresponding to the private key used to sign a certificate. The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate chain building.=20 If this is what you use, this means that you use a field that must be present but does not need to be understood, since this extension is marked NON critical. If your implementation relies on that field, which options of that field are you using (since this is a sequence of three optional fields) ? If I misunderstood what you are using, please clarify. > This applies to intermediate > as well as self signed certificates. We have seen customer > scenarios where you need to deliberately build certificates which > don't chain on names so enforcing name chaining would cause > problems. It is true that enforcing name constraints within certificates themselves provides limitations and causes problems. Enforcing name chaining outside the certificates is much morer flexible ... and should be recognized as a valid additional check in the "son-of-RFC2459".=20 > I know this is at odds with RFC2459, but as this behaviour does > not in our view cause a security problem, but does make the > overall process more robust, we have and will continue to opt for > the more robust solution. It seems to early at this stage to conclude that there are no security problems with such an approach (there are not enough information at this stage to make any conclusion). Just a remainder. The basic principle is the following: it is not because a CA certificate exists that it should be trusted.=20 Denis =20 > I have also posted previously on the list that mandating name > chaining, in addition to signatures and policy chaining is a bad > idea. >=20 > Trevor >=20 > -----Original Message----- > From: denis.bider@siol.net [mailto:denis.bider@siol.net] > Sent: Sunday, June 04, 2000 11:19 AM > To: ietf-pkix@imc.org > Subject: Correct approach to certificate validation? >=20 > Now, based on my previous message, my question for this workgroup: >=20 > Which of these approaches is correct? > - the approach of IE5 and Outlook, which, if an Authority Key > Identifier > extension is present, does not perform a comparison of the > issuer-DN in the > subject-cert to the subject-DN of the root-cert? > - or the approach of Netscape and IIS4, which, even if an > Authority Key > Identifier extension is present, DOES still perform a comparison > of the > subject-cert-issuer-DN to the root-cert-subject-DN? >=20 > Regards, >=20 > denis bider >=20 > PS. I would like to thank Ace Swerling from Microsoft Consulting > Services > for the fact that he bothered to look into my problem, and > especially to > Peter Williams from Valicert who devoted much of his time to help > me solve > this issue. I appreciate your feedback very much. >=20 > -----Original Message----- > From: denis bider [mailto:denis@denisbider.com] On Behalf Of > denis.bider@siol.net > Sent: Sunday, June 04, 2000 20:08 > To: 'ietf-pkix@imc.org' > Subject: Report - certificate validation in IE5, Outlook, > IIS4, Netscape > 4.72 >=20 > Hello, >=20 > a while ago I sent to this list an enquiry regarding Microsoft's > certificate > validation code in IIS4. I have now resolved the problem that was > the reason > for my enquiry. Since the solution to the problem produced some > interesting > insight into how certificate chains are handled in IE5 and Outlook > / IIS4 > and Netscape, and since the behavior in question should be covered > by > RFC2459, but does not seem to be, I am forwarding my findings to > you. >=20 > I produced my own certificate generating utility, the intention of > which was > to generate certificates which could be used by IE5 to login into > an > SSL-protected web site running on IIS4. My problem was that, > although IE5 > claimed my root-cert/subject-cert certificate chain to be valid, > and > although Outlook properly signed and verified messages signed by > these > certificates, IIS4 rejected all attempts to use the subject > certificate for > SSL client authentication. Also, when the subject certificate was > imported > into Netscape, Netscape didn't even show it as an elligible choice > for SSL > client authentication. >=20 > To sum it up, the problem was that there was a glitch in my code > that caused > the subject-DN in root-cert to be slightly different from the > issuer-DN in > the subject-cert. It seems that the certificate verification code > in IE5 and > Outlook2000 is somewhat easy-going, since both of these products > validated > the pair of certificates as valid (they performed cert-chain > validation > solely on the grounds of the key identifier in the Authority Key > Identifier > extension, they did not compare the sub-cert-issuerDN to the > root-cert-subjectDN). IIS4 and Netscape Communicator, on the other > hand, > seem to have a more stringent policy, since they both rejected > these > certificates. >=20 > denis bider ------_=_NextPart_001_01BFD029.F8666240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

We use AKI, but don't require it, as the field can be = calculated on the fly so to speak.
I am not linking the enforcement of name constrains with the enforcement = of name chaining in any. We will enforce name constraints as this is a = security issue, we don't enforce name chaining.
We trust the CA because we have built a chain of certificate to a = trusted root, with valid policy and name constraints.

 -----Original Message-----
From:   Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent:   Tuesday, June 06, 2000 1:33 AM
To:     Trevor Freeman
Cc:     denis.bider@siol.net; ietf-pkix@imc.org
Subject:        Re: Correct approach = to certificate validation?

> Hi Denis,

Now there are two Denis on the list. Don't be confused, the one
above is not me ! :-)

It seems that we are starting a very interesting threat.

> We have found that enforcing name chaining in path = construction,
> causes more problems than it solves. We therefore have reverted = to
> using the name as just a hint, rather than a critical factor = and
> will as you have found, use a certificate signed with the right
> key as a valid parent in that chain.

To be more precise, do you mean that you are using the authority key
identifier extension ?

This extension provides a means of identifying the public key
corresponding to the private key used to sign a certificate. The
keyIdentifier field of the authorityKeyIdentifier extension MUST be
included in all certificates generated by conforming CAs to
facilitate chain building.

If this is what you use, this means that you use a field that must
be present but does not need to be understood, since this extension
is marked NON critical. If your implementation relies on that field,
which options of that field are you using (since this is a sequence
of three optional fields) ? If I misunderstood what you are using,
please clarify.

> This applies to intermediate
> as well as self signed certificates. We have seen customer
> scenarios where you need to deliberately build certificates = which
> don't chain on names so enforcing name chaining would cause
> problems.

It is true that enforcing name constraints within certificates
themselves provides limitations and causes problems. Enforcing name
chaining outside the certificates is much morer flexible ... and
should be recognized as a valid additional check in the
"son-of-RFC2459".

> I know this is at odds with RFC2459, but as this behaviour does
> not in our view cause a security problem, but does make the
> overall process more robust, we have and will continue to opt = for
> the more robust solution.

It seems to early at this stage to conclude that there are no
security problems with such an approach (there are not enough
information at this stage to make any conclusion). Just a remainder.
The basic principle is the following: it is not because a CA
certificate exists that it should be trusted.

Denis

> I have also posted previously on the list that mandating name
> chaining, in addition to signatures and policy chaining is a = bad
> idea.
>
> Trevor
>
> -----Original Message-----
> From: denis.bider@siol.net [mailto:denis.bider@siol.net]
= > Sent: Sunday, June 04, 2000 11:19 AM
> To: ietf-pkix@imc.org
> Subject: Correct approach to certificate validation?
>
> Now, based on my previous message, my question for this = workgroup:
>
> Which of these approaches is correct?
>   - the approach of IE5 and Outlook, which, if an = Authority Key
> Identifier
> extension is present, does not perform a comparison of the
> issuer-DN in the
> subject-cert to the subject-DN of the root-cert?
>   - or the approach of Netscape and IIS4, which, even if = an
> Authority Key
> Identifier extension is present, DOES still perform a = comparison
> of the
> subject-cert-issuer-DN to the root-cert-subject-DN?
>
> Regards,
>
> denis bider
>
> PS. I would like to thank Ace Swerling from Microsoft = Consulting
> Services
> for the fact that he bothered to look into my problem, and
> especially to
> Peter Williams from Valicert who devoted much of his time to = help
> me solve
> this issue. I appreciate your feedback very much.
>
>  -----Original Message-----
> From:   denis bider [mailto:denis@denisbider.com]&nbs= p; On Behalf Of
> denis.bider@siol.net
> Sent:   Sunday, June 04, 2000 20:08
> To:     'ietf-pkix@imc.org'
> Subject:        Report - = certificate validation in IE5, Outlook,
> IIS4, Netscape
> 4.72
>
> Hello,
>
> a while ago I sent to this list an enquiry regarding = Microsoft's
> certificate
> validation code in IIS4. I have now resolved the problem that = was
> the reason
> for my enquiry. Since the solution to the problem produced some
> interesting
> insight into how certificate chains are handled in IE5 and = Outlook
> / IIS4
> and Netscape, and since the behavior in question should be = covered
> by
> RFC2459, but does not seem to be, I am forwarding my findings = to
> you.
>
> I produced my own certificate generating utility, the intention = of
> which was
> to generate certificates which could be used by IE5 to login = into
> an
> SSL-protected web site running on IIS4. My problem was that,
> although IE5
> claimed my root-cert/subject-cert certificate chain to be = valid,
> and
> although Outlook properly signed and verified messages signed = by
> these
> certificates, IIS4 rejected all attempts to use the subject
> certificate for
> SSL client authentication. Also, when the subject certificate = was
> imported
> into Netscape, Netscape didn't even show it as an elligible = choice
> for SSL
> client authentication.
>
> To sum it up, the problem was that there was a glitch in my = code
> that caused
> the subject-DN in root-cert to be slightly different from the
> issuer-DN in
> the subject-cert. It seems that the certificate verification = code
> in IE5 and
> Outlook2000 is somewhat easy-going, since both of these = products
> validated
> the pair of certificates as valid (they performed cert-chain
> validation
> solely on the grounds of the key identifier in the Authority = Key
> Identifier
> extension, they did not compare the sub-cert-issuerDN to the
> root-cert-subjectDN). IIS4 and Netscape Communicator, on the = other
> hand,
> seem to have a more stringent policy, since they both rejected
> these
> certificates.
>
> denis bider

------_=_NextPart_001_01BFD029.F8666240-- From owner-ietf-pkix@imc.org Wed Jun 7 00:20:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24782 for ; Wed, 7 Jun 2000 00:20:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA20836; Tue, 6 Jun 2000 21:09:10 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 6 Jun 2000 21:09:08 -0700 Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20804 for ; Tue, 6 Jun 2000 21:09:06 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Jun 2000 14:19:55 +1000 Message-ID: From: "Ramsay, Ron" To: Trevor Freeman , "David P. Kemp" Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Date: Wed, 7 Jun 2000 14:21:04 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Trevor, I don't think David was saying you can't go your own way. In fact, RFC 2459 has a funny statement in it where it recognises that vendors may produce non-conforming products. I think the point he is making is that customers should be made aware that your product conforms neither to RFC 2459 nor to X.509. And I think you agree that it doesn't. Ron. PS These are my views and not those of my employer. -----Original Message----- From: Trevor Freeman [mailto:trevorf@Exchange.Microsoft.com] Sent: Wednesday, 7 June 2000 13:00 To: David P. Kemp Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Hi David, I am afraid I don't see it necessary to eradicate every little imperfection because it is there. To err is human, and people make mistakes. People also have a wide list of requires which you may or may not agree with, but it does not mean that it is less real to them. So I don't see this as an error, simple a different point of view, and we will obviously disagree on this point. At the end of the day it is up to any product vendor to make the call as to what is\is not in their product, regardless what is in the standard. It is up to the market place to decide. History certainly tells us that customers like robustness in a product. If you can cite a specific issue, then we will obviously reconsider, but I don't find punishing minor infractions of administrators a compelling case. Trevor -----Original Message----- From: David P. Kemp [ mailto:dpkemp@missi.ncsc.mil ] Sent: Tuesday, June 06, 2000 11:20 AM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, Could you describe a customer scenario which requires deliberate non-chaining of names? I can't envision any circumstance where a CA 1) does not have a certificate containing the CA's signing key and a subject name for the CA, or 2) cannot populate the issuer and signature-value fields of certificates it issues with values matching the subject name and public key from its own cert. Enforcing name chaining during path construction does not cause problems; it highlights existing problems. When a system continues to function in an environment with errors over which it has no control (transmission bit errors, for example), it is called "robust". But when a system continues to function normally in the face of correctable errors without providing any indication of a problem, "oblivious" is a better term than "robust". Like fixing an engine problem by removing the offending indicator lamp from the dashboard. I agree that ignoring name chaining errors during path construction or validation does not cause a "security" problem, using a sufficiently limited definition of security. But the real security of a system depends on (among other things) correct administration, and anything which promotes sloppy administration promotes sloppy security. I therefore disagree that applications should ignore the path validation requirements of X.509: "a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked." This name chaining requirement wasn't inserted willy-nilly into RFC 2459, it has been a fundamental part of an International Standard for twelve years. Saying "we don't like this requirement, so we are going to ignore it" is undoubtedly an option for a company with the market cap of MSFT. But customers for whom standards conformance is a checklist item should be fully informed that you have chosen not to conform to either X.509 or RFC 2459. Dave > From: "Trevor Freeman" > > Hi Denis, > We have found that enforcing name chaining in path construction, causes > more problems than it solves. We therefore have reverted to using the > name as just a hint, rather than a critical factor and will as you have > found, use a certificate signed with the right key as a valid parent in > that chain. This applies to intermediate as well as self signed > certificates. We have seen customer scenarios where you need to > deliberately build certificates which don't chain on names so enforcing > name chaining would cause problems. From owner-ietf-pkix@imc.org Wed Jun 7 10:06:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10751 for ; Wed, 7 Jun 2000 10:06:50 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA27732; Wed, 7 Jun 2000 06:54:59 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jun 2000 06:54:31 -0700 Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27691 for ; Wed, 7 Jun 2000 06:54:30 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA25323 for ; Wed, 7 Jun 2000 09:55:38 -0400 (EDT) Message-Id: <200006071355.JAA25280@roadblock.missi.ncsc.mil> Date: Wed, 7 Jun 2000 10:00:12 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Correct approach to certificate validation? To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BNyxfe4iNnIIbfsREL1EMg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Trevor, It isn't about punishing administrators for minor errors, it is about achieving an overall system with the goals of being both secure and non-intrusive to the end user. That may well mean that administrators have to do more thinking, planning, and quality control, but that is what they (we, the providers of a PKI for our branch of Govt) are paid to do. The specific case I'm referring to is Jim Schaad's assertion that an S/MIME-specific cert path attribute is needed because applications can't find CA certificates. I didn't realize until now that that was because in your environment subject certificates are not required to have a correct issuer name! It seemed obvious to me that the PKI is responsible for correctly binding names to keys. But you are saying that Issuer names don't really matter, they're just a hint to help applications search for a cert with a signing key that validates the subject cert signature. Well no wonder applications can't find CA certs in that environment! That isn't necessarily a wrong theoretical approach - SPKI is based on the premise that only keys are important, names are simply optional attributes attached to keys. But it is wrong in X.509 because X.509 certificates are identified by and stored under Distinguished Names, not public keys or SubjectKeyIdentifiers. Standards are about interworking in a multi-vendor environment; the testable requirements contained in standards are covenants between supplier and customer. My goal is for a CMI purchased from vendor X and operated by company A to work with applications purchased from vendors Y and Z and operated by companies B and C. I understand that that is not your primary goal, but I expect you to acknowledge that when as a result of non-conformance some applications work and others don't, it is NOT the fault of the conforming applications even when they are the ones that fail. And that when someone from company X proposes as a Standard a workaround for a problem created somewhere else in company X, the IETF is entitled to disregard the company-specific rationale for that workaround. Regards, Dave > From: "Trevor Freeman" > > Hi David, > I am afraid I don't see it necessary to eradicate every little > imperfection because it is there. To err is human, and people make > mistakes. People also have a wide list of requires which you may or may > not agree with, but it does not mean that it is less real to them. > So I don't see this as an error, simple a different point of view, and > we will obviously disagree on this point. > At the end of the day it is up to any product vendor to make the call as > to what is\is not in their product, regardless what is in the standard. > It is up to the market place to decide. History certainly tells us that > customers like robustness in a product. > If you can cite a specific issue, then we will obviously reconsider, but > I don't find punishing minor infractions of administrators a compelling > case. > Trevor From owner-ietf-pkix@imc.org Wed Jun 7 15:56:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19361 for ; Wed, 7 Jun 2000 15:56:46 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA14662; Wed, 7 Jun 2000 12:45:27 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jun 2000 12:45:11 -0700 Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14631 for ; Wed, 7 Jun 2000 12:45:10 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Jun 2000 15:53:00 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B101715960@sothmxs06.entrust.com> From: Carlisle Adams To: borges@sibs.pt, "'stephen.farrell@baltimore.ie'" Cc: ietf-pkix@imc.org Subject: RE: Attribute Certificate Request Date: Wed, 7 Jun 2000 15:53:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi Stephen, Pedro, > ---------- > From: Stephen Farrell[SMTP:stephen.farrell@baltimore.ie] > Reply To: stephen.farrell@baltimore.ie > Sent: Monday, June 05, 2000 3:46 PM > To: borges@sibs.pt > Cc: ietf-pkix@imc.org > Subject: Re: Attribute Certificate Request > > Pedro, > > Since the use cases for ACs aren't as well understood as for > public key certificates, there is, as yet, no equivalent to > CMP/CMC for AC requests. I would expect that, in future, we > might get around to writing one. Actually, the future is not that far away... :-) The draft rfc2510bis puts in place a framework that allows CMP to be used as a general protocol for management (including, of course, an initial request) of any kind of certificate. (Note that this was accomplished without requiring any bits-on-the-wire changes to the RFC 2510 syntax.) Formats that have already been envisioned include attribute certificates and WTLS certificates. This strikes me as a very powerful and useful generalization, and should serve to make this PKIX protocol potentially applicable to a number of environments. All that is required is a very short document listing the certificate types of interest and providing a syntax for their corresponding templates. Look for this Internet Draft to appear shortly (within the next 2-3 weeks, I hope). Carlisle. > Meanwhile, there is draft-ietf-pkix-laap-00.txt which describes > an alternative to LDAP for AC retrieval, though this deliberately > doesn't try to provide the equivalent of a CMP certification > request. > > Regards, > Stephen. > > Pedro Miguel Pereira Borges wrote: > > > > Hi all, > > > > I'm currently reading the "An Internet Attribute Certificate > Profile > > for Authorization" draft... > > However, there is a question that I would like to see answered: > is > > there a definition (ASN.1 or not) of what an attribute certificate > request > > should contain like there is one for the "normal" X.509 ID certificates > ? > > > > Thanks in advance, > > > > Pedro Borges > From owner-ietf-pkix@imc.org Wed Jun 7 16:57:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20594 for ; Wed, 7 Jun 2000 16:57:56 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA16431; Wed, 7 Jun 2000 13:42:54 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jun 2000 13:42:47 -0700 Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16400 for ; Wed, 7 Jun 2000 13:42:47 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Jun 2000 13:45:25 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE235E2D4@seine.valicert.com> From: Peter Williams To: "'David P. Kemp'" Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Date: Wed, 7 Jun 2000 13:45:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe David, "But it is wrong in X.509 because X.509 certificates are identified by and stored under Distinguished Names, not public keys or SubjectKeyIdentifiers." X.509 does not require one to identify a storage location for a cert at all, locate storage using a DN, nor does it require that the DN be used as the subject identity element bound to a key. You should be aware, in further support of my earlier statement, that PKIX certificates need contain no subject DN information. Nor need there be a DN name form populated in the standard alternative name field for subjects, as RFC 2459 authors and chairs declare to the Internet: "The subject alternative names extension allows additional identities to be bound to the subject of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a uniform resource identifier (URI). Other options exist, including completely local definitions [...]" "Further, if the only subject identity included in the certificate is an alternative name form (e.g., an electronic mail address), then the subject distinguished name MUST be empty (an empty sequence), and the subjectAltName extension MUST be present. If the subject field contains an empty sequence, the subjectAltName extension MUST be marked critical." Do you assert that PKIX profile is not aligned with X.509, when you make your various claims concerning DNs? Does a PKIX cert conform to X.509 literally or in spirit, if the actual exampled option stated above in RFC 2459 is used? PS. The PKIX authors' name comparison rules already make PKIX path processing non-conforming against X.509 (i.e. the result of path processing using the PKIX name chaining rule is not the same as if one were to use the X.509 path processing and name matching rule. X.509 conformance is really not an issue in PKIX WG! 2459 already built in the situation that even two PKIX implementations may not process paths the same! A cert chain can be valid in one implementation, and invalid in another; its not clear it the X.509 rules, though permitted by PKIX, make for a conforming path processing implementation. -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Wednesday, June 07, 2000 7:00 AM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, It isn't about punishing administrators for minor errors, it is about achieving an overall system with the goals of being both secure and non-intrusive to the end user. That may well mean that administrators have to do more thinking, planning, and quality control, but that is what they (we, the providers of a PKI for our branch of Govt) are paid to do. The specific case I'm referring to is Jim Schaad's assertion that an S/MIME-specific cert path attribute is needed because applications can't find CA certificates. I didn't realize until now that that was because in your environment subject certificates are not required to have a correct issuer name! It seemed obvious to me that the PKI is responsible for correctly binding names to keys. But you are saying that Issuer names don't really matter, they're just a hint to help applications search for a cert with a signing key that validates the subject cert signature. Well no wonder applications can't find CA certs in that environment! That isn't necessarily a wrong theoretical approach - SPKI is based on the premise that only keys are important, names are simply optional attributes attached to keys. But it is wrong in X.509 because X.509 certificates are identified by and stored under Distinguished Names, not public keys or SubjectKeyIdentifiers. Standards are about interworking in a multi-vendor environment; the testable requirements contained in standards are covenants between supplier and customer. My goal is for a CMI purchased from vendor X and operated by company A to work with applications purchased from vendors Y and Z and operated by companies B and C. I understand that that is not your primary goal, but I expect you to acknowledge that when as a result of non-conformance some applications work and others don't, it is NOT the fault of the conforming applications even when they are the ones that fail. And that when someone from company X proposes as a Standard a workaround for a problem created somewhere else in company X, the IETF is entitled to disregard the company-specific rationale for that workaround. Regards, Dave > From: "Trevor Freeman" > > Hi David, > I am afraid I don't see it necessary to eradicate every little > imperfection because it is there. To err is human, and people make > mistakes. People also have a wide list of requires which you may or may > not agree with, but it does not mean that it is less real to them. > So I don't see this as an error, simple a different point of view, and > we will obviously disagree on this point. > At the end of the day it is up to any product vendor to make the call as > to what is\is not in their product, regardless what is in the standard. > It is up to the market place to decide. History certainly tells us that > customers like robustness in a product. > If you can cite a specific issue, then we will obviously reconsider, but > I don't find punishing minor infractions of administrators a compelling > case. > Trevor From owner-ietf-pkix@imc.org Wed Jun 7 17:49:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21231 for ; Wed, 7 Jun 2000 17:49:26 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA17797; Wed, 7 Jun 2000 14:17:57 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jun 2000 14:17:53 -0700 Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17764 for ; Wed, 7 Jun 2000 14:17:51 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id RAA08224 for ; Wed, 7 Jun 2000 17:18:59 -0400 (EDT) Message-Id: <200006072118.RAA08217@roadblock.missi.ncsc.mil> Date: Wed, 7 Jun 2000 17:23:39 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Correct approach to certificate validation? To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: o906YrGPIOvV6INslRpnPw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Peter, Do you agree that: 1) path validation requirement "a" of X.509 requires name chaining? 2) if the subject of a certificate is a CA then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field in all certificates issued by the CA (RFC 2459 section 4.2.1.6) 3) A certificate may use a null DN iff the subject/issuer alternative name extension is flagged critical *and* for every name form used in the GeneralName type, there shall be a name registration system that ensures that any name used unambiguously identifies one entity to both certificate issuer and certificate users. (X.509 section 12.3.2.1) Dave From owner-ietf-pkix@imc.org Wed Jun 7 18:43:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21983 for ; Wed, 7 Jun 2000 18:43:26 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA19408; Wed, 7 Jun 2000 15:33:00 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jun 2000 15:32:50 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19378 for ; Wed, 7 Jun 2000 15:32:49 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA02274; Wed, 7 Jun 2000 18:40:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 7 Jun 2000 18:42:12 -0400 To: "Trevor Freeman" From: Stephen Kent Subject: RE: Correct approach to certificate validation? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Trevor, Two observations: - path construction (going up toward a root) is nominally based on the use of the issuer name to find the right CA certificate, with the AKI/SKI used to disambiguate among multiple valid CA certs. I recall that the list discussed the potential problems of using just the AKI to locate a CA certificate. I expressed concern then that the AKI didn't provide a means of locating a CA certificate when it was not local, i.e., one would need to have a database that was a flat file for all possible CA certificates to do the lookup. My concern was that we were creating a situation where people might build systems that had all the shortcomings of LAN e-mail systems, e.g., they worked well locally, but did not scale across the Internet. Of course, if one uses the AIA extension this problem might be ameliorated. So, my question is how do MS products locate a CA cert that is not available in a local cache or local LDAP directory, using just the AKI? - name constraints are critical to secure use of certs, so I do hope that you are correctly enforcing this extension, when it is present. Contrary to what Amir said, this is PKIX, not SPKI. We don't buy into the notion that keys are principals here :-). If one always uses name constraints in cross certs that link to other administrative domains, something that a local CA or can enforce unilaterally, then names are reasonably safe to employ for access control purposes. (Of course, one can't do this with TTP, but maybe that's another good reason for not using them when identification for access control is important.) But, if you're violating the standards to accommodate administrative sloppiness in managing CA names for chaining, then maybe you're assuming an environment where one can never rely on names for ACLs anyway. That's a scary environment. Steve From owner-ietf-pkix@imc.org Wed Jun 7 20:05:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23003 for ; Wed, 7 Jun 2000 20:05:46 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA20491; Wed, 7 Jun 2000 16:51:54 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jun 2000 16:51:46 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA20441 for ; Wed, 7 Jun 2000 16:51:45 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 07 Jun 2000 17:26:05 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 07 Jun 2000 17:26:01 -0600 From: "Bob Jueneman" To: , Cc: , Subject: RE: Correct approach to certificate validation? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA20442 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit At this point I am mightily confused, and would appreciate it if someone would clarify the issue, as I apparently tuned in late. Trevor says that they enforce name constraints, but that they don't support name chaining. I must be missing something important here -- how do the two differ, and/or how is one possible without the other? Are we talking about CA names only, end-entity names, or what? Some concrete examples pro and con would be very helpful. Regards, Bob >>> "Trevor Freeman" 06/06/00 08:42PM >>> We use AKI, but don't require it, as the field can be calculated on the fly so to speak. I am not linking the enforcement of name constrains with the enforcement of name chaining in any. We will enforce name constraints as this is a security issue, we don't enforce name chaining. We trust the CA because we have built a chain of certificate to a trusted root, with valid policy and name constraints. -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent: Tuesday, June 06, 2000 1:33 AM To: Trevor Freeman Cc: denis.bider@siol.net; ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? > Hi Denis, Now there are two Denis on the list. Don't be confused, the one above is not me ! :-) It seems that we are starting a very interesting threat. > We have found that enforcing name chaining in path construction, > causes more problems than it solves. We therefore have reverted to > using the name as just a hint, rather than a critical factor and > will as you have found, use a certificate signed with the right > key as a valid parent in that chain. To be more precise, do you mean that you are using the authority key identifier extension ? This extension provides a means of identifying the public key corresponding to the private key used to sign a certificate. The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate chain building. If this is what you use, this means that you use a field that must be present but does not need to be understood, since this extension is marked NON critical. If your implementation relies on that field, which options of that field are you using (since this is a sequence of three optional fields) ? If I misunderstood what you are using, please clarify. > This applies to intermediate > as well as self signed certificates. We have seen customer > scenarios where you need to deliberately build certificates which > don't chain on names so enforcing name chaining would cause > problems. It is true that enforcing name constraints within certificates themselves provides limitations and causes problems. Enforcing name chaining outside the certificates is much morer flexible ... and should be recognized as a valid additional check in the "son-of-RFC2459". > I know this is at odds with RFC2459, but as this behaviour does > not in our view cause a security problem, but does make the > overall process more robust, we have and will continue to opt for > the more robust solution. It seems to early at this stage to conclude that there are no security problems with such an approach (there are not enough information at this stage to make any conclusion). Just a remainder. The basic principle is the following: it is not because a CA certificate exists that it should be trusted. Denis > I have also posted previously on the list that mandating name > chaining, in addition to signatures and policy chaining is a bad > idea. > > Trevor > > -----Original Message----- > From: denis.bider@siol.net [mailto:denis.bider@siol.net] > Sent: Sunday, June 04, 2000 11:19 AM > To: ietf-pkix@imc.org > Subject: Correct approach to certificate validation? > > Now, based on my previous message, my question for this workgroup: > > Which of these approaches is correct? > - the approach of IE5 and Outlook, which, if an Authority Key > Identifier > extension is present, does not perform a comparison of the > issuer-DN in the > subject-cert to the subject-DN of the root-cert? > - or the approach of Netscape and IIS4, which, even if an > Authority Key > Identifier extension is present, DOES still perform a comparison > of the > subject-cert-issuer-DN to the root-cert-subject-DN? > > Regards, > > denis bider > > PS. I would like to thank Ace Swerling from Microsoft Consulting > Services > for the fact that he bothered to look into my problem, and > especially to > Peter Williams from Valicert who devoted much of his time to help > me solve > this issue. I appreciate your feedback very much. > > -----Original Message----- > From: denis bider [mailto:denis@denisbider.com] On Behalf Of > denis.bider@siol.net > Sent: Sunday, June 04, 2000 20:08 > To: 'ietf-pkix@imc.org' > Subject: Report - certificate validation in IE5, Outlook, > IIS4, Netscape > 4.72 > > Hello, > > a while ago I sent to this list an enquiry regarding Microsoft's > certificate > validation code in IIS4. I have now resolved the problem that was > the reason > for my enquiry. Since the solution to the problem produced some > interesting > insight into how certificate chains are handled in IE5 and Outlook > / IIS4 > and Netscape, and since the behavior in question should be covered > by > RFC2459, but does not seem to be, I am forwarding my findings to > you. > > I produced my own certificate generating utility, the intention of > which was > to generate certificates which could be used by IE5 to login into > an > SSL-protected web site running on IIS4. My problem was that, > although IE5 > claimed my root-cert/subject-cert certificate chain to be valid, > and > although Outlook properly signed and verified messages signed by > these > certificates, IIS4 rejected all attempts to use the subject > certificate for > SSL client authentication. Also, when the subject certificate was > imported > into Netscape, Netscape didn't even show it as an elligible choice > for SSL > client authentication. > > To sum it up, the problem was that there was a glitch in my code > that caused > the subject-DN in root-cert to be slightly different from the > issuer-DN in > the subject-cert. It seems that the certificate verification code > in IE5 and > Outlook2000 is somewhat easy-going, since both of these products > validated > the pair of certificates as valid (they performed cert-chain > validation > solely on the grounds of the key identifier in the Authority Key > Identifier > extension, they did not compare the sub-cert-issuerDN to the > root-cert-subjectDN). IIS4 and Netscape Communicator, on the other > hand, > seem to have a more stringent policy, since they both rejected > these > certificates. > > denis bider From owner-ietf-pkix@imc.org Wed Jun 7 20:26:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23113 for ; Wed, 7 Jun 2000 20:26:30 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA21231; Wed, 7 Jun 2000 17:10:25 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jun 2000 17:10:13 -0700 Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA21198 for ; Wed, 7 Jun 2000 17:10:11 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Jun 2000 17:08:07 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Wed, 7 Jun 2000 16:03:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD0D4.253A6B56" Subject: RE: Correct approach to certificate validation? Date: Wed, 7 Jun 2000 16:00:16 -0700 Message-ID: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/QiWeGxhvxdtQrRjaMEI8dySivbQARqf6g From: "Trevor Freeman" To: "David P. Kemp" Cc: X-OriginalArrivalTime: 07 Jun 2000 23:03:30.0381 (UTC) FILETIME=[98BCAFD0:01BFD0D4] Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD0D4.253A6B56 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, Interoperability is a primary goal, however that is often scarified by standards. It is very easy to produce a document with a set of do's and don'ts without any regard for the previous standard, the impact on the deployed products or how migration is achieved between the old and new standard. It is also unrealistic to think that all products deployed would conform to a single standard. Most products have a lifetime of years. The interoperability matrix is vast and getting worse every time a new version of a standard is released.=20 So to return to the original point, besides citing a 20 year old clause in a standard, and saying we should do it because its in the standard, and requiring administrators to have a faultless record, I have still not hear any reasoned, argument as to what is actually achieved by this behavior. No standard or clause in a standard has a divine right of existence. Trevor -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]=20 Sent: Wednesday, June 07, 2000 7:00 AM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, It isn't about punishing administrators for minor errors, it is about achieving an overall system with the goals of being both secure and non-intrusive to the end user. That may well mean that administrators have to do more thinking, planning, and quality control, but that is what they (we, the providers of a PKI for our branch of Govt) are paid to do. The specific case I'm referring to is Jim Schaad's assertion that an S/MIME-specific cert path attribute is needed because applications can't find CA certificates. I didn't realize until now that that was because in your environment subject certificates are not required to have a correct issuer name! It seemed obvious to me that the PKI is responsible for correctly binding names to keys. But you are saying that Issuer names don't really matter, they're just a hint to help applications search for a cert with a signing key that validates the subject cert signature. Well no wonder applications can't find CA certs in that environment! That isn't necessarily a wrong theoretical approach - SPKI is based on the premise that only keys are important, names are simply optional attributes attached to keys. But it is wrong in X.509 because X.509 certificates are identified by and stored under Distinguished Names, not public keys or SubjectKeyIdentifiers. Standards are about interworking in a multi-vendor environment; the testable requirements contained in standards are covenants between supplier and customer. My goal is for a CMI purchased from vendor X and operated by company A to work with applications purchased from vendors Y and Z and operated by companies B and C. I understand that that is not your primary goal, but I expect you to acknowledge that when as a result of non-conformance some applications work and others don't, it is NOT the fault of the conforming applications even when they are the ones that fail. And that when someone from company X proposes as a Standard a workaround for a problem created somewhere else in company X, the IETF is entitled to disregard the company-specific rationale for that workaround. Regards, Dave > From: "Trevor Freeman" >=20 > Hi David, > I am afraid I don't see it necessary to eradicate every little > imperfection because it is there. To err is human, and people make > mistakes. People also have a wide list of requires which you may or may > not agree with, but it does not mean that it is less real to them. > So I don't see this as an error, simple a different point of view, and > we will obviously disagree on this point. > At the end of the day it is up to any product vendor to make the call as > to what is\is not in their product, regardless what is in the standard. > It is up to the market place to decide. History certainly tells us that > customers like robustness in a product. > If you can cite a specific issue, then we will obviously reconsider, but > I don't find punishing minor infractions of administrators a compelling > case. > Trevor ------_=_NextPart_001_01BFD0D4.253A6B56 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

David,
Interoperability is a primary goal, however that is often scarified by = standards. It is very easy to produce a document with a set of do's and = don'ts  without any regard for the previous standard, the impact on = the deployed products or how migration is achieved between the old and = new standard. It is also unrealistic to think that all products deployed = would conform to a single standard. Most products have a lifetime of = years. The interoperability matrix is vast and getting worse every time = a new version of  a standard is released.
So to return to the original point, besides citing a 20 year old clause = in a standard, and saying we should do it because its in the standard, = and requiring administrators to have a faultless record, I have still = not hear any reasoned, argument as to what is actually achieved by this = behavior.
No standard or clause in a standard has a divine right of existence.
Trevor
 -----Original Message-----
From:   David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent:   Wednesday, June 07, 2000 7:00 AM
To:     ietf-pkix@imc.org
Subject:        RE: Correct approach = to certificate validation?

Trevor,

It isn't about punishing administrators for minor errors, it is
about achieving an overall system with the goals of being both
secure and non-intrusive to the end user.  That may well mean = that
administrators have to do more thinking, planning, and quality = control,
but that is what they (we, the providers of a PKI for our branch of
Govt) are paid to do.

The specific case I'm referring to is Jim Schaad's assertion that an
S/MIME-specific cert path attribute is needed because applications
can't find CA certificates.  I didn't realize until now that that = was
because in your environment subject certificates are not required to
have a correct issuer name!  It seemed obvious to me that the PKI = is
responsible for correctly binding names to keys.  But you are = saying
that Issuer names don't really matter, they're just a hint to help
applications search for a cert with a signing key that validates the
subject cert signature.  Well no wonder applications can't find = CA
certs in that environment!

That isn't necessarily a wrong theoretical approach - SPKI is based
on the premise that only keys are important, names are simply = optional
attributes attached to keys.  But it is wrong in X.509 because = X.509
certificates are identified by and stored under Distinguished Names,
not public keys or SubjectKeyIdentifiers.

Standards are about interworking in a multi-vendor environment; the
testable requirements contained in standards are covenants between
supplier and customer.  My goal is for a CMI purchased from = vendor
X and operated by company A to work with applications purchased from
vendors Y and Z and operated by companies B and C.  I = understand
that that is not your primary goal, but I expect you to acknowledge
that when as a result of non-conformance some applications work and
others don't, it is NOT the fault of the conforming applications = even
when they are the ones that fail.  And that when someone from = company
X proposes as a Standard a workaround for a problem created = somewhere
else in company X, the IETF is entitled to disregard the
company-specific rationale for that workaround.

Regards,
Dave



> From: "Trevor Freeman" = <trevorf@Exchange.Microsoft.com>
>
> Hi David,
> I am afraid I don't see it necessary to eradicate every little
> imperfection because it is there. To err is human, and people = make
> mistakes. People also have a wide list of requires which you may or = may
> not agree with, but it does not mean that it is less real to = them.
> So I don't see this as an error, simple a different point of view, = and
> we will obviously disagree on this point.
> At the end of the day it is up to any product vendor to make the = call as
> to what is\is not in their product, regardless what is in the = standard.
> It is up to the market place to decide. History certainly tells us = that
> customers like robustness in a product.
> If you can cite a specific issue, then we will obviously = reconsider, but
> I don't find punishing minor infractions of administrators a = compelling
> case.
> Trevor

------_=_NextPart_001_01BFD0D4.253A6B56-- From owner-ietf-pkix@imc.org Wed Jun 7 20:41:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23286 for ; Wed, 7 Jun 2000 20:41:07 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA21709; Wed, 7 Jun 2000 17:26:15 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 7 Jun 2000 17:26:12 -0700 Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA21677 for ; Wed, 7 Jun 2000 17:26:09 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Jun 2000 17:26:14 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Wed, 7 Jun 2000 16:54:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD0DB.C6A84F29" Subject: RE: Correct approach to certificate validation? Date: Wed, 7 Jun 2000 16:54:53 -0700 Message-ID: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/Q0mAlKVrnAUvRSoG9rL6mPiPzkgAAfgNA From: "Trevor Freeman" To: "Stephen Kent" Cc: X-OriginalArrivalTime: 07 Jun 2000 23:54:55.0100 (UTC) FILETIME=[C75F73C0:01BFD0DB] Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD0DB.C6A84F29 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Certificate discovery is not the issue here.=20 The question is that if you have a certificate who's signature integrity can be traced up to a trusted root, containing acceptable policy as defined by that root, and who's names lie within the allowed namespaces as defined by the name constraints in parent certificates to the certificate in question, what is the value in checking that the issuer-subject names chain? We have encountered such situations, by design, and by accident. In all cases, the cost\benefit analysis in our view is stacked in favor of not performing the name chaining check, and tolerating this situation. I agree that name constraints are important as the certificate is making those names available to the applications, so it is important that we can filter acceptable from not-acceptable names. We actually follow a methodology similar to one you mentioned in a previous thread which is to build all possible paths, then apply the name constraints to determine the quality of the path. For certificate discovery, we have a domain push mechanism as well as AIA. We are also adding a lookup by name, and a configurable URL search path i.e. a set of URLs to search (LDAP, HTTP, FTP) Trevor -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Wednesday, June 07, 2000 3:42 PM To: Trevor Freeman Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, Two observations: - path construction (going up toward a root) is nominally=20 based on the use of the issuer name to find the right CA certificate,=20 with the AKI/SKI used to disambiguate among multiple valid CA certs.=20 I recall that the list discussed the potential problems of using just=20 the AKI to locate a CA certificate. I expressed concern then that=20 the AKI didn't provide a means of locating a CA certificate when it=20 was not local, i.e., one would need to have a database that was a=20 flat file for all possible CA certificates to do the lookup. My=20 concern was that we were creating a situation where people might=20 build systems that had all the shortcomings of LAN e-mail systems,=20 e.g., they worked well locally, but did not scale across the=20 Internet. Of course, if one uses the AIA extension this problem might=20 be ameliorated. So, my question is how do MS products locate a CA=20 cert that is not available in a local cache or local LDAP directory,=20 using just the AKI? - name constraints are critical to secure use of certs, so I=20 do hope that you are correctly enforcing this extension, when it is=20 present. Contrary to what Amir said, this is PKIX, not SPKI. We=20 don't buy into the notion that keys are principals here :-). If one=20 always uses name constraints in cross certs that link to other=20 administrative domains, something that a local CA or can enforce=20 unilaterally, then names are reasonably safe to employ for access=20 control purposes. (Of course, one can't do this with TTP, but maybe=20 that's another good reason for not using them when identification for=20 access control is important.) But, if you're violating the standards=20 to accommodate administrative sloppiness in managing CA names for=20 chaining, then maybe you're assuming an environment where one can=20 never rely on names for ACLs anyway. That's a scary environment. Steve ------_=_NextPart_001_01BFD0DB.C6A84F29 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

Certificate discovery is not the issue here.

The question is that if you have a certificate who's signature integrity = can be traced up to a trusted root, containing acceptable policy as = defined by that root, and  who's names lie within the allowed = namespaces as defined by the name constraints in parent certificates to = the certificate in question, what is the value in checking that the = issuer-subject names chain?
We have encountered such situations, by design, and by accident. In all = cases, the cost\benefit analysis in our view is stacked in favor of not = performing the name chaining check, and tolerating this situation.

I agree that name constraints are important as the certificate is making = those names available to the applications, so it is important that we = can filter acceptable from not-acceptable names. We actually follow a = methodology similar to one you mentioned in a previous thread which is = to build all possible paths, then apply the name constraints to = determine the quality of the path.

For certificate discovery,  we have a domain push mechanism as well = as AIA. We are also adding a lookup by name, and a configurable URL = search path i.e. a set of URLs to search (LDAP, HTTP, FTP)

Trevor
 -----Original Message-----
From:   Stephen Kent [mailto:kent@bbn.com]
Sent:   Wednesday, June 07, 2000 3:42 PM
To:     Trevor Freeman
Cc:     ietf-pkix@imc.org
Subject:        RE: Correct approach = to certificate validation?

Trevor,

Two observations:

        - path construction (going up = toward a root) is nominally
based on the use of the issuer name to find the right CA = certificate,
with the AKI/SKI used to disambiguate among multiple valid CA certs.
I recall that the list discussed the potential problems of using = just
the AKI to locate a CA certificate.  I expressed concern then = that
the AKI didn't provide a means of locating a CA certificate when it
was not local, i.e., one would need to have a database that was a
flat file for all possible CA certificates to do the lookup.  = My
concern was that we were creating a situation where people might
build systems that had all the shortcomings of LAN e-mail systems,
e.g., they worked well locally, but did not scale across the
Internet. Of course, if one uses the AIA extension this problem = might
be ameliorated.  So, my question is how do MS products locate a = CA
cert that is not available in a local cache or local LDAP directory,
using just the AKI?

        - name constraints are = critical to secure use of certs, so I
do hope that you are correctly enforcing this extension, when it is
present.  Contrary to what  Amir said, this is PKIX, not = SPKI.  We
don't buy into the notion that keys are principals here :-).  If = one
always uses name constraints in cross certs that link to other
administrative domains, something that a local CA or  can = enforce
unilaterally, then names are reasonably safe to employ for access
control purposes. (Of course, one can't do this with TTP, but maybe
that's another good reason for not using them when identification = for
access control is important.)  But, if you're violating the = standards
to accommodate administrative sloppiness in managing CA names for
chaining, then maybe you're assuming an environment where one can
never rely on names for ACLs anyway. That's a scary environment.

Steve

------_=_NextPart_001_01BFD0DB.C6A84F29-- From owner-ietf-pkix@imc.org Thu Jun 8 11:48:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10100 for ; Thu, 8 Jun 2000 11:48:08 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA26331; Thu, 8 Jun 2000 08:30:05 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jun 2000 08:29:04 -0700 Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26247 for ; Thu, 8 Jun 2000 08:29:02 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id LAA15871 for ; Thu, 8 Jun 2000 11:30:08 -0400 (EDT) Message-Id: <200006081530.LAA15867@roadblock.missi.ncsc.mil> Date: Thu, 8 Jun 2000 11:34:52 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Correct approach to certificate validation? To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 066FyQiZQm4F+lXgEhbL+w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Trevor, > From: "Trevor Freeman" > > David, > Interoperability is a primary goal, however that is often scarified by > standards. It is very easy to produce a document with a set of do's and > don'ts without any regard for the previous standard, the impact on the > deployed products or how migration is achieved between the old and new > standard. It is also unrealistic to think that all products deployed > would conform to a single standard. Most products have a lifetime of > years. The interoperability matrix is vast and getting worse every time > a new version of a standard is released. > So to return to the original point, besides citing a 20 year old clause > in a standard, and saying we should do it because its in the standard, > and requiring administrators to have a faultless record, I have still > not hear any reasoned, argument as to what is actually achieved by this > behavior. > No standard or clause in a standard has a divine right of existence. > Trevor On the one hand, you seem to be decrying the ease of producing new specifications without regard for previous standards and deployed products. On the other, you seem to support discarding a 20 year old clause in a standard without regard for its impact on deployed products which have been built according to the standard. The "divine right" of any clause comes not from heaven or inheritance, but from the fact that it has been vetted internationally (in the ISO and the IETF) over a period of many years. Over that time (whether it's 12 or 20 years is immaterial), the requirement that certificates point to the correct issuer has not only survived, it has not to my knowledge been even mildly controversial. Now that there is discussion of the topic, the requirement will either survive or be discarded based on international consensus. There is no divine right, just the stability (inertia?) of a consensus-based standard-setting process. You may present a case that the requirement should be removed from X.509 and then from the PKIX profile of X.509. Or you may choose not to comply with X.509. But you can't both ignore the requirement and claim compliance. > Certificate discovery is not the issue here. > > For certificate discovery, we have a domain push mechanism as well as > AIA. We are also adding a lookup by name, and a configurable URL search > path i.e. a set of URLs to search (LDAP, HTTP, FTP) Certificate discovery *is* the issue. If you are adding a "lookup by name" function to your products, how will that work if certificates do not have correct issuer names? If I have someone's End Entity certificate, how do I find a path of CA certs that leads to my trust point (not necessarily the certificate subject's trust point), in the multi-vendor, multi-administrative-domain environment of the Internet. Products may support many certificate discovery mechanisms, both standards-based and differentiating. But there needs to be at least one "Internet" interoperability mode which all products support. That mode is defined by PKIX: the certificate profile and the LDAP schema. One "Internet mode" mechanism which follows the current PKIX specifications is for organizations to place public information, including CA and EE certificates, in border directories, and to link the border directories together using directory-to-directory chaining, LDAP referrals, or both. If you propose to eliminate the X.509 requirement for correct issuer names, you will need to address the impact on current applications built to the current standards, as well as the feasability of future applications built to an amended standard. Dave P.S. I don't understand why you keep referring to "punishing administrators" and "requiring administrators to have a flawless record" and "eliminating imperfection". A CA workstation has its own signing key and certificate. If the workstation cannot correctly place its own name in the issuer field of every certificate it signs, that is a product flaw. This X.509 requirement does not hinge upon human perfectability. From owner-ietf-pkix@imc.org Thu Jun 8 12:19:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10882 for ; Thu, 8 Jun 2000 12:19:20 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA28712; Thu, 8 Jun 2000 09:08:44 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jun 2000 09:08:40 -0700 Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28652 for ; Thu, 8 Jun 2000 09:08:39 -0700 (PDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00DRVF4T39@mta5.rcsntx.swbell.net> for ietf-pkix@imc.org; Thu, 8 Jun 2000 11:06:01 -0500 (CDT) Date: Thu, 08 Jun 2000 11:06:01 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: ietf-pkix@imc.org Message-id: <0FVU00DUOFDZ39@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson From owner-ietf-pkix@imc.org Thu Jun 8 15:28:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14979 for ; Thu, 8 Jun 2000 15:28:18 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA05048; Thu, 8 Jun 2000 12:17:23 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jun 2000 12:17:00 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05017 for ; Thu, 8 Jun 2000 12:16:59 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA13589; Thu, 8 Jun 2000 15:25:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 8 Jun 2000 15:20:47 -0400 To: "Trevor Freeman" From: Stephen Kent Subject: RE: Correct approach to certificate validation? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Trevor, >Certificate discovery is not the issue here. I know that the focus of the discussion has been matching up subject and issuer names when validating a cert path. However, since cert path discovery logically precedes validation, and since the nominal model for discovery is based on looking for a CA cert that contains a subject name that was the issuer name on the "lower" level cert, I think it appropriate to ask the discovery question. >The question is that if you have a certificate who's signature >integrity can be traced up to a trusted root, containing acceptable >policy as defined by that root, and who's names lie within the >allowed namespaces as defined by the name constraints in parent >certificates to the certificate in question, what is the value in >checking that the issuer-subject names chain? >We have encountered such situations, by design, and by accident. In >all cases, the cost\benefit analysis in our view is stacked in favor >of not performing the name chaining check, and tolerating this >situation. Could you provide some examples of the "by design" situations you have encountered? >I agree that name constraints are important as the certificate is >making those names available to the applications, so it is important >that we can filter acceptable from not-acceptable names. We actually >follow a methodology similar to one you mentioned in a previous >thread which is to build all possible paths, then apply the name >constraints to determine the quality of the path. I don't recall suggesting the approach you mention here. I would guess that path discovery performed using subject/issuer name matching and AIK/SIK discrimination would rarely yield multiple paths. But, if it did, then I agree that application of the name constraints extension as part of path validation would discard paths that violated the constraints. >For certificate discovery, we have a domain push mechanism as well >as AIA. We are also adding a lookup by name, and a configurable URL >search path i.e. a set of URLs to search (LDAP, HTTP, FTP) The domain push mechanism sounds local, perhaps MS specific? AIA would be definitive. Does one look at the issuer name to select a subset of the search search paths you allude to, or do you just try to do lookups via ll of them? Steve From owner-ietf-pkix@imc.org Thu Jun 8 17:57:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17749 for ; Thu, 8 Jun 2000 17:57:01 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA07309; Thu, 8 Jun 2000 14:45:09 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jun 2000 14:44:56 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07273 for ; Thu, 8 Jun 2000 14:44:55 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FVU00A01VGTDP@ext-mail.valicert.com> for ietf-pkix@imc.org; Thu, 08 Jun 2000 14:53:17 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FVU00A5JVGTA0@ext-mail.valicert.com>; Thu, 08 Jun 2000 14:53:17 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 08 Jun 2000 14:47:30 -0700 Content-return: allowed Date: Thu, 08 Jun 2000 14:47:27 -0700 From: Peter Williams Subject: RE: Correct approach to certificate validation? To: "'David P. Kemp'" Cc: ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE235E2D9@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Dave, I agree that (1), (2) and (3) are true assertions. Perhaps you could be as clear for me...for the PKIX profile of X.509: Do you realize, and agree, that the way NIST/NSA designers deliberately constructed RFC 2459's name matching process (during path validation of an intermediate or EE certificate) is such that implementations of the X.509 path processing algorithm produce a different validity result to the PKIX algorithm. To keep your schema, I would suggest that it is not enough to ask Q1. In fact, one can be easily deceived by considering only Q1. You must ask the PKIX-specific version of Q1, and then consider the ramifications on testable X.509 conformance. (Q3 seems irrelevant.) Q1 refers to the rule: "10.5 Certificate processing ... The following checks are applied to a certificate: a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked." PKIX Q1 refers to a particular definition of what chaining names "correctly" is. And the 2459 definition of name matching in *PKIX-conforming* systems is not compatible with systems tested/certified to be conforming to the X509 standard, by specific intent of the NIST/NSA authors, evidently. As Trevor said, its all a big mess that requires practical treatment, not religious dogma, in today's products that are "based on RFC 2459". The list will no doubt diverge here between the paper-architects and product builders. Why we cannot just implement X.509 name matching defeats me. Peter. -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Wednesday, June 07, 2000 2:24 PM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Peter, Do you agree that: 1) path validation requirement "a" of X.509 requires name chaining? 2) if the subject of a certificate is a CA then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field in all certificates issued by the CA (RFC 2459 section 4.2.1.6) 3) A certificate may use a null DN iff the subject/issuer alternative name extension is flagged critical *and* for every name form used in the GeneralName type, there shall be a name registration system that ensures that any name used unambiguously identifies one entity to both certificate issuer and certificate users. (X.509 section 12.3.2.1) Dave From owner-ietf-pkix@imc.org Thu Jun 8 21:20:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20077 for ; Thu, 8 Jun 2000 21:20:00 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA13539; Thu, 8 Jun 2000 18:02:37 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jun 2000 18:02:28 -0700 Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA13463 for ; Thu, 8 Jun 2000 18:02:27 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 08 Jun 2000 17:29:10 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Thu, 8 Jun 2000 16:02:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD19A.5E79C38C" Subject: RE: Correct approach to certificate validation? Date: Thu, 8 Jun 2000 15:39:12 -0700 Message-ID: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/RYJMCXGniSOc7SzajKKMeEOGrKwAOKjCA From: "Trevor Freeman" To: "David P. Kemp" Cc: X-OriginalArrivalTime: 08 Jun 2000 23:02:26.0702 (UTC) FILETIME=[9D31CAE0:01BFD19D] Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD19A.5E79C38C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Life is complicated, but this is not so bad - Isaac Newton's rules where around a lot longer before they were found to be wrong. I am still waiting to here further justification (beyond the old ground of "its in the spec"). and so far you are confirming my suspicions that there are none. -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]=20 Sent: Thursday, June 08, 2000 8:35 AM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, > From: "Trevor Freeman" >=20 > David, > Interoperability is a primary goal, however that is often scarified by > standards. It is very easy to produce a document with a set of do's and > don'ts without any regard for the previous standard, the impact on the > deployed products or how migration is achieved between the old and new > standard. It is also unrealistic to think that all products deployed > would conform to a single standard. Most products have a lifetime of > years. The interoperability matrix is vast and getting worse every time > a new version of a standard is released. > So to return to the original point, besides citing a 20 year old clause > in a standard, and saying we should do it because its in the standard, > and requiring administrators to have a faultless record, I have still > not hear any reasoned, argument as to what is actually achieved by this > behavior. > No standard or clause in a standard has a divine right of existence. > Trevor On the one hand, you seem to be decrying the ease of producing new specifications without regard for previous standards and deployed products. On the other, you seem to support discarding a 20 year old clause in a standard without regard for its impact on deployed products which have been built according to the standard. The "divine right" of any clause comes not from heaven or inheritance, but from the fact that it has been vetted internationally (in the ISO and the IETF) over a period of many years. Over that time (whether it's 12 or 20 years is immaterial), the requirement that certificates point to the correct issuer has not only survived, it has not to my knowledge been even mildly controversial. Now that there is discussion of the topic, the requirement will either survive or be discarded based on international consensus. There is no divine right, just the stability (inertia?) of a consensus-based standard-setting process. You may present a case that the requirement should be removed from X.509 and then from the PKIX profile of X.509. Or you may choose not to comply with X.509. But you can't both ignore the requirement and claim compliance. > Certificate discovery is not the issue here. > > For certificate discovery, we have a domain push mechanism as well as > AIA. We are also adding a lookup by name, and a configurable URL search > path i.e. a set of URLs to search (LDAP, HTTP, FTP) Certificate discovery *is* the issue. If you are adding a "lookup by name" function to your products, how will that work if certificates do not have correct issuer names? If I have someone's End Entity certificate, how do I find a path of CA certs that leads to my trust point (not necessarily the certificate subject's trust point), in the multi-vendor, multi-administrative-domain environment of the Internet. Products may support many certificate discovery mechanisms, both standards-based and differentiating. But there needs to be at least one "Internet" interoperability mode which all products support. That mode is defined by PKIX: the certificate profile and the LDAP schema. One "Internet mode" mechanism which follows the current PKIX specifications is for organizations to place public information, including CA and EE certificates, in border directories, and to link the border directories together using directory-to-directory chaining, LDAP referrals, or both. If you propose to eliminate the X.509 requirement for correct issuer names, you will need to address the impact on current applications built to the current standards, as well as the feasability of future applications built to an amended standard. Dave P.S. I don't understand why you keep referring to "punishing administrators" and "requiring administrators to have a flawless record" and "eliminating imperfection". A CA workstation has its own signing key and certificate. If the workstation cannot correctly place its own name in the issuer field of every certificate it signs, that is a product flaw. This X.509 requirement does not hinge upon human perfectability. ------_=_NextPart_001_01BFD19A.5E79C38C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

Life is complicated, but this is not so bad - Isaac = Newton's rules  where around a lot longer before they were found to = be wrong.
I am still waiting to here further justification (beyond the old ground = of "its in the spec"). and so far you are confirming my = suspicions that there are none.

 -----Original Message-----
From:   David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent:   Thursday, June 08, 2000 8:35 AM
To:     ietf-pkix@imc.org
Subject:        RE: Correct approach = to certificate validation?

Trevor,

> From: "Trevor Freeman" = <trevorf@Exchange.Microsoft.com>
>
> David,
> Interoperability is a primary goal, however that is often scarified = by
> standards. It is very easy to produce a document with a set of do's = and
> don'ts  without any regard for the previous standard, the = impact on the
> deployed products or how migration is achieved between the old and = new
> standard. It is also unrealistic to think that all products = deployed
> would conform to a single standard. Most products have a lifetime = of
> years. The interoperability matrix is vast and getting worse every = time
> a new version of  a standard is released.
> So to return to the original point, besides citing a 20 year old = clause
> in a standard, and saying we should do it because its in the = standard,
> and requiring administrators to have a faultless record, I have = still
> not hear any reasoned, argument as to what is actually achieved by = this
> behavior.
> No standard or clause in a standard has a divine right of = existence.
> Trevor

On the one hand, you seem to be decrying the ease of producing new
specifications without regard for previous standards and deployed
products.

On the other, you seem to support discarding a 20 year old clause
in a standard without regard for its impact on deployed products = which
have been built according to the standard.

The "divine right" of any clause comes not from heaven or = inheritance,
but from the fact that it has been vetted internationally (in the = ISO
and the IETF) over a period of many years.  Over that time (whether = it's
12 or 20 years is immaterial), the requirement that certificates = point
to the correct issuer has not only survived, it has not to my = knowledge
been even mildly controversial.   Now that there is discussion = of
the topic, the requirement will either survive or be discarded based
on international consensus.   There is no divine right, just = the
stability (inertia?) of a consensus-based standard-setting
process.

You may present a case that the requirement should be removed from = X.509
and then from the PKIX profile of X.509.
Or you may choose not to comply with X.509.

But you can't both ignore the requirement and claim compliance.




> Certificate discovery is not the issue here.
>
> For certificate discovery,  we have a domain push mechanism as = well as
> AIA. We are also adding a lookup by name, and a configurable URL = search
> path i.e. a set of URLs to search (LDAP, HTTP, FTP)

Certificate discovery *is* the issue.

If you are adding a "lookup by name" function to your = products,
how will that work if certificates do not have correct issuer
names?  If I have someone's End Entity certificate, how do I find = a
path of CA certs that leads to my trust point (not necessarily the
certificate subject's trust point), in the multi-vendor,
multi-administrative-domain environment of the Internet.

Products may support many certificate discovery mechanisms, both
standards-based and differentiating.  But there needs to be at
least one "Internet" interoperability mode which all = products
support.  That mode is defined by PKIX: the certificate profile
and the LDAP schema.

One "Internet mode" mechanism which follows the current = PKIX
specifications is for organizations to place public information,
including CA and EE certificates, in border directories, and to link
the border directories together using directory-to-directory = chaining,
LDAP referrals, or both.  If you propose to eliminate the X.509
requirement for correct issuer names, you will need to address the
impact on current applications built to the current standards,
as well as the feasability of future applications built to an
amended standard.

Dave


P.S.  I don't understand why you keep referring to = "punishing
administrators" and "requiring administrators to have a = flawless
record" and "eliminating imperfection".  A CA = workstation has its own
signing key and certificate.  If the workstation cannot correctly = place
its own name in the issuer field of every certificate it signs, that = is
a product flaw.  This X.509 requirement does not hinge upon = human
perfectability.

------_=_NextPart_001_01BFD19A.5E79C38C-- From owner-ietf-pkix@imc.org Thu Jun 8 21:38:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20326 for ; Thu, 8 Jun 2000 21:38:39 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA18951; Thu, 8 Jun 2000 18:27:06 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jun 2000 18:27:04 -0700 Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA18908 for ; Thu, 8 Jun 2000 18:27:03 -0700 (PDT) Received: from jimsch1t (ip166.du1.bel.nwlink.com [209.20.136.166]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id SAA18616; Thu, 8 Jun 2000 18:35:19 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'David P. Kemp'" , Subject: RE: Correct approach to certificate validation? Date: Thu, 8 Jun 2000 18:35:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200006071355.JAA25280@roadblock.missi.ncsc.mil> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit David, My draft has nothing to do with the fact that the name chaining may be incorrect but applies even in the cases where name chaining is present and correct. There are various cases where not going strictly on name chaining can be benifitual. For example, if a company changes names the CA certificate can be updated without having to re-issue all subordiante certificates at the same time. (This may happen due to merges, splits, name changes or court ordered actions.) jim -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Wednesday, June 07, 2000 7:00 AM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, It isn't about punishing administrators for minor errors, it is about achieving an overall system with the goals of being both secure and non-intrusive to the end user. That may well mean that administrators have to do more thinking, planning, and quality control, but that is what they (we, the providers of a PKI for our branch of Govt) are paid to do. The specific case I'm referring to is Jim Schaad's assertion that an S/MIME-specific cert path attribute is needed because applications can't find CA certificates. I didn't realize until now that that was because in your environment subject certificates are not required to have a correct issuer name! It seemed obvious to me that the PKI is responsible for correctly binding names to keys. But you are saying that Issuer names don't really matter, they're just a hint to help applications search for a cert with a signing key that validates the subject cert signature. Well no wonder applications can't find CA certs in that environment! That isn't necessarily a wrong theoretical approach - SPKI is based on the premise that only keys are important, names are simply optional attributes attached to keys. But it is wrong in X.509 because X.509 certificates are identified by and stored under Distinguished Names, not public keys or SubjectKeyIdentifiers. Standards are about interworking in a multi-vendor environment; the testable requirements contained in standards are covenants between supplier and customer. My goal is for a CMI purchased from vendor X and operated by company A to work with applications purchased from vendors Y and Z and operated by companies B and C. I understand that that is not your primary goal, but I expect you to acknowledge that when as a result of non-conformance some applications work and others don't, it is NOT the fault of the conforming applications even when they are the ones that fail. And that when someone from company X proposes as a Standard a workaround for a problem created somewhere else in company X, the IETF is entitled to disregard the company-specific rationale for that workaround. Regards, Dave > From: "Trevor Freeman" > > Hi David, > I am afraid I don't see it necessary to eradicate every little > imperfection because it is there. To err is human, and people make > mistakes. People also have a wide list of requires which you may or may > not agree with, but it does not mean that it is less real to them. > So I don't see this as an error, simple a different point of view, and > we will obviously disagree on this point. > At the end of the day it is up to any product vendor to make the call as > to what is\is not in their product, regardless what is in the standard. > It is up to the market place to decide. History certainly tells us that > customers like robustness in a product. > If you can cite a specific issue, then we will obviously reconsider, but > I don't find punishing minor infractions of administrators a compelling > case. > Trevor From owner-ietf-pkix@imc.org Thu Jun 8 22:39:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22688 for ; Thu, 8 Jun 2000 22:39:39 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA27335; Thu, 8 Jun 2000 19:25:51 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jun 2000 19:25:41 -0700 Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA27271 for ; Thu, 8 Jun 2000 19:25:40 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000609023401.QKNA23916.mail.rdc1.md.home.com@home.com>; Thu, 8 Jun 2000 19:34:01 -0700 Message-ID: <39405703.916283C1@home.com> Date: Thu, 08 Jun 2000 22:31:31 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Trevor Freeman CC: "David P. Kemp" , ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Trevor, Here's the justification: Suppose that a CA system (by, e.g., Netscape, Entrust, VeriSign, whomever) has been built to conform to existing/understood X.509/RFC2459 name chaining rules. Suppose that such a system has been deployed for, oh, say, a large Government department, or a large corporation, or... Now, suppose that a CA from some other corporation that follows the rules you suggest - i.e., name chaining doesn't matter. We want to integrate that CA into the existing PKI. Now, for whatever reason - human frailty, whatever - that new CA is used to create a certificate whose distinguish name is "C=AW, O=Government, OU= Computers, CN= CA1", and then that CA creates user certs where the issuer name is "C=AW, O=Government, OU=Computer, CN=CA1". Note that these names are not equivalent.* Suppose that all other information - AKI, AIA, etc. - is set up properly. Now, whenever a cert path is validated using the new CA, it will be validated, because the fact that the end entity cert's issuer name and the CA cert's subject name aren't the same doesn't matter. However, whenever that same cert path is validated by a node in the existing PKI, validation will fail, because of the name chaining failure. The notion of obtaining different results by different points in the system is disconcerting, to say the least. That's the reason: by building your system this way, you cause the multi-vendor interoperable PKI to fail. If you were building your system to not interoperate with any other existing products, then I think we could probably agree that you were right; there is no real reason that names have to chain. However, lots of people do want your system to interoperate with other products. I'm fairly confident that Dave wants them to. I know that in some of the cases I'm dealing with now, I need them to. And they don't. Al Arsenault Chief Security Architect Diversinet Corp. *And yes, I have seen cases where name chaining failed - and thus certificate validation failed when it shouldn't have - because of a misplaced comma in a CN field. I've also seen it fail because of an extra space in an OU field, and several other situations. > Trevor Freeman wrote: > > Life is complicated, but this is not so bad - Isaac Newton's rules > where around a lot longer before they were found to be wrong. > I am still waiting to here further justification (beyond the old > ground of "its in the spec"). and so far you are confirming my > suspicions that there are none. > > -----Original Message----- > From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > Sent: Thursday, June 08, 2000 8:35 AM > To: ietf-pkix@imc.org > Subject: RE: Correct approach to certificate validation? > > Trevor, > > > From: "Trevor Freeman" > > > > David, > > Interoperability is a primary goal, however that is often scarified > by > > standards. It is very easy to produce a document with a set of do's > and > > don'ts without any regard for the previous standard, the impact on > the > > deployed products or how migration is achieved between the old and > new > > standard. It is also unrealistic to think that all products deployed > > would conform to a single standard. Most products have a lifetime of > > years. The interoperability matrix is vast and getting worse every > time > > a new version of a standard is released. > > So to return to the original point, besides citing a 20 year old > clause > > in a standard, and saying we should do it because its in the > standard, > > and requiring administrators to have a faultless record, I have > still > > not hear any reasoned, argument as to what is actually achieved by > this > > behavior. > > No standard or clause in a standard has a divine right of existence. > > Trevor > > On the one hand, you seem to be decrying the ease of producing new > specifications without regard for previous standards and deployed > products. > > On the other, you seem to support discarding a 20 year old clause > in a standard without regard for its impact on deployed products which > have been built according to the standard. > > The "divine right" of any clause comes not from heaven or inheritance, > but from the fact that it has been vetted internationally (in the ISO > and the IETF) over a period of many years. Over that time (whether > it's > 12 or 20 years is immaterial), the requirement that certificates point > to the correct issuer has not only survived, it has not to my > knowledge > been even mildly controversial. Now that there is discussion of > the topic, the requirement will either survive or be discarded based > on international consensus. There is no divine right, just the > stability (inertia?) of a consensus-based standard-setting > process. > > You may present a case that the requirement should be removed from > X.509 > and then from the PKIX profile of X.509. > Or you may choose not to comply with X.509. > > But you can't both ignore the requirement and claim compliance. > > > Certificate discovery is not the issue here. > > > > For certificate discovery, we have a domain push mechanism as well > as > > AIA. We are also adding a lookup by name, and a configurable URL > search > > path i.e. a set of URLs to search (LDAP, HTTP, FTP) > > Certificate discovery *is* the issue. > > If you are adding a "lookup by name" function to your products, > how will that work if certificates do not have correct issuer > names? If I have someone's End Entity certificate, how do I find a > path of CA certs that leads to my trust point (not necessarily the > certificate subject's trust point), in the multi-vendor, > multi-administrative-domain environment of the Internet. > > Products may support many certificate discovery mechanisms, both > standards-based and differentiating. But there needs to be at > least one "Internet" interoperability mode which all products > support. That mode is defined by PKIX: the certificate profile > and the LDAP schema. > > One "Internet mode" mechanism which follows the current PKIX > specifications is for organizations to place public information, > including CA and EE certificates, in border directories, and to link > the border directories together using directory-to-directory chaining, > LDAP referrals, or both. If you propose to eliminate the X.509 > requirement for correct issuer names, you will need to address the > impact on current applications built to the current standards, > as well as the feasability of future applications built to an > amended standard. > > Dave > > P.S. I don't understand why you keep referring to "punishing > administrators" and "requiring administrators to have a flawless > record" and "eliminating imperfection". A CA workstation has its own > signing key and certificate. If the workstation cannot correctly > place > its own name in the issuer field of every certificate it signs, that > is > a product flaw. This X.509 requirement does not hinge upon human > perfectability. From owner-ietf-pkix@imc.org Thu Jun 8 23:09:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22886 for ; Thu, 8 Jun 2000 23:09:56 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA01610; Thu, 8 Jun 2000 19:55:21 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jun 2000 19:55:19 -0700 Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA01570 for ; Thu, 8 Jun 2000 19:55:17 -0700 (PDT) Received: (qmail 18285 invoked from network); 9 Jun 2000 03:03:37 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.communitech.net with SMTP; 9 Jun 2000 03:03:37 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Thu, 08 Jun 2000 22:03:34 -0500 Message-ID: <39405E88.13BADEF8@nma.com> Date: Thu, 08 Jun 2000 20:03:36 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit List: Why should we continue to confuse name validation with certificate validation? Name chaining should be optional IMO, not expected behavior. 'Be liberal in what you expect' can be applied here without A N Y decrease in cryptographic authentication security. Cheers, Ed Gerck From owner-ietf-pkix@imc.org Thu Jun 8 23:10:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22907 for ; Thu, 8 Jun 2000 23:10:52 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA02817; Thu, 8 Jun 2000 20:01:22 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jun 2000 20:01:19 -0700 Received: from mail-fwd.verio-web.com ([161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA02778 for ; Thu, 8 Jun 2000 20:01:18 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 03476090; Thu, 8 Jun 2000 23:09:42 -0400 (EDT) Message-ID: <39406032.84762F55@caveosystems.com> Date: Thu, 08 Jun 2000 23:10:42 -0400 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Al Arsenault CC: Trevor Freeman , "David P. Kemp" , ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Al, You're saying that the current deployed base of CA's ensures that the issuer DN of certs they issue is exactly the same as the subject DN of its own signing cert? If my understanding is correct, not only do I strongly concur, but I don't know of any product that works otherwise, in the course of normal operation/default config. Does anyone know of a product that doesn't? Even if there is one, it doesn't matter. And if the standard is 20 years old, it doesn't matter (heck, TCP's older than that). Generally speaking, "that's what everyone else does" is the kind of argument that, in the IETF, generally trumps anything else. Trevor, I thought you've been around long enough to know this. /r$ From owner-ietf-pkix@imc.org Thu Jun 8 23:54:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23590 for ; Thu, 8 Jun 2000 23:54:56 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA08862; Thu, 8 Jun 2000 20:45:42 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 8 Jun 2000 20:45:35 -0700 Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08820 for ; Thu, 8 Jun 2000 20:45:33 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Jun 2000 13:56:40 +1000 Message-ID: From: "Grant, Alistair" To: Trevor Freeman Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Date: Fri, 9 Jun 2000 13:57:51 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi Trevor, Trevor Freeman wrote: > To err is human, and people make mistakes. Which is one of the reasons why a certificate may be revoked and re-issued. To add to the list of arguments for following the standard: Inconsistent behaviour amongst various components of a system simply makes tracking down a problem more difficult, as I expect Denis Bider can attest to. I doubt that this change has made the overall system more robust. It seems unlikely that all implementations are going to operate in the same manner. Based on Denis' experience, just taking Microsoft's various systems results in inconsistent behaviour. Cheers, Alistair Grant Project Manager - Development Computer Associates, OpenDirectory Lab Mooroolbark, Victoria, Australia Phone: +61 3 9727 8912 Mobile: +61 408 565 080 Fax: +61 3 9727 3491 E-Mail: Alistair.Grant@ca.com From owner-ietf-pkix@imc.org Fri Jun 9 05:33:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07979 for ; Fri, 9 Jun 2000 05:33:43 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA29403; Fri, 9 Jun 2000 02:20:49 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 02:20:30 -0700 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29361 for ; Fri, 9 Jun 2000 02:20:27 -0700 (PDT) Received: by ns.celocom.se; id LAA03583; Fri, 9 Jun 2000 11:28:46 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma003529; Fri, 9 Jun 00 11:28:30 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id LAA20395 for ; Fri, 9 Jun 2000 11:31:03 +0200 Message-ID: <3940B8BB.8ACAE8AC@celocom.com> Date: Fri, 09 Jun 2000 11:28:27 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms828A2011C597B02E3D4CF8A6" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a cryptographically signed message in MIME format. --------------ms828A2011C597B02E3D4CF8A6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ed Gerck wrote: > Why should we continue to confuse name validation with > certificate validation? Name chaining should be optional IMO, > not expected behavior. 'Be liberal in what you expect' can be > applied here without A N Y decrease in cryptographic > authentication security. My personal opinion, and humble one at that, is that the issue is of greater importance than "simply" one of cryptographic security. The principals of X.509, as has been previously stated in this thread, are in the naming, and not in the cryptographic keys themselves. The value of authentication, again IMHO, is in the degree of trust which the Relying Party can hold as to the identity of the certificate subject presented and not in the relative merits of the length and/or algorithm employed for the cryptographic key. My two crowns worth, anyway. Cheers! //oscar --------------ms828A2011C597B02E3D4CF8A6 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjA5MDkyODI5 WjAjBgkqhkiG9w0BCQQxFgQUC9AvFfffQuA0UniiUEHZ4mYQveUwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB9hNisgOy8iF1UzMuCfpZzhojE2Ooh Mbu6htNYloq8c278ogmJUMAep7/vnSBGBxoD1iEqrqgInaaubw9ux7WlMi4HeUW03FWsDWDF meKziGn7u2SD137lPMADsoQIVBjm67JU5TN+b0UMFTw1Xe5UCPpMGZCXh6t4VLvaNNTSyA== --------------ms828A2011C597B02E3D4CF8A6-- From owner-ietf-pkix@imc.org Fri Jun 9 08:12:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09602 for ; Fri, 9 Jun 2000 08:12:43 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA10406; Fri, 9 Jun 2000 05:02:59 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 05:02:52 -0700 Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10369 for ; Fri, 9 Jun 2000 05:02:45 -0700 (PDT) Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id NAA21814; Fri, 9 Jun 2000 13:57:23 +0200 From: Sender: "denis bider" To: "'Grant, Alistair'" , "'Trevor Freeman'" Cc: Subject: RE: Correct approach to certificate validation? Date: Fri, 9 Jun 2000 14:05:08 +0200 Message-ID: <000501bfd20a$f5474da0$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > Inconsistent behaviour amongst various components of a system simply > makes tracking down a problem more difficult, as I expect Denis Bider > can attest to. Grant is correct on this issue. As a user/developer, I would have preferred IE5 and Outlook to use the same validation scheme as is used in other products out there. (Simple example: if IE5/Outlook2000 did use the same validation technique as the rest of the world, I would not have been misled into thinking that the problem is at the IIS side, and, hence, would not have spent tens of hours trying to find the problem where it did not exist. Of course, it was my mistake that caused certificate names not to chain, and nor IE5 nor IIS can be blamed for any of this. Essentially, the fault was mine entirely. But still, where IE's behavior could be helpful, it was misleading. Personally, I would have preferred it to be helpful.) Regards, denis From owner-ietf-pkix@imc.org Fri Jun 9 08:19:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09777 for ; Fri, 9 Jun 2000 08:19:56 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA10564; Fri, 9 Jun 2000 05:04:21 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 05:04:19 -0700 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10534 for ; Fri, 9 Jun 2000 05:04:18 -0700 (PDT) Received: by ns.celocom.se; id OAA11579; Fri, 9 Jun 2000 14:12:47 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma011577; Fri, 9 Jun 00 14:12:43 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id OAA24569 for ; Fri, 9 Jun 2000 14:15:18 +0200 Message-ID: <3940DF3A.7D592D88@celocom.com> Date: Fri, 09 Jun 2000 14:12:42 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBE97078F8A0220D47D35FEB4" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a cryptographically signed message in MIME format. --------------msBE97078F8A0220D47D35FEB4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Ed Gerck wrote: > > 'Be liberal in what you expect' can be > > applied here without A N Y decrease in cryptographic > > authentication security. I wasn't particularly lucid in my earlier response, so feel I should probably try again. A few nights' worth of heavy drinking works all but wonders on one's faculties for reason. Being liberal should certainly remain an option, since potential customers will no doubt continue to insist that one's applications be interoperable with broken, or non-conformant if you prefer that term, Public Key Infrastructures and their components. I feel that name constraints are a valuable tool for delegating trust to external parties. Rather than my current behavior, which is to trust whomever AOL tells me to trust, I would be much more comfortable using a certificate issued by a local administrator here at Celo. Such a certificate would, hopefully, hold more worth to the recipient than merely the ability to send me encrypted e-mail, by virtue of being issued by my employer, who should be able to vouch for my identity with a reasonably high degree of certainty. Rather than expecting all recipients to blindly trust the Celo-local issuer for any and all extents, which I personally consider rather rude, an rfc822Name constraint could be included in order to inform the relying party that this issuer intends to issue certificates to Celo employees exclusively, thus requiring far less blind faith from the relying party. To try to summarize: Constraining one's intended certification is essential, since it will allow for a much finer granularity in the delegation of trust than the current model with it's childish boolean trusted/not trusted mechanism. //oscar --------------msBE97078F8A0220D47D35FEB4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjA5MTIxMjQz WjAjBgkqhkiG9w0BCQQxFgQUAOTCTNzPzvdocJlvcGPW6LtqhdYwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBD0RG19HJib1z38jtVk4OJClCpnpDZ YJ3F2hTgUwl/VWkH4EOhByRFASATzd+nOvjCDMjDbhCRHUmvDirfUyphG5r8LLgLw2QSp9Af RqvPx95bJpyNXs/2fhy6c7CR11Esk+lxKMf/y4YKKinM/UUNLaMHZAYjyLl5mlVC5jrK/Q== --------------msBE97078F8A0220D47D35FEB4-- From owner-ietf-pkix@imc.org Fri Jun 9 09:39:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11384 for ; Fri, 9 Jun 2000 09:39:50 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA14340; Fri, 9 Jun 2000 06:26:16 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 06:26:08 -0700 Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14302 for ; Fri, 9 Jun 2000 06:26:07 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA13009 for ; Fri, 9 Jun 2000 09:27:12 -0400 (EDT) Message-Id: <200006091327.JAA13004@roadblock.missi.ncsc.mil> Date: Fri, 9 Jun 2000 09:32:00 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Correct approach to certificate validation? To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: v/aXcAcK82QGq+2aKGRB0Q== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Peter, No, I didn't realize that RFC 2459's name matching process is a subset of X.509's. What I read is: (a) Verify the basic certificate information, including: ... (4) the subject and issuer names chain correctly (that is, the issuer of this certificate was the subject of the previous certificate.) Although I could understand the motivation for PKIX profiling a binary match (identical RDN tags and values - much simpler to implement than forming equivalence classes for all possible values of DirectoryString), I don't see that PKIX has, in fact, required exact comparison. From reading requirement (4), I would assume that "X.509 name matching" is permitted by RFC 2459. What I object to, and what I am assuming Trevor is referring to, are name chaining failures that would be failures under even the most liberal and complex string matching rules. The extent to which applications handle equivalent but not identical names is an implementation detail, best handled by the "be conservative in what you generate" rule - CA's should create certificates with binary-exact chaining, and applications should do as much string matching as the developer feels is appropriate for the targeted certificate profiles. Dave > From: Peter Williams > Subject: RE: Correct approach to certificate validation? > To: "'David P. Kemp'" > Cc: ietf-pkix@imc.org > > Dave, > > I agree that (1), (2) and (3) are true assertions. Perhaps you > could be as clear for me...for the PKIX profile of X.509: > > Do you realize, and agree, that > the way NIST/NSA designers deliberately constructed > RFC 2459's name matching process (during > path validation of an intermediate or > EE certificate) is such that implementations > of the X.509 path processing algorithm produce a different > validity result to the PKIX algorithm. > > To keep your schema, I would suggest that it is not enough to > ask Q1. In fact, one can be easily deceived by considering > only Q1. You must ask the PKIX-specific version of Q1, > and then consider the ramifications on testable > X.509 conformance. (Q3 seems irrelevant.) > > Q1 refers to the rule: > > "10.5 Certificate processing > ... > > The following checks are applied to a certificate: > a) Check that the signature verifies, that dates are valid, that > the certificate subject and certificate issuer names chain correctly, and > that the certificate has not been revoked." > > PKIX Q1 refers to a particular definition of what > chaining names "correctly" is. And the 2459 definition > of name matching in *PKIX-conforming* systems is not compatible > with systems tested/certified to be conforming to the X509 standard, by > specific intent of the NIST/NSA authors, evidently. > > As Trevor said, its all a big mess that requires practical > treatment, not religious dogma, in today's products > that are "based on RFC 2459". The list will no doubt > diverge here between the paper-architects and product > builders. > > Why we cannot just implement X.509 name matching defeats me. > > Peter. From owner-ietf-pkix@imc.org Fri Jun 9 09:42:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11490 for ; Fri, 9 Jun 2000 09:42:47 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA14951; Fri, 9 Jun 2000 06:33:14 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 06:33:12 -0700 Received: from corp.tivoli.com (corp.tivoli.com [216.140.178.60]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14919 for ; Fri, 9 Jun 2000 06:33:11 -0700 (PDT) From: Edward_Dobner@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id IAA10300 for ; Fri, 9 Jun 2000 08:41:39 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568F9.004B84DD ; Fri, 9 Jun 2000 08:44:52 -0500 X-Lotus-FromDomain: TIVOLI SYSTEMS To: ietf-pkix@imc.org Message-ID: <862568F9.004B82D2.00@tivmta4.tivoli.com> Date: Fri, 9 Jun 2000 09:33:30 -0400 Subject: of March 10, 2000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I have a question. In section 6.3.3 CRL Processing, is the following text " (d) Perform the checks in step 1 (b) and (c): 1. obtain and validate the certification path for the delta issuer 2. validate the signature on the delta CRL" I am assuming that steps 1 and 2 here are summarising what steps 1(b) and 1(c) are. But step 1 is not step 1(b) and step 2 is not step 1(c). Should this be "perform the checks in step 1 (b), (c) and (d)" or something else. I am working on the review of the java.cert.CertPath apis that are being defined. I work on IBM tools and API's that incorporate PKI technology in IBM products. Edward J. Dobner Network Security Products Address: IBM; 3039 Cornwallis Drive; NGEA/B502; Research Triangle Park, NC 27709 Telephone: 919-254-4169 (T/L 444-4169) Email: edward.dobner@tivoli.com VM: edobner@tivoli.com Lotus Notes: Edward Dobner/Tivoli Systems@Tivoli Systems From owner-ietf-pkix@imc.org Fri Jun 9 09:51:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11643 for ; Fri, 9 Jun 2000 09:51:14 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA15559; Fri, 9 Jun 2000 06:40:19 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 06:40:17 -0700 Received: from mars.syndata.com ([208.195.248.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15528 for ; Fri, 9 Jun 2000 06:40:17 -0700 (PDT) Received: from syndata.com (CHICKENMAN5 [10.50.1.196]) by mars.syndata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ74GN95; Fri, 9 Jun 2000 09:48:39 -0400 Message-ID: <3940F5D5.6A20878F@syndata.com> Date: Fri, 09 Jun 2000 09:49:09 -0400 From: "Carol A. McNab" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: unsubscribe Content-Type: multipart/mixed; boundary="------------1B086A00A26C151F0CF07A10" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. --------------1B086A00A26C151F0CF07A10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe --------------1B086A00A26C151F0CF07A10 Content-Type: text/x-vcard; charset=us-ascii; name="cmcnab.vcf" Content-Description: Card for Carol A. McNab Content-Disposition: attachment; filename="cmcnab.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:McNab;Carol A. tel;work:(201)836-6200 x1147 x-mozilla-html:TRUE org:Syndata Technologies, Inc. adr:;;500 Frank W. Burr Blvd.;Teaneck;NJ;07666; version:2.1 email;internet:cmcnab@syndata.com title:Senior Software Engineer x-mozilla-cpt:;15600 fn:Carol A. McNab end:vcard --------------1B086A00A26C151F0CF07A10-- From owner-ietf-pkix@imc.org Fri Jun 9 09:56:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11751 for ; Fri, 9 Jun 2000 09:56:27 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA16237; Fri, 9 Jun 2000 06:47:02 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 06:47:01 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16205 for ; Fri, 9 Jun 2000 06:47:00 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA20681; Fri, 9 Jun 2000 09:55:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39405E88.13BADEF8@nma.com> References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> Date: Fri, 9 Jun 2000 09:48:17 -0400 To: Ed Gerck From: Stephen Kent Subject: Re: Correct approach to certificate validation? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Ed, >List: > >Why should we continue to confuse name validation with >certificate validation? Name chaining should be optional IMO, >not expected behavior. 'Be liberal in what you expect' can be >applied here without A N Y decrease in cryptographic >authentication security. > Jon's protocol design advice is good in general, but inappropriate in security contexts, where liberal acceptance policies often lead to vulnerabilities. Steve From owner-ietf-pkix@imc.org Fri Jun 9 10:05:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11976 for ; Fri, 9 Jun 2000 10:05:38 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA16995; Fri, 9 Jun 2000 06:56:13 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 06:56:11 -0700 Received: from corp.tivoli.com (corp.tivoli.com [216.140.178.60]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16961 for ; Fri, 9 Jun 2000 06:56:09 -0700 (PDT) From: Edward_Dobner@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id JAA16472 for ; Fri, 9 Jun 2000 09:04:39 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568F9.004DA21E ; Fri, 9 Jun 2000 09:07:57 -0500 X-Lotus-FromDomain: TIVOLI SYSTEMS To: ietf-pkix@imc.org Message-ID: <862568F9.004DA193.00@tivmta4.tivoli.com> Date: Fri, 9 Jun 2000 09:56:39 -0400 Subject: March 10, 2000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe In section 6.3.3 and the third paragraph from the end of that section. "If all CRLs named in the crl distribution points extension have been exhausted, and the reasons_mask is not "all-reasons" and the cert_status is still UNREVOKED, the verifier must obtain addi- tional CRLs. If the " Is more intended to be here or should the "If the" be removed? Edward J. Dobner Network Security Products Address: IBM; 3039 Cornwallis Drive; NGEA/B502; Research Triangle Park, NC 27709 Telephone: 919-254-4169 (T/L 444-4169) Email: edward.dobner@tivoli.com VM: edobner@tivoli.com Lotus Notes: Edward Dobner/Tivoli Systems@Tivoli Systems From owner-ietf-pkix@imc.org Fri Jun 9 10:18:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12066 for ; Fri, 9 Jun 2000 10:18:06 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA17871; Fri, 9 Jun 2000 07:07:16 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 07:07:09 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17839 for ; Fri, 9 Jun 2000 07:07:08 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA23965; Fri, 9 Jun 2000 10:15:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3940DF3A.7D592D88@celocom.com> References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <3940DF3A.7D592D88@celocom.com> Date: Fri, 9 Jun 2000 10:09:37 -0400 To: Oscar Jacobsson From: Stephen Kent Subject: Re: Correct approach to certificate validation? Cc: ietf-pkix@imc.org Content-Type: multipart/alternative; boundary="============_-1251562280==_ma============" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --============_-1251562280==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Oscar, > > >To try to summarize: > >Constraining one's intended certification is essential, since it will >allow for a much finer granularity in the delegation of trust than the >current model with it's childish boolean trusted/not trusted mechanism. Another way to state this is that use of name constraints allows one to recognize the authority of a CA for a portion of a name space, e.g., a company CA is responsible for issuing certs to employees, a university to faculty, staff and students, etc. I prefer this phrasing because it emphasizes the difference between TTPs where one has to trust the CA, vs. various types of authoritative CAs, where the trust is implicit. Steve --============_-1251562280==_ma============ Content-Type: text/enriched; charset="us-ascii" Oscar, < To try to summarize: Constraining one's intended certification is essential, since it will allow for a much finer granularity in the delegation of trust than the current model with it's childish boolean trusted/not trusted mechanism. Another way to state this is that use of name constraints allows one to recognize the authority of a CA for a portion of a name space, e.g., a company CA is responsible for issuing certs to employees, a university to faculty, staff and students, etc. I prefer this phrasing because it emphasizes the difference between TTPs where one has to trust the CA, vs. various types of authoritative CAs, where the trust is implicit. Steve --============_-1251562280==_ma============-- From owner-ietf-pkix@imc.org Fri Jun 9 10:32:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12287 for ; Fri, 9 Jun 2000 10:32:42 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA19035; Fri, 9 Jun 2000 07:22:30 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 07:22:27 -0700 Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19002 for ; Fri, 9 Jun 2000 07:22:26 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQisvq08638; Fri, 9 Jun 2000 14:30:56 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA23110; Fri, 9 Jun 00 10:27:20 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA26228; Fri, 9 Jun 2000 10:30:54 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14656.65438.308754.800587@xedia.com> Date: Fri, 9 Jun 2000 10:30:54 -0400 (EDT) To: trevorf@Exchange.Microsoft.com Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit >>>>> "Trevor" == Trevor Freeman writes: Trevor> Life is complicated, but this is not so bad - Isaac Newton's Trevor> rules where around a lot longer before they were found to be Trevor> wrong. I am still waiting to here further justification Trevor> (beyond the old ground of "its in the spec"). and so far you Trevor> are confirming my suspicions that there are none. That's interesting. It sounds to me like you're saying "Nothing in any standard matters unless someone can come up with a specific justification for each and every rule I've chosen to ignore". That's comical. In standardization, it often occurs that there are several incompatible ways of doing something, and one has to be chosen. And it may well be that several of the alternatives are equally valid technically. In that case, when one is picked, you have to use that one to interoperate, and the only justification for that one rather than one of the alternatives is indeed "it's in the spec". So are you now claiming that such a standards process is not acceptable? Bizarre. Incidentally, your statement about Newton is incorrect, too. paul From owner-ietf-pkix@imc.org Fri Jun 9 10:48:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12443 for ; Fri, 9 Jun 2000 10:48:14 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA20145; Fri, 9 Jun 2000 07:36:23 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 07:36:19 -0700 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20114 for ; Fri, 9 Jun 2000 07:36:17 -0700 (PDT) Received: by ns.celocom.se; id QAA21043; Fri, 9 Jun 2000 16:44:47 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma021032; Fri, 9 Jun 00 16:44:42 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id QAA28666; Fri, 9 Jun 2000 16:47:17 +0200 Message-ID: <394102D9.AF41B95A@celocom.com> Date: Fri, 09 Jun 2000 16:44:41 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <3940DF3A.7D592D88@celocom.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5ECF4F507BB3224147ED10B9" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a cryptographically signed message in MIME format. --------------ms5ECF4F507BB3224147ED10B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Kent wrote: > I prefer this phrasing because it emphasizes the difference between TTPs where one has to trust the CA, vs. various types of authoritative CAs, where the trust is implicit. A very good point. Besides, the notion of "authoritative CA" becomes a bit vague without some in-band method of communicating precisely what said CA claims to be an authority on. //oscar --------------ms5ECF4F507BB3224147ED10B9 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjA5MTQ0NDQy WjAjBgkqhkiG9w0BCQQxFgQU3I8NRe1o1AgzEtgvUgGDy2Cb8pgwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB12GSJwBCmmToMdUufDO68VE+KOD0Y V/zyjqSQ0i4zon8muysmluU1MeEBtTplBq2XYXkJz8cNeDedPjQD5FEFsi8qVJlRyMZzY3Fs /47PChSoPmI+/AoYH1LhTAgHhd9rL8x7/Stsc5z5w+ExJxKU420Aa27XKSXjiLNo/m2+xg== --------------ms5ECF4F507BB3224147ED10B9-- From owner-ietf-pkix@imc.org Fri Jun 9 11:28:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13088 for ; Fri, 9 Jun 2000 11:28:27 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA22916; Fri, 9 Jun 2000 08:16:31 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 08:16:19 -0700 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22863 for ; Fri, 9 Jun 2000 08:16:18 -0700 (PDT) Received: by ns.celocom.se; id RAA22777; Fri, 9 Jun 2000 17:24:47 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma022692; Fri, 9 Jun 00 17:24:07 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id RAA29711; Fri, 9 Jun 2000 17:26:42 +0200 Message-ID: <39410C15.4A2EECDF@celocom.com> Date: Fri, 09 Jun 2000 17:24:05 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent , ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <3940DF3A.7D592D88@celocom.com> <394102D9.AF41B95A@celocom.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB956762982A67F23934ADFD8" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a cryptographically signed message in MIME format. --------------msB956762982A67F23934ADFD8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oscar Jacobsson wrote: > Besides, the notion of "authoritative CA" becomes a bit vague without > some in-band method of communicating precisely what said CA claims to be > an authority on. Oh dear. I'm still not entirely lucid, I guess. What I was referring to, which might not have been perfectly obvious, was the role of naming constraints in defining exactly which Authority a given CA is claiming. //oscar --------------msB956762982A67F23934ADFD8 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjA5MTUyNDA3 WjAjBgkqhkiG9w0BCQQxFgQUc4D9ZGb4uwyauw1b0aKtP+aeoi4wUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYABQy5KFUq1j9da9TKJD3l9tmZwNXiu 42cYr3+NQg+CR7KcqbmTG64gqypWFTfKCNIeJhVqm1kOxogffHLS43OhcVtC5+EXWABw7xdk sHyWCimKcNryg6mdHjGN+C2SNm/d6g6Knbdw1kjoMZh6EVxKVaoDk4OEHCxF+YekDbQkCg== --------------msB956762982A67F23934ADFD8-- From owner-ietf-pkix@imc.org Fri Jun 9 11:36:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13271 for ; Fri, 9 Jun 2000 11:36:46 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA24382; Fri, 9 Jun 2000 08:27:09 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 08:26:59 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24327 for ; Fri, 9 Jun 2000 08:26:58 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA07428; Fri, 9 Jun 2000 11:35:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39410C15.4A2EECDF@celocom.com> References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <3940DF3A.7D592D88@celocom.com> <394102D9.AF41B95A@celocom.com> <39410C15.4A2EECDF@celocom.com> Date: Fri, 9 Jun 2000 11:36:43 -0400 To: Oscar Jacobsson From: Stephen Kent Subject: Re: Correct approach to certificate validation? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Oscar, >Oscar Jacobsson wrote: > > Besides, the notion of "authoritative CA" becomes a bit vague without > > some in-band method of communicating precisely what said CA claims to be > > an authority on. > >Oh dear. > >I'm still not entirely lucid, I guess. What I was referring to, which >might not have been perfectly obvious, was the role of naming >constraints in defining exactly which Authority a given CA is claiming. Actually, the "local" CA issues a cross cert to the "foreign" CA, and thus the local CA asserts in the name constraints extension the part of the portion of the name space for which it considers the foreign CA to be authoritative. So, the foreign CA does not make the claim in terms of the name constraints. But you are right in asserting that some OOB mechanism is used by the local CA to decide what set of name constraints are appropriate re the foreign CA. Steve From owner-ietf-pkix@imc.org Fri Jun 9 11:58:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13786 for ; Fri, 9 Jun 2000 11:58:38 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27030; Fri, 9 Jun 2000 08:48:05 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 08:47:02 -0700 Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26920 for ; Fri, 9 Jun 2000 08:47:01 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e59FtUV16227 for ; Fri, 9 Jun 2000 08:55:31 -0700 (PDT) Message-ID: <394113ED.D38CD417@xcert.com> Date: Fri, 09 Jun 2000 11:57:33 -0400 From: Michael Young Organization: Xcert International X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: remove Content-Type: multipart/mixed; boundary="------------D27A8B7D42B16DA9DC4CB9B3" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. --------------D27A8B7D42B16DA9DC4CB9B3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit remove --------------D27A8B7D42B16DA9DC4CB9B3 Content-Type: text/x-vcard; charset=us-ascii; name="myoung.vcf" Content-Description: Card for Michael Young Content-Disposition: attachment; filename="myoung.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Young;Michael tel;cell:1-914-572-2803 tel;work:1-203-969-2387 x-mozilla-html:FALSE url:http://www.xcert.com org:Xcert International Inc. adr:;;463-3 Cove Road;Stamford;Connecticut;06902;USA version:2.1 email;internet:myoung@xcert.com title:Sales Engineer note:No notes at this time. fn:Michael Young end:vcard --------------D27A8B7D42B16DA9DC4CB9B3-- From owner-ietf-pkix@imc.org Fri Jun 9 12:05:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14019 for ; Fri, 9 Jun 2000 12:05:42 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28284; Fri, 9 Jun 2000 08:56:15 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 08:56:13 -0700 Received: from symbianuk05.symbian.com ([194.200.144.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28242 for ; Fri, 9 Jun 2000 08:56:09 -0700 (PDT) Received: from lon-williamb ([10.151.15.235]) by symbianuk05.symbian.com (Lotus Domino Release 5.0.1b (Intl)) with SMTP id 2000060917011389:25271 ; Fri, 9 Jun 2000 17:01:13 +0100 Message-ID: <024701bfd22b$f50eae70$eb0f970a@lon-williamb.intra> From: "william bamberg" To: Subject: HTTP over TLS: dNSName syntax question Date: Fri, 9 Jun 2000 17:00:53 +0100 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-MIMETrack: Itemize by SMTP Server on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 09/06/2000 05:01:13 PM, Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 09/06/2000 05:01:46 PM, Serialize complete at 09/06/2000 05:01:46 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Sorry if this is marginally off topic, but I'd like to know people's opinions... RFC 2818, 'HTTP over TLS', Section 3.1, 'Server Identity' describes how to compare the name in the server's certificate with the server domain name: 'If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used...Matching is performed using the matching rules specified by [RFC2459].' RFC 2459 says that the dNSName 'MUST be in the "preferred name syntax," as specified by RFC 1034.' So, presumably the matching here is performed by comparing every subdomain in the dNSName against the corresponding subdomain in the server's domain name. But RFC 2818 goes on to say that 'Names may contain the wildcard character *' and goes on to specify how these names should be handled. The 'preferred name syntax' says nothing about wildcards, so my question really is, how can the dNSName component both be represented according to the 'preferred name syntax', and contain wildcards? Thanks very much for any help you can offer. Will From owner-ietf-pkix@imc.org Fri Jun 9 12:08:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14105 for ; Fri, 9 Jun 2000 12:08:19 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27403; Fri, 9 Jun 2000 08:50:59 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 08:50:47 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27325 for ; Fri, 9 Jun 2000 08:50:46 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 09 Jun 2000 09:26:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 09 Jun 2000 09:26:30 -0600 From: "Bob Jueneman" To: , Cc: , Subject: Re: Correct approach to certificate validation? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA27326 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Trevor, putting aside for a moment the issue of what the standard says, doesn't say, or ought to say, I'm still not sure that I understand the issue that you are raising. I thought that when you said that you were using the issuer name in a subordinate certificate as a "hint" in finding the correct certificate issuer, you might referring to some kind of fancy heuristic algorithm that would try to divine where the next certificate up the chain might actually be found -- something I would very much like to see. But if Al's example is a correct presentation of what you are saying, then I don't understand how or why the CA created the certificate in that manner in the first place. I have a reasonable fertile imagination, and so I can imagine situations where the issuer name might not match, deliberately -- for example a merger or company name change, where the CA certificate is reissued with the new name, but all of the end-user certs haven't been rolled over yet. (Why the old certificate with the old name would have been left in place escapes me, however.) I tend to agree with the rest of the community -- if this is just the result of sloppy programming of the CA implementation in not enforcing reasonable behavior when the certificates were created, then this is indefensible. However, if you have a real reason or justification, I'd like to hear it. It does disturb me just a little to be over-constraining the chaining relationship. If name subordination really matters, then a constraint ought to be expressed. If name subordination doesn't matter, then I suppose I could question why the reverse chaining issue is important, assuming the path can still be constructed somehow. One example that might be interesting to consider would be a bilingual country such as Canada, where the CA's certificate might be in English, and yet the end-user's certificate might be in French, including the French version of the issuer's name. Other multilingual examples might include certificates where the CA's DN is written in one character set, and for reasons of national pride, local laws, custom, or merely comprehensibility by the consumer, the subject and issuer name are written in a different character set. Generally speaking, accepted standards ought to be followed, unless there are good reasons not to (not including programming bugs).. If there is such a good reason, the standards ought to be revised. I'm trying to understand where there is in fact a good reason. Bob << 06/08/00 08:31PM >>> Trevor, Here's the justification: Suppose that a CA system (by, e.g., Netscape, Entrust, VeriSign, whomever) has been built to conform to existing/understood X.509/RFC2459 name chaining rules. Suppose that such a system has been deployed for, oh, say, a large Government department, or a large corporation, or... Now, suppose that a CA from some other corporation that follows the rules you suggest - i.e., name chaining doesn't matter. We want to integrate that CA into the existing PKI. Now, for whatever reason - human frailty, whatever - that new CA is used to create a certificate whose distinguish name is "C=AW, O=Government, OU= Computers, CN= CA1", and then that CA creates user certs where the issuer name is "C=AW, O=Government, OU=Computer, CN=CA1". Note that these names are not equivalent.* Suppose that all other information - AKI, AIA, etc. - is set up properly. Now, whenever a cert path is validated using the new CA, it will be validated, because the fact that the end entity cert's issuer name and the CA cert's subject name aren't the same doesn't matter. However, whenever that same cert path is validated by a node in the existing PKI, validation will fail, because of the name chaining failure. The notion of obtaining different results by different points in the system is disconcerting, to say the least. That's the reason: by building your system this way, you cause the multi-vendor interoperable PKI to fail. If you were building your system to not interoperate with any other existing products, then I think we could probably agree that you were right; there is no real reason that names have to chain. However, lots of people do want your system to interoperate with other products. I'm fairly confident that Dave wants them to. I know that in some of the cases I'm dealing with now, I need them to. And they don't. Al Arsenault Chief Security Architect Diversinet Corp. *And yes, I have seen cases where name chaining failed - and thus certificate validation failed when it shouldn't have - because of a misplaced comma in a CN field. I've also seen it fail because of an extra space in an OU field, and several other situations. > Trevor Freeman wrote: > > Life is complicated, but this is not so bad - Isaac Newton's rules > where around a lot longer before they were found to be wrong. > I am still waiting to here further justification (beyond the old > ground of "its in the spec"). and so far you are confirming my > suspicions that there are none. > > -----Original Message----- > From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > Sent: Thursday, June 08, 2000 8:35 AM > To: ietf-pkix@imc.org > Subject: RE: Correct approach to certificate validation? > > Trevor, > > > From: "Trevor Freeman" > > > > David, > > Interoperability is a primary goal, however that is often scarified > by > > standards. It is very easy to produce a document with a set of do's > and > > don'ts without any regard for the previous standard, the impact on > the > > deployed products or how migration is achieved between the old and > new > > standard. It is also unrealistic to think that all products deployed > > would conform to a single standard. Most products have a lifetime of > > years. The interoperability matrix is vast and getting worse every > time > > a new version of a standard is released. > > So to return to the original point, besides citing a 20 year old > clause > > in a standard, and saying we should do it because its in the > standard, > > and requiring administrators to have a faultless record, I have > still > > not hear any reasoned, argument as to what is actually achieved by > this > > behavior. > > No standard or clause in a standard has a divine right of existence. > > Trevor > > On the one hand, you seem to be decrying the ease of producing new > specifications without regard for previous standards and deployed > products. > > On the other, you seem to support discarding a 20 year old clause > in a standard without regard for its impact on deployed products which > have been built according to the standard. > > The "divine right" of any clause comes not from heaven or inheritance, > but from the fact that it has been vetted internationally (in the ISO > and the IETF) over a period of many years. Over that time (whether > it's > 12 or 20 years is immaterial), the requirement that certificates point > to the correct issuer has not only survived, it has not to my > knowledge > been even mildly controversial. Now that there is discussion of > the topic, the requirement will either survive or be discarded based > on international consensus. There is no divine right, just the > stability (inertia?) of a consensus-based standard-setting > process. > > You may present a case that the requirement should be removed from > X.509 > and then from the PKIX profile of X.509. > Or you may choose not to comply with X.509. > > But you can't both ignore the requirement and claim compliance. > > > Certificate discovery is not the issue here. > > > > For certificate discovery, we have a domain push mechanism as well > as > > AIA. We are also adding a lookup by name, and a configurable URL > search > > path i.e. a set of URLs to search (LDAP, HTTP, FTP) > > Certificate discovery *is* the issue. > > If you are adding a "lookup by name" function to your products, > how will that work if certificates do not have correct issuer > names? If I have someone's End Entity certificate, how do I find a > path of CA certs that leads to my trust point (not necessarily the > certificate subject's trust point), in the multi-vendor, > multi-administrative-domain environment of the Internet. > > Products may support many certificate discovery mechanisms, both > standards-based and differentiating. But there needs to be at > least one "Internet" interoperability mode which all products > support. That mode is defined by PKIX: the certificate profile > and the LDAP schema. > > One "Internet mode" mechanism which follows the current PKIX > specifications is for organizations to place public information, > including CA and EE certificates, in border directories, and to link > the border directories together using directory-to-directory chaining, > LDAP referrals, or both. If you propose to eliminate the X.509 > requirement for correct issuer names, you will need to address the > impact on current applications built to the current standards, > as well as the feasability of future applications built to an > amended standard. > > Dave > > P.S. I don't understand why you keep referring to "punishing > administrators" and "requiring administrators to have a flawless > record" and "eliminating imperfection". A CA workstation has its own > signing key and certificate. If the workstation cannot correctly > place > its own name in the issuer field of every certificate it signs, that > is > a product flaw. This X.509 requirement does not hinge upon human > perfectability. From owner-ietf-pkix@imc.org Fri Jun 9 12:09:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14146 for ; Fri, 9 Jun 2000 12:09:15 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28021; Fri, 9 Jun 2000 08:55:25 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 08:55:22 -0700 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27976 for ; Fri, 9 Jun 2000 08:55:19 -0700 (PDT) Received: by ns.celocom.se; id SAA25342; Fri, 9 Jun 2000 18:03:48 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma025297; Fri, 9 Jun 00 18:03:25 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id SAA30768; Fri, 9 Jun 2000 18:06:01 +0200 Message-ID: <3941154C.22D86807@celocom.com> Date: Fri, 09 Jun 2000 18:03:24 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <3940DF3A.7D592D88@celocom.com> <394102D9.AF41B95A@celocom.com> <39410C15.4A2EECDF@celocom.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5A69A9209B0A2DAD24DDBCF3" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a cryptographically signed message in MIME format. --------------ms5A69A9209B0A2DAD24DDBCF3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Kent wrote: > Actually, the "local" CA issues a cross cert to the "foreign" CA, and > thus the local CA asserts in the name constraints extension the part > of the portion of the name space for which it considers the foreign > CA to be authoritative. So, the foreign CA does not make the claim > in terms of the name constraints. But you are right in asserting > that some OOB mechanism is used by the local CA to decide what set of > name constraints are appropriate re the foreign CA. Naming constraints in cross-certificates hadn't even begun to occur to me. I seem to have missed the actual point. Again. :-( My reasoning was along the line that it would not only be polite of a Certification Authority to clearly define the limits of its intended certification, both generally as in its Certification Practise Statement and specifically as in its naming constraints, but would also, IMHO, make the decision of the relying party to trust that CA less "critical". I can't really see the current on/off trust mechanisms usually employed as one that even attempts to approximate reality. There are completely different levels of trust involved between, as an example, allowing somone to fix your car and allowing someone to baby-sit (sp?) your children. Even if the level of trust were the same, the level of authority would differ. One would not necessarily expect one person to be suitable to perform both roles, trusted or not. Note to self: or am I just not a very trusting person? //oscar --------------ms5A69A9209B0A2DAD24DDBCF3 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjA5MTYwMzI2 WjAjBgkqhkiG9w0BCQQxFgQUIVc8JbpF4FVCT5aNuE8pWq2S/WYwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCDO4S9a64bMEP95NkoxEVv/fIY7HBb iSBplpG9TA4EjEdLJBn+LiXHQgOfYMeJzYy819gxs2E5pZRZxVLi0/C3d2/eXg7+2MNZKaUD ZVA2VtrMU/3WLbojcgwZAng1juZZwLKs/XYXgBfS7MUMMkskFbO5xo+IRA9MlX6FwYipJQ== --------------ms5A69A9209B0A2DAD24DDBCF3-- From owner-ietf-pkix@imc.org Fri Jun 9 12:41:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14759 for ; Fri, 9 Jun 2000 12:41:05 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01029; Fri, 9 Jun 2000 09:28:18 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 09:28:11 -0700 Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA00995 for ; Fri, 9 Jun 2000 09:28:10 -0700 (PDT) Received: (qmail 27848 invoked from network); 9 Jun 2000 16:36:42 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.communitech.net with SMTP; 9 Jun 2000 16:36:42 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 09 Jun 2000 11:36:40 -0500 Message-ID: <39411D1C.795C399D@nma.com> Date: Fri, 09 Jun 2000 09:36:44 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Oscar Jacobsson wrote: > Ed Gerck wrote: > > Why should we continue to confuse name validation with > > certificate validation? Name chaining should be optional IMO, > > not expected behavior. 'Be liberal in what you expect' can be > > applied here without A N Y decrease in cryptographic > > authentication security. > > My personal opinion, and humble one at that, is that the issue is of > greater importance than "simply" one of cryptographic security. > > The principals of X.509, as has been previously stated in this thread, > are in the naming, and not in the cryptographic keys themselves. But X.509 is moot on how to verify such names [1,2], which task it delegates to the CA (and NA). The ONLY verification procedure that X.509 specifies [2] is on the subject's key pair by requiring nonce authentication -- the subject must prove possession of the private-key. So, in X.509 (and PKIX) what we have are *two* pieces of data with different validity levels: 1. the public-key was positively verified 2. the name was hearsay. So, now the name should trump the key? The tail wants to wag the dog, we may as well say. Of course, I agree that an additional function COULD provide for name validation according to chaining rules but satisfying such a function should be optional, not expected. Cheers, Ed Gerck [1] Section 11.2 of X.509v3, "Management of certificates", states that the certificate allows an association between a name called "unique distinguished name" or DN for the user and the user's public-key: "A certificate associates the public key and unique distinguished name of the user it describes.", while Section 7 explains that such DNs are essential to the security design of X.509: "Authentication relies on each user possessing a unique distinguished name." But, how are such DNs assigned? Where are they unique? The DN is denoted by a NA (Naming Authority) and accepted by a CA (Certification Authority) as unique within the CA's domain, where the CA can double as a NA. HOWEVER, note that the same user can have different DNs in different CAs, or can use the same DN in different CAs even if it is not the first one to use it in a CA -- so that different DNs for different CAs do not necessarily mean different users and vice-versa. Further, a DN does not have to contain the user's real-world name or location. Thus, semantically, the CA certificate refers to a name; however it does not denote it. [2] X.509 is moot on validation procedures for data included in a certificate such as the user's name, with the exception of validation procedures for the user's public-key which are suggested (not mandated) in Section 10 of X.509v3. For example, regarding validation procedures for the user's identity, Section 11.2.a states that: "a certification authority shall be satisfied of the identity of a user before creating a certificate for it", which means that identity validation procedures are to be satisfied in the CA's frame of reference by following the CA's own self-defined rules (CPS), which are declared outside the scope of X.509 and can be entirely different for different CAs. From owner-ietf-pkix@imc.org Fri Jun 9 12:55:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15089 for ; Fri, 9 Jun 2000 12:55:53 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01440; Fri, 9 Jun 2000 09:46:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 09:45:59 -0700 Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01410 for ; Fri, 9 Jun 2000 09:45:58 -0700 (PDT) Received: (qmail 5578 invoked from network); 9 Jun 2000 16:54:30 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.communitech.net with SMTP; 9 Jun 2000 16:54:30 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 09 Jun 2000 11:54:26 -0500 Message-ID: <39412146.B5FC28EB@nma.com> Date: Fri, 09 Jun 2000 09:54:30 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Stephen Kent wrote: > Ed, > >List: > > > >Why should we continue to confuse name validation with > >certificate validation? Name chaining should be optional IMO, > >not expected behavior. 'Be liberal in what you expect' can be > >applied here without A N Y decrease in cryptographic > >authentication security. > > > > Jon's protocol design advice is good in general, but inappropriate in > security contexts, where liberal acceptance policies often lead to > vulnerabilities. In this case, however, I see no vulnerability in what X.509/PKIX intend to provide -- a cryptographic authentication protocol. In regard to name assignment vulnerabilities, I note that this is also declared out of scope in X.509/PKIX and delegated to the CA/NA + CPS. So, why should that which is declared out of scope trump that which is the only thing that the protocol verifies? Logic would indicate that since name validation by name chaining verification is a weaker concept than the one it is blocking, then this should not be mandatory behavior. Making it mandatory is what is confusing, IMO. Cheers, Ed Gerck From owner-ietf-pkix@imc.org Fri Jun 9 13:01:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15253 for ; Fri, 9 Jun 2000 13:01:34 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01734; Fri, 9 Jun 2000 09:52:00 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 09:51:56 -0700 Received: from server.ica.cz (server.ica.cz [195.47.13.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01698 for ; Fri, 9 Jun 2000 09:51:55 -0700 (PDT) Received: from SZOTKOWSKI (com.ica.cz [195.47.13.10]) by server.ica.cz (8.9.2/8.8.7) with SMTP id TAA11854 for ; Fri, 9 Jun 2000 19:00:11 +0200 (CEST) Message-ID: <164901bfd234$2cb1b7c0$0c7011ac@SZOTKOWSKI> From: "Martin Szotkowski" To: References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> Subject: TSA signing key? Date: Fri, 9 Jun 2000 19:00:10 +0200 Organization: PVT, a.s. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit In draft is written that TSA cert must be used exclusively for time stamp. Why TSA certificate cann't be same as CA certificate? thanks Martin From owner-ietf-pkix@imc.org Fri Jun 9 14:10:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16535 for ; Fri, 9 Jun 2000 14:10:32 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA02999; Fri, 9 Jun 2000 10:58:26 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 10:58:19 -0700 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02969 for ; Fri, 9 Jun 2000 10:58:17 -0700 (PDT) Received: by ns.celocom.se; id UAA28669; Fri, 9 Jun 2000 20:06:47 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma028638; Fri, 9 Jun 00 20:06:03 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id UAA01628; Fri, 9 Jun 2000 20:08:38 +0200 Message-ID: <3941320A.6D65328A@celocom.com> Date: Fri, 09 Jun 2000 20:06:02 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ed Gerck CC: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCE6C76DA8CA93233F3045CEB" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a cryptographically signed message in MIME format. --------------msCE6C76DA8CA93233F3045CEB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ed Gerck wrote: > So, now the name should trump the key? The tail wants to wag the > dog, we may as well say. Neither name nor key would amount to much on their own, IMHO. I agree that there is a great deal of ambiguity regarding how certificate subjects are named. Naming conventions are decided on a per-issuer basis, IIRC, which has confused quite a few of my countrymen, being used to having access to a government-issued personal identification number. However: if constraints are placed on subject names, they are most probably placed there for a reason. Ignoring said constraints, having been deemed important enough to distribute signed and in-band, could surely hardly be considered prudent? //oscar --------------msCE6C76DA8CA93233F3045CEB Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjA5MTgwNjAz WjAjBgkqhkiG9w0BCQQxFgQUfcp3P3jCw6IVzn7N0416FZPGZdYwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBk/U6KE0mQz5d6vQfBrrKxkwbCsgTt uYFHV65vPxTLAbHWgC/aKBl5Ji/PQpg2f+wWwz9X7rrn3Z1DLt1G0qI261M0H8fi0U/7CEsw Wjs7mvkhR6P4fNEk5JJ4Hthb6KZ4mBLtDCa+iwX2tSEAirGuefEgMETLFace1cX9B+okFA== --------------msCE6C76DA8CA93233F3045CEB-- From owner-ietf-pkix@imc.org Fri Jun 9 15:25:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17664 for ; Fri, 9 Jun 2000 15:25:30 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA04617; Fri, 9 Jun 2000 12:01:59 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 12:01:50 -0700 Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA04581 for ; Fri, 9 Jun 2000 12:01:49 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Jun 2000 11:27:55 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Fri, 9 Jun 2000 11:36:13 -0700 content-class: urn:content-classes:message Subject: RE: Correct approach to certificate validation? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD241.964A9470" Date: Fri, 9 Jun 2000 11:36:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Message-ID: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/RpYvr/R0mTULqScSPtcRBnaryigACZ76w From: "Trevor Freeman" To: "Stephen Kent" Cc: X-OriginalArrivalTime: 09 Jun 2000 18:36:13.0177 (UTC) FILETIME=[96A50E90:01BFD241] Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD241.964A9470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Steve, With the Internet today, if you are relying on directory lookup based on a DN as you only solution to certificate discovery - I think you will be disappointed. There will be "communities" who will be able to get this to work, but there is no sign of a universal solution equivalent to DNS where I can take any DN and find an object in a directory with that name. Therefore failure to find a certificate based on a issuer DN in a certificate is a reality that will have to be dealt with - for much more fundamental reasons. There are a couple of instances of by design behavior that have been presented to me. There are mergers and acquisitions where names and affiliation are changing. There are also instances where one CA does not want to endorse the name of another when it cross certifies. The search path mechanism is very similar to AIA, in that given a set of URLs, you can access the URL looking for certificates. With LDAP URLs, it's not difficult to construct a generic query. With other, the underlying assumption is that you find a pkcs#7. Trevor -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Thursday, June 08, 2000 12:21 PM To: Trevor Freeman Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, >Certificate discovery is not the issue here. I know that the focus of the discussion has been matching up subject=20 and issuer names when validating a cert path. However, since cert=20 path discovery logically precedes validation, and since the nominal=20 model for discovery is based on looking for a CA cert that contains a=20 subject name that was the issuer name on the "lower" level cert, I=20 think it appropriate to ask the discovery question. >The question is that if you have a certificate who's signature=20 >integrity can be traced up to a trusted root, containing acceptable=20 >policy as defined by that root, and who's names lie within the=20 >allowed namespaces as defined by the name constraints in parent=20 >certificates to the certificate in question, what is the value in=20 >checking that the issuer-subject names chain? >We have encountered such situations, by design, and by accident. In=20 >all cases, the cost\benefit analysis in our view is stacked in favor=20 >of not performing the name chaining check, and tolerating this=20 >situation. Could you provide some examples of the "by design" situations you=20 have encountered? >I agree that name constraints are important as the certificate is=20 >making those names available to the applications, so it is important=20 >that we can filter acceptable from not-acceptable names. We actually=20 >follow a methodology similar to one you mentioned in a previous=20 >thread which is to build all possible paths, then apply the name=20 >constraints to determine the quality of the path. I don't recall suggesting the approach you mention here. I would=20 guess that path discovery performed using subject/issuer name=20 matching and AIK/SIK discrimination would rarely yield multiple=20 paths. But, if it did, then I agree that application of the name=20 constraints extension as part of path validation would discard paths=20 that violated the constraints. >For certificate discovery, we have a domain push mechanism as well=20 >as AIA. We are also adding a lookup by name, and a configurable URL=20 >search path i.e. a set of URLs to search (LDAP, HTTP, FTP) The domain push mechanism sounds local, perhaps MS specific? AIA=20 would be definitive. Does one look at the issuer name to select a=20 subset of the search search paths you allude to, or do you just try=20 to do lookups via ll of them? Steve ------_=_NextPart_001_01BFD241.964A9470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

Steve,
With the Internet today, if you are relying on = directory lookup based on a DN as you only solution to certificate = discovery - I think you will be disappointed. There will be = "communities" who will be able to get this to work, but there = is no sign of a universal solution equivalent to DNS where I can take = any DN and find an object in a directory with that name. Therefore = failure to find a certificate based on a issuer DN in a certificate is a = reality that will have to be dealt with - for much more fundamental = reasons.

There are a couple of instances of by design behavior = that have been presented to me. There are mergers and acquisitions where = names and affiliation are changing. There are also instances where one = CA does not want to endorse the name of another when it cross = certifies.

The search path mechanism is very similar to AIA, in = that given a set of URLs, you can access the URL looking for = certificates. With LDAP URLs, it's not difficult to construct a generic = query. With other, the underlying assumption is that you find a = pkcs#7.

Trevor

 -----Original Message-----
From:   Stephen Kent [mailto:kent@bbn.com]
Sent:   Thursday, June 08, 2000 12:21 = PM
To:     Trevor Freeman
Cc:     ietf-pkix@imc.org
Subject:        = RE: Correct approach to certificate validation?

Trevor,

>Certificate discovery is not the issue = here.

I know that the focus of the discussion has been = matching up subject
and issuer names when validating a cert path.  = However, since cert
path discovery logically precedes validation, and = since the nominal
model for discovery is based on looking for a CA cert = that contains a
subject name that was the issuer name on the = "lower" level cert, I
think it appropriate to ask the discovery = question.

>The question is that if you have a certificate = who's signature
>integrity can be traced up to a trusted root, = containing acceptable
>policy as defined by that root, and  who's = names lie within the
>allowed namespaces as defined by the name = constraints in parent
>certificates to the certificate in question, what = is the value in
>checking that the issuer-subject names = chain?
>We have encountered such situations, by design, = and by accident. In
>all cases, the cost\benefit analysis in our view = is stacked in favor
>of not performing the name chaining check, and = tolerating this
>situation.

Could you provide some examples of the "by = design" situations you
have encountered?

>I agree that name constraints are important as the = certificate is
>making those names available to the applications, = so it is important
>that we can filter acceptable from not-acceptable = names. We actually
>follow a methodology similar to one you mentioned = in a previous
>thread which is to build all possible paths, then = apply the name
>constraints to determine the quality of the = path.

I don't recall suggesting the approach you mention = here.  I would
guess that path discovery performed using = subject/issuer name
matching and AIK/SIK discrimination would rarely = yield multiple
paths. But, if it did, then I agree that application = of the name
constraints extension as part of path validation = would discard paths
that violated the constraints.

>For certificate discovery,  we have a domain = push mechanism as well
>as AIA. We are also adding a lookup by name, and = a configurable URL
>search path i.e. a set of URLs to search (LDAP, = HTTP, FTP)

The domain push mechanism sounds local, perhaps MS = specific?  AIA
would be definitive.  Does one look at the = issuer name to select a
subset of the search search paths you allude to, or = do you just try
to do lookups via ll of them?

Steve


------_=_NextPart_001_01BFD241.964A9470-- From owner-ietf-pkix@imc.org Fri Jun 9 17:07:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18841 for ; Fri, 9 Jun 2000 17:07:27 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA06773; Fri, 9 Jun 2000 13:56:39 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 13:56:29 -0700 Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA06741 for ; Fri, 9 Jun 2000 13:56:28 -0700 (PDT) Received: (qmail 6345 invoked from network); 9 Jun 2000 21:05:01 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.communitech.net with SMTP; 9 Jun 2000 21:05:01 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 09 Jun 2000 16:04:59 -0500 Message-ID: <39415C00.773D4669@nma.com> Date: Fri, 09 Jun 2000 14:05:04 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> <3941320A.6D65328A@celocom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Oscar Jacobsson wrote: > Ed Gerck wrote: > > So, now the name should trump the key? The tail wants to wag the > > dog, we may as well say. > > However: if constraints are placed on subject names, they are most > probably placed there for a reason. Ignoring said constraints, having > been deemed important enough to distribute signed and in-band, could > surely hardly be considered prudent? A checkbox with "Enforce name chaining" could take care of all cases where name chaining is desired, much in the same way that the depth of certificate signing can also be chosen by the user in Apache SSL for example (or, do you really must trust a CA you don't trust just because it chains with a CA you trust? -- maybe, possibly not). Making name chaining mandatory, OTOH, still does not mean that the name is: (i) correct, (ii) valid, (iii) legal, (iv) unique, etc. So, if constraints are placed on names this is still much weaker than the nonce authentication constraints placed on keys -- where a principal must have had use of the private-key in order to sign a nonce. They are like apples and speedboats, names and keys. Why then should we not differentiate between name validation and certificate validation? Cert validation may include name validation but not necessarily and there is no cryptographic value to be gained thereby. Of course, some years ago everything was quite undifferentiated and there was no distinction between different functions which we now perceive as distinct. For example, the CA and the NA roles -- as well as the CA and the TTP roles. Cheers, Ed Gerck From owner-ietf-pkix@imc.org Fri Jun 9 17:31:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19082 for ; Fri, 9 Jun 2000 17:31:24 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA07482; Fri, 9 Jun 2000 14:18:37 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 9 Jun 2000 14:18:34 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07452 for ; Fri, 9 Jun 2000 14:18:34 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FVW00F01OX6UN@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 09 Jun 2000 14:27:06 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FVW00FLROX62A@ext-mail.valicert.com>; Fri, 09 Jun 2000 14:27:06 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 09 Jun 2000 14:21:16 -0700 Content-return: allowed Date: Fri, 09 Jun 2000 14:21:15 -0700 From: Frank Balluffi Subject: RE: Correct approach to certificate validation? To: "'jimsch@nwlink.com'" , "'David P. Kemp'" , ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE2E08B10@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=windows-1252 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Regarding a company changing its name, it is difficult for me to imagine a scenario in which a company would need to change the subject in its certificate but not need to change the issuer in the certificates that it has issued. Frank > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Thursday, June 08, 2000 9:36 PM > To: 'David P. Kemp'; ietf-pkix@imc.org > Subject: RE: Correct approach to certificate validation? > > > David, > > My draft has nothing to do with the fact that the name chaining may be > incorrect but applies even in the cases where name chaining > is present and > correct. > > There are various cases where not going strictly on name > chaining can be > benifitual. For example, if a company changes names the CA > certificate can > be updated without having to re-issue all subordiante > certificates at the > same time. (This may happen due to merges, splits, name > changes or court > ordered actions.) > > jim > > -----Original Message----- > From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > Sent: Wednesday, June 07, 2000 7:00 AM > To: ietf-pkix@imc.org > Subject: RE: Correct approach to certificate validation? > > > Trevor, > > It isn't about punishing administrators for minor errors, it is > about achieving an overall system with the goals of being both > secure and non-intrusive to the end user. That may well mean that > administrators have to do more thinking, planning, and > quality control, > but that is what they (we, the providers of a PKI for our branch of > Govt) are paid to do. > > The specific case I'm referring to is Jim Schaad's assertion that an > S/MIME-specific cert path attribute is needed because applications > can't find CA certificates. I didn't realize until now that that was > because in your environment subject certificates are not required to > have a correct issuer name! It seemed obvious to me that the PKI is > responsible for correctly binding names to keys. But you are saying > that Issuer names don't really matter, they're just a hint to help > applications search for a cert with a signing key that validates the > subject cert signature. Well no wonder applications can't find CA > certs in that environment! > > That isn't necessarily a wrong theoretical approach - SPKI is based > on the premise that only keys are important, names are simply optional > attributes attached to keys. But it is wrong in X.509 because X.509 > certificates are identified by and stored under Distinguished Names, > not public keys or SubjectKeyIdentifiers. > > Standards are about interworking in a multi-vendor environment; the > testable requirements contained in standards are covenants between > supplier and customer. My goal is for a CMI purchased from vendor > X and operated by company A to work with applications purchased from > vendors Y and Z and operated by companies B and C. I understand > that that is not your primary goal, but I expect you to acknowledge > that when as a result of non-conformance some applications work and > others don't, it is NOT the fault of the conforming applications even > when they are the ones that fail. And that when someone from company > X proposes as a Standard a workaround for a problem created somewhere > else in company X, the IETF is entitled to disregard the > company-specific rationale for that workaround. > > Regards, > Dave > > > > > From: "Trevor Freeman" > > > > Hi David, > > I am afraid I don't see it necessary to eradicate every little > > imperfection because it is there. To err is human, and people make > > mistakes. People also have a wide list of requires which > you may or may > > not agree with, but it does not mean that it is less real to them. > > So I don't see this as an error, simple a different point > of view, and > > we will obviously disagree on this point. > > At the end of the day it is up to any product vendor to > make the call as > > to what is\is not in their product, regardless what is in > the standard. > > It is up to the market place to decide. History certainly > tells us that > > customers like robustness in a product. > > If you can cite a specific issue, then we will obviously > reconsider, but > > I don't find punishing minor infractions of administrators > a compelling > > case. > > Trevor > > From owner-ietf-pkix@imc.org Sun Jun 11 21:59:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11731 for ; Sun, 11 Jun 2000 21:59:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA01790; Sun, 11 Jun 2000 18:30:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 11 Jun 2000 18:29:43 -0700 Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA01495 for ; Sun, 11 Jun 2000 18:29:42 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 11 Jun 2000 18:30:15 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Sun, 11 Jun 2000 18:36:54 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD40E.AFF1AEB2" Subject: RE: Correct approach to certificate validation? X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Date: Sun, 11 Jun 2000 18:36:53 -0700 Message-ID: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/Ru2F5TWCKgxP7QKScErHf0p2sTACUb6Jg From: "Trevor Freeman" To: "Al Arsenault" Cc: X-OriginalArrivalTime: 12 Jun 2000 01:36:54.0273 (UTC) FILETIME=[B0562710:01BFD40E] Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD40E.AFF1AEB2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Al, There are two players in this piece. CA and relying parties. THE only point where the name chaining rule can be enforced reliably is when building a self signed root certificate.=20 It you are asserting that if by some change a set of certificate was built where the names did not chain, and that clients who enforced the name chaining rule would consider the chain invalid, whereas clients which did not enforce the rule would consider the chain as valid, then I agree.=20 What I don't see is justification of the rule as being necessary. Why is this rule considered necessary in the standard? Trevor -----Original Message----- From: Al Arsenault [mailto:awa1@home.com]=20 Sent: Thursday, June 08, 2000 7:32 PM To: Trevor Freeman Cc: David P. Kemp; ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? Trevor, Here's the justification: Suppose that a CA system (by, e.g., Netscape, Entrust, VeriSign, whomever) has been built to conform to existing/understood X.509/RFC2459 name chaining rules. Suppose that such a system has been deployed for, oh, say, a large Government department, or a large corporation, or... Now, suppose that a CA from some other corporation that follows the rules you suggest - i.e., name chaining doesn't matter. We want to integrate that CA into the existing PKI. =20 Now, for whatever reason - human frailty, whatever - that new CA is used to create a certificate whose distinguish name is "C=3DAW, O=3DGovernment, OU=3D Computers, CN=3D CA1", and then that CA creates = user certs where the issuer name is "C=3DAW, O=3DGovernment, OU=3DComputer, CN=3DCA1". Note that these names are not equivalent.* Suppose that all other information - AKI, AIA, etc. - is set up properly. Now, whenever a cert path is validated using the new CA, it will be validated, because the fact that the end entity cert's issuer name and the CA cert's subject name aren't the same doesn't matter. However, whenever that same cert path is validated by a node in the existing PKI, validation will fail, because of the name chaining failure. The notion of obtaining different results by different points in the system is disconcerting, to say the least. That's the reason: by building your system this way, you cause the multi-vendor interoperable PKI to fail. If you were building your system to not interoperate with any other existing products, then I think we could probably agree that you were right; there is no real reason that names have to chain. However, lots of people do want your system to interoperate with other products. I'm fairly confident that Dave wants them to. I know that in some of the cases I'm dealing with now, I need them to. And they don't. Al Arsenault Chief Security Architect Diversinet Corp. *And yes, I have seen cases where name chaining failed - and thus certificate validation failed when it shouldn't have - because of a misplaced comma in a CN field. I've also seen it fail because of an extra space in an OU field, and several other situations. > Trevor Freeman wrote: >=20 > Life is complicated, but this is not so bad - Isaac Newton's rules > where around a lot longer before they were found to be wrong. > I am still waiting to here further justification (beyond the old > ground of "its in the spec"). and so far you are confirming my > suspicions that there are none. >=20 > -----Original Message----- > From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > Sent: Thursday, June 08, 2000 8:35 AM > To: ietf-pkix@imc.org > Subject: RE: Correct approach to certificate validation? >=20 > Trevor, >=20 > > From: "Trevor Freeman" > > > > David, > > Interoperability is a primary goal, however that is often scarified > by > > standards. It is very easy to produce a document with a set of do's > and > > don'ts without any regard for the previous standard, the impact on > the > > deployed products or how migration is achieved between the old and > new > > standard. It is also unrealistic to think that all products deployed > > would conform to a single standard. Most products have a lifetime of > > years. The interoperability matrix is vast and getting worse every > time > > a new version of a standard is released. > > So to return to the original point, besides citing a 20 year old > clause > > in a standard, and saying we should do it because its in the > standard, > > and requiring administrators to have a faultless record, I have > still > > not hear any reasoned, argument as to what is actually achieved by > this > > behavior. > > No standard or clause in a standard has a divine right of existence. > > Trevor >=20 > On the one hand, you seem to be decrying the ease of producing new > specifications without regard for previous standards and deployed > products. >=20 > On the other, you seem to support discarding a 20 year old clause > in a standard without regard for its impact on deployed products which > have been built according to the standard. >=20 > The "divine right" of any clause comes not from heaven or inheritance, > but from the fact that it has been vetted internationally (in the ISO > and the IETF) over a period of many years. Over that time (whether > it's > 12 or 20 years is immaterial), the requirement that certificates point > to the correct issuer has not only survived, it has not to my > knowledge > been even mildly controversial. Now that there is discussion of > the topic, the requirement will either survive or be discarded based > on international consensus. There is no divine right, just the > stability (inertia?) of a consensus-based standard-setting > process. >=20 > You may present a case that the requirement should be removed from > X.509 > and then from the PKIX profile of X.509. > Or you may choose not to comply with X.509. >=20 > But you can't both ignore the requirement and claim compliance. >=20 > > Certificate discovery is not the issue here. > > > > For certificate discovery, we have a domain push mechanism as well > as > > AIA. We are also adding a lookup by name, and a configurable URL > search > > path i.e. a set of URLs to search (LDAP, HTTP, FTP) >=20 > Certificate discovery *is* the issue. >=20 > If you are adding a "lookup by name" function to your products, > how will that work if certificates do not have correct issuer > names? If I have someone's End Entity certificate, how do I find a > path of CA certs that leads to my trust point (not necessarily the > certificate subject's trust point), in the multi-vendor, > multi-administrative-domain environment of the Internet. >=20 > Products may support many certificate discovery mechanisms, both > standards-based and differentiating. But there needs to be at > least one "Internet" interoperability mode which all products > support. That mode is defined by PKIX: the certificate profile > and the LDAP schema. >=20 > One "Internet mode" mechanism which follows the current PKIX > specifications is for organizations to place public information, > including CA and EE certificates, in border directories, and to link > the border directories together using directory-to-directory chaining, > LDAP referrals, or both. If you propose to eliminate the X.509 > requirement for correct issuer names, you will need to address the > impact on current applications built to the current standards, > as well as the feasability of future applications built to an > amended standard. >=20 > Dave >=20 > P.S. I don't understand why you keep referring to "punishing > administrators" and "requiring administrators to have a flawless > record" and "eliminating imperfection". A CA workstation has its own > signing key and certificate. If the workstation cannot correctly > place > its own name in the issuer field of every certificate it signs, that > is > a product flaw. This X.509 requirement does not hinge upon human > perfectability. ------_=_NextPart_001_01BFD40E.AFF1AEB2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

Al,
There are two players in this piece. CA and relying = parties. THE only point where the name chaining rule can be enforced = reliably is when building a self signed root certificate.

It you are asserting that if by some change a set of = certificate was built where the names did not chain, and that clients = who enforced the name chaining rule would consider the chain invalid, = whereas clients which did not enforce the rule would consider the chain = as valid, then I agree.

What I don't see is justification of the rule as being = necessary.
Why is this rule considered necessary in the = standard?
Trevor

 -----Original Message-----
From:   Al Arsenault [mailto:awa1@home.com]
Sent:   Thursday, June 08, 2000 7:32 = PM
To:     Trevor Freeman
Cc:     David P. Kemp; = ietf-pkix@imc.org
Subject:        = Re: Correct approach to certificate validation?

Trevor,

        Here's the = justification:

        Suppose = that a CA system (by, e.g., Netscape, Entrust, VeriSign,
whomever) has been built to conform to = existing/understood X.509/RFC2459
name chaining rules.  Suppose that such a system = has been deployed for,
oh, say, a large Government department, or a large = corporation, or...

        Now, = suppose that a CA from some other corporation that follows the
rules you suggest - i.e., name chaining doesn't = matter.  We want to
integrate that CA into the existing PKI.  =

        Now, for = whatever reason - human frailty, whatever - that new CA is
used to create a certificate whose distinguish name = is "C=3DAW,
O=3DGovernment, OU=3D Computers, CN=3D CA1", and = then that CA creates user
certs where the issuer name is "C=3DAW, = O=3DGovernment, OU=3DComputer,
CN=3DCA1".  Note that these names are not = equivalent.*

        Suppose = that all other information - AKI, AIA, etc. - is set up
properly.

        Now, = whenever a cert path is validated using the new CA, it will be
validated, because the fact that the end entity = cert's issuer name and
the CA cert's subject name aren't the same doesn't = matter.  However,
whenever that same cert path is validated by a node = in the existing PKI,
validation will fail, because of the name chaining = failure. The notion
of obtaining different results by different points in = the system is
disconcerting, to say the least.

        That's the = reason:  by building your system this way, you cause the
multi-vendor interoperable PKI to fail.  If you = were building your
system to not interoperate with any other existing = products, then I
think we could probably agree that you were right; = there is no real
reason that names have to chain.  However, lots = of people do want your
system to interoperate with other products.  I'm = fairly confident that
Dave wants them to.  I know that in some of the = cases I'm dealing with
now, I need them to.  And they don't.

        =         =         Al = Arsenault
        =         =         Chief Security = Architect
        =         =         Diversinet = Corp.

*And yes, I have seen cases where name chaining failed = - and thus
certificate validation failed when it shouldn't have = - because of a
misplaced comma in a CN field.  I've also seen = it fail because of an
extra space in an OU field, and several other = situations.


> Trevor Freeman wrote:
>
> Life is complicated, but this is not so bad - = Isaac Newton's rules
> where around a lot longer before they were found = to be wrong.
> I am still waiting to here further justification = (beyond the old
> ground of "its in the spec"). and so = far you are confirming my
> suspicions that there are none.
>
>  -----Original Message-----
> From:   David P. Kemp [mailto:dpkemp@missi.ncsc.mil]
> Sent:   Thursday, June 08, 2000 8:35 = AM
> To:     = ietf-pkix@imc.org
> = Subject:        RE: Correct approach = to certificate validation?
>
> Trevor,
>
> > From: "Trevor Freeman" = <trevorf@Exchange.Microsoft.com>
> >
> > David,
> > Interoperability is a primary goal, however = that is often scarified
> by
> > standards. It is very easy to produce a = document with a set of do's
> and
> > don'ts  without any regard for the = previous standard, the impact on
> the
> > deployed products or how migration is = achieved between the old and
> new
> > standard. It is also unrealistic to think = that all products deployed
> > would conform to a single standard. Most = products have a lifetime of
> > years. The interoperability matrix is vast = and getting worse every
> time
> > a new version of  a standard is = released.
> > So to return to the original point, besides = citing a 20 year old
> clause
> > in a standard, and saying we should do it = because its in the
> standard,
> > and requiring administrators to have a = faultless record, I have
> still
> > not hear any reasoned, argument as to what = is actually achieved by
> this
> > behavior.
> > No standard or clause in a standard has a = divine right of existence.
> > Trevor
>
> On the one hand, you seem to be decrying the = ease of producing new
> specifications without regard for previous = standards and deployed
> products.
>
> On the other, you seem to support discarding a = 20 year old clause
> in a standard without regard for its impact on = deployed products which
> have been built according to the = standard.
>
> The "divine right" of any clause comes = not from heaven or inheritance,
> but from the fact that it has been vetted = internationally (in the ISO
> and the IETF) over a period of many years.  = Over that time (whether
> it's
> 12 or 20 years is immaterial), the requirement = that certificates point
> to the correct issuer has not only survived, it = has not to my
> knowledge
> been even mildly controversial.   Now = that there is discussion of
> the topic, the requirement will either survive = or be discarded based
> on international consensus.   There is = no divine right, just the
> stability (inertia?) of a consensus-based = standard-setting
> process.
>
> You may present a case that the requirement = should be removed from
> X.509
> and then from the PKIX profile of X.509.
> Or you may choose not to comply with = X.509.
>
> But you can't both ignore the requirement and = claim compliance.
>
> > Certificate discovery is not the issue = here.
> >
> > For certificate discovery,  we have a = domain push mechanism as well
> as
> > AIA. We are also adding a lookup by name, = and a configurable URL
> search
> > path i.e. a set of URLs to search (LDAP, = HTTP, FTP)
>
> Certificate discovery *is* the issue.
>
> If you are adding a "lookup by name" = function to your products,
> how will that work if certificates do not have = correct issuer
> names?  If I have someone's End Entity = certificate, how do I find a
> path of CA certs that leads to my trust point = (not necessarily the
> certificate subject's trust point), in the = multi-vendor,
> multi-administrative-domain environment of the = Internet.
>
> Products may support many certificate discovery = mechanisms, both
> standards-based and differentiating.  But = there needs to be at
> least one "Internet" interoperability = mode which all products
> support.  That mode is defined by PKIX: the = certificate profile
> and the LDAP schema.
>
> One "Internet mode" mechanism which = follows the current PKIX
> specifications is for organizations to place = public information,
> including CA and EE certificates, in border = directories, and to link
> the border directories together using = directory-to-directory chaining,
> LDAP referrals, or both.  If you propose to = eliminate the X.509
> requirement for correct issuer names, you will = need to address the
> impact on current applications built to the = current standards,
> as well as the feasability of future = applications built to an
> amended standard.
>
> Dave
>
> P.S.  I don't understand why you keep = referring to "punishing
> administrators" and "requiring = administrators to have a flawless
> record" and "eliminating = imperfection".  A CA workstation has its own
> signing key and certificate.  If the = workstation cannot correctly
> place
> its own name in the issuer field of every = certificate it signs, that
> is
> a product flaw.  This X.509 requirement = does not hinge upon human
> perfectability.

------_=_NextPart_001_01BFD40E.AFF1AEB2-- From owner-ietf-pkix@imc.org Mon Jun 12 10:50:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03140 for ; Mon, 12 Jun 2000 10:50:29 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA03333; Mon, 12 Jun 2000 07:42:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jun 2000 07:41:59 -0700 Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03289 for ; Mon, 12 Jun 2000 07:41:58 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 10:40:52 -0400 Message-ID: From: Sharon Boeyen To: "'500 list'" Cc: "'ietf-pkix@imc.org'" , "'pki-twg@nist.gov'" , "'Hoyt Kesterson'" Subject: New X.509 defect report Date: Mon, 12 Jun 2000 10:40:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a new defect report against X.509 (1997 and 2000 editions). It emerged from the US Bridge CA project participants and indicates that text regarding handling of non-critical extensions has flaws and needs to be fixed. I'm submitting this defect report but it represents the result of discussion that occured among the Bridge CA project participants. Also, I apologize for not including a defect report number but Hoyt is away and I was unable to reach him to get one. Hoyt, can you tell us what DR number this will be? Sharon DEFECT REPORT FORM 1. Defect Report Number: 9594/XXX Title: Handling non-critical extensions 2. Source: X.509 Editor (on behalf of US Bridge CA project participants) 3. Addressed to: 4. (a) (b) 5. Date circulated by WG Secretariat: 6. Deadline for Response from Editor: 7. Defect Report Concerning: ITU-T X.509 (1997 and 2000 editions) | ISO/IEC 9594-8:1997 and 2000 editions 8. Qualifier: Error/Clarification 9. References in Document: Several, See solution proposed by source 10. Nature of Defect: X.509 clearly states what a certificate-using system is do in the case where certificate extensions are present and are are flagged critical. It also clearly states what a certificate-using system is to do in the case where certificate extensions are present, flagged non-critical, but are not recognized by a certificate-using system. However, there are errors, ambiguities and omissions about what a certificate-using system is to do when encountering a certificate extension flagged non-critical, that it does recognize and is capable of processing. To ensure that the requirements of certificate and CRL issuers, as well as requirements for consistent treatment of extensions by certificate-using systems, these errors must be fixed. 11. Solution Proposed by the Source: In ITU-T Rec. X.509 and ISO/IEC 9594-8: Change 1: In 1997 edition clause 8 and 2000 edition clause 7: In the paragraph that begins "The extensions field allows addition of new ...", add the following two sentences to the end of the paragraph: " When a certificate-using implementation recognizes and is able to process an extension, then the certificate-using implementation shall process the extension regardless of the value of the criticality flag. Note that any extension that is flagged non-critical will cause inconsistent behaviour between certificate-using systems that will process the extension and certificate-using that do not recognize the extension and will ignore it." Change 2: In 1997 edition clause 8 and 2000 edition clause 7: Add the following immediately after the paragraph that begins "If unknown elements appear within the extension ...": A CA has three options with respect to an extension: i) it can exclude the extension from the certificate; ii) it can include the extension and flag it non-critical; iii) it can include the extension and flag it critical. A validation engine has two possible actions to take with respect to an extension: i) it can ignore the extension and accept the certificate (all other things being equal); ii) it can process the extension and accept or reject the certificate depending on the content of the extension and the conditions under which processing is occuring (e.g. the current values of the path processing variables). Some extensions can ONLY be marked critical. In these cases a validation engine that understands the extension, processes it and acceptance/rejection of the certificate is dependent (at least in part) on the content of the extension. A validation engine that does not understand the extension rejects the certificate. Some extensions can ONLY be marked non-critical. In these cases a validation engine that understands the extension processes it and acceptance/rejection of the certificate is dependent (at least in part) on the content of the extension. A validation engine that does not understand the extension accepts the certificate (unless factors other than this extension cause it to be rejected). Some extensions can be marked critical or non-critical. In these cases a validation engine that understands the extension processes it and acceptance/rejection of the certificate is dependent (at least in part) on the content of the extension, regardless of the criticality flag. A validation engine that does not understand the extension accepts the certificate if the extension is marked non-critical (unless factors other than this extension cause it to be rejected) and rejects the certificate if the extension is marked critical. When a CA considers including an extension in a certificate it does so with the expectation that its intent will be adhered to wherever possible. If it is necessary that the content of the extension be considered prior to ANY reliance on the certificate, a CA would flag the extension critical. This must be done with the realization that any validation engine that does not process the extension will reject the certificate (probably limiting the set of applications that can verify the certificate). The a CA may mark certain extensions non-critical to achieve backward compatibility with validation applications that cannot process the extensions. Where the need for backward compatibility and interoperability with validation applications incapable of processing the extensions is more vital than the ability of the CA to enforce the extensions, then these optionally critical extensions would be marked non-critical. It is most likely that CAs would set optionally critical extensions as non-critical during a transition period while the verifiers' certificate processing applications are upgraded to ones that can process the extensions. Change 3: In 1997 edition clause 12.1 and 2000 edition clause 8: In the paragraph that begins "In a certificate or CRL, an extension is flagged ...", add the following immediately after the third sentence that ends with "...ignoring the extension": " If an extension is flagged non-critical, a certificate-using system that does recognize the extension, shall process the extension." Change 4: In 1997 edition clause 12.2.2.3 and 2000 edition clause 8.2.2.3: In the paragraph that begins "If the extension is flagged non-critical ...", replace the second sentence with the following: "If this extension is present, and the certificate-using system recognizes and processes the keyUsage extension type, then the certificate using system shall ensure that the certificate shall be used only for a purpose for which the corresponding key usage bit is set to one." Change 5: In 1997 edition clause 12.2.2.4 and 2000 edition clause 8.2.2.4: In the paragraph that begins "If the extension is flagged non-critical ...", replace the second and third sentences with the following: "If this extension is present, and the certificate-using system recognizes and processes the extendedKeyUsage extension type, then the certificate using system shall ensure that the certificate shall be used only for one of the purposes indicated." Change 6: In 1997 edition clause 12.4.2.1 and 2000 edition clause 8.4.2.1: In the 4th paragraph following the ASN.1, replace: "If this extension is present and is flagged critical then:" with the following: "If this extension is present and is flagged critical, or is flagged non-critical but is recognized by the certificate-using system, then:" Change 7: In 1997 edition clause 12.4.2.2 and 2000 edition clause 8.4.2.2: Replace the last sentence "If this extension is present and is flagged critical ..." with the following: "If this extension is present and is flagged critical, or is flagged non-critical but is recognized by the certificate-using system, then the certificate-using system shall check that the certification path being processed is consistent with the value in this extension." 12. Editor's Response: tbd Sharon Boeyen Entrust Technologies sharon.boeyen@entrust.com From owner-ietf-pkix@imc.org Mon Jun 12 11:05:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03546 for ; Mon, 12 Jun 2000 11:05:58 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA04139; Mon, 12 Jun 2000 08:05:38 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jun 2000 08:05:26 -0700 Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04109 for ; Mon, 12 Jun 2000 08:05:26 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 11:04:20 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C001558BF0@wfhqex01.wangfed.com> From: "Pawling, John" To: "'Sharon Boeyen'" , "'500 list'" Cc: "'ietf-pkix@imc.org'" , "'pki-twg@nist.gov'" , "'Hoyt Kesterson'" Subject: RE: New X.509 defect is 244 Date: Mon, 12 Jun 2000 11:04:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe All, I strongly agree with the solutions proposed in X.509 defect report 244. These changes are important to ensure that certification path verification implementations process all non-critical extensions that they recognize and are capable of processing. ============================================ John Pawling, john.pawling@wang.com Wang Government Services, Inc., A Getronics Company ============================================ From owner-ietf-pkix@imc.org Mon Jun 12 11:08:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03579 for ; Mon, 12 Jun 2000 11:08:32 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA03840; Mon, 12 Jun 2000 07:59:41 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jun 2000 07:59:29 -0700 Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03803 for ; Mon, 12 Jun 2000 07:59:28 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 10:58:22 -0400 Message-ID: From: Sharon Boeyen To: "'500 list'" Cc: "'ietf-pkix@imc.org'" , "'pki-twg@nist.gov'" , "'Hoyt Kesterson'" Subject: RE: New X.509 defect is 244 Date: Mon, 12 Jun 2000 10:58:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Oops, we were actually more efficient that I thought. I did get the defect report number from Hoyt before I went on vacation. This is defect report number 244. (Note that we may also probably should look at the conformance statements in X.519 and, duplicate appropriate material in 509 itself so that it can stand alone. > -----Original Message----- > From: Sharon Boeyen > Sent: Monday, June 12, 2000 10:41 AM > To: '500 list' > Cc: 'ietf-pkix@imc.org'; 'pki-twg@nist.gov'; 'Hoyt Kesterson' > Subject: New X.509 defect report > > > This is a new defect report against X.509 (1997 and 2000 > editions). It > emerged from the US Bridge CA project participants and indicates that > text regarding handling of non-critical extensions has flaws > and needs > to be fixed. > > I'm submitting this defect report but it represents the result of > discussion that occured among the Bridge CA project participants. > > Also, I apologize for not including a defect report number but Hoyt > is away and I was unable to reach him to get one. > > Hoyt, can you tell us what DR number this will be? > > Sharon > > > DEFECT REPORT FORM > > 1. Defect Report Number: 9594/XXX > > > Title: Handling non-critical extensions > > 2. Source: X.509 Editor (on behalf of US Bridge CA project > participants) > > 3. Addressed to: > 4. (a) > (b) > > 5. Date circulated by WG Secretariat: > > 6. Deadline for Response from Editor: > > 7. Defect Report Concerning: > > ITU-T X.509 (1997 and 2000 editions) | ISO/IEC 9594-8:1997 > and 2000 editions > > 8. Qualifier: > > Error/Clarification > > 9. References in Document: > > Several, See solution proposed by source > > 10. Nature of Defect: > > X.509 clearly states what a certificate-using > system is do in the case where certificate extensions are present and > are are flagged critical. It also clearly states what a > certificate-using > system is to do in the case where certificate extensions are > present, flagged > non-critical, but are not recognized by a certificate-using > system. However, > there are errors, ambiguities and omissions about what a > certificate-using system > is to do when encountering a certificate extension flagged > non-critical, that it > does recognize and is capable of processing. To ensure that > the requirements of > certificate and CRL issuers, as well as requirements for > consistent treatment > of extensions by certificate-using systems, these errors must > be fixed. > > > 11. Solution Proposed by the Source: > > In ITU-T Rec. X.509 and ISO/IEC 9594-8: > > Change 1: In 1997 edition clause 8 and 2000 edition clause 7: > > In the paragraph that begins "The extensions field allows > addition of new ...", > add the following two sentences to the end of the paragraph: > > " When a certificate-using implementation recognizes and is > able to process an extension, then > the certificate-using implementation shall process the > extension regardless of the value > of the criticality flag. Note that any extension that is > flagged non-critical will cause > inconsistent behaviour between certificate-using systems that > will process the extension and > certificate-using that do not recognize the extension and > will ignore it." > > Change 2: In 1997 edition clause 8 and 2000 edition clause 7: > > Add the following immediately after the paragraph that begins "If > unknown elements appear within the extension ...": > > A CA has three options with respect to an extension: > i) it can exclude the extension from the certificate; > ii) it can include the extension and flag it non-critical; > iii) it can include the extension and flag it critical. > > A validation engine has two possible actions to take with > respect to an extension: > i) it can ignore the extension and accept the certificate > (all other things being equal); > ii) it can process the extension and accept or reject the > certificate depending on the > content of the extension and the conditions under which > processing is occuring > (e.g. the current values of the path processing variables). > > Some extensions can ONLY be marked critical. In these cases a > validation engine that > understands the extension, processes it and > acceptance/rejection of the certificate > is dependent (at least in part) on the content of the > extension. A validation engine > that does not understand the extension rejects the certificate. > > Some extensions can ONLY be marked non-critical. In these > cases a validation engine that > understands the extension processes it and > acceptance/rejection of the certificate is > dependent (at least in part) on the content of the extension. > A validation engine that > does not understand the extension accepts the certificate > (unless factors other than > this extension cause it to be rejected). > > Some extensions can be marked critical or non-critical. In > these cases a validation engine > that understands the extension processes it and > acceptance/rejection of the certificate is > dependent (at least in part) on the content of the extension, > regardless of the criticality > flag. A validation engine that does not understand the > extension accepts the certificate if > the extension is marked non-critical (unless factors other > than this extension cause it to > be rejected) and rejects the certificate if the extension is > marked critical. > > When a CA considers including an extension in a certificate > it does so with > the expectation that its intent will be adhered to wherever > possible. If it > is necessary that the content of the extension be considered > prior to ANY > reliance on the certificate, a CA would flag the extension > critical. This > must be done with the realization that any validation engine > that does not > process the extension will reject the certificate (probably > limiting the set > of applications that can verify the certificate). The a CA > may mark certain > extensions non-critical to achieve backward compatibility > with validation > applications that cannot process the extensions. Where the > need for backward > compatibility and interoperability with validation > applications incapable of > processing the extensions is more vital than the ability of the CA to > enforce the extensions, then these optionally critical > extensions would be > marked non-critical. It is most likely that CAs would set > optionally critical > extensions as non-critical during a transition period while > the verifiers' > certificate processing applications are upgraded to ones that > can process the > extensions. > > Change 3: In 1997 edition clause 12.1 and 2000 edition clause 8: > > In the paragraph that begins "In a certificate or CRL, an > extension is flagged ...", > add the following immediately after the third sentence that > ends with "...ignoring > the extension": > > " If an extension is flagged non-critical, a > certificate-using system that does > recognize the extension, shall process the extension." > > Change 4: In 1997 edition clause 12.2.2.3 and 2000 edition > clause 8.2.2.3: > > In the paragraph that begins "If the extension is flagged > non-critical ...", replace > the second sentence with the following: > > "If this extension is present, and the certificate-using > system recognizes and processes > the keyUsage extension type, then the certificate using > system shall ensure that the > certificate shall be used only for a purpose for which the > corresponding key usage > bit is set to one." > > Change 5: In 1997 edition clause 12.2.2.4 and 2000 edition > clause 8.2.2.4: > > In the paragraph that begins "If the extension is flagged > non-critical ...", replace > the second and third sentences with the following: > > "If this extension is present, and the certificate-using > system recognizes and processes > the extendedKeyUsage extension type, then the certificate > using system shall ensure that the > certificate shall be used only for one of the purposes indicated." > > Change 6: In 1997 edition clause 12.4.2.1 and 2000 edition > clause 8.4.2.1: > > In the 4th paragraph following the ASN.1, replace: > "If this extension is present and is flagged critical then:" > with the following: > "If this extension is present and is flagged critical, or is > flagged non-critical but is > recognized by the certificate-using system, then:" > > Change 7: In 1997 edition clause 12.4.2.2 and 2000 edition > clause 8.4.2.2: > > Replace the last sentence "If this extension is present and > is flagged critical ..." with the > following: > > "If this extension is present and is flagged critical, or is > flagged non-critical but > is recognized by the certificate-using system, then the > certificate-using system shall > check that the certification path being processed is > consistent with the value in this > extension." > > > > 12. Editor's Response: > > tbd > > > > Sharon Boeyen > Entrust Technologies > sharon.boeyen@entrust.com > From owner-ietf-pkix@imc.org Mon Jun 12 16:26:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10609 for ; Mon, 12 Jun 2000 16:26:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA14778; Mon, 12 Jun 2000 13:24:02 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jun 2000 13:23:40 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14744 for ; Mon, 12 Jun 2000 13:23:40 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA02664; Mon, 12 Jun 2000 16:23:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39412146.B5FC28EB@nma.com> References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <39412146.B5FC28EB@nma.com> Date: Mon, 12 Jun 2000 16:17:56 -0400 To: Ed Gerck From: Stephen Kent Subject: Re: Correct approach to certificate validation? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Ed, >Stephen Kent wrote: > > > Ed, > > >List: > > > > > >Why should we continue to confuse name validation with > > >certificate validation? Name chaining should be optional IMO, > > >not expected behavior. 'Be liberal in what you expect' can be > > >applied here without A N Y decrease in cryptographic > > >authentication security. > > > > > > > Jon's protocol design advice is good in general, but inappropriate in > > security contexts, where liberal acceptance policies often lead to > > vulnerabilities. > >In this case, however, I see no vulnerability in what X.509/PKIX >intend to provide -- a cryptographic authentication protocol. In >regard to name assignment vulnerabilities, I note that this is also >declared out of scope in X.509/PKIX and delegated to the CA/NA >+ CPS. My observation about the applicability of Jon's admonition to security protocols in general is true. So far we don't have a killer example of a new vulnerability created by this deviation from the standards, just user confusion. Someone suggested to me that if a user is examining the CA names in a path to make a trust judgement, then this inconsistency might cause the user to make a wrong trust decision. I don't know if this is critical, because I doubt that many users would be so diligent, but it is an example of what might happen. You state that our standards do not address name assignment vulnerabilities; we'll PKIX is trying to do this to some extent. There was already some text about a CA's responsibility to verify name data in a cert, although that must be qualified by the CPS/policy. As others have pointed out, there is a fine line here. We don't want to usurp the CA's options here, yet we want to make a general statement about what an RP can expect in a cert. >So, why should that which is declared out of scope trump that >which is the only thing that the protocol verifies? Logic would >indicate that since name validation by name chaining verification >is a weaker concept than the one it is blocking, then this should >not be mandatory behavior. Making it mandatory is what is >confusing, IMO. We disagree on fundamentals here. Name verification in the context of chaining is what one would expect from reading ANY description of X.509 certificates for over a decade and a half. There should be a very good reason to NOT do it before such a deviation from the standards is considered reasonable. Steve From owner-ietf-pkix@imc.org Mon Jun 12 18:17:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12229 for ; Mon, 12 Jun 2000 18:17:38 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA16888; Mon, 12 Jun 2000 15:16:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jun 2000 15:15:55 -0700 Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16857 for ; Mon, 12 Jun 2000 15:15:53 -0700 (PDT) Received: from [128.33.238.77] (TC077.BBN.COM [128.33.238.77]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id SAA25418; Mon, 12 Jun 2000 18:14:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 12 Jun 2000 17:36:35 -0400 To: "Trevor Freeman" From: Stephen Kent Subject: RE: Correct approach to certificate validation? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Trevor, >Steve, >With the Internet today, if you are relying on directory lookup >based on a DN as you only solution to certificate discovery - I >think you will be disappointed. There will be "communities" who will >be able to get this to work, but there is no sign of a universal >solution equivalent to DNS where I can take any DN and find an >object in a directory with that name. Therefore failure to find a >certificate based on a issuer DN in a certificate is a reality that >will have to be dealt with - for much more fundamental reasons. In general I agree if we're talking about most DNs, and that's why I alluded to use of AIA. But, if one used DC-based DNs, we could leverage the DNS and that would be very powerful. So, for those who might choose to rely on this or analogous discovery approaches, mismatches between CA names in subject and issuer fields would pose a problem. Facilitating an environment in which such mismatches are tolerated by client software undermines the efforts of those who might be trying to use CA DNs for repository discovery. > >There are a couple of instances of by design behavior that have been >presented to me. There are mergers and acquisitions where names and >affiliation are changing. There are also instances where one CA does >not want to endorse the name of another when it cross certifies. The first example does not seem very good; as someone else noted, I would want to reissue the EE certs as much as I want to change the CA cert. I've gone through a bunch of business cards over the last few years as we wer bought, reorganized, bought again, etc. > >The search path mechanism is very similar to AIA, in that given a >set of URLs, you can access the URL looking for certificates. With >LDAP URLs, it's not difficult to construct a generic query. With >other, the underlying assumption is that you find a pkcs#7. The "algorithm" you allude to seems a bit squishy :-), and its scaling features are not at all clear. Steve From owner-ietf-pkix@imc.org Mon Jun 12 18:18:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12240 for ; Mon, 12 Jun 2000 18:18:08 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA17021; Mon, 12 Jun 2000 15:16:43 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jun 2000 15:16:41 -0700 Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16991 for ; Mon, 12 Jun 2000 15:16:41 -0700 (PDT) Received: from [128.33.238.77] (TC077.BBN.COM [128.33.238.77]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id SAA25645; Mon, 12 Jun 2000 18:15:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <024701bfd22b$f50eae70$eb0f970a@lon-williamb.intra> References: <024701bfd22b$f50eae70$eb0f970a@lon-williamb.intra> Date: Mon, 12 Jun 2000 17:56:30 -0400 To: "william bamberg" From: Stephen Kent Subject: Re: HTTP over TLS: dNSName syntax question Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Will, >Sorry if this is marginally off topic, but I'd like to know people's >opinions... > >RFC 2818, 'HTTP over TLS', Section 3.1, 'Server Identity' describes how to >compare the name in the server's certificate with the server domain name: > >'If a subjectAltName extension of type dNSName is present, that MUST be used >as the identity. Otherwise, the (most specific) Common Name field in the >Subject field of the certificate MUST be used...Matching is performed using >the matching rules specified by [RFC2459].' > >RFC 2459 says that the dNSName 'MUST be in the "preferred name syntax," as >specified by RFC 1034.' > >So, presumably the matching here is performed by comparing every subdomain >in the dNSName against the corresponding subdomain in the server's domain >name. > >But RFC 2818 goes on to say that 'Names may contain the wildcard character >*' >and goes on to specify how these names should be handled. > >The 'preferred name syntax' says nothing about wildcards, so my question >really is, how can the dNSName component both be represented according to >the 'preferred name syntax', and contain wildcards? RFC 2459 does not allow wildcards in the dNSname attribute, as that would result in strings that are NOT DNS names. The 2818 text refers to an historic convention employed when CAs put DNS names in the CN field of a DN. In fact, the text you cite refers to this convention (that is disparaged in 2459). Note the reference to "Common Name" in that text. So, it seems that the 2818 text is a bit schizophrenic, based on what you say above. (I have not read 2818, so I am taking your word for the relevant quote.) Steve From owner-ietf-pkix@imc.org Mon Jun 12 18:18:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12251 for ; Mon, 12 Jun 2000 18:18:15 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA16931; Mon, 12 Jun 2000 15:16:05 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jun 2000 15:16:03 -0700 Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16893 for ; Mon, 12 Jun 2000 15:16:02 -0700 (PDT) Received: from [128.33.238.77] (TC077.BBN.COM [128.33.238.77]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id SAA25553; Mon, 12 Jun 2000 18:15:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <39415C00.773D4669@nma.com> References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> <3941320A.6D65328A@celocom.com> <39415C00.773D4669@nma.com> Date: Mon, 12 Jun 2000 17:44:58 -0400 To: Ed Gerck From: Stephen Kent Subject: Re: Correct approach to certificate validation? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Ed, >Oscar Jacobsson wrote: > > > Ed Gerck wrote: > > > So, now the name should trump the key? The tail wants to wag the > > > dog, we may as well say. > > > > > However: if constraints are placed on subject names, they are most > > probably placed there for a reason. Ignoring said constraints, having > > been deemed important enough to distribute signed and in-band, could > > surely hardly be considered prudent? > >A checkbox with "Enforce name chaining" could take care of all cases >where name chaining is desired, much in the same way that the depth >of certificate signing can also be chosen by the user in Apache SSL for >example (or, do you really must trust a CA you don't trust just because it >chains with a CA you trust? -- maybe, possibly not). Based on this approach we could make all aspects of cert processing user selectable options. But, that's not what we have done. We have divided processing rules into those that are uniformly enforced (in principle), those under CA control, and those under user control. Given the difficulty of getting local configuration info right, it's preferable to minimize this last set. >Making name chaining mandatory, OTOH, still does not mean that >the name is: (i) correct, (ii) valid, (iii) legal, (iv) unique, etc. So, >if constraints are placed on names this is still much weaker than the >nonce authentication constraints placed on keys -- where a principal >must have had use of the private-key in order to sign a nonce. They >are like apples and speedboats, names and keys. Why then should we >not differentiate between name validation and certificate validation? >Cert validation may include name validation but not necessarily and >there is no cryptographic value to be gained thereby. Nonce? What syntax are you referring to? Ed, we've all had the pleasure of your efforts to redefine X.509 on an ab initio basis. Please spare us a repeat of such efforts again. >Of course, some years ago everything was quite undifferentiated and >there was no distinction between different functions which we now >perceive as distinct. For example, the CA and the NA roles -- as well as >the CA and the TTP roles. the concept of a naming authority (vs. a CA or a directory service provider) have been recognized in the directory community that begat X.509, probably for about 15 years. But, some of the names spaces we use, including DNs, don't have universally recognized NAs, so the concept is not universally applicable. CAs vs. TTPs? I still think that a TTP is just one form of CA, so what's the issue here? Steve From owner-ietf-pkix@imc.org Mon Jun 12 20:30:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13498 for ; Mon, 12 Jun 2000 20:30:31 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA19288; Mon, 12 Jun 2000 17:29:07 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jun 2000 17:28:34 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19256 for ; Mon, 12 Jun 2000 17:28:30 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA21264; Tue, 13 Jun 2000 10:32:37 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Jun 2000 10:26:46 +1000 Message-ID: From: Michael Zolotarev To: Martin Szotkowski , ietf-pkix@imc.org Subject: RE: TSA signing key? Date: Tue, 13 Jun 2000 10:26:45 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Martin, Not allowing using the same cert for CA and TSA is simply a matter of clearly specifying what a TTP is doing. An entity claiming that it is a TSA (by putting a special value of extKeyUsage flag), accepts certain legal responsibilities which makes it distinct in the PKI world. The responsibilities of CA are 100% different from those of TSA, and you would not generally expect the same physical(!) entity to operate as both a CA and a TSA. A CA which signs a TSA cert (if it is not a self-signed), is expected to perform a diligent check that the subject (TSA) complies to whatever a TSA must be compliant to. For those very reasons, as a verifier of a timestamp, I'd never trust a TSA cert which does not have the extKeyUsage set to "timestamping", and I would be very suspicious about a TSA cert which has both "timestamping" and "CA" flags set. Also, in a TSA cert there may be certain extensions specific to TSA only. And there are heaps of CA-specific extensions too. Mixing them in one certificate will be just messy and more than confusing. If a CA organisation wants to run a TSA, it won't be a problem to issue a dedicated cert for the TSS, be it a self-signed or a CA-signed certificate. Hope it answered your question. Regards Michael > -----Original Message----- > From: Martin Szotkowski [mailto:martin.szotkowski@ica.cz] > Sent: Saturday, June 10, 2000 3:00 AM > To: ietf-pkix@imc.org > Subject: TSA signing key? > > > In draft is written that TSA cert must be used exclusively > for time stamp. > Why TSA certificate cann't be same as CA certificate? > > thanks Martin > From owner-ietf-pkix@imc.org Mon Jun 12 21:02:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13893 for ; Mon, 12 Jun 2000 21:02:49 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA19814; Mon, 12 Jun 2000 17:59:11 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 12 Jun 2000 17:59:08 -0700 Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA19784 for ; Mon, 12 Jun 2000 17:59:07 -0700 (PDT) Received: (qmail 1501 invoked from network); 13 Jun 2000 00:58:24 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 13 Jun 2000 00:58:24 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Mon, 12 Jun 2000 19:58:20 -0500 Message-ID: <3945872C.3ABDCA0@nma.com> Date: Mon, 12 Jun 2000 17:58:20 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Ed Gerck , ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> <3941320A.6D65328A@celocom.com> <39415C00.773D4669@nma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Stephen Kent wrote: > Ed Gerck wrote: > >A checkbox with "Enforce name chaining" could take care of all cases > >where name chaining is desired, much in the same way that the depth > >of certificate signing can also be chosen by the user in Apache SSL for > >example (or, do you really must trust a CA you don't trust just because it > >chains with a CA you trust? -- maybe, possibly not). > > Based on this approach we could make all aspects of cert processing > user selectable options. No, this is not what I say -- this would be using my words to an extreme limit where they are obviously false and never intended to apply, with the intent to "prove them wrong." However, anything is wrong if taken out of context. If we stay with the case at hand and don' try to outwit the argument by such tricks, then we could recognize that there are cases where a "one size fits all" does not apply. Name chaining is, I suggest, one such case. Again, this does NOT mean that ALL cases are like it. The name PKIX, for example, should not be optional ;-) > >Making name chaining mandatory, OTOH, still does not mean that > >the name is: (i) correct, (ii) valid, (iii) legal, (iv) unique, etc. So, > >if constraints are placed on names this is still much weaker than the > >nonce authentication constraints placed on keys -- where a principal > >must have had use of the private-key in order to sign a nonce. They > >are like apples and speedboats, names and keys. Why then should we > >not differentiate between name validation and certificate validation? > >Cert validation may include name validation but not necessarily and > >there is no cryptographic value to be gained thereby. > > Nonce? What syntax are you referring to? Ed, we've all had the > pleasure of your efforts to redefine X.509 on an ab initio basis. > Please spare us a repeat of such efforts again. I recall much of my efforts have been in the direction of avoding that some, including oftentimes you, would needlessly redefine X.509. For example, as I showed in my analysis of "non-repudiation" as it occurs in the X.509 text itself, in contrast to what was being defined in PKIX. Now, if that discussion left some sour tones as I see between the lines in your text above, please recall that this is an open group based on consensus and that there are no "winners" or "losers" here -- except our loss of time to go back to that which is already closed. Unless, of course, you think that there was something in your arguments then which were not clearly understood by this WG. Regarding the term "nonce" -- in cryptography, "nonce" is a value used no more than once for the same purpose. In X.509, you will find it under the designation "a non-repeating number" when "strong authentication" is defined. To avoid confusion and nitpicking, this what I said above: ...if constraints are placed on names this is still much weaker than the strong authentication constraints placed on keys -- where a principal must have had use of the private-key in order to sign the non-repeating number. They are like apples and speedboats, names and keys. Why then should we not differentiate between name validation and certificate validation? Cert validation may include name validation but not necessarily and there is no cryptographic value to be gained thereby. > >Of course, some years ago everything was quite undifferentiated and > >there was no distinction between different functions which we now > >perceive as distinct. For example, the CA and the NA roles -- as well as > >the CA and the TTP roles. > > the concept of a naming authority (vs. a CA or a directory service > provider) have been recognized in the directory community that begat > X.509, probably for about 15 years. But, some of the names spaces we > use, including DNs, don't have universally recognized NAs, so the > concept is not universally applicable. CAs vs. TTPs? I still think > that a TTP is just one form of CA, so what's the issue here? As you have shown with your own words, some issues do have more than one universally recognized answer. Thus, where there is no bad security consequence the standard must recognize them. Cheers, Ed Gerck From owner-ietf-pkix@imc.org Tue Jun 13 11:18:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11295 for ; Tue, 13 Jun 2000 11:18:10 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA22188; Tue, 13 Jun 2000 08:17:06 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jun 2000 08:15:55 -0700 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22064 for ; Tue, 13 Jun 2000 08:15:54 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA116010; Tue, 13 Jun 2000 17:18:21 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA40022; Tue, 13 Jun 2000 17:14:39 +0200 Message-ID: <39464FE0.60CFF540@bull.net> Date: Tue, 13 Jun 2000 17:14:40 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Martin Szotkowski CC: ietf-pkix@imc.org Subject: Re: TSA signing key? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> <164901bfd234$2cb1b7c0$0c7011ac@SZOTKOWSKI> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Martin, I guess that they are several arguments for that. Let me give one. This allows you to build a black box, to place the TSA private key in it and then to close the box, only making sure that the clock inside is still synchronized with UTC (with respect to the accuracy that is guaranted by the TSA). If not, the box shall stop working. The private key will not be used for signing anything else which would require a management interface. If the implementation is poor, this management interface could possibly be used to sign, e.g. a wrong token. :-( Denis > In draft is written that TSA cert must be used exclusively for time stamp. > Why TSA certificate cann't be same as CA certificate? > > thanks Martin From owner-ietf-pkix@imc.org Tue Jun 13 11:25:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11699 for ; Tue, 13 Jun 2000 11:25:32 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA22852; Tue, 13 Jun 2000 08:24:58 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jun 2000 08:24:46 -0700 Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22813 for ; Tue, 13 Jun 2000 08:24:45 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQitkn26901; Tue, 13 Jun 2000 15:24:06 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA14649; Tue, 13 Jun 00 11:20:29 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA07114; Tue, 13 Jun 2000 11:24:05 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14662.21012.864694.380020@xedia.com> Date: Tue, 13 Jun 2000 11:24:04 -0400 (EDT) To: Denis.Pinkas@bull.net Cc: martin.szotkowski@ica.cz, ietf-pkix@imc.org Subject: Re: TSA signing key? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> <164901bfd234$2cb1b7c0$0c7011ac@SZOTKOWSKI> <39464FE0.60CFF540@bull.net> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit >>>>> "Denis" == Denis Pinkas writes: Denis> Martin, Denis> I guess that they are several arguments for that. Let me give Denis> one. Denis> This allows you to build a black box, to place the TSA private Denis> key in it and then to close the box, only making sure that the Denis> clock inside is still synchronized with UTC (with respect to Denis> the accuracy that is guaranted by the TSA). If not, the box Denis> shall stop working. The private key will not be used for Denis> signing anything else which would require a management Denis> interface. If the implementation is poor, this management Denis> interface could possibly be used to sign, e.g. a wrong Denis> token. :-( >> In draft is written that TSA cert must be used exclusively for >> time stamp. Why TSA certificate cann't be same as CA certificate? If the intent is that the *key* should not be used for other purposes, it should say that -- restricting the cert doesn't necessarily constrain the use of the key. paul From owner-ietf-pkix@imc.org Tue Jun 13 11:43:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12311 for ; Tue, 13 Jun 2000 11:43:12 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA23949; Tue, 13 Jun 2000 08:40:46 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 13 Jun 2000 08:40:33 -0700 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23906 for ; Tue, 13 Jun 2000 08:40:32 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA105958; Tue, 13 Jun 2000 17:43:07 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA37834; Tue, 13 Jun 2000 17:39:28 +0200 Message-ID: <394655B0.33640501@bull.net> Date: Tue, 13 Jun 2000 17:39:28 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Paul Koning CC: martin.szotkowski@ica.cz, ietf-pkix@imc.org Subject: Re: TSA signing key? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> <164901bfd234$2cb1b7c0$0c7011ac@SZOTKOWSKI> <39464FE0.60CFF540@bull.net> <14662.21012.864694.380020@xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Paul, Please, before answering, take a look at the document: 10. to sign each time stamp token using a key generated exclusively for this purpose and have this property of the key indicated on the corresponding certificate. Denis > >>>>> "Denis" == Denis Pinkas writes: > > Denis> Martin, > > Denis> I guess that they are several arguments for that. Let me give > Denis> one. > > Denis> This allows you to build a black box, to place the TSA private > Denis> key in it and then to close the box, only making sure that the > Denis> clock inside is still synchronized with UTC (with respect to > Denis> the accuracy that is guaranted by the TSA). If not, the box > Denis> shall stop working. The private key will not be used for > Denis> signing anything else which would require a management > Denis> interface. If the implementation is poor, this management > Denis> interface could possibly be used to sign, e.g. a wrong > Denis> token. :-( > > >> In draft is written that TSA cert must be used exclusively for > >> time stamp. Why TSA certificate cann't be same as CA certificate? > > If the intent is that the *key* should not be used for other purposes, > it should say that -- restricting the cert doesn't necessarily > constrain the use of the key. > > paul From owner-ietf-pkix@imc.org Wed Jun 14 03:41:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13752 for ; Wed, 14 Jun 2000 03:41:54 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA13584; Wed, 14 Jun 2000 00:37:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jun 2000 00:36:27 -0700 Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13515 for ; Wed, 14 Jun 2000 00:36:21 -0700 (PDT) Received: from [38.29.123.149] (ip180.phoenix11.az.pub-ip.psi.net [38.29.123.180]) by snipe.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id AAA24302; Wed, 14 Jun 2000 00:35:06 -0700 (PDT) Mime-Version: 1.0 X-Sender: hoytkesterson@mail.earthlink.net Message-Id: Date: Wed, 14 Jun 2000 00:34:45 -0700 To: OSI Directory List , ietf-pkix@imc.org, ABA Information Security Committee From: "Hoyt L. Kesterson II" Subject: a new revision of the 4th edition of x.509 is on the server Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe we have recently made a critical fix to x.509. a ballot comment was not accurately captured in the text. the revised text has been placed on the server as ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV4.doc ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV4.pdf the change is to clause 15.1.2.2 Targeting information extension Replace the 6th paragraph following the ASN.1, that currently reads "This extension is always non-critical." with "This extension is always critical." this is likely to be the last change to the text before it ballots in ISO/IEC as a Final Draft International Standard. Once that ballot completes (a yes/no) and the standard can be purchased, this version will be removed from this server. hoyt From owner-ietf-pkix@imc.org Wed Jun 14 05:06:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14493 for ; Wed, 14 Jun 2000 05:06:32 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA21822; Wed, 14 Jun 2000 02:06:13 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jun 2000 02:05:57 -0700 Received: from mta02-svc.server.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA21789 for ; Wed, 14 Jun 2000 02:05:55 -0700 (PDT) Received: from darxstar ([62.252.198.118]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000614100502.HQVN10065.mta02-svc.server.ntlworld.com@darxstar> for ; Wed, 14 Jun 2000 10:05:02 +0000 Message-ID: <002101bfd5df$c2173f70$76c6fc3e@darxstar> From: "Christopher Williams" To: "PKIX Mailing List" Subject: Are there any TSAs out there? Date: Wed, 14 Jun 2000 10:00:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Does anybody know of any commercial / free implementations of Time Stamp Protocol server software? Christopher Williams Software engineer, NetLexis Ltd. Solutions for secure electronic commerce http://www.netlexis.com From owner-ietf-pkix@imc.org Wed Jun 14 08:13:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17175 for ; Wed, 14 Jun 2000 08:13:00 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA00327; Wed, 14 Jun 2000 05:12:15 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jun 2000 05:11:57 -0700 Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA00292 for ; Wed, 14 Jun 2000 05:11:55 -0700 (PDT) Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id (multiple receipients); Wed, 14 Jun 2000 14:11:28 +0200 (MET DST) Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id OAA11549; Wed, 14 Jun 2000 14:10:58 +0200 (MEST) Message-ID: <39477901.9E73A007@timeproof.de> Date: Wed, 14 Jun 2000 14:22:25 +0200 From: Joerg Seidel Organization: timeproof X-Mailer: Mozilla 4.5 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: Christopher Williams CC: PKIX Mailing List Subject: Re: Are there any TSAs out there? References: <002101bfd5df$c2173f70$76c6fc3e@darxstar> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Hello, it is not a software but hardware implementation, but timeproof is planning to implement the time-stamp-protocol as soon as it's draft becomes stable. For details please have a look at our website or contact or sales manager Mr. Förster . Joerg -- __________________________________________________________________ Jörg Seidel phone +49-40-76629-1911 Director Technology fax +49-40-76629-551 timeproof GmbH Harburger Schloßstraße 6-12 mailto:seidel@timeproof.de DE 21079 Hamburg http://www.timeproof.de __________________________________________________________________ Christopher Williams schrieb: > > Does anybody know of any commercial / free implementations of Time Stamp > Protocol server software? > > Christopher Williams > > Software engineer, NetLexis Ltd. > Solutions for secure electronic commerce > http://www.netlexis.com From owner-ietf-pkix@imc.org Wed Jun 14 10:54:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23892 for ; Wed, 14 Jun 2000 10:54:17 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA05242; Wed, 14 Jun 2000 07:52:17 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jun 2000 07:51:52 -0700 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05201 for ; Wed, 14 Jun 2000 07:51:49 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA366072; Wed, 14 Jun 2000 16:54:26 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA22448; Wed, 14 Jun 2000 16:50:37 +0200 Message-ID: <39479BC0.A23EF657@bull.net> Date: Wed, 14 Jun 2000 16:50:40 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Ed Gerck CC: "'ietf-pkix@imc.org'" Subject: Re: TSA Response serialNumber Field References: <852568F2.0050472B.00@D51MTA04.pok.ibm.com> <393BA827.6487CB21@bull.net> <393C6F32.C7B0BEF8@nma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Ed, Sorry for the delay to answer. > Denis Pinkas wrote: > > > I propose that we all look back > > at the definition we have in the current document. > > > > " By adding the XXXX value to the GeneralizedTime, an upper limit of > > the time at which the timestamp has been created by the TSA can be > > obtained. In the same way, by subtracting the XXXX to the > > GeneralizedTime, a lower limit of the time at which the timestamp > > has been created by the TSA can be obtained." > > > > The single remaining question is how do you call XXXX, while > > sticking to THIS definition. It is currently called "accuracy". If > > this term is not adequate, please make a proposal. I would like to > > close this issue soon. > > > > Dennis: > > The question is not so much what it is called (even though it would be > nice to use an already accepted name for it) but that THIS definition is > broken. The *concept* is quite clear and is *not* broken. Since you have not proposed an alternative to define this concept, I assume that the word chosen to define the concept is acceptable. > Pls see the former emails. So, one should not stick to THIS > definition. The definition says what it says and is very clear. It might not be what you want (we are not making measurements of a value), but we are seeking 100 % GUARANTEES for the value we get, even if the "accuracy", as we call it, is pretty large. We are not seeking a probabilistic answer, even with 99,99 % confidence. I have just posted a new draft to the web editor. This new draft should be available soon. Regards, Denis > Cheers, > > Ed Gerck From owner-ietf-pkix@imc.org Wed Jun 14 11:00:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24152 for ; Wed, 14 Jun 2000 11:00:07 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA05496; Wed, 14 Jun 2000 07:57:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jun 2000 07:57:00 -0700 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05463 for ; Wed, 14 Jun 2000 07:56:56 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA220174 for ; Wed, 14 Jun 2000 16:59:37 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA21746 for ; Wed, 14 Jun 2000 16:55:56 +0200 Message-ID: <39479CFF.ED3AC6AC@bull.net> Date: Wed, 14 Jun 2000 16:55:59 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: IETF-PXIX Subject: TSP Draft 08 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit I take advantage of a pause on the mailing list about TSP, to post a new draft and provide a summary of the main modifications performed to produce draft 8: 1. serial number now matches with the definition of serial number from RFC 2459. 2. The Authority Information Access (AIA) extension has been replaced by a Subject Information Access (SIA) extension which *should* appear in the son of RFC2459. 3. The field: extensions [0] Extensions OPTIONAL has been replaced by: extensions [0] IMPLICIT Extensions OPTIONAL 4. The explanations around the certReq field have been corrected/clarified. 5. Time Stamps users must now be ready to accommodate serial number integers up to 160 bits. 6. An additional field called ordering has been introduced in the response after accuracy: ordering BOOLEAN DEFAULT FALSE, This allows to build two categories of TSAs, whether ordering of Time Stamp tokens from the same TSA within the accuracy of the genTime (e.g. within the same second) is or is not a requirement. 7. The tagging of the two last parameters of the response has been modified in the following way: tsa [0] GeneralName OPTIONAL, extensions [1] Extensions OPTIONAL 8. The tagging of the three parameters of Accuracy has been simplified: Accuracy ::= SEQUENCE { seconds INTEGER OPTIONAL, millis [0] INTEGER (1..999) OPTIONAL, micros [1] INTEGER (1..999) OPTIONAL } 9. A new item 6 has been added to the security considerations section. If you have any comment (I hope you have none. :-| ), please wait until the new draft is made available. Denis From owner-ietf-pkix@imc.org Wed Jun 14 13:16:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28682 for ; Wed, 14 Jun 2000 13:16:52 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA13471; Wed, 14 Jun 2000 10:14:50 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jun 2000 10:14:00 -0700 Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA13437 for ; Wed, 14 Jun 2000 10:13:59 -0700 (PDT) Received: (qmail 3122 invoked from network); 14 Jun 2000 17:13:34 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 14 Jun 2000 17:13:34 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Wed, 14 Jun 2000 12:13:32 -0500 Message-ID: <3947BD3E.7AF7CE81@nma.com> Date: Wed, 14 Jun 2000 10:13:34 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Denis Pinkas CC: "'ietf-pkix@imc.org'" Subject: Re: TSA Response serialNumber Field References: <852568F2.0050472B.00@D51MTA04.pok.ibm.com> <393BA827.6487CB21@bull.net> <393C6F32.C7B0BEF8@nma.com> <39479BC0.A23EF657@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Denis Pinkas wrote: > Ed, > > Sorry for the delay to answer. No problem, my comment was not timestamped ;-) Let me retain the thread, for continuity. > > Denis Pinkas wrote: > > > > > I propose that we all look back > > > at the definition we have in the current document. > > > > > > " By adding the XXXX value to the GeneralizedTime, an upper limit of > > > the time at which the timestamp has been created by the TSA can be > > > obtained. In the same way, by subtracting the XXXX to the > > > GeneralizedTime, a lower limit of the time at which the timestamp > > > has been created by the TSA can be obtained." > > > > > > The single remaining question is how do you call XXXX, while > > > sticking to THIS definition. It is currently called "accuracy". If > > > this term is not adequate, please make a proposal. I would like to > > > close this issue soon. > > > > > > > Ed Gerck wrote: > > > > The question is not so much what it is called (even though it would be > > nice to use an already accepted name for it) but that THIS definition is > > broken. > > The *concept* is quite clear and is *not* broken. Since you have not > proposed an alternative to define this concept, I assume that the > word chosen to define the concept is acceptable. Please see the WG archives -- the alternative I suggested and was accepted by some is "uncertainty", and was also defined. > > Pls see the former emails. So, one should not stick to THIS > > definition. > > The definition says what it says and is very clear. It might not be > what you want (we are not making measurements of a value), but we > are seeking 100 % GUARANTEES for the value we get, even if the > "accuracy", as we call it, is pretty large. We are not seeking a > probabilistic answer, even with 99,99 % confidence. My comment is not whether you are seeking a probabilistic answer, but that seeking 100% guarantees is moot in this case -- this is NOT a digital signature, this represents a measurement of a value. So, if the standard wants to warrant that which cannot be warranted then I suggest that this be made clear to this WG and in the standard itself for those that might not have time to wade through all PKIX WG messages. IMO, though, this should NOT be done and the standard should make clear that there is no 100% guarantee on the time stamp -- which does not mean it is useless either, because if the deviation is known (as I suggested must be) then it is possible to get assurances which approach 100% as much as you please as a function of the error bar you want to consider. Cheers, Ed Gerck From owner-ietf-pkix@imc.org Wed Jun 14 21:35:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07223 for ; Wed, 14 Jun 2000 21:35:28 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA29932; Wed, 14 Jun 2000 18:35:04 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 14 Jun 2000 18:34:50 -0700 Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA29806 for ; Wed, 14 Jun 2000 18:34:45 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id NAA23027; Thu, 15 Jun 2000 13:34:11 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96103285213203>; Thu, 15 Jun 2000 13:34:12 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ccwilliams@ntlworld.com, ietf-pkix@imc.org Subject: Re: Are there any TSAs out there? Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Thu, 15 Jun 2000 13:34:12 (NZST) Message-ID: <96103285213203@kahu.cs.auckland.ac.nz> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe "Christopher Williams" writes: >Does anybody know of any commercial / free implementations of Time Stamp >Protocol server software? I made some quiet inquiries about this a few months back, but there don't seem to be any implementations around. Does anyone have something to test against? Peter. From owner-ietf-pkix@imc.org Thu Jun 15 06:43:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26259 for ; Thu, 15 Jun 2000 06:43:26 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA16435; Thu, 15 Jun 2000 03:41:42 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 15 Jun 2000 03:41:18 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16395 for ; Thu, 15 Jun 2000 03:41:17 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26141; Thu, 15 Jun 2000 06:40:55 -0400 (EDT) Message-Id: <200006151040.GAA26141@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt Date: Thu, 15 Jun 2000 06:40:55 -0400 Sender: nsyracus@cnri.reston.va.us Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) Author(s) : C. Adams, D. Pinkas, P. Cain, R. Zuccherato Filename : draft-ietf-pkix-time-stamp-08.txt Pages : 22 Date : 14-Jun-00 A time stamping service allows to prove that a datum existed before a particular time and can be used by a Trusted Third Party (TTP) as one component in building reliable non-repudiation services (see [ISONR]). This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. An example of how to prove that a digital signature was generated during the validity period of a public key certificate is given in an annex. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-time-stamp-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-time-stamp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000614110622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-time-stamp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-time-stamp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000614110622.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@imc.org Thu Jun 15 13:25:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09119 for ; Thu, 15 Jun 2000 13:25:38 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA27626; Thu, 15 Jun 2000 10:08:56 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 15 Jun 2000 10:08:10 -0700 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27584 for ; Thu, 15 Jun 2000 10:08:09 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 13:08:25 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C01F@panda.chrysalis-its.com> To: Denis.Pinkas@bull.net Cc: ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt Date: Thu, 15 Jun 2000 13:08:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD6EC.50BA7A8C" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD6EC.50BA7A8C Content-Type: text/plain; charset="iso-8859-1" Salut Denis, Here are few comments on version 8, some a which are a repeat of previous comments: a. Under Section 2.3, the first sentence indicates that "The TSA MUST sign all time stamp messages with one or more keys reserved specifically for that purpose". As suggested before, I would recommend that you add the following sentence after the first sentence to explain the reason(s) why a TSA could have more than one key reserved specifically for that purpose: "A TSA MAY have more than one key to accommodate different policies, different algorithms and/or different private key sizes". b. In Section 2.4.2, the structure "PKIStatusInfo" is missing the OPTIONAL "statusString" field, which is defined in RFC 2510 as PKIFreeText. Because later in Section 2.4.2 it is mentioned that "The statusString field of PKIStatusInfo MAY be used to include reason text such as 'messageImprint field is not correctly formatted'", it would be preferable if the structure "PKIStatusInfo" in this document was made consistent with the one in RFC 2510. c. Under Section 2.4.2, the structure "PKIStatus" can take the value of one (1) (i.e. grantedWithMods), which is defined in RFC 2510 as: grantedWithMods (1), -- you got something like what you asked for; the -- requester is responsible for ascertaining the differences However, base on this definition from RFC 2510, it is not clear in the context of a TSA if this means that a Time Stamp Token can be present, but its format was modified from what the requester demanded. If so, some text will need to be modified to also indicate that when the PKIStatus contains the value one (1) and not just zero (0), a Time Stamp Token can also be present. Otherwise, it should be clear what values for are allowed in the structure "PKIStatus" of a response by a TSA. In this case, I would suggest that you then indicate that the value of one (1) MUST not be used in a time stamping response. d. Under Section 2.4.2, in the definition for the TSTInfo "policy" field, it would be more meaningful to the requester if the document mandated that the error "unacceptedPolicy (15)" be returned instead of the error "badRequest (5)" when the TSA can not produce a response with a the same policy as requested by the requester in the TimeStampReq. e. Since there is no "automated" way for a TSA announce to the world what algorithms it supports to sign Time Stamp Tokens and also what algorithms it supports in messageImprints although I had previously suggested using the S/MIME capabilities attribute for this, I would then suggest that a new Section be added between the current Sections 3 and 4, which would define the minimum set of algorithm that MUST and SHOULD be supported by requesters and TSAs. Based on Section 12 of RFC 2630 [CMS], it could read as follows: 4 Supported Algorithms This section lists the algorithms that must be supported. Additional algorithms that should be supported are also included. 4.1 Hash Algorithms TSA implementations MUST support SHA-1. TSA implementations SHOULD support MD5. Hash algorithm identifiers are located in the MessageImprint hashAlgorithm field, the [CMS] SignedData digestAlgorithms field and the [CMS] SignerInfo digestAlgorithm field. Hash values are located in the MessageImprint and the [CMS] Message Digest authenticated attribute. In addition, hash values are input to signature algorithms. 4.1.1 SHA-1 The SHA-1 hash algorithm is defined in FIPS Pub 180-1 [SHA1]. The algorithm identifier for SHA-1 is: sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } The AlgorithmIdentifier parameters field is optional. If present, the parameters field must contain an ASN.1 NULL. Implementations should accept SHA-1 AlgorithmIdentifiers with absent parameters as well as NULL parameters. Implementations should generate SHA-1 AlgorithmIdentifiers with NULL parameters. 4.1.2 MD5 The MD5 hash algorithm is defined in RFC 1321 [MD5]. The algorithm identifier for MD5 is: md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5 } The AlgorithmIdentifier parameters field must be present, and the parameters field must contain NULL. Implementations may accept the MD5 AlgorithmIdentifiers with absent parameters as well as NULL parameters. 4.2 Signature Algorithms TSA implementations MUST support DSA. TSA implementations MAY include RSA. Signature algorithm identifiers are located in the [CMS] SignerInfo signatureAlgorithm field. Signature values are located in the [CMS] SignerInfo signature field. 4.2.1 DSA The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is always used with the SHA-1 message digest algorithm. The algorithm identifier for DSA is: id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 } The AlgorithmIdentifier parameters field must not be present. 4.2.2 RSA The RSA signature algorithm is defined in RFC 2347 [NEWPKCS#1]. RFC 2347 specifies the use of the RSA signature algorithm with the SHA-1 and MD5 message digest algorithms. The algorithm identifier for RSA is: rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } f. Under Section 6, you will have to add the [son of RFC 2459], which you are now referring under Section 2.3 for the Subject Information Access (SIA). You will also have to add all the references for the supported algorithms (i.e. [SHA1], [MD5], [DSS] and [NEWPKCS#1]) if you agree to add the new Section 4 above on Supported Algorithms. Regards, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFD6EC.50BA7A8C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

Salut Denis,

Here are few comments on version 8, some a which are = a repeat of previous comments:

a.  Under Section 2.3, the first sentence = indicates that "The TSA MUST sign all time stamp messages with one = or more keys reserved specifically for that purpose". As suggested = before, I would recommend that you add the following sentence after the = first sentence to explain the reason(s) why a TSA could have more than = one key reserved specifically for that purpose: "A TSA MAY have = more than one key to accommodate different policies, different = algorithms and/or different private key sizes".

b.  In Section 2.4.2, the structure = "PKIStatusInfo" is missing the OPTIONAL = "statusString" field, which is defined in RFC 2510 as = PKIFreeText. Because later in Section 2.4.2 it is mentioned that = "The statusString field of PKIStatusInfo MAY be used to include = reason text such as 'messageImprint field is not correctly = formatted'", it would be preferable if the structure = "PKIStatusInfo" in this document was made consistent with the = one in RFC 2510.

c.  Under Section 2.4.2, the structure = "PKIStatus" can take the value of one (1) (i.e. = grantedWithMods), which is defined in RFC 2510 as:

         = grantedWithMods        (1),
         -- = you got something like what you asked for; the
         -- = requester is responsible for ascertaining the differences

However, base on this definition from RFC 2510, it is = not clear in the context of a TSA if this means that a Time Stamp Token = can be present, but its format was modified from what the requester = demanded. If so, some text will need to be modified to also indicate = that when the PKIStatus contains the value one (1) and not just zero = (0), a Time Stamp Token can also be present. Otherwise, it should be = clear what values for are allowed in the structure = "PKIStatus" of a response by a TSA. In this case, I would = suggest that you then indicate that the value of one (1) MUST not be = used in a time stamping response.

d.  Under Section 2.4.2, in the definition for = the TSTInfo "policy" field, it would be more meaningful to = the requester if the document mandated that the error = "unacceptedPolicy (15)" be returned instead of the error = "badRequest (5)" when the TSA can not produce a response with = a the same policy as requested by the requester in the = TimeStampReq.

e.  Since there is no "automated" way = for a TSA announce to the world what algorithms it supports to sign = Time Stamp Tokens and also what algorithms it supports in = messageImprints although I had previously suggested using the = S/MIME

capabilities attribute for this, I would then suggest = that a new Section be added between the current Sections 3 and 4, which = would define the minimum set of algorithm that MUST and SHOULD be = supported by requesters and TSAs. Based on Section 12 of RFC 2630 = [CMS], it could read as follows:

4  Supported Algorithms

   This section lists the algorithms that = must be supported.
   Additional algorithms that should be = supported are also included.

4.1  Hash Algorithms

   TSA implementations MUST support = SHA-1.  TSA implementations SHOULD
   support MD5.

   Hash algorithm identifiers are located = in the MessageImprint
   hashAlgorithm field, the [CMS] = SignedData digestAlgorithms field and
   the [CMS] SignerInfo digestAlgorithm = field.

   Hash values are located in the = MessageImprint and the [CMS] Message
   Digest authenticated attribute.  = In addition, hash values are input
   to signature algorithms.

4.1.1  SHA-1

   The SHA-1 hash algorithm is defined in = FIPS Pub 180-1 [SHA1]. The
   algorithm identifier for SHA-1 = is:

      sha-1 OBJECT = IDENTIFIER ::=3D { iso(1) identified-organization(3)
          oiw(14) = secsig(3) algorithm(2) 26 }

   The AlgorithmIdentifier parameters field = is optional.  If present,
   the parameters field must contain an = ASN.1 NULL.  Implementations
   should accept SHA-1 = AlgorithmIdentifiers with absent parameters as
   well as NULL parameters.  = Implementations should generate SHA-1
   AlgorithmIdentifiers with NULL = parameters.

4.1.2  MD5

   The MD5 hash algorithm is defined in RFC = 1321 [MD5].  The algorithm
   identifier for MD5 is:

      md5 OBJECT IDENTIFIER = ::=3D { iso(1) member-body(2) us(840)
          = rsadsi(113549) digestAlgorithm(2) 5 }

   The AlgorithmIdentifier parameters field = must be present, and the
   parameters field must contain = NULL.  Implementations may accept the
   MD5 AlgorithmIdentifiers with absent = parameters as well as NULL
   parameters.

4.2  Signature Algorithms

   TSA implementations MUST support = DSA.  TSA implementations MAY
   include RSA.

   Signature algorithm identifiers are = located in the [CMS] SignerInfo
   signatureAlgorithm field.

   Signature values are located in the = [CMS] SignerInfo signature
   field.

4.2.1  DSA

   The DSA signature algorithm is defined = in FIPS Pub 186 [DSS].  DSA
   is always used with the SHA-1 message = digest algorithm.  The
   algorithm identifier for DSA is:

      id-dsa-with-sha1 = OBJECT IDENTIFIER ::=3D  { iso(1) member-body(2)
          us(840) = x9-57 (10040) x9cm(4) 3 }

   The AlgorithmIdentifier parameters field = must not be present.

4.2.2  RSA

   The RSA signature algorithm is defined = in RFC 2347 [NEWPKCS#1]. RFC
   2347 specifies the use of the RSA = signature algorithm with the SHA-1
   and MD5 message digest = algorithms.  The algorithm identifier for RSA
   is:

      rsaEncryption OBJECT = IDENTIFIER ::=3D { iso(1) member-body(2)
          us(840) = rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

f.  Under Section 6, you will have to add the = [son of RFC 2459], which you are now referring under Section 2.3 for = the Subject Information Access (SIA). You will also have to add all the = references for the supported algorithms (i.e. [SHA1], [MD5], [DSS] and = [NEWPKCS#1]) if you agree to add the new Section 4 above on Supported = Algorithms.

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01BFD6EC.50BA7A8C-- From owner-ietf-pkix@imc.org Thu Jun 15 14:46:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11627 for ; Thu, 15 Jun 2000 14:46:46 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA29561; Thu, 15 Jun 2000 11:45:45 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 15 Jun 2000 11:44:55 -0700 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29516 for ; Thu, 15 Jun 2000 11:44:54 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA12870 for ; Thu, 15 Jun 2000 20:44:34 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 15 Jun 2000 20:44:34 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA00260 for ; Thu, 15 Jun 2000 20:44:33 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA11525 for ietf-pkix@imc.org; Thu, 15 Jun 2000 20:44:33 +0200 (MET DST) Date: Thu, 15 Jun 2000 20:44:33 +0200 (MET DST) Message-Id: <200006151844.UAA11525@emeriau.edelweb.fr> To: ietf-pkix@imc.org Subject: Re: TSP Draft 08 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I find it somewhat unelegant to change the functionality of ordering is such an incompatible way. I think it would have been wiser to at least inverse the meaning or BOOLEAN ordering. It is not said anywhere whether a TSA has to set the ordering in a identical way in ALL of its time stamps. The ordering bit defines two different services; there is no way fore a TSA to publish which of the services it supports, there is also no way for the client to indicate whether ordering or not is desired when requesting a time stamp? The text says: 'Using a nonce always allows to detect replays' This should be 'using a nonce reduces the possibility of replay attacks.'. P From owner-ietf-pkix@imc.org Thu Jun 15 15:22:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12469 for ; Thu, 15 Jun 2000 15:22:53 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA00385; Thu, 15 Jun 2000 12:20:49 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 15 Jun 2000 12:20:30 -0700 Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00351 for ; Thu, 15 Jun 2000 12:20:28 -0700 (PDT) Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id (multiple receipients); Thu, 15 Jun 2000 21:20:03 +0200 (MET DST) Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id VAA26748; Thu, 15 Jun 2000 21:19:33 +0200 (MEST) Message-ID: <39492EF4.CE266284@timeproof.de> Date: Thu, 15 Jun 2000 21:31:00 +0200 From: Joerg Seidel Organization: timeproof X-Mailer: Mozilla 4.5 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: FRousseau@chrysalis-its.com CC: Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <918C70B01822D411A87400B0D0204DFF04C01F@panda.chrysalis-its.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Comments inline. > FRousseau@chrysalis-its.com schrieb: > > a. Under Section 2.3, the first sentence indicates that "The TSA MUST sign > all time stamp messages with one or more keys reserved specifically for that > purpose". As suggested before, I would recommend that you add the following > sentence after the first sentence to explain the reason(s) why a TSA could > have more than one key reserved specifically for that purpose: "A TSA MAY > have more than one key to accommodate different policies, different > algorithms and/or different private key sizes". Or just for performance purposes. > I would then suggest that a new Section be > added between the current Sections 3 and 4, which would define the minimum > set of algorithm that MUST and SHOULD be supported by requesters and TSAs. > Based on Section 12 of RFC 2630 [CMS], it could read as follows: > > 4 Supported Algorithms > > This section lists the algorithms that must be supported. > Additional algorithms that should be supported are also included. > > 4.1 Hash Algorithms > > TSA implementations MUST support SHA-1. TSA implementations SHOULD > support MD5. I think there are good reasons not to use MD5 in time stamps. They should use a strong hash function in order to achive long validity periods. MD5 is likely to be unsafe (=not collision free) soon and is already discuraged by german authorities. IF we add a section about algorithms, it should maybe read: "TSA implementations MUST support SHA-1. TSA implementations SHOULD NOT support MD5.". But I think such a section is not very necessary. > 4.2 Signature Algorithms > > TSA implementations MUST support DSA. TSA implementations MAY > include RSA. Again I would do it the other way round: "TSA MUST support RSA. MAY support DSA". Jörg -- __________________________________________________________________ Jörg Seidel phone +49-40-76629-1911 Director Technology fax +49-40-76629-551 timeproof GmbH Harburger Schloßstraße 6-12 mailto:seidel@timeproof.de DE 21079 Hamburg http://www.timeproof.de __________________________________________________________________ From owner-ietf-pkix@imc.org Thu Jun 15 20:04:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18244 for ; Thu, 15 Jun 2000 20:04:14 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA06734; Thu, 15 Jun 2000 16:56:59 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 15 Jun 2000 16:56:53 -0700 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06702 for ; Thu, 15 Jun 2000 16:56:52 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 19:57:19 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C024@panda.chrysalis-its.com> To: Peter.Sylvester@EdelWeb.fr Cc: ietf-pkix@imc.org Subject: RE: TSP Draft 08 Date: Thu, 15 Jun 2000 19:57:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD725.6F087410" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD725.6F087410 Content-Type: text/plain; charset="iso-8859-1" Peter, I disagree that the addition of the ordering flag is creating any incompatibility issue since the TSA document is still only an Internet Draft that should not have been used to develop any commercial product until it becomes an RFC. In addition, I think it is much more meaningful to require the flag to be present to indicate that ordering is supported as currently mandated by the latest TSA document. I agree however that there must be a way for a TSA to publish which of the ordering services it supports. As a minimum this should be done through the TSA's policy and it could possibly be done through the Subject Information Access (SIA) extension from the son of RFC 2459 if it contained a similar ordering flag. By using the reqPolicy field a requester could then request the appropriate service if a TSA offers different ordering services. I also agree that the document should indicate if a TSA has to set the ordering in a identical way in ALL of its time stamps. I would think that if a TSA explicitly indicate that it will not support ordering (e.g. through the TSA's policy or the SIA extension), Time Stamp tokens issued from this TSA MUST NEVER have the ordering field set to true. However, if a TSA explicitly indicate that it will support ordering, all Time Stamp tokens issued from this TSA SHOULD have the ordering field set to true unless the TSA can not longer do this because of some technical problems. This would then be a good reason to use the value of one (1) in the structure "PKIStatus" (i.e. grantedWithMods). Regards, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] Sent: Thursday, June 15, 2000 2:45 PM To: ietf-pkix@imc.org Subject: Re: TSP Draft 08 I find it somewhat unelegant to change the functionality of ordering is such an incompatible way. I think it would have been wiser to at least inverse the meaning or BOOLEAN ordering. It is not said anywhere whether a TSA has to set the ordering in a identical way in ALL of its time stamps. The ordering bit defines two different services; there is no way fore a TSA to publish which of the services it supports, there is also no way for the client to indicate whether ordering or not is desired when requesting a time stamp? The text says: 'Using a nonce always allows to detect replays' This should be 'using a nonce reduces the possibility of replay attacks.'. P ------_=_NextPart_001_01BFD725.6F087410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: TSP Draft 08

Peter,

I disagree that the addition of the ordering flag is = creating any incompatibility issue since the TSA document is still only = an Internet Draft that should not have been used to develop any = commercial product until it becomes an RFC. In addition, I think it is = much more meaningful to require the flag to be present to indicate that = ordering is supported as currently mandated by the latest TSA = document.

I agree however that there must be a way for a TSA to = publish which of the ordering services it supports. As a minimum this = should be done through the TSA's policy and it could possibly be done = through the Subject Information Access (SIA) extension from the son of = RFC 2459 if it contained a similar ordering flag. By using the = reqPolicy field a requester could then request the appropriate service = if a TSA offers different ordering services.

I also agree that the document should indicate if a = TSA has to set the ordering in a identical way in ALL of its time = stamps. I would think that if a TSA explicitly indicate that it will = not support ordering (e.g. through the TSA's policy or the SIA = extension), Time Stamp tokens issued from this TSA MUST NEVER have the = ordering field set to true. However, if a TSA explicitly indicate that = it will support ordering, all Time Stamp tokens issued from this TSA = SHOULD have the ordering field set to true unless the TSA can not = longer do this because of some technical problems. This would then be a = good reason to use the value of one (1) in the structure = "PKIStatus" (i.e. grantedWithMods).

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078


-----Original Message-----
From: Peter Sylvester [mailto:Peter.Sylvester@EdelWe= b.fr]
Sent: Thursday, June 15, 2000 2:45 PM
To: ietf-pkix@imc.org
Subject: Re: TSP Draft 08

I find it somewhat unelegant to change the = functionality of
ordering is such an incompatible way. I think = it
would have been wiser to at least inverse the = meaning
or BOOLEAN ordering.

It is not said anywhere whether a TSA has to set the = ordering
in a identical way in ALL of its time stamps.

The ordering bit defines two different services; = there is
no way fore a TSA to publish which of the services = it supports,
there is also no way for the client to indicate = whether
ordering or not is desired when requesting a time = stamp?

The text says: 'Using a nonce always allows to detect = replays'
This should be 'using a nonce reduces the = possibility of replay attacks.'.

P

------_=_NextPart_001_01BFD725.6F087410-- From owner-ietf-pkix@imc.org Fri Jun 16 07:26:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09061 for ; Fri, 16 Jun 2000 07:26:05 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA03835; Fri, 16 Jun 2000 04:24:03 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 04:23:21 -0700 Received: from mta02-svc.server.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03799 for ; Fri, 16 Jun 2000 04:23:20 -0700 (PDT) Received: from darxstar ([62.252.200.29]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000616122236.ZOIV10065.mta02-svc.server.ntlworld.com@darxstar> for ; Fri, 16 Jun 2000 12:22:36 +0000 Message-ID: <009701bfd785$529a9d70$c4cbfc3e@darxstar> From: "Christopher Williams" To: "PKIX Mailing List" Subject: Do people have something against RSA? Date: Fri, 16 Jun 2000 12:22:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Do people in the PKI world have something RSA Data Corporation? It's just that every document mandates DSA as a signature algorithm and indicates that RSA "MAY" also be supported. Another example is that PKIX does not support PKCS#8 for securing private keys, even though PKCS#8 is a well-established standard (eight years old now?). Then I read as a suggested amendment to the TSP document: "TSA implementations MUST support DSA. TSA implementations MAY include RSA. " Get real! The whole world uses RSA. The future worldwide PKI will run on RSA. I have never seen a certificate signed with an algorithm other than RSA and containing anything other than an RSA public key. Sure, RSA is patented, so factor licensing it as part of your software development costs and pay them their fee - they deserve it. Insisting upon DSA and Diffie-Hellman is like railing against the universality of Microsoft: pointless and missing the point. Christopher Williams Software engineer, NetLexis Ltd. http://www.netlexis.com "Intelligent Trust" From owner-ietf-pkix@imc.org Fri Jun 16 07:42:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09503 for ; Fri, 16 Jun 2000 07:42:41 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA04407; Fri, 16 Jun 2000 04:40:04 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 04:39:57 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA04366 for ; Fri, 16 Jun 2000 04:39:55 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id VAA00600; Fri, 16 Jun 2000 21:45:20 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 16 Jun 2000 21:38:52 +1000 Message-ID: From: Michael Zolotarev To: Christopher Williams , PKIX Mailing List Subject: RE: Do people have something against RSA? Date: Fri, 16 Jun 2000 21:38:51 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFD787.718D6774" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFD787.718D6774 Content-Type: text/plain; charset="iso-8859-1" > Get real! The whole world uses RSA. The future worldwide > PKI will run on > RSA. I have never seen a certificate signed with an > algorithm other than > RSA and containing anything other than an RSA public key. Here is one for you, Christopher. It contains a DSA key. If you insist, I can generate a *real* certificate for you. And I can sign it with a DSA key. Having fun? Michael :) ------_=_NextPart_000_01BFD787.718D6774 Content-Type: application/octet-stream; name="DEMO_DSA.crt" Content-Disposition: attachment; filename="DEMO_DSA.crt" Content-Transfer-Encoding: base64 MIIDwDCCAymgAwIBAgIEOHq2UTANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMCQVUxHzAdBgNV BAoTFkJhbHRpbW9yZSBUZWNobm9sb2dpZXMxGzAZBgNVBAsTEldlYlJBTyBEZXZlbG9wbWVudDEP MA0GA1UEAxMGRGVtb0NBMSQwIgYKCZImiZPyLGQBAxQURGVtb0NBQGJhbHRpbW9yZS5jb20wHhcN MDAwMTExMDQ0OTIxWhcNMDEwMTEwMTQ0OTIxWjCBgzELMAkGA1UEBhMCQVUxHzAdBgNVBAoTFkJh bHRpbW9yZSBUZWNobm9sb2dpZXMxIzAhBgNVBAsTGlRpbWVTdGFtcGluZyBEZW1vIFNlcnZpY2Vz MS4wLAYDVQQDEyVCYWx0aW1vcmUgVGltZVN0YW1waW5nIERlbW8gYXV0aG9yaXR5MIIBtzCCASwG ByqGSM44BAEwggEfAoGBAN5q7pg48zsWbRqU5ynTin7qK8lM1ppO4duhWA/owgn+tjdifKexFhee XZ0lL8jcEMAOVvzVlFB/aPVqBqP0sP39X7ecSbzYOl5LWeXpEWYdm/8jWh24OnjTnXHtpmNbw81M udsqVf3INkbA5gqE94gfnKbKAewzXaLnrHHjMqtjAhUAqmRGAyKQmBrQ0NxbsALlaTXkjE8CgYEA wjmOWeQea1+6Rlkdp9vJAhWPuvlgvLpn2KL0OFcbDvpN9fkpRUA4sbAlp8e7HRoO8jkLhypg03yV LgkqSiI3QCcZWCPSa9X9JVGXweYUM+sOQMX2SjdNmwwAypw/anaBDPnwzffuPVCckjYqvJGuATHX a+roLbpnYDasC/rz4vEDgYQAAoGAVhOJmRFPjUZgl/gKbZLZ2xaa9Bzjw6hJaS46o7JBZX7n16Lf ivzz7ICwmkbxIjmw8SltKgtkVWO8QXEII8bZJUlYsVs94vJ0s9GLIqv8sFwnd3P0JtVnDAYCA1to szQ+LtTBtQMe5I7bNSAxe/c/cKuVyZ2jDuLaHIsGTFdT7vGjJzAlMA4GA1UdDwEB/wQEAwIHgDAT BgNVHSUEDDAKBggrBgEFBQcDCDANBgkqhkiG9w0BAQUFAAOBgQBu0HCRDur34mAMEZMSwpnP3oVa Be6Twp24nF00UgO74i0uKhUNcSFxFIi6LqT70BMrxGSZIlzZot/8DKWIFgl5oDbhXIMpX05ogCIm xNtyUjZUIVt1ltD/7EOAnJ7asbGjB+uw4HG0JZYx5sIUFN5kucb/NFPD7OcO1em//nrVsw== ------_=_NextPart_000_01BFD787.718D6774-- From owner-ietf-pkix@imc.org Fri Jun 16 07:55:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09746 for ; Fri, 16 Jun 2000 07:55:03 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA05071; Fri, 16 Jun 2000 04:52:31 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 04:52:20 -0700 Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA05041 for ; Fri, 16 Jun 2000 04:52:01 -0700 (PDT) Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id MAA24209; Fri, 16 Jun 2000 12:51:29 +0100 Message-ID: <394A14B2.8A8E5312@algroup.co.uk> Date: Fri, 16 Jun 2000 12:51:14 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: Christopher Williams CC: PKIX Mailing List Subject: Re: Do people have something against RSA? References: <009701bfd785$529a9d70$c4cbfc3e@darxstar> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Christopher Williams wrote: > > Do people in the PKI world have something RSA Data Corporation? It's just > that every document mandates DSA as a signature algorithm and indicates that > RSA "MAY" also be supported. Another example is that PKIX does not support > PKCS#8 for securing private keys, even though PKCS#8 is a well-established > standard (eight years old now?). Then I read as a suggested amendment to > the TSP document: > > "TSA implementations MUST support DSA. TSA implementations MAY include RSA. > " > > Get real! The whole world uses RSA. The future worldwide PKI will run on > RSA. I have never seen a certificate signed with an algorithm other than > RSA and containing anything other than an RSA public key. Sure, RSA is > patented, so factor licensing it as part of your software development costs > and pay them their fee - they deserve it. > > Insisting upon DSA and Diffie-Hellman is like railing against the > universality of Microsoft: pointless and missing the point. IETF standards are required to use non-proprietary technologies wherever possible. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ From owner-ietf-pkix@imc.org Fri Jun 16 08:28:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10489 for ; Fri, 16 Jun 2000 08:28:14 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA06734; Fri, 16 Jun 2000 05:25:39 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 05:25:23 -0700 Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06697 for ; Fri, 16 Jun 2000 05:25:19 -0700 (PDT) Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id OAA15060; Fri, 16 Jun 2000 14:11:06 +0200 From: Sender: "denis bider" To: "'Ben Laurie'" , "'Christopher Williams'" Cc: "'PKIX Mailing List'" Subject: RE: Do people have something against RSA? Date: Fri, 16 Jun 2000 14:24:04 +0200 Message-ID: <000a01bfd78d$c3846ea0$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <394A14B2.8A8E5312@algroup.co.uk> Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > > Get real! The whole world uses RSA. [...] > > Insisting upon DSA and Diffie-Hellman is like railing against the > > universality of Microsoft: pointless and missing the point. > IETF standards are required to use non-proprietary technologies wherever > possible. Yes, but - the RSA patent is going to expire in September this year, is it not? There are not going to be any serious commercial employments of, say, a TSA, before September, are they? So why not put in RSA, since the patent is going to expire soon enough anyway? As far as I know, the validity of the patent cannot be extended, thus RSA becomes public domain. Regards, denis From owner-ietf-pkix@imc.org Fri Jun 16 08:43:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10710 for ; Fri, 16 Jun 2000 08:43:06 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA08102; Fri, 16 Jun 2000 05:42:02 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 05:41:50 -0700 Received: from exch1.rhbnc.ac.uk (exch1.rhbnc.ac.uk [134.219.200.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08066 for ; Fri, 16 Jun 2000 05:41:46 -0700 (PDT) Received: by exch1.rhbnc.ac.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 13:46:17 +0100 Message-ID: <837B0A2C05ADD111A31200E029054E30A91271@exch4.rhbnc.ac.uk> From: Xenitellis S To: "'PKIX Mailing List'" Subject: RE: Do people have something against RSA? Date: Fri, 16 Jun 2000 13:41:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I am not an expert on this, however I have heard two reasons that may make RSA still difficult to use. 1. The RSA patent expires this September, but there are several related to RSA patents that do not expire yet. It depends on the course that these additional patents will be fought for. 2. In other countries (like in the UK), I think that RSA is patented. What is the case in those countries? When do patents expire? My 2 drx, Simos Xenitellis > ---------- > From: denis.bider[SMTP:denis.bider@siol.net] > Sent: 16 June 2000 13:24 > To: 'Ben Laurie'; 'Christopher Williams' > Cc: 'PKIX Mailing List' > Subject: RE: Do people have something against RSA? > > > > Get real! The whole world uses RSA. [...] > > > Insisting upon DSA and Diffie-Hellman is like railing against the > > > universality of Microsoft: pointless and missing the point. > > IETF standards are required to use non-proprietary technologies wherever > > possible. > > Yes, but - the RSA patent is going to expire in September this year, is it > not? > > There are not going to be any serious commercial employments of, say, a > TSA, > before September, are they? > > So why not put in RSA, since the patent is going to expire soon enough > anyway? As far as I know, the validity of the patent cannot be extended, > thus RSA becomes public domain. > > Regards, > > denis > From owner-ietf-pkix@imc.org Fri Jun 16 09:05:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11037 for ; Fri, 16 Jun 2000 09:05:48 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA08725; Fri, 16 Jun 2000 05:53:51 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 05:53:38 -0700 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08691 for ; Fri, 16 Jun 2000 05:53:37 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 08:54:08 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C025@panda.chrysalis-its.com> To: seidel@timeproof.de Cc: ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt Date: Fri, 16 Jun 2000 08:53:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD791.F4FB4180" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD791.F4FB4180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable J=F6rg, See comments inline. Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 >-----Original Message----- >From: Joerg Seidel [mailto:seidel@timeproof.de] >Sent: Thursday, June 15, 2000 3:31 PM >To: FRousseau@chrysalis-its.com >Cc: Denis.Pinkas@bull.net; ietf-pkix@imc.org >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt > >Comments inline. > >> FRousseau@chrysalis-its.com schrieb: >>=20 >> a. Under Section 2.3, the first sentence indicates that "The TSA = MUST sign >> all time stamp messages with one or more keys reserved specifically = for that >> purpose". As suggested before, I would recommend that you add the following >> sentence after the first sentence to explain the reason(s) why a TSA could >> have more than one key reserved specifically for that purpose: "A = TSA MAY >> have more than one key to accommodate different policies, different >> algorithms and/or different private key sizes". > >Or just for performance purposes. If a TSA has more than one key for performance purposes, I would assume = they are just copies of the same private key cloned in different = cryptographic modules for performance and load balancing reasons. I think that the document meant "distinct" private keys, but I would agree with you that = it is not obvious. Instead it could read this way: "The TSA MUST sign all time stamp messages with one or more keys = reserved specifically for that purpose. A TSA MAY have distinct private keys to accommodate different policies, different algorithms and/or different = key sizes." >> I would then suggest that a new Section be >> added between the current Sections 3 and 4, which would define the minimum >> set of algorithm that MUST and SHOULD be supported by requesters and TSAs. >> Based on Section 12 of RFC 2630 [CMS], it could read as follows: >>=20 >> 4 Supported Algorithms >>=20 >> This section lists the algorithms that must be supported. >> Additional algorithms that should be supported are also included. >>=20 >> 4.1 Hash Algorithms >>=20 >> TSA implementations MUST support SHA-1. TSA implementations = SHOULD >> support MD5. > >I think there are good reasons not to use MD5 in time stamps. They = should use >a strong hash function in order to achive long validity periods. MD5 = is likely >to be unsafe (=3Dnot collision free) soon and is already discuraged by = german >authorities. I agree that TSAs should not use MD5 in their time stamps and MUST only = use strong hash functions (e.g. SHA-1, RIPEMD-160). However, there is = nothing wrong for a requester to submit a message imprint containing a MD5 hash, = which means that TSAs should be able accept request with MD5. >IF we add a section about algorithms, it should maybe read: "TSA >implementations MUST support SHA-1. TSA implementations SHOULD NOT = support >MD5.". But I think such a section is not very necessary. See comment above, however I agree that the text will have to be = modified to distinguish between the hash supported by TSAs in requests versus the = hash used by TSAs in time stamp tokens. >> 4.2 Signature Algorithms >>=20 >> TSA implementations MUST support DSA. TSA implementations MAY >> include RSA. > >Again I would do it the other way round: "TSA MUST support RSA. MAY = support >DSA". This came directly from RFC 2630 [CMS], however this document could = mandate different algorithms for TSA if this is what everyone agree. >J=F6rg >--=20 >__________________________________________________________________ > >J=F6rg Seidel phone +49-40-76629-1911 >Director Technology fax +49-40-76629-551 >timeproof GmbH =20 >Harburger Schlo=DFstra=DFe 6-12 mailto:seidel@timeproof.de >DE 21079 Hamburg http://www.timeproof.de >__________________________________________________________________ > ------_=_NextPart_001_01BFD791.F4FB4180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

J=F6rg,

See comments inline.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078


>-----Original Message-----
>From: Joerg Seidel [mailto:seidel@timeproof.de]
>Sent: Thursday, June 15, 2000 3:31 PM
>To: FRousseau@chrysalis-its.com
>Cc: Denis.Pinkas@bull.net; = ietf-pkix@imc.org
>Subject: Re: I-D = ACTION:draft-ietf-pkix-time-stamp-08.txt
>
>Comments inline.
>
>> FRousseau@chrysalis-its.com schrieb:
>>
>> a.  Under Section 2.3, the first = sentence indicates that "The TSA MUST sign
>> all time stamp messages with one or more = keys reserved specifically for that
>> purpose". As suggested before, I would = recommend that you add the following
>> sentence after the first sentence to = explain the reason(s) why a TSA could
>> have more than one key reserved = specifically for that purpose: "A TSA MAY
>> have more than one key to accommodate = different policies, different
>> algorithms and/or different private key = sizes".
>
>Or just for performance purposes.

If a TSA has more than one key for performance = purposes, I would assume they are just copies of the same private key = cloned in different cryptographic modules for performance and load = balancing reasons. I think that the document meant "distinct" = private keys, but I would agree with you that it is not obvious. = Instead it could read this way:

"The TSA MUST sign all time stamp messages with = one or more keys reserved specifically for that purpose. A TSA MAY have = distinct private keys to accommodate different policies, different = algorithms and/or different key sizes."

>> I would then suggest that a new Section = be
>> added between the current Sections 3 and 4, = which would define the minimum
>> set of algorithm that MUST and SHOULD be = supported by requesters and TSAs.
>> Based on Section 12 of RFC 2630 [CMS], it = could read as follows:
>>
>> 4  Supported Algorithms
>>
>>    This section lists the = algorithms that must be supported.
>>    Additional algorithms = that should be supported are also included.
>>
>> 4.1  Hash Algorithms
>>
>>    TSA implementations MUST = support SHA-1.  TSA implementations SHOULD
>>    support MD5.
>
>I think there are good reasons not to use MD5 in = time stamps. They should use
>a strong hash function in order to achive long = validity periods. MD5 is likely
>to be unsafe (=3Dnot collision free) soon and is = already discuraged by german
>authorities.

I agree that TSAs should not use MD5 in their time = stamps and MUST only use
strong hash functions (e.g. SHA-1, RIPEMD-160). = However, there is nothing wrong
for a requester to submit a message imprint = containing a MD5 hash, which means
that TSAs should be able accept request with = MD5.

>IF we add a section about algorithms, it should = maybe read: "TSA
>implementations MUST support SHA-1.  TSA = implementations SHOULD NOT support
>MD5.". But I think such a section is not = very necessary.

See comment above, however I agree that the text will = have to be modified to distinguish between the hash supported by TSAs = in requests versus the hash used by TSAs in time stamp = tokens.

>> 4.2  Signature Algorithms
>>
>>    TSA implementations MUST = support DSA.  TSA implementations MAY
>>    include RSA.
>
>Again I would do it the other way round: = "TSA MUST support RSA. MAY support
>DSA".

This came directly from RFC 2630 [CMS], however this = document could mandate different algorithms for TSA if this is what = everyone agree.

>J=F6rg
>--
>___________________________________________________________= _______
>
>J=F6rg = Seidel           =             =       phone  +49-40-76629-1911
>Director = Technology          &n= bsp;          = fax    +49-40-76629-551
>timeproof = GmbH           &n= bsp;           &n= bsp; 
>Harburger Schlo=DFstra=DFe = 6-12           &n= bsp; mailto:seidel@timeproof.de
>DE 21079 = Hamburg           = ;            = ; http://www.timeproof.de
>___________________________________________________________= _______
>

------_=_NextPart_001_01BFD791.F4FB4180-- From owner-ietf-pkix@imc.org Fri Jun 16 09:36:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11486 for ; Fri, 16 Jun 2000 09:35:59 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA10157; Fri, 16 Jun 2000 06:32:29 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 06:32:16 -0700 Received: from stonewall.baltimore.com (mailhost.baltimore.com [195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA10126 for ; Fri, 16 Jun 2000 06:32:13 -0700 (PDT) Message-ID: <61922E6DA745D311A42000508B2CFD14B96766@baltimore.com> From: Paul Halliden To: "'Xenitellis S'" , "'PKIX Mailing List'" Subject: RE: Do people have something against RSA? Date: Fri, 16 Jun 2000 14:32:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe >2. In other countries (like in the UK), I think that RSA is >patented. What is the case in those countries? RSA is not patented in the UK or, to the best of my knowledge, in any other European country. However, I understand that there is a claim that DSA may covered by a European patent. In the US, I believe that the Federal authorities provide indemnity to vendors using DSA in products supplied to the government - but I have not heard of that happening elsewhere. Regards Paul Halliden From owner-ietf-pkix@imc.org Fri Jun 16 10:22:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12627 for ; Fri, 16 Jun 2000 10:22:05 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA11817; Fri, 16 Jun 2000 07:21:15 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 07:21:01 -0700 Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA11775 for ; Fri, 16 Jun 2000 07:20:59 -0700 (PDT) Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id PAA25276; Fri, 16 Jun 2000 15:20:30 +0100 Message-ID: <394A379B.D57E3142@algroup.co.uk> Date: Fri, 16 Jun 2000 15:20:11 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: Xenitellis S CC: "'PKIX Mailing List'" Subject: Re: Do people have something against RSA? References: <837B0A2C05ADD111A31200E029054E30A91271@exch4.rhbnc.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Xenitellis S wrote: > > I am not an expert on this, however I have heard two reasons that > may make RSA still difficult to use. > > 1. The RSA patent expires this September, but there are several related > to RSA patents that do not expire yet. It depends on the course that > these additional patents will be fought for. > > 2. In other countries (like in the UK), I think that RSA is patented. What > is > the case in those countries? When do patents expire? RSA is not patented in the UK (or the rest of Europe). Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ From owner-ietf-pkix@imc.org Fri Jun 16 10:22:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12650 for ; Fri, 16 Jun 2000 10:22:58 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA11910; Fri, 16 Jun 2000 07:21:33 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 07:21:22 -0700 Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA11837 for ; Fri, 16 Jun 2000 07:21:20 -0700 (PDT) Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id PAA25280; Fri, 16 Jun 2000 15:21:04 +0100 Message-ID: <394A37BD.511FCADF@algroup.co.uk> Date: Fri, 16 Jun 2000 15:20:45 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: denis.bider@siol.net CC: "'Christopher Williams'" , "'PKIX Mailing List'" Subject: Re: Do people have something against RSA? References: <000a01bfd78d$c3846ea0$0201010a@intergalactic> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit denis.bider@siol.net wrote: > > > > Get real! The whole world uses RSA. [...] > > > Insisting upon DSA and Diffie-Hellman is like railing against the > > > universality of Microsoft: pointless and missing the point. > > IETF standards are required to use non-proprietary technologies wherever > > possible. > > Yes, but - the RSA patent is going to expire in September this year, is it > not? > > There are not going to be any serious commercial employments of, say, a TSA, > before September, are they? Rules are rules! In September, you'll be right. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ From owner-ietf-pkix@imc.org Fri Jun 16 10:28:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12754 for ; Fri, 16 Jun 2000 10:28:38 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA12467; Fri, 16 Jun 2000 07:28:02 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 07:27:50 -0700 Received: from dns1.provide.net (root@dns1.provide.net [216.86.64.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12422 for ; Fri, 16 Jun 2000 07:27:49 -0700 (PDT) Received: from cyclonecommerce.com (usr08-113.provide.net [216.86.68.241]) by dns1.provide.net (8.9.0/8.9.3) with ESMTP id KAA06816; Fri, 16 Jun 2000 10:27:20 -0400 (EDT) Message-ID: <394A36E1.615C66F3@cyclonecommerce.com> Date: Fri, 16 Jun 2000 10:17:05 -0400 From: Timothy Fisher X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Williams CC: PKIX Mailing List Subject: Re: Do people have something against RSA? References: <009701bfd785$529a9d70$c4cbfc3e@darxstar> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Fortunately, the patent will expire at the end of September of this year. After that, you will no longer have to pay RSA data corp. any fees to use RSA. The reason that DSA is mandated in most standards is simply because it is free to use. A standard should never mandate an algorithm which must be licensed from a specific provider. This would be a mistake. Timothy Fisher Christopher Williams wrote: > Do people in the PKI world have something RSA Data Corporation? It's just > that every document mandates DSA as a signature algorithm and indicates that > RSA "MAY" also be supported. Another example is that PKIX does not support > PKCS#8 for securing private keys, even though PKCS#8 is a well-established > standard (eight years old now?). Then I read as a suggested amendment to > the TSP document: > > "TSA implementations MUST support DSA. TSA implementations MAY include RSA. > " > > Get real! The whole world uses RSA. The future worldwide PKI will run on > RSA. I have never seen a certificate signed with an algorithm other than > RSA and containing anything other than an RSA public key. Sure, RSA is > patented, so factor licensing it as part of your software development costs > and pay them their fee - they deserve it. > > Insisting upon DSA and Diffie-Hellman is like railing against the > universality of Microsoft: pointless and missing the point. > > Christopher Williams > > Software engineer, NetLexis Ltd. > http://www.netlexis.com "Intelligent Trust" From owner-ietf-pkix@imc.org Fri Jun 16 10:31:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12916 for ; Fri, 16 Jun 2000 10:31:04 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA12746; Fri, 16 Jun 2000 07:29:57 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 07:29:45 -0700 Received: from dns1.provide.net (root@dns1.provide.net [216.86.64.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12703 for ; Fri, 16 Jun 2000 07:29:45 -0700 (PDT) Received: from cyclonecommerce.com (usr08-113.provide.net [216.86.68.241]) by dns1.provide.net (8.9.0/8.9.3) with ESMTP id KAA06916; Fri, 16 Jun 2000 10:28:54 -0400 (EDT) Message-ID: <394A374F.D475E249@cyclonecommerce.com> Date: Fri, 16 Jun 2000 10:18:55 -0400 From: Timothy Fisher X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Laurie CC: Christopher Williams , PKIX Mailing List Subject: Re: Do people have something against RSA? References: <009701bfd785$529a9d70$c4cbfc3e@darxstar> <394A14B2.8A8E5312@algroup.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Chris, I also think that the simple fact is that YES, quite a few people do have something against RSA Security Inc. Have you ever tryed negotiating with them? I have... Its not a fun process.... Many people share this opinion of RSA. Tim Ben Laurie wrote: > Christopher Williams wrote: > > > > Do people in the PKI world have something RSA Data Corporation? It's just > > that every document mandates DSA as a signature algorithm and indicates that > > RSA "MAY" also be supported. Another example is that PKIX does not support > > PKCS#8 for securing private keys, even though PKCS#8 is a well-established > > standard (eight years old now?). Then I read as a suggested amendment to > > the TSP document: > > > > "TSA implementations MUST support DSA. TSA implementations MAY include RSA. > > " > > > > Get real! The whole world uses RSA. The future worldwide PKI will run on > > RSA. I have never seen a certificate signed with an algorithm other than > > RSA and containing anything other than an RSA public key. Sure, RSA is > > patented, so factor licensing it as part of your software development costs > > and pay them their fee - they deserve it. > > > > Insisting upon DSA and Diffie-Hellman is like railing against the > > universality of Microsoft: pointless and missing the point. > > IETF standards are required to use non-proprietary technologies wherever > possible. > > Cheers, > > Ben. > > -- > http://www.apache-ssl.org/ben.html > > Coming to ApacheCon Europe 2000? http://apachecon.com/ From owner-ietf-pkix@imc.org Fri Jun 16 10:31:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12953 for ; Fri, 16 Jun 2000 10:31:36 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA12950; Fri, 16 Jun 2000 07:30:39 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 07:30:27 -0700 Received: from mail.addtrust.com ([212.28.208.199]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12892 for ; Fri, 16 Jun 2000 07:30:15 -0700 (PDT) Received: from santesson.addtrust.com (unknown [212.28.208.198]) by mail.addtrust.com (Postfix) with ESMTP id D50E53E203 for ; Fri, 16 Jun 2000 16:28:46 +0200 (CEST) Message-Id: <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> X-Sender: sts@mail.addtrust.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Jun 2000 16:29:17 +0200 To: ietf-pkix@imc.org From: Stefan Santesson Subject: Can we form certificates with just name and e-mail address Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Just a seemingly easy question! How do you form a certificate according to PKIX where the subjects name only consists of a name (commonName or GivenName + surname) and an e-mail address ?? It seams to be virtually impossible to do this. I'm almost certain that this must have been up before, so I would appreciate some hints here. The problem is that son of RFC 2459 in "4.1.2.6 Subject" says Conforming implementations generating new certificates with elec- tronic mail addresses MUST use the rfc822Name in the subject alterna- tive name field (see sec. 4.2.1.7) to describe such identities. Simultaneous inclusion of the EmailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted. My problem with this is that the name (given name + surname) is not unique. I.e. it can't be stored in the subject field nor as a name form in the subjectAltName ext, unless combined with some disambiguating data (such as an e-mail address), which is deprecated according to the current text. This means that inclusion of a name in the subject field must be combined with some disambiguating data other than an e-mail address (if the name is not unique enough). This seams like a pragmatic view that hardly meets the requirements of a practical world. What has historic debates concluded in? /Stefan From owner-ietf-pkix@imc.org Fri Jun 16 10:56:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13601 for ; Fri, 16 Jun 2000 10:56:05 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA14097; Fri, 16 Jun 2000 07:52:45 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 07:51:52 -0700 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14040 for ; Fri, 16 Jun 2000 07:51:50 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA33904 for ; Fri, 16 Jun 2000 16:54:40 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA20436 for ; Fri, 16 Jun 2000 16:50:56 +0200 Message-ID: <394A3ED2.E70B5912@bull.net> Date: Fri, 16 Jun 2000 16:50:58 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: "'PKIX Mailing List'" Subject: Re: Do people have something against RSA? References: <000a01bfd78d$c3846ea0$0201010a@intergalactic> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit denis, I will use your E-mail to comment. > > > Get real! The whole world uses RSA. [...] > > > Insisting upon DSA and Diffie-Hellman is like railing against the > > > universality of Microsoft: pointless and missing the point. > > IETF standards are required to use non-proprietary technologies wherever > > possible. > > Yes, but - the RSA patent is going to expire in September this year, is it > not? > > There are not going to be any serious commercial employments of, say, a TSA, > before September, are they? I do not buy the arguments from Christopher, but I thank him for being the first one daring to raise the issue. The question raised by denis makes sense: we only have a little bit more than 3 months left before the expiration of the RSA patent. There are two related questions: 1) Should we mandate the use of the RSA algorithm for signing TS token ? This seems reasonable in this new context. 2) Should the chairs wait until September 21 rst, 2000 to send the TSP draft to the IESG (and mandate the use of the RSA algorithm for signing) or should they do it now (i.e. as soon as they consider that we have reached a WG consensus) taking into account that the next step is Proposed Standard, i.e. not Standard, which means that in any case, the Standard will be published three months AFTER the expiration of the RSA patent. The later seems reasonable ... but would mean to publish a version 9 of the TSP draft before sending it to the IESG. Anyway the question is much broader than the TSP draft and applies to all other drafts, in particular Attibute Certificates. Denis > So why not put in RSA, since the patent is going to expire soon enough > anyway? As far as I know, the validity of the patent cannot be extended, > thus RSA becomes public domain. > > Regards, > > denis From owner-ietf-pkix@imc.org Fri Jun 16 11:24:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14330 for ; Fri, 16 Jun 2000 11:24:19 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA15184; Fri, 16 Jun 2000 08:21:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 08:21:38 -0700 Received: from windoze.tenebras.com (windoze.tenebras.com [216.15.43.196]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15145 for ; Fri, 16 Jun 2000 08:21:37 -0700 (PDT) Received: from dnai.com (localhost [127.0.0.1]) by windoze.tenebras.com (8.9.3/8.9.3) with ESMTP id IAA37417; Fri, 16 Jun 2000 08:20:48 -0700 (PDT) (envelope-from kudzu@dnai.com) Sender: kudzu@windoze.tenebras.com Message-ID: <394A45D0.B58E698@dnai.com> Date: Fri, 16 Jun 2000 08:20:48 -0700 From: Michael Sierchio X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: fr, en MIME-Version: 1.0 To: Christopher Williams CC: PKIX Mailing List Subject: Re: Do people have something against RSA? References: <009701bfd785$529a9d70$c4cbfc3e@darxstar> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Christopher Williams wrote: > > Do people in the PKI world have something RSA Data Corporation? It's just > that every document mandates DSA as a signature algorithm and indicates that > RSA "MAY" also be supported. Another example is that PKIX does not support > PKCS#8 for securing private keys, even though PKCS#8 is a well-established > standard (eight years old now?). Then I read as a suggested amendment to > the TSP document: > > "TSA implementations MUST support DSA. TSA implementations MAY include RSA." I'm afraid that I don't see why a mandate for private key storage is relevant to this discussion -- other than the obvious requirement that private keys be kept private, whether by embedding in tamper-resistant hardware, password based encryption, etc., and that there be a revocation mechanism in the event of compromise. And the answer to your query -- as a former employee of RSADSI (now RSA Security) -- is: yes. There is antipathy for RSA, perhaps because they have always spent more on lawyers than on R&D. I have the greatest respect for the folks at RSA Labs, but slight regard for the rest of the company that was RSADSI and SDTI. > Get real! The whole world uses RSA. The future worldwide PKI will run on > RSA. One might easily surmise that the future of PKI is ECC, or something yet to be invented. However, choosing technology that is unecumbered by patents is an IETF requirement. > I have never seen a certificate signed with an algorithm other than > RSA and containing anything other than an RSA public key. That is a self-referential statement -- the plural of anecdote is not data, IIRC. > Insisting upon DSA and Diffie-Hellman is like railing against the > universality of Microsoft: pointless and missing the point. There are distinct advantages to the use of long-term DH values tied to identity, esp. when it comes to stateless protocols, IPSec, and other uses for key agreement. From owner-ietf-pkix@imc.org Fri Jun 16 12:06:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15495 for ; Fri, 16 Jun 2000 12:06:02 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA16159; Fri, 16 Jun 2000 09:04:58 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 09:04:39 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16121 for ; Fri, 16 Jun 2000 09:04:38 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA05764; Fri, 16 Jun 2000 12:04:17 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <394A3ED2.E70B5912@bull.net> References: <000a01bfd78d$c3846ea0$0201010a@intergalactic> <394A3ED2.E70B5912@bull.net> Date: Fri, 16 Jun 2000 11:55:55 -0400 To: Denis Pinkas From: Stephen Kent Subject: Re: Do people have something against RSA? Cc: "'PKIX Mailing List'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Denis, The TSP draft is well along and I don't envision holding it up, waiting for the RSA patent to expire. The document adopted an algorithm approach consistent with IESG policy, and with other crypto-based RFCs. Let's just stick with that. Steve From owner-ietf-pkix@imc.org Fri Jun 16 12:11:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15621 for ; Fri, 16 Jun 2000 12:11:28 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA16440; Fri, 16 Jun 2000 09:08:26 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 09:08:15 -0700 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16402 for ; Fri, 16 Jun 2000 09:08:13 -0700 (PDT) Received: by ns.celocom.se; id SAA24781; Fri, 16 Jun 2000 18:07:57 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma024771; Fri, 16 Jun 00 18:07:36 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id SAA28077; Fri, 16 Jun 2000 18:10:54 +0200 Message-ID: <394A50C7.1F54699B@celocom.com> Date: Fri, 16 Jun 2000 18:07:35 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Santesson CC: ietf-pkix@imc.org Subject: Re: Can we form certificates with just name and e-mail address References: <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5659E2AFB7538B3B3AFF4A69" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a cryptographically signed message in MIME format. --------------ms5659E2AFB7538B3B3AFF4A69 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stefan Santesson wrote: > How do you form a certificate according to PKIX where the subjects name > only consists of a name (commonName or GivenName + surname) and an e-mail > address ?? It seams to be virtually impossible to do this. > > [...] > > What has historic debates concluded in? I don't actually know the history here, but I would wager a suggestion: Could you not leave the subject name empty and include both a rfc822Name and a directoryName (which would then contain your given name and surname attributes) in the subject alternate name extension? //oscar --------------ms5659E2AFB7538B3B3AFF4A69 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjE2MTYwNzM2 WjAjBgkqhkiG9w0BCQQxFgQU7I78gJT2zg+dy9DC78tFftRF35MwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBeG1SKy2n0uKsPp4O6dTcPASQVd5G8 6dGyHdH5dZRtdKuihHA6e548WJJFCSR5z5tSh/ikIKKzo/wndoej2F+mhmEwKX0MwHLdh62V i55ZTLBI8Vhjt4odWdCfx+kT5qdT3RPl3/1pOh63Zs+ZTv5CL9BfRYCBHj7zKreQWaOccg== --------------ms5659E2AFB7538B3B3AFF4A69-- From owner-ietf-pkix@imc.org Fri Jun 16 12:22:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15958 for ; Fri, 16 Jun 2000 12:22:23 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA17236; Fri, 16 Jun 2000 09:21:44 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 09:21:31 -0700 Received: from indy.gradient.com (indy.gradient.com [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17197 for ; Fri, 16 Jun 2000 09:21:30 -0700 (PDT) Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id MAA06645; Fri, 16 Jun 2000 12:20:10 -0400 (EDT) Received: by bigbird.gradient.com with Internet Mail Service (5.5.2448.0) id ; Fri, 16 Jun 2000 12:15:23 -0400 Message-ID: <899128A30EEDD1118FC900A0C9C74A34844CA8@bigbird.gradient.com> From: Hal Lockhart To: "'Stephen Kent'" , Denis Pinkas Cc: "'PKIX Mailing List'" Subject: RE: Do people have something against RSA? Date: Fri, 16 Jun 2000 12:14:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > The TSP draft is well along and I don't envision holding it up, > waiting for the RSA patent to expire. The document adopted an > algorithm approach consistent with IESG policy, and with other > crypto-based RFCs. Let's just stick with that. I agree and predict that algorithm support will be a frequent type of modification. For example, all the specs that deal with symmetric algorithms will upgrade to AES, most likely as the required choice, once that selection occurs. Hal ======================================================= Harold W. Lockhart Entegrity Solutions 2 Mount Royal Avenue Marlborough, MA 01752 USA V: 1-508-624-9600 x 260 hal.lockhart@entegrity.com F: 1-508-229-0338 www.entegrity.com ======================================================= From owner-ietf-pkix@imc.org Fri Jun 16 12:34:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16210 for ; Fri, 16 Jun 2000 12:34:51 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA17927; Fri, 16 Jun 2000 09:34:05 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 09:33:57 -0700 Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA17893 for ; Fri, 16 Jun 2000 09:33:56 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Jun 2000 16:28:51 UT Received: from exrsa01.rsa.com ([10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA25404 for ; Fri, 16 Jun 2000 12:33:20 -0400 (EDT) Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2448.0) id <293KY97D>; Fri, 16 Jun 2000 09:32:09 -0700 Message-ID: From: "Jacoby, Jeffrey" To: "'ietf-pkix@imc.org'" Subject: CRMF (RFC 2511) and password-based MAC question Date: Fri, 16 Jun 2000 09:31:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi, In section 4.4.1 of RFC 2511, on generating a password-based MAC value, there is no recommended minimum (or maximum) length for the salt value. Does anyone have a recommendation for salt length? What's typically used in practice or existing applications? Thanks, Jeff Jacoby phone: (650) 295-7569 email: jjacoby@rsasecurity.com RSA Security, SMDC 2755 Campus Drive San Mateo, CA 94403 From owner-ietf-pkix@imc.org Fri Jun 16 13:37:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18214 for ; Fri, 16 Jun 2000 13:37:18 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA20270; Fri, 16 Jun 2000 10:36:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 10:35:44 -0700 Received: from mta02-svc.server.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20189 for ; Fri, 16 Jun 2000 10:35:41 -0700 (PDT) Received: from darxstar ([62.252.196.216]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000616183459.CBSI10065.mta02-svc.server.ntlworld.com@darxstar>; Fri, 16 Jun 2000 18:34:59 +0000 Message-ID: <003501bfd7b9$58be2080$d8c4fc3e@darxstar> From: "Christopher Williams" To: "Stefan Santesson" Cc: "PKIX Mailing List" References: <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> Subject: Re: Can we form certificates with just name and e-mail address Date: Fri, 16 Jun 2000 18:07:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit You put your common name (or given name + surname) in the SubjectName field and your e-mail address in the rfc822Name field in a SubjectAlternativeName field extension. I don't think that it is too important if the SubjectName is not unique; the combination of SubjectName and SerialNo has to be unique. Alternatively, you can leave the SubjectName field blank (unusual but the standard permits it) and put your common name in a directoryName field in your alternative name and your e-mail address in an rfc822Name. While you're at it, why not include the URL of your homepage in a uRI field! Remember that a SubjectAlternativeName is type GeneralNames, which means it can have any number of elements. On the subject of alternative names, what exactly is an ediPartyName, anybody? I know that EDI stands for "Electronic Data Interchange" but I don't know anything more. Also, I have to say that I think it's crazy that your e-mail address has to go into an extension, or can only be placed in the name field by means of a (deprecated) kludge. In a world context, your e-mail address is as important (at least) as your X-500 characteristics. If I get a personal certificate, I don't have an "organization" or an "organizational unit" - it's just me. Christopher Williams Software engineer, NetLexis Ltd. http://www.netlexis.com "Intelligent Trust" From owner-ietf-pkix@imc.org Fri Jun 16 13:37:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18225 for ; Fri, 16 Jun 2000 13:37:28 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA20261; Fri, 16 Jun 2000 10:36:11 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 10:35:52 -0700 Received: from mta02-svc.server.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20214 for ; Fri, 16 Jun 2000 10:35:51 -0700 (PDT) Received: from darxstar ([62.252.196.216]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000616183508.CBTQ10065.mta02-svc.server.ntlworld.com@darxstar> for ; Fri, 16 Jun 2000 18:35:08 +0000 Message-ID: <003701bfd7b9$5e4e3ad0$d8c4fc3e@darxstar> From: "Christopher Williams" To: "PKIX Mailing List" References: <899128A30EEDD1118FC900A0C9C74A34844CA8@bigbird.gradient.com> Subject: Re: Do people have something against RSA? Date: Fri, 16 Jun 2000 18:35:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit OK, maybe RSADSI are litigious and awkward to deal with. I don't know, I've never dealt with them. However, let's say that I implemented a standard, say TLS, and only included the mandatory cipher suite, DSA with ephemeral Diffie-Hellman, SHA-1 and 3-DES encryption. You know what? It wouldn't work with anything! Everybody else's implementation uses RSA so mine has to as well, whether I like it or not. The reality is that RSA is mandatory and DSA the nice optional extra which adds spice and competitive advantage. As to whether the future belongs to RSA or maybe some recent innovation like ECC or some as-yet uninvented scheme, as Microsoft shows, it's not being the best that makes you the winner, it's being the most widespread. So, given that: - RSA's patent is due to expire (news to me, but welcome news) - DSA has patent issues in Europe - Everybody uses RSA anyway; very few use DSA Can we please start mandating RSA in future? It will make implementing standards much easier and remove the FUD because I haven't incorporated support for Diffie-Hellman! Christopher Williams Software engineer, NetLexis Ltd. http://www.netlexis.com "Intelligent Trust" From owner-ietf-pkix@imc.org Fri Jun 16 14:16:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19618 for ; Fri, 16 Jun 2000 14:16:53 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA21384; Fri, 16 Jun 2000 11:14:40 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 11:14:15 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21345 for ; Fri, 16 Jun 2000 11:14:14 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA24313; Fri, 16 Jun 2000 14:13:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <003501bfd7b9$58be2080$d8c4fc3e@darxstar> References: <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> Date: Fri, 16 Jun 2000 14:13:47 -0400 To: "Christopher Williams" From: Stephen Kent Subject: Re: Can we form certificates with just name and e-mail address Cc: "PKIX Mailing List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Christopher, >You put your common name (or given name + surname) in the SubjectName field >and your e-mail address in the rfc822Name field in a SubjectAlternativeName >field extension. I don't think that it is too important if the SubjectName >is not unique; the combination of SubjectName and SerialNo has to be unique. We have had this discussion in this list. The decision was that if you're going to use a DN field (subject name or a directory name as an alt name) then the contents should be "reasonable" in a directory context. That's why, when Denis Pinkas proposed a name form built from DN attributes but not consistent with real directory use, he agreed to define a new data type for it. The bottom line is that just because a name is constructed from directory attributes, that does not make it a reasonable DN. >Alternatively, you can leave the SubjectName field blank (unusual but the >standard permits it) and put your common name in a directoryName field in >your alternative name and your e-mail address in an rfc822Name. While >you're at it, why not include the URL of your homepage in a uRI field! >Remember that a SubjectAlternativeName is type GeneralNames, which means it >can have any number of elements. But, it is still of type DirectoryName and thus should be a name suitable for use in a directory, as noted above. >On the subject of alternative names, what exactly is an ediPartyName, >anybody? I know that EDI stands for "Electronic Data Interchange" but I >don't know anything more. I always assumed the EDI folks have really exclusive parties and never invite the rest of us. > >Also, I have to say that I think it's crazy that your e-mail address has to >go into an extension, or can only be placed in the name field by means of a >(deprecated) kludge. In a world context, your e-mail address is as >important (at least) as your X-500 characteristics. If I get a personal >certificate, I don't have an "organization" or an "organizational unit" - >it's just me. I agree that having a cert with an alt subject name that is JUST an RFC822 name would be fine. Your comments re O and OU are correct, but perhaps you are missing some context here. The directory distinguishes between organizational persons and residential persons. The latter don't contain an O or OU attribute. Steve From owner-ietf-pkix@imc.org Fri Jun 16 15:43:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22489 for ; Fri, 16 Jun 2000 15:43:34 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA22897; Fri, 16 Jun 2000 12:42:34 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 16 Jun 2000 12:41:51 -0700 Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22821 for ; Fri, 16 Jun 2000 12:41:48 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id HAA14916; Sat, 17 Jun 2000 07:41:25 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96118448411860>; Sat, 17 Jun 2000 07:41:24 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ccwilliams@ntlworld.com, ietf-pkix@imc.org Subject: Re: Do people have something against RSA? Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Sat, 17 Jun 2000 07:41:24 (NZST) Message-ID: <96118448411860@kahu.cs.auckland.ac.nz> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe "Christopher Williams" >Can we please start mandating RSA in future? It will make implementing >standards much easier and remove the FUD because I haven't incorporated >support for Diffie-Hellman! Calm down, calm down, it's not that bad. The way it works is that everyone pretends to do DSA+DH until September, then stops pretending on the 20th. The "shall DSA, may RSA" wording of the standards is a bit confusing at first, but it all works out in the long run. (You're new to this, right? :-). Peter. From owner-ietf-pkix@imc.org Sat Jun 17 03:37:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16649 for ; Sat, 17 Jun 2000 03:37:20 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA04517; Sat, 17 Jun 2000 00:36:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 17 Jun 2000 00:35:42 -0700 Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04468 for ; Sat, 17 Jun 2000 00:35:39 -0700 (PDT) Received: from mega (t4o69p117.telia.com [62.20.145.237]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id JAA04574; Sat, 17 Jun 2000 09:36:50 +0200 Message-ID: <000801bfd836$e04a1bd0$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: , "PKIX-List" Subject: A Heretic's view of Certificates Date: Sat, 17 Jun 2000 10:34:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA04471 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Interesting reading. Particularly for PKI "fundamentalists".... -----Original Message----- From: Lynn.Wheeler@firstdata.com To: ansi-epay@lists.commerce.net Date: Friday, June 16, 2000 22:14 Subject: another view of certificates > > >for another view of certificates > >http://www.DGA.co.uk/customer/publicdo.nsf/public/WP-HERESY > > From owner-ietf-pkix@imc.org Sat Jun 17 07:46:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17869 for ; Sat, 17 Jun 2000 07:46:57 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA13380; Sat, 17 Jun 2000 04:46:11 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 17 Jun 2000 04:45:26 -0700 Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13350 for ; Sat, 17 Jun 2000 04:45:24 -0700 (PDT) Received: from mega (t6o69p39.telia.com [213.64.110.159]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id NAA08097 for ; Sat, 17 Jun 2000 13:46:38 +0200 Message-ID: <000301bfd859$c5f43c70$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: "PKIX-List" Subject: Why is Java still crypto-crippled? Date: Sat, 17 Jun 2000 14:44:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA13351 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit I have since quite a while been using W2K (Bill, it IS great!) using strong crypto although I live in Europe. But why can't I get that for JDK? Without special permissions. This is a *serious* threat to Java to be dependent on third-party tools when the "other guy" has it all built-in! Anders Not religious about Java but likes it anyway. From owner-ietf-pkix@imc.org Sat Jun 17 09:43:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18839 for ; Sat, 17 Jun 2000 09:43:22 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA14632; Sat, 17 Jun 2000 06:41:32 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 17 Jun 2000 06:41:16 -0700 Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14601 for ; Sat, 17 Jun 2000 06:41:14 -0700 (PDT) Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id PAA18267; Sat, 17 Jun 2000 15:27:57 +0200 Reply-To: From: "denis bider" To: "'Anders Rundgren'" , Subject: Off-topic: crypto crippling Date: Sat, 17 Jun 2000 15:40:58 +0200 Message-ID: <000001bfd861$abccb450$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Low In-Reply-To: <000301bfd859$c5f43c70$0201a8c0@mega.vincent.se> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit [I would have posted this to the sci.crypt newsgroup, but I dislike doing that for several reasons - among them, slow message propagation, spam and last but not the least, I do not have Usenet configured and it takes a while to find a server that carries sci.crypt. Does anyone know of a regular mailing list equivalent to the sci.crypt newsgroup?] Actually, I have heard a rumour that the '128-bit encryption' that Microsoft is shipping with Windows 2000 has actually been tweaked in such a way that it is only 128-bit when observed by a non-clued-in person, but is rather 40-bit for the people who know how it has been designed. In effect, rumour therefore has it that 88 bits out of the 128 are set in such a way that it is extremely easy to find them for someone who knows how. The French are supposed to have found this out, and they are supposed to have been a little bit upset because of this fact. I am not sure how much of this is actually the truth. The person I received this information from might have confused this with the silent "3DES -> DES" fallback in Windows that has been demonstrated lately. Can anyone confirm or deny the above rumour? Anyway. The bottom line is - I think people today are a little bit crazy to use, and even buy, security software as executables without any kind of access to the source code. It is plain stupid, and it gives the country which supplied you with the binaries a perfect weapon for the information wars that are due to ensue sooner or later. The world is not all roses all the time. Remember the several-billion-dollar deal which was lost by the European airplane manufacturer to Boeing because the USA was eavesdropping on their conversations with the purchaser? Iraq, Vatican and several others have learned this lesson when they bought black-box crypto machines from Crypto AG, only to find out that the machine transmits the encryption key almost in plaintext along with the encrypted message. Which, hence, was easily recoverable by folks from the NSA and from the German intelligence agency. denis -----Original Message----- From: Anders Rundgren [mailto:anders.rundgren@jaybis.com] Sent: 17. junij 2000 14:44 To: PKIX-List Subject: Why is Java still crypto-crippled? I have since quite a while been using W2K (Bill, it IS great!) using strong crypto although I live in Europe. But why can't I get that for JDK? Without special permissions. This is a *serious* threat to Java to be dependent on third-party tools when the "other guy" has it all built-in! Anders Not religious about Java but likes it anyway. From owner-ietf-pkix@imc.org Sun Jun 18 18:47:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10847 for ; Sun, 18 Jun 2000 18:47:38 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA15067; Sun, 18 Jun 2000 15:44:46 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 18 Jun 2000 15:43:30 -0700 Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15015 for ; Sun, 18 Jun 2000 15:43:27 -0700 (PDT) Received: from santesson.accurata.se (t4o68p69.telia.com [62.20.139.189]) by popmail.inbox.se (8.9.3/8.9.3) with ESMTP id AAA25754; Mon, 19 Jun 2000 00:43:18 +0200 Message-Id: <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> X-Sender: mb517@mail.accurata.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Jun 2000 00:43:48 +0200 To: Stephen Kent From: Stefan Santesson Subject: Re: Can we form certificates with just name and e-mail address Cc: "PKIX Mailing List" In-Reply-To: References: <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Steve, At 14:13 2000-06-16 -0400, you wrote: >Christopher, > >>You put your common name (or given name + surname) in the SubjectName field >>and your e-mail address in the rfc822Name field in a SubjectAlternativeName >>field extension. I don't think that it is too important if the SubjectName >>is not unique; the combination of SubjectName and SerialNo has to be unique. > >We have had this discussion in this list. The decision was that if you're >going to use a DN field (subject name or a directory name as an alt name) >then the contents should be "reasonable" in a directory context. That's >why, when Denis Pinkas proposed a name form built from DN attributes but >not consistent with real directory use, he agreed to define a new data >type for it. The bottom line is that just because a name is constructed >from directory attributes, that does not make it a reasonable DN. Rest deleted .... So I guess you confirm my conclusion that givenName + surname in the subject field, or as a directory name in alt name, does NOT by itself form a reasonable DN. Especially since there will be duplicate names. So the only thing left seams to be putting the names in SubjectDirectoryAttributes but I have problems/thoughts with that: 1) What will the current installed base of products say about that? 2) The latest X.509 version implies that attributes stored in the SubjectDirectoryAttributes are primary for authorization and not part of the subjects name. It seams that we have no where to go. Why can't an e-mail address be part of a reasonable DN? (I guess that's what the current text implies) /Stefan From owner-ietf-pkix@imc.org Mon Jun 19 00:49:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14765 for ; Mon, 19 Jun 2000 00:49:00 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA20280; Sun, 18 Jun 2000 21:45:54 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 18 Jun 2000 21:45:42 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20245 for ; Sun, 18 Jun 2000 21:45:40 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA06771; Mon, 19 Jun 2000 14:50:32 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Mon, 19 Jun 2000 14:44:17 +1000 Message-ID: From: Michael Zolotarev To: Stefan Santesson , Stephen Kent Cc: PKIX Mailing List Subject: RE: Can we form certificates with just name and e-mail address Date: Mon, 19 Jun 2000 14:44:12 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Sorry, but I'm not quite getting what is so problematic with what Christopher and Oscar proposed: What really stops me from leaving Subject field empty, and including BOTH my e-mail address (as RFC822name) and my name/surname as a proper(!) DirectoryName into SubjectAltName field? I believe that the root of the problem is in [mis]interpretation of the "uniqueness of the name" requirement. The document says in (4.1.2.6 Subject): ------------- Where it is non-empty, the subject field MUST contain an X.500 dis- tinguished name (DN). The DN MUST be unique for each subject entity certified by the one CA as defined by the issuer name field. A CA may issue more than one certificate with the same DN to the same subject entity. -------------- This is what Stefan was referring to, right? However, there is NO such uniqueness requirement for the DN included into the SubjectAltName. Or I've missed one. So I do not see a problem with having a SubjectAltName containing non_unique DN, as long as the rest of the information in the extension makes it unique. Regards Michael > -----Original Message----- > From: Stefan Santesson [mailto:stefan@accurata.se] > Sent: Monday, June 19, 2000 8:44 AM > To: Stephen Kent > Cc: PKIX Mailing List > Subject: Re: Can we form certificates with just name and > e-mail address > > > Steve, > > > At 14:13 2000-06-16 -0400, you wrote: > >Christopher, > > > >>You put your common name (or given name + surname) in the > SubjectName field > >>and your e-mail address in the rfc822Name field in a > SubjectAlternativeName > >>field extension. I don't think that it is too important if > the SubjectName > >>is not unique; the combination of SubjectName and SerialNo > has to be unique. > > > >We have had this discussion in this list. The decision was > that if you're > >going to use a DN field (subject name or a directory name as > an alt name) > >then the contents should be "reasonable" in a directory > context. That's > >why, when Denis Pinkas proposed a name form built from DN > attributes but > >not consistent with real directory use, he agreed to define > a new data > >type for it. The bottom line is that just because a name is > constructed > >from directory attributes, that does not make it a reasonable DN. > Rest deleted .... > > So I guess you confirm my conclusion that givenName + surname in the > subject field, or as a directory name in alt name, does NOT > by itself form > a reasonable DN. Especially since there will be duplicate names. > > So the only thing left seams to be putting the names in > SubjectDirectoryAttributes but I have problems/thoughts with that: > > 1) What will the current installed base of products say about that? > 2) The latest X.509 version implies that attributes stored in the > SubjectDirectoryAttributes are primary for authorization and > not part of > the subjects name. > > It seams that we have no where to go. > > Why can't an e-mail address be part of a reasonable DN? (I > guess that's > what the current text implies) > > /Stefan > From owner-ietf-pkix@imc.org Mon Jun 19 03:45:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27548 for ; Mon, 19 Jun 2000 03:45:18 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA24957; Mon, 19 Jun 2000 00:44:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 00:43:51 -0700 Received: from keb.roamingfactory.com (aktse.appius.lejonet.telia.com [193.45.212.169] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA24926 for ; Mon, 19 Jun 2000 00:43:48 -0700 (PDT) Received: from roamingfactory.com (localhost [127.0.0.1]) by keb.roamingfactory.com (Postfix) with ESMTP id 513C5136CD; Mon, 19 Jun 2000 09:43:19 +0200 (CEST) X-Mailer: exmh version 2.1.1 10/15/1999 From: Mats.Gustafsson@roamingfactory.com To: "Christopher Williams" Cc: "PKIX Mailing List" Subject: Re: Do people have something against RSA? In-Reply-To: Message from "Christopher Williams" of "Fri, 16 Jun 2000 18:35:18 BST." <003701bfd7b9$5e4e3ad0$d8c4fc3e@darxstar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Mon, 19 Jun 2000 09:43:19 +0200 Sender: magn@roamingfactory.com Message-Id: <20000619074319.513C5136CD@keb.roamingfactory.com> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit ccwilliams@ntlworld.com said: > However, let's say that I implemented a standard, say TLS, and only > included the mandatory cipher suite, DSA with ephemeral > Diffie-Hellman, SHA-1 and 3-DES encryption. You know what? It > wouldn't work with anything! Everybody else's implementation uses RSA > so mine has to as well, whether I like it or not. Is seems to me that your reasonoing is flawed in that you assume that "everone else" will *not* include the *mandatory* cipher suite. The whole idea of having mandatory cipher suites in the first place is to assure at least one common fall back algorithm. Best regards, //Mats From owner-ietf-pkix@imc.org Mon Jun 19 05:17:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28030 for ; Mon, 19 Jun 2000 05:17:09 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA27516; Mon, 19 Jun 2000 02:13:29 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 02:13:19 -0700 Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA27477 for ; Mon, 19 Jun 2000 02:13:17 -0700 (PDT) Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id (multiple receipients); Mon, 19 Jun 2000 11:13:14 +0200 (MET DST) Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id LAA11292; Mon, 19 Jun 2000 11:12:44 +0200 (MEST) Message-ID: <394DE6C6.9CD268D8@timeproof.de> Date: Mon, 19 Jun 2000 11:24:22 +0200 From: Joerg Seidel Organization: timeproof X-Mailer: Mozilla 4.5 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: FRousseau@chrysalis-its.com CC: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <918C70B01822D411A87400B0D0204DFF04C025@panda.chrysalis-its.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Francois, comments inline. > If a TSA has more than one key for performance purposes, I would assume they > are just copies of the same private key cloned in different cryptographic > modules for performance and load balancing reasons. Since it is not possible with some cryptograpic modules to make copies of the private key... > "The TSA MUST sign all time stamp messages with one or more keys reserved > specifically for that purpose. A TSA MAY have distinct private keys to > accommodate different policies, different algorithms and/or different key > sizes." ... I suggest: "The TSA MUST sign all time stamp messages with one or more keys reserved specifically for that purpose. A TSA MAY have distinct private keys to accommodate different policies, different algorithms, different key sizes and/or to increase the performance." > I agree that TSAs should not use MD5 in their time stamps and MUST only use > strong hash functions (e.g. SHA-1, RIPEMD-160). However, there is nothing > wrong > for a requester to submit a message imprint containing a MD5 hash, which > means > that TSAs should be able accept request with MD5. You are right. If a requester insists on using MD5 it is not up to the TSA to explain him he shouldn't. Joerg -- __________________________________________________________________ Jörg Seidel phone +49-40-76629-1911 Director Technology fax +49-40-76629-551 timeproof GmbH Harburger Schloßstraße 6-12 mailto:seidel@timeproof.de DE 21079 Hamburg http://www.timeproof.de __________________________________________________________________ From owner-ietf-pkix@imc.org Mon Jun 19 05:26:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28147 for ; Mon, 19 Jun 2000 05:26:56 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA28052; Mon, 19 Jun 2000 02:25:57 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 02:25:55 -0700 Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA28021 for ; Mon, 19 Jun 2000 02:25:54 -0700 (PDT) Received: by mystic1.trustcenter.de; id LAA03029; Mon, 19 Jun 2000 11:23:54 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma003026; Mon, 19 Jun 00 11:23:09 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id LAA15097 for ; Mon, 19 Jun 2000 11:24:37 +0200 (MET DST) Message-Id: <3.0.5.32.20000619112437.0394c100@callisto> X-Sender: jbr@callisto X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 19 Jun 2000 11:24:37 +0200 To: ietf-pkix@imc.org From: Juergen Brauckmann Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt In-Reply-To: <394DE6C6.9CD268D8@timeproof.de> References: <918C70B01822D411A87400B0D0204DFF04C025@panda.chrysalis-its.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA28022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit At 11:24 19.06.00 +0200, Joerg Seidel wrote: >> If a TSA has more than one key for performance purposes, I would assume they >> are just copies of the same private key cloned in different cryptographic >> modules for performance and load balancing reasons. > >Since it is not possible with some cryptograpic modules to make copies of the >private key... And sometimes not legal... . Regards, Juergen -- Juergen Brauckmann Tel.: 040 / 8080 26 311 TC TrustCenter GmbH Fax.: 040 / 8080 26 126 Sonninstraße 24-28 mailto:brauckmann@trustcenter.de 20097 Hamburg http://www.trustcenter.de From owner-ietf-pkix@imc.org Mon Jun 19 10:18:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06829 for ; Mon, 19 Jun 2000 10:18:00 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA05882; Mon, 19 Jun 2000 07:11:08 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 07:10:41 -0700 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05840 for ; Mon, 19 Jun 2000 07:10:41 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Jun 2000 10:11:26 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C030@panda.chrysalis-its.com> To: brauckmann@trustcenter.de Cc: ietf-pkix@imc.org Subject: Private Key Cloning Date: Mon, 19 Jun 2000 10:11:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD9F8.4134A830" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD9F8.4134A830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Juergen, If a private key generated within a hardware cryptographic module is securely wrapped within that same module, is then exported to another similar hardware cryptographic module through an authenticated key = exchange where it is unwrapped and both of these private keys are then used to perform electronic signatures in a load balancing situation (e.g. OCSP = or TSA server), do you mean this would not be legal in Germany? Regards, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: Juergen Brauckmann [mailto:brauckmann@trustcenter.de] Sent: Monday, June 19, 2000 5:25 AM To: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt At 11:24 19.06.00 +0200, Joerg Seidel wrote: >> If a TSA has more than one key for performance purposes, I would = assume they >> are just copies of the same private key cloned in different = cryptographic >> modules for performance and load balancing reasons. > >Since it is not possible with some cryptograpic modules to make copies = of the >private key... And sometimes not legal... . Regards, Juergen --=20 Juergen Brauckmann Tel.: 040 / 8080 26 311 TC TrustCenter GmbH Fax.: 040 / 8080 26 126 Sonninstra=DFe 24-28 mailto:brauckmann@trustcenter.de 20097 Hamburg http://www.trustcenter.de=09 ------_=_NextPart_001_01BFD9F8.4134A830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Private Key Cloning

Juergen,

If a private key generated within a hardware = cryptographic module is securely wrapped within that same module, is = then exported to another similar hardware cryptographic module through = an authenticated key exchange where it is unwrapped and both of these = private keys are then used to perform electronic signatures in a load = balancing situation (e.g. OCSP or TSA server), do you mean this would = not be legal in Germany?

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

-----Original Message-----
From: Juergen Brauckmann [mailto:brauckmann@trustcenter.= de]
Sent: Monday, June 19, 2000 5:25 AM
To: ietf-pkix@imc.org
Subject: Re: I-D = ACTION:draft-ietf-pkix-time-stamp-08.txt


At 11:24 19.06.00 +0200, Joerg Seidel wrote:
>> If a TSA has more than one key for = performance purposes, I would assume
they
>> are just copies of the same private key = cloned in different cryptographic
>> modules for performance and load balancing = reasons.
>
>Since it is not possible with some cryptograpic = modules to make copies of the
>private key...

And sometimes not legal... .

Regards,
   Juergen

--
Juergen = Brauckmann          &n= bsp;  Tel.:  040 / 8080 26 311
TC TrustCenter = GmbH            = Fax.:  040 / 8080 26 126
Sonninstra=DFe 24-28      =     mailto:brauckmann@trustcenter.= de
20097 Hamburg   =             http://www.trustcenter.de  

------_=_NextPart_001_01BFD9F8.4134A830-- From owner-ietf-pkix@imc.org Mon Jun 19 10:27:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07192 for ; Mon, 19 Jun 2000 10:27:03 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA06289; Mon, 19 Jun 2000 07:23:49 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 07:23:47 -0700 Received: from firewall1.glaxowellcome.com (firewall-user@firewall1.glaxowellcome.com [192.58.204.204]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06257 for ; Mon, 19 Jun 2000 07:23:32 -0700 (PDT) Received: by firewall1.glaxowellcome.com; id KAA28646; Mon, 19 Jun 2000 10:23:45 -0400 (EDT) Received: from ussun2m.glaxo.com(152.51.20.99) by firewall1.glaxowellcome.com via smap (V5.5) id xma028134; Mon, 19 Jun 00 10:22:25 -0400 Received: by ussun2m.glaxo.com id KAA09589; Mon, 19 Jun 2000 10:21:55 -0400 (EDT) Received: from 152.51.60.17 by securemail1.glaxo.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Mon, 19 Jun 2000 10:11:20 -0400 X-Server-Uuid: c7fabf50-5a2e-11d2-968c-00805fc1f894 Received: from 152.51.4.175 by securemail1.glaxo.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Mon, 19 Jun 2000 05:27:59 -0400 X-Server-Uuid: c7fabf50-5a2e-11d2-968c-00805fc1f894 Received: by ussun1d.glaxo.com id FAA19500; Mon, 19 Jun 2000 05:27:58 -0400 (EDT) Received: by firewall3.glaxowellcome.com; id FAA19426; Mon, 19 Jun 2000 05:20:08 -0400 (EDT) Received: from ns.secondary.com(208.184.76.39) by firewall3.glaxowellcome.com via smap (V5.5) id xma019398; Mon, 19 Jun 00 05:19:44 -0400 Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA28131; Mon, 19 Jun 2000 02:27:21 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 02:25:55 -0700 Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA28021 for ; Mon, 19 Jun 2000 02:25:54 -0700 (PDT) Received: by mystic1.trustcenter.de; id LAA03029; Mon, 19 Jun 2000 11: 23:54 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma003026; Mon, 19 Jun 00 11:23:09 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id LAA15097 for ; Mon, 19 Jun 2000 11:24:37 +0200 (MET DST) Message-ID: <3.0.5.32.20000619112437.0394c100@callisto> X-Sender: jbr@callisto X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 19 Jun 2000 11:24:37 +0200 To: ietf-pkix@imc.org From: "Juergen Brauckmann" Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt In-Reply-To: <394DE6C6.9CD268D8@timeproof.de> References: <918C70B01822D411A87400B0D0204DFF04C025@panda.chrysalis-its.com> MIME-Version: 1.0 X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA28022 X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id CAA28131 X-WSS-ID: 1550F58213824-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA06260 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit At 11:24 19.06.00 +0200, Joerg Seidel wrote: >> If a TSA has more than one key for performance purposes, I would assume they >> are just copies of the same private key cloned in different cryptographic >> modules for performance and load balancing reasons. > >Since it is not possible with some cryptograpic modules to make copies of the >private key... And sometimes not legal... . Regards, Juergen -- Juergen Brauckmann Tel.: 040 / 8080 26 311 TC TrustCenter GmbH Fax.: 040 / 8080 26 126 Sonninstraße 24-28 mailto:brauckmann@trustcenter.de 20097 Hamburg http://www.trustcenter.de From owner-ietf-pkix@imc.org Mon Jun 19 10:40:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07954 for ; Mon, 19 Jun 2000 10:40:44 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA07883; Mon, 19 Jun 2000 07:39:10 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 07:39:08 -0700 Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA07852 for ; Mon, 19 Jun 2000 07:39:06 -0700 (PDT) Received: by mystic1.trustcenter.de; id QAA05317; Mon, 19 Jun 2000 16:37:06 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma005312; Mon, 19 Jun 00 16:36:10 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id QAA29190; Mon, 19 Jun 2000 16:37:39 +0200 (MET DST) Message-Id: <3.0.5.32.20000619163739.00c31670@callisto> X-Sender: jbr@callisto X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 19 Jun 2000 16:37:39 +0200 To: FRousseau@chrysalis-its.com From: Juergen Brauckmann Subject: Re: Private Key Cloning Cc: ietf-pkix@imc.org In-Reply-To: <918C70B01822D411A87400B0D0204DFF04C030@panda.chrysalis-its .com> Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: quoted-printable At 10:11 19.06.00 -0400, you wrote:=20 >If a private key generated within a hardware cryptographic module is securely wrapped within that=20 >same module, is then exported to another similar hardware cryptographic module through an=20 >authenticated key exchange where it is unwrapped and both of these private keys are then used to=20 >perform electronic signatures in a load balancing situation (e.g. OCSP or TSA server), do you mean=20 >this would not be legal in Germany? It is of course legal if you don't want to conform to the German Digital Signature Act. It is not legal if you operate according to that Act. In fact it's a requirement to the equipment that it's not possible to duplicate the key. It makes some sense to forbid a single user to duplicate it's key if that key is to be used for "valuable" signatures (this minimizes the risk that the key may be stolen or lost unnoticed). The problem is that the current German Signature Act does not take into account that the scenario you described above is necessary for servers. Regards, Juergen --=20 Juergen Brauckmann Tel.: 040 / 8080 26 311 TC TrustCenter GmbH Fax.: 040 / 8080 26 126 Sonninstra=DFe 24-28 mailto:brauckmann@trustcenter.de 20097 Hamburg http://www.trustcenter.de=09 From owner-ietf-pkix@imc.org Mon Jun 19 10:50:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08513 for ; Mon, 19 Jun 2000 10:50:40 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA08562; Mon, 19 Jun 2000 07:48:25 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 07:48:21 -0700 Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08528 for ; Mon, 19 Jun 2000 07:48:20 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiugp02778; Mon, 19 Jun 2000 14:48:19 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA27210; Mon, 19 Jun 00 10:44:39 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA23823; Mon, 19 Jun 2000 10:48:17 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14670.12977.681919.987123@xedia.com> Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT) To: FRousseau@chrysalis-its.com Cc: brauckmann@trustcenter.de, ietf-pkix@imc.org Subject: Re: Private Key Cloning References: <918C70B01822D411A87400B0D0204DFF04C030@panda.chrysalis-its.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit >>>>> "FRousseau" == FRousseau writes: FRousseau> Juergen, If a private key generated within a hardware FRousseau> cryptographic module is securely wrapped within that same FRousseau> module, is then exported to another similar hardware FRousseau> cryptographic module through an authenticated key exchange FRousseau> where it is unwrapped and both of these private keys are FRousseau> then used to perform electronic signatures in a load FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean FRousseau> this would not be legal in Germany? How would you guarantee that there's no man in the middle? The only way would be to have a prior out of band secure setup of authenticating data, such as a shared secret or public keys used for this key exchange process. While the user of such a device can ensure that this is done right, the manufacturer of the devices cannot. It doesn't surprise me at all to see devices that don't allow this. It makes good security sense to omit such a capability. paul From owner-ietf-pkix@imc.org Mon Jun 19 11:03:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09315 for ; Mon, 19 Jun 2000 11:03:03 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA09358; Mon, 19 Jun 2000 08:00:11 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 08:00:08 -0700 Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09324 for ; Mon, 19 Jun 2000 08:00:07 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiugp23126; Mon, 19 Jun 2000 14:59:55 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA27396; Mon, 19 Jun 00 10:56:15 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA25234; Mon, 19 Jun 2000 10:59:54 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14670.13673.725862.625427@xedia.com> Date: Mon, 19 Jun 2000 10:59:53 -0400 (EDT) To: seidel@timeproof.de Cc: FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <918C70B01822D411A87400B0D0204DFF04C01F@panda.chrysalis-its.com> <39492EF4.CE266284@timeproof.de> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit >>>>> "Joerg" == Joerg Seidel writes: Joerg> Comments inline. >> TSA implementations MUST support SHA-1. TSA implementations >> SHOULD support MD5. Joerg> I think there are good reasons not to use MD5 in time Joerg> stamps. They should use a strong hash function in order to Joerg> achive long validity periods. MD5 is likely to be unsafe (=not Joerg> collision free) soon and is already discuraged by german Joerg> authorities. Joerg> IF we add a section about algorithms, it should maybe read: Joerg> "TSA implementations MUST support SHA-1. TSA implementations Joerg> SHOULD NOT support MD5.". But I think such a section is not Joerg> very necessary. IANAC, but from what I understand the currently known attacks on MD5 are nowhere near strong enough to justify that. I don't have a problem with the current text (SHA-1 required, MD5 recommended). I do have a problem with text that implies that MD5 is bad, because I don't know of data that supports such an assertion. Also, it doesn't seem like a good idea for the timestamp spec to give very different signals from the other security specs. If there really is good reason to say these kinds of things about MD5, let's have them identified. (German authorities are not a good reason. Cryptanalysis that shows weaknesses of interesting size would be.) If the issues are real, changes to MD5 text should be applied across the board. paul From owner-ietf-pkix@imc.org Mon Jun 19 13:18:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16667 for ; Mon, 19 Jun 2000 13:18:19 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19433; Mon, 19 Jun 2000 10:14:46 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 10:14:37 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19401 for ; Mon, 19 Jun 2000 10:14:37 -0700 (PDT) Received: from shorter.eng.sun.com ([129.144.250.35]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28635; Mon, 19 Jun 2000 10:14:32 -0700 (PDT) Received: from rosendale (rosendale [129.144.250.155]) by shorter.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id KAA11089; Mon, 19 Jun 2000 10:09:52 -0700 (PDT) Message-Id: <200006191709.KAA11089@shorter.eng.sun.com> Date: Mon, 19 Jun 2000 10:09:53 -0700 (PDT) From: Sharon Liu Reply-To: Sharon Liu Subject: Re: Why is Java still crypto-crippled? To: anders.rundgren@jaybis.com Cc: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UN12bPu1ZTtFMm8JP9ZvOw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4 SunOS 5.7 sun4u sparc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Anders, There are on-going works to make strong crypto into JDK. Sun's JCE (Java Cryptography Extension) 1.2.1 is exportable. It is currently in Beta, and its global distribution has restrictions on available crypto strength. Sun has filed a new JCE export application to remove the crypto restrictions in JCE global distribution. Once that application gets approved by the U.S. government, we'll have a single JCE distribution for both domestic and global users. Then we plan to move JCE into JDK (note: JCE was initially introduced as a Java 2 extension due to the U.S export regulations). This is depend on the Java Community Process. Hope this helps a bit. Thanks, Sharon ------------- Begin Forwarded Message ------------- From: "Anders Rundgren" To: "PKIX-List" Subject: Why is Java still crypto-crippled? Date: Sat, 17 Jun 2000 14:44:25 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA13351 List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I have since quite a while been using W2K (Bill, it IS great!) using strong crypto although I live in Europe. But why can't I get that for JDK? Without special permissions. This is a *serious* threat to Java to be dependent on third-party tools when the "other guy" has it all built-in! Anders Not religious about Java but likes it anyway. ------------- End Forwarded Message ------------- From owner-ietf-pkix@imc.org Mon Jun 19 13:19:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16825 for ; Mon, 19 Jun 2000 13:19:28 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19646; Mon, 19 Jun 2000 10:17:10 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 10:17:08 -0700 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19607 for ; Mon, 19 Jun 2000 10:17:07 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5JHCLX19816 for ; Mon, 19 Jun 2000 10:12:21 -0700 (PDT) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FWEVZO01.2S4; Mon, 19 Jun 2000 10:16:36 -0700 Message-ID: <394E5572.67272FC0@netscape.com> Date: Mon, 19 Jun 2000 10:16:34 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Santesson CC: Stephen Kent , PKIX Mailing List Subject: Re: Can we form certificates with just name and e-mail address References: <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Stefan Santesson wrote: > .... > > Why can't an e-mail address be part of a reasonable DN? (I guess that's > what the current text implies) > There is no reason that it can't be. In fact, I believe that e=name@isp.com is a perfectly good DN. It's probably not a good DN in the X.509 world, since it isn't very helpful in locating the portion of the "global" directory that actually contains the entry. It is a unique name and probably will work in many LDAP or other directory environments. The RFC deprecates using an email component of the DN as the RFC822 name for delivering email. This means that you need to put the email address in the Subject Alternate Name extension as well, to allow S/MIME (and other) applications to find it there. It does not mean that it is disallowed as a component in the DN. Terry From owner-ietf-pkix@imc.org Mon Jun 19 13:47:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18249 for ; Mon, 19 Jun 2000 13:47:15 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA21086; Mon, 19 Jun 2000 10:45:18 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 10:45:10 -0700 Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21050 for ; Mon, 19 Jun 2000 10:45:08 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA22416 for ; Mon, 19 Jun 2000 13:37:05 -0400 (EDT) Message-Id: <200006191737.NAA22404@roadblock.missi.ncsc.mil> Date: Mon, 19 Jun 2000 13:42:52 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Can we form certificates with just name and e-mail address To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4WQznHPMAzrZebsnHHg4Cw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > From: Stefan Santesson > > ... > > Why can't an e-mail address be part of a reasonable DN? (I guess that's > what the current text implies) > > /Stefan DNS is a (the only?) universal-coverage name registration system, and although one would never know it by examining current X.509 certificates, "reasonable" does not have to mean "beginning with a Country= RDN". So one reasonable DN might be: "DC=se, DC=accurata, SN=stefan + CN=Stefan Santesson" This is semantically identical to a null DN and an rfc822Name in the subjectAltName extension, and if there were an RFC spelling out some equivalence rules, applications might someday be able to translate between the rfc822Name format and the RDNSequence format as required. From owner-ietf-pkix@imc.org Mon Jun 19 14:25:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19510 for ; Mon, 19 Jun 2000 14:25:42 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA22646; Mon, 19 Jun 2000 11:24:33 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 11:24:20 -0700 Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22602 for ; Mon, 19 Jun 2000 11:24:19 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id OAA03461 for ; Mon, 19 Jun 2000 14:15:47 -0400 (EDT) Message-Id: <200006191815.OAA03454@roadblock.missi.ncsc.mil> Date: Mon, 19 Jun 2000 14:21:34 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Private Key Cloning To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NG2ebhAazn8tGK/TbEmeFA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > From: Paul Koning > Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT) > To: FRousseau@chrysalis-its.com > Cc: brauckmann@trustcenter.de, ietf-pkix@imc.org > Subject: Re: Private Key Cloning > > >>>>> "FRousseau" == FRousseau writes: > > FRousseau> Juergen, If a private key generated within a hardware > FRousseau> cryptographic module is securely wrapped within that same > FRousseau> module, is then exported to another similar hardware > FRousseau> cryptographic module through an authenticated key exchange > FRousseau> where it is unwrapped and both of these private keys are > FRousseau> then used to perform electronic signatures in a load > FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean > FRousseau> this would not be legal in Germany? > > How would you guarantee that there's no man in the middle? The only > way would be to have a prior out of band secure setup of > authenticating data, such as a shared secret or public keys used for > this key exchange process. While the user of such a device can ensure > that this is done right, the manufacturer of the devices cannot. > > It doesn't surprise me at all to see devices that don't allow this. > It makes good security sense to omit such a capability. > > paul And it doesn't seem to present insurmountable obstacles to load balancing ... why shouldn't each server have its own signature key? Is there a reason not to use N certificates with identical distinguished names and different public keys? From owner-ietf-pkix@imc.org Mon Jun 19 14:48:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20072 for ; Mon, 19 Jun 2000 14:48:09 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA23713; Mon, 19 Jun 2000 11:46:18 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 11:46:16 -0700 Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23682 for ; Mon, 19 Jun 2000 11:46:15 -0700 (PDT) Received: from Vigenere.secorvo.de (p3E9E7CB1.dip0.t-ipconnect.de [62.158.124.177]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id UAA11461; Mon, 19 Jun 2000 20:28:08 +0200 Message-Id: <4.2.0.58.20000619173932.0097a940@mail.antech.de> X-Sender: hammer.secorvo@mail.antech.de X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 19 Jun 2000 17:44:17 +0200 To: FRousseau@chrysalis-its.com, brauckmann@trustcenter.de From: Volker Hammer Subject: Re: Private Key Cloning Cc: ietf-pkix@imc.org In-Reply-To: <918C70B01822D411A87400B0D0204DFF04C030@panda.chrysalis-its .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi, >Juergen, > >If a private key generated within a hardware cryptographic module is securely wrapped within that same module, is then exported to another similar hardware cryptographic module through an authenticated key exchange where it is unwrapped and both of these private keys are then used to perform electronic signatures in a load balancing situation (e.g. OCSP or TSA server), do you mean this would not be legal in Germany? why you don't want to use two (or more) different key-pairs for different / fallback servers? For every key a similar certificate can be issued. This should not be a problem except for root certificates. For TSA or OCSP servers key cloning seems not to be necessary from my point of view. Regards Volker Hammer. -------------------------------------------------------- Dr.-Ing. Volker Hammer Security Consultant Secorvo Security Consulting GmbH Albert-Nestler-Strasse 9, D-76131 Karlsruhe Tel. +49 721 6105-458, Fax +49 721 6105-455 E-Mail hammer@secorvo.de, http://www.secorvo.de -------------------------------------------------------- PGP-Fingerprint 3C9C AD64 AC6B 64CC FA6B AE8D 2A5D 462D From owner-ietf-pkix@imc.org Mon Jun 19 14:58:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20351 for ; Mon, 19 Jun 2000 14:58:09 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA24162; Mon, 19 Jun 2000 11:55:55 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 11:55:52 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24129 for ; Mon, 19 Jun 2000 11:55:51 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA16929; Mon, 19 Jun 2000 14:55:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <394E5572.67272FC0@netscape.com> References: <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> <394E5572.67272FC0@netscape.com> Date: Mon, 19 Jun 2000 14:52:56 -0400 To: thayes@netscape.com (Terry Hayes) From: Stephen Kent Subject: Re: Can we form certificates with just name and e-mail address Cc: Stefan Santesson , PKIX Mailing List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Terry, >Stefan Santesson wrote: > > > .... > > > > Why can't an e-mail address be part of a reasonable DN? (I guess that's > > what the current text implies) > > > >There is no reason that it can't be. In fact, I believe that >e=name@isp.com is a >perfectly good DN. It's probably not a good DN in the X.509 world, >since it isn't >very helpful in locating the portion of the "global" directory that actually >contains the entry. It is a unique name and probably will work in >many LDAP or >other directory environments. I think you mean in the "X.500 world" not "the X.509 world." X.509 deals with certs and CRLs, whereas X.500 is the broader directory environment. DNs are X.500 constructs, not X.509 constructs, so it is in the directory context that one ought to evaluate the appropriateness of a candidate DN. In that context, the example you provide is not a good one, e.g., for the searching reasons you cite, as well as others. David Kemp's suggestion is an example of what one could reasonably do to map a DNS name into the DIT. However, I disagree with David in that a real DN, if it does not begin with a country code attribute, should begin with an international organization attribute (e.g., for the OCRC, NATO, UN, etc.). The DNS, for legacy reasons, has a handful of TLDs that are not country names, which has been the source of numerous name battles, scaling problems, etc. >The RFC deprecates using an email component of the DN as the RFC822 name for >delivering email. This means that you need to put the email address in the >Subject Alternate Name extension as well, to allow S/MIME (and >other) applications >to find it there. It does not mean that it is disallowed as a >component in the >DN. I don't think I would characterize the 2459 discussion of e-mail addresses in names in quite this way. What section 4.1.2.6 says is that newly generated certs should not contain an EmailAddress attribute in the Subject name field. Instead, the preferred approach is to place the e-mail address in a subject alt name of the type rfc822name. If a non-null subject name is present, it may include an EmailAddress attribute, but such inclusion is permitted for backwards compatibility, and it is deprecated. The overall message from this text is that EmailAddress is a directory attribute that has no place in a DN, but we allow it, with prejudice, to avoid breaking existing (S/MIME) systems. Going forward, the right approach is to put an e-mail address into the subject alt name using the name type designed to carry it. Steve From owner-ietf-pkix@imc.org Mon Jun 19 15:17:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20917 for ; Mon, 19 Jun 2000 15:17:16 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA25016; Mon, 19 Jun 2000 12:16:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 12:16:10 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24986 for ; Mon, 19 Jun 2000 12:16:09 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA20757; Mon, 19 Jun 2000 15:15:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 19 Jun 2000 15:15:47 -0400 To: Michael Zolotarev From: Stephen Kent Subject: RE: Can we form certificates with just name and e-mail address Cc: Stefan Santesson , PKIX Mailing List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Zolotarev, >Sorry, but I'm not quite getting what is so problematic with what >Christopher and Oscar proposed: > >What really stops me from leaving Subject field empty, and including BOTH my >e-mail address (as RFC822name) and my name/surname as a proper(!) >DirectoryName into SubjectAltName field? > >I believe that the root of the problem is in [mis]interpretation of the >"uniqueness of the name" requirement. The document says in (4.1.2.6 >Subject): >------------- > Where it is non-empty, the subject field MUST contain an X.500 dis- > tinguished name (DN). The DN MUST be unique for each subject entity > certified by the one CA as defined by the issuer name field. A CA may > issue more than one certificate with the same DN to the same subject > entity. >-------------- >This is what Stefan was referring to, right? > >However, there is NO such uniqueness requirement for the DN included into >the SubjectAltName. Or I've missed one. So I do not see a problem with >having a SubjectAltName containing non_unique DN, as long as the rest of the >information in the extension makes it unique. We're in the process of revising the alt subject name text, and one of the proposed changes is to treat it as stringently as the subject name. I believe text citing the uniqueness check, as well as CA verification, has been circulated. Irrespective of this, other traffic I've just sent discusses the question of whether/how an email address fits into a DN. Steve From owner-ietf-pkix@imc.org Mon Jun 19 15:18:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21006 for ; Mon, 19 Jun 2000 15:18:04 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA24958; Mon, 19 Jun 2000 12:15:59 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 12:15:56 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24926 for ; Mon, 19 Jun 2000 12:15:55 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA20722; Mon, 19 Jun 2000 15:15:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> References: <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> Date: Mon, 19 Jun 2000 15:12:51 -0400 To: Stefan Santesson From: Stephen Kent Subject: Re: Can we form certificates with just name and e-mail address Cc: "PKIX Mailing List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Stefan, >Steve, > > >At 14:13 2000-06-16 -0400, you wrote: >>Christopher, >> >>>You put your common name (or given name + surname) in the SubjectName field >>>and your e-mail address in the rfc822Name field in a SubjectAlternativeName >>>field extension. I don't think that it is too important if the SubjectName >>>is not unique; the combination of SubjectName and SerialNo has to be unique. >> >>We have had this discussion in this list. The decision was that if >>you're going to use a DN field (subject name or a directory name as >>an alt name) then the contents should be "reasonable" in a >>directory context. That's why, when Denis Pinkas proposed a name >>form built from DN attributes but not consistent with real >>directory use, he agreed to define a new data type for it. The >>bottom line is that just because a name is constructed from >>directory attributes, that does not make it a reasonable DN. >Rest deleted .... > >So I guess you confirm my conclusion that givenName + surname in the >subject field, or as a directory name in alt name, does NOT by >itself form a reasonable DN. Especially since there will be >duplicate names. Right. > >So the only thing left seams to be putting the names in >SubjectDirectoryAttributes but I have problems/thoughts with that: > >1) What will the current installed base of products say about that? I don't know. Many would probably ignore attributes in that extension. >2) The latest X.509 version implies that attributes stored in the >SubjectDirectoryAttributes are primary for authorization and not >part of the subjects name. Right again. >It seams that we have no where to go. > >Why can't an e-mail address be part of a reasonable DN? (I guess >that's what the current text implies) The argument is that a DN is the name of an entry in the DIT. One would not create a schema where a e-mail address was tacked onto the end of an otherwise good DN. It would create an additional layer of the tree that served no purpose, as it dangles under the real user entry. An e-mail address is an alternative way of identifying an entity. Thus it is a perfectly fine attribute for a directory entry, but it makes no sense as an added attribute in a DN. Steve From owner-ietf-pkix@imc.org Mon Jun 19 15:29:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21304 for ; Mon, 19 Jun 2000 15:29:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA25511; Mon, 19 Jun 2000 12:27:29 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 12:27:23 -0700 Received: from ponyexpress8.csc.com (ponyexpress8.csc.com [208.219.64.209]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25477 for ; Mon, 19 Jun 2000 12:27:22 -0700 (PDT) From: ghilborn@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress8.csc.com with smtp (Exim 2.12 #1) id 1347C0-00000P-02 for ietf-pkix@imc.org; Mon, 19 Jun 2000 15:26:44 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256903.006AD9F5 ; Mon, 19 Jun 2000 15:27:06 -0400 X-Lotus-FromDomain: CSC To: ietf-pkix@imc.org Message-ID: <85256903.006AA56B.00@csc.com> Date: Mon, 19 Jun 2000 15:24:05 -0400 Subject: Re: Private Key Cloning Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe The issue is relevant only for for a very basic PKI. The wish is to have a single trust anchor of one public key, no sub-CAs, yet assure availability and load balance the CA service by cloned copies of the CA server (and its key). This scenario pre-empts by definition each server having its own key. However, it also conflicts with the no-copy rule. -Gene Hilborn dpkemp@roadblock.missi.ncsc.mil on 06/19/2000 02:21:34 PM Please respond to dpkemp@roadblock.missi.ncsc.mil To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: Re: Private Key Cloning > From: Paul Koning > Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT) > To: FRousseau@chrysalis-its.com > Cc: brauckmann@trustcenter.de, ietf-pkix@imc.org > Subject: Re: Private Key Cloning > > >>>>> "FRousseau" == FRousseau writes: > > FRousseau> Juergen, If a private key generated within a hardware > FRousseau> cryptographic module is securely wrapped within that same > FRousseau> module, is then exported to another similar hardware > FRousseau> cryptographic module through an authenticated key exchange > FRousseau> where it is unwrapped and both of these private keys are > FRousseau> then used to perform electronic signatures in a load > FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean > FRousseau> this would not be legal in Germany? > > How would you guarantee that there's no man in the middle? The only > way would be to have a prior out of band secure setup of > authenticating data, such as a shared secret or public keys used for > this key exchange process. While the user of such a device can ensure > that this is done right, the manufacturer of the devices cannot. > > It doesn't surprise me at all to see devices that don't allow this. > It makes good security sense to omit such a capability. > > paul And it doesn't seem to present insurmountable obstacles to load balancing ... why shouldn't each server have its own signature key? Is there a reason not to use N certificates with identical distinguished names and different public keys? From owner-ietf-pkix@imc.org Mon Jun 19 15:40:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21629 for ; Mon, 19 Jun 2000 15:40:35 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA25798; Mon, 19 Jun 2000 12:36:30 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 12:36:28 -0700 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25768 for ; Mon, 19 Jun 2000 12:36:26 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id VAA16668; Mon, 19 Jun 2000 21:36:17 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 19 Jun 2000 21:36:17 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id VAA12480; Mon, 19 Jun 2000 21:36:16 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id VAA13173; Mon, 19 Jun 2000 21:36:16 +0200 (MET DST) Date: Mon, 19 Jun 2000 21:36:16 +0200 (MET DST) Message-Id: <200006191936.VAA13173@emeriau.edelweb.fr> To: Peter.Sylvester@EdelWeb.fr, FRousseau@chrysalis-its.com Subject: RE: TSP Draft 08 Cc: ietf-pkix@imc.org Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > > Peter, > > I disagree that the addition of the ordering flag is creating any > incompatibility issue since the TSA document is still only an Internet Draft > that should not have been used to develop any commercial product until it > becomes an RFC. In addition, I think it is much more meaningful to require > the flag to be present to indicate that ordering is supported as currently > mandated by the latest TSA document. I did not say that the changings had created any incompatibility in commercial products. I have said the spec is incompatible with the previous texts Some parts of the text had been 'stable' since two years or so, and get suddenly changed. Well, the token format is so small, that modifications of the actual syntax do not really influence product designers to prepare all the other stuff. An implementation that used draft 7 spec and did not set accuracy and by used a serialnumber that contains some encoded value can easily retransform the serialnumber into genTime with the need of using ordering for comparisions. Thje only problem is that when you receive such a time stamp, it doesn't tell that there is ordering. Since the very beginning the ordering was defined solely by the order of the serialnumber. There was no even mention about the order of the genTime values. Thus you could have all kinds of equal genTime values and even genTimes in different order than the serialnumber. In version 8 the serialnumber of the timestamp has no real purpose anymore inside this protocol; it is not used at all in any other protocol elements like in crls or esscertid etc. To resume (somewhat flame) : I disagree with Ed Gerck; the model is not broken, there is simply no service model. > > I agree however that there must be a way for a TSA to publish which of the > ordering services it supports. As a minimum this should be done through the > TSA's policy and it could possibly be done through the Subject Information > Access (SIA) extension from the son of RFC 2459 if it contained a similar > ordering flag. By using the reqPolicy field a requester could then request > the appropriate service if a TSA offers different ordering services. I would like to repeat a question that I had already asked several times on that list: An equivalent of SIA was in drafts of X.509 and 2459. When did this disappear and why? There were two extensions, the other one was telling something about a CA subject. > > I also agree that the document should indicate if a TSA has to set the > ordering in a identical way in ALL of its time stamps. I would think that if > a TSA explicitly indicate that it will not support ordering (e.g. through > the TSA's policy or the SIA extension), Time Stamp tokens issued from this > TSA MUST NEVER have the ordering field set to true. However, if a TSA > explicitly indicate that it will support ordering, all Time Stamp tokens > issued from this TSA SHOULD have the ordering field set to true unless the > TSA can not longer do this because of some technical problems. This would > then be a good reason to use the value of one (1) in the structure > "PKIStatus" (i.e. grantedWithMods). You suggest that a TSA that provides an ordered set may want to switch to a reduced service. Why not just giving an error? An application that really need an order would have to loop and reask until a orderable stamp is returned. If the order is not necessary then I would use the other type of service. Or, if grantedWithMods is done, one can simply add a failurebit indicating that 'order not guaranteed contrary of what is indicated in the TSA's cert.' /P From owner-ietf-pkix@imc.org Mon Jun 19 16:17:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22657 for ; Mon, 19 Jun 2000 16:17:33 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA26559; Mon, 19 Jun 2000 13:15:33 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 13:15:28 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26529 for ; Mon, 19 Jun 2000 13:15:27 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA02204; Mon, 19 Jun 2000 16:15:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <000801bfd836$e04a1bd0$0201a8c0@mega.vincent.se> References: <000801bfd836$e04a1bd0$0201a8c0@mega.vincent.se> Date: Mon, 19 Jun 2000 16:11:24 -0400 To: "Anders Rundgren" From: Stephen Kent Subject: Re: A Heretic's view of Certificates Cc: "PKIX-List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Anders, Part of this material, like the Schneier and Ellison article, makes the mistake of equating X.509 with the trusted third party model of VeriSign, CyberTrust, etc. The figure in Section 4 illustrates this bias. The author acts as thought the 10 point list from that article is some sort of holy grail, rather than what is really was, i.e., a list of points of a length inspired by David Letterman. The discussion of revocation is a bit naive. It seems to assume a push model, whereas traditional X.509 is pull, as is OCSP. The argument about the implied net traffic associated with maintaining CRLs for a very large population is just hand waving, with no good analysis. The author places way too much emphasis on the browser model of a PKI, which is not a very good one, especially for the B2B transactions that are the focus of the article. Again, a strawman. The author's most significant criticisms of current PKI models are contained in Section 5, and there are several seriously flawed arguments. For example, he claims that some of the conditions that he sets as requirements cannot be met because existing (already issued) certs do not meet these requirements. This is an interesting criticism, since the suggestion is that one can develop and deploy a new, different system (of the author's design) but cannot reissue certs to meet his declared requirements! He misunderstands options for retention of certs and CRLs in support of NR, and argues that anything that LDAP does not do now will not change. (Anyone who has followed the progress of LDAP would know better!) More errors arise in this discussion, but one ought not be surprised since the goal of this section is as a strawman to motivate the author's proposal. Most, if not all, of what the author proposes, in Section 7, can be effected with X.509 certificates, based on PKI models that are organizational and/or geopolitical in scope, rather than TTP-based PKIs. Some details of his proposals require changes (or usage restrictions) to current e-mail and web protocols. (For example, the function assigned to a secure e-mail proxy could be effected using the S/MIME triple-wrapping feature. The author alludes to signing an "SMTP envelope," which causes me to question the depth of his protocol knowledge.) If these functions were deemed important, they could be supported just as well with X.509 as with his newly minted "credentials." Other aspects of this model merely reflect implementation choices for such PKI elements as certification policy statements. Some aspects of model also appears to be consistent with the ongoing PKIX work on delegated cert path validation, for those who desire to adopt this approach. The model is thus a mix of new data types, implementation options, and a few assurance mandates. Finally, when one gets to the end of this text, it appears to be promotional (marketing) material for some products/services that the author is hoping to sell. So, Anders, what exactly was your point? Steve From owner-ietf-pkix@imc.org Mon Jun 19 18:08:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24475 for ; Mon, 19 Jun 2000 18:08:12 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA28465; Mon, 19 Jun 2000 15:07:21 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 15:07:12 -0700 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28428 for ; Mon, 19 Jun 2000 15:07:11 -0700 (PDT) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id PAA04137 for ; Mon, 19 Jun 2000 15:07:13 -0700 (PDT) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 19 Jun 2000 22:07:12 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 19 Jun 2000 15:07:10 -0700 Message-ID: <8DCFE693DDFFD111AC4100A0C9B8DB940156608F@hdsmsx33.hd.intel.com> From: "Eissa, Mohamed" To: "'ietf-pkix@imc.org'" Subject: Certificate Retrieval from LDAP/CA Date: Mon, 19 Jun 2000 13:12:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hi, In general, after a user submits a certificate request, is it better to retrieve issued certificates from LDAP server? or from CA server? and why? Also, is PKIX capable of retrieving certificates from LDAP and CA servers or CAs only? Thanks, Mohamed From owner-ietf-pkix@imc.org Mon Jun 19 18:53:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25098 for ; Mon, 19 Jun 2000 18:53:53 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA29477; Mon, 19 Jun 2000 15:50:38 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 15:49:56 -0700 Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA29434 for ; Mon, 19 Jun 2000 15:49:51 -0700 (PDT) Received: from santesson.accurata.se (lon-qbu-gyt-vty28.as.wcom.net [195.232.106.28]) by popmail.inbox.se (8.9.3/8.9.3) with ESMTP id AAA24276; Tue, 20 Jun 2000 00:49:25 +0200 Message-Id: <4.3.2.7.2.20000620004422.00c11850@mail.accurata.se> X-Sender: mb517@mail.accurata.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Jun 2000 00:50:22 +0200 To: Stephen Kent From: Stefan Santesson Subject: Re: Can we form certificates with just name and e-mail address Cc: "PKIX Mailing List" In-Reply-To: References: <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Steve, Thank's for useful input. Just to round this up, can you confirm the conclusion that issuing certificates where subjects are represented by just e-mail address + givenName + surname (and maybe also country) is simply not possible. The name must simply be combined with a serialNumber attribute or some other information that makes the name (with e-mail address excluded) a reasonable DN. Right? /Stefan At 15:12 2000-06-19 -0400, Stephen Kent wrote: >Stefan, > >>Steve, >> >> >>At 14:13 2000-06-16 -0400, you wrote: >>>Christopher, >>> >>>>You put your common name (or given name + surname) in the SubjectName field >>>>and your e-mail address in the rfc822Name field in a SubjectAlternativeName >>>>field extension. I don't think that it is too important if the SubjectName >>>>is not unique; the combination of SubjectName and SerialNo has to be >>>>unique. >>> >>>We have had this discussion in this list. The decision was that if >>>you're going to use a DN field (subject name or a directory name as an >>>alt name) then the contents should be "reasonable" in a directory >>>context. That's why, when Denis Pinkas proposed a name form built from >>>DN attributes but not consistent with real directory use, he agreed to >>>define a new data type for it. The bottom line is that just because a >>>name is constructed from directory attributes, that does not make it a >>>reasonable DN. >>Rest deleted .... >> >>So I guess you confirm my conclusion that givenName + surname in the >>subject field, or as a directory name in alt name, does NOT by itself >>form a reasonable DN. Especially since there will be duplicate names. > >Right. > >> >>So the only thing left seams to be putting the names in >>SubjectDirectoryAttributes but I have problems/thoughts with that: >> >>1) What will the current installed base of products say about that? > >I don't know. Many would probably ignore attributes in that extension. > >>2) The latest X.509 version implies that attributes stored in the >>SubjectDirectoryAttributes are primary for authorization and not part of >>the subjects name. > >Right again. > >>It seams that we have no where to go. >> >>Why can't an e-mail address be part of a reasonable DN? (I guess that's >>what the current text implies) > >The argument is that a DN is the name of an entry in the DIT. One would >not create a schema where a e-mail address was tacked onto the end of an >otherwise good DN. It would create an additional layer of the tree that >served no purpose, as it dangles under the real user entry. An e-mail >address is an alternative way of identifying an entity. Thus it is a >perfectly fine attribute for a directory entry, but it makes no sense as >an added attribute in a DN. > >Steve From owner-ietf-pkix@imc.org Mon Jun 19 20:40:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26273 for ; Mon, 19 Jun 2000 20:40:26 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA02531; Mon, 19 Jun 2000 17:39:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 17:39:28 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA02500 for ; Mon, 19 Jun 2000 17:39:25 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA04073; Tue, 20 Jun 2000 10:45:04 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Tue, 20 Jun 2000 10:38:36 +1000 Message-ID: From: Michael Zolotarev To: "David P. Kemp" , ietf-pkix@imc.org Subject: RE: Private Key Cloning Date: Tue, 20 Jun 2000 10:38:35 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > > And it doesn't seem to present insurmountable obstacles to load > balancing ... why shouldn't each server have its own signature key? > Is there a reason not to use N certificates with identical > distinguished names and different public keys? > I can see a problem with it with self-signed TSA certificates. Normally, a client would be configured to directly trust THAT [self-signed] TSA cert. Having a set of self-signed TSA certificates would be a configuration nightmare for the clients. And then you add another crypto box to your load balancing array on TSS, and then another one... M From owner-ietf-pkix@imc.org Mon Jun 19 22:06:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27967 for ; Mon, 19 Jun 2000 22:06:17 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA12340; Mon, 19 Jun 2000 19:04:40 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 19:04:22 -0700 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12258 for ; Mon, 19 Jun 2000 19:04:21 -0700 (PDT) Received: from [207.215.85.217] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWF00E34JXDDA@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Mon, 19 Jun 2000 18:53:38 -0700 (PDT) Date: Mon, 19 Jun 2000 18:54:22 -0700 From: Aram Perez Subject: Re: Can we form certificates with just name and e-mail address In-reply-to: <394E5572.67272FC0@netscape.com> To: PKIX Mailing List Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi Terry, > From: thayes@netscape.com (Terry Hayes) > Date: Mon, 19 Jun 2000 10:16:34 -0700 > To: Stefan Santesson > Cc: Stephen Kent , PKIX Mailing List > Subject: Re: Can we form certificates with just name and e-mail address > > Stefan Santesson wrote: > >> .... >> >> Why can't an e-mail address be part of a reasonable DN? (I guess that's >> what the current text implies) >> > > There is no reason that it can't be. In fact, I believe that e=name@isp.com > is a > perfectly good DN. It's probably not a good DN in the X.509 world, since it > isn't > very helpful in locating the portion of the "global" directory that actually > contains the entry. It is a unique name and probably will work in many LDAP > or > other directory environments. I haven't seen any provide this answer so here I go: Someone can correct my ASN.1, but a reason you shouldn't use "e=name@isp.com" in a/or as a DN is that it does not meet the ASN.1 rules for a DN (the '@' symbol is not in one of the valid character sets for DNs). There are a number of "public CAs" that do put the '@' in a DN, but technically they are incorrect. Regards, Aram Perez [snip] From owner-ietf-pkix@imc.org Mon Jun 19 23:24:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29698 for ; Mon, 19 Jun 2000 23:24:48 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA20506; Mon, 19 Jun 2000 20:22:23 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 20:21:56 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA20426 for ; Mon, 19 Jun 2000 20:21:54 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id NAA05471; Tue, 20 Jun 2000 13:27:41 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Tue, 20 Jun 2000 13:21:13 +1000 Message-ID: From: Michael Zolotarev To: ietf-pkix@imc.org Cc: Denis.Pinkas@bull.net Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH Date: Tue, 20 Jun 2000 13:21:12 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Folks, Haven't we already had a discussion about hash algorithm for messageImprint? I believe that the consensus was (and it is 100% reflected in the current draft) to allow a user to use whatever digest he/she wants. It is NOT a TSA concern if a user used 'weak' hash. The TSA does not inspect, modify, store or analyse the content of messageImprint - it only checks that the length of the hash corresponds to the hash algorithm. If so, then why should the draft imply any limitations on type of digest algorithms, except saying that they must be known? The position of the draft is, if I interpret it correctly: 1) The TSA does not care about hash algorithm used in messageImprint. But the algorithm must be known, to allow TSA to sanity-check the length of digested data. 2) The user is ADVICED to use strong hash, such as SHA-1 or MD5. This position of the draft with regards to hash is general, and provides enough space to grow, instead of being unnecessary restrictive. Can we leave it in peace :)? Michael > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: Tuesday, June 20, 2000 1:00 AM > To: seidel@timeproof.de > Cc: FRousseau@chrysalis-its.com; Denis.Pinkas@bull.net; > ietf-pkix@imc.org > Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt > > > >>>>> "Joerg" == Joerg Seidel writes: > > Joerg> Comments inline. > >> TSA implementations MUST support SHA-1. TSA implementations > >> SHOULD support MD5. > > Joerg> I think there are good reasons not to use MD5 in time > Joerg> stamps. They should use a strong hash function in order to > Joerg> achive long validity periods. MD5 is likely to be unsafe (=not > Joerg> collision free) soon and is already discuraged by german > Joerg> authorities. > > Joerg> IF we add a section about algorithms, it should maybe read: > Joerg> "TSA implementations MUST support SHA-1. TSA implementations > Joerg> SHOULD NOT support MD5.". But I think such a section is not > Joerg> very necessary. > > IANAC, but from what I understand the currently known attacks on MD5 > are nowhere near strong enough to justify that. > > I don't have a problem with the current text (SHA-1 required, MD5 > recommended). I do have a problem with text that implies that MD5 is > bad, because I don't know of data that supports such an assertion. > > Also, it doesn't seem like a good idea for the timestamp spec to give > very different signals from the other security specs. If there really > is good reason to say these kinds of things about MD5, let's have them > identified. (German authorities are not a good reason. Cryptanalysis > that shows weaknesses of interesting size would be.) If the issues > are real, changes to MD5 text should be applied across the board. > > paul > From owner-ietf-pkix@imc.org Tue Jun 20 03:28:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14740 for ; Tue, 20 Jun 2000 03:28:08 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA08996; Tue, 20 Jun 2000 00:27:00 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 00:26:52 -0700 Received: from mail5.registeredsite.com (root@mail5.registeredsite.com [209.35.159.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA08966 for ; Tue, 20 Jun 2000 00:26:50 -0700 (PDT) Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by mail5.registeredsite.com (8.9.3/8.9.3) with ESMTP id OAA09479 for ; Mon, 19 Jun 2000 14:24:29 -0400 Received: from arabtrust [206.161.197.58] by mail.arabtrust.com (SMTPD32-6.00) id AD6F1E90102; Tue, 20 Jun 2000 03:29:51 -0400 From: "Jean Abraham" To: Date: Tue, 20 Jun 2000 10:26:51 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit hi, What is TSA, OSCP? Jean From owner-ietf-pkix@imc.org Tue Jun 20 03:43:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14863 for ; Tue, 20 Jun 2000 03:43:43 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA10108; Tue, 20 Jun 2000 00:40:38 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 00:40:36 -0700 Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA10077 for ; Tue, 20 Jun 2000 00:40:35 -0700 (PDT) Received: from Alberti (pc04.secorvo.de [194.45.12.202]) by rom.antech.de (8.9.3/8.9.3) with SMTP id JAA15051; Tue, 20 Jun 2000 09:22:42 +0200 From: "Joerg Voelker" To: "Jean Abraham" , Subject: AW: Date: Tue, 20 Jun 2000 09:42:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Jean, TSA : Time Stamping Authority OCSP: Online Certificate Status Protocol For further information see: http://www.ietf.org/ID.html regards, Joerg >-----Ursprüngliche Nachricht----- >Von: Jean Abraham [mailto:jean.med@arabtrust.com] >Gesendet: Dienstag, 20. Juni 2000 09:27 >An: ietf-pkix@imc.org >Betreff: > > >hi, > >What is TSA, OSCP? > >Jean > From owner-ietf-pkix@imc.org Tue Jun 20 06:11:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16047 for ; Tue, 20 Jun 2000 06:11:31 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA18203; Tue, 20 Jun 2000 03:07:25 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 03:07:19 -0700 Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA18158 for ; Tue, 20 Jun 2000 03:07:17 -0700 (PDT) Received: from secude.com ([141.12.207.27]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id MAA16099; Tue, 20 Jun 2000 12:06:37 +0200 (MET DST) Message-ID: <394F4227.FFBC1AF6@secude.com> Date: Tue, 20 Jun 2000 12:06:31 +0200 From: Hans Schupp Organization: SECUDE GmbH X-Mailer: Mozilla 4.7 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: Aram Perez CC: PKIX Mailing List Subject: Re: Can we form certificates with just name and e-mail address References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0E2F3B897E84257584775E83" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Dies ist eine kryptographisch unterzeichnete Nachricht im MIME-Format. --------------ms0E2F3B897E84257584775E83 Content-Type: multipart/mixed; boundary="------------9E538EACC218188EF5083E6D" Dies ist eine mehrteilige Nachricht im MIME-Format. --------------9E538EACC218188EF5083E6D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Aram Perez schrieb: > I haven't seen any provide this answer so here I go: Someone can > correct my ASN.1, but a reason you shouldn't use "e=name@isp.com" > in a/or as a DN is that it does not meet the ASN.1 rules for a DN > (the '@' symbol is not in one of the valid character sets for DNs). > There are a number of "public CAs" that do put the '@' in a DN, but > technically they are incorrect. There is no single valid character set for "DName", only one for each defined "AttributeValueAssertion" (i.e. every pair XX=YY). The email-Attribute (OID 1.2.840.113549.1.9.1) has IA5String as defined character set, which contains the '@' character. So there is no problem. best regards, Hans Schupp --------------9E538EACC218188EF5083E6D Content-Type: text/x-vcard; charset=us-ascii; name="schupp.vcf" Content-Description: Visitenkarte für Hans Schupp Content-Disposition: attachment; filename="schupp.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Schupp;Hans tel;cell:(+49) 177 / 2452088 (private) tel;fax:(+49) 6151 / 82897 - 26 tel;work:(+49) 6151 / 82897 - 37 x-mozilla-html:FALSE url:http://www.secude.com org:

SECUDE Sicherheitstechnologie
Informationssysteme GmbH
e-security for e-business version:2.1 email;internet:schupp@secude.com adr;quoted-printable:;;NEW ADDRESS:=0D=0ADolivostr. 11=0D=0A;Darmstadt;;D-64293;Germany fn:Hans Schupp end:vcard --------------9E538EACC218188EF5083E6D-- --------------ms0E2F3B897E84257584775E83 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Kryptographische Unterschrift mit S/MIME Content-Transfer-Encoding: base64 MIIFGAYJKoZIhvcNAQcCoIIFCTCCBQUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC AzEwggMtMIICFaADAgECAgFOMA0GCSqGSIb3DQEBBQUAMFAxCzAJBgNVBAYTAkRFMRQwEgYD VQQKEwtTRUNVREUgR21iSDErMCkGA1UECxMiU0VDVURFIFRydXN0RmFjdG9yeSBJbmRpdmlk dWFscyBDQTAeFw05OTEwMjgxNTI2MzNaFw0wMTEwMjgxNTI2MzNaMDkxCzAJBgNVBAYTAkRF MRQwEgYDVQQKEwtTRUNVREUgR21iSDEUMBIGA1UEAxMLSGFucyBTY2h1cHAwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAP4CQoNsxm0rCW/ncYHxEGE9H4IStq2k0sAUJrKzBXvA1gkn c1jrMoQDEORcPjdIVoppbgt4xcmGz59GbGzrHQLDYX4wWtbpeuRQ5p//Dpw+ilA+dfH2WvOi v/OT4q04anv4tI1bHmfHjX0K/T9JoWJNduV1mhhBOvi+G/XG6VgjAgMBAAGjgawwgakwDgYD VR0PAQH/BAQDAgTwMBwGA1UdEQQVMBOBEXNjaHVwcEBzZWN1ZGUuY29tMFgGA1UdEgRRME+B F3RydXN0ZmFjdG9yeUBzZWN1ZGUuY29thjRodHRwOi8vd3d3LnNlY3VkZS5jb20vdHJ1c3Rm YWN0b3J5L2luZGl2aWR1YWxzY2EuY3J0MAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQD AgCgMA0GCSqGSIb3DQEBBQUAA4IBAQDB4naym+cwkZ9vjIIAJzoiNzsuywA1QiSElOnfnADa dD7NH3DyfRGjI5sjZBKpFuj2GDHXQBQnZikMxWI1H/J14IyZhv8CORIli8OboSfjavpMlQiJ oQOzO8FDk0j2dJBhOsBxkhGoO/GxTMy+xOdFHsBWsHHyQAFWlgdaCSPrgpq9fSDZ8+Kt5XIj pkyiWjkwnGr7espfevPB1weHlrO5tmD+KFKyVZ+cuDjf0ABAQDXP29HFWxve246Ga2SBnv0Y DTdDfIpVkeHbPd9n8LPGte7MNxM4s2GSJ7lY+p/z33TW0na+ZNmhdhaz8jmXSI/BP0Qvjy/b xKYfAKwvBFvLMYIBrzCCAasCAQEwVTBQMQswCQYDVQQGEwJERTEUMBIGA1UEChMLU0VDVURF IEdtYkgxKzApBgNVBAsTIlNFQ1VERSBUcnVzdEZhY3RvcnkgSW5kaXZpZHVhbHMgQ0ECAU4w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wMDA2MjAxMDA2MzRaMCMGCSqGSIb3DQEJBDEWBBQidGWphAb+tsgvnq5dxaX542Iw3zBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgPOvIk1Svkzm ubyOxfbHFx9/MGtPlsm0/k3DgpHqy3uInSh8bXNdyeMmZDrv3dQQFPqs5SRKufW5pzYCjYXD t4uBDgliygAIJFa9tQSCbtOnYpcLvYlzwgKd76abL2WQOdXUVqvNiHenKi4Fz7b6QXt0/cHs L/4OJyAuAe+0+Iwm --------------ms0E2F3B897E84257584775E83-- From owner-ietf-pkix@imc.org Tue Jun 20 06:40:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16250 for ; Tue, 20 Jun 2000 06:40:23 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA22558; Tue, 20 Jun 2000 03:36:29 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 03:36:26 -0700 Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22528 for ; Tue, 20 Jun 2000 03:36:25 -0700 (PDT) Received: from certplus.com (nt4_jmd.certplus.com [192.168.1.17]) by certplus.com (8.8.7/8.8.7) with ESMTP id LAA17685 for ; Tue, 20 Jun 2000 11:06:40 +0200 Message-ID: <394F493A.E5CAECCC@certplus.com> Date: Tue, 20 Jun 2000 12:36:42 +0200 From: Jean-Marc Desperrier Organization: Certplus X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Michael Zolotarev wrote: > I can see a problem with it with self-signed TSA certificates. Normally, a > client would be configured to directly trust THAT [self-signed] TSA cert. > Having a set of self-signed TSA certificates would be a configuration > nightmare for the clients. And then you add another crypto box to your load > balancing array on TSS, and then another one... It is my understanding of the current draft that a TSA certificate can not be self-signed : 2.3 : The TSA MUST sign all time stamp messages with one or more keys reserved specifically for that purpose. The corresponding certificate MUST contain only one instance of the extended key usage field extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID having value id-kp-timeStamping. This extension MUST be critical. If the TSA is self-signed then the private key has been used for something else than signing time stamp, and something it does not have the correct key usage field for. So if self-signed TSA certificate should be enabled, I think the wording of the draft should be changed to specify this. From owner-ietf-pkix@imc.org Tue Jun 20 10:25:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23382 for ; Tue, 20 Jun 2000 10:25:39 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA08232; Tue, 20 Jun 2000 07:22:55 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 07:22:47 -0700 Received: from smtp0.atl.equifax.com (smtp0.atl.equifax.com [216.46.96.116]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08199 for ; Tue, 20 Jun 2000 07:22:46 -0700 (PDT) From: Mcken.Mak@equifax.com Received: from postoffice-2.equifax.com (postoffice-2.equifax.com [192.168.4.11]) by smtp0.atl.equifax.com (Postfix) with ESMTP id E22ED5F; Tue, 20 Jun 2000 10:23:29 -0400 (EDT) Received: from noteswetc15.fin.equifax.com (noteswetc15.fin.equifax.com [172.18.113.65]) by postoffice-2.equifax.com (Postfix) with SMTP id 9B0776A2AA; Tue, 20 Jun 2000 10:22:20 -0400 (EDT) Received: by noteswetc15.fin.equifax.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256904.004F40A2 ; Tue, 20 Jun 2000 10:25:38 -0400 X-Lotus-FromDomain: EQUIFAX To: ietf-pkix@imc.org Cc: ghilborn@csc.com Message-ID: <85256904.004F3324.00@noteswetc15.fin.equifax.com> Date: Tue, 20 Jun 2000 10:24:54 -0400 Subject: Re: Private Key Cloning Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I agree on what you said. We had done it different for the load balance, the design is to us sub-CAs for the load balance, this may be more complex. The result should be cleaner and for better management for long term, since the serial number and the DN will need special care after service for a while. And as the sub-CA method do no need to clone the CA key at all. Mcken Mak ghilborn@csc.com on 06/19/2000 03:24:05 PM To: ietf-pkix@imc.org cc: (bcc: Mcken Mak/Technology/Equifax) Subject: Re: Private Key Cloning The issue is relevant only for for a very basic PKI. The wish is to have a single trust anchor of one public key, no sub-CAs, yet assure availability and load balance the CA service by cloned copies of the CA server (and its key). This scenario pre-empts by definition each server having its own key. However, it also conflicts with the no-copy rule. -Gene Hilborn dpkemp@roadblock.missi.ncsc.mil on 06/19/2000 02:21:34 PM Please respond to dpkemp@roadblock.missi.ncsc.mil To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: Re: Private Key Cloning > From: Paul Koning > Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT) > To: FRousseau@chrysalis-its.com > Cc: brauckmann@trustcenter.de, ietf-pkix@imc.org > Subject: Re: Private Key Cloning > > >>>>> "FRousseau" == FRousseau writes: > > FRousseau> Juergen, If a private key generated within a hardware > FRousseau> cryptographic module is securely wrapped within that same > FRousseau> module, is then exported to another similar hardware > FRousseau> cryptographic module through an authenticated key exchange > FRousseau> where it is unwrapped and both of these private keys are > FRousseau> then used to perform electronic signatures in a load > FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean > FRousseau> this would not be legal in Germany? > > How would you guarantee that there's no man in the middle? The only > way would be to have a prior out of band secure setup of > authenticating data, such as a shared secret or public keys used for > this key exchange process. While the user of such a device can ensure > that this is done right, the manufacturer of the devices cannot. > > It doesn't surprise me at all to see devices that don't allow this. > It makes good security sense to omit such a capability. > > paul And it doesn't seem to present insurmountable obstacles to load balancing ... why shouldn't each server have its own signature key? Is there a reason not to use N certificates with identical distinguished names and different public keys? From owner-ietf-pkix@imc.org Tue Jun 20 10:52:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24781 for ; Tue, 20 Jun 2000 10:52:18 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA09056; Tue, 20 Jun 2000 07:51:07 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 07:51:05 -0700 Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09026 for ; Tue, 20 Jun 2000 07:51:04 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiukh27143; Tue, 20 Jun 2000 14:51:02 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA09146; Tue, 20 Jun 00 10:47:22 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA14474; Tue, 20 Jun 2000 10:51:01 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14671.34005.182423.45349@xedia.com> Date: Tue, 20 Jun 2000 10:51:01 -0400 (EDT) To: mzolotarev@baltimore.com Cc: "David P. Kemp" , ietf-pkix@imc.org Subject: RE: Private Key Cloning References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit >>>>> "Michael" == Michael Zolotarev writes: >> And it doesn't seem to present insurmountable obstacles to load >> balancing ... why shouldn't each server have its own signature >> key? Is there a reason not to use N certificates with identical >> distinguished names and different public keys? >> Michael> I can see a problem with it with self-signed TSA Michael> certificates. Normally, a client would be configured to Michael> directly trust THAT [self-signed] TSA cert. Having a set of Michael> self-signed TSA certificates would be a configuration Michael> nightmare for the clients. And then you add another crypto Michael> box to your load balancing array on TSS, and then another Michael> one... So have one of the copies self-sign its own key and in addition sign each of the other keys. Is there a problem with that? paul From owner-ietf-pkix@imc.org Tue Jun 20 11:08:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25421 for ; Tue, 20 Jun 2000 11:08:55 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA10085; Tue, 20 Jun 2000 08:05:08 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 08:05:05 -0700 Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10049 for ; Tue, 20 Jun 2000 08:05:04 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiuki21067; Tue, 20 Jun 2000 15:04:43 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA09372; Tue, 20 Jun 00 11:01:03 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA14482; Tue, 20 Jun 2000 11:04:42 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14671.34826.394447.525886@xedia.com> Date: Tue, 20 Jun 2000 11:04:42 -0400 (EDT) To: mzolotarev@baltimore.com Cc: ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit >>>>> "Michael" == Michael Zolotarev writes: Michael> Folks, Haven't we already had a discussion about hash Michael> algorithm for messageImprint? Michael> I believe that the consensus was (and it is 100% reflected Michael> in the current draft) to allow a user to use whatever digest Michael> he/she wants. It is NOT a TSA concern if a user used 'weak' Michael> hash. The TSA does not inspect, modify, store or analyse the Michael> content of messageImprint - it only checks that the length Michael> of the hash corresponds to the hash algorithm. If so, then Michael> why should the draft imply any limitations on type of digest Michael> algorithms, except saying that they must be known? Michael> The position of the draft is, if I interpret it correctly: Michael> 1) The TSA does not care about hash algorithm used in Michael> messageImprint. But the algorithm must be known, to allow Michael> TSA to sanity-check the length of digested data. 2) The Michael> user is ADVICED to use strong hash, such as SHA-1 or MD5. Michael> This position of the draft with regards to hash is general, Michael> and provides enough space to grow, instead of being Michael> unnecessary restrictive. Can we leave it in peace :)? Can we remove this unnecessary restrictions instead? A rule of thumb of protocol design is that requirements are put in because they are necessary for interoperability. In the case we have here, that rule of thumb doesn't apply. If I were to generate my imprint with hash algorithm FRED that has a 37 byte digest, does it matter to the TSA? No, it does not. So why are we saying that the TSA needs to know the OID for FRED, and the associated digest length? The spec says that it's done to consistency-check the length of the imprint. Sure, but to what end? If I send a digest generated by FRED but truncate it to 31 bytes, what purpose is served by the TSA saying "naughty boy you threw away 6 bytes"? I may in fact have a legitimate reason for doing this -- just as IPsec has a legitimate reason for throwing away some of the hash bytes in the HMAC construct. If it actually mattered to the TSA algorithms, that would be one thing. But since the only purpose of the check is to do the check, let's get rid of it, simplify the spec, make the TSA implementations more reliable, and eliminate the need to ECO the spec every time a new hash appears. paul From owner-ietf-pkix@imc.org Tue Jun 20 11:23:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25880 for ; Tue, 20 Jun 2000 11:23:47 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA11265; Tue, 20 Jun 2000 08:21:00 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 08:20:57 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11233 for ; Tue, 20 Jun 2000 08:20:56 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA29467; Tue, 20 Jun 2000 11:20:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20000620004422.00c11850@mail.accurata.se> References: <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> <4.3.2.7.2.20000620004422.00c11850@mail.accurata.se> Date: Tue, 20 Jun 2000 11:13:52 -0400 To: Stefan Santesson From: Stephen Kent Subject: Re: Can we form certificates with just name and e-mail address Cc: "PKIX Mailing List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Stefan, >Steve, > >Thank's for useful input. Just to round this up, can you confirm the >conclusion that issuing certificates where subjects are represented >by just e-mail address + givenName + surname (and maybe also >country) is simply not possible. > >The name must simply be combined with a serialNumber attribute or >some other information that makes the name (with e-mail address >excluded) a reasonable DN. > >Right? Well, its possible to issue certs with any sort of DN. The question is what makes sense given the semantics of a DN, not just viewing it as a string of AVAs irrespective of context. The question I would ask is what would the directory tree look like given a proposed DN. How would the tree be distributed and managed? Think about the schema with those considerations in mind. For example, if one uses a geopolitical and organizational structure, which is the common model for DNs, we see lots of reasonable options for dividing the tree and determining who is responsible for maintainign what portions of it. On the other hand, if a DN consists of an e-mail address plus givenname and surname, this seems rather odd. The e-mail address, as a single attribute, results in a very broad fan out under the root. (in contrast, if one used DC attributes, as mentioned recently, one could mimic the structure of the DNS, which is well suited for separation and distributed maintenance, as the DNS has shown.) Since e-mail addresses are already globally unique, what does the given name and surname do for you, from a tree structure standpoint? Steve From owner-ietf-pkix@imc.org Tue Jun 20 11:56:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27145 for ; Tue, 20 Jun 2000 11:56:39 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA14336; Tue, 20 Jun 2000 08:55:34 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 08:55:25 -0700 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14297 for ; Tue, 20 Jun 2000 08:55:23 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA25682; Tue, 20 Jun 2000 17:55:20 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 20 Jun 2000 17:55:20 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA16590; Tue, 20 Jun 2000 17:55:19 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA13727; Tue, 20 Jun 2000 17:55:18 +0200 (MET DST) Date: Tue, 20 Jun 2000 17:55:18 +0200 (MET DST) Message-Id: <200006201555.RAA13727@emeriau.edelweb.fr> To: kent@bbn.com Subject: Re: Can we form certificates with just name and e-mail address Cc: ietf-pkix@imc.org Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Why not using an alternature subject with an email and the x.509 extension for the name parts. Subject directory attributes extension This field conveyes and desired Directory attribute values for the subject of the certificate. This field is defined as follows: subjectDirectoryAttributes EXTENSION ::= { SYNTAX AttributesSyntax IDENTIFIED BY id-ce-subjectDirectoryAttributes } AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute id-ce-subjectDirectoryAttributes :: OBJECT IDENTIFIER ::= {id-ce 9} From owner-ietf-pkix@imc.org Tue Jun 20 12:38:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28279 for ; Tue, 20 Jun 2000 12:38:52 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA18364; Tue, 20 Jun 2000 09:36:29 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 09:36:24 -0700 Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18329 for ; Tue, 20 Jun 2000 09:36:23 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA07737 for ; Tue, 20 Jun 2000 12:27:49 -0400 (EDT) Message-Id: <200006201627.MAA07733@roadblock.missi.ncsc.mil> Date: Tue, 20 Jun 2000 12:33:41 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Private Key Cloning To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Zy2YnAfwx0TZodRsz2lfzg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Agree that it is a problem with the architecture you and Gene describe. But I remember an old quote (can't remember the source) -- "I never met a problem that couldn't be solved with another layer of indirection." You could add that layer (a self-signed TSA trust point that signs the server keys), or you could use static load balancing - assign the first 100,000 clients to one server, then stand up another server and assign the next 100,000 clients to it, etc. Not pretty, but not a "nightmare" either. Or you could use server accelerators which allow you to import and export private signature keys. I'm sure there is a market for both tokens which prevent signature key cloning and tokens which allow it, allowing system architects to trade off technical controls with procedural controls. Personally, I prefer technical -- never offer a human the opportunity to be the man-in-the-middle (or the man-at-one-end, since spoofing a token-to-token protocol doesn't require two tokens). > From: Michael Zolotarev > To: "David P. Kemp" , ietf-pkix@imc.org > Subject: RE: Private Key Cloning > Date: Tue, 20 Jun 2000 10:38:35 +1000 > > > > > And it doesn't seem to present insurmountable obstacles to load > > balancing ... why shouldn't each server have its own signature key? > > Is there a reason not to use N certificates with identical > > distinguished names and different public keys? > > > > I can see a problem with it with self-signed TSA certificates. Normally, a > client would be configured to directly trust THAT [self-signed] TSA cert. > Having a set of self-signed TSA certificates would be a configuration > nightmare for the clients. And then you add another crypto box to your load > balancing array on TSS, and then another one... > > M > > > ***************************************************************************** > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ****************************************************************************** From owner-ietf-pkix@imc.org Tue Jun 20 13:09:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29547 for ; Tue, 20 Jun 2000 13:09:24 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19149; Tue, 20 Jun 2000 10:07:50 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 10:07:42 -0700 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19118 for ; Tue, 20 Jun 2000 10:07:35 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5KH2aX22862 for ; Tue, 20 Jun 2000 10:02:37 -0700 (PDT) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FWGQ7G02.R6W; Tue, 20 Jun 2000 10:06:52 -0700 Message-ID: <394FA4AB.B10D2290@netscape.com> Date: Tue, 20 Jun 2000 10:06:51 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: mzolotarev@baltimore.com, "David P. Kemp" , ietf-pkix@imc.org Subject: Re: Private Key Cloning References: <14671.34005.182423.45349@xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Paul Koning wrote: > > Michael> I can see a problem with it with self-signed TSA > Michael> certificates. Normally, a client would be configured to > Michael> directly trust THAT [self-signed] TSA cert. Having a set of > Michael> self-signed TSA certificates would be a configuration > Michael> nightmare for the clients. And then you add another crypto > Michael> box to your load balancing array on TSS, and then another > Michael> one... > > So have one of the copies self-sign its own key and in addition sign > each of the other keys. Is there a problem with that? > I suspect that this would not be acceptable. The draft indicates that TSA keys should only be used for signing timestamps. Your proposal allows signing other keys (creating certificates) as well. The best solution is to create a separate key that is trusted to create TSA certificates and is used only for that purpose, or to get another (trusted) CA to sign each of the TSA keys. Terry From owner-ietf-pkix@imc.org Tue Jun 20 13:19:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29767 for ; Tue, 20 Jun 2000 13:19:15 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19494; Tue, 20 Jun 2000 10:17:04 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 10:16:59 -0700 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19462 for ; Tue, 20 Jun 2000 10:16:57 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id KAA27393; Tue, 20 Jun 2000 10:16:23 -0700 (PDT) Message-Id: <4.2.2.20000620102117.00a85cb0@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 20 Jun 2000 10:22:19 -0700 To: "David P. Kemp" , ietf-pkix@imc.org From: Tony Bartoletti Subject: RE: Private Key Cloning In-Reply-To: <200006201627.MAA07733@roadblock.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 12:33 PM 6/20/00 -0400, David P. Kemp wrote: >But I remember an old quote (can't remember the source) -- > > "I never met a problem that couldn't be solved with another layer > of indirection." That would have to be Bill Gates ... :) ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Tue Jun 20 15:01:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01724 for ; Tue, 20 Jun 2000 15:01:44 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA22043; Tue, 20 Jun 2000 11:56:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 11:56:29 -0700 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22012 for ; Tue, 20 Jun 2000 11:56:28 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22783 for ; Tue, 20 Jun 2000 12:56:11 -0600 (MDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA21278 for ; Tue, 20 Jun 2000 14:56:01 -0400 (EDT) Received: from sun.com (edgemont [129.148.75.133]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id OAA12122 for ; Tue, 20 Jun 2000 14:56:01 -0400 (EDT) Message-ID: <394FBBAA.5CF09058@sun.com> Date: Tue, 20 Jun 2000 14:44:58 -0400 From: Yassir Elley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Using certificates as trust anchors Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit In looking over draft-ietf-pkix-new-part1-01.txt, a question arises as to how to process trust anchors provided in the form of a self-signed certificate. Since many applications use such certificates as trust anchors, I think it is important for PKIX to explicitly spell out how to process these certificates. Section 6.1.1 describes the five pieces of trust anchor information and mentions that the trust anchor information may be provided in the form of a self-signed certificate. "(d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor infor- mation includes: (1) the trusted issuer name, (2) optionally, the trusted issuer unique identifier, (3) the trusted public key algorithm, (4) the trusted public key, and (5) optionally, the trusted public key parameters associated with the public key. The trust anchor information may be provided to the path process- ing procedure in the form of a self-signed certificate. The trusted anchor information is trusted because it was delivered to the path processing procedure by some trustworthy "out-of-band" procedure. If the trusted public key algorithm requires parame- ters, then the parameters are provided along with the trusted pub- lic key." However, in other parts of Section 6, we find that the algorithm also requires the validity period of the public key, as well as other constraints (presumably this refers to initial name constraints, policy constraints, basic constraints[pathLenConstraint]?). For example: "In section 6.1, the text describes basic path validation. This text assumes that all valid paths begin with certificates issued by a sin- gle "most-trusted CA". The algorithm requires the public key of the CA, the CA's name, the validity period of the public key, and any constraints upon the set of paths which may be validated using this key." Section 6.2 also refers to making use of the certificate's extensions to limit the path. "Limitations in the trust paths for any particular key may be incorporated into the self-signed certificate's extensions. In this way, the self-signed certificates permit the path validation module to automatically incorporate local security policy and requirements." If the trust anchor information is provided in the form of a self-signed certificate, we can certainly extract the five pieces of trust anchor information mentioned in Section 6.1.1. Should we also be extracting other information from the certificate, such as policy constraints, policy mappings, name constraints, and basic constraints, and using these to initialize the relevant state variables? What about the validity period of the public key? Do we need to verify that the self-signed certificates's validity period includes time T? Do we need to validate the self-signed certificate itself? (i.e. do we have to verify the self-signed certificate's signature, revocation status, name chaining, uid chaining, that any certificate policies and policy mappings are processed, that it is a CA cert, that it has a keyCertSign key usage asserted, that all critical extensions are processed?) If the trust anchor information is trusted because it was delivered "out-of-band", can we use non-self-signed certificates to provide the trust anchor information? Perhaps I have a certificate that is not self-signed that I trust for some "out-of-band" reason. I would think that I should be able to use this certificate as a trust anchor since I have designated it as trusted. If this is allowed, it should be noted that we will not be able to validate the signature, revocation status, name chaining, and uid chaining checks because these checks rely on a "previous" certificate's values which we don't have. One approach would be to not validate any part of the trust anchor certificate and simply accept it (whether or not it is self-signed) because the user has designated it as "trusted", but to extract any relevant information. In other words, we wouldn't perform any of the steps in 6.1.3 (Basic Certificate Processing) but we would perform all the steps in 6.1.4 (Preparation for Certificate i+1). All of these questions need to be answered explicitly so that we can all process trust anchor certificates in a standard way. -Yassir. From owner-ietf-pkix@imc.org Tue Jun 20 20:52:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07134 for ; Tue, 20 Jun 2000 20:52:56 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA27376; Tue, 20 Jun 2000 17:51:00 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 17:50:13 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27341 for ; Tue, 20 Jun 2000 17:50:09 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA14072; Wed, 21 Jun 2000 10:55:26 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Jun 2000 10:49:00 +1000 Message-ID: From: Michael Zolotarev To: Paul Koning Cc: ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH Date: Wed, 21 Jun 2000 10:48:58 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > If I were to generate my imprint with hash algorithm FRED that has a > 37 byte digest, does it matter to the TSA? No, it does not. So why > are we saying that the TSA needs to know the OID for FRED, and the > associated digest length? > > The spec says that it's done to consistency-check the length of the > imprint. Sure, but to what end? If I send a digest generated by FRED > but truncate it to 31 bytes, what purpose is served by the TSA saying > "naughty boy you threw away 6 bytes"? I may in fact have a legitimate > reason for doing this -- just as IPsec has a legitimate reason for > throwing away some of the hash bytes in the HMAC construct. If it > actually mattered to the TSA algorithms, that would be one thing. But > since the only purpose of the check is to do the check, let's get rid > of it, simplify the spec, make the TSA implementations more reliable, > and eliminate the need to ECO the spec every time a new hash appears. > > paul I agree (expecting a public outcry here :). I always felt pretty uncomfortable with the TSA having to recognise the hash OID and checking the length. And on top of if, this would now allow a client tp send a NO-HASH imprint, a clear text, if they want to. Michael > From owner-ietf-pkix@imc.org Tue Jun 20 21:21:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07384 for ; Tue, 20 Jun 2000 21:21:04 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA00594; Tue, 20 Jun 2000 18:18:55 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 18:18:53 -0700 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA00560 for ; Tue, 20 Jun 2000 18:18:53 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5L1EDX17452 for ; Tue, 20 Jun 2000 18:14:13 -0700 (PDT) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FWHCYT01.3I3; Tue, 20 Jun 2000 18:18:29 -0700 Message-ID: <395017E5.59EF334D@netscape.com> Date: Tue, 20 Jun 2000 18:18:29 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Zolotarev CC: Paul Koning , ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit I agree as well. There is no need for the TSA to check anything about the imprint. This requirement should be removed from the draft. Terry Hayes thayes@netscape.com Michael Zolotarev wrote: > > If I were to generate my imprint with hash algorithm FRED that has a > > 37 byte digest, does it matter to the TSA? No, it does not. So why > > are we saying that the TSA needs to know the OID for FRED, and the > > associated digest length? > > > > The spec says that it's done to consistency-check the length of the > > imprint. Sure, but to what end? If I send a digest generated by FRED > > but truncate it to 31 bytes, what purpose is served by the TSA saying > > "naughty boy you threw away 6 bytes"? I may in fact have a legitimate > > reason for doing this -- just as IPsec has a legitimate reason for > > throwing away some of the hash bytes in the HMAC construct. If it > > actually mattered to the TSA algorithms, that would be one thing. But > > since the only purpose of the check is to do the check, let's get rid > > of it, simplify the spec, make the TSA implementations more reliable, > > and eliminate the need to ECO the spec every time a new hash appears. > > > > paul > > I agree (expecting a public outcry here :). I always felt pretty > uncomfortable with the TSA having to recognise the hash OID and checking the > length. And on top of if, this would now allow a client tp send a NO-HASH > imprint, a clear text, if they want to. > > Michael > > From owner-ietf-pkix@imc.org Tue Jun 20 23:26:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10236 for ; Tue, 20 Jun 2000 23:26:06 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA11071; Tue, 20 Jun 2000 20:22:45 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 20:22:33 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA11018 for ; Tue, 20 Jun 2000 20:22:31 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id NAA15577; Wed, 21 Jun 2000 13:27:45 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Jun 2000 13:21:22 +1000 Message-ID: From: Michael Zolotarev To: thayes@netscape.com, Paul Koning Cc: Michael Zolotarev , "David P. Kemp" , ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: RE: Private Key Cloning (TSA keys) Date: Wed, 21 Jun 2000 13:21:21 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Guys, Let's talk about one issue at a time. 1. Using self-signed TSA certs. The specifics of timestamping framework, in my opinion, make it perfectly normal and acceptable that a client would trust a TSA directly. A TSA can be generally considered a TTP, with no pressing need to have a TSA cert issued by other TTP (a CA). Consequently, there should be nothing wrong in having a self-signed TSA certificate. If the current draft precludes from doing it, or makes the possibility of it confusing, I believe it should be fixed. (This is why I cc-ed Denis on this). 2. Assuming that using self-signed TSA certs is Ok, then we do have an issue of handling an array of crypto boxes. The solutions for simplifying client's side trust configuration proposed in the recent traffic were all about the same: making the TSA to allocate a dedicated "signing key", and to sign the 'real operational' TSA certs with that key. I agree that this 'redirection' would simplify the client's side. The rule of trust for the client would be something like "Trust any TSA certificate, signed by THAT key-signing cert". Note that this makes a TSA operating more like a mini-CA, signing the certs for the keys it generates itself with yet another key it has [just] generated. This creates extra inconvenience for the TSA management - they would have to maintain a separate [and potentially secure] procedure/facility. Probably even having to allocate a different DN for each of the 'operational' certificate as well? But this is not a huge issue - who cares about poor system administrators :)? As a conclusion, I personally do not see any problems with that approach, and tend to agree that the problem of key cloning for TSA can be solved with the 'redirection'. Regards Michael > -----Original Message----- > From: thayes@netscape.com [mailto:thayes@netscape.com] > Sent: Wednesday, June 21, 2000 3:07 AM > To: Paul Koning > Cc: mzolotarev@baltimore.com; David P. Kemp; ietf-pkix@imc.org > Subject: Re: Private Key Cloning > > > Paul Koning wrote: > > > > > Michael> I can see a problem with it with self-signed TSA > > Michael> certificates. Normally, a client would be configured to > > Michael> directly trust THAT [self-signed] TSA cert. > Having a set of > > Michael> self-signed TSA certificates would be a configuration > > Michael> nightmare for the clients. And then you add another crypto > > Michael> box to your load balancing array on TSS, and then another > > Michael> one... > > > > So have one of the copies self-sign its own key and in addition sign > > each of the other keys. Is there a problem with that? > > > > I suspect that this would not be acceptable. The draft > indicates that TSA > keys should only be used for signing timestamps. Your proposal allows > signing other keys (creating certificates) as well. > > The best solution is to create a separate key that is trusted > to create TSA > certificates and is used only for that purpose, or to get > another (trusted) > CA to sign each of the TSA keys. > > Terry > > From owner-ietf-pkix@imc.org Wed Jun 21 00:34:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11331 for ; Wed, 21 Jun 2000 00:34:20 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA15519; Tue, 20 Jun 2000 21:33:23 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 21:33:21 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA15487 for ; Tue, 20 Jun 2000 21:33:21 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FWH00J01LZTPQ@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 20 Jun 2000 21:33:29 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FWH00JH3LZT6F@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 20 Jun 2000 21:33:29 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 21:27:00 -0700 Content-return: allowed Date: Tue, 20 Jun 2000 21:26:55 -0700 From: Ambarish Malpani Subject: Generalizing the concept of id-pkix-ocsp-nocheck To: ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE2B4149C@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I was recently having a conversation with a collegue and he asked a question. Here goes: In OCSP, we have support the concept of a CA issuing a special certificate to an OCSP responder, allowing it to respond on its [the CA's] behalf with a special extended key usage flag. We also allow the CA to indicate that the responder's cert does not need to be validated by having it include the id-pkix-ocsp-nocheck extension in the responder's certificate. Why can't the concept of including an id-pkix-ocsp-nocheck extension in a certificate be extended to any arbitrary certificate to indicate that it doesn't need to be validated? If this makes sense, should this capability be specified in son-of-rfc2459? Comments? Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 From owner-ietf-pkix@imc.org Wed Jun 21 00:37:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11353 for ; Wed, 21 Jun 2000 00:37:39 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA15269; Tue, 20 Jun 2000 21:31:30 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 21:31:21 -0700 Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA15227 for ; Tue, 20 Jun 2000 21:31:18 -0700 (PDT) Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id OAA62759; Wed, 21 Jun 2000 14:30:33 +1000 (EST) Message-ID: <00cd01bfdb3a$a2f90c80$8802a8c0@eracom.com.au> From: "Simon McMahon" To: "Michael Zolotarev" , , "Paul Koning" Cc: "David P. Kemp" , , References: Subject: Re: Private Key Cloning (TSA keys) Date: Wed, 21 Jun 2000 14:38:34 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi All, I've been considering load balancing and Private Key cloning for another project (not TSA) but a lot of the issues are the same. I think the problems of messing with the client software to fix what looks to me like a server problem is a bad idea. Anyway, here is my 2c worth. Performance / availablilty is a problem that the TSA server has and load balancing is one solution to address that problem. In my opinion any load balancing scheme that impacts on the clients will not be very scalable or interoperable and should be avoided. In other words cloning the private key is necessary to do load balancing transparently to the client base. The problem is legislation which boils down to "dont copy that private key". However, if the cloned private keys were controlled in such a way that they could not be seperated and used independantly outside a well defined boundary, e.g. the TSA, couldn't they still be considered as one instance of the private key since externally (to the TSA) there would be no way of knowing that more than one copy exists within the TSA. The TSA would also have to show that any loss or theft of any copy of the private key, for any amount of time, is detectable and would result in revocation of that key. As an extreme example - consider a hardware accelerator with two modular exponentiation processors on board. The TSA application loads up one private key but the accelerator splits it into two copies one loaded into each of the processors. The TSA application then pumps signature requests at the accelerator and has no control over which processor inside the device does the operation. The accelerator offers no other services which would allow either copy of the private key to be messed around with. If the accelerator was evaluated to Fips 140, ITSEC, CC or whatever, then surely there would be no problem with the legislation here. Scaling that example up to physically seperate devices within a TSA might require a security evaluation of the TSA, or at least that physical part tha t includes the devices and management processes for them but wont TSAs need to be evaluated anyway ? Simon McMahon ERACOM Pty. Ltd. ----- Original Message ----- From: Michael Zolotarev To: ; Paul Koning Cc: Michael Zolotarev ; David P. Kemp ; ; Sent: Wednesday, 21 June 2000 13:21 Subject: RE: Private Key Cloning (TSA keys) > Guys, > > Let's talk about one issue at a time. > > 1. Using self-signed TSA certs. > The specifics of timestamping framework, in my opinion, make it perfectly > normal and acceptable that a client would trust a TSA directly. A TSA can be > generally considered a TTP, with no pressing need to have a TSA cert issued > by other TTP (a CA). Consequently, there should be nothing wrong in having > a self-signed TSA certificate. If the current draft precludes from doing it, > or makes the possibility of it confusing, I believe it should be fixed. > (This is why I cc-ed Denis on this). > > 2. Assuming that using self-signed TSA certs is Ok, then we do have an issue > of handling an array of crypto boxes. The solutions for simplifying client's > side trust configuration proposed in the recent traffic were all about the > same: making the TSA to allocate a dedicated "signing key", and to sign the > 'real operational' TSA certs with that key. > I agree that this 'redirection' would simplify the client's side. The rule > of trust for the client would be something like "Trust any TSA certificate, > signed by THAT key-signing cert". > > Note that this makes a TSA operating more like a mini-CA, signing the certs > for the keys it generates itself with yet another key it has [just] > generated. This creates extra inconvenience for the TSA management - they > would have to maintain a separate [and potentially secure] > procedure/facility. Probably even having to allocate a different DN for each > of the 'operational' certificate as well? But this is not a huge issue - who > cares about poor system administrators :)? > > As a conclusion, I personally do not see any problems with that approach, > and tend to agree that the problem of key cloning for TSA can be solved with > the 'redirection'. > > Regards > Michael > > > > > > -----Original Message----- > > From: thayes@netscape.com [mailto:thayes@netscape.com] > > Sent: Wednesday, June 21, 2000 3:07 AM > > To: Paul Koning > > Cc: mzolotarev@baltimore.com; David P. Kemp; ietf-pkix@imc.org > > Subject: Re: Private Key Cloning > > > > > > Paul Koning wrote: > > > > > > > > Michael> I can see a problem with it with self-signed TSA > > > Michael> certificates. Normally, a client would be configured to > > > Michael> directly trust THAT [self-signed] TSA cert. > > Having a set of > > > Michael> self-signed TSA certificates would be a configuration > > > Michael> nightmare for the clients. And then you add another crypto > > > Michael> box to your load balancing array on TSS, and then another > > > Michael> one... > > > > > > So have one of the copies self-sign its own key and in addition sign > > > each of the other keys. Is there a problem with that? > > > > > > > I suspect that this would not be acceptable. The draft > > indicates that TSA > > keys should only be used for signing timestamps. Your proposal allows > > signing other keys (creating certificates) as well. > > > > The best solution is to create a separate key that is trusted > > to create TSA > > certificates and is used only for that purpose, or to get > > another (trusted) > > CA to sign each of the TSA keys. > > > > Terry > > > > > From owner-ietf-pkix@imc.org Wed Jun 21 01:00:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11445 for ; Wed, 21 Jun 2000 01:00:56 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA16418; Tue, 20 Jun 2000 21:54:17 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 21:54:14 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA16388 for ; Tue, 20 Jun 2000 21:54:11 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA16225; Wed, 21 Jun 2000 14:59:37 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Jun 2000 14:53:14 +1000 Message-ID: From: Michael Zolotarev To: Simon McMahon , Michael Zolotarev , thayes@netscape.com, Paul Koning Cc: "David P. Kemp" , ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: RE: Private Key Cloning (TSA keys) Date: Wed, 21 Jun 2000 14:53:14 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Simon, (I'm taking luxury of being in the same time zone with you, so I can answer the first :) What you are saying is absolutely right, and technically I believe we all know that it is more practical to clone the keys, than to come up with the solution around it. But the argument has started as a result of the fact that some legislations, namely German Digital Signature Law, prohibit key cloning. So we've been discussing just one of the possible solutions to get around the restrictions of the law. I'm still not convinced, though, that the interpretation of the law is correct. Taking your example with accelerator - would it be regarded as a breach of the law? If not, and the accelerator is all right, what makes it dramatically different from cloning the key in the environment which can be formally certified as a security-equivalent to the accelerator's? The law is written for general use, and each particular scenario requires specific peruse. I'm wondering if we are trying to scare ourselves away even before the law has a chance to "speak out". Would really like to hear from anybody who has legal expertise and can provide an interpretation of the German Law for that specific case. Regards Michael > -----Original Message----- > From: Simon McMahon [mailto:simon@onthenet.com.au] > Sent: Wednesday, June 21, 2000 2:39 PM > To: Michael Zolotarev; thayes@netscape.com; Paul Koning > Cc: David P. Kemp; ietf-pkix@imc.org; Denis.Pinkas@bull.net > Subject: Re: Private Key Cloning (TSA keys) > > > Hi All, > > I've been considering load balancing and Private Key cloning > for another > project (not TSA) but a lot of the issues are the same. I > think the problems > of messing with the client software to fix what looks to me > like a server > problem is a bad idea. Anyway, here is my 2c worth. > > Performance / availablilty is a problem that the TSA server > has and load > balancing is one solution to address that problem. In my > opinion any load > balancing scheme that impacts on the clients will not be very > scalable or > interoperable and should be avoided. In other words cloning > the private key > is necessary to do load balancing transparently to the client base. > > The problem is legislation which boils down to "dont copy > that private key". > > However, if the cloned private keys were controlled in such a > way that they > could not be seperated and used independantly outside a well defined > boundary, e.g. the TSA, couldn't they still be considered as > one instance of > the private key since externally (to the TSA) there would be no way of > knowing that more than one copy exists within the TSA. The > TSA would also > have to show that any loss or theft of any copy of the > private key, for any > amount of time, is detectable and would result in revocation > of that key. > > As an extreme example - consider a hardware accelerator with > two modular > exponentiation processors on board. The TSA application loads > up one private > key but the accelerator splits it into two copies one loaded > into each of > the processors. The TSA application then pumps signature > requests at the > accelerator and has no control over which processor inside > the device does > the operation. The accelerator offers no other services which > would allow > either copy of the private key to be messed around with. If > the accelerator > was evaluated to Fips 140, ITSEC, CC or whatever, then surely > there would be > no problem with the legislation here. > > Scaling that example up to physically seperate devices within > a TSA might > require a security evaluation of the TSA, or at least that > physical part tha > t includes the devices and management processes for them but > wont TSAs need > to be evaluated anyway ? > > Simon McMahon > ERACOM Pty. Ltd. > > ----- Original Message ----- > From: Michael Zolotarev > To: ; Paul Koning > Cc: Michael Zolotarev ; David P. Kemp > ; ; > > Sent: Wednesday, 21 June 2000 13:21 > Subject: RE: Private Key Cloning (TSA keys) > > > > Guys, > > > > Let's talk about one issue at a time. > > > > 1. Using self-signed TSA certs. > > The specifics of timestamping framework, in my opinion, > make it perfectly > > normal and acceptable that a client would trust a TSA > directly. A TSA can > be > > generally considered a TTP, with no pressing need to have a TSA cert > issued > > by other TTP (a CA). Consequently, there should be nothing wrong in > having > > a self-signed TSA certificate. If the current draft > precludes from doing > it, > > or makes the possibility of it confusing, I believe it > should be fixed. > > (This is why I cc-ed Denis on this). > > > > 2. Assuming that using self-signed TSA certs is Ok, then we > do have an > issue > > of handling an array of crypto boxes. The solutions for simplifying > client's > > side trust configuration proposed in the recent traffic > were all about the > > same: making the TSA to allocate a dedicated "signing key", > and to sign > the > > 'real operational' TSA certs with that key. > > I agree that this 'redirection' would simplify the client's > side. The rule > > of trust for the client would be something like "Trust any TSA > certificate, > > signed by THAT key-signing cert". > > > > Note that this makes a TSA operating more like a mini-CA, > signing the > certs > > for the keys it generates itself with yet another key it has [just] > > generated. This creates extra inconvenience for the TSA > management - they > > would have to maintain a separate [and potentially secure] > > procedure/facility. Probably even having to allocate a > different DN for > each > > of the 'operational' certificate as well? But this is not a > huge issue - > who > > cares about poor system administrators :)? > > > > As a conclusion, I personally do not see any problems with > that approach, > > and tend to agree that the problem of key cloning for TSA > can be solved > with > > the 'redirection'. > > > > Regards > > Michael > > > > > > > > > > > -----Original Message----- > > > From: thayes@netscape.com [mailto:thayes@netscape.com] > > > Sent: Wednesday, June 21, 2000 3:07 AM > > > To: Paul Koning > > > Cc: mzolotarev@baltimore.com; David P. Kemp; ietf-pkix@imc.org > > > Subject: Re: Private Key Cloning > > > > > > > > > Paul Koning wrote: > > > > > > > > > > > Michael> I can see a problem with it with self-signed TSA > > > > Michael> certificates. Normally, a client would be > configured to > > > > Michael> directly trust THAT [self-signed] TSA cert. > > > Having a set of > > > > Michael> self-signed TSA certificates would be a configuration > > > > Michael> nightmare for the clients. And then you add > another crypto > > > > Michael> box to your load balancing array on TSS, and > then another > > > > Michael> one... > > > > > > > > So have one of the copies self-sign its own key and in > addition sign > > > > each of the other keys. Is there a problem with that? > > > > > > > > > > I suspect that this would not be acceptable. The draft > > > indicates that TSA > > > keys should only be used for signing timestamps. Your > proposal allows > > > signing other keys (creating certificates) as well. > > > > > > The best solution is to create a separate key that is trusted > > > to create TSA > > > certificates and is used only for that purpose, or to get > > > another (trusted) > > > CA to sign each of the TSA keys. > > > > > > Terry > > > > > > > > > From owner-ietf-pkix@imc.org Wed Jun 21 01:27:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14754 for ; Wed, 21 Jun 2000 01:27:03 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA17454; Tue, 20 Jun 2000 22:24:48 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 22:24:44 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA17414 for ; Tue, 20 Jun 2000 22:24:42 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id PAA16409; Wed, 21 Jun 2000 15:30:12 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Jun 2000 15:23:50 +1000 Message-ID: From: Michael Zolotarev To: Jean-Marc Desperrier , ietf-pkix@imc.org Subject: RE: self-signed TSA [Was Re: Private Key Cloning] Date: Wed, 21 Jun 2000 15:23:49 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Jean, My interpretation of the current text is: The text mandates that a timestamp token can be only signed with a specific 'timestamping' key, as indicated by the ExtKeyUsage. A timestamp token signed by a key which does not contain that ExtKeyUsage field must be considered invalid. However, it does NOT necessarily say that the same 'timestamping' key can not be used for signing whatever else, for example a certificate. So, I can not see anything in the current text that would prohibit issuing a self-signed TSA certificate. However, I'd suggest that the draft makes it clearer, by adding a comment (in a security section?) about possibility of generating and using self-signed TSA certificates. Regards M > -----Original Message----- > From: Jean-Marc Desperrier [mailto:jean-marc.desperrier@certplus.com] > Sent: Tuesday, June 20, 2000 8:37 PM > To: ietf-pkix@imc.org > Subject: self-signed TSA [Was Re: Private Key Cloning] > > > Michael Zolotarev wrote: > > > I can see a problem with it with self-signed TSA > certificates. Normally, a > > client would be configured to directly trust THAT > [self-signed] TSA cert. > > Having a set of self-signed TSA certificates would be a > configuration > > nightmare for the clients. And then you add another crypto > box to your load > > balancing array on TSS, and then another one... > > It is my understanding of the current draft that a TSA > certificate can not be > self-signed : > > 2.3 : > The TSA MUST sign all time stamp messages with one or more keys > reserved specifically for that purpose. The corresponding certificate > MUST contain only one instance of the extended key usage field > extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID > having value id-kp-timeStamping. This extension MUST be critical. > > If the TSA is self-signed then the private key has been used > for something else > than signing time stamp, and something it does not have the > correct key usage > field for. > > So if self-signed TSA certificate should be enabled, I think > the wording of the > draft should be changed to specify this. > From owner-ietf-pkix@imc.org Wed Jun 21 01:58:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17008 for ; Wed, 21 Jun 2000 01:58:07 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA20184; Tue, 20 Jun 2000 22:56:31 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 22:56:25 -0700 Received: from localhost.localdomain (root@mail4.registeredsite.com [209.35.159.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA20145 for ; Tue, 20 Jun 2000 22:56:23 -0700 (PDT) Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id AAA26042 for ; Wed, 21 Jun 2000 00:53:49 -0400 Received: from arabtrust [195.226.253.30] by mail.arabtrust.com (SMTPD32-6.00) id A9C027A00BA; Wed, 21 Jun 2000 01:59:28 -0400 From: "Jean Abraham" To: Date: Wed, 21 Jun 2000 08:56:27 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi, What are the applications that does or does not support more than 4 hierachies in a digital certificate. Jean From owner-ietf-pkix@imc.org Wed Jun 21 02:03:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22415 for ; Wed, 21 Jun 2000 02:03:53 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA20784; Tue, 20 Jun 2000 23:01:16 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 20 Jun 2000 23:01:14 -0700 Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA20749 for ; Tue, 20 Jun 2000 23:01:12 -0700 (PDT) Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id QAA78943; Wed, 21 Jun 2000 16:00:45 +1000 (EST) Message-ID: <010501bfdb47$3caa06c0$8802a8c0@eracom.com.au> From: "Simon McMahon" To: "Michael Zolotarev" , , "Paul Koning" Cc: "David P. Kemp" , , References: Subject: Re: Private Key Cloning (TSA keys) Date: Wed, 21 Jun 2000 16:08:45 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > ... But the argument has started as a result of the fact > that some legislations, namely German Digital Signature Law, prohibit key > cloning. So we've been discussing just one of the possible solutions to get > around the restrictions of the law. > Is that the SigG / SigV German signature law ? I thought that was more for personal private keys where authentication data (e.g. the PIN) is provided for EVERY signature generated by the private key as well as "no copying the private key". Surely that is not relevant to TSA servers where no one is there to enter a PIN. > I'm still not convinced, though, that the interpretation of the law is > correct. Taking your example with accelerator - would it be regarded as a > breach of the law? If not, and the accelerator is all right, what makes it > dramatically different from cloning the key in the environment which can be > formally certified as a security-equivalent to the accelerator's? > Yes, its a question of whether it is within the law, and within which relevant law. The german signature law that I have indirectly worked with was very specific but in my opinion not relevant to private keys used by unattended servers. > The law is written for general use, and each particular scenario requires > specific peruse. I'm wondering if we are trying to scare ourselves away even > before the law has a chance to "speak out". Would really like to hear from > anybody who has legal expertise and can provide an interpretation of the > German Law for that specific case. > That would be good but I'll be surprised if you get any. What good is legal advice that is not based on actual case law anyway ? There are no TSA's yet (are there ?) let alone cases regarding them ? Using a time-stamping key to self sign TSA certificates looks a bit like a kludge to me to fix a problem that TSA's may not even have. Surely well defined key usage, particularly single key usage, is a good security goal to achieve that this approach undermines. Simon McMahon ERACOM Pty. Ltd. From owner-ietf-pkix@imc.org Wed Jun 21 03:25:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24205 for ; Wed, 21 Jun 2000 03:25:07 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA24255; Wed, 21 Jun 2000 00:21:55 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 00:21:45 -0700 Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA24217 for ; Wed, 21 Jun 2000 00:21:44 -0700 (PDT) Received: by mystic1.trustcenter.de; id JAA18309; Wed, 21 Jun 2000 09:18:44 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma018303; Wed, 21 Jun 00 09:18:44 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id JAA13508; Wed, 21 Jun 2000 09:20:12 +0200 (MET DST) Message-Id: <3.0.5.32.20000621092012.0379c8b0@callisto> X-Sender: jbr@callisto X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Jun 2000 09:20:12 +0200 To: "Simon McMahon" , "Michael Zolotarev" , , "Paul Koning" From: Juergen Brauckmann Subject: Re: Private Key Cloning (TSA keys) Cc: "David P. Kemp" , , In-Reply-To: <010501bfdb47$3caa06c0$8802a8c0@eracom.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA24219 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit At 16:08 21.06.00 +1000, Simon McMahon wrote: >> ... But the argument has started as a result of the fact >> that some legislations, namely German Digital Signature Law, prohibit key >> cloning. So we've been discussing just one of the possible solutions to >get >> around the restrictions of the law. >> >Is that the SigG / SigV German signature law ? >I thought that was more for personal private keys where authentication data >(e.g. the PIN) is provided for EVERY signature generated by the private key >as well as "no copying the private key". Surely that is not relevant to TSA >servers where no one is there to enter a PIN. Funnily it is relevant. CAs that want to operate according to SigG/SigV have to offer a timestamping service. This is a requirement of the law. They have to sign the timestamps with signatures that comply with that law. The current SigG does not recognize the necessity to have server keys/certificate, and so all restrictions to personal private keys apply to CA/TSA operating keys. With some tricks (mostly not technical) we can get around entering a PIN for every timestamp issued, but the "no copying a private key" issue still applies. >Yes, its a question of whether it is within the law, and within which >relevant law. The german signature law that I have indirectly worked with >was very specific but in my opinion not relevant to private keys used by >unattended servers. As all servers that want to operate according to the German Digital Signature Law must issue signatures that comply with this law, it is relevant. We hope that a revision of the law will contain a notion of "server keys/certificates", so that all the things that are not appliable for CAs/TSAs will disappear... . Regards, Juergen -- Juergen Brauckmann Tel.: 040 / 8080 26 311 TC TrustCenter GmbH Fax.: 040 / 8080 26 126 Sonninstraße 24-28 mailto:brauckmann@trustcenter.de 20097 Hamburg http://www.trustcenter.de From owner-ietf-pkix@imc.org Wed Jun 21 05:08:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24897 for ; Wed, 21 Jun 2000 05:08:04 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA27196; Wed, 21 Jun 2000 02:04:57 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 02:04:40 -0700 Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA27164 for ; Wed, 21 Jun 2000 02:04:37 -0700 (PDT) Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id TAA07862; Wed, 21 Jun 2000 19:04:10 +1000 (EST) Message-ID: <013d01bfdb60$dbe0a820$8802a8c0@eracom.com.au> From: "Simon McMahon" To: "Michael Zolotarev" , , "Paul Koning" , "Juergen Brauckmann" Cc: "David P. Kemp" , , References: <3.0.5.32.20000621092012.0379c8b0@callisto> Subject: Re: Private Key Cloning (TSA keys) Date: Wed, 21 Jun 2000 19:12:10 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Juergen wrote : > As all servers that want to operate according to the German Digital > Signature Law must issue signatures that comply with this law, it is > relevant. > > We hope that a revision of the law will contain a notion of "server > keys/certificates", so that all the things that are not appliable for > CAs/TSAs will disappear... . > So perhaps SigG/SigV compliant TSAs should not attempt load balancing until the revision to the law is released. If the revision is really likely then wont this problem just go away ? > ... With some tricks (mostly not technical) we can get > around entering a PIN for every timestamp issued, but the "no copying a > private key" issue still applies. > Surely this is a better approach, to use tricks to get around the deficiencies in the law, rather than trying to accomidate it in the standard when it gets too messy. Especially if the law is likely to be changed to accomidate CA/TSA servers anyway. I guess the analogy with an accelerater with controlled private key copies within the secure perimeter was not tricky enough to convince you :-). I know of an ITSEC evaluation with SigG/SigV compiance which argued that copies of private keys was OK because they were made in order to move the private key from one module to another within the secure perimieter. It wasn't a TSA, of course, and the existance of two copies was only for an instant before the previous copy was destroyed. We are talking about long term persistance of multiple copies of the private key and doing signatures with them, but as long as they stay within the target of evaluation's secure perimeter ... Regards, Simon. From owner-ietf-pkix@imc.org Wed Jun 21 06:01:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25392 for ; Wed, 21 Jun 2000 06:01:33 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA00124; Wed, 21 Jun 2000 03:00:20 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 03:00:13 -0700 Received: from mail3.registeredsite.com (IDENT:root@mail3.registeredsite.com [209.35.159.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29988 for ; Wed, 21 Jun 2000 03:00:11 -0700 (PDT) Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by mail3.registeredsite.com (8.9.3/8.9.3) with ESMTP id EAA05892 for ; Wed, 21 Jun 2000 04:56:38 -0400 Received: from arabtrust [213.189.81.49] by mail.arabtrust.com (SMTPD32-6.00) id A2DD18F00EE; Wed, 21 Jun 2000 06:03:09 -0400 From: "Jean Abraham" To: Subject: certification for pki Date: Wed, 21 Jun 2000 13:00:06 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi, Is there any internationally accredited certification for PKI Jean From owner-ietf-pkix@imc.org Wed Jun 21 06:33:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25571 for ; Wed, 21 Jun 2000 06:33:57 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA03231; Wed, 21 Jun 2000 03:31:37 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 03:31:24 -0700 Received: from FW-BEL.utimaco.be ([193.121.107.230]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03197 for ; Wed, 21 Jun 2000 03:31:23 -0700 (PDT) Received: (from uucp@localhost) by FW-BEL.utimaco.be (8.9.3/8.9.3) id MAA03479 for ; Wed, 21 Jun 2000 12:33:56 +0200 (CEST) (envelope-from frederik.loeckx@utimaco.be) Received: from (belgien1.utimaco.be [10.7.0.25]) by FW-BEL.utimaco.be via smap (V2.1) id xma003477; Wed, 21 Jun 00 12:33:35 +0200 Received: by belgien1.utimaco.be(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id C1256905.00393467 ; Wed, 21 Jun 2000 12:24:49 +0200 X-Lotus-FromDomain: UTIMACO From: "Frederik Loeckx" To: ietf-pkix@imc.org Message-ID: Date: Wed, 21 Jun 2000 12:24:45 +0200 Subject: PKIStatusInfo inside draft-ietf-pkix-time-stamp-08.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Hello, A somewhat less philosophical question as cloning keys: Inside RFC2510bis, PKIStatusInfo is defined as PKIStatusInfo ::= SEQUENCE { status PKIStatus, statusString PKIFreeText OPTIONAL, failInfo PKIFailureInfo OPTIONAL } In draft-ietf-pkix-time-stamp-08.txt, the second field, statusString, disappeared resulting in PKIStatusInfo ::= SEQUENCE { status PKIStatus, failInfo PKIFailureInfo OPTIONAL } So I think this is a little mistake inside the time stamping draft, especially because the statusString field is explicitly mentioned inside the corresponding text of the draft. Kind regards, Frederik Loeckx From owner-ietf-pkix@imc.org Wed Jun 21 08:32:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28836 for ; Wed, 21 Jun 2000 08:32:29 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA07241; Wed, 21 Jun 2000 05:23:47 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 05:23:36 -0700 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07210 for ; Wed, 21 Jun 2000 05:23:34 -0700 (PDT) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A3B2989012A; Wed, 21 Jun 2000 14:23:14 +0200 Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Mi, 21 Jun 2000 14:24:12 +0100 From: "Peter Lipp" To: "Michael Zolotarev" , "Jean-Marc Desperrier" , Subject: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Wed, 21 Jun 2000 14:24:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.776CFB97--"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.776CFB97-- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > However, it does NOT necessarily say that the same > 'timestamping' key can not be used for signing whatever else, for > example a certificate. Looking at the current draft it sais: A TSA is REQUIRED ... 10. to sign each time stamp token using a key generated exclusively for this purpose and have this property of the key indicated on the corresponding certificate. I read "exclusively for this purpose" as "not allowed for signing certificates". Peter ----IAIK.SMIME.MAPPER.776CFB97-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC 2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9 ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy 2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE 6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx 2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7 rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8 lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3 DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI 7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG 9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6 Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25 sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9 l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q 19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6 ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1 OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B 2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1 2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64 vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMDA2MjExMjI0MTJaMCMGCSqGSIb3DQEJBDEWBBRrrjN33h5Y+qa7 g3/Voc3rKycbqjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN BgkqhkiG9w0BAQEFAASBgB7/jeAJfY+Z+SuuGXi0yFY9DAngS/ijX8eNgLicIpAG O4aAyiyhLqYWfAbozXOWWgnNUJK/fMvo7RjsnSgr899XzBDHrleeYzBcO+G15UNK 9zJ+OaeSp2c6wtMaKIUXweDbU3eIsg0YnYcnIGaDfkVluZremHWGegiY3HREu+QS AAAAAAAA ----IAIK.SMIME.MAPPER.776CFB97---- From owner-ietf-pkix@imc.org Wed Jun 21 09:50:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01732 for ; Wed, 21 Jun 2000 09:50:33 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA09446; Wed, 21 Jun 2000 06:48:13 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 06:48:06 -0700 Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09413 for ; Wed, 21 Jun 2000 06:48:04 -0700 (PDT) Received: from certplus.com (nt4_jmd.certplus.com [192.168.1.17]) by certplus.com (8.8.7/8.8.7) with ESMTP id OAA30170 for ; Wed, 21 Jun 2000 14:18:56 +0200 Message-ID: <3950C7CF.7F57A0EB@certplus.com> Date: Wed, 21 Jun 2000 15:49:03 +0200 From: Jean-Marc Desperrier Organization: Certplus X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Peter Lipp wrote: > > However, it does NOT necessarily say that the same > > 'timestamping' key can not be used for signing whatever else, for > > example a certificate. > > Looking at the current draft it says: > > A TSA is REQUIRED ... > 10. to sign each time stamp token using a key generated > exclusively for this purpose and have this property of the > key indicated on the corresponding certificate. > > I read "exclusively for this purpose" as "not allowed for signing > certificates". I wrote another answer before, but it seems I have sent it to Michael Zolotarev instead of to the list. It seems that the beginning of 2.3 and point 10 of 2.2 are a rewording of each other. After rereading, paragraph 2.3 does not explicitely forbid keyCertSign to be asserted, as this is a key usage bit, and not an extended keyusage. This said, if we take into account point 10, it sounds like this key usage bit should not be asserted. It would more explicit to have a list in the draft of the key usage bits that must/musn't be asserted. The message about the use of "certificates as trust anchor" suggests that it should not be necessary that the key usage bitfield of a self-signed certificate has the keyCertSign set for it to be accepted as a trust anchor. This seems to me to make sense. But from a practical point of view what does self-signed TSA cert means ? That there has been at least one point of time where your TSA hardware crypto module has been able to sign something that is not a time-stamp. I think that if a TSA is under a formal evaluation process, it will have to prove it's "impossible" to get it to sign something that is not a valid time stamp. Of course, the signing of this certificate would be done in an initial step, before the hardware crypto module is inserted inside the actual TSA operation process, but it does not sound that great. Also couldn't there be circonstances, where we would have to generate a new certificate, if the policy changes, etc... ? From owner-ietf-pkix@imc.org Wed Jun 21 10:22:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02820 for ; Wed, 21 Jun 2000 10:22:39 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA09966; Wed, 21 Jun 2000 07:15:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 07:15:50 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09935 for ; Wed, 21 Jun 2000 07:15:49 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FWI00L01CYN31@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 21 Jun 2000 07:15:59 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FWI00K8ACYNP9@ext-mail.valicert.com>; Wed, 21 Jun 2000 07:15:59 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 07:09:28 -0700 Content-return: allowed Date: Wed, 21 Jun 2000 07:09:26 -0700 From: Frank Balluffi Subject: RE: Using certificates as trust anchors To: "'Yassir Elley'" , ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE2E08B76@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Yassir asked: > If the trust anchor information is trusted because it > was delivered "out-of-band", can we use non-self-signed > certificates to provide the trust anchor information? draft-ietf-pkix-new-part1-01.txt, section 6, paragraph 4 states: The "most-trusted CA" is a matter of policy: it could be a root CA in a hierarchical PKI; the CA that issued the verifier's own certificate(s); or any other CA in a network PKI. The path valida- tion procedure is the same regardless of the choice of "most-trusted CA." My interpretation of the above paragraph is yes, the trust anchor need not be a self-signed root certificate, which leads me to ... I have a difficult time comprehending section 6 of RFC 2459 and draft-ietf-pkix-new-part1-01.txt. I believe the reason is that many terms are used without first being clearly defined. For example, the term root CA, in the above paragraph, appears once without being defined. The term root certificate does not appear in draft-ietf-pkix-new-part1-01.txt. As an aside, I would love to know how many times the terms root CA or root certificate appear in PKIX-related implementations, either in comments or variable names. Is there interest in formally defining the terms used in section 6? If yes, I would be more than willing to take a stab at defining the terms I deem relevant, including: certificate [Is currently defined in section 3.1.] certificate hierarchy root certificate superior (or parent) certificate subordinate (or child) certificate self-signed certificate trusted certificate certificate (or certification) path [Is currently defined in section 3.2.] Perhaps this would make it easier to for developers (such as myself) to convert the narrative into code. Frank > -----Original Message----- > From: Yassir Elley [mailto:yassir.elley@sun.com] > Sent: Tuesday, June 20, 2000 2:45 PM > To: ietf-pkix@imc.org > Subject: Using certificates as trust anchors > > > In looking over draft-ietf-pkix-new-part1-01.txt, a question > arises as to how to process trust anchors provided in the > form of a self-signed certificate. Since many applications > use such certificates > as trust anchors, I think it is important for PKIX to > explicitly spell out how > to process these certificates. > > Section 6.1.1 describes the five pieces of trust anchor > information and > mentions that the trust anchor information may be provided in the form > of a self-signed certificate. > > "(d) trust anchor information, describing a CA that serves as a > trust anchor for the certification path. The trust > anchor infor- > mation includes: > (1) the trusted issuer name, > (2) optionally, the trusted issuer unique identifier, > (3) the trusted public key algorithm, > (4) the trusted public key, and > (5) optionally, the trusted public key parameters associated > with the public key. > > The trust anchor information may be provided to the > path process- > ing procedure in the form of a self-signed certificate. The > trusted anchor information is trusted because it was > delivered to > the path processing procedure by some trustworthy "out-of-band" > procedure. If the trusted public key algorithm requires parame- > ters, then the parameters are provided along with the > trusted pub- > lic key." > > However, in other parts of Section 6, we find that the algorithm > also requires the validity period of the public key, as well > as other constraints (presumably this refers to initial > name constraints, policy constraints, basic > constraints[pathLenConstraint]?). > > For example: > "In section 6.1, the text describes basic path validation. This text > assumes that all valid paths begin with certificates > issued by a sin- > gle "most-trusted CA". The algorithm requires the public key of the > CA, the CA's name, the validity period of the public key, and any > constraints upon the set of paths which may be validated using this > key." > > Section 6.2 also refers to making use of the certificate's extensions > to limit the path. > "Limitations in the trust paths for any particular key may > be incorporated into the self-signed certificate's extensions. In > this way, the self-signed certificates permit the path validation > module to automatically incorporate local security policy and > requirements." > > If the trust anchor information is provided in the form of a > self-signed > certificate, we can certainly extract the five pieces of trust anchor > information mentioned in Section 6.1.1. > > Should we also be extracting other information from the certificate, > such as policy constraints, policy mappings, name constraints, and > basic constraints, and using these to initialize the relevant state > variables? What about the validity period of the public key? > Do we need to verify that the self-signed certificates's > validity period > includes time T? > > Do we need to validate the self-signed certificate itself? > (i.e. do we have to verify the self-signed certificate's signature, > revocation status, name chaining, uid chaining, that any > certificate policies and policy mappings are processed, > that it is a CA cert, that it has a keyCertSign key usage asserted, > that all critical extensions are processed?) > > If the trust anchor information is trusted because it > was delivered "out-of-band", can we use non-self-signed > certificates to provide the trust anchor information? > Perhaps I have a certificate that is not self-signed that I > trust for some "out-of-band" reason. I would think > that I should be able to use this certificate as a trust anchor > since I have designated it as trusted. If this is allowed, > it should be noted that we will not be able to > validate the signature, revocation status, name chaining, > and uid chaining checks because these checks rely > on a "previous" certificate's values which we don't have. > > One approach would be to not validate any part of > the trust anchor certificate and simply accept it > (whether or not it is self-signed) > because the user has designated it as "trusted", but > to extract any relevant information. In other words, > we wouldn't perform any of the steps in > 6.1.3 (Basic Certificate Processing) but we would > perform all the steps in 6.1.4 (Preparation for > Certificate i+1). > > All of these questions need to be answered explicitly > so that we can all process trust anchor certificates in > a standard way. > > -Yassir. > > > > From owner-ietf-pkix@imc.org Wed Jun 21 10:25:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02869 for ; Wed, 21 Jun 2000 10:25:29 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA10252; Wed, 21 Jun 2000 07:24:15 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 07:24:12 -0700 Received: from ponyexpress2.csc.com (ponyexpress2.csc.com [208.219.64.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10222 for ; Wed, 21 Jun 2000 07:24:11 -0700 (PDT) From: ghilborn@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress2.csc.com with smtp (Exim 2.12 #1) id 134lPy-0001Ha-00 for ietf-pkix@imc.org; Wed, 21 Jun 2000 10:23:50 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256905.004F1C63 ; Wed, 21 Jun 2000 10:24:06 -0400 X-Lotus-FromDomain: CSC To: ietf-pkix@imc.org cc: jean.med@arabtrust.com Message-ID: <85256905.004F19F5.00@csc.com> Date: Wed, 21 Jun 2000 10:23:09 -0400 Subject: Re: certification for pki Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe One internationally recognized avenue is an evaluation under the Common Criteria/ISO 15408. Such an evaluation up to EAL4 is automatically recognized by the (currently) nine mutual recognition arrangement countries. Two current problems are (1) that the CC itself does not contain a crypto module evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus and evaluated Protection Profile for PKI components. Some product vendors have undertanen evaluations without PPs. FIPS 140-1 is officially US/Canada, but also widely recognized. There is a maturing draft PP sponsored/created by the (US) National Institute of Science and Technology, which offers a selection of four levels of assurance for certificate issuing and management components (CIMC). See http://csrc.nist.gov/pki/documents/. For specific crypto module validation, it references FIPS 140-1, but also includes all the other system security funcional and assurance requirements appropriate to CIMC. -Gene Hilborn jean.med@arabtrust.com on 06/21/2000 06:00:06 AM To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: certification for pki Hi, Is there any internationally accredited certification for PKI Jean From owner-ietf-pkix@imc.org Wed Jun 21 10:27:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02901 for ; Wed, 21 Jun 2000 10:27:52 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA10488; Wed, 21 Jun 2000 07:26:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 07:26:35 -0700 Received: from irwell.zetnet.co.uk (root@irwell.zetnet.co.uk [194.247.47.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10458 for ; Wed, 21 Jun 2000 07:26:33 -0700 (PDT) Received: from jeffdavis (man-a190.dialup.zetnet.co.uk [194.247.44.190]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA05673 for ; Wed, 21 Jun 2000 15:26:42 +0100 X-Authentication-Warning: irwell.zetnet.co.uk: Host man-a190.dialup.zetnet.co.uk [194.247.44.190] claimed to be jeffdavis Message-ID: <008601bfdb8c$8defca70$7c2cf7c2@zetnet.co.uk> From: "Jeff Davis" To: Subject: Re: Private Key Cloning Date: Wed, 21 Jun 2000 15:25:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi, Being new to this group I would just like to add my 0.00001c ( or pennies in my case ) worth to this discussion. The whole idea of having a private key is just that, it is private to a single entity and not shared across many other "clones" of that entity. IMHO, and it is very "H" in this case, cloning a private key, of any nature, is opening yourselves up to all sorts of repudiation claims. If you clone once what stops you cloning "n" times without anyone knowing ( regardless of what procedures you have in place ). Part of the basis of "trust" is that a private key only exists in one place under the strict control of the owner of that key. I support the views put forward that maybe the TSA root should sign certificates for level 1 TSA Agents, of which there could be as many as required, but all of whom have a different DN ( very closely associated with the parent TSA ). The trust of the Time Stamp would then be through a normal certificate chain and that only being 1 level. Maybe the TSA root could then go offline leaving the "work horses" to perform the stamping. Re-issuing of new TSA signing keys would then be quite easy for each Agent, with only 1 out of "n" Agents being offline at any one time, update the hardware signing module and get back online a.s.a.p. I may be well off the mark here, if so, just tell me to shut up and get back in the cupboard. However, as I am trying to learn this stuff, a little help with my waywardness would go a long way. Jeff From owner-ietf-pkix@imc.org Wed Jun 21 10:39:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03164 for ; Wed, 21 Jun 2000 10:39:43 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA10864; Wed, 21 Jun 2000 07:36:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 07:36:34 -0700 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10833 for ; Wed, 21 Jun 2000 07:36:33 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 10:37:28 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C037@panda.chrysalis-its.com> To: ietf-pkix@imc.org Cc: jean-marc.desperrier@certplus.com Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Wed, 21 Jun 2000 10:37:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDB8E.391CBF4C" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDB8E.391CBF4C Content-Type: text/plain; charset="iso-8859-1" Jean-Marc Desperrier wrote: [snip] > > Also couldn't there be circonstances, where we would have to > generate a new certificate, if the policy changes, etc... ? In addition, a TSA private key would eventually expire. When a TSA using a self-signed certificate has to update its key pair, would it also have to generate three (3) certificates (i.e. the OldWithNew, NewWithOld and NewWithNew TSA certificates) as per Section 2.4 of RFC 2510? Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFDB8E.391CBF4C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: AW: self-signed TSA [Was Re: Private Key Cloning]

Jean-Marc Desperrier wrote:

[snip]
>
> Also couldn't there be circonstances, where we = would have to
> generate a new certificate, if the policy = changes, etc... ?

In addition, a TSA private key would eventually = expire.

When a TSA using a self-signed certificate has to = update its key pair, would it also have to generate three (3) = certificates (i.e. the OldWithNew, NewWithOld and NewWithNew TSA = certificates) as per Section 2.4 of RFC 2510?

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01BFDB8E.391CBF4C-- From owner-ietf-pkix@imc.org Wed Jun 21 11:13:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03799 for ; Wed, 21 Jun 2000 11:13:36 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA12153; Wed, 21 Jun 2000 08:11:55 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 08:11:41 -0700 Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12099 for ; Wed, 21 Jun 2000 08:11:38 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id DAA04418 for ; Thu, 22 Jun 2000 03:11:43 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96160030324826>; Thu, 22 Jun 2000 03:11:43 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: Re: certification for pki Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Thu, 22 Jun 2000 03:11:43 (NZST) Message-ID: <96160030324826@kahu.cs.auckland.ac.nz> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe ghilborn@csc.com writes: >One internationally recognized avenue is an evaluation under the Common >Criteria/ISO 15408. Such an evaluation up to EAL4 is automatically recognized >by the (currently) nine mutual recognition arrangement countries. Two current >problems are (1) that the CC itself does not contain a crypto module >evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus >and evaluated Protection Profile for PKI components. Some product vendors >have undertanen evaluations without PPs. FIPS 140-1 is officially US/Canada, >but also widely recognized. A third problem with the CC, for those who haven't experienced it before, is that it acts as a form of torture for companies to determine how badly they need government (or whatever) contracts - the more pain you can stand, the better you've demonstrated that you need the contract. I'm not just saying this for $generic_CC_bashing, from talking to people who have gone through it it really sounds like an incredibly unpleasant experience (when I used the term "torture" to describe it above this doesn't originate with me but with the people I talked to). In terms of achieving more or less the same effect (the certification that is, not the torture :-) it looks like FIPS 140 is the easier path, and it does constitute a de facto PP which the CC doesn't have yet. I'd go with FIPS 140. Peter. From owner-ietf-pkix@imc.org Wed Jun 21 11:51:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04603 for ; Wed, 21 Jun 2000 11:51:08 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16403; Wed, 21 Jun 2000 08:49:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 08:48:56 -0700 Received: from ponyexpress2.csc.com (ponyexpress2.csc.com [208.219.64.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16356 for ; Wed, 21 Jun 2000 08:48:55 -0700 (PDT) From: ghilborn@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress2.csc.com with smtp (Exim 2.12 #1) id 134mjx-00036P-01; Wed, 21 Jun 2000 11:48:33 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256905.0056D888 ; Wed, 21 Jun 2000 11:48:35 -0400 X-Lotus-FromDomain: CSC To: pgut001@cs.auckland.ac.nz cc: ietf-pkix@imc.org Message-ID: <85256905.0056D63D.00@csc.com> Date: Wed, 21 Jun 2000 11:47:39 -0400 Subject: Re: certification for pki Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe It is not a choice of CC vs. FIPS. The FIPS 140-1 testing pertains narrowly to crypto modules. The CC evaluation/"torture" process is about the system/components for certificate issuance and management meeting its security specification (security target and claimed PP(s)). A crypto module is just an embedded "engine" in the larger vehicle. To continue with the automotive metaphor, it is not a choice between auto emission testing vs. crash testing vs. fuel economy vs. performance testing, etc. All of these tests may be required for the consumer to understand and compare what they are buying. It may be "torture" for the manufacturer, but when the market (or laws, regulations, etc.) demand it, manufacturers do it. -GH pgut001@cs.auckland.ac.nz on 06/21/2000 11:11:43 PM Please respond to pgut001@cs.auckland.ac.nz To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: Re: certification for pki ghilborn@csc.com writes: >One internationally recognized avenue is an evaluation under the Common >Criteria/ISO 15408. Such an evaluation up to EAL4 is automatically recognized >by the (currently) nine mutual recognition arrangement countries. Two current >problems are (1) that the CC itself does not contain a crypto module >evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus >and evaluated Protection Profile for PKI components. Some product vendors >have undertanen evaluations without PPs. FIPS 140-1 is officially US/Canada, >but also widely recognized. A third problem with the CC, for those who haven't experienced it before, is that it acts as a form of torture for companies to determine how badly they need government (or whatever) contracts - the more pain you can stand, the better you've demonstrated that you need the contract. I'm not just saying this for $generic_CC_bashing, from talking to people who have gone through it it really sounds like an incredibly unpleasant experience (when I used the term "torture" to describe it above this doesn't originate with me but with the people I talked to). In terms of achieving more or less the same effect (the certification that is, not the torture :-) it looks like FIPS 140 is the easier path, and it does constitute a de facto PP which the CC doesn't have yet. I'd go with FIPS 140. Peter. From owner-ietf-pkix@imc.org Wed Jun 21 12:15:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06213 for ; Wed, 21 Jun 2000 12:15:09 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA18770; Wed, 21 Jun 2000 09:08:41 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 09:08:38 -0700 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18729 for ; Wed, 21 Jun 2000 09:08:37 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 12:09:33 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C039@panda.chrysalis-its.com> To: ghilborn@csc.com Cc: jean.med@arabtrust.com, ietf-pkix@imc.org Subject: RE: certification for pki Date: Wed, 21 Jun 2000 12:09:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDB9B.166638B8" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDB9B.166638B8 Content-Type: text/plain; charset="iso-8859-1" Gene, However, the major drawback with the Certificate Issuing and Management Component (CIMC) Protection Profile (PP) sponsored/created by the (US) National Institute of Science and Technology (NIST) is that the current version still specifies about 25 new security functional requirements (SFRs) that are NOT included in the Common Criteria (CC)/ISO 15408 instead of using the refinement and/or the iteration operations on existing CC security functional requirements. In addition, all these additional security functional requirements from the NIST CIMC PP would probably not be recognised through the mutual recognition arrangement (MRA). Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: ghilborn@csc.com [mailto:ghilborn@csc.com] Sent: Wednesday, June 21, 2000 10:23 AM To: ietf-pkix@imc.org Cc: jean.med@arabtrust.com Subject: Re: certification for pki One internationally recognized avenue is an evaluation under the Common Criteria/ISO 15408. Such an evaluation up to EAL4 is automatically recognized by the (currently) nine mutual recognition arrangement countries. Two current problems are (1) that the CC itself does not contain a crypto module evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus and evaluated Protection Profile for PKI components. Some product vendors have undertanen evaluations without PPs. FIPS 140-1 is officially US/Canada, but also widely recognized. There is a maturing draft PP sponsored/created by the (US) National Institute of Science and Technology, which offers a selection of four levels of assurance for certificate issuing and management components (CIMC). See http://csrc.nist.gov/pki/documents/. For specific crypto module validation, it references FIPS 140-1, but also includes all the other system security funcional and assurance requirements appropriate to CIMC. -Gene Hilborn jean.med@arabtrust.com on 06/21/2000 06:00:06 AM To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: certification for pki Hi, Is there any internationally accredited certification for PKI Jean ------_=_NextPart_001_01BFDB9B.166638B8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: certification for pki

Gene,

However, the major drawback with the Certificate = Issuing and Management Component (CIMC) Protection Profile (PP) = sponsored/created by the (US) National Institute of Science and = Technology (NIST) is that the current version still specifies about 25 = new security functional requirements (SFRs) that are NOT included in = the Common Criteria (CC)/ISO 15408 instead of using the refinement = and/or the iteration operations on existing CC security functional = requirements.

In addition, all these additional security functional = requirements from the NIST CIMC PP would probably not be recognised = through the mutual recognition arrangement (MRA).

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078


-----Original Message-----
From: ghilborn@csc.com [mailto:ghilborn@csc.com]
Sent: Wednesday, June 21, 2000 10:23 AM
To: ietf-pkix@imc.org
Cc: jean.med@arabtrust.com
Subject: Re: certification for pki

One internationally recognized avenue is an = evaluation under the Common
Criteria/ISO 15408.  Such an evaluation up to = EAL4 is automatically recognized
by the (currently) nine mutual recognition = arrangement countries.  Two current
problems are (1) that the CC itself does not contain = a crypto module evaluation
standard such as FIPS 140-1/2, and (2) there is not = yet a consensus and
evaluated Protection Profile for PKI = components.   Some product vendors have
undertanen evaluations without PPs.  FIPS 140-1 = is officially US/Canada, but
also widely recognized.

There is a maturing draft PP sponsored/created by the = (US) National Institute of
Science and Technology,  which offers a = selection of four levels of assurance
for certificate issuing and management components = (CIMC).  See
http://csrc.nist.gov/pki/documents/.  For = specific crypto module validation, it
references FIPS 140-1, but also includes all the = other system security funcional
and assurance requirements appropriate to = CIMC.

-Gene Hilborn


jean.med@arabtrust.com on 06/21/2000 06:00:06 = AM

To:   ietf-pkix@imc.org
cc:    (bcc: Gene = Hilborn/DEF/CSC)
Subject:  certification for pki

Hi,

Is there any internationally accredited certification = for PKI

Jean

------_=_NextPart_001_01BFDB9B.166638B8-- From owner-ietf-pkix@imc.org Wed Jun 21 12:33:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07267 for ; Wed, 21 Jun 2000 12:33:49 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA22609; Wed, 21 Jun 2000 09:31:32 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 09:31:22 -0700 Received: from laemail.bankofamerica.com (laemail.bankofamerica.com [171.161.96.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22529 for ; Wed, 21 Jun 2000 09:31:22 -0700 (PDT) Received: from laimail.bankofamerica.com (laimail.bankofamerica.com [171.182.104.13]) by laemail.bankofamerica.com (8.9.1/8.9.1) with ESMTP id JAA18275; Wed, 21 Jun 2000 09:31:02 -0700 (PDT) Received: from smtpsw03 (smtpsw03.bankofamerica.com [165.48.14.143]) by laimail.bankofamerica.com (8.9.1/8.9.1) with ESMTP id JAA25205; Wed, 21 Jun 2000 09:31:02 -0700 (PDT) Date: Wed, 21 Jun 2000 09:31:04 -0700 From: Mack Hicks Subject: Re: certification for pki To: ghilborn@csc.com Cc: ietf-pkix@imc.org Message-id: <3950EDC8.C397650C@bankofamerica.com> MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <85256905.0056D63D.00@csc.com> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7BIT GH, As a "consumer", a banking business, of these products and services -- and as one who is also deploying into the marketplace, I do demand some testing and review. I also ask how much all this security is costing, and what risks are being minimized or eliminated. What I do NOT demand is the use of a "military threat" model in a commercial context. I define "military threat" as "a fault in security could ultimately lead to nuclear war - so no faults are allowed". What I mean is that most of the evaluations and criteria I have seen, like the AICPA draft and the ANSI X9.79 draft, are regarding risks as if they cannot be commercially controlled. To this end, Bank of America has voted "NO" on the first round of balloting for ANSI X9.79, and I encourage all other ANSI members to do the same. I mention this in the context of the mailing list discussion on private key cloning for commercial servers. Given budget constraints and the cost of the cryptographic hardware - not to mention the operational costs and customer (client) impact - there is no choice but to have some cloning and/or key backup of server signing keys. These keys are just too important to business flow to leave to a single location or piece of hardware. Admittedly, when one is acting in a position of trust for other organizations, care must be exercised - but it must be compatible and commensurate with the risk involved - not just to the risk to the keys but much more importantly - to the on-going operation of our customer's business. Further, when key management hardware is deployed to commercial servers that are not under bank security guidelines (like we do with credit card merchants today), there is an even greater need for resilience and key backup. The cost of hardware replication or the cost of business interruption (for rekeying and certification) is too high for the associated risk and perceived security benefit. ghilborn@csc.com wrote: > ... It may be > "torture" for the manufacturer, but when the market (or laws, regulations, etc.) > demand it, manufacturers do it. > -GH ------------------------------------------------- Mack Hicks, SVP mack.hicks@bankofamerica.com Bank of America +1-415-436-5809 From owner-ietf-pkix@imc.org Wed Jun 21 12:49:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08106 for ; Wed, 21 Jun 2000 12:49:03 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA25486; Wed, 21 Jun 2000 09:47:48 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 09:47:46 -0700 Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25455 for ; Wed, 21 Jun 2000 09:47:43 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id EAA07854 for ; Thu, 22 Jun 2000 04:47:52 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96160607224858>; Thu, 22 Jun 2000 04:47:52 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: Re: certification for pki Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Thu, 22 Jun 2000 04:47:52 (NZST) Message-ID: <96160607224858@kahu.cs.auckland.ac.nz> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe ghilborn@csc.com writes: >It is not a choice of CC vs. FIPS. The FIPS 140-1 testing pertains narrowly >to crypto modules. The CC evaluation/"torture" process is about the >system/components for certificate issuance and management meeting its security >specification (security target and claimed PP(s)). Oh, so the interest is in certifying the PKI process rather than machinery which makes it possible? In that case there's a whole host of standards to choose from, from ISO there's ISO 15782-1, Banking - Certificate Management, from ANSI theres X9.57 Certificate Management and ANSI X9.79, PKI Practices and Framework, and from vendors there's both VISA and MC's SET PKI requirements (which, while in some cases SET-specific), are well thought out. Would any of those be usable as a PP? Peter. From owner-ietf-pkix@imc.org Wed Jun 21 13:09:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08866 for ; Wed, 21 Jun 2000 13:09:32 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA26279; Wed, 21 Jun 2000 10:08:03 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 10:07:59 -0700 Received: from cnbskpt2.cnbs.navy.mil (cnbskpt2.cnbs.navy.mil [164.221.184.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26248 for ; Wed, 21 Jun 2000 10:07:57 -0700 (PDT) Received: by cnbskpt2.cnbs.navy.mil with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Jun 2000 10:04:15 -0700 Message-ID: <07278C38CF83D21181B200105AA34A858B82D6@cnbskpt2.cnbs.navy.mil> From: "Morrill, Dan" To: "'pgut001@cs.auckland.ac.nz'" , ietf-pkix@imc.org Subject: RE: certification for pki Date: Wed, 21 Jun 2000 10:04:13 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I don't suppose that out there on the net or in committee, there is one unifying document to take care of both the PKI process and the machinery that it is stored on as a mutually agreed upon set of standards? If not, maybe it would be good for this panel to make one? Just a thought. r/ Dan Morrill CSC -----Original Message----- From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz] Sent: Wednesday, June 21, 2000 09:48 PM To: ietf-pkix@imc.org Subject: Re: certification for pki ghilborn@csc.com writes: >It is not a choice of CC vs. FIPS. The FIPS 140-1 testing pertains narrowly >to crypto modules. The CC evaluation/"torture" process is about the >system/components for certificate issuance and management meeting its security >specification (security target and claimed PP(s)). Oh, so the interest is in certifying the PKI process rather than machinery which makes it possible? In that case there's a whole host of standards to choose from, from ISO there's ISO 15782-1, Banking - Certificate Management, from ANSI theres X9.57 Certificate Management and ANSI X9.79, PKI Practices and Framework, and from vendors there's both VISA and MC's SET PKI requirements (which, while in some cases SET-specific), are well thought out. Would any of those be usable as a PP? Peter. From owner-ietf-pkix@imc.org Wed Jun 21 14:29:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10688 for ; Wed, 21 Jun 2000 14:29:54 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA27661; Wed, 21 Jun 2000 11:28:21 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 11:28:14 -0700 Received: from ponyexpress6.csc.com (ponyexpress6.csc.com [208.219.64.207]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27630 for ; Wed, 21 Jun 2000 11:28:13 -0700 (PDT) From: ghilborn@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress6.csc.com with smtp (Exim 2.12 #1) id 134pDy-0007fb-00; Wed, 21 Jun 2000 14:27:42 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256905.006572C7 ; Wed, 21 Jun 2000 14:28:05 -0400 X-Lotus-FromDomain: CSC To: pgut001@cs.auckland.ac.nz cc: ietf-pkix@imc.org Message-ID: <85256905.0065702D.00@csc.com> Date: Wed, 21 Jun 2000 14:27:10 -0400 Subject: Re: certification for pki Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Peter, I said nothing about "certifying the PKI process." Rather I spoke of the process of certifying the products (CC and FIPS). -Gene pgut001@cs.auckland.ac.nz on 06/22/2000 12:47:52 AM Please respond to pgut001@cs.auckland.ac.nz To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: Re: certification for pki ghilborn@csc.com writes: >It is not a choice of CC vs. FIPS. The FIPS 140-1 testing pertains narrowly >to crypto modules. The CC evaluation/"torture" process is about the >system/components for certificate issuance and management meeting its security >specification (security target and claimed PP(s)). Oh, so the interest is in certifying the PKI process rather than machinery which makes it possible? In that case there's a whole host of standards to choose from, from ISO there's ISO 15782-1, Banking - Certificate Management, from ANSI theres X9.57 Certificate Management and ANSI X9.79, PKI Practices and Framework, and from vendors there's both VISA and MC's SET PKI requirements (which, while in some cases SET-specific), are well thought out. Would any of those be usable as a PP? Peter. From owner-ietf-pkix@imc.org Wed Jun 21 14:53:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11106 for ; Wed, 21 Jun 2000 14:53:25 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA28178; Wed, 21 Jun 2000 11:43:34 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 11:43:32 -0700 Received: from ponyexpress4.csc.com (ponyexpress4.csc.com [208.219.64.203]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28147 for ; Wed, 21 Jun 2000 11:43:17 -0700 (PDT) From: ghilborn@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress4.csc.com with smtp (Exim 2.12 #1) id 134pSh-0001WU-00 for ietf-pkix@imc.org; Wed, 21 Jun 2000 14:42:55 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256905.0066D553 ; Wed, 21 Jun 2000 14:43:12 -0400 X-Lotus-FromDomain: CSC To: FRousseau@chrysalis-its.com cc: ietf-pkix@imc.org Message-ID: <85256905.0066D323.00@csc.com> Date: Wed, 21 Jun 2000 14:42:12 -0400 Subject: RE: certification for pki Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0QwgtU9BSQQ4HjJODHxsbZkidPG5u58Ri4RqOKNcIJuWTfFQzZOpHbfs" Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --0__=0QwgtU9BSQQ4HjJODHxsbZkidPG5u58Ri4RqOKNcIJuWTfFQzZOpHbfs Content-type: text/plain; charset=us-ascii Content-Disposition: inline I apologize to the pkix list if the following is getting to be too off-topic, and would be happy to take it off list if anyone wishes. Francois, I agree generally with your critique of NIST's draft CIMC PP, in the sense that its authors probably made over-liberal use of creating new security functional requirements that are not in the CC, rather than using the SFRs available. They probably could have done a much better job of using the existing SFRs with creative use of legitimate operations (selection, assignment, iteration, and refinement). However, I disagree with the statement that "all these additional requirements would probably not be recognized through the mutual recognition." The MRA http://niap.nist.gov/cc-scheme/DownloadCCMRA.html does not recognize "requirements;" it does recognize CC evaluation certificates for PPs and IT products evaluated under the member national schemes. A proper use of custom or "explicit" SFRs and/or security assurance requirements (SARs) is most definitely provided for in the CC. For example, in CC part 1 paragraph 5.2 we have: "The CC recognizes the possibility that functional and assurance requirements not included in the provided catalogues may be required in order to represent the complete set of IT security requirements. The following shall apply to the inclusion of these extended functional or assurance requirements: ..." The exact CC requirements for SFR/SAR extension in a PP are further elaborated in the Annex B Specification of Protection Profiles. If done properly and justified in the PP/ST rationale, the use of explicit/extended SFRs in no way invalidates a PP or product evaluation. The PP/ST author does have the burden of justifying the use of any explicit (extended) requirements (which IMO the CIMC PP authors have failed to do in the current draft). Once a PP (even with explicit SFRs) has been successfully evaluated under one of the national schemes it's evaluation will be mutually recognized. Once a product with an ST claiming compliance to such a PP has been successfully evaluated under one of the national schemes it's evaluation will be mutually recognized. -GH FRousseau@chrysalis-its.com on 06/21/2000 12:09:18 PM To: Gene Hilborn/DEF/CSC@CSC cc: jean.med@arabtrust.com, ietf-pkix@imc.org Subject: RE: certification for pki Gene, However, the major drawback with the Certificate Issuing and Management Component (CIMC) Protection Profile (PP) sponsored/created by the (US) National Institute of Science and Technology (NIST) is that the current version still specifies about 25 new security functional requirements (SFRs) that are NOT included in the Common Criteria (CC)/ISO 15408 instead of using the refinement and/or the iteration operations on existing CC security functional requirements. In addition, all these additional security functional requirements from the NIST CIMC PP would probably not be recognised through the mutual recognition arrangement (MRA). Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: ghilborn@csc.com [mailto:ghilborn@csc.com] Sent: Wednesday, June 21, 2000 10:23 AM To: ietf-pkix@imc.org Cc: jean.med@arabtrust.com Subject: Re: certification for pki One internationally recognized avenue is an evaluation under the Common Criteria/ISO 15408. Such an evaluation up to EAL4 is automatically recognized by the (currently) nine mutual recognition arrangement countries. Two current problems are (1) that the CC itself does not contain a crypto module evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus and evaluated Protection Profile for PKI components. Some product vendors have undertanen evaluations without PPs. FIPS 140-1 is officially US/Canada, but also widely recognized. There is a maturing draft PP sponsored/created by the (US) National Institute of Science and Technology, which offers a selection of four levels of assurance for certificate issuing and management components (CIMC). See http://csrc.nist.gov/pki/documents/. For specific crypto module validation, it references FIPS 140-1, but also includes all the other system security funcional and assurance requirements appropriate to CIMC. -Gene Hilborn jean.med@arabtrust.com on 06/21/2000 06:00:06 AM To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: certification for pki Hi, Is there any internationally accredited certification for PKI Jean --0__=0QwgtU9BSQQ4HjJODHxsbZkidPG5u58Ri4RqOKNcIJuWTfFQzZOpHbfs Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1MC4xMiI+DQo8VElUTEU+UkU6IGNl cnRpZmljYXRpb24gZm9yIHBraTwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQg U0laRT0yPkdlbmUsPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SG93ZXZlciwgdGhl IG1ham9yIGRyYXdiYWNrIHdpdGggdGhlIENlcnRpZmljYXRlIElzc3VpbmcgYW5kIE1hbmFnZW1l bnQgQ29tcG9uZW50IChDSU1DKSBQcm90ZWN0aW9uIFByb2ZpbGUgKFBQKSBzcG9uc29yZWQvY3Jl YXRlZCBieSB0aGUgKFVTKSBOYXRpb25hbCBJbnN0aXR1dGUgb2YgU2NpZW5jZSBhbmQgVGVjaG5v bG9neSAoTklTVCkgaXMgdGhhdCB0aGUgY3VycmVudCB2ZXJzaW9uIHN0aWxsIHNwZWNpZmllcyBh Ym91dCAyNSBuZXcgc2VjdXJpdHkgZnVuY3Rpb25hbCByZXF1aXJlbWVudHMgKFNGUnMpIHRoYXQg YXJlIE5PVCBpbmNsdWRlZCBpbiB0aGUgQ29tbW9uIENyaXRlcmlhIChDQykvSVNPIDE1NDA4IGlu c3RlYWQgb2YgdXNpbmcgdGhlIHJlZmluZW1lbnQgYW5kL29yIHRoZSBpdGVyYXRpb24gb3BlcmF0 aW9ucyBvbiBleGlzdGluZyBDQyBzZWN1cml0eSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cy48L0ZP TlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SW4gYWRkaXRpb24sIGFsbCB0aGVzZSBhZGRpdGlv bmFsIHNlY3VyaXR5IGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGZyb20gdGhlIE5JU1QgQ0lNQyBQ UCB3b3VsZCBwcm9iYWJseSBub3QgYmUgcmVjb2duaXNlZCB0aHJvdWdoIHRoZSBtdXR1YWwgcmVj b2duaXRpb24gYXJyYW5nZW1lbnQgKE1SQSkuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y PkZyYW5jb2lzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+RnJhbmNvaXMgUm91c3NlYXU8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkRpcmVjdG9yIG9mIFN0YW5kYXJkcyBhbmQgQ29uZm9y bWFuY2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkNocnlzYWxpcy1JVFM8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPjE2ODggV29vZHdhcmQgRHJpdmU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y Pk90dGF3YSwgT250YXJpbywgQ0FOQURBLCBLMkMgM1I3PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj5mcm91c3NlYXVAY2hyeXNhbGlzLWl0cy5jb20mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVGVsLiAoNjEzKSA3MjMtNTA3NiBleHQuIDQxOTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ PEEgSFJFRj0iaHR0cDovL3d3dy5jaHJ5c2FsaXMtaXRzLmNvbSIgVEFSR0VUPSJfYmxhbmsiPmh0 dHA6Ly93d3cuY2hyeXNhbGlzLWl0cy5jb208L0E+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZh eC4gKDYxMykgNzIzLTUwNzg8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+RnJvbTog Z2hpbGJvcm5AY3NjLmNvbSBbPEEgSFJFRj0ibWFpbHRvOmdoaWxib3JuQGNzYy5jb20iPm1haWx0 bzpnaGlsYm9ybkBjc2MuY29tPC9BPl08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlNlbnQ6IFdl ZG5lc2RheSwgSnVuZSAyMSwgMjAwMCAxMDoyMyBBTTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ VG86IGlldGYtcGtpeEBpbWMub3JnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5DYzogamVhbi5t ZWRAYXJhYnRydXN0LmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+U3ViamVjdDogUmU6IGNl cnRpZmljYXRpb24gZm9yIHBraTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPk9uZSBp bnRlcm5hdGlvbmFsbHkgcmVjb2duaXplZCBhdmVudWUgaXMgYW4gZXZhbHVhdGlvbiB1bmRlciB0 aGUgQ29tbW9uPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Dcml0ZXJpYS9JU08gMTU0MDguJm5i c3A7IFN1Y2ggYW4gZXZhbHVhdGlvbiB1cCB0byBFQUw0IGlzIGF1dG9tYXRpY2FsbHkgcmVjb2du aXplZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+YnkgdGhlIChjdXJyZW50bHkpIG5pbmUgbXV0 dWFsIHJlY29nbml0aW9uIGFycmFuZ2VtZW50IGNvdW50cmllcy4mbmJzcDsgVHdvIGN1cnJlbnQ8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnByb2JsZW1zIGFyZSAoMSkgdGhhdCB0aGUgQ0MgaXRz ZWxmIGRvZXMgbm90IGNvbnRhaW4gYSBjcnlwdG8gbW9kdWxlIGV2YWx1YXRpb248L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPnN0YW5kYXJkIHN1Y2ggYXMgRklQUyAxNDAtMS8yLCBhbmQgKDIpIHRo ZXJlIGlzIG5vdCB5ZXQgYSBjb25zZW5zdXMgYW5kPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5l dmFsdWF0ZWQgUHJvdGVjdGlvbiBQcm9maWxlIGZvciBQS0kgY29tcG9uZW50cy4mbmJzcDsmbmJz cDsgU29tZSBwcm9kdWN0IHZlbmRvcnMgaGF2ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dW5k ZXJ0YW5lbiBldmFsdWF0aW9ucyB3aXRob3V0IFBQcy4mbmJzcDsgRklQUyAxNDAtMSBpcyBvZmZp Y2lhbGx5IFVTL0NhbmFkYSwgYnV0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5hbHNvIHdpZGVs eSByZWNvZ25pemVkLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlRoZXJlIGlzIGEg bWF0dXJpbmcgZHJhZnQgUFAgc3BvbnNvcmVkL2NyZWF0ZWQgYnkgdGhlIChVUykgTmF0aW9uYWwg SW5zdGl0dXRlIG9mPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TY2llbmNlIGFuZCBUZWNobm9s b2d5LCZuYnNwOyB3aGljaCBvZmZlcnMgYSBzZWxlY3Rpb24gb2YgZm91ciBsZXZlbHMgb2YgYXNz dXJhbmNlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5mb3IgY2VydGlmaWNhdGUgaXNzdWluZyBh bmQgbWFuYWdlbWVudCBjb21wb25lbnRzIChDSU1DKS4mbmJzcDsgU2VlPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj48QSBIUkVGPSJodHRwOi8vY3NyYy5uaXN0Lmdvdi9wa2kvZG9jdW1lbnRzLyIg VEFSR0VUPSJfYmxhbmsiPmh0dHA6Ly9jc3JjLm5pc3QuZ292L3BraS9kb2N1bWVudHMvPC9BPi4m bmJzcDsgRm9yIHNwZWNpZmljIGNyeXB0byBtb2R1bGUgdmFsaWRhdGlvbiwgaXQ8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPnJlZmVyZW5jZXMgRklQUyAxNDAtMSwgYnV0IGFsc28gaW5jbHVkZXMg YWxsIHRoZSBvdGhlciBzeXN0ZW0gc2VjdXJpdHkgZnVuY2lvbmFsPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj5hbmQgYXNzdXJhbmNlIHJlcXVpcmVtZW50cyBhcHByb3ByaWF0ZSB0byBDSU1DLjwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi1HZW5lIEhpbGJvcm48L0ZPTlQ+DQo8L1A+ DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5qZWFuLm1lZEBhcmFidHJ1c3QuY29tIG9uIDA2LzIx LzIwMDAgMDY6MDA6MDYgQU08L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UbzombmJz cDsmbmJzcDsgaWV0Zi1wa2l4QGltYy5vcmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmNjOiZu YnNwOyZuYnNwOyZuYnNwOyAoYmNjOiBHZW5lIEhpbGJvcm4vREVGL0NTQyk8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPlN1YmplY3Q6Jm5ic3A7IGNlcnRpZmljYXRpb24gZm9yIHBraTwvRk9OVD4N CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkhpLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0la RT0yPklzIHRoZXJlIGFueSBpbnRlcm5hdGlvbmFsbHkgYWNjcmVkaXRlZCBjZXJ0aWZpY2F0aW9u IGZvciBQS0k8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5KZWFuPC9GT05UPg0KPC9Q Pg0KDQo8L0JPRFk+DQo8L0hUTUw+DQo= --0__=0QwgtU9BSQQ4HjJODHxsbZkidPG5u58Ri4RqOKNcIJuWTfFQzZOpHbfs-- From owner-ietf-pkix@imc.org Wed Jun 21 19:23:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14772 for ; Wed, 21 Jun 2000 19:23:47 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA02748; Wed, 21 Jun 2000 16:22:33 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 16:22:18 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02706 for ; Wed, 21 Jun 2000 16:22:16 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA20661; Thu, 22 Jun 2000 09:27:33 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Jun 2000 09:21:14 +1000 Message-ID: From: Michael Zolotarev To: Peter Lipp , Jean-Marc Desperrier , ietf-pkix@imc.org Subject: RE: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 09:21:13 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I see. But do you think that the requirement should be loosen up a bit, in order to accommodate self-signed certificates? > -----Original Message----- > From: Peter Lipp [mailto:Peter.Lipp@iaik.at] > Sent: Wednesday, June 21, 2000 10:24 PM > To: Michael Zolotarev; Jean-Marc Desperrier; ietf-pkix@imc.org > Subject: AW: self-signed TSA [Was Re: Private Key Cloning] > > > > However, it does NOT necessarily say that the same > > 'timestamping' key can not be used for signing whatever else, for > > example a certificate. > > Looking at the current draft it sais: > > A TSA is REQUIRED ... > 10. to sign each time stamp token using a key generated > exclusively for this purpose and have this property of the > key indicated on the corresponding certificate. > > I read "exclusively for this purpose" as "not allowed for signing > certificates". > > Peter > > > From owner-ietf-pkix@imc.org Wed Jun 21 19:47:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15030 for ; Wed, 21 Jun 2000 19:47:13 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA03284; Wed, 21 Jun 2000 16:46:08 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 16:46:05 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03253 for ; Wed, 21 Jun 2000 16:46:04 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA20926; Thu, 22 Jun 2000 09:51:46 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Jun 2000 09:45:27 +1000 Message-ID: From: Michael Zolotarev To: Jean-Marc Desperrier , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 09:45:26 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > > But from a practical point of view what does self-signed TSA > cert means? > That there has been at least one point of time where your TSA hardware > crypto module has been able to sign something that is not a > time-stamp. If we forget for a moment about what the draft says (please): what is wrong with using a TSA key for signing 'something that is not a time-stamp'? I do not see anything criminal about that. Especially if the case is well-defined and justified. Please do not mistake this with signing a timestamp with a 'wrong' key. That would be just too bad. > I think that if a TSA is under a formal evaluation process, > it will have to prove it's "impossible" to get it to sign something that is not a > valid time stamp. Considering what I said above, we won't have to prove it at all. > > Of course, the signing of this certificate would be done in an initial > step, before the hardware crypto module is inserted inside the actual > TSA operation process, but it does not sound that great. > Also couldn't there be circonstances, where we would have to > generate a > new certificate, if the policy changes, etc... ? > Under those circumstances a new key would need to be generated, most likely. Michael From owner-ietf-pkix@imc.org Wed Jun 21 20:23:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15505 for ; Wed, 21 Jun 2000 20:23:06 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA03808; Wed, 21 Jun 2000 17:19:54 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 17:19:47 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA03778 for ; Wed, 21 Jun 2000 17:19:45 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA21258; Thu, 22 Jun 2000 10:24:50 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Jun 2000 10:18:31 +1000 Message-ID: From: Michael Zolotarev To: Jeff Davis , ietf-pkix@imc.org Subject: RE: Private Key Cloning Date: Thu, 22 Jun 2000 10:18:30 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Jeff wrote: > The whole idea of having a private key is just that, it is > private to a > single entity and not shared across many other "clones" of > that entity. > > IMHO, and it is very "H" in this case, cloning a private key, of any > nature, is opening yourselves up to all sorts of repudiation > claims. If > you clone once what stops you cloning "n" times without > anyone knowing > ( regardless of what procedures you have in place ). Part of > the basis > of "trust" is that a private key only exists in one place under the > strict control of the owner of that key. The cloning procedure becomes a critical part, I agree. So the authority would have to certify both the security/procedures of its operational environment, and the security/procedures of key cloning. The same scale of precautions that currently applies to keeping the [only and single] key secure would apply to the cloning process. If you suspect that the cloning may allow a criminal-minded high-privileged insider to perpetrate a fraud, then for the same reason your should similarly suspect any other security aspects of the authority operations. We must always consider every particular case of key cloning, instead of dismissing the whole concept. If a particular cloning procedure, executed by a particular authority, using given hardware, in a particular secure environment etc etc can be formally certified as being sufficiently secure, at least not less(!) secure than the rest of the solution - what is wrong with it? If you can prove that your solution is secure - that would be just fine. Why reject the approach on the basis that it MAY present a security hole. Following that logic, whole PKI would be extinct by now. > > I support the views put forward that maybe the TSA root should sign > certificates for level 1 TSA Agents, of which there could be > as many as > required, but all of whom have a different DN ( very closely > associated > with the parent TSA ). The trust of the Time Stamp would then be > through a normal certificate chain and that only being 1 level. Maybe > the TSA root could then go offline leaving the "work horses" > to perform > the stamping. Re-issuing of new TSA signing keys would then be quite > easy for each Agent, with only 1 out of "n" Agents being > offline at any > one time, update the hardware signing module and get back online > a.s.a.p. > > I may be well off the mark here, if so, just tell me to shut > up and get > back in the cupboard. However, as I am trying to learn this stuff, a > little help with my waywardness would go a long way. > I'm also new to the house. But I've learned that there are two words missing in the group's dictionary - "beautiful" and "shut up". Three words, actually :) M From owner-ietf-pkix@imc.org Wed Jun 21 22:49:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18636 for ; Wed, 21 Jun 2000 22:49:25 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA13914; Wed, 21 Jun 2000 19:44:28 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 19:43:16 -0700 Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13774 for ; Wed, 21 Jun 2000 19:43:13 -0700 (PDT) Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id MAA30030; Thu, 22 Jun 2000 12:43:05 +1000 (EST) Message-ID: <018a01bfdbf4$c92e2150$8802a8c0@eracom.com.au> From: "Simon McMahon" To: "Michael Zolotarev" , "Jean-Marc Desperrier" , References: Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 12:51:06 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Michael wrote: > > If we forget for a moment about what the draft says (please): what is wrong > with using a TSA key for signing 'something that is not a time-stamp'? I do > not see anything criminal about that. Especially if the case is well-defined > and justified. > The draft obviously said it for a reason but to answer "what is wrong with using a TSA key for signing 'something that is not a time-stamp'?" 1. Its good security policy to restrict usage of particularly sensitive keys. The ultimate restriction is one exclusive use which is the state of the draft now. You should show a very good reason to weaken that or show that the new usage has negligable impact. If you do this then an attack on certificate signing keys will be useful as an attack on time-stamp signing keys since time-stamp signing keys can also sign certificates. 2. It couples the primary TSA service (making timestamps) with a CA service (making certificates). I'm not sure that the intention is for TSAs to always be CAs or vice versa. If CAs and TSAs will be operated, managed and owned seperately then it is good that their services are not too coupled or intertwined. Also, if TSAs will be subject to formal evaluation "torture" then the less services and complications they include the less the torture will be. Both uses of the private key, time-stamp signing and certificate signing, will need to be evaluated. Regards, Simon. From owner-ietf-pkix@imc.org Wed Jun 21 23:07:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18786 for ; Wed, 21 Jun 2000 23:07:28 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA15331; Wed, 21 Jun 2000 20:04:07 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 20:04:04 -0700 Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA15297 for ; Wed, 21 Jun 2000 20:04:03 -0700 (PDT) Received: from rhousley_laptop.spyrus.com (dial02.spyrus.com [207.212.34.122]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id UAA24174; Wed, 21 Jun 2000 20:03:31 -0700 (PDT) Message-Id: <4.2.0.58.20000621224526.00a71100@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 21 Jun 2000 22:48:08 -0400 To: FRousseau@chrysalis-its.com From: Russ Housley Subject: RE: certification for pki Cc: ghilborn@csc.com, jean.med@arabtrust.com, ietf-pkix@imc.org In-Reply-To: <918C70B01822D411A87400B0D0204DFF04C039@panda.chrysalis-its .com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Please take a look at the protection profiles being proposed by SPYRUS.  You can find them at http://www.spyrus.com/documents/cims.  We have released the Level 3 profile to ANSI X9 as a strawman for a financial industry protection profile.

Russ

At 12:09 PM 06/21/2000 -0400, FRousseau@chrysalis-its.com wrote:

Gene,

However, the major drawback with the Certificate Issuing and Management Component (CIMC) Protection Profile (PP) sponsored/created by the (US) National Institute of Science and Technology (NIST) is that the current version still specifies about 25 new security functional requirements (SFRs) that are NOT included in the Common Criteria (CC)/ISO 15408 instead of using the refinement and/or the iteration operations on existing CC security functional requirements.

In addition, all these additional security functional requirements from the NIST CIMC PP would probably not be recognised through the mutual recognition arrangement (MRA).

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: ghilborn@csc.com [mailto:ghilborn@csc.com]
Sent: Wednesday, June 21, 2000 10:23 AM
To: ietf-pkix@imc.org
Cc: jean.med@arabtrust.com
Subject: Re: certification for pki

One internationally recognized avenue is an evaluation under the Common
Criteria/ISO 15408.  Such an evaluation up to EAL4 is automatically recognized
by the (currently) nine mutual recognition arrangement countries.  Two current
problems are (1) that the CC itself does not contain a crypto module evaluation
standard such as FIPS 140-1/2, and (2) there is not yet a consensus and
evaluated Protection Profile for PKI components.   Some product vendors have
undertanen evaluations without PPs.  FIPS 140-1 is officially US/Canada, but
also widely recognized.

There is a maturing draft PP sponsored/created by the (US) National Institute of
Science and Technology,  which offers a selection of four levels of assurance
for certificate issuing and management components (CIMC).  See
http://csrc.nist.gov/pki/documents/.  For specific crypto module validation, it
references FIPS 140-1, but also includes all the other system security funcional
and assurance requirements appropriate to CIMC.

-Gene Hilborn

jean.med@arabtrust.com on 06/21/2000 06:00:06 AM

To:   ietf-pkix@imc.org
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  certification for pki

Hi,

Is there any internationally accredited certification for PKI

Jean
From owner-ietf-pkix@imc.org Thu Jun 22 00:17:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19936 for ; Thu, 22 Jun 2000 00:17:48 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA19238; Wed, 21 Jun 2000 21:07:29 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 21 Jun 2000 21:07:19 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA19200 for ; Wed, 21 Jun 2000 21:07:16 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA00889; Thu, 22 Jun 2000 14:13:04 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Jun 2000 14:06:29 +1000 Message-ID: From: Michael Zolotarev To: Simon McMahon , Jean-Marc Desperrier , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 14:06:28 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > > Michael wrote: > > > > If we forget for a moment about what the draft says > (please): what is > wrong > > with using a TSA key for signing 'something that is not a > time-stamp'? I > do > > not see anything criminal about that. Especially if the case is > well-defined > > and justified. > > > The draft obviously said it for a reason but to answer "what is wrong > with using a TSA key for signing 'something that is not a > time-stamp'?" > > 1. Its good security policy to restrict usage of > particularly sensitive > keys. > Use a TSA key for signing timestamps and for signing a TSA's own certificate is still within well-defined and restricted scope of use. The use of the key IS STILL WELL RESTRICTED. > The ultimate restriction is one exclusive use which is the > state of the > draft now. > You should show a very good reason to weaken that Self-signed TSA cert is a very good reason to me. > or show that the new usage has negligable impact. If you do this then an attack on > certificate signing keys will be useful as an attack on time-stamp > signing keys since time-stamp signing keys can also sign certificates. Do you mean that using a particular key to produce N signatures (timestamps) as compared to producing N+1 signatures (timestamps and a self-signed TSA cert) makes an attack any easier? I doubt it. > > 2. It couples the primary TSA service (making timestamps) with a CA > service (making certificates). > Do not agree here. Issuing a self-signed cert by no means makes an entity a CA. TSA does not become a CA, and it does not need to become one, simply for the fact that it has a self-signed cert. No no no :). > I'm not sure that the intention is for TSAs to always be CAs > or vice versa. > If CAs and TSAs will be operated, managed and owned seperately then it > is good that their services are not too coupled or intertwined. > > Also, if TSAs will be subject to formal evaluation "torture" > then the less > services and complications they include the less the torture > will be. Both > uses of the private key, time-stamp signing and certificate > signing, will > need to be evaluated. Ok, lets go for it: 1. Self-signed TSA cert. You have to evaluate your secure signing environment. Which is the same for generating timestamps and for generation a self-signed cert. 2. Not self-signed TSA cert. You have to evaluate your secure timestamp signing environment AND whatever mechanism you (or whoever else) employed to issue TSA a certificate. What is easier? (1) is sure looks simpler to me. Regards Michael > > > Regards, > > Simon. > > From owner-ietf-pkix@imc.org Thu Jun 22 03:08:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22321 for ; Thu, 22 Jun 2000 03:08:39 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA25442; Thu, 22 Jun 2000 00:04:44 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 00:04:37 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA25409 for ; Thu, 22 Jun 2000 00:04:35 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id RAA02379; Thu, 22 Jun 2000 17:10:22 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Jun 2000 17:03:47 +1000 Message-ID: From: Michael Zolotarev To: Simon McMahon , Jean-Marc Desperrier , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 17:03:46 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe And yet another argument (as shyly suggested by Stephen Farrell) - in order to get a TSA certificate from a CA, you may have to (as an obedient PKIX follower) sign the request (P-O-P stuff). Which means that the key, which is otherwise 100% pure timestamping, will be still used for non-timestamping purpose. We are not going to prohibit the mechanism of POP, are we? M > -----Original Message----- > From: Simon McMahon [mailto:simon@onthenet.com.au] > Sent: Thursday, June 22, 2000 12:51 PM > To: Michael Zolotarev; Jean-Marc Desperrier; ietf-pkix@imc.org > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > > > Michael wrote: > > > > If we forget for a moment about what the draft says > (please): what is > wrong > > with using a TSA key for signing 'something that is not a > time-stamp'? I > do > > not see anything criminal about that. Especially if the case is > well-defined > > and justified. > > > The draft obviously said it for a reason but to answer "what is wrong > with using a TSA key for signing 'something that is not a > time-stamp'?" > > 1. Its good security policy to restrict usage of > particularly sensitive > keys. > > The ultimate restriction is one exclusive use which is the > state of the > draft now. > You should show a very good reason to weaken that or show that the new > usage has negligable impact. If you do this then an attack on > certificate > signing keys will be useful as an attack on time-stamp > signing keys since > time-stamp signing keys can also sign certificates. > > 2. It couples the primary TSA service (making timestamps) with a CA > service (making certificates). > > I'm not sure that the intention is for TSAs to always be CAs > or vice versa. > If CAs and TSAs will be operated, managed and owned seperately then it > is good that their services are not too coupled or intertwined. > > Also, if TSAs will be subject to formal evaluation "torture" > then the less > services and complications they include the less the torture > will be. Both > uses of the private key, time-stamp signing and certificate > signing, will > need to be evaluated. > > > Regards, > > Simon. > > From owner-ietf-pkix@imc.org Thu Jun 22 04:23:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23335 for ; Thu, 22 Jun 2000 04:23:36 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA28412; Thu, 22 Jun 2000 01:20:25 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 01:20:23 -0700 Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA28380 for ; Thu, 22 Jun 2000 01:20:20 -0700 (PDT) Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id SAA88914; Thu, 22 Jun 2000 18:20:07 +1000 (EST) Message-ID: <01c901bfdc23$de0ad080$8802a8c0@eracom.com.au> From: "Simon McMahon" To: "Michael Zolotarev" , "Jean-Marc Desperrier" , References: Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 18:28:08 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > > Ok, lets go for it: > 1. Self-signed TSA cert. You have to evaluate your secure signing > environment. Which is the same for generating timestamps and for generation > a self-signed cert. > 2. Not self-signed TSA cert. You have to evaluate your secure timestamp > signing environment AND whatever mechanism you (or whoever else) employed to > issue TSA a certificate. > In both cases you will have to evaluate. a. Key generation - Output public key and private key pair. b. Secure private key storage. c. Public key distribution. d. Private key usage - input validation & signing. a & b are the same for TSA types 1 & 2. c1 - Public key goes into a cert encoding and is signed by the private key (uses d1). d1 - Sign timestamps, and sign encoded cert (from c1). c2 - Public key goes to evaluated CA for cert encoding and distribution. d2 - Sign timestamps. I would suspect that type 1 TSAs will also have to support having their public key certified by a CA which means that c2 applies to them also. A type 2 TSA would not need c1. just received : > And yet another argument (as shyly suggested by Stephen Farrell) - in order > to get a TSA certificate from a CA, you may have to (as an obedient PKIX > follower) sign the request (P-O-P stuff). Which means that the key, which is > otherwise 100% pure timestamping, will be still used for non-timestamping > purpose. We are not going to prohibit the mechanism of POP, are we? You are right. That means c2 includes generating a cert request and d2 includes self-signing the encoded cert request. The only difference now is that type 2 TSAs includes self-signed certificate request encodings and type 1 includes them and self-signed certificate encodings also. For an evaluated TSA I would push the self-signed cert-request (or cert) into the Key generation operation. That way signing the cert-request could not be classed as a form of run-time usage of the key and should not conflict with the intended exclusive usage (signing timestamps) of the key. If thats what you've been saying all along then I apolagise. You would not be able to re-generate another self-signed cert later on though. Does that matter ? BTW The steps now become : a. Key generation - output self-signed cert-request (or cert) and private key pair. b. Secure private key storage. c. Cert-request (or cert) distribution. d. Private key usage - input validation & signing. Regards, Simon. From owner-ietf-pkix@imc.org Thu Jun 22 04:31:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23489 for ; Thu, 22 Jun 2000 04:31:47 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA27708; Thu, 22 Jun 2000 01:11:02 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 01:10:54 -0700 Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA27675 for ; Thu, 22 Jun 2000 01:10:52 -0700 (PDT) Received: from certplus.com (nt4_jmd.certplus.com [192.168.1.17]) by certplus.com (8.8.7/8.8.7) with ESMTP id IAA04967 for ; Thu, 22 Jun 2000 08:41:50 +0200 Message-ID: <3951CA50.CA0992FE@certplus.com> Date: Thu, 22 Jun 2000 10:12:00 +0200 From: Jean-Marc Desperrier Organization: Certplus X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Michael Zolotarev wrote: > > That there has been at least one point of time where your TSA hardware > > crypto module has been able to sign something that is not a > > time-stamp. > > If we forget for a moment about what the draft says (please): what is wrong > with using a TSA key for signing 'something that is not a time-stamp'? I do > not see anything criminal about that. Especially if the case is well-defined > and justified. Maybe I did not express myself clearly enough. I'm not convinced it's bad to issue self-signed TSA certificate. I'm just saying it might not be a great idea. I sure did not analyse the implication of that in every detail, and especially the inconvenience not being able to issue self-signed certificate. From what you say, it looks like it should be allowed, and then up to every TSA operator to design his own policy with regard to using this possibility or not. From owner-ietf-pkix@imc.org Thu Jun 22 04:54:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23722 for ; Thu, 22 Jun 2000 04:54:45 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA01185; Thu, 22 Jun 2000 01:53:28 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 01:53:24 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA01152 for ; Thu, 22 Jun 2000 01:53:22 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id SAA03131; Thu, 22 Jun 2000 18:59:22 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Jun 2000 18:52:48 +1000 Message-ID: From: Michael Zolotarev To: Simon McMahon , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 18:52:47 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > For an evaluated TSA I would push the self-signed > cert-request (or cert) > into the Key generation operation. That way signing the > cert-request could > not be classed as a form of run-time usage of the key and should not > conflict with the intended exclusive usage (signing > timestamps) of the key. > If thats what you've been saying all along then I apolagise. > You would not > be able to re-generate another self-signed cert later on > though. Does that > matter ? Well, that would probably matter when a current certificate expires and you need to issue another certificate. Do you mean that logical(!) definition of Key Generation operation can not embrace re-issuing a certificate with the same value of the key? Why not? I think we'd be able to defend it for the evaluation. It is not part of the run-time usage (a tick box here), the key was not compromised (a tick box here), a new certificate is issued following the same (already evaluated) procedure as the very first one (a tick box here). Do not think it would be a problem, in general. > > BTW The steps now become : > > a. Key generation - output self-signed cert-request (or > cert) and private > key pair. > b. Secure private key storage. > c. Cert-request (or cert) distribution. > d. Private key usage - input validation & signing. > > Regards, > > Simon. > > From owner-ietf-pkix@imc.org Thu Jun 22 05:38:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24283 for ; Thu, 22 Jun 2000 05:38:03 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA02315; Thu, 22 Jun 2000 02:24:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 02:23:11 -0700 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA02256 for ; Thu, 22 Jun 2000 02:23:10 -0700 (PDT) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AB0A28A0052; Thu, 22 Jun 2000 11:23:22 +0200 From: "Peter Lipp" To: Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 11:24:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3951CA50.CA0992FE@certplus.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > I'm not convinced it's bad to issue self-signed TSA certificate. > I'm just saying it might not be a great idea. Agree. I don't see the big advantage. For one, if I want to trust a CA I need to go through whatever steps are appropriate. If the CA offers/recommends/uses a TSA, it can give me a certificate for the TSA and - having already decided to trust the CA - it is simple to verify the certificate and decide to trust the TSA too. So what does the self-signed TSA cert buy me besides the need to go through the trust decisions again? Now consider revocation - do you really suggest to set up a separate revocation-scheme for the TSA? I simply don't see any advantage here... Peter From owner-ietf-pkix@imc.org Thu Jun 22 07:51:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26261 for ; Thu, 22 Jun 2000 07:50:54 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA09065; Thu, 22 Jun 2000 04:45:20 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 04:45:12 -0700 Received: from stonewall.baltimore.com (mailhost.baltimore.com [195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA09034 for ; Thu, 22 Jun 2000 04:45:09 -0700 (PDT) Message-ID: <001301bfdc3e$b4d31a40$123c70c2@baltimore.com> Reply-To: "Farrukh Ahmad" From: "Farrukh Ahmad" To: , References: <96160607224858@baltimore.com> Subject: Re: certification for pki Date: Thu, 22 Jun 2000 12:34:54 +0100 Organization: Baltimore Technology (UK) Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit FYI, under the CEN/ETSI standards work currently being carried out for use with the European Directive on Digital Signatures, trustworthy system standards are being written which include in their annex CC PPs for CAs and RAs. These may be used by a Certification Service Provider (CSP) issuing Qualified Certificates for compliance assessment. A public draft will be available sometime in September and a complete standard by the end of the year. Regards Farrukh Ahmad ----- Original Message ----- From: To: Sent: Thursday, June 22, 2000 5:47 AM Subject: Re: certification for pki > ghilborn@csc.com writes: > > >It is not a choice of CC vs. FIPS. The FIPS 140-1 testing pertains > narrowly > >to crypto modules. The CC evaluation/"torture" process is about the > >system/components for certificate issuance and management meeting its > security > >specification (security target and claimed PP(s)). > > Oh, so the interest is in certifying the PKI process rather than > machinery > which makes it possible? In that case there's a whole host of standards > to > choose from, from ISO there's ISO 15782-1, Banking - Certificate > Management, > from ANSI theres X9.57 Certificate Management and ANSI X9.79, PKI > Practices and > Framework, and from vendors there's both VISA and MC's SET PKI > requirements > (which, while in some cases SET-specific), are well thought out. Would > any of > those be usable as a PP? > > Peter. > From owner-ietf-pkix@imc.org Thu Jun 22 08:28:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28116 for ; Thu, 22 Jun 2000 08:28:41 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA10291; Thu, 22 Jun 2000 05:26:03 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 05:25:59 -0700 Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10258 for ; Thu, 22 Jun 2000 05:25:58 -0700 (PDT) Received: from ctex01.us.cybertrust.com (ctex01.us.cybertrust.com [192.233.30.4]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id IAA27900; Thu, 22 Jun 2000 08:25:47 -0400 (EDT) Received: by ctex01.us.cybertrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 08:24:55 -0400 Message-ID: From: "Meggison, Tim" To: "'Simon McMahon'" , Michael Zolotarev , Jean-Marc Desperrier , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 08:24:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I believe the key word in Simon's email is policy. What is good policy for one situation is overkill for another. I suggest the spec should be limited to technical and interop requirements, and leave policy decisions to actual implementations. > -----Original Message----- > From: Simon McMahon [mailto:simon@onthenet.com.au] > Sent: Wednesday, June 21, 2000 10:51 PM > To: Michael Zolotarev; Jean-Marc Desperrier; ietf-pkix@imc.org > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > > > Michael wrote: > > > > If we forget for a moment about what the draft says > (please): what is > wrong > > with using a TSA key for signing 'something that is not a > time-stamp'? I > do > > not see anything criminal about that. Especially if the case is > well-defined > > and justified. > > > The draft obviously said it for a reason but to answer "what is wrong > with using a TSA key for signing 'something that is not a > time-stamp'?" > > 1. Its good security policy to restrict usage of > particularly sensitive > keys. > > The ultimate restriction is one exclusive use which is the > state of the > draft now. > You should show a very good reason to weaken that or show that the new > usage has negligable impact. If you do this then an attack on > certificate > signing keys will be useful as an attack on time-stamp > signing keys since > time-stamp signing keys can also sign certificates. > > 2. It couples the primary TSA service (making timestamps) with a CA > service (making certificates). > > I'm not sure that the intention is for TSAs to always be CAs > or vice versa. > If CAs and TSAs will be operated, managed and owned seperately then it > is good that their services are not too coupled or intertwined. > > Also, if TSAs will be subject to formal evaluation "torture" > then the less > services and complications they include the less the torture > will be. Both > uses of the private key, time-stamp signing and certificate > signing, will > need to be evaluated. > > > Regards, > > Simon. > > From owner-ietf-pkix@imc.org Thu Jun 22 09:53:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05903 for ; Thu, 22 Jun 2000 09:53:04 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA12872; Thu, 22 Jun 2000 06:50:50 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 06:50:39 -0700 Received: from mail-fwd.verio-web.com ([161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA12841 for ; Thu, 22 Jun 2000 06:50:38 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 08234539; Thu, 22 Jun 2000 09:50:16 -0400 (EDT) Sender: rsalz@ns.secondary.com Message-ID: <3952194B.84989CDE@caveosystems.com> Date: Thu, 22 Jun 2000 09:48:59 -0400 From: Rich Salz Organization: Caveo Systems, LLC X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Peter Lipp CC: ietf-pkix@imc.org Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > So what does the self-signed > TSA cert buy me besides the need to go through the trust decisions again? You actually have *less* to trust if you have a self-signed TSA. Trusting the CA means you trust all it signs. Trusting the TSA means just and only that. /r$ From owner-ietf-pkix@imc.org Thu Jun 22 10:11:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06513 for ; Thu, 22 Jun 2000 10:11:35 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA13249; Thu, 22 Jun 2000 07:03:27 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 07:03:25 -0700 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13219 for ; Thu, 22 Jun 2000 07:03:24 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 10:04:25 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C045@panda.chrysalis-its.com> To: ietf-pkix@imc.org Subject: RE: certification for pki Date: Thu, 22 Jun 2000 10:04:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDC52.C59A3F34" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDC52.C59A3F34 Content-Type: text/plain; charset="iso-8859-1" Russ, Thanks for the link. I had a quick look at them and I have noted that contrary to the NIST CIMC PP, which as indicated in my previous Email created new security functional requirements even for key management, the SPYRUS CIMS PPs contain no security functional requirements whatsoever about cryptographic functionality. Each SPYRUS's PP contains the same statement, "I haven't got a clue" when addressing Common Criteria requirement statements about cryptographic support. Does SPYRUS plan to add some security functional requirements from the Class FCS on cryptographic support in a future version of its PPs? Reagards, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Wednesday, June 21, 2000 10:48 PM To: FRousseau@chrysalis-its.com Cc: ghilborn@csc.com; jean.med@arabtrust.com; ietf-pkix@imc.org Subject: RE: certification for pki Please take a look at the protection profiles being proposed by SPYRUS. You can find them at http://www.spyrus.com/documents/cims. We have released the Level 3 profile to ANSI X9 as a strawman for a financial industry protection profile. Russ [snip] ------_=_NextPart_001_01BFDC52.C59A3F34 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: certification for pki

Russ,

Thanks for the link. I had a quick look at them and I = have noted that contrary to the NIST CIMC PP, which as indicated in my = previous Email created new security functional requirements even for = key management, the SPYRUS CIMS PPs contain no security functional = requirements whatsoever about cryptographic functionality. Each = SPYRUS's PP contains the same statement, "I haven't got a = clue" when addressing Common Criteria requirement statements about = cryptographic support. Does SPYRUS plan to add some security functional = requirements from the Class FCS on cryptographic support in a future = version of its PPs?

Reagards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078


-----Original Message-----
From: Russ Housley [mailto:housley@spyrus.com]=
Sent: Wednesday, June 21, 2000 10:48 PM
To: FRousseau@chrysalis-its.com
Cc: ghilborn@csc.com; jean.med@arabtrust.com; = ietf-pkix@imc.org
Subject: RE: certification for pki


Please take a look at the protection profiles being = proposed by SPYRUS.  You can find them at http://www.spyrus.com/documents/cims.  We = have released the Level 3 profile to ANSI X9 as a strawman for a = financial industry protection profile.

Russ

[snip]

------_=_NextPart_001_01BFDC52.C59A3F34-- From owner-ietf-pkix@imc.org Thu Jun 22 10:22:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06679 for ; Thu, 22 Jun 2000 10:22:47 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA13709; Thu, 22 Jun 2000 07:20:19 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 07:20:17 -0700 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13679 for ; Thu, 22 Jun 2000 07:20:17 -0700 (PDT) Received: from [207.215.85.136] by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWK00FHP7TIQQ@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 22 Jun 2000 07:20:07 -0700 (PDT) Date: Thu, 22 Jun 2000 07:20:44 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <3952194B.84989CDE@caveosystems.com> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Rich Salz wrote: >> So what does the self-signed >> TSA cert buy me besides the need to go through the trust decisions again? > > You actually have *less* to trust if you have a self-signed TSA. Trusting > the CA means you trust all it signs. Trusting the TSA means just and only > that. I'm not sure I understand your statement of having "*less* to trust". To trust a self-signed certificate (no matter if it is from a CA or TSA), you have to have an out-of-band mechanism to verify that the self-signed certificate is valid. One of the nice features of a hierarchical PKI is that I can limit the number of times I need the out-of-band mechanisms to verify self-signed certificates. If I don't want to trust the self-signed certificate of a CA that signs a TSA, then I can use the out-of-band mechanism to verify the TSA's certificate (that was signed by a CA) and treat it as an "anchor certificate". My definition of an anchor certificate is a certificate I implicitly trust because I have used an out-of-band mechanism to verify it. When I'm validating the certificate chain, I stop whenever I reach an anchor certificate (whether or not it is self-signed). Regards, Aram Perez From owner-ietf-pkix@imc.org Thu Jun 22 10:49:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07123 for ; Thu, 22 Jun 2000 10:49:56 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA14346; Thu, 22 Jun 2000 07:46:19 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 07:46:16 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14304 for ; Thu, 22 Jun 2000 07:46:15 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA29576; Thu, 22 Jun 2000 10:46:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3952194B.84989CDE@caveosystems.com> References: <3952194B.84989CDE@caveosystems.com> Date: Thu, 22 Jun 2000 10:39:16 -0400 To: Rich Salz From: Stephen Kent Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Folks, I support Denis's original restriction on the uses of a TSA private key. It is desirable to constrain the use of a private key to avoid possible errors in its use. It seems that we have gone down a thread that focuses on certificates for a TSA, more than on the original key usage restriction. I've always asserted that self-signed certs are just a syntactic convenience, not a generally useful way of ensuring security for transmitted public keys. If we agree on that point, then I don't see a lot of reason to push for self-signed TSA certs. A TSA is not a CA. Even if the same organization happens to operate both a CA function and a TSA function, it seems appropriate to separate these functions. That's part of why we have the proposed constraint for using the TSA private key only for signing TSA responses. It was suggested that this is not consistent with the use of POP. True, but only in so far as the POP in question is the one defined in our automated registration protocols. Thus is not the only game in town, and for a TSA it is reasonable to anticipate other mechanisms that provide POP, but not via those protocols. So, I don't think that the POP argument is a good basis for rejecting the key usage restriction. The "less to trust" argument that Michael makes does have some merit, but as Aram points out, a self-signed cert required some integrity/authenticity secure, OOB means for its delivery, which is why we try to minimize the use of such certs. It seems hard enough to do this for CAs, without adding TSAs to the list. Let's assume that TSAs are certified like other entities, by CAs, and work from there. Steve From owner-ietf-pkix@imc.org Thu Jun 22 11:59:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08985 for ; Thu, 22 Jun 2000 11:59:44 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA17526; Thu, 22 Jun 2000 08:58:28 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 08:58:16 -0700 Received: from mail-fwd.verio-web.com ([161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA17486 for ; Thu, 22 Jun 2000 08:58:16 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 08300882; Thu, 22 Jun 2000 11:58:17 -0400 (EDT) Sender: rsalz@ns.secondary.com Message-ID: <395234B0.D4546882@caveosystems.com> Date: Thu, 22 Jun 2000 11:45:52 -0400 From: Rich Salz Organization: Caveo Systems, LLC X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Aram Perez CC: PKIX Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > I'm not sure I understand your statement of having "*less* to trust". Sorry, poorly worded. If I trust the CA that certifies a TSA, then aren't I (by default, and certainly by philosophy) trusting EVERY certificate that CA issues? Why should I have to? /r$ From owner-ietf-pkix@imc.org Thu Jun 22 13:08:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10521 for ; Thu, 22 Jun 2000 13:08:03 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA22441; Thu, 22 Jun 2000 10:05:46 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 10:05:36 -0700 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22410 for ; Thu, 22 Jun 2000 10:05:35 -0700 (PDT) Received: from [207.215.85.136] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWK00F0CFFAAC@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 22 Jun 2000 10:04:23 -0700 (PDT) Date: Thu, 22 Jun 2000 10:05:12 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Stephen Kent wrote: > Folks, > > I support Denis's original restriction on the uses of a TSA private > key. It is desirable to constrain the use of a private key to avoid > possible errors in its use. It seems that we have gone down a thread > that focuses on certificates for a TSA, more than on the original key > usage restriction. > > I've always asserted that self-signed certs are just a syntactic > convenience, not a generally useful way of ensuring security for > transmitted public keys. If we agree on that point, then I don't see > a lot of reason to push for self-signed TSA certs. A TSA is not a > CA. Even if the same organization happens to operate both a CA > function and a TSA function, it seems appropriate to separate these > functions. That's part of why we have the proposed constraint for > using the TSA private key only for signing TSA responses. It was > suggested that this is not consistent with the use of POP. True, but > only in so far as the POP in question is the one defined in our > automated registration protocols. Thus is not the only game in town, > and for a TSA it is reasonable to anticipate other mechanisms that > provide POP, but not via those protocols. So, I don't think that the > POP argument is a good basis for rejecting the key usage restriction. > > The "less to trust" argument that Michael makes does have some merit, > but as Aram points out, a self-signed cert required some > integrity/authenticity secure, OOB means for its delivery, which is > why we try to minimize the use of such certs. It seems hard enough > to do this for CAs, without adding TSAs to the list. Let's assume > that TSAs are certified like other entities, by CAs, and work from > there. Well put Steve, I fully support this position. Regards, Aram Perez From owner-ietf-pkix@imc.org Thu Jun 22 13:14:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10753 for ; Thu, 22 Jun 2000 13:14:35 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA22791; Thu, 22 Jun 2000 10:13:22 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 10:13:20 -0700 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22760 for ; Thu, 22 Jun 2000 10:13:19 -0700 (PDT) Received: from [207.215.85.136] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWK00CM5FLZ9R@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 22 Jun 2000 10:08:23 -0700 (PDT) Date: Thu, 22 Jun 2000 10:09:12 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <395234B0.D4546882@caveosystems.com> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Rich Salz wrote: >> I'm not sure I understand your statement of having "*less* to trust". > > Sorry, poorly worded. > > If I trust the CA that certifies a TSA, then aren't I (by default, and > certainly by philosophy) trusting EVERY certificate that CA issues? > Why should I have to? You shouldn't have to, although this is the model that most public CAs seem to push and/or encourage. As I mentioned, a possible solution is the the use of "anchor certificates". Regards, Aram Perez From owner-ietf-pkix@imc.org Thu Jun 22 13:18:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10843 for ; Thu, 22 Jun 2000 13:18:17 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA22971; Thu, 22 Jun 2000 10:15:53 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 10:15:52 -0700 Received: from stonewall.baltimore.com (mailhost.baltimore.com [195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA22941 for ; Thu, 22 Jun 2000 10:15:49 -0700 (PDT) Message-ID: <61922E6DA745D311A42000508B2CFD14B96779@baltimore.com> From: Paul Halliden To: "'Paul Koning'" , seidel@timeproof.de Cc: FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt Date: Thu, 22 Jun 2000 18:16:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe There were two potential issues with MD5. The first one was an indication that, at the time MD4 was "broken", MD5 was expected to fall to a similar attack "in the near future". That has not happened so far. We do not know if that is because the task was too hard or if it was simply that no-one has got round to trying. But it was the reason that many stopped using MD5 at that time. The second potential issue concerns the size of an MD5 hash, which is shorter than an SHA-1 hash. If an end entity is able to create two messages that have the same value of hash, he can submit the hash to the TSA and then subsequently claim that either of the messages existed. When challenged, the end entity presents whichever version of the message best suits his argument - an adjudicator would not be able to tell which was the genuine one. Whilst this task is far from trivial for a 128-bit hash such as MD5, I believe it is the same order of magnitude as finding a 64-bit symmetric key by exhaustive search. (IANAC - so any cryptographer / mathematician please feel free to correct me). This potential attack is, IMHO, more significant for a TSA where one entity chooses the message and generates the hash and a second entity signs it (as part of the timestamp). Regards Paul Halliden >-----Original Message----- >From: Paul Koning [mailto:pkoning@xedia.com] >Sent: 19 June 2000 16:00 >To: seidel@timeproof.de >Cc: FRousseau@chrysalis-its.com; Denis.Pinkas@bull.net; >ietf-pkix@imc.org >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt > > >>>>>> "Joerg" == Joerg Seidel writes: > > Joerg> Comments inline. > >> TSA implementations MUST support SHA-1. TSA implementations > >> SHOULD support MD5. > > Joerg> I think there are good reasons not to use MD5 in time > Joerg> stamps. They should use a strong hash function in order to > Joerg> achive long validity periods. MD5 is likely to be unsafe (=not > Joerg> collision free) soon and is already discuraged by german > Joerg> authorities. > > Joerg> IF we add a section about algorithms, it should maybe read: > Joerg> "TSA implementations MUST support SHA-1. TSA implementations > Joerg> SHOULD NOT support MD5.". But I think such a section is not > Joerg> very necessary. > >IANAC, but from what I understand the currently known attacks on MD5 >are nowhere near strong enough to justify that. > >I don't have a problem with the current text (SHA-1 required, MD5 >recommended). I do have a problem with text that implies that MD5 is >bad, because I don't know of data that supports such an assertion. > >Also, it doesn't seem like a good idea for the timestamp spec to give >very different signals from the other security specs. If there really >is good reason to say these kinds of things about MD5, let's have them >identified. (German authorities are not a good reason. Cryptanalysis >that shows weaknesses of interesting size would be.) If the issues >are real, changes to MD5 text should be applied across the board. > > paul > From owner-ietf-pkix@imc.org Thu Jun 22 13:45:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11486 for ; Thu, 22 Jun 2000 13:45:52 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA23555; Thu, 22 Jun 2000 10:44:34 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 10:44:32 -0700 Received: from windoze.tenebras.com (windoze.tenebras.com [216.15.43.196]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23525 for ; Thu, 22 Jun 2000 10:44:31 -0700 (PDT) Received: from dnai.com (localhost [127.0.0.1]) by windoze.tenebras.com (8.9.3/8.9.3) with ESMTP id KAA24292; Thu, 22 Jun 2000 10:43:19 -0700 (PDT) (envelope-from kudzu@dnai.com) Sender: kudzu@windoze.tenebras.com Message-ID: <39525036.A930020E@dnai.com> Date: Thu, 22 Jun 2000 10:43:18 -0700 From: Michael Sierchio X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: fr, en MIME-Version: 1.0 To: Paul Halliden CC: "'Paul Koning'" , seidel@timeproof.de, FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <61922E6DA745D311A42000508B2CFD14B96779@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Paul Halliden wrote: > > There were two potential issues with MD5. A potential issue is not an issue... > ...If an end entity is able to create two messages > that have the same value of hash, he can submit the hash to the TSA and then > subsequently claim that either of the messages existed. > ...(IANAC - so any cryptographer / mathematician please feel > free to correct me). The difficulty of finding any two messages that have the same MD5 hash is enormous. But consider that if both such messages are to be meaningful it is quite another order of difficulty (greater, if it isn't obvious). There is still no mechanism for creating a message which has a given MD5 hash value... From owner-ietf-pkix@imc.org Thu Jun 22 14:19:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12196 for ; Thu, 22 Jun 2000 14:19:52 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA24323; Thu, 22 Jun 2000 11:13:27 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 11:13:19 -0700 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24292 for ; Thu, 22 Jun 2000 11:13:13 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5MI59g18905 for ; Thu, 22 Jun 2000 11:05:10 -0700 (PDT) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FWKILJ00.CG3; Thu, 22 Jun 2000 11:12:55 -0700 Message-ID: <39525726.5D23F3CC@netscape.com> Date: Thu, 22 Jun 2000 11:12:54 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Halliden CC: "'Paul Koning'" , seidel@timeproof.de, FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <61922E6DA745D311A42000508B2CFD14B96779@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Paul, Addressing the first point in your message (a client submitting a "cooked" MD5 hash for timestamping), there are two points to make: 1. Finding collisions in MD5 is still hard, and finding meaningful ones much harder. 2. It is not the concern of the TSA whether the client has chosen a form of message imprint that will hold up under a challenge. The TSA's function is to associate a timestamp with the message imprint, no more. Whether that message imprint can be used later to convince a third party that a particular document was reference is more important to the client. The client should choose an imprint algorithm that will meet their requirements. Addressing the second point (getting the TSA to generate a colliding time stamp token): 1. Again, it is difficult to find meaningful collisions. 2. The TSA is concern in this case, since a collision could result it a token that indicates a different timestamp (probably an earlier one). 3. The TSA should choose a strong signature algorithm that will provide the appropriate level of assurance for the required time period. I suspect that many TSAs will choose a signature based on SHA for this reason. They will also choose key lengths depending on the desired security level. 4. Since a large part of the timestamp token is fixed or guessable, t is probably worth including a "nonce" value in the generated signature to make it difficult to force the TSA into generating a colliding signature. This value can easily be incorporated into the CMS SignedData object as a signed attribute. Terry Hayes Netscape Communications Corp. Paul Halliden wrote: > There were two potential issues with MD5. The first one was an indication > that, at the time MD4 was "broken", MD5 was expected to fall to a similar > attack "in the near future". That has not happened so far. We do not know > if that is because the task was too hard or if it was simply that no-one has > got round to trying. But it was the reason that many stopped using MD5 at > that time. > > The second potential issue concerns the size of an MD5 hash, which is > shorter than an SHA-1 hash. If an end entity is able to create two messages > that have the same value of hash, he can submit the hash to the TSA and then > subsequently claim that either of the messages existed. When challenged, the > end entity presents whichever version of the message best suits his argument > - an adjudicator would not be able to tell which was the genuine one. Whilst > this task is far from trivial for a 128-bit hash such as MD5, I believe it > is the same order of magnitude as finding a 64-bit symmetric key by > exhaustive search. (IANAC - so any cryptographer / mathematician please feel > free to correct me). > > This potential attack is, IMHO, more significant for a TSA where one entity > chooses the message and generates the hash and a second entity signs it (as > part of the timestamp). > > Regards > Paul Halliden > > >-----Original Message----- > >From: Paul Koning [mailto:pkoning@xedia.com] > >Sent: 19 June 2000 16:00 > >To: seidel@timeproof.de > >Cc: FRousseau@chrysalis-its.com; Denis.Pinkas@bull.net; > >ietf-pkix@imc.org > >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt > > > > > >>>>>> "Joerg" == Joerg Seidel writes: > > > > Joerg> Comments inline. > > >> TSA implementations MUST support SHA-1. TSA implementations > > >> SHOULD support MD5. > > > > Joerg> I think there are good reasons not to use MD5 in time > > Joerg> stamps. They should use a strong hash function in order to > > Joerg> achive long validity periods. MD5 is likely to be unsafe (=not > > Joerg> collision free) soon and is already discuraged by german > > Joerg> authorities. > > > > Joerg> IF we add a section about algorithms, it should maybe read: > > Joerg> "TSA implementations MUST support SHA-1. TSA implementations > > Joerg> SHOULD NOT support MD5.". But I think such a section is not > > Joerg> very necessary. > > > >IANAC, but from what I understand the currently known attacks on MD5 > >are nowhere near strong enough to justify that. > > > >I don't have a problem with the current text (SHA-1 required, MD5 > >recommended). I do have a problem with text that implies that MD5 is > >bad, because I don't know of data that supports such an assertion. > > > >Also, it doesn't seem like a good idea for the timestamp spec to give > >very different signals from the other security specs. If there really > >is good reason to say these kinds of things about MD5, let's have them > >identified. (German authorities are not a good reason. Cryptanalysis > >that shows weaknesses of interesting size would be.) If the issues > >are real, changes to MD5 text should be applied across the board. > > > > paul > > From owner-ietf-pkix@imc.org Thu Jun 22 15:43:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14150 for ; Thu, 22 Jun 2000 15:43:06 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA25740; Thu, 22 Jun 2000 12:36:39 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 12:36:32 -0700 Received: from stonewall.baltimore.com (mailhost.baltimore.com [195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA25708 for ; Thu, 22 Jun 2000 12:36:29 -0700 (PDT) Message-ID: <61922E6DA745D311A42000508B2CFD14B9677A@baltimore.com> From: Paul Halliden To: "'thayes@netscape.com'" Cc: "'Paul Koning'" , seidel@timeproof.de, FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt Date: Thu, 22 Jun 2000 20:36:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Terry, Michael I agree that finding "meaningful" collisions *can* be substantially harder than simply finding two arbitrary strings with the same hash. How much harder, depends on the application. For instance, if a strictly formatted message has provision for a 64-bit randomly allocated nonce, the task is no more difficult. The point is that, as security system designers, we should not make any assumptions about the message and it is therefore safest to assume that creating a set of meaningful messages is not significantly more difficult than creating un-meaningful ones. Ok, there are many cases where that will not be valid, but... Certainly, as Terry argues, collisions in the TSA's own process will always be a concern. Whether or not end entity collisions are a concern to the TSA is application dependent. As a minimum, collisions deliberately created by the end entity would be an embarrassment to the TSA and affect the perception of it in a public dispute. Again, I would argue that it is safest not to make assumptions about the application. As regards the possibility of actually mounting a "brute force" attack on MD5 today, I originally said that "this task is far from trivial". That is British understatement for "very difficult". As far as I am aware, the largest exhaustive search was for 56-bits in 1997 - and that required massive distributed processing. Searching for a collision would also require large amount of memory / storage (one has to store the variable part of 2^64 [meaningful] messages and their hash in order to have about 50% probability of having two identical hashes). So I do not expect to read of a successful brute force attack on MD5 this year - but I would not express great surprise if it happened. Regards Paul Halliden >-----Original Message----- >From: thayes@netscape.com [mailto:thayes@netscape.com] >Sent: 22 June 2000 19:13 >To: Paul Halliden >Cc: 'Paul Koning'; seidel@timeproof.de; FRousseau@chrysalis-its.com; >Denis.Pinkas@bull.net; ietf-pkix@imc.org >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt > > >Paul, > >Addressing the first point in your message (a client >submitting a "cooked" MD5 >hash for timestamping), there are two points to make: > >1. Finding collisions in MD5 is still hard, and finding >meaningful ones much >harder. >2. It is not the concern of the TSA whether the client has >chosen a form of >message imprint that will hold up under a challenge. The >TSA's function is to >associate a timestamp with the message imprint, no more. >Whether that message >imprint can be used later to convince a third party that a >particular document >was reference is more important to the client. The client >should choose an >imprint algorithm that will meet their requirements. > >Addressing the second point (getting the TSA to generate a >colliding time stamp >token): > >1. Again, it is difficult to find meaningful collisions. >2. The TSA is concern in this case, since a collision could >result it a token >that indicates a different timestamp (probably an earlier one). >3. The TSA should choose a strong signature algorithm that >will provide the >appropriate level of assurance for the required time period. >I suspect that >many TSAs will choose a signature based on SHA for this >reason. They will also >choose key lengths depending on the desired security level. >4. Since a large part of the timestamp token is fixed or >guessable, t is >probably worth including a "nonce" value in the generated >signature to make it >difficult to force the TSA into generating a colliding >signature. This value >can easily be incorporated into the CMS SignedData object as a >signed attribute. > >Terry Hayes >Netscape Communications Corp. > >Paul Halliden wrote: > >> There were two potential issues with MD5. The first one was >an indication >> that, at the time MD4 was "broken", MD5 was expected to fall >to a similar >> attack "in the near future". That has not happened so far. >We do not know >> if that is because the task was too hard or if it was simply >that no-one has >> got round to trying. But it was the reason that many >stopped using MD5 at >> that time. >> >> The second potential issue concerns the size of an MD5 hash, which is >> shorter than an SHA-1 hash. If an end entity is able to >create two messages >> that have the same value of hash, he can submit the hash to >the TSA and then >> subsequently claim that either of the messages existed. When >challenged, the >> end entity presents whichever version of the message best >suits his argument >> - an adjudicator would not be able to tell which was the >genuine one. Whilst >> this task is far from trivial for a 128-bit hash such as >MD5, I believe it >> is the same order of magnitude as finding a 64-bit symmetric key by >> exhaustive search. (IANAC - so any cryptographer / >mathematician please feel >> free to correct me). >> >> This potential attack is, IMHO, more significant for a TSA >where one entity >> chooses the message and generates the hash and a second >entity signs it (as >> part of the timestamp). >> >> Regards >> Paul Halliden >> >> >-----Original Message----- >> >From: Paul Koning [mailto:pkoning@xedia.com] >> >Sent: 19 June 2000 16:00 >> >To: seidel@timeproof.de >> >Cc: FRousseau@chrysalis-its.com; Denis.Pinkas@bull.net; >> >ietf-pkix@imc.org >> >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt >> > >> > >> >>>>>> "Joerg" == Joerg Seidel writes: >> > >> > Joerg> Comments inline. >> > >> TSA implementations MUST support SHA-1. TSA implementations >> > >> SHOULD support MD5. >> > >> > Joerg> I think there are good reasons not to use MD5 in time >> > Joerg> stamps. They should use a strong hash function in order to >> > Joerg> achive long validity periods. MD5 is likely to be >unsafe (=not >> > Joerg> collision free) soon and is already discuraged by german >> > Joerg> authorities. >> > >> > Joerg> IF we add a section about algorithms, it should maybe read: >> > Joerg> "TSA implementations MUST support SHA-1. TSA >implementations >> > Joerg> SHOULD NOT support MD5.". But I think such a section is not >> > Joerg> very necessary. >> > >> >IANAC, but from what I understand the currently known attacks on MD5 >> >are nowhere near strong enough to justify that. >> > >> >I don't have a problem with the current text (SHA-1 required, MD5 >> >recommended). I do have a problem with text that implies >that MD5 is >> >bad, because I don't know of data that supports such an assertion. >> > >> >Also, it doesn't seem like a good idea for the timestamp >spec to give >> >very different signals from the other security specs. If >there really >> >is good reason to say these kinds of things about MD5, >let's have them >> >identified. (German authorities are not a good reason. >Cryptanalysis >> >that shows weaknesses of interesting size would be.) If the issues >> >are real, changes to MD5 text should be applied across the board. >> > >> > paul >> > > From owner-ietf-pkix@imc.org Thu Jun 22 16:36:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15182 for ; Thu, 22 Jun 2000 16:36:17 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA26652; Thu, 22 Jun 2000 13:31:24 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 13:31:17 -0700 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26622 for ; Thu, 22 Jun 2000 13:31:17 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5MKQgX06011 for ; Thu, 22 Jun 2000 13:26:42 -0700 (PDT) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FWKOZP01.XI2; Thu, 22 Jun 2000 13:31:01 -0700 Message-ID: <39527784.1BC470B@netscape.com> Date: Thu, 22 Jun 2000 13:31:00 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Halliden CC: "'Paul Koning'" , seidel@timeproof.de, FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <61922E6DA745D311A42000508B2CFD14B9677A@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Paul Halliden wrote: > Certainly, as Terry argues, collisions in the TSA's own process will always > be a concern. Whether or not end entity collisions are a concern to the TSA > is application dependent. As a minimum, collisions deliberately created by > the end entity would be an embarrassment to the TSA and affect the > perception of it in a public dispute. Again, I would argue that it is > safest not to make assumptions about the application. Embarrassment to the TSA should result from failure to provide a correct and secure timestamp, not from the content that is being stamped. If you are worried about embarrassment, perhaps you should insist on seeing the entire message, rather than just an imprint. After all, the imprint may be referring to racist material, or plans for terrorist attacks. While I'll grant that the imprint algorithm used (and the appropriateness of the value given for that algorithm) are important for the functioning of the process, I don't see any need to have the TSA enforce restrictions on them at the time the timestamp is created. If the primary goal is achieved (correct and secure timestamping of the imprint), then a dispute resolution process can determine whether a reasonable imprint algorithm (for the time) was used. A TSA MAY choose enforce restrictions on the imprint, but the standard should not REQUIRE it. Terry Hayes From owner-ietf-pkix@imc.org Thu Jun 22 16:37:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15206 for ; Thu, 22 Jun 2000 16:37:46 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA26893; Thu, 22 Jun 2000 13:36:41 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 13:36:37 -0700 Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26863 for ; Thu, 22 Jun 2000 13:36:35 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id QAA29237 for ; Thu, 22 Jun 2000 16:28:36 -0400 (EDT) Message-Id: <200006222028.QAA29233@roadblock.missi.ncsc.mil> Date: Thu, 22 Jun 2000 16:34:01 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: OgKp0bhJ2vWpkO0jtilCTg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > From: Michael Zolotarev > > 1. Self-signed TSA cert. You have to evaluate your secure signing > environment. Which is the same for generating timestamps and for generation > a self-signed cert. What security-relevant information are you expecting clients to derive from validating the signature of a self-signed cert? Do you expect clients to have trusted storage which could hold a bare TSA public key, but which could not hold the entire self-signed TSA cert??? From owner-ietf-pkix@imc.org Thu Jun 22 16:58:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15478 for ; Thu, 22 Jun 2000 16:58:29 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA27321; Thu, 22 Jun 2000 13:55:57 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 13:55:55 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA27286 for ; Thu, 22 Jun 2000 13:55:54 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 22 Jun 2000 14:55:27 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 22 Jun 2000 14:55:21 -0600 From: "Bob Jueneman" To: , Subject: Re: Do people have something against RSA? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA27287 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Amen, brother! I'm still waiting to see piece of e-mail that was signed using DSA and validated by a signature that also uses DSA. It isn't that it couldn't necessarily be done, it's just that it would be such a curiosity that I would be inclined to frame it. It's exactly like when all of the coin machine vendors were forced to change their machines to handle the Susan B. Anthony dollar, only to have that coin sink like a rock. The Post Office (and only the Post Office) issued them as change if you bought a book of stamps, and anyone who received one got rid of it at the first opportunity. In the meantime, mandating particular algorithms that no one uses adds very significantly to the cost of development, testing, and documentation, not to mention bloated code. And piling on additional, "standardized" optional algorithms just makes things worse. "The nice thing about standards is that there are so many different ones to choose from." Fortunately, the various vendors are quite free to say "Nuts to that" and ignore the political correctness nonsense, and many of them are doing so. RSA may very well be the Lavoris of cryptography -- the mouthwash you love to hate, twice a day -- but their standards, including the PKCS suite and S/MIME (along with Netscape's SSL, for all of its warts) have been commercial successes, while the adoption of IETF standards in this space have been lukewarm at best. And they (along with Phil Zimmerman) were the ones who were standing up to NSA and refusing to back down when the government wanted desperately to put the crypto genie back in the bottle. I'm glad that patents don't last forever, but we shouldn't begrudge them a reasonable return on their hard work. Bob >>> "Christopher Williams" 06/16/00 11:35AM >>> OK, maybe RSADSI are litigious and awkward to deal with. I don't know, I've never dealt with them. However, let's say that I implemented a standard, say TLS, and only included the mandatory cipher suite, DSA with ephemeral Diffie-Hellman, SHA-1 and 3-DES encryption. You know what? It wouldn't work with anything! Everybody else's implementation uses RSA so mine has to as well, whether I like it or not. The reality is that RSA is mandatory and DSA the nice optional extra which adds spice and competitive advantage. As to whether the future belongs to RSA or maybe some recent innovation like ECC or some as-yet uninvented scheme, as Microsoft shows, it's not being the best that makes you the winner, it's being the most widespread. So, given that: - RSA's patent is due to expire (news to me, but welcome news) - DSA has patent issues in Europe - Everybody uses RSA anyway; very few use DSA Can we please start mandating RSA in future? It will make implementing standards much easier and remove the FUD because I haven't incorporated support for Diffie-Hellman! Christopher Williams Software engineer, NetLexis Ltd. http://www.netlexis.com "Intelligent Trust" From owner-ietf-pkix@imc.org Thu Jun 22 17:20:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15874 for ; Thu, 22 Jun 2000 17:20:38 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA27739; Thu, 22 Jun 2000 14:12:35 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 14:12:32 -0700 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27706 for ; Thu, 22 Jun 2000 14:12:28 -0700 (PDT) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A1472110046; Thu, 22 Jun 2000 23:12:39 +0200 Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Do, 22 Jun 2000 23:13:33 +0100 From: "Peter Lipp" To: "Bob Jueneman" , Subject: AW: Do people have something against RSA? Date: Thu, 22 Jun 2000 23:13:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.D38462D0--"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.D38462D0-- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob, > I'm still waiting to see piece of e-mail that was signed using DSA > and validated by a signature that also uses DSA. It isn't that it > couldn't necessarily > be done, it's just that it would be such a curiosity that I would=20 > be inclined to=20 > frame it. You did not insist on S/Mime, did you? :-) Peter -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.2 for non-commercial use iQA/AwUBOVJzV957bAzp9yvZEQJpCACg+kFddmAtF1sQLcxsQb08tuvEwUAAn33F cEdI+b9r5DlcFZOZR6yC2MQb =3DbEaT -----END PGP SIGNATURE----- ----IAIK.SMIME.MAPPER.D38462D0-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC 2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9 ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy 2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE 6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx 2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7 rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8 lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3 DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI 7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG 9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6 Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25 sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9 l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q 19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6 ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1 OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B 2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1 2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64 vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMDA2MjIyMTEzMzNaMCMGCSqGSIb3DQEJBDEWBBQ/i1ZRD+w5COw7 9cM6hVYFk6tY/TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN BgkqhkiG9w0BAQEFAASBgJXgdAkoIEwjh6cRhyFIvtUWzUyPGjpZFftbgpI5uHNT rNgxnYRj6fHTi5JqpzHDDxTGl5lDCobGDzTu4of1x1REUBOVv+6i/sRreNeHB8Rw SODA4+ZuyJCXrddfEjugoUWums+oERrslP9hOh/dBipiEja0HZ+dyct9jOdoiHU7 AAAAAAAA ----IAIK.SMIME.MAPPER.D38462D0---- From owner-ietf-pkix@imc.org Thu Jun 22 17:55:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16367 for ; Thu, 22 Jun 2000 17:54:59 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA28248; Thu, 22 Jun 2000 14:46:55 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 14:46:45 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA28217 for ; Thu, 22 Jun 2000 14:46:44 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 22 Jun 2000 15:46:22 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 22 Jun 2000 15:46:24 -0600 From: "Bob Jueneman" To: , Cc: Subject: Re: Can we form certificates with just name and e-mail address Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA28218 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Steve, >"Since e-mail addresses are already globally unique, what does the given name and surname do for you, from a tree structure standpoint?" Well, e-mail addresses are presumably globally unique, but they are not necessarily one to one with an identifiable person. Two or more people may share an e-mail mailbox, and very often do. And one person may have more than one mailbox, and many do. Likewise, there may be multiple Steve Kent's, and there might or might not be multiple c=US, sP=MA, l=Cambridge, cN="Steve Kent". But presumably there would only be one {c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="kent@bbn.com" Even so, that DN might be globally unambiguous, but not globally unique. {c=US, l=Gotham, cN="Clark Kent"}+rfc822="kent@bbn.com" may in fact refer to the same individual. And both e-mail postal boxes and DNS components can have aliases, so {c=US, l=Gotham, cN=Superman}+rfc822="Faster Than A Speeding Bullet"@DailyPlanet.com may also refer to the same person. Signed, "Leaps Tall Buildings with a Bound and a Half"@novell.com :-) >>> Stephen Kent 06/20/00 09:13AM >>> Stefan, >Steve, > >Thank's for useful input. Just to round this up, can you confirm the >conclusion that issuing certificates where subjects are represented >by just e-mail address + givenName + surname (and maybe also >country) is simply not possible. > >The name must simply be combined with a serialNumber attribute or >some other information that makes the name (with e-mail address >excluded) a reasonable DN. > >Right? Well, its possible to issue certs with any sort of DN. The question is what makes sense given the semantics of a DN, not just viewing it as a string of AVAs irrespective of context. The question I would ask is what would the directory tree look like given a proposed DN. How would the tree be distributed and managed? Think about the schema with those considerations in mind. For example, if one uses a geopolitical and organizational structure, which is the common model for DNs, we see lots of reasonable options for dividing the tree and determining who is responsible for maintainign what portions of it. On the other hand, if a DN consists of an e-mail address plus givenname and surname, this seems rather odd. The e-mail address, as a single attribute, results in a very broad fan out under the root. (in contrast, if one used DC attributes, as mentioned recently, one could mimic the structure of the DNS, which is well suited for separation and distributed maintenance, as the DNS has shown.) Since e-mail addresses are already globally unique, what does the given name and surname do for you, from a tree structure standpoint? Steve From owner-ietf-pkix@imc.org Thu Jun 22 18:28:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16706 for ; Thu, 22 Jun 2000 18:28:09 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA28935; Thu, 22 Jun 2000 15:27:04 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 15:27:01 -0700 Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28904; Thu, 22 Jun 2000 15:27:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Thu, 22 Jun 2000 15:27:16 -0700 To: "Bob Jueneman" , From: Paul Hoffman / IMC Subject: Re: Do people have something against RSA? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 2:55 PM -0600 6/22/00, Bob Jueneman wrote: >I'm still waiting to see piece of e-mail that was signed using DSA and >validated by a signature that also uses DSA. Start using PGP. >I'm glad that patents don't last forever, but we shouldn't begrudge them a >reasonable return on their hard work. It's funny how we never hear things like this from anyone who doesn't work for a large company. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix@imc.org Thu Jun 22 18:34:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16863 for ; Thu, 22 Jun 2000 18:34:03 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA29197; Thu, 22 Jun 2000 15:31:53 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 15:31:51 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA29167 for ; Thu, 22 Jun 2000 15:31:51 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA09740; Thu, 22 Jun 2000 18:32:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 22 Jun 2000 18:28:43 -0400 To: "Bob Jueneman" From: Stephen Kent Subject: Re: Can we form certificates with just name and e-mail address Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Bob, >Steve, > > >"Since e-mail addresses are >already globally unique, what does the given name and surname do for >you, from a tree structure standpoint?" > >Well, e-mail addresses are presumably globally unique, but they are >not necessarily >one to one with an identifiable person. Two or more people may share an >e-mail mailbox, and very often do. And one person may have more than one >mailbox, and many do. OK. But that does not justify constructing the schema we're debating, nor does the schema in question match your examples below. > >Likewise, there may be multiple Steve Kent's, and there might or might not >be multiple c=US, sP=MA, l=Cambridge, cN="Steve Kent". Yes, we need to have a DN that distinguishes among multiple Steve Kents. In your example above, a postal address would typically be employed to identify me as a specific residential person, or a binding to my employer would be used for me as an organizational person. >But presumably there would only be one >{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="kent@bbn.com" True. If the intent were to create multiple leaf entries below the single entry of this form then the justification would be better, but I don't that's what people have been suggesting. >Even so, that DN might be globally unambiguous, but not globally unique. >{c=US, l=Gotham, cN="Clark Kent"}+rfc822="kent@bbn.com" >may in fact refer to the same individual. No argument there. Multiple entries in the DIT may correspond to the same physical entity, ad would usually be true for residential and organizational persons, for example. >And both e-mail postal boxes and DNS components can have aliases, >so {c=US, l=Gotham, cN=Superman}+rfc822="Faster Than A Speeding >Bullet"@DailyPlanet.com >may also refer to the same person. Sure. Steve From owner-ietf-pkix@imc.org Thu Jun 22 19:08:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17118 for ; Thu, 22 Jun 2000 19:08:31 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA29745; Thu, 22 Jun 2000 15:59:04 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 15:58:59 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA29714 for ; Thu, 22 Jun 2000 15:58:58 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 22 Jun 2000 16:58:34 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 22 Jun 2000 16:58:24 -0600 From: "Bob Jueneman" To: , Cc: Subject: Re: certification for pki Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA29715 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit I attended the recent International Common Criteria conference in Baltimore, mostly to learn the answers to these kinds of questions. My assessment would be as follows: 1. The Common Criteria, and the fact that 13 or so countries have agreed to it, is not really a criteria at all, from the usual perspective, but rather a meta-criteria or specification language for laying out in some (excruciating) detail what the requirements are, and how you have met them. As a process for convincing yourself, or your industry, that you have thought hard about the problem you are trying to solve, it is excellent. 2. The real "guts" of the issue, however, is not how you specify the requirements, but what the requirements really are. And this is done through the Protection Profile. 3. Unfortunately, there are as yet very few Protection Profiles that have been published, and even fewer, if any that have been widely vetted and accepted by a broad segment of the user community. 4. One of the best examples of a good Protection Profile is being hammered out by the smart card industry, with the clout of the banks and credit card companies behind it. That will almost surely emerge as a almost universally accept PP. 5. Some of the worst (from the standpoint of universality) Protection Profiles may be in the area of PKI. It should be obvious, but if there is substantial disagreement as to the fundamentals of the digital signature law of the jurisdiction, there is not likely going to be any commonality regarding the Protection Profile. As a result, I would expect that if say Siemens expects to sell a PKI for use in Germany, they will eventually have to get it certified against the German Protection Profile. But having done so, that may or may not carry any weight at all with respect to say the State of Utah's PKI requirement. And vice versa, for someone like Digital Signature Trust if they try to sell into Germany. In other words, I wouldn't bet a whole lot of money on the Common Criteria being a roaring success, and especially in the PKI space. And I say that, even though I'm a firm believer in the value of an independent evaluation of important software components. Time will tell bob >>> 06/21/00 09:47AM >>> It is not a choice of CC vs. FIPS. The FIPS 140-1 testing pertains narrowly to crypto modules. The CC evaluation/"torture" process is about the system/components for certificate issuance and management meeting its security specification (security target and claimed PP(s)). A crypto module is just an embedded "engine" in the larger vehicle. To continue with the automotive metaphor, it is not a choice between auto emission testing vs. crash testing vs. fuel economy vs. performance testing, etc. All of these tests may be required for the consumer to understand and compare what they are buying. It may be "torture" for the manufacturer, but when the market (or laws, regulations, etc.) demand it, manufacturers do it. -GH pgut001@cs.auckland.ac.nz on 06/21/2000 11:11:43 PM Please respond to pgut001@cs.auckland.ac.nz To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: Re: certification for pki ghilborn@csc.com writes: >One internationally recognized avenue is an evaluation under the Common >Criteria/ISO 15408. Such an evaluation up to EAL4 is automatically recognized >by the (currently) nine mutual recognition arrangement countries. Two current >problems are (1) that the CC itself does not contain a crypto module >evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus >and evaluated Protection Profile for PKI components. Some product vendors >have undertanen evaluations without PPs. FIPS 140-1 is officially US/Canada, >but also widely recognized. A third problem with the CC, for those who haven't experienced it before, is that it acts as a form of torture for companies to determine how badly they need government (or whatever) contracts - the more pain you can stand, the better you've demonstrated that you need the contract. I'm not just saying this for $generic_CC_bashing, from talking to people who have gone through it it really sounds like an incredibly unpleasant experience (when I used the term "torture" to describe it above this doesn't originate with me but with the people I talked to). In terms of achieving more or less the same effect (the certification that is, not the torture :-) it looks like FIPS 140 is the easier path, and it does constitute a de facto PP which the CC doesn't have yet. I'd go with FIPS 140. Peter. From owner-ietf-pkix@imc.org Thu Jun 22 19:14:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17181 for ; Thu, 22 Jun 2000 19:14:35 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA00185; Thu, 22 Jun 2000 16:12:23 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 16:12:20 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA00153 for ; Thu, 22 Jun 2000 16:12:19 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 22 Jun 2000 17:11:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 22 Jun 2000 17:11:18 -0600 From: "Bob Jueneman" To: Cc: Subject: Re: Can we form certificates with just name and e-mail address Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA00154 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit Steve/Clark :-), >>But presumably there would only be one >{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="kent@bbn.com" >True. If the intent were to create multiple leaf entries below the single entry of this form then the justification would be better, but I don't that's what people have been suggesting. It's not that I particularly like compound attributes, but that's what I was suggesting, rather than having the rfc822 be a leaf under the user name DN. That's what I mean to imply by the plus sign -- exactly like most people have been suggesting for name+serial. At least the rfc822 name component has a great semantic content than a serial number. On the other hand, I guess we could always revert to the imfamous MPEG of me and my cat. But instead of putting it in the DN, I guess we would have to make it a directory attribute now. (Just joking, of course.) Bob >>> Stephen Kent 06/22/00 04:28PM >>> Bob, >Steve, > > >"Since e-mail addresses are >already globally unique, what does the given name and surname do for >you, from a tree structure standpoint?" > >Well, e-mail addresses are presumably globally unique, but they are >not necessarily >one to one with an identifiable person. Two or more people may share an >e-mail mailbox, and very often do. And one person may have more than one >mailbox, and many do. OK. But that does not justify constructing the schema we're debating, nor does the schema in question match your examples below. > >Likewise, there may be multiple Steve Kent's, and there might or might not >be multiple c=US, sP=MA, l=Cambridge, cN="Steve Kent". Yes, we need to have a DN that distinguishes among multiple Steve Kents. In your example above, a postal address would typically be employed to identify me as a specific residential person, or a binding to my employer would be used for me as an organizational person. >But presumably there would only be one >{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="kent@bbn.com" True. If the intent were to create multiple leaf entries below the single entry of this form then the justification would be better, but I don't that's what people have been suggesting. >Even so, that DN might be globally unambiguous, but not globally unique. >{c=US, l=Gotham, cN="Clark Kent"}+rfc822="kent@bbn.com" >may in fact refer to the same individual. No argument there. Multiple entries in the DIT may correspond to the same physical entity, ad would usually be true for residential and organizational persons, for example. >And both e-mail postal boxes and DNS components can have aliases, >so {c=US, l=Gotham, cN=Superman}+rfc822="Faster Than A Speeding >Bullet"@DailyPlanet.com >may also refer to the same person. Sure. Steve From owner-ietf-pkix@imc.org Thu Jun 22 20:16:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17768 for ; Thu, 22 Jun 2000 20:16:25 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA00922; Thu, 22 Jun 2000 17:08:10 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 17:08:00 -0700 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA00890; Thu, 22 Jun 2000 17:07:59 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 22 Jun 2000 18:07:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 22 Jun 2000 18:07:43 -0600 From: "Bob Jueneman" To: , Subject: Re: Do people have something against RSA? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id RAA00891 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit I don't disagree that PGP can use DSA. And if I were building and giving away a product primarily to advance my own notions of social justice, freedom, and privacy for all, laudable as that might be, instead of trying to make a reasonable living, I would certainly pick a free algorithm also. But we were talking about IETF standards, not freeware. I don't think that the issue is one of large companies vs. small companies, or even individuals or nonprofit institutitions. Instead, the issue cuts to the very heart of t he value of intellectual property, and whether someone, including you, has a right to make a profit from their creative endeavors. Because the Internet was originally paid for by the US government and member institutions, individuals never received a bill for service, and hence they tended to develop a sense of entitlement. "From each, according to their abilities, and to each, according to their needs" was the credo of the Communists, and to a degree that mantra seems to have been adopted by a segment of the Internet community. Since I "need" free movies, free MP3, free crypto, free computer games, etc., etc., and don't have the artistic or technical ability to generate them myself, I should be entitled to casually reach in and take whatever I want, without paying for anything. Minor details such as copyrights, patents, licensing fees, attorneys -- these are just impediments created by the "suits" to prevent my instant self-gratification. After all, these things are just bits, right? It isn't as though I was stealing a car, right? Sounds great, at least to the young and naive (as most of us were at one time). Unfortunately, although the Soviets tried this system for 80 years, and the Cubans, North Koreans, and some other societies are still trying it, the jury has come back with a verdict. Except in some closed societies, normally religious orders, this system simply does not work, and can only be sustained through a very harsh and cruel dictatorship. Those who have talent either opt out or become the bosses, leaving those who cannot to fend for themselves. If inventors cannot be rewarded for the fruits of their labors, then the entire structure of capitalism is without a foundation, and all of the IPOs and stock market gains are merely the Tulip Bulb mania repeating itself all over again. Unfortunately, it has gotten to the point that filing for an invention has become the kiss of death within the IETF. No matter how good the idea is, if you patent it the IETF will go out of their way to make sure that it isn't standardized. The inevitable result of this is that either (1) companies will stop inventing things, since they won't be rewarded for them, or (2) companies will drop out of the IETF process, and ignore the standards as either irrelevant or explicitly contrary to their business interests. Is that what we want to have happen? Bob >>> Paul Hoffman / IMC 06/22/00 04:27PM >>> At 2:55 PM -0600 6/22/00, Bob Jueneman wrote: >I'm still waiting to see piece of e-mail that was signed using DSA and >validated by a signature that also uses DSA. Start using PGP. >I'm glad that patents don't last forever, but we shouldn't begrudge them a >reasonable return on their hard work. It's funny how we never hear things like this from anyone who doesn't work for a large company. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix@imc.org Thu Jun 22 20:44:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18016 for ; Thu, 22 Jun 2000 20:44:29 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA01876; Thu, 22 Jun 2000 17:42:08 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 17:42:02 -0700 Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA01846; Thu, 22 Jun 2000 17:42:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Thu, 22 Jun 2000 17:42:06 -0700 To: "Bob Jueneman" , From: Paul Hoffman / IMC Subject: Re: Do people have something against RSA? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 6:07 PM -0600 6/22/00, Bob Jueneman wrote: >I don't disagree that PGP can use DSA. And if I were building and giving away >a product primarily to advance my own notions of social justice, >freedom, and privacy >for all, laudable as that might be, instead of trying to make a >reasonable living, I >would certainly pick a free algorithm also. But we were talking about IETF >standards, not freeware. OpenPGP *is* and IETF standard. It has the same standards level as S/MIME and PKIX does. You may not use it, and your company may not sell it, but please stop pretending it is not an IETF standard. >I don't think that the issue is one of large companies vs. small >companies, or even >individuals or nonprofit institutitions. We fully disagree here. Small companies cannot get reasonably-priced licenses for RSA today. Even large companies who have business models where they want to give away free software (have you ever heard of Microsoft, IBM, and AOL?) that happens to have good security in it cannot get reasonably-priced licenses from RSA. That is a business decision that RSA has had in place for many, many years. >Instead, the issue cuts to the very heart of t >he value of intellectual property, and whether someone, including >you, has a right >to make a profit from their creative endeavors. That's absolutely right. And, because there are freely-usable alternatives, we can ignore it. When the RSA patent expires, we can decide what to do about RSA vs. DSA. [ insulting assumptions about other people's motivations snipped ] >Unfortunately, it has gotten to the point that filing for an >invention has become >the kiss of death within the IETF. No matter how good the idea is, >if you patent it >the IETF will go out of their way to make sure that it isn't standardized. Bob, you need to get out into the rest of the IETF more. There are many IETF standards that use patented technologies. The patent holders have granted reasonable licenses to their competitors to use the technology in IETF standards. >The inevitable result of this is that either (1) companies will stop >inventing things, >since they won't be rewarded for them, or (2) companies will drop >out of the IETF >process, and ignore the standards as either irrelevant or explicitly >contrary to their >business interests. Is that what we want to have happen? The same argument has been heard here for many years, and it has never become true. I won't predict why that is, because my prediction mechanism is probably as badly flawed as yours is. If you (as an individual) want to drop out of the IETF, and/or if you want to try to convince Novell to drop out of the IETF, you are welcome to. What we want to have happen is that useful, freely-implementable standards can be created. There are many other standards bodies that have different agendas. Spend your time in them as you wish. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-pkix@imc.org Thu Jun 22 21:29:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18241 for ; Thu, 22 Jun 2000 21:29:33 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA05646; Thu, 22 Jun 2000 18:23:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 18:22:54 -0700 Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA05607 for ; Thu, 22 Jun 2000 18:22:52 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 0149118 for ; Thu, 22 Jun 2000 21:22:58 -0400 (EDT) Message-ID: <3952BC34.498B6D2E@caveosystems.com> Date: Thu, 22 Jun 2000 21:24:04 -0400 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: PKIX Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Aram: > You shouldn't have to, although this is the model that most public CAs seem > to push and/or encourage. As I mentioned, a possible solution is the the use > of "anchor certificates". Seems a little complicated. I don't see why I have to introduce an extra entity involved, or extra certs involved. Stephen Kent: > I've always asserted that self-signed certs are just a syntactic > convenience, not a generally useful way of ensuring security for > transmitted public keys. If we agree on that point, then I don't see > a lot of reason to push for self-signed TSA certs. I don't agree. As the service provider, why do I *have* to deal with the management of two private keys. It's way more than syntax. We don't need to "push" anything. We need to not prohibit it. /r$ From owner-ietf-pkix@imc.org Thu Jun 22 21:34:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18346 for ; Thu, 22 Jun 2000 21:34:12 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA06538; Thu, 22 Jun 2000 18:30:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 18:30:50 -0700 Received: from cymail.cylink.com (cymail.cylink.com [192.43.161.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06505 for ; Thu, 22 Jun 2000 18:30:49 -0700 (PDT) Received: from hurricane ([10.108.20.6]) by cymail.cylink.com (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-41860U500L2S100) with SMTP id AAA22064 for ; Thu, 22 Jun 2000 18:27:06 -0700 Reply-To: From: lnightin@cylink.com (Les Nightingill) To: Subject: RE: Private Key Cloning Date: Thu, 22 Jun 2000 18:24:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit I'm curious on the views of the "key cloning detractors" on the notable disaster-recovery mitigation benefits of cloning. While the indirection solution helps with load-sharing, it still leaves the root unrecoverable under a no-clone policy. I suppose I should check, but perhaps someone knows, too, whether an M-of-N secret sharing scheme for disaster recovery of a root key is also non-compliant with the German Digital Signature laws? Les Nightingill Cylink -----Original Message----- From: Michael Zolotarev [mailto:mzolotarev@baltimore.com] Sent: Wednesday, June 21, 2000 5:19 PM To: Jeff Davis; ietf-pkix@imc.org Subject: RE: Private Key Cloning Jeff wrote: > The whole idea of having a private key is just that, it is > private to a > single entity and not shared across many other "clones" of > that entity. > > IMHO, and it is very "H" in this case, cloning a private key, of any > nature, is opening yourselves up to all sorts of repudiation > claims. If > you clone once what stops you cloning "n" times without > anyone knowing > ( regardless of what procedures you have in place ). Part of > the basis > of "trust" is that a private key only exists in one place under the > strict control of the owner of that key. The cloning procedure becomes a critical part, I agree. So the authority would have to certify both the security/procedures of its operational environment, and the security/procedures of key cloning. The same scale of precautions that currently applies to keeping the [only and single] key secure would apply to the cloning process. If you suspect that the cloning may allow a criminal-minded high-privileged insider to perpetrate a fraud, then for the same reason your should similarly suspect any other security aspects of the authority operations. We must always consider every particular case of key cloning, instead of dismissing the whole concept. If a particular cloning procedure, executed by a particular authority, using given hardware, in a particular secure environment etc etc can be formally certified as being sufficiently secure, at least not less(!) secure than the rest of the solution - what is wrong with it? If you can prove that your solution is secure - that would be just fine. Why reject the approach on the basis that it MAY present a security hole. Following that logic, whole PKI would be extinct by now. > > I support the views put forward that maybe the TSA root should sign > certificates for level 1 TSA Agents, of which there could be > as many as > required, but all of whom have a different DN ( very closely > associated > with the parent TSA ). The trust of the Time Stamp would then be > through a normal certificate chain and that only being 1 level. Maybe > the TSA root could then go offline leaving the "work horses" > to perform > the stamping. Re-issuing of new TSA signing keys would then be quite > easy for each Agent, with only 1 out of "n" Agents being > offline at any > one time, update the hardware signing module and get back online > a.s.a.p. > > I may be well off the mark here, if so, just tell me to shut > up and get > back in the cupboard. However, as I am trying to learn this stuff, a > little help with my waywardness would go a long way. > I'm also new to the house. But I've learned that there are two words missing in the group's dictionary - "beautiful" and "shut up". Three words, actually :) M From owner-ietf-pkix@imc.org Thu Jun 22 22:04:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19490 for ; Thu, 22 Jun 2000 22:04:26 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA10127; Thu, 22 Jun 2000 19:03:19 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 19:03:09 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10095 for ; Thu, 22 Jun 2000 19:03:07 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id MAA06673; Fri, 23 Jun 2000 12:08:47 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Jun 2000 12:02:17 +1000 Message-ID: From: Michael Zolotarev To: Peter Lipp , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Fri, 23 Jun 2000 12:02:16 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I guess the problem is a common misconception that a TSA is always a subsidiary/sub-service of a CA. Not necessary. TSA is/can_be a service on its own, with no inherited relationship to any CA at all. So when NIST starts offering TSA services, it would have to get a certificate from some CA? Why? Why wouldn't you trust their TSA certificate directly? > -----Original Message----- > From: Peter Lipp [mailto:Peter.Lipp@iaik.at] > Sent: Thursday, June 22, 2000 7:24 PM > To: ietf-pkix@imc.org > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > > > > I'm not convinced it's bad to issue self-signed TSA certificate. > > I'm just saying it might not be a great idea. > Agree. I don't see the big advantage. For one, if I want to > trust a CA I > need to go through whatever steps are appropriate. If the CA > offers/recommends/uses a TSA, it can give me a certificate > for the TSA and - > having already decided to trust the CA - it is simple to verify the > certificate and decide to trust the TSA too. So what does the > self-signed > TSA cert buy me besides the need to go through the trust > decisions again? > Now consider revocation - do you really suggest to set up a separate > revocation-scheme for the TSA? I simply don't see any > advantage here... > > Peter > From owner-ietf-pkix@imc.org Thu Jun 22 23:43:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21419 for ; Thu, 22 Jun 2000 23:43:08 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA16822; Thu, 22 Jun 2000 20:40:38 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 20:39:54 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16750 for ; Thu, 22 Jun 2000 20:39:48 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id NAA07411; Fri, 23 Jun 2000 13:45:46 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Jun 2000 13:39:16 +1000 Message-ID: From: Michael Zolotarev To: Rich Salz , PKIX , kent@bbn.com Cc: Denis.Pinkas@bull.net Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Fri, 23 Jun 2000 13:39:15 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > > I don't agree. As the service provider, why do I *have* to deal with > the management of two private keys. It's way more than syntax. > > We don't need to "push" anything. We need to not prohibit it. > /r$ > I fully agree with that. Guys, << I feel that I've said all I had to say on the subject. In this mail I'll try to put together a little summary of my position, which I know is supported by a number of the list members. It was taking too much and too long - this message will be the last from me on self-signed TSA certs (do I see happy smiles :)? Denis, it is really up to you now - put it on vote, or forget. >> I (quite frankly) fail to understand the rational for the draft to introduce limitations which necessitate extra entities and potentially more complex environment for all involved parties. All for a sake of extra purity of a concept, which is already pure enough. Probably my position is too much 'engineering', but this is what I am, sorry. An example first: Imagine some Business_Domain_Managing_Authority (BDMA) that wants to deploy a TSA service for its members. Would it be Ok that the members express their trust directly to the TSA? I guess so. With the client's trust expressed directly to the TSA cert, it is irrelevant if the TSA cert was self-signed or CA-signed. Referring to the arguments in favor of signing by CA - yes, I agree that there are benefits, thank you. It is all perfect with the assumption that there IS a CA around, or at least a business has a need for a CA. Now, can anybody explain the BDMA's manager (a stubborn and slow guy he is indeed :) why the organisation has to buy/setup/employ a CA, if everything that they will ever need is just a TSA? << I know that the previous sentence may get me sacked from Baltimore, which main business is selling CAs. :) So the standard disclaimer is right here. >> Mind you, out-of-band TSA cert delivery is as complex, or as simple, as the one for distributing a CA's cert, should it exist. As a conclusion: Using self-signed TSA certs should be an internal matter for each domain, each TSA, subject to specific policy and national regulations. And a hell lot more. Therefore, the draft should not encourage self-signed TSA certs, neither it should prohibit them. It should be neutral and stay away from that slippery subject. And it is not far from what the current draft is about, as it seems. A minor fix- a sentence for the security considerations section would be something like: "The TSA private key must be generated and used ONLY for signing timestamps, and possibly for internal key/certificate management operations such as P-O-P or self-signing." Best regards Michael From owner-ietf-pkix@imc.org Fri Jun 23 00:30:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21865 for ; Fri, 23 Jun 2000 00:30:31 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA19657; Thu, 22 Jun 2000 21:29:25 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 21:29:19 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA19624 for ; Thu, 22 Jun 2000 21:29:17 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA00375; Fri, 23 Jun 2000 14:35:03 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Jun 2000 14:28:27 +1000 Message-ID: From: Michael Zolotarev To: "David P. Kemp" , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Fri, 23 Jun 2000 14:28:26 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > > > From: Michael Zolotarev > > > > 1. Self-signed TSA cert. You have to evaluate your secure signing > > environment. Which is the same for generating timestamps > and for generation > > a self-signed cert. > > What security-relevant information are you expecting clients to derive > from validating the signature of a self-signed cert? > A client would not validate a self-signed cert - it would have to be trusted directly, as an anchor. Distributed and cjecked out-of-bands. Why the question? > Do you expect clients to have trusted storage which could > hold a bare TSA > public key, but which could not hold the entire self-signed > TSA cert??? > No, I do not. The clients would store the entire self-signed cert. Aha, I see it now: phrasing in (1) could be misleading. The signing of the self-signed certificate is not critical, as the cert must be validated out-of-band anyway. You only need to evaluate your secure key generation environment, and the security of key storage and the crypto engine used for signing timestamps. But the argument still stays: using self-signed certificate does not necessarily make the formal security evaluation process of a TSA any more difficult, compared to having the TSA cert signed by a CA. Regards Michael From owner-ietf-pkix@imc.org Fri Jun 23 01:35:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26622 for ; Fri, 23 Jun 2000 01:35:14 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA21763; Thu, 22 Jun 2000 22:28:54 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 22 Jun 2000 22:28:41 -0700 Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA21703 for ; Thu, 22 Jun 2000 22:28:38 -0700 (PDT) Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id PAA49336; Fri, 23 Jun 2000 15:28:22 +1000 (EST) Message-ID: <027401bfdcd5$0a02e590$8802a8c0@eracom.com.au> From: "Simon McMahon" To: "Michael Zolotarev" , "David P. Kemp" , References: Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Fri, 23 Jun 2000 15:36:22 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > > > From: Michael Zolotarev > > > > > > 1. Self-signed TSA cert. You have to evaluate your secure signing > > > environment. Which is the same for generating timestamps > > and for generation > > > a self-signed cert. > > > > What security-relevant information are you expecting clients to derive > > from validating the signature of a self-signed cert? > > > A client would not validate a self-signed cert - it would have to be trusted > directly, as an anchor. Distributed and cjecked out-of-bands. Why the > question? > > Why should the TSA self-sign this cert if no client will ever check the signature ? This cert could be signed by any private key and the client would not know since it trusts it directly and does not verify the sig. Would you really abuse the usage constraints on a timestamping key to make a signature that nobody needs to verify ? The TSA may as well use another key-pair that it generates to sign this cert. It can then make a normal self-signed cert with this new key pair that will not sign timestamps. Then clients who will not check the TSA cert's signature can just install and trust the TSA cert (not self-signed). Clients that insist on checking signatures on trusted and/or self-signed certs can install both certs then trust the self-signed cert (not the TSA cert) as if it was from a real CA. The TSA is effectively has its own mini CA and will only certify its own time-stamping key pair. Its hardly a full blown CA with all the costs that go with them. You could leave out the possibility of revocation etc. and you would be no worse off than the self-signed TSA cert scenario. > > I don't agree. As the service provider, why do I *have* to deal with > the management of two private keys. It's way more than syntax. > Because you are trying to do two things with one key. Producing timestamps, and trusting them. You are still *having* to deal with these two seperate processes the difference is with one key or with two. If your clients dont check the trusted TSA cert's signature then you fall back to only needing one key. Simon. From owner-ietf-pkix@imc.org Fri Jun 23 04:14:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05368 for ; Fri, 23 Jun 2000 04:14:38 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA28143; Fri, 23 Jun 2000 01:09:39 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 01:09:31 -0700 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA28110 for ; Fri, 23 Jun 2000 01:09:30 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA24328 for ; Fri, 23 Jun 2000 10:13:05 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA28904 for ; Fri, 23 Jun 2000 10:09:11 +0200 Message-ID: <39531B2A.56B1643F@bull.net> Date: Fri, 23 Jun 2000 10:09:14 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: IETF-PXIX Subject: Allow RSA mandatory after September 20, 2000 ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Up to now, the IETF WGs and the IESG have mandated the DSA and Diffie-Hellman algorithms only, since the RSA algorithm was patented. On September 20, 2000 the RSA patent will expire, so this allows the IESG to reconsider the issue. I would like the co-chairs to raise this issue to the IESG, so that for any Standard (not Proposed Standard) issued after September 20, 2000, we can, if this is a WG decision, mandate the RSA algorithm. Denis From owner-ietf-pkix@imc.org Fri Jun 23 04:19:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05387 for ; Fri, 23 Jun 2000 04:19:50 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA28620; Fri, 23 Jun 2000 01:18:35 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 01:18:33 -0700 Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA28587 for ; Fri, 23 Jun 2000 01:18:32 -0700 (PDT) Received: by mystic1.trustcenter.de; id KAA03791; Fri, 23 Jun 2000 10:16:43 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma003785; Fri, 23 Jun 00 10:15:58 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id KAA28179; Fri, 23 Jun 2000 10:17:28 +0200 (MET DST) Message-Id: <3.0.5.32.20000623101727.03831100@callisto> X-Sender: jbr@callisto X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 23 Jun 2000 10:17:27 +0200 To: , From: Juergen Brauckmann Subject: RE: Private Key Cloning In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA28589 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 8bit At 18:24 22.06.00 -0700, Les Nightingill wrote: >I suppose I should check, but perhaps someone knows, too, whether an M-of-N >secret sharing scheme for disaster recovery of a root key is also >non-compliant with the German Digital Signature laws? Well, this is untested yet, I guess... . Private key cloning is explicitely prohibited in the text of the law, but whether copying with secret sharing is the same is not sure to me. As this is a law and legal stuff, you probably cannot check this issue yourself, but you have to test against the authorities:-) Juergen -- Juergen Brauckmann Tel.: 040 / 8080 26 311 TC TrustCenter GmbH Fax.: 040 / 8080 26 126 Sonninstraße 24-28 mailto:brauckmann@trustcenter.de 20097 Hamburg http://www.trustcenter.de From owner-ietf-pkix@imc.org Fri Jun 23 04:27:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05439 for ; Fri, 23 Jun 2000 04:27:44 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA29263; Fri, 23 Jun 2000 01:26:56 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 01:26:50 -0700 Received: from stonewall.baltimore.com (mailhost.baltimore.com [195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA29229 for ; Fri, 23 Jun 2000 01:26:47 -0700 (PDT) Message-ID: <61922E6DA745D311A42000508B2CFD14B9677B@baltimore.com> From: Paul Halliden To: "'thayes@netscape.com'" Cc: "'Paul Koning'" , seidel@timeproof.de, FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt Date: Fri, 23 Jun 2000 09:27:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Terry Hayes wrote: >A TSA MAY choose enforce restrictions on the imprint, but the >standard should not REQUIRE it. Agreed. The question I was answering was "Why should people avoid using MD5 - other than because the German Digital Signature Law says so?". Paul Halliden From owner-ietf-pkix@imc.org Fri Jun 23 07:53:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07419 for ; Fri, 23 Jun 2000 07:53:53 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA10621; Fri, 23 Jun 2000 04:52:20 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 04:52:13 -0700 Received: from FW-BEL.utimaco.be ([193.121.107.230]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10591 for ; Fri, 23 Jun 2000 04:52:06 -0700 (PDT) Received: (from uucp@localhost) by FW-BEL.utimaco.be (8.9.3/8.9.3) id NAA09677 for ; Fri, 23 Jun 2000 13:55:01 +0200 (CEST) (envelope-from frederik.loeckx@utimaco.be) Received: from (belgien1.utimaco.be [10.7.0.25]) by FW-BEL.utimaco.be via smap (V2.1) id xma009670; Fri, 23 Jun 00 13:54:56 +0200 Received: by belgien1.utimaco.be(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id C1256907.0040A245 ; Fri, 23 Jun 2000 13:45:51 +0200 X-Lotus-FromDomain: UTIMACO From: "Frederik Loeckx" To: ietf-pkix@imc.org Message-ID: Date: Fri, 23 Jun 2000 13:45:47 +0200 Subject: Re: Allow RSA mandatory after September 20, 2000 ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Even further, the question could be raised if DSA and Diffie Hellman need to be marked as mandatory if RSA is already marked as mandatory. When RSA is already present as a common algorithm, there is not need for DSA, DH to be mandated. The standards will more reflect the actual marketplace, when DSA and Diffie Hellman are considered as optional. Frederik Denis Pinkas on 23/06/2000 10:09:14 To: IETF-PXIX cc: (bcc: Frederik Loeckx/Utimaco/BE) Subject: Allow RSA mandatory after September 20, 2000 ? Up to now, the IETF WGs and the IESG have mandated the DSA and Diffie-Hellman algorithms only, since the RSA algorithm was patented. On September 20, 2000 the RSA patent will expire, so this allows the IESG to reconsider the issue. I would like the co-chairs to raise this issue to the IESG, so that for any Standard (not Proposed Standard) issued after September 20, 2000, we can, if this is a WG decision, mandate the RSA algorithm. Denis From owner-ietf-pkix@imc.org Fri Jun 23 08:11:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07923 for ; Fri, 23 Jun 2000 08:11:32 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA11435; Fri, 23 Jun 2000 05:10:14 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 05:10:12 -0700 Received: from ns.secuve.co.kr (IDENT:root@[211.55.106.125]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA11402 for ; Fri, 23 Jun 2000 05:10:10 -0700 (PDT) Received: from secuve.com ([211.55.106.121]) by ns.secuve.co.kr (8.10.2/8.9.3) with ESMTP id e5NCB0P01181 for ; Fri, 23 Jun 2000 21:11:01 +0900 Message-ID: <395353E9.FD4471B7@secuve.com> Date: Fri, 23 Jun 2000 21:11:21 +0900 From: "Youjin, Eun" Organization: SECUVE X-Mailer: Mozilla 4.71 [en] (Win98; I) X-Accept-Language: ko,en MIME-Version: 1.0 To: "ietf-pkix@imc.org" Subject: subscribe Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit -- ============================================================= ------------------------------------------------------------- Name : Eun, You Jin ------------------------------------------------------------- Technical Director. SECUVE CO., Ltd. ------------------------------------------------------------- Phone : +82-342-726-0830 Fax : +82-342-726-0821 Cellular : +82-11-9968-0287 Address : D-217 SIGMA II 18, Koomi-Dong, Bundang-Gu, Sungnam-City, Kyunggi-Do, Korea E-mail : silver@secuve.com URL : http://www.secuve.com ============================================================= From owner-ietf-pkix@imc.org Fri Jun 23 09:30:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09620 for ; Fri, 23 Jun 2000 09:30:17 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA14486; Fri, 23 Jun 2000 06:26:34 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 06:26:24 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14448 for ; Fri, 23 Jun 2000 06:26:23 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FWM0070100J2R@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 23 Jun 2000 06:26:43 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FWM0070L00J2C@ext-mail.valicert.com>; Fri, 23 Jun 2000 06:26:43 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 06:20:06 -0700 Content-return: allowed Date: Fri, 23 Jun 2000 06:20:05 -0700 From: Frank Balluffi Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] To: "'Michael Zolotarev'" , Peter Lipp , ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE2E08B97@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe According to RFC 2459 and draft-ietf-pkix-time-stamp-08.txt, the decision of how to terminate the most-significant end of a certificate path and obtain the most-trusted public key is up to you (i.e., is a matter of policy). I recommend that section 2.4.1 of draft-ietf-pkix-time-stamp-08.txt point to section 6.1 of RFC 2459 with something like: For more information about validating the certificates in the certificates field of the SignedData structure and obtaining the most-trusted public key, see RFC 2459, section 6.1. The relevant text follows. Frank RFC 2459, section 6: This text assumes that all valid paths begin with certificates issued by a single "most-trusted CA". ... The "most-trusted CA" is a matter of policy: it could be a root CA in a hierarchical PKI; the CA that issued the verifier's own certificate(s); or any other CA in a network PKI. RFC 2459, section 6.1: The text assumes that the trusted public key (and related information) is contained in a "self-signed" certificate. This simplifies the description of the path processing procedure. Note that the signature on the self-signed certificate does not provide any security services. The trusted public key (and related information) may be obtained in other formats; the information is trusted because of other procedures used to obtain and protect it. draft-ietf-pkix-time-stamp-08.txt, section 2.4.1 If the certReq field is present and set to true, the TSA's public key certificate that is referenced by the ESSCertID attribute in the response must be provided by the TSA in the certificates field from the SignedData structure in that response. That field may also contain other certificates. > -----Original Message----- > From: Michael Zolotarev [mailto:mzolotarev@baltimore.com] > Sent: Thursday, June 22, 2000 10:02 PM > To: Peter Lipp; ietf-pkix@imc.org > Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] > > > I guess the problem is a common misconception that a TSA is always a > subsidiary/sub-service of a CA. Not necessary. TSA is/can_be > a service on > its own, with no inherited relationship to any CA at all. > > So when NIST starts offering TSA services, it would have to get a > certificate from some CA? Why? Why wouldn't you trust their > TSA certificate > directly? > > > > -----Original Message----- > > From: Peter Lipp [mailto:Peter.Lipp@iaik.at] > > Sent: Thursday, June 22, 2000 7:24 PM > > To: ietf-pkix@imc.org > > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > > > > > > > I'm not convinced it's bad to issue self-signed TSA certificate. > > > I'm just saying it might not be a great idea. > > Agree. I don't see the big advantage. For one, if I want to > > trust a CA I > > need to go through whatever steps are appropriate. If the CA > > offers/recommends/uses a TSA, it can give me a certificate > > for the TSA and - > > having already decided to trust the CA - it is simple to verify the > > certificate and decide to trust the TSA too. So what does the > > self-signed > > TSA cert buy me besides the need to go through the trust > > decisions again? > > Now consider revocation - do you really suggest to set up a separate > > revocation-scheme for the TSA? I simply don't see any > > advantage here... > > > > Peter > > > From owner-ietf-pkix@imc.org Fri Jun 23 12:56:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15062 for ; Fri, 23 Jun 2000 12:56:07 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA23197; Fri, 23 Jun 2000 09:54:13 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 09:54:04 -0700 Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23150 for ; Fri, 23 Jun 2000 09:54:03 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.209]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA15606; Fri, 23 Jun 2000 09:53:51 -0700 (PDT) Message-Id: <4.2.0.58.20000622164315.00ae4ae0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 22 Jun 2000 16:44:46 -0400 To: Ambarish Malpani From: Russ Housley Subject: Re: Generalizing the concept of id-pkix-ocsp-nocheck Cc: ietf-pkix@imc.org In-Reply-To: <27FF4FAEA8CDD211B97E00902745CBE2B4149C@seine.valicert.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Ambrish: Are you suggesting that the replying party should blindly accept any certificate that contains this flag? Or, are you suggesting that the flag indicates that no revocation information is available for the certificate? Russ At 09:26 PM 06/20/2000 -0700, Ambarish Malpani wrote: >I was recently having a conversation with a collegue and he >asked a question. Here goes: > >In OCSP, we have support the concept of a CA issuing a special >certificate to an OCSP responder, allowing it to respond on its >[the CA's] behalf with a special extended key usage flag. > >We also allow the CA to indicate that the responder's cert does >not need to be validated by having it include the >id-pkix-ocsp-nocheck extension in the responder's certificate. > >Why can't the concept of including an id-pkix-ocsp-nocheck >extension in a certificate be extended to any arbitrary certificate >to indicate that it doesn't need to be validated? > >If this makes sense, should this capability be specified in >son-of-rfc2459? > >Comments? > >Ambarish > > >--------------------------------------------------------------------- >Ambarish Malpani >Architect 650.567.5457 >ValiCert, Inc. ambarish@valicert.com >339 N. Bernardo Ave. http://www.valicert.com >Mountain View, CA 94043 From owner-ietf-pkix@imc.org Fri Jun 23 13:39:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16035 for ; Fri, 23 Jun 2000 13:39:37 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA24828; Fri, 23 Jun 2000 10:37:05 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 10:36:59 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24798 for ; Fri, 23 Jun 2000 10:36:58 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FWM00801BM6CR@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 23 Jun 2000 10:37:18 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FWM007COBM5TP@ext-mail.valicert.com>; Fri, 23 Jun 2000 10:37:17 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 10:30:39 -0700 Content-return: allowed Date: Fri, 23 Jun 2000 10:30:30 -0700 From: Ambarish Malpani Subject: RE: Generalizing the concept of id-pkix-ocsp-nocheck To: "'Russ Housley'" Cc: ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE2B414CF@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I am suggesting that a CA does not require you to do a revocation check on that certificate. The reason a CA might want to do this is: a. The CA has rules which say that the guarantees associated with such certificates are more limited (e.g. utility certs in Identrus). b. The CA "knows" that the cert will never be revoked [because the CA controls that key with exactly the same care with which its root key is protected]. c. The CA is trying to protect from infinite recursion [e.g. the OCSP responder cert or maybe its indirect CRL signing cert]. Do we need to distinguish between a and b? Or should the CA do that in its policies? Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Russ Housley [mailto:housley@spyrus.com] > Sent: Thursday, June 22, 2000 1:45 PM > To: Ambarish Malpani > Cc: ietf-pkix@imc.org > Subject: Re: Generalizing the concept of id-pkix-ocsp-nocheck > > > Ambrish: > > Are you suggesting that the replying party should blindly accept any > certificate that contains this flag? Or, are you suggesting > that the flag > indicates that no revocation information is available for the > certificate? > > Russ > > > At 09:26 PM 06/20/2000 -0700, Ambarish Malpani wrote: > > >I was recently having a conversation with a collegue and he > >asked a question. Here goes: > > > >In OCSP, we have support the concept of a CA issuing a special > >certificate to an OCSP responder, allowing it to respond on its > >[the CA's] behalf with a special extended key usage flag. > > > >We also allow the CA to indicate that the responder's cert does > >not need to be validated by having it include the > >id-pkix-ocsp-nocheck extension in the responder's certificate. > > > >Why can't the concept of including an id-pkix-ocsp-nocheck > >extension in a certificate be extended to any arbitrary certificate > >to indicate that it doesn't need to be validated? > > > >If this makes sense, should this capability be specified in > >son-of-rfc2459? > > > >Comments? > > > >Ambarish > > > > > >--------------------------------------------------------------------- > >Ambarish Malpani > >Architect 650.567.5457 > >ValiCert, Inc. ambarish@valicert.com > >339 N. Bernardo Ave. http://www.valicert.com > >Mountain View, CA 94043 > From owner-ietf-pkix@imc.org Fri Jun 23 14:34:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16989 for ; Fri, 23 Jun 2000 14:34:01 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA25892; Fri, 23 Jun 2000 11:30:08 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 11:30:03 -0700 Received: from mail.moh.hnet.bc.ca (mail.moh.hnet.bc.ca [142.36.56.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25861 for ; Fri, 23 Jun 2000 11:30:02 -0700 (PDT) Received: from moh.hnet.bc.ca ([142.36.11.183]) by mail.moh.hnet.bc.ca (Netscape Messaging Server 3.61) with ESMTP id AAA60A3 for ; Fri, 23 Jun 2000 11:30:11 -0700 Message-ID: <3953ACBD.E4F94255@moh.hnet.bc.ca> Date: Fri, 23 Jun 2000 11:30:21 -0700 From: "Doug M Williscroft" X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Trading Partner Web Certificates Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit This note is to elicit feedback on a PKI model that my organization has implemented for web delivery/collection of information. We call it the "trading partner certificate" model. The trading partner certificate model does not attempt to provide the full benefits of the grand PKI vision but limits itself to browser-based extranets. The solution we have adopted is rather simple but - due to limitations of existing technology - not especially elegant. Even so, we believe it to provide significant authentication benefit at at significantly lower cost than other alternatives. At the end of this note I describe a desirable new function for certificate management (at the browser and/or OS) that would provide broad benefit for extranet applications under this model. I believe this additional functionality would be relatively easy to develop, and would quite possibly find a large market. Our model: 1) Establish a trading agreement with an organization through standard business processes which include contractual definition of obligaitions. 2) Issue a trading partner certificate to the organization. (In our current case the certificates are "anonymous"; they make no statement about the trading partner. This is not a necessary component of the model. Neither is it necessary that we be the certificate issuer.) 3) The trading partner installs the certificate and private key on all browsers that will be used to access our services. (Most of our trading partners use the IE5 browser which allows the private key to be flagged as "not exportable" from the computer - a highly desirable feature in our from our perspective.) 4) The trading partner registers its users in our extranet directory - and assumes responsibility for managing those users - including assignment of access permissions within the bounds of the trading partner agreement. (At this point user administration requires some intervention on our part - we anticipate fully externalized user management in the future.) 5) Users connecting to our web servers are challenged (via SSL) to provide a client certificate. 6) Users presenting a valid trading partner certificate are challenged for UserID and Password. 7) Users presenting a valid password and the correct trading partner certificate for that user's organization are granted access to the appropriate services. To impersonate a user an attacker must gain direct access to a computer in the trading partner organization, and gain knowledge of a valid userID and password pair. We see this 2-factor mechanism as offering protection against password discovery (by attackers external to the trading partner organization), and against man-in-the-middle attacks based on URL hijacking or DNS poisoning. Desirable new certificate management functionality: It would be helpful to our trading partners if certificates/private keys could be centrally distributed en-masse to all computers/user profiles in a trading partner organization. Currently, our trading partners must manually install the private key to each user login account that will use our services - a tedious activity. This task must be repeated prior to certificate expiry. Fortunately our trading partners are willing to accept this administrative burden because they consider the services we offer sufficiently valuable. Comments? -- Doug Williscroft HealthNet/BC Architecture and Standards Branch Ministry of Health Information Management Group Telephone: (250) 952-2497 _______________________________________________ From owner-ietf-pkix@imc.org Fri Jun 23 15:37:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18145 for ; Fri, 23 Jun 2000 15:37:37 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA00635; Fri, 23 Jun 2000 12:30:18 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 12:30:10 -0700 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00604 for ; Fri, 23 Jun 2000 12:30:09 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA26578; Fri, 23 Jun 2000 12:31:07 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 12:29:53 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EB77@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Frederik Loeckx'" , ietf-pkix@imc.org Subject: RE: Allow RSA mandatory after September 20, 2000 ? Date: Fri, 23 Jun 2000 12:29:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0025_01BFDD28.07BA6670"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_0025_01BFDD28.07BA6670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Even further, why wait till September 30? The patent sunset is sufficiently close and the deployment of RSA sufficiently widespread that the IESG is not likely to influence the situation much. I strongly suspect that MOST implementations of S/MIME will ignore the mandatory support for D-H. The IESG can issue Canute like demands but the tide of deployed clients will not head them any more than the sea did the King. We all know that after Sept 30 the IESG won't have any rational argument for not recognising that support for RSA is necessary for S/MIME interoperability and support for DH is not. It does not take a game theorist to determine that the IESG has no negotiating strength in such a situation. Coupled with the various pieces of mud bubbling to the surface of the swamp with various obscure D-H related claims emerging, the IP story on D-H is likely to be worse than that on RSA after Sept 30. Phill -----Original Message----- From: Frederik Loeckx [mailto:frederik.loeckx@utimaco.be] Sent: Friday, June 23, 2000 7:46 AM To: ietf-pkix@imc.org Subject: Re: Allow RSA mandatory after September 20, 2000 ? Even further, the question could be raised if DSA and Diffie Hellman need to be marked as mandatory if RSA is already marked as mandatory. When RSA is already present as a common algorithm, there is not need for DSA, DH to be mandated. The standards will more reflect the actual marketplace, when DSA and Diffie Hellman are considered as optional. Frederik Denis Pinkas on 23/06/2000 10:09:14 To: IETF-PXIX cc: (bcc: Frederik Loeckx/Utimaco/BE) Subject: Allow RSA mandatory after September 20, 2000 ? Up to now, the IETF WGs and the IESG have mandated the DSA and Diffie-Hellman algorithms only, since the RSA algorithm was patented. On September 20, 2000 the RSA patent will expire, so this allows the IESG to reconsider the issue. I would like the co-chairs to raise this issue to the IESG, so that for any Standard (not Proposed Standard) issued after September 20, 2000, we can, if this is a WG decision, mandate the RSA algorithm. Denis ------=_NextPart_000_0025_01BFDD28.07BA6670 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyMzE5MzA1OFowIwYJKoZI hvcNAQkEMRYEFK4WJnQy1u5i55nq3OIhKoie++3JMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAI9LpyEQKTpP6/JI43UOI0zLkYqq9nf85Den7+h3Irf22L7FpxeEQmdpza8w/Surs 6mA59CsLUHMq63n4pP7miQLxDbl+tSeQy4a0IwQzW6uuycopvvLaDKIt7l+ONPdGmv5xp2PWCGnE wxqHxZrB+iKWwkx834bfns4I4JQ07/AAAAAAAAA= ------=_NextPart_000_0025_01BFDD28.07BA6670-- From owner-ietf-pkix@imc.org Fri Jun 23 16:08:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18594 for ; Fri, 23 Jun 2000 16:08:17 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA01322; Fri, 23 Jun 2000 13:06:46 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 13:06:44 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01292 for ; Fri, 23 Jun 2000 13:06:43 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA01892; Fri, 23 Jun 2000 16:06:55 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 23 Jun 2000 15:58:35 -0400 To: "Bob Jueneman" From: Stephen Kent Subject: Re: Can we form certificates with just name and e-mail address Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Bob, >Steve/Clark :-), (hey, don't blow my cover ...) > > >>But presumably there would only be one > >{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="kent@bbn.com" > > >True. If the intent were to create multiple leaf entries below the >single entry of this form then the justification would be better, >but I don't that's what people have been suggesting. >It's not that I particularly like compound attributes, but that's what >I was suggesting, rather than having the rfc822 be a leaf under the user name >DN. That's what I mean to imply by the plus sign -- exactly like most >people have been suggesting for name+serial. At least the rfc822 name >component has a great semantic content than a serial number. Yes. But, what people were suggesting was a DN with ONLY a given name and surname, plus an e-mail address. That's a bit odd from a directory structure perspective. Obviously we would not use the first two components as RDNs under a root, since there would be no good way to separate the database base for people on a large geographic basis using those attributes. If we used the e-mail address as the first RDN it would allow for meaningful partitioning, but because the address is a composite value, it seems wrong too. It would be more appropriate to use the DC attribute to mimic the DNS structure, then put the user name as the leaf RDN. In that case, though, the given name and surname are redundant, right? Steve From owner-ietf-pkix@imc.org Fri Jun 23 16:26:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18814 for ; Fri, 23 Jun 2000 16:26:47 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA05075; Fri, 23 Jun 2000 13:25:22 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 13:25:20 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05045 for ; Fri, 23 Jun 2000 13:25:20 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FWM00901JETII@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 23 Jun 2000 13:25:41 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FWM008O1JETLW@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 23 Jun 2000 13:25:41 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 13:19:02 -0700 Content-return: allowed Date: Fri, 23 Jun 2000 13:18:53 -0700 From: Frank Balluffi Subject: RFC 2459: Use of Key Identifiers During Path Validation To: "'ietf-pkix@imc.org'" Message-id: <27FF4FAEA8CDD211B97E00902745CBE2E08BA9@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Based on my reading of section 6.1 of RFC 2459 there is no need to check that key identifiers chain properly during path validation. Is this true? Frank From owner-ietf-pkix@imc.org Fri Jun 23 16:27:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18836 for ; Fri, 23 Jun 2000 16:27:11 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA04789; Fri, 23 Jun 2000 13:19:26 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 13:19:23 -0700 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04759 for ; Fri, 23 Jun 2000 13:19:22 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA27872 for ; Fri, 23 Jun 2000 13:19:51 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 13:18:37 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EB78@vhqpostal.verisign.com> From: Philip Hallam-Baker To: PKIX Mailing List Subject: RE: Do people have something against RSA? Date: Fri, 23 Jun 2000 13:18:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_002D_01BFDD2E.D7428C00"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_002D_01BFDD2E.D7428C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Summary: Unless we modify the drafts to rip out the mandatory DH but optional RSA the PKIX and SMIME specs will inevitably end up being recycled at DRAFT stage since otherwise our spec will not correspond to reality. While we are at it a good purge of all lossage related to 40bit ciphers is needed. On the patent issue, yes I do begrudge folk a return on their IP. I have yet to see anyone go out and hand me (or CERN) a cheque for the IP we put in the public domain. The fact is that in most cases a patent is the kiss of death as far as I am concerned. If you patent something it means that I have to talk to our lawyers if I want to use it in a design. It is usually easier to work out another way to do the same thing - as some folk on this list have discovered. I don't have a problem in the case that someone genuinely invented something worthwhile. In most cases however I'm reading claims written by some weasel that developed a better mousetrap and is claiming the idea of catching all forms of vermin for purposes of disposal (excluding weasels). When I was at MIT one of the Profs made certain patent claims which had they been made in an academic paper would have been considered plagarism. I have noted a distinct decline in said profs patent prolixity since I made my position clear (and no it isn't anyone the folk in this group is likely to know - unless they spend time reading bogus patent claims). The fact that DH expired two years ago and will not expire till the end of the month after the next IETF does not appear to me to be a sufficient reason to absolutely reject RSA until the second hand reaches the top of the hour ushering in October 1. When the argument is that we all need one default algorithm to permit interoperation it aoccurs to me that ignoring the 100 odd million installations already shipped is ridiculous. They do RSA, they don't do DH, it will be five years at least before that installed base will cease to be a constraint - end of story. Phill ------=_NextPart_000_002D_01BFDD2E.D7428C00 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyMzIwMTk0M1owIwYJKoZI hvcNAQkEMRYEFH+Sm18nCSnNakQInZxMol59578mMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAKZxDHtrhgk83JApyx50nwLVZAwLPY0IYTCB2mxuPdxpT4SCtvpxDSDVcLLHKdx1S tW6Mp8UTqXumVpEzs7fgmvaqyZ1d7PuAvlpildU8TgB9OdfxkyhHBuIZft3/mZhNjS62G6TkJ41B EakEEiveuA1BmCcVXdz8dnCq2lgnqU8AAAAAAAA= ------=_NextPart_000_002D_01BFDD2E.D7428C00-- From owner-ietf-pkix@imc.org Fri Jun 23 16:31:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18981 for ; Fri, 23 Jun 2000 16:31:41 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA05253; Fri, 23 Jun 2000 13:25:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 13:25:51 -0700 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05216; Fri, 23 Jun 2000 13:25:49 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA28112; Fri, 23 Jun 2000 13:26:24 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 13:25:10 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EB79@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Paul Hoffman / IMC'" , Bob Jueneman , ietf-pkix@imc.org Subject: RE: Do people have something against RSA? Date: Fri, 23 Jun 2000 13:25:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0032_01BFDD2F.C163D550"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_0032_01BFDD2F.C163D550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >OpenPGP *is* and IETF standard. It has the same standards level as >S/MIME and PKIX does. You may not use it, and your company may not >sell it, but please stop pretending it is not an IETF standard. Paul as a matter of FACT, PGP is NOT an IETF standard. There are in fact practically no IETF standards. IP and TCP being some of the few exceptions. SMTP is a standard but HTTP still is not. PGP is currently a proposed standard. Recognition as an actual standard is far from certain and depends in part upon market acceptance. The status of market acceptance of PGP and PKIX is NOT equivalent in any degree. In addition X.509v3 of which PKIX is a profile IS a standard recognised by the International Standards Organization. It is thus not a 'pretense' to claim PGP is not an IETF standard. X.509v3 is however a longstanding ISO standard that the IETF has already incorporated into widely deployed standards proposals. Phill ------=_NextPart_000_0032_01BFDD2F.C163D550 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyMzIwMjYxNlowIwYJKoZI hvcNAQkEMRYEFHrpdZOO+nm6oP1K1A5Ux9FzGoUFMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAtUdabFDLOo62qvQ8jes0neFMY7goxEOKR3mDrS6jEXYzx8gl7VYLeMd7BRhhraah luXD59P6IyDV8yKZc/FYExwOSyn6Id6TfY2HASP9CfKZ169dxyqT6XuOYvrnn7E92iqQ1PIrgZgq o9hzcqTPauCpmodfMpyjfXgXfMbY55IAAAAAAAA= ------=_NextPart_000_0032_01BFDD2F.C163D550-- From owner-ietf-pkix@imc.org Fri Jun 23 17:13:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19411 for ; Fri, 23 Jun 2000 17:12:59 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA05979; Fri, 23 Jun 2000 14:11:40 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 14:11:34 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05949 for ; Fri, 23 Jun 2000 14:11:33 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA09861; Fri, 23 Jun 2000 17:06:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3952BC34.498B6D2E@caveosystems.com> References: <3952BC34.498B6D2E@caveosystems.com> Date: Fri, 23 Jun 2000 17:04:53 -0400 To: Rich Salz From: Stephen Kent Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Cc: PKIX Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Rich, > > >Stephen Kent: > > I've always asserted that self-signed certs are just a syntactic > > convenience, not a generally useful way of ensuring security for > > transmitted public keys. If we agree on that point, then I don't see > > a lot of reason to push for self-signed TSA certs. > >I don't agree. As the service provider, why do I *have* to deal with >the management of two private keys. It's way more than syntax. > >We don't need to "push" anything. We need to not prohibit it. You don't agree with what, the assertion about syntactic convenience? I don't think it's much easier to manage one private key vs. two when you have to distribute one key visa OOB means in either case. It is a lot cleaner, and it provides a straightforward revocation mechanism for the TSA key, even allowing delegation to an OCSP server without further violating the notion of what a TSA should be used to sign. Steve From owner-ietf-pkix@imc.org Fri Jun 23 17:46:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20047 for ; Fri, 23 Jun 2000 17:46:43 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA06508; Fri, 23 Jun 2000 14:33:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 14:33:33 -0700 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06477 for ; Fri, 23 Jun 2000 14:33:31 -0700 (PDT) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A7AB19D0128; Fri, 23 Jun 2000 23:33:31 +0200 Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Fr, 23 Jun 2000 23:34:23 +0100 From: "Peter Lipp" To: "Michael Zolotarev" , Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Fri, 23 Jun 2000 23:34:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.8A03CDEB--"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.8A03CDEB-- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I guess the problem is a common misconception that a TSA is always a > subsidiary/sub-service of a CA. Not necessary. TSA is/can_be a service on > its own, with no inherited relationship to any CA at all. Sure it can. But I bet it still will have certificates from some CA (more than one maybe) that trust the TSA for doing their service properly. Do you really believe the average user will and can go and check for each and every service provider if it should be trusted? If he at some point really consiously decided to trust a certain CA, it will be close to a miracle. Most will accept somebody elses decisions, maybe preconfigured by the vendor, and if the SW asks: should I trust, he will hit the "never ask me that question again" button.... Peter ----IAIK.SMIME.MAPPER.8A03CDEB-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC 2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9 ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy 2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE 6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx 2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7 rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8 lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3 DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI 7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG 9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6 Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25 sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9 l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q 19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6 ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1 OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B 2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1 2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64 vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMDA2MjMyMTM0MjNaMCMGCSqGSIb3DQEJBDEWBBRxCE72xr47V3Mr SVFLlPFfOZikgzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN BgkqhkiG9w0BAQEFAASBgMiIJYnloS3RWMW4oAn/jeFn8V6nVPjyWfgnSWnK2ko8 D1cqCS31beJePiEa+7eFjgaz/luEEngzEHWmOIZLwg/fg9JQPUuWx2tDByoyp6IE qdolRWRFIja4CYOToMUGmoXv1UqO5Lv8qa7M5bVS+JhMFyQvNwCoSrLWJwL87AgN AAAAAAAA ----IAIK.SMIME.MAPPER.8A03CDEB---- From owner-ietf-pkix@imc.org Sat Jun 24 00:16:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27527 for ; Sat, 24 Jun 2000 00:16:34 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA24695; Fri, 23 Jun 2000 21:14:37 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 21:13:32 -0700 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24639 for ; Fri, 23 Jun 2000 21:13:32 -0700 (PDT) Received: from [209.77.88.197] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWN009HJ50LC2@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Fri, 23 Jun 2000 21:12:22 -0700 (PDT) Date: Fri, 23 Jun 2000 21:12:33 -0700 From: Aram Perez Subject: Re: Allow RSA mandatory after September 20, 2000 ? In-reply-to: <39531B2A.56B1643F@bull.net> To: IETF-PXIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi Denis, > Up to now, the IETF WGs and the IESG have mandated the DSA and > Diffie-Hellman algorithms only, since the RSA algorithm was > patented. On September 20, 2000 the RSA patent will expire, so this > allows the IESG to reconsider the issue. > > I would like the co-chairs to raise this issue to the IESG, so that > for any Standard (not Proposed Standard) issued after September 20, > 2000, we can, if this is a WG decision, mandate the RSA algorithm. Great suggestion! I fully support this request. Regards, Aram Perez From owner-ietf-pkix@imc.org Sat Jun 24 00:18:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27538 for ; Sat, 24 Jun 2000 00:18:50 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA24699; Fri, 23 Jun 2000 21:14:38 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 23 Jun 2000 21:13:31 -0700 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24627 for ; Fri, 23 Jun 2000 21:13:31 -0700 (PDT) Received: from [209.77.88.197] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWN009HJ50LC2@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Fri, 23 Jun 2000 21:12:23 -0700 (PDT) Date: Fri, 23 Jun 2000 21:12:36 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi Michael, If I take your statements/conclusions below to their extreme, then anytime PKIX comes up with a new service that uses digital signatures, that service would have to issue its own self-signed certificates. I don't see the OCSP folks requesting their own self-signed certificates. Regards, Aram Perez >> >> I don't agree. As the service provider, why do I *have* to deal with >> the management of two private keys. It's way more than syntax. >> >> We don't need to "push" anything. We need to not prohibit it. >> /r$ >> > > I fully agree with that. > > Guys, > > << I feel that I've said all I had to say on the subject. In this mail I'll > try to put together a little summary of my position, which I know is > supported by a number of the list members. It was taking too much and too > long - this message will be the last from me on self-signed TSA certs (do I > see happy smiles :)? Denis, it is really up to you now - put it on vote, or > forget. >> > > I (quite frankly) fail to understand the rational for the draft to introduce > limitations which necessitate extra entities and potentially more complex > environment for all involved parties. All for a sake of extra purity of a > concept, which is already pure enough. Probably my position is too much > 'engineering', but this is what I am, sorry. > > An example first: > Imagine some Business_Domain_Managing_Authority (BDMA) that wants to deploy > a TSA service for its members. Would it be Ok that the members express their > trust directly to the TSA? I guess so. > > With the client's trust expressed directly to the TSA cert, it is irrelevant > if the TSA cert was self-signed or CA-signed. Referring to the arguments in > favor of signing by CA - yes, I agree that there are benefits, thank you. It > is all perfect with the assumption that there IS a CA around, or at least a > business has a need for a CA. > > Now, can anybody explain the BDMA's manager (a stubborn and slow guy he is > indeed :) why the organisation has to buy/setup/employ a CA, if everything > that they will ever need is just a TSA? > > << I know that the previous sentence may get me sacked from Baltimore, which > main business is selling CAs. :) So the standard disclaimer is right here. >>> > > Mind you, out-of-band TSA cert delivery is as complex, or as simple, as the > one for distributing a CA's cert, should it exist. > > As a conclusion: > Using self-signed TSA certs should be an internal matter for each domain, > each TSA, subject to specific policy and national regulations. And a hell > lot more. Therefore, the draft should not encourage self-signed TSA certs, > neither it should prohibit them. It should be neutral and stay away from > that slippery subject. > > And it is not far from what the current draft is about, as it seems. > > A minor fix- a sentence for the security considerations section would be > something like: > "The TSA private key must be generated and used ONLY for signing timestamps, > and possibly for internal key/certificate management operations such as > P-O-P or self-signing." > > Best regards > Michael > From owner-ietf-pkix@imc.org Sat Jun 24 06:14:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11303 for ; Sat, 24 Jun 2000 06:14:16 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA11385; Sat, 24 Jun 2000 03:13:12 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 24 Jun 2000 03:12:48 -0700 Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11343 for ; Sat, 24 Jun 2000 03:12:45 -0700 (PDT) Received: from arabtrust [195.39.129.32] by mail.arabtrust.com (SMTPD32-6.00) id AA207B200A8; Sat, 24 Jun 2000 06:14:56 -0400 From: "Jean Abraham" To: Subject: digital certificate supports? Date: Sat, 24 Jun 2000 13:11:51 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi, What are the applications that does or does not support more than 4 hierachies in a digital certificate. Jean From owner-ietf-pkix@imc.org Sat Jun 24 06:41:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11404 for ; Sat, 24 Jun 2000 06:41:51 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA14958; Sat, 24 Jun 2000 03:40:31 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 24 Jun 2000 03:40:29 -0700 Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA14928 for ; Sat, 24 Jun 2000 03:40:28 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 0313444; Sat, 24 Jun 2000 06:40:39 -0400 (EDT) Message-ID: <3954903D.57F4EA14@caveosystems.com> Date: Sat, 24 Jun 2000 06:41:01 -0400 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aram Perez CC: PKIX Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > If I take your statements/conclusions below to their extreme, then anytime > PKIX comes up with a new service that uses digital signatures, that service > would have to issue its own self-signed certificates. I don't see the OCSP > folks requesting their own self-signed certificates. Not HAVE TO issue, but COULD issue. Most definitely. From owner-ietf-pkix@imc.org Sat Jun 24 07:50:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11759 for ; Sat, 24 Jun 2000 07:50:47 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA17168; Sat, 24 Jun 2000 04:41:37 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 24 Jun 2000 04:40:06 -0700 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA17128 for ; Sat, 24 Jun 2000 04:40:04 -0700 (PDT) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AE2412C20058; Sat, 24 Jun 2000 13:40:20 +0200 Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Sa, 24 Jun 2000 13:41:13 +0100 From: "Peter Lipp" To: "Rich Salz" , "Aram Perez" Cc: "PKIX" Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Sat, 24 Jun 2000 13:41:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.261C1BF8--"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <3954903D.57F4EA14@caveosystems.com> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.261C1BF8-- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > > If I take your statements/conclusions below to their extreme, > then anytime > > PKIX comes up with a new service that uses digital signatures, > that service > > would have to issue its own self-signed certificates. I don't > see the OCSP > > folks requesting their own self-signed certificates. > > Not HAVE TO issue, but COULD issue. Most definitely. Yes. And I could also issue my self-signed certificate, and you would have less problems trusting me because you would not need to bother with the obscure cert I might have from some CA service. Welcome to the PGP-model! Peter ----IAIK.SMIME.MAPPER.261C1BF8-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC 2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9 ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy 2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE 6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx 2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7 rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8 lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3 DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI 7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG 9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6 Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25 sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9 l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q 19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6 ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1 OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B 2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1 2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64 vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMDA2MjQxMTQxMTNaMCMGCSqGSIb3DQEJBDEWBBQFNfktWnD8i08a B+mSnLCEDIV/FjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN BgkqhkiG9w0BAQEFAASBgBmxRfjyDq5HaNk7ibRjoba4TjIS1kwNXRCz/KmH2N70 by7SWB7gWcE9KSn+HYhQqnAk6sRwKjrNNmTXRweHc1SJmP5Hc12u5nbO7KGuX9Su qryyJ7QLcV3WVRWiSu6e9yJRg5CtZqJE06H5/ZFnggRaLHz8GgDX7yup9luQ0yfi AAAAAAAA ----IAIK.SMIME.MAPPER.261C1BF8---- From owner-ietf-pkix@imc.org Sat Jun 24 17:39:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15548 for ; Sat, 24 Jun 2000 17:39:00 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA03972; Sat, 24 Jun 2000 14:37:46 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 24 Jun 2000 14:37:19 -0700 Received: from imo-r16.mx.aol.com (imo-r16.mx.aol.com [152.163.225.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03939 for ; Sat, 24 Jun 2000 14:37:18 -0700 (PDT) From: Scruggs01@aol.com Received: from Scruggs01@aol.com by imo-r16.mx.aol.com (mail_out_v27.10.) id h.db.5eb4e6e (4247); Sat, 24 Jun 2000 17:37:11 -0400 (EDT) Message-ID: Date: Sat, 24 Jun 2000 17:37:11 EDT Subject: Re: certification for pki To: jean.med@arabtrust.com, ietf-pkix@imc.org CC: cscruggs@kpmg.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 109 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Jean, There is a process called WebTrust that is endorsed by the American Institute of Certified Public Accountants (AICPA) and the Canadian Institute of Chartered Accountants (CICA). WebTrust offers several models of audit and certification guidance including one for Certificate Authorities (WebTrust Principles and Criteria for Certificate Authorities). While this process does not currently have "international" acceptance, many past AICPA standards have gained that stature. If you would like additional information, please go to: http://www.cpawebtrust.org. Charlie From owner-ietf-pkix@imc.org Sun Jun 25 01:37:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24854 for ; Sun, 25 Jun 2000 01:37:38 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA19480; Sat, 24 Jun 2000 22:35:57 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sat, 24 Jun 2000 22:35:09 -0700 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA19446 for ; Sat, 24 Jun 2000 22:35:07 -0700 (PDT) Received: from [207.215.86.189] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWP00HJQ3G2BY@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Sat, 24 Jun 2000 22:33:39 -0700 (PDT) Date: Sat, 24 Jun 2000 22:34:32 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <3954903D.57F4EA14@caveosystems.com> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Rish Salz wrote: >> If I take your statements/conclusions below to their extreme, then anytime >> PKIX comes up with a new service that uses digital signatures, that service >> would have to issue its own self-signed certificates. I don't see the OCSP >> folks requesting their own self-signed certificates. > > Not HAVE TO issue, but COULD issue. Most definitely. So you want any user of a PKIX service to have to figure out a OOB mechanism for each provider of the service to verify the self-signed certificate? Regards, Aram Perez From owner-ietf-pkix@imc.org Sun Jun 25 14:59:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09754 for ; Sun, 25 Jun 2000 14:59:08 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA13797; Sun, 25 Jun 2000 11:57:41 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 25 Jun 2000 11:57:21 -0700 Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA13765 for ; Sun, 25 Jun 2000 11:57:20 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 08688107; Sun, 25 Jun 2000 14:57:45 -0400 (EDT) Message-ID: <39565606.3DB590E2@caveosystems.com> Date: Sun, 25 Jun 2000 14:57:10 -0400 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aram Perez CC: PKIX Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > So you want any user of a PKIX service to have to figure out a OOB mechanism > for each provider of the service to verify the self-signed certificate? Not at all. I want it to be *possible* to start an independant PKIX service. Let me turn the question around: why do you feel it necessary to force me to run a CA? /r$ From owner-ietf-pkix@imc.org Sun Jun 25 19:48:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10944 for ; Sun, 25 Jun 2000 19:48:11 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA16045; Sun, 25 Jun 2000 16:45:30 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 25 Jun 2000 16:45:17 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16013 for ; Sun, 25 Jun 2000 16:45:14 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA06200; Mon, 26 Jun 2000 09:50:47 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Mon, 26 Jun 2000 09:44:25 +1000 Message-ID: From: Michael Zolotarev To: Peter Lipp , Rich Salz , Aram Perez Cc: PKIX Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Mon, 26 Jun 2000 09:44:19 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe It is not a PGP-model. I register my direct trust a self-signed CA certificate - is it PGP? Of course not. So why are you saying that trusting to a self-signed TSA certificate is PGP? Are we trying to limit issuing self-signed certificates to CA only, PKI-wide? The same arguments apply to any non-CA service, such as Attribute Authority, don't they? > -----Original Message----- > From: Peter Lipp [mailto:Peter.Lipp@iaik.at] > Sent: Saturday, June 24, 2000 9:41 PM > To: Rich Salz; Aram Perez > Cc: PKIX > Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning] > > > > > If I take your statements/conclusions below to their extreme, > > then anytime > > > PKIX comes up with a new service that uses digital signatures, > > that service > > > would have to issue its own self-signed certificates. I don't > > see the OCSP > > > folks requesting their own self-signed certificates. > > > > Not HAVE TO issue, but COULD issue. Most definitely. > > Yes. And I could also issue my self-signed certificate, and > you would have > less problems trusting me because you would not need to > bother with the > obscure cert I might have from some CA service. Welcome to > the PGP-model! > > Peter > > > From owner-ietf-pkix@imc.org Mon Jun 26 02:04:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26878 for ; Mon, 26 Jun 2000 02:04:47 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA25955; Sun, 25 Jun 2000 23:03:20 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 25 Jun 2000 23:02:39 -0700 Received: from hitpro.hitachi.co.jp (root@hitpro.hitachi.co.jp [133.145.224.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA25896 for ; Sun, 25 Jun 2000 23:02:38 -0700 (PDT) Received: from bisdgw.bisd.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id PAA12186; Mon, 26 Jun 2000 15:02:36 +0900 (JST) Received: from bisdmail.bisd.hitachi.co.jp by bisdgw.bisd.hitachi.co.jp (8.9.3+3.2W/3.7W-bisdgw) with ESMTP id PAA03481 for ; Mon, 26 Jun 2000 15:02:36 +0900 (JST) (envelope-from kawatura@bisd.hitachi.co.jp) Received: from localhost by bisdmail.bisd.hitachi.co.jp (8.9.3/3.7W-bisdmail) with ESMTP id PAA05432; Mon, 26 Jun 2000 15:02:35 +0900 (JST) (envelope-from kawatura@bisd.hitachi.co.jp) To: ietf-pkix@imc.org Cc: kawatura@bisd.hitachi.co.jp Subject: Unique identifiers for certificate. From: Yoshiaki KAWATSURA In-Reply-To: <85256905.0066D323.00@csc.com> References: <85256905.0066D323.00@csc.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000626150211O.kawatura@bisd.hitachi.co.jp> Date: Mon, 26 Jun 2000 15:02:11 +0900 (JST) X-Dispatcher: imput version 990905(IM130) Lines: 17 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hello, I have a question of unique identifiers for certificate. Is there any general guideline which describes which unambiguous identifiers for certificate should be used? For example, a combination of Issuer Name and Certificate Serial Number is used as the identifier for the actual public key to verify the signature in PKCS#7. Additinally, a combination of issuer name, subject name and subject key identifier is also used (this is described in draft-ietf-pkix-technr-00.txt.) Thanks, ---- Yoshiaki Kawatsura : E-mail kawatura@bisd.hitachi.co.jp Business Solution Systems Development Division, Hitachi,Ltd. Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721 From owner-ietf-pkix@imc.org Mon Jun 26 02:15:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27264 for ; Mon, 26 Jun 2000 02:15:38 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA26495; Sun, 25 Jun 2000 23:13:03 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Sun, 25 Jun 2000 23:13:01 -0700 Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA26461; Sun, 25 Jun 2000 23:12:59 -0700 (PDT) Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id HAA21923; Mon, 26 Jun 2000 07:16:40 +0100 Message-ID: <3956F4BF.AF5170D7@algroup.co.uk> Date: Mon, 26 Jun 2000 07:14:23 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: Bob Jueneman CC: ietf-pkix@imc.org, phoffman@imc.org Subject: Re: Do people have something against RSA? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Bob Jueneman wrote: > Sounds great, at least to the young and naive (as most of us were at one time). > Unfortunately, although the Soviets tried this system for 80 years, and the Cubans, > North Koreans, and some other societies are still trying it, the jury has come back with > a verdict. Except in some closed societies, normally religious orders, this system > simply does not work, and can only be sustained through a very harsh and cruel > dictatorship. Those who have talent either opt out or become the bosses, leaving > those who cannot to fend for themselves. > > If inventors cannot be rewarded for the fruits of their labors, then the entire structure > of capitalism is without a foundation, and all of the IPOs and stock market gains > are merely the Tulip Bulb mania repeating itself all over again. > > Unfortunately, it has gotten to the point that filing for an invention has become > the kiss of death within the IETF. No matter how good the idea is, if you patent it > the IETF will go out of their way to make sure that it isn't standardized. a) Are you aware of the IETF rules regarding patented stuff in standards? b) Why do you think that patents are the only way to be rewarded for inventing things? > The inevitable result of this is that either (1) companies will stop inventing things, > since they won't be rewarded for them, or (2) companies will drop out of the IETF > process, and ignore the standards as either irrelevant or explicitly contrary to their > business interests. Is that what we want to have happen? The problem with this "prediction" is that although its premise is demonstrably correct, the consequence hasn't occurred. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ From owner-ietf-pkix@imc.org Mon Jun 26 04:16:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28254 for ; Mon, 26 Jun 2000 04:16:28 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA29190; Mon, 26 Jun 2000 01:08:14 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 26 Jun 2000 01:08:04 -0700 Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA29159 for ; Mon, 26 Jun 2000 01:08:02 -0700 (PDT) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AF7AFE0150; Mon, 26 Jun 2000 10:08:26 +0200 Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Mo, 26 Jun 2000 10:09:19 +0100 From: "Peter Lipp" To: "Michael Zolotarev" Cc: "PKIX" Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Mon, 26 Jun 2000 10:09:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.A287CEE0--"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.A287CEE0-- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It is not a PGP-model. I register my direct trust a self-signed CA > certificate - is it PGP? Of course not. So why are you saying > that trusting to a self-signed TSA certificate is PGP? Because if every PKI-service (TSA, OCSP, SCVP, ...) signs their own certificate, and if I have to verify trust into each and every one of them separately, and that smells PGPish and not PKIXish. Strictly speaking it is not PGP, but if I extrapolate and allow you to register your direct trust into my personal self signed CA certificate, we are very close to PGP, aren't we? And I don't care about the data formats here... Peter ----IAIK.SMIME.MAPPER.A287CEE0-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC 2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9 ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy 2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE 6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx 2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7 rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8 lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3 DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI 7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG 9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6 Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25 sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9 l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q 19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6 ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1 OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B 2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1 2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64 vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMDA2MjYwODA5MTlaMCMGCSqGSIb3DQEJBDEWBBTlQN4ObuKIfPpb UO7tN+O9ifAJpTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN BgkqhkiG9w0BAQEFAASBgE2PpajNd8YRSpMtKRYFXKNOfbk7zHL00T1uLQ0eEWFa wjMA4DMG7ty54+z3Cx3/8KtohO1F7+Mcxv/6ZC8+zCcw5LBwfq4Y0Tlp7jFtQTTY 9dI241hXRtLfQXzddZTfoWt7E884e41pMeix9yAvgEJ/Ru/XgICdGgZJgBCt5LS+ AAAAAAAA ----IAIK.SMIME.MAPPER.A287CEE0---- From owner-ietf-pkix@imc.org Mon Jun 26 06:48:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29433 for ; Mon, 26 Jun 2000 06:48:56 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA06111; Mon, 26 Jun 2000 03:46:09 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 26 Jun 2000 03:45:59 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06076 for ; Mon, 26 Jun 2000 03:45:58 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29344; Mon, 26 Jun 2000 06:46:31 -0400 (EDT) Message-Id: <200006261046.GAA29344@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-time-stamp-09.txt Date: Mon, 26 Jun 2000 06:46:31 -0400 Sender: nsyracus@cnri.reston.va.us Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) Author(s) : C. Adams, P. Cain, D. Pinkas, R. Zuccherato Filename : draft-ietf-pkix-time-stamp-09.txt Pages : 22 Date : 23-Jun-00 A time stamping service allows to prove that a datum existed before a particular time and can be used by a Trusted Third Party (TTP) as one component in building reliable non-repudiation services (see [ISONR]). This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. An example of how to prove that a digital signature was generated during the validity period of a public key certificate is given in an annex. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-09.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-time-stamp-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-time-stamp-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000623134944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-time-stamp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-time-stamp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000623134944.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@imc.org Mon Jun 26 08:48:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03386 for ; Mon, 26 Jun 2000 08:48:25 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA08858; Mon, 26 Jun 2000 05:45:19 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 26 Jun 2000 05:44:49 -0700 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08820 for ; Mon, 26 Jun 2000 05:44:48 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA254580 for ; Mon, 26 Jun 2000 14:48:43 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA06442 for ; Mon, 26 Jun 2000 14:44:50 +0200 Message-ID: <39575042.6692BACA@bull.net> Date: Mon, 26 Jun 2000 14:44:50 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: IETF-PXIX Subject: TSP-09 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit I took advantage of a pause on the mailing list about TSP, to post a new draft now available at: http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-09.txt The main reason to issue a new draft was to correct the syntax of PKIStatus which was missing one line, i.e. statusString PKIFreeText OPTIONAL, :-( At the same time, the following changes have been made: Turn some "shall" into "SHALL". Modifications to say that a modified Token may be returned when the status is one (grantedWithMods), e.g. when some extensions have been incorporated in a way that is slightly different from the request. The status 6 (KeyUpdateWarning) has been deleted since it bears a different meaning in CMP and cannot be returned in our case. Modification of the sentence about multiple private signature keys in section 2.3. to get the following: "A TSA MAY have distinct private keys, e.g. to accommodate different policies, different algorithms, different private key sizes or to increase the performance." As supported by Steve Kent and some others, the current text to specify that the private key MUST not be used for any other purpose has been maintained. Peter Sylvester noticed that (in version 8) I changed in the module, extensions [0] Extensions OPTIONAL with extensions [0] IMPLICIT Extensions OPTIONAL but I forgot do do it as well in the text. I will fix it. It is now time to send this document to the IESG. There are still opportunities to make minor changes to the document when it becomes a Standard, at least six months after it becomes Proposed Standard. Denis From owner-ietf-pkix@imc.org Mon Jun 26 09:45:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05471 for ; Mon, 26 Jun 2000 09:45:41 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA10092; Mon, 26 Jun 2000 06:43:04 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 26 Jun 2000 06:43:00 -0700 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10060 for ; Mon, 26 Jun 2000 06:42:59 -0700 (PDT) Received: from [207.215.86.188] by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWR00F1NKRYCC@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Mon, 26 Jun 2000 06:43:11 -0700 (PDT) Date: Mon, 26 Jun 2000 06:43:50 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <39565606.3DB590E2@caveosystems.com> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi Rich, >> So you want any user of a PKIX service to have to figure out a OOB mechanism >> for each provider of the service to verify the self-signed certificate? > > Not at all. > > I want it to be *possible* to start an independant PKIX service. > > Let me turn the question around: why do you feel it necessary to force me > to run a CA? I've never stated that I want you to run a CA for each PKIX service. I think the issuance of certificates should be handled by a CA, not every PKIX service that pops up. Why do you want to force me to figure out the OOB mechanism for every new PKIX service? You, most of the folks on this list and I may know how to do that, but I doubt my mother or grandmother would know how to. Regards, Aram Perez From owner-ietf-pkix@imc.org Mon Jun 26 10:39:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07240 for ; Mon, 26 Jun 2000 10:39:14 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA11110; Mon, 26 Jun 2000 07:34:07 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 26 Jun 2000 07:33:52 -0700 Received: from postino.blockade.com (mailgw.blockade.com [204.225.93.196]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11079 for ; Mon, 26 Jun 2000 07:33:48 -0700 (PDT) Received: by mailgw.blockade.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 10:36:49 -0400 Message-ID: <60A30A0BD275D211B8F1006097E472851AC2F9@mailgw.blockade.com> From: "Mason, Shane" To: ietf-pkix@imc.org Subject: unsubscribe Date: Mon, 26 Jun 2000 10:36:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDF7B.F61DCEF0" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDF7B.F61DCEF0 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01BFDF7B.F61DCEF0 Content-Type: text/html; charset="iso-8859-1"
unsubscribe
------_=_NextPart_001_01BFDF7B.F61DCEF0-- From owner-ietf-pkix@imc.org Mon Jun 26 10:48:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07498 for ; Mon, 26 Jun 2000 10:48:50 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA11549; Mon, 26 Jun 2000 07:47:15 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 26 Jun 2000 07:47:09 -0700 Received: from maex02.security.com (machine111.netegrity.com [63.73.77.111] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11519 for ; Mon, 26 Jun 2000 07:47:08 -0700 (PDT) Received: by maex02.netegrity.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 11:03:04 -0400 Message-ID: From: "Lutz, Lisa" To: ietf-pkix@imc.org Subject: unsubsribe Date: Mon, 26 Jun 2000 11:03:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe From owner-ietf-pkix@imc.org Mon Jun 26 13:28:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11481 for ; Mon, 26 Jun 2000 13:28:06 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA19770; Mon, 26 Jun 2000 10:20:18 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 26 Jun 2000 10:19:43 -0700 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19716; Mon, 26 Jun 2000 10:19:41 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA01649; Mon, 26 Jun 2000 10:19:05 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 10:17:51 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EB7E@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Ben Laurie'" , Bob Jueneman Cc: ietf-pkix@imc.org, phoffman@imc.org Subject: RE: Do people have something against RSA? Date: Mon, 26 Jun 2000 10:17:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0019_01BFDF71.12D65C80" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This is a multi-part message in MIME format. ------=_NextPart_000_0019_01BFDF71.12D65C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I agree with Ben, burn down the PTO. Patents are in any case a sixteenth century method of supporting innovation. To equate them with 'capitalism' is ridiculous. Since when was appealing to the government to grant you a twenty year monopoly an intrinsic part of free market competition? The problem is that the US PTO is systematically incompetent. The lack of prior public review utterly compromises the patents issued. No other country has such a ridiculous scheme. The lack of public review is doubly iniquitous. It should be possible for me to determine through due dilligence what IP claims might impinge upon a proposed product. The closed review permits the 'submarine patent' strategy. Keep the patent in process for ten years and rewrite it after the standards have been set. The poor standard of review at the US PTO hurts genuine applicants too. Hold up a US PTO patent and you don't have half the credibility you have with a UK, French or German one. Anyone here believe Unisys deserve a patent royalty on Compuserve's Gif format? Compuserve were entirely unaware that their standard might infringe. Had they known that Unisys had a patent they could easily have avoided the specific inventions claimed. Has anyone considered that a person making a bogus patent application might be held liable under a private suit for conversion in fraud? Phill ------=_NextPart_000_0019_01BFDF71.12D65C80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyNjE3MTg1M1owIwYJKoZI hvcNAQkEMRYEFEFJSZGIAaHjblw7QPz5BvcWoc5PMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAXl3OQxdPPBnK2RrX66MHsBxV2A6brLtzBbYnfkpaZmjr6VRJSOswsMqMqFaq6XdV b4GLxf2NQirTpMxys+vneQy2u+P0ArssD3aF1FKcPUjpxfpcWUE7RDGjF+CHFGpNPe3IltpcyfAS tjabxF9XAzH/6mpp2D935lwvUwsBG/YAAAAAAAA= ------=_NextPart_000_0019_01BFDF71.12D65C80-- From owner-ietf-pkix@imc.org Mon Jun 26 14:41:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13330 for ; Mon, 26 Jun 2000 14:41:58 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA21132; Mon, 26 Jun 2000 11:38:34 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 26 Jun 2000 11:38:19 -0700 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21097; Mon, 26 Jun 2000 11:38:17 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA10970; Mon, 26 Jun 2000 11:36:22 -0700 (PDT) Message-Id: <4.2.2.20000626112651.00ada240@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 26 Jun 2000 11:42:07 -0700 To: Philip Hallam-Baker , "'Ben Laurie'" , Bob Jueneman From: Tony Bartoletti Subject: RE: Do people have something against RSA? Cc: ietf-pkix@imc.org, phoffman@imc.org In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F408EB7E@vhqpostal.verisign. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I have to agree with Phillip and Ben as well. The USPTO seems way-behind the times when it comes to "software" and "web" inventions. If you were the lucky one to first think of the idea of coordinating web auctions (eBay) you just about have the market sewn up. Just try to start your own such service if you want to know what an army of lawyers looks like. They (PTO) seem to think anything transferred to "the web" = "new invention". At minimum, I would like to see such "patents" awarded for at most a one-year period (i.e., adjusted to "cyber-time".) With an adequate review, that should give patent-holders time to leverage their IP into a market advantage. But if all they can produce with their one-year head start are lawsuits, "times up". ___tony___ At 10:17 AM 6/26/00 -0700, Philip Hallam-Baker wrote: >I agree with Ben, burn down the PTO. Patents are in any case a sixteenth >century method of supporting innovation. To equate them with >'capitalism' is ridiculous. > >Since when was appealing to the government to grant you a twenty year >monopoly an intrinsic part of free market competition? > > >The problem is that the US PTO is systematically incompetent. The lack >of prior public review utterly compromises the patents issued. No other >country has such a ridiculous scheme. > >The lack of public review is doubly iniquitous. It should be possible >for me to determine through due dilligence what IP claims might impinge >upon a proposed product. The closed review permits the 'submarine >patent' strategy. Keep the patent in process for ten years and rewrite >it after the standards have been set. > >The poor standard of review at the US PTO hurts genuine applicants too. >Hold up a US PTO patent and you don't have half the credibility you have >with a UK, French or German one. > >Anyone here believe Unisys deserve a patent royalty on Compuserve's Gif >format? Compuserve were entirely unaware that their standard might >infringe. Had they known that Unisys had a patent they could easily have >avoided the specific inventions claimed. > > >Has anyone considered that a person making a bogus patent application >might be held liable under a private suit for conversion in fraud? > > Phill Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Tue Jun 27 06:47:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06443 for ; Tue, 27 Jun 2000 06:47:22 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA00264; Tue, 27 Jun 2000 03:44:35 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Tue, 27 Jun 2000 03:43:29 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00218 for ; Tue, 27 Jun 2000 03:43:28 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06289; Tue, 27 Jun 2000 06:44:06 -0400 (EDT) Message-Id: <200006271044.GAA06289@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-cmp-transport-protocols-00.txt Date: Tue, 27 Jun 2000 06:44:06 -0400 Sender: nsyracus@cnri.reston.va.us Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Transport Protocols for CMP Author(s) : A. Kapoor, R. Tschalar Filename : draft-ietf-pkix-cmp-transport-protocols-00.txt Pages : 10 Date : 26-Jun-00 This document describes how to layer Certificate Management Protocols [CMP] over various transport protocols. The key words 'MUST','MUST NOT', 'REQUIRED', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. This document version corresponds to the draft-ietf-pkix-cmp-transports-03.txt published and discussed in the PKI Forum interoperability mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-cmp-transport-protocols-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-cmp-transport-protocols-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000626112350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-cmp-transport-protocols-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-cmp-transport-protocols-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000626112350.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@imc.org Wed Jun 28 08:45:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21197 for ; Wed, 28 Jun 2000 08:45:46 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA29167; Wed, 28 Jun 2000 05:38:30 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 28 Jun 2000 05:36:53 -0700 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA29045 for ; Wed, 28 Jun 2000 05:36:49 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA01318; Wed, 28 Jun 2000 14:37:30 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 28 Jun 2000 14:37:30 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA24549; Wed, 28 Jun 2000 14:37:28 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA16846; Wed, 28 Jun 2000 14:37:27 +0200 (MET DST) Date: Wed, 28 Jun 2000 14:37:27 +0200 (MET DST) Message-Id: <200006281237.OAA16846@emeriau.edelweb.fr> To: ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: Re: TSP-09 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe > > Modifications to say that a modified Token may be returned when the > status is one (grantedWithMods), e.g. when some extensions have been > incorporated in a way that is slightly different from the request. Note that the status is not part of the token, and it is not signed. It should be made clear that grantedWithMods can only be seen as a hint in order to indicate to the client, that the token may not be what had been asked for. Anyway, a client has to verify all the fields in the token, thus this status doesn't really give additional information. It is not specified in what situation a TSA would set revocationWarning (4), -- this message contains a warning that a revocation is -- imminent revocationNotification (5), -- notification that a revocation has occurred and addInfoNotAvailable (17) -- the additional information requested could not be understood -- or is not available That latter I imagine to see in case of extensions, for example. > It is now time to send this document to the IESG. There are still > opportunities to make minor changes to the document when it becomes > a Standard, at least six months after it becomes Proposed Standard. Hm. The text references a non existing specification: A TSA's certificate MAY contain a Subject Information Access (SIA) extension [son of RFC2459] in order to convey the method of contacting the TSA. The accessMethod field in this extension MUST contain the OID id-ad-timestamping: At least, I propose the following change: A TSA's certificate MAY contain a Subject Information Access (SIA) extension [son of RFC2459]. In order to convey the method of contacting the TSA, the accessMethod field in this extension MUST contain the OID id-ad-timestamping: The following comment should be changed if one uses a SIA: -- Authority Information Access for TSA Besides that, I do not think that a SIA is necessary, it is sufficient to slightly modify the AIA definition by saying that the exact meaning is defined by the definition of the access method, i.e., whether and how it is related to the subject or the issuer. /P From owner-ietf-pkix@imc.org Wed Jun 28 09:10:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21946 for ; Wed, 28 Jun 2000 09:10:31 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA00583; Wed, 28 Jun 2000 06:08:10 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 28 Jun 2000 06:07:57 -0700 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA00546 for ; Wed, 28 Jun 2000 06:06:45 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA01572; Wed, 28 Jun 2000 15:07:17 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 28 Jun 2000 15:07:18 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA24636; Wed, 28 Jun 2000 15:07:16 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA16858; Wed, 28 Jun 2000 15:07:16 +0200 (MET DST) Date: Wed, 28 Jun 2000 15:07:16 +0200 (MET DST) Message-Id: <200006281307.PAA16858@emeriau.edelweb.fr> To: ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: Re: TSP-09 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I forgot : The text says: When the accuracy optional field is not present, then the accuracy may be available through other means, e.g. the PolicyInformation. The text does not indicate the default value for accuracy. Appendix C says: Security considerations: Carries a request for a timestamp and the response. The response will be cryptographically signed. Actually only a part of the response is signed. From owner-ietf-pkix@imc.org Thu Jun 29 00:07:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10391 for ; Thu, 29 Jun 2000 00:07:15 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA26201; Wed, 28 Jun 2000 21:06:04 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Wed, 28 Jun 2000 21:05:35 -0700 Received: from mailcity.com (fes-qout.whowhere.com [209.1.236.7]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA26164 for ; Wed, 28 Jun 2000 21:05:34 -0700 (PDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Wed Jun 28 21:05:44 2000 To: ietf-pkix@imc.org Date: Wed, 28 Jun 2000 21:05:44 -0700 From: "chandrasekaran natarajan" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: chandrasekaran_n@mailcity.com X-Mailer: MailCity Service Subject: hello world ! X-Sender-Ip: 202.144.10.93 Organization: MailCity (http://www.mailcity.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hello all, These days I am not getting any mails from this forum .. Is this forum On ? chandar Send FREE Greetings for Father's Day--or any day! Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct From owner-ietf-pkix@imc.org Thu Jun 29 11:46:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11828 for ; Thu, 29 Jun 2000 11:46:17 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA14550; Thu, 29 Jun 2000 08:41:47 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 08:40:52 -0700 Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA14477 for ; Thu, 29 Jun 2000 08:40:50 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 0336766; Thu, 29 Jun 2000 11:41:31 -0400 (EDT) Sender: rsalz@ns.secondary.com Message-ID: <395B6DFB.67374B30@caveosystems.com> Date: Thu, 29 Jun 2000 11:40:43 -0400 From: Rich Salz X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Aram Perez CC: PKIX Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > Why do you want to force me to figure out the OOB mechanism for every new > PKIX service? I don't. I want it to be possible. Surely you see the difference. Without a self-signed cert, my service has to either 1 Run a CA, doubling the amount of private key material I maintain; or 2 Go to someone else's CA, who might be a competitor, and convince them to perform the due diligence necessary to certify me as a TSA; or 3 Repeat step 2 with "every" CA a potential customer might know. I don't believe it's reasonable claim that just because it's a CA, it is qualified to certify TSA usage. "Trusted to sign end-entitities without these eKU values" is not a feasible trust model. /r$ From owner-ietf-pkix@imc.org Thu Jun 29 13:05:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14813 for ; Thu, 29 Jun 2000 13:05:45 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA24560; Thu, 29 Jun 2000 10:01:27 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 10:01:20 -0700 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24519 for ; Thu, 29 Jun 2000 10:01:14 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FWX00C01DZ5U9@ext-mail.valicert.com> for ietf-pkix@imc.org; Thu, 29 Jun 2000 10:01:53 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FWX00COZDZ5CT@ext-mail.valicert.com>; Thu, 29 Jun 2000 10:01:53 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 09:54:55 -0700 Content-return: allowed Date: Thu, 29 Jun 2000 09:54:54 -0700 From: Peter Williams Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] To: "'Rich Salz'" , Aram Perez Cc: PKIX Message-id: <27FF4FAEA8CDD211B97E00902745CBE235E2EF@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Rich/Aram, The OCSP model got it - the control constructs - about right, I suggest. There, a key management model was embedded in the RFC that leveraged both hierarchical control systems theory (2459) and non-control-oriented constructs for authenticating the public keys of the responder to the service user. OCSP used a specific set of concepts for orchestrating the control relationships between the parties. These went beyond the notion of "delegation of authority via certificates" - a parochial construct from the proprietary system security designs of the late 70s and 80s - a reflection of a certain era of designed-in integrity for distributed systems. TSA should do the same as OCSP, I suggest. The simplistic military security model in which TSAs are "granted authority to act" by a CA is doubtfully sufficient for the Internet environment that we profile here. The commercial, political and practical realities make such a simple model as impractical as the same model was for OCSP. I doubt we would now have the various validation networks that we see popping up if the OCSP standard had not had the flexibility to adapt to various ideas of control, as decided by the deployment community. OCSP enabled us (a significant OCSP vendor/user community now) to deploy switched, proxied, cached, pushed, pulled and delegated forms of validation authorities (OCSP responders) as the risk management culture demanded. To engender a successful, commercially-driven, multi-vendor, value-adding, open TSA industry, we should perhaps follow the OCSP lead. We should again use interworking-standards consensus to help form another round of open, Internet infrastructure. Ensuring that there are various models of control - that relying parties apply under their own models of risk management - seems vital: only those Internet security standards with the required degree of openness in the control area seem to get adopted in practice. Peter. -----Original Message----- From: Rich Salz [mailto:rsalz@caveosystems.com] Sent: Thursday, June 29, 2000 8:41 AM To: Aram Perez Cc: PKIX Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > Why do you want to force me to figure out the OOB mechanism for every new > PKIX service? I don't. I want it to be possible. Surely you see the difference. Without a self-signed cert, my service has to either 1 Run a CA, doubling the amount of private key material I maintain; or 2 Go to someone else's CA, who might be a competitor, and convince them to perform the due diligence necessary to certify me as a TSA; or 3 Repeat step 2 with "every" CA a potential customer might know. I don't believe it's reasonable claim that just because it's a CA, it is qualified to certify TSA usage. "Trusted to sign end-entitities without these eKU values" is not a feasible trust model. /r$ From owner-ietf-pkix@imc.org Thu Jun 29 13:13:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15132 for ; Thu, 29 Jun 2000 13:13:38 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA24942; Thu, 29 Jun 2000 10:11:47 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 10:11:45 -0700 Received: from ponyexpress7.csc.com (ponyexpress7.csc.com [208.219.64.208]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24908 for ; Thu, 29 Jun 2000 10:11:44 -0700 (PDT) From: ghilborn@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress7.csc.com with smtp (Exim 2.12 #1) id 137hrA-00045L-01 for ietf-pkix@imc.org; Thu, 29 Jun 2000 13:12:04 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690D.005E8712 ; Thu, 29 Jun 2000 13:12:29 -0400 X-Lotus-FromDomain: CSC To: rsalz@caveosystems.com cc: ietf-pkix@imc.org Message-ID: <8525690D.005E86BD.00@csc.com> Date: Thu, 29 Jun 2000 13:11:27 -0400 Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe If the CP under which the CA operates says that it certifies identity and binding of that to a public key, then that is all it does. The validity or security or accuracy, etc. of whatever service a business operates under that identity (e.g., time sever, ocsp responder, web information server, etc.) is NOT what a CA "certifies." So isn't the only "due-diligence" required of the CA that of certifing the valid business identity and private key possession of the public key bound into the certificate of the TSA? The accuracy, availability, etc. of TSA service is expressed in their own policy/contract with their customers, just as is the privacy policy for a web server to which a CA issues a certificate. -GH rsalz@caveosystems.com on 06/29/2000 11:40:43 AM To: aram@pacbell.net cc: ietf-pkix@imc.org (bcc: Gene Hilborn/DEF/CSC) Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > Why do you want to force me to figure out the OOB mechanism for every new > PKIX service? I don't. I want it to be possible. Surely you see the difference. Without a self-signed cert, my service has to either 1 Run a CA, doubling the amount of private key material I maintain; or 2 Go to someone else's CA, who might be a competitor, and convince them to perform the due diligence necessary to certify me as a TSA; or 3 Repeat step 2 with "every" CA a potential customer might know. I don't believe it's reasonable claim that just because it's a CA, it is qualified to certify TSA usage. "Trusted to sign end-entitities without these eKU values" is not a feasible trust model. /r$ From owner-ietf-pkix@imc.org Thu Jun 29 14:39:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17249 for ; Thu, 29 Jun 2000 14:39:35 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA26987; Thu, 29 Jun 2000 11:37:53 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 11:37:42 -0700 Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA26953 for ; Thu, 29 Jun 2000 11:37:42 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 0487337; Thu, 29 Jun 2000 14:38:21 -0400 (EDT) Sender: rsalz@ns.secondary.com Message-ID: <395B976E.CCA3AC43@caveosystems.com> Date: Thu, 29 Jun 2000 14:37:34 -0400 From: Rich Salz X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ghilborn@csc.com CC: ietf-pkix@imc.org Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: <8525690D.005E86BD.00@csc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit > If the CP under which the CA operates says that it certifies identity and > binding of that to a public key, then that is all it does. And that's pretty much indistinguishable from self-signed, no? Actually, it's "less secure." Self-signed is proof-of-possesion, while the CA you describe means "I trust that you saw proof-of-possesion." /r$ From owner-ietf-pkix@imc.org Thu Jun 29 16:48:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19808 for ; Thu, 29 Jun 2000 16:48:01 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA29042; Thu, 29 Jun 2000 13:42:56 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 13:42:43 -0700 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29012 for ; Thu, 29 Jun 2000 13:42:42 -0700 (PDT) Received: from [192.168.1.57] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWX00GHQO3Y85@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 29 Jun 2000 13:40:48 -0700 (PDT) Date: Thu, 29 Jun 2000 12:40:31 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <395B6DFB.67374B30@caveosystems.com> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi Rich, >> Why do you want to force me to figure out the OOB mechanism for every new >> PKIX service? > > I don't. I want it to be possible. Surely you see the difference. Yes I see the difference. But the more possibilities you have, the more potential for security breakdown there is, i.e. someone doesn't do their due diligence with the OOB mechanism. > > Without a self-signed cert, my service has to either > 1 Run a CA, doubling the amount of private key material I maintain; or In my opinion, this should NOT be an option. > 2 Go to someone else's CA, who might be a competitor, and convince > them to perform the due diligence necessary to certify me as a TSA; or This is the correct option. That is why they are in business: to certify public keys. And any CA, whether or not it signs your TSA key and whether or not a TSA can issue self-signed roots, is a potential competitor. Look at all the non-CA things Verisign is doing now days. Besides, a CA should not certify you as a TSA, it should certify your TSA public key. If I want to use your service, I will not go to the CA that signed your key to determine whether or not your TSA service is valid. > 3 Repeat step 2 with "every" CA a potential customer might know. I doubt your potential customers will want many CAs. Again, for every CA they want, they have to have an OOB mechanism to validate the root certificate. > > I don't believe it's reasonable claim that just because it's a CA, it is > qualified to certify TSA usage. "Trusted to sign end-entitities without > these eKU values" is not a feasible trust model. See my comment under option 2. Regards, Aram Perez From owner-ietf-pkix@imc.org Thu Jun 29 17:04:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20170 for ; Thu, 29 Jun 2000 17:04:02 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA29506; Thu, 29 Jun 2000 13:58:35 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 13:58:12 -0700 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29438 for ; Thu, 29 Jun 2000 13:58:12 -0700 (PDT) Received: from [192.168.1.57] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWX00GFQOJJ6D@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 29 Jun 2000 13:50:08 -0700 (PDT) Date: Thu, 29 Jun 2000 12:49:50 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <8525690D.005E86BD.00@csc.com> To: ghilborn@csc.com, rsalz@caveosystems.com Cc: ietf-pkix@imc.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit GHilborn wrote: > If the CP under which the CA operates says that it certifies identity and > binding of that to a public key, then that is all it does. The validity or > security or accuracy, etc. of whatever service a business operates under that > identity (e.g., time sever, ocsp responder, web information server, etc.) is > NOT what a CA "certifies." So isn't the only "due-diligence" required of the > CA > that of certifing the valid business identity and private key possession of > the > public key bound into the certificate of the TSA? The accuracy, availability, > etc. of TSA service is expressed in their own policy/contract with their > customers, just as is the privacy policy for a web server to which a CA issues > a certificate. Well stated! I'm sure there are a number of web-based stores that Verisign issued certificates to that are no longer in business. The same will happen with TSAs, not all of them will exist after a few years (whether or not they issued self-signed certificates). Aram Perez > -GH > > > > > rsalz@caveosystems.com on 06/29/2000 11:40:43 AM > > To: aram@pacbell.net > cc: ietf-pkix@imc.org (bcc: Gene Hilborn/DEF/CSC) > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > > > >> Why do you want to force me to figure out the OOB mechanism for every new >> PKIX service? > > I don't. I want it to be possible. Surely you see the difference. > > Without a self-signed cert, my service has to either > 1 Run a CA, doubling the amount of private key material I maintain; or > 2 Go to someone else's CA, who might be a competitor, and convince > them to perform the due diligence necessary to certify me as a TSA; or > 3 Repeat step 2 with "every" CA a potential customer might know. > > I don't believe it's reasonable claim that just because it's a CA, it is > qualified to certify TSA usage. "Trusted to sign end-entitities without > these eKU values" is not a feasible trust model. > /r$ > > > > From owner-ietf-pkix@imc.org Thu Jun 29 17:05:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20215 for ; Thu, 29 Jun 2000 17:05:33 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA29502; Thu, 29 Jun 2000 13:58:34 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 13:58:21 -0700 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29457 for ; Thu, 29 Jun 2000 13:58:21 -0700 (PDT) Received: from [192.168.1.57] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWX00JS8OXKNC@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 29 Jun 2000 13:58:33 -0700 (PDT) Date: Thu, 29 Jun 2000 12:58:11 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <27FF4FAEA8CDD211B97E00902745CBE235E2EF@seine.valicert.com> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi Peter, While I mostly agree with you, this is the PKIX (where the X is for X.509) with is by definition hierarchical (or "parochial" as you put it). I'm not sure where this notion of "delegation of authority via certificates" comes from or the concept of "trust me, I have a certificate from XYZ (a CA)", but I certain am not a believer or practitioner of it. In a PKIX world, I only want a CA to bind some identity and a public key. I will establish authority and trust via other mechanisms that are not necessarily tied to a CA and/or certificates. Regards, Aram Perez > Rich/Aram, > > The OCSP model got it - the control constructs - about right, I > suggest. There, a key management model was embedded in the RFC that > leveraged both hierarchical control systems theory (2459) and > non-control-oriented constructs for authenticating the public > keys of the responder to the service user. > > OCSP used a specific set of concepts for orchestrating > the control relationships between the parties. These went > beyond the notion of "delegation of authority via > certificates" - a parochial construct from the proprietary system > security designs of the late 70s and 80s - a reflection of a certain > era of designed-in integrity for distributed systems. > > TSA should do the same as OCSP, I suggest. The simplistic military > security model in which TSAs are "granted authority to act" by > a CA is doubtfully sufficient for the Internet environment > that we profile here. The commercial, political and > practical realities make such a simple model as impractical > as the same model was for OCSP. > > I doubt we would now have the various validation networks that > we see popping up if the OCSP standard had not had > the flexibility to adapt to various ideas of control, as > decided by the deployment community. OCSP > enabled us (a significant OCSP vendor/user community now) to > deploy switched, proxied, cached, pushed, pulled and delegated > forms of validation authorities (OCSP responders) as the > risk management culture demanded. > > To engender a successful, commercially-driven, multi-vendor, > value-adding, open TSA industry, we should perhaps follow the > OCSP lead. We should again use interworking-standards consensus to > help form another round of open, Internet infrastructure. Ensuring > that there are various models of control - that relying parties apply > under their own models of risk management - seems vital: only > those Internet security standards with the required degree of openness > in the control area seem to get adopted in practice. > > Peter. > > -----Original Message----- > From: Rich Salz [mailto:rsalz@caveosystems.com] > Sent: Thursday, June 29, 2000 8:41 AM > To: Aram Perez > Cc: PKIX > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > > >> Why do you want to force me to figure out the OOB mechanism for every new >> PKIX service? > > I don't. I want it to be possible. Surely you see the difference. > > Without a self-signed cert, my service has to either > 1 Run a CA, doubling the amount of private key material I maintain; or > 2 Go to someone else's CA, who might be a competitor, and convince > them to perform the due diligence necessary to certify me as a TSA; > or > 3 Repeat step 2 with "every" CA a potential customer might know. > > I don't believe it's reasonable claim that just because it's a CA, it is > qualified to certify TSA usage. "Trusted to sign end-entitities without > these eKU values" is not a feasible trust model. > /r$ From owner-ietf-pkix@imc.org Thu Jun 29 17:48:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20701 for ; Thu, 29 Jun 2000 17:48:40 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA00468; Thu, 29 Jun 2000 14:38:33 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 14:38:29 -0700 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00438 for ; Thu, 29 Jun 2000 14:38:29 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id OAA03749; Thu, 29 Jun 2000 14:38:24 -0700 (PDT) Message-Id: <4.2.2.20000629133613.00a9f950@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 29 Jun 2000 14:44:03 -0700 To: Rich Salz , ghilborn@csc.com From: Tony Bartoletti Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Cc: ietf-pkix@imc.org In-Reply-To: <395B976E.CCA3AC43@caveosystems.com> References: <8525690D.005E86BD.00@csc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 02:37 PM 6/29/00 -0400, Rich Salz wrote: > > If the CP under which the CA operates says that it certifies identity and > > binding of that to a public key, then that is all it does. > >And that's pretty much indistinguishable from self-signed, no? >Actually, it's "less secure." Self-signed is proof-of-possesion, >while the CA you describe means "I trust that you saw >proof-of-possesion." > /r$ Even a (supposed) CA that attests to POP is of no value if you do not first (1) trust that CA, and (2) trust that you actually have a certificate issued by that CA. Both sides of this argument make good points in their isolation. I must apply a (naive, dumb) usage example to clarify the issues in my own mind. I imagine some poor soul who discovers they must rely critically upon a particular timestamped piece of data, the timestamp itself a critical value. While simultaneously demonstrating my ignorance of the protocols and procedures that might be in place, I think I am not too far off in recognizing that the following "logical" operations must occur, in one or another order: 1. Obtain a public key value for which the TS signature verifies. (Call this key the TS-Public). (This establishes that the signer, whoever in the world they might be), possessed the corresponding private key, and (we must assume) effected the TS signature. 2. Obtain a certificate (self-signed or otherwise) that hopes to represent a binding of the TS-Public with a set of name- like attributes. In our case, the name is "TS-R-US". (My boss TOLD me that TS-R-US is the TSA to trust.) So far, so good... Now, what are the possible avenues of attack, for which either "self-signed" or "CA-signed" is intended to be a better remedy? In order for a fraud to be perpetrated, we assume it is the fraudster who must have possessed and signed the timestamp. An attacker, knowing our penchant to trust "TS-R-US", would need to a. Create a TS-signing key pair (easy) b. Formulate a certificate attesting to the binding of this keypair with the name "TS-R-US", EITHER in self-signed fashion, or else by another ersatz key-pair/cert appearing as the (well-known;) CA "AnyCerts.com". (Yes, my boss SAID to trust "AnyCerts.com") c. Then (How?) circulate/distribute this/these certificates in such a fashion that the poor soul verifying the timestamp in question is sure to run across them first. Of course, in the case of "AnyCerts.com", that certificate is itself either self-signed, or invokes a further chain of verification. But eventually the buck stops. Beyond the mere mechanics of verification, there must be an established place where the buck is to stop. That place SHOULD be anywhere the RP chooses it to be, I would think. After all, they are the Relying Party. Similarly, each RP will need to apply the "discovery procedures" that they feel serve to satisfy their own operational and security needs. In light of this, I am not convinced that any one "solution" has a hands-down advantage for all reasonable use-cases. Comments? ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Thu Jun 29 18:04:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21151 for ; Thu, 29 Jun 2000 18:04:04 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA00991; Thu, 29 Jun 2000 15:01:42 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 15:01:37 -0700 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00961 for ; Thu, 29 Jun 2000 15:01:37 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id PAA18318; Thu, 29 Jun 2000 15:01:57 -0700 (PDT) Message-Id: <4.2.2.20000629145854.00aa9c90@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 29 Jun 2000 15:07:36 -0700 To: Aram Perez , PKIX From: Tony Bartoletti Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-Reply-To: References: <395B6DFB.67374B30@caveosystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 12:40 PM 6/29/00 -0700, Aram Perez wrote: >Hi Rich, > > 3 Repeat step 2 with "every" CA a potential customer might know. > >I doubt your potential customers will want many CAs. Again, for every CA >they want, they have to have an OOB mechanism to validate the root >certificate. I don't think Rich meant that "a" potential customer may want to employ many different CAs, but rather that he must deal with the union of the set of CAs trusted by his set of customers, right? Inescapably, there must be a good OOB procedure somewhere, but each customer would need only the one of their choosing, and it must be of their own choosing, of course, unless someone else is willing to accept the liability of making that decision for them (show of hands?) ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Thu Jun 29 18:28:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21433 for ; Thu, 29 Jun 2000 18:28:16 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA01508; Thu, 29 Jun 2000 15:25:19 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 15:25:16 -0700 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01478 for ; Thu, 29 Jun 2000 15:25:15 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id PAA03046; Thu, 29 Jun 2000 15:25:27 -0700 (PDT) Message-Id: <4.2.2.20000629151343.00ad4490@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 29 Jun 2000 15:31:06 -0700 To: Aram Perez , PKIX From: Tony Bartoletti Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-Reply-To: References: <395B6DFB.67374B30@caveosystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 12:40 PM 6/29/00 -0700, Aram Perez wrote: >Hi Rich, > > >> Why do you want to force me to figure out the OOB mechanism for every new > >> PKIX service? > > > > I don't. I want it to be possible. Surely you see the difference. > >Yes I see the difference. But the more possibilities you have, the more >potential for security breakdown there is, i.e. someone doesn't do their due >diligence with the OOB mechanism. On Aram's side, I envision a large enterprise dealing routinely with signature verifications of all manner. In such a case, it would certainly make sense to have the TSA key be similarly certified, rather than invoking an additional OOB mechanism. On Rich's side, I envision a dedicated operation that had purely a need for a secured timestamp. In any case, some TSA must be independently trusted for this operation. If the TS-client has to form a secure OOB conveyance, and could do so directly with the TSA, it does seem "unnatural" to require that they instead seek a CA to trust, and require this TSA to have their key certified by this particular choice of CA. (Otherwise, their choice of TSA becomes restricted to those whose keys have been certified by the "trusted" CAs, if any.) Granted, for future RPs who need to make verifications, it is a question of whether the TSA went out of business first, and the CA second, or the TSA outlived the CA. Are we betting on relative longevity here? ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Thu Jun 29 19:08:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22179 for ; Thu, 29 Jun 2000 19:08:17 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA02155; Thu, 29 Jun 2000 16:06:26 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 16:06:19 -0700 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02125 for ; Thu, 29 Jun 2000 16:06:19 -0700 (PDT) Received: from [192.168.1.57] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWX0010IUP2R2@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 29 Jun 2000 16:03:03 -0700 (PDT) Date: Thu, 29 Jun 2000 15:03:36 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <4.2.2.20000629145854.00aa9c90@poptop.llnl.gov> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi Tony, > At 12:40 PM 6/29/00 -0700, Aram Perez wrote: >> Hi Rich, >>> 3 Repeat step 2 with "every" CA a potential customer might know. >> >> I doubt your potential customers will want many CAs. Again, for every CA >> they want, they have to have an OOB mechanism to validate the root >> certificate. > > I don't think Rich meant that "a" potential customer may want to > employ many different CAs, but rather that he must deal with the > union of the set of CAs trusted by his set of customers, right? Yes that is correct. But that is the PKIX model. > > Inescapably, there must be a good OOB procedure somewhere, but > each customer would need only the one of their choosing, and it > must be of their own choosing, of course, unless someone else > is willing to accept the liability of making that decision for > them (show of hands?) If you find that one OOB procedure, let me know. I far as I can tell, you need a separate OOB procedure for every self-signed certificate. I raised this issue quite a while back: try to find out the root certificate fingerprints for Verisign, Thawte or any public CA and try to validate your browser root certificates. Regards, Aram Perez From owner-ietf-pkix@imc.org Thu Jun 29 19:33:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23025 for ; Thu, 29 Jun 2000 19:33:59 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA02536; Thu, 29 Jun 2000 16:26:34 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 16:26:31 -0700 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02506 for ; Thu, 29 Jun 2000 16:26:30 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 19:28:03 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF22D74B@panda.chrysalis-its.com> To: stephen.farrell@baltimore.ie Cc: ietf-pkix@imc.org Subject: CRMF encValue Field Date: Thu, 29 Jun 2000 19:27:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE221.AB1BCDEC" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFE221.AB1BCDEC Content-Type: text/plain; charset="iso-8859-1" Steve, As agreed yesterday at the PKI Forum meeting in Dublin, could you please check and add some clarification in the next version of RFC2510bis about what exactly must be encoded in the "encValue" field of the EncryptedValue structure, which is described in Section 6.4 of CRMF [RFC2511]. This clarification will become necessary in order to ensure interoperability between components using hardware or software from different vendors (i.e. clients, RAs and CAs) that might use this CRMF "encValue" field. As discussed, please note that hardware cryptographic module vendors that implement PKCS#11 would normally use the Cryptoki wrapping mechanism to encrypt any private key that has to be extracted from their module to go in this "encValue" field. Since Section 11.9 of PKCS#11 v2.01 mandates for wrapping a private key that: "Cryptoki Version 2.01 allows the use of secret keys for wrapping and unwrapping RSA private keys, Diffie-Hellman private keys, and DSA private keys. For wrapping, a private key is BER-encoded according to PKCS #8's PrivateKeyInfo ASN.1 type." I hope that the type "PrivateKeyInfo" from Section 6 of PKCS#8 is what is currently being encrypted within this CRMF "encValue" field of the EncryptedValue structure for today CMP implementations. Regards, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: Francois Rousseau Sent: Thursday, May 25, 2000 3:42 PM To: 'Carlisle Adams' Cc: ietf-pkix@imc.org Subject: Encryption of Private Keys in CRMF and CMP Carlisle, In Section 6.4 of RFC 2511 on CRMF, it is indicated that the EncryptedValue field "encValue" is a BIT STRING, however I could not find any further detail in RFC 2511 nor in RFC 2510bis, which also use this syntax, about how to create this encrypted value (restricted, in RFC 2510bis, to be either private keys or certificates). Am I missing something? I understand that RFC 2511 EncryptedValue field "symmAlg" tells me the symmetric algorithm that was used to encrypt a private key value and that Appendix B2 of RFC 2510bis mandates that conforming implementations MUST support 3-DES (3-key-EDE, CBC mode) for this. However, this does not tell me what exactly is being encrypted. Is it a type "PrivateKeyInfo" from Section 6 of PKCS#8 or a type "RSAPrivateKey" from Section 11.1.2 of PKCS#1 for a RSA private key since RFC 2511 EncryptedValue field "intendedAlg" already tell me the intended algorithm for which the private key will be used for? Thanks in advance for any help. Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFE221.AB1BCDEC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CRMF encValue Field

Steve,

As agreed yesterday at the PKI Forum meeting in = Dublin, could you please check and add some clarification in the next = version of RFC2510bis about what exactly must be encoded in the = "encValue" field of the EncryptedValue structure, which is = described in Section 6.4 of CRMF [RFC2511]. This clarification will = become necessary in order to ensure interoperability between components = using hardware or software from different vendors (i.e. clients, RAs = and CAs) that might use this CRMF "encValue" = field.

As discussed, please note that hardware cryptographic = module vendors that implement PKCS#11 would normally use the Cryptoki = wrapping mechanism to encrypt any private key that has to be extracted = from their module to go in this "encValue" field. Since = Section 11.9 of PKCS#11 v2.01 mandates for wrapping a private key = that:

"Cryptoki Version 2.01 allows the use of secret = keys for wrapping and unwrapping RSA private keys, Diffie-Hellman = private keys, and DSA private keys. For wrapping, a private key is = BER-encoded according to PKCS #8's PrivateKeyInfo ASN.1 = type."

I hope that the type "PrivateKeyInfo" from = Section 6 of PKCS#8 is what is currently being encrypted within this = CRMF "encValue" field of the EncryptedValue structure for = today CMP implementations.

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078


-----Original Message-----
From: Francois Rousseau
Sent: Thursday, May 25, 2000 3:42 PM
To: 'Carlisle Adams'
Cc: ietf-pkix@imc.org
Subject: Encryption of Private Keys in CRMF and = CMP


Carlisle,

In Section 6.4 of RFC 2511 on CRMF, it is indicated = that the EncryptedValue field "encValue" is a BIT STRING, = however I could not find any further detail in RFC 2511 nor in RFC = 2510bis, which also use this syntax, about how to create this encrypted = value (restricted, in RFC 2510bis, to be either private keys or = certificates).

Am I missing something?

I understand that RFC 2511 EncryptedValue field = "symmAlg" tells me the symmetric algorithm that was used to = encrypt a private key value and that Appendix B2 of RFC 2510bis = mandates that conforming implementations MUST support 3-DES (3-key-EDE, = CBC mode) for this. However, this does not tell me what exactly is = being encrypted.

Is it a type "PrivateKeyInfo" from Section = 6 of PKCS#8 or a type "RSAPrivateKey" from Section 11.1.2 of = PKCS#1 for a RSA private key since RFC 2511 EncryptedValue field = "intendedAlg" already tell me the intended algorithm for = which the private key will be used for?

Thanks in advance for any help.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01BFE221.AB1BCDEC-- From owner-ietf-pkix@imc.org Thu Jun 29 20:29:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23628 for ; Thu, 29 Jun 2000 20:29:54 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA04041; Thu, 29 Jun 2000 17:26:58 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 17:26:52 -0700 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA04008 for ; Thu, 29 Jun 2000 17:26:51 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id RAA02829; Thu, 29 Jun 2000 17:27:14 -0700 (PDT) Message-Id: <4.2.2.20000629162526.00adfdd0@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 29 Jun 2000 17:32:53 -0700 To: Aram Perez , PKIX From: Tony Bartoletti Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-Reply-To: References: <4.2.2.20000629145854.00aa9c90@poptop.llnl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 03:03 PM 6/29/00 -0700, Aram Perez wrote: >Hi Tony, > > Inescapably, there must be a good OOB procedure somewhere, but > > each customer would need only the one of their choosing, and it > > must be of their own choosing, of course, unless someone else > > is willing to accept the liability of making that decision for > > them (show of hands?) > >If you find that one OOB procedure, let me know. I far as I can tell, you >need a separate OOB procedure for every self-signed certificate. I raised >this issue quite a while back: try to find out the root certificate >fingerprints for Verisign, Thawte or any public CA and try to validate your >browser root certificates. You are right there. In general, our browser (or its distributor) is the effective root of our trust. What a thought. Classic regress problem. You want a secure channel in order to convey the items that establish the security of another channel. The only channel that you can trust a priori is the channel that you have with yourself, (hence the SPKI approach.) Hypothetically, (assuming I just give up and assume that my browser's root certs are "currently" valid,) I could create a self-signed root cert, use it to certify all of the root-keys in the browser, and thus establish myself as my (personal) root-over-them-all (solely to prevent their tampering or replacement). Beyond this, when I felt (for whatever reason) that CA XYZ was no longer to be trusted, I would simply revoke MY certification of their public key. But what would be required to make such processing occur (for what little comfort it might bring?) How might I force all chains to reach for my root-cert as endpoint? ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Thu Jun 29 22:14:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25510 for ; Thu, 29 Jun 2000 22:14:11 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA08922; Thu, 29 Jun 2000 19:12:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 19:12:37 -0700 Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08874 for ; Thu, 29 Jun 2000 19:12:36 -0700 (PDT) Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id AAA09576 for ; Fri, 30 Jun 2000 00:55:59 -0500 (EST) (envelope-from arik@phaos.com) Message-Id: <4.2.0.58.20000629221438.00ab3d20@mail.phaos.com> X-Sender: arik@mail.phaos.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 29 Jun 2000 22:21:53 -0400 To: ietf-pkix@imc.org From: Ari Kermaier Subject: algorithm OID esoterica Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe This may not be of interest to many people, but are there any legitimate/official/semi-real OIDs defined for the Blowfish symmetric cipher algorithm and the Null cipher (for completeness' sake)? Ari Kermaier From owner-ietf-pkix@imc.org Thu Jun 29 22:28:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25600 for ; Thu, 29 Jun 2000 22:28:47 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA09731; Thu, 29 Jun 2000 19:27:01 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 19:26:59 -0700 Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA09700 for ; Thu, 29 Jun 2000 19:26:57 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id OAA24820 for ; Fri, 30 Jun 2000 14:27:48 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96233206730218>; Fri, 30 Jun 2000 14:27:47 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: Re: algorithm OID esoterica Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Fri, 30 Jun 2000 14:27:47 (NZST) Message-ID: <96233206730218@kahu.cs.auckland.ac.nz> Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Ari Kermaier writes: >This may not be of interest to many people, but are there any >legitimate/official/semi-real OIDs defined for the Blowfish symmetric >cipher algorithm and the Null cipher (for completeness' sake)? draft-schneier-blowfish-00.txt has: 5. ASN.1 structures and Object Identifiers Blowfish has the following ASN.1 definitions: blowfishECB ALGORITHM PARAMETER NULL ::= {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) algorithm(1) symmetric-encryption(1) 1} blowfishCBC ALGORITHM PARAMETER CBCParameter ::= {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) algorithm(1) symmetric-encryption(1) 2} blowfishCFB ALGORITHM PARAMETER FBParameter ::= {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) algorithm(1) symmetric-encryption(1) 3} blowfishOFB ALGORITHM PARAMETER FBParameter ::= {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) algorithm(1) symmetric-encryption(1) 4} The parameters are the standard OIW parameters for block cipher chaining modes [OIW] and are reproduced below: CBCParameter ::= IV FBParameter ::= SEQUENCE { iv IV, numberOfBits NumberOfBits } IV ::= OCTET STRING -- 8 octets NumberOfBits ::= INTEGER When used with Blowfish, NumberOfBits should always be 64. Peter. From owner-ietf-pkix@imc.org Fri Jun 30 02:45:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10990 for ; Fri, 30 Jun 2000 02:45:49 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA19717; Thu, 29 Jun 2000 23:42:47 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 23:42:33 -0700 Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19672 for ; Thu, 29 Jun 2000 23:42:30 -0700 (PDT) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA11679 for ; Fri, 30 Jun 2000 16:42:52 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0lYHny; Fri Jun 30 16:42:04 2000 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA24211 for ; Fri, 30 Jun 2000 16:42:04 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdErDBt_; Fri Jun 30 16:41:31 2000 Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA00130 for ; Fri, 30 Jun 2000 16:41:30 +1000 (EST) Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Jun 2000 16:41:29 +1000 Message-ID: <73388857A695D31197EF00508B08F2988A3C17@ntmsg0131.corpmail.telstra.com.au> From: "Manger, James H" To: "'PKIX'" Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH Date: Fri, 30 Jun 2000 16:40:55 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Denis Paul Koning provided sensible arguments for removing the unnecessary checks by the TSA on the messageImprint field. Michael Zolotarev agreed, as did Terry Hayes. No one disagreed. However, the latest timestamp draft does not reflect this agreement. Why not? If more voices are needed I add my agreement. If details of specific text changes are required here goes (apply to draft 09): 1. In section 2.1. "Requirements of the TSA", delete item 7 ("to examine the OID of the one-way..") and renumber the subsequent items. 2. In section 2.1. "Requirements of the TSA", delete the bracketed text in item 8, i.e. the text that refers to item 7. 3. In section 2.4.1 "Request Format", page 4, delete the following sentence: "Its length MUST match the length of the hash value for that algorithm (e.g. 20 bytes for SHA-1 or 16 bytes for MD5)" 4. In section 2.4.1 "Request Format", page 5, delete the following paragraph: "The hash algorithm indicated in the hashAlgorithm field MUST be a known hash algorithm (one-way and collision resistant)." 5. In section 2.4.2 "Response Format", page 8, delete the following text: ", provided that the size of the hash value matches the expected size of the hash algorithm identified in hashAlgorithm" P.S. The changes do not prevent a TSA rejecting a timestamp request if it knows the hash algorithm is bad. From owner-ietf-pkix@imc.org Fri Jun 30 03:01:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11097 for ; Fri, 30 Jun 2000 03:01:59 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA20339; Thu, 29 Jun 2000 23:58:54 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Thu, 29 Jun 2000 23:58:52 -0700 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA20309 for ; Thu, 29 Jun 2000 23:58:50 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id RAA20418; Fri, 30 Jun 2000 17:03:57 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 30 Jun 2000 16:57:31 +1000 Message-ID: From: Michael Zolotarev To: Aram Perez , PKIX Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Fri, 30 Jun 2000 16:57:31 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe God knows I was trying hard to stay away from it :) > > > > Inescapably, there must be a good OOB procedure somewhere, but > > each customer would need only the one of their choosing, and it > > must be of their own choosing, of course, unless someone else > > is willing to accept the liability of making that decision for > > them (show of hands?) > > If you find that one OOB procedure, let me know. I far as I > can tell, you > need a separate OOB procedure for every self-signed > certificate. I raised > this issue quite a while back: try to find out the root certificate > fingerprints for Verisign, Thawte or any public CA and try to > validate your > browser root certificates. So you are saying that we must prohibit self-signed TSA certs for the lack of practical and reliable OOB mechanism? That seems to be the root of the problem to me. Well, the same argument would have to apply to the most of self-signed PKI then, as your experience with Verisign and Co rightly shows. Following the same logic - should we temporary freeze everything, 'till there is an OOB that we all agree to trust? And consequently shut those authorities that do not seem to provide adequate OOB (or so we reckon)? Who should we start with? any suggestions? Out of the bitchy mood now. If my clients community decides that my OOB is adequate - why should you stop my clients from exercising their trust? On the other hand, if a client decides that my OOB is NOT adequate - it is his/her right not to use my services. I just don't see why is it of any concern for us. I envisage you saying that an average client is a no-brain moron (NBM) with a tendency to trust anybody, and it is our sacred mission to protect them. Well - doesn't the same argument apply to a NBM using "any public CA", which did not happen to be pre-loaded into IE5? Please, be consistent - once you start talking about NBMs, there is no difference between self-signed CA cert and self-signed TSA cert. As for non-NBM, we should have some kind of reliance into OOB and general intellegence of the clients (not a very technical argument though, I admit :) Michael From owner-ietf-pkix@imc.org Fri Jun 30 03:56:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11397 for ; Fri, 30 Jun 2000 03:56:25 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA22326; Fri, 30 Jun 2000 00:50:40 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 30 Jun 2000 00:50:25 -0700 Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA22292 for ; Fri, 30 Jun 2000 00:50:24 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id JAA20102 for ; Fri, 30 Jun 2000 09:51:17 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 30 Jun 2000 09:51:17 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id JAA05099 for ; Fri, 30 Jun 2000 09:51:15 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id JAA17820 for ietf-pkix@imc.org; Fri, 30 Jun 2000 09:51:15 +0200 (MET DST) Date: Fri, 30 Jun 2000 09:51:15 +0200 (MET DST) Message-Id: <200006300751.JAA17820@emeriau.edelweb.fr> To: ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Currently a CA can have several key usages indicated in its cert (or in some cert given to it) EXCEPT you can newer use a CA key for time stamping. Why is it that a TSA needs a more restrictive handling than a CA? > > I envisage you saying that an average client is a no-brain moron (NBM) with > a tendency to trust anybody, and it is our sacred mission to protect them. > Well - doesn't the same argument apply to a NBM using "any public CA", which > did not happen to be pre-loaded into IE5? Please, be consistent - once you > start talking about NBMs, there is no difference between self-signed CA cert > and self-signed TSA cert. As for non-NBM, we should have some kind of > reliance into OOB and general intellegence of the clients (not a very > technical argument though, I admit :) > > Michael From owner-ietf-pkix@imc.org Fri Jun 30 04:09:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11517 for ; Fri, 30 Jun 2000 04:09:23 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA22910; Fri, 30 Jun 2000 01:06:21 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 30 Jun 2000 01:06:19 -0700 Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA22878 for ; Fri, 30 Jun 2000 01:06:18 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id RAA14853 for ; Fri, 30 Jun 2000 17:06:36 +0900 (JST) (envelope-from kongqy@ec.cs.fujitsu.co.jp) Received: from vishnu.ec.cs.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0006-Fujitsu Domain Master) id RAA10580; Fri, 30 Jun 2000 17:06:35 +0900 (JST) Received: from ec.cs.fujitsu.co.jp (cath.ec.cs.fujitsu.co.jp [10.34.199.204]) by vishnu.ec.cs.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.4W5-04/12/98 EC domain mail master) with ESMTP id RAA01987 for ; Fri, 30 Jun 2000 17:06:35 +0900 (JST) Message-ID: <395C5506.D233574B@ec.cs.fujitsu.co.jp> Date: Fri, 30 Jun 2000 17:06:30 +0900 From: Kong QiuYan X-Mailer: Mozilla 4.7 [ja] (WinNT; U) X-Accept-Language: ja MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: certificate chain validation(policy extension) Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Suppose I have a certificate chain consisting of a Root, a CA and a User certificate. The policy extension in the Root certificate contains one oid of 1.1.1(critical) The policy extension in the CA certificate does not exist. The policy extension in the User certificate contains one oid of 1.1.1(critical) Assuming all other data is valid, is this a valid certificate chain? It appears to me that the algorithm defined in RFC2459 would determine that this certificate path is valid. ----------- RFC2459 6.1 says: (e) Verify that policy information is consistent with the acceptable policy set: (1) if the certificate policies extension is marked critical, the intersection of the policies extension and the acceptable policy set shall be non-null; (2) the acceptable policy set is assigned the resulting intersection as its new value. (g) Verify that the intersection of the acceptable policy set and the initial policy set is non-null. --------- Personally, I think that all of the certificates in a valid path must have policy extension(critical or non-critical). Am I wrong? QiuYan Kong, Fujitsu Ltd From owner-ietf-pkix@imc.org Fri Jun 30 07:39:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14011 for ; Fri, 30 Jun 2000 07:39:02 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA01717; Fri, 30 Jun 2000 04:33:47 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 30 Jun 2000 04:33:34 -0700 Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01678 for ; Fri, 30 Jun 2000 04:33:33 -0700 (PDT) Received: by balinese.baltimore.ie; id MAA23249; Fri, 30 Jun 2000 12:34:26 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma023156; Fri, 30 Jun 00 12:33:53 +0100 Received: from baltimore.ie (lease212-21.baltimore.ie [192.168.21.212]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA06567; Fri, 30 Jun 2000 12:33:53 +0100 Message-ID: <395C859B.E13B5085@baltimore.ie> Date: Fri, 30 Jun 2000 12:33:47 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: FRousseau@chrysalis-its.com CC: ietf-pkix@imc.org Subject: Re: CRMF encValue Field References: <918C70B01822D411A87400B0D0204DFF22D74B@panda.chrysalis-its.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi Francois, As I said yesterday, I'll check what the folks on Bob's ca-talk list have implemented. I do agree that handling pkcs#11 tokens is desirable, but I would guess is lower priority than not breaking current implementations. So pkcs#11 support (if different from what's implemented already), could either be added to 2510bis as an implenmentation note, or, if it gets complicated, in a separate "pkcs#11 key wrapping in CMP" draft. Let's wait & see what the developers have done. Regards, Stephen. > FRousseau@chrysalis-its.com wrote: > > Steve, > > As agreed yesterday at the PKI Forum meeting in Dublin, could you please check and add some > clarification in the next version of RFC2510bis about what exactly must be encoded in the > "encValue" field of the EncryptedValue structure, which is described in Section 6.4 of CRMF > [RFC2511]. This clarification will become necessary in order to ensure interoperability between > components using hardware or software from different vendors (i.e. clients, RAs and CAs) that > might use this CRMF "encValue" field. > > As discussed, please note that hardware cryptographic module vendors that implement PKCS#11 would > normally use the Cryptoki wrapping mechanism to encrypt any private key that has to be extracted > from their module to go in this "encValue" field. Since Section 11.9 of PKCS#11 v2.01 mandates for > wrapping a private key that: > > "Cryptoki Version 2.01 allows the use of secret keys for wrapping and unwrapping RSA private keys, > Diffie-Hellman private keys, and DSA private keys. For wrapping, a private key is BER-encoded > according to PKCS #8's PrivateKeyInfo ASN.1 type." > > I hope that the type "PrivateKeyInfo" from Section 6 of PKCS#8 is what is currently being > encrypted within this CRMF "encValue" field of the EncryptedValue structure for today CMP > implementations. > > Regards, > > Francois > ___________________________________ > Francois Rousseau > Director of Standards and Conformance > Chrysalis-ITS > 1688 Woodward Drive > Ottawa, Ontario, CANADA, K2C 3R7 > frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 > http://www.chrysalis-its.com Fax. (613) 723-5078 > > -----Original Message----- > From: Francois Rousseau > Sent: Thursday, May 25, 2000 3:42 PM > To: 'Carlisle Adams' > Cc: ietf-pkix@imc.org > Subject: Encryption of Private Keys in CRMF and CMP > > Carlisle, > > In Section 6.4 of RFC 2511 on CRMF, it is indicated that the EncryptedValue field "encValue" is a > BIT STRING, however I could not find any further detail in RFC 2511 nor in RFC 2510bis, which also > use this syntax, about how to create this encrypted value (restricted, in RFC 2510bis, to be > either private keys or certificates). > > Am I missing something? > > I understand that RFC 2511 EncryptedValue field "symmAlg" tells me the symmetric algorithm that > was used to encrypt a private key value and that Appendix B2 of RFC 2510bis mandates that > conforming implementations MUST support 3-DES (3-key-EDE, CBC mode) for this. However, this does > not tell me what exactly is being encrypted. > > Is it a type "PrivateKeyInfo" from Section 6 of PKCS#8 or a type "RSAPrivateKey" from Section > 11.1.2 of PKCS#1 for a RSA private key since RFC 2511 EncryptedValue field "intendedAlg" already > tell me the intended algorithm for which the private key will be used for? > > Thanks in advance for any help. > > Francois > ___________________________________ > Francois Rousseau > Director of Standards and Conformance > Chrysalis-ITS > 1688 Woodward Drive > Ottawa, Ontario, CANADA, K2C 3R7 > frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 > http://www.chrysalis-its.com Fax. (613) 723-5078 -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-ietf-pkix@imc.org Fri Jun 30 11:05:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19040 for ; Fri, 30 Jun 2000 11:05:46 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA06477; Fri, 30 Jun 2000 08:01:20 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 30 Jun 2000 08:00:50 -0700 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06433 for ; Fri, 30 Jun 2000 08:00:50 -0700 (PDT) Received: from [192.168.1.57] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWZ005JG2Y669@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Fri, 30 Jun 2000 07:58:54 -0700 (PDT) Date: Fri, 30 Jun 2000 07:59:09 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <4.2.2.20000629162526.00adfdd0@poptop.llnl.gov> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi Tony, > At 03:03 PM 6/29/00 -0700, Aram Perez wrote: >> Hi Tony, >>> Inescapably, there must be a good OOB procedure somewhere, but >>> each customer would need only the one of their choosing, and it >>> must be of their own choosing, of course, unless someone else >>> is willing to accept the liability of making that decision for >>> them (show of hands?) >> >> If you find that one OOB procedure, let me know. I far as I can tell, you >> need a separate OOB procedure for every self-signed certificate. I raised >> this issue quite a while back: try to find out the root certificate >> fingerprints for Verisign, Thawte or any public CA and try to validate your >> browser root certificates. > > You are right there. In general, our browser (or its distributor) > is the effective root of our trust. What a thought. > > Classic regress problem. You want a secure channel in order to convey > the items that establish the security of another channel. The only > channel that you can trust a priori is the channel that you have with > yourself, (hence the SPKI approach.) > > Hypothetically, (assuming I just give up and assume that my browser's > root certs are "currently" valid,) I could create a self-signed root > cert, use it to certify all of the root-keys in the browser, and thus > establish myself as my (personal) root-over-them-all (solely to prevent > their tampering or replacement). Beyond this, when I felt (for whatever > reason) that CA XYZ was no longer to be trusted, I would simply revoke > MY certification of their public key. But what would be required to > make such processing occur (for what little comfort it might bring?) > > How might I force all chains to reach for my root-cert as endpoint? The issue of how to trust anchor certificates (using my previously stated definition of anchor certificates) is largely being ignored, either by choice or by ignorance. There is no one OOB mechanism to solve this issue, whether you are using PKIX, SPKI, PGP or any other PKI. Regards, Aram Perez From owner-ietf-pkix@imc.org Fri Jun 30 11:45:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19940 for ; Fri, 30 Jun 2000 11:45:03 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA08179; Fri, 30 Jun 2000 08:38:36 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 30 Jun 2000 08:38:32 -0700 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08142 for ; Fri, 30 Jun 2000 08:38:31 -0700 (PDT) Received: from [192.168.1.57] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWZ007RU4LXMC@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Fri, 30 Jun 2000 08:34:47 -0700 (PDT) Date: Fri, 30 Jun 2000 08:34:55 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Content-Transfer-Encoding: 7bit Hi Michael, > God knows I was trying hard to stay away from it :) You can't keep a good man away for long ;-) >>> >>> Inescapably, there must be a good OOB procedure somewhere, but >>> each customer would need only the one of their choosing, and it >>> must be of their own choosing, of course, unless someone else >>> is willing to accept the liability of making that decision for >>> them (show of hands?) >> >> If you find that one OOB procedure, let me know. I far as I >> can tell, you >> need a separate OOB procedure for every self-signed >> certificate. I raised >> this issue quite a while back: try to find out the root certificate >> fingerprints for Verisign, Thawte or any public CA and try to >> validate your >> browser root certificates. > > So you are saying that we must prohibit self-signed TSA certs for the lack > of practical and reliable OOB mechanism? That seems to be the root of the > problem to me. That's partially true, but more to the point, this is PKIX, where, by definition (whether we like it or not), CA issue certificates. > > Well, the same argument would have to apply to the most of self-signed PKI > then, as your experience with Verisign and Co rightly shows. > Following the same logic - should we temporary freeze everything, 'till > there is an OOB that we all agree to trust? > And consequently shut those authorities that do not seem to provide adequate > OOB (or so we reckon)? Who should we start with? any suggestions? As I stated to Tony B., the issue of trusting anchor certificates is largely being ignored, by choice or ignorance. That does not mean that you must freeze everything. Right now the obvious OOB mechanism seems to be the NULL one: don't do an OOB validation. Most folks obviously trust Microsoft and Netscape. If you are satisfied with not doing an OOB validation or trusting in Microsoft and Netscape, then continue with the status quo. > > Out of the bitchy mood now. > > If my clients community decides that my OOB is adequate - why should you > stop my clients from exercising their trust? On the other hand, if a client > decides that my OOB is NOT adequate - it is his/her right not to use my > services. You are right that the clients (and/or relying parties) have the right to trust or not to trust any particular service. But should be make it harder for them to make that decision? > > I just don't see why is it of any concern for us. I would hope that one of the purposes of defining standards is to make it easier and safer to implement and use, and hence our concern. > > I envisage you saying that an average client is a no-brain moron (NBM) with > a tendency to trust anybody, and it is our sacred mission to protect them. Yes, I do believe that we, as non-NBM and security experts, do have some moral responsibility to the NBM to make their use of our systems as easy and safe as possible. > Well - doesn't the same argument apply to a NBM using "any public CA", which > did not happen to be pre-loaded into IE5? Yes it does, and look at the problems that were caused when all those pre-loaded certs expired on December 31, 1999. > Please, be consistent - once you > start talking about NBMs, there is no difference between self-signed CA cert > and self-signed TSA cert. As for non-NBM, we should have some kind of > reliance into OOB and general intellegence of the clients (not a very > technical argument though, I admit :) I am trying to be consistent with respect to PKIX. In PKIX, by definition and whether we like it or not, only CAs issue certificates, not any new service that comes along and wants to issue a self-signed cert for itself. The OOB validation issue applies to any PKI, whether it is PKIX, SPKI, PGP or whatever. Regards, Aram Perez From owner-ietf-pkix@imc.org Fri Jun 30 14:22:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23501 for ; Fri, 30 Jun 2000 14:22:41 -0400 (EDT) Received: from localhost (daemon@localhost) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA15368; Fri, 30 Jun 2000 11:19:52 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 30 Jun 2000 11:19:05 -0700 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15316 for ; Fri, 30 Jun 2000 11:19:04 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA11357 for ; Fri, 30 Jun 2000 11:19:30 -0700 (PDT) Message-Id: <4.2.2.20000630090719.00aa6de0@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 30 Jun 2000 11:26:08 -0700 To: PKIX From: Tony Bartoletti Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-Reply-To: References: < Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe At 08:34 AM 6/30/00 -0700, Aram Perez wrote: >Hi Michael, > > > > I envisage you saying that an average client is a no-brain moron (NBM) with > > a tendency to trust anybody, and it is our sacred mission to protect them. > >Yes, I do believe that we, as non-NBM and security experts, do have some >moral responsibility to the NBM to make their use of our systems as easy and >safe as possible. >I am trying to be consistent with respect to PKIX. In PKIX, by definition >and whether we like it or not, only CAs issue certificates, not any new >service that comes along and wants to issue a self-signed cert for itself. > >The OOB validation issue applies to any PKI, whether it is PKIX, SPKI, PGP >or whatever. Aram, I do appreciate the sentiment that standards should avoid making it default for people to ignore safety (though there may be a limiting tradeoff between "easy" and "safe".) At the very real risk of appearing ignorant, I must ask "What does it take to be a PKIX CA?" Not a big CA, or for-profit CA, or even a trusted CA, but simply a (minimally) PKIX-compliant CA. Does the PKIX standard mandate social compliance in addition to protocol? If, as you describe, the current tack taken by most folks regarding the validation of root-certs is the "Null Option", then it cannot be worse to allow individuals to create their own self-signed anchor, and "certify" these foreign root-certs as they please. The software should comply (that "easy" goal) and I cannot see where safety is reduced in the process. Functionally, it is not far from simply encrypting your browser's root-certs, and having it prompt you for a pass-key at each root-cert usage. It provides both tamper-detection AND control over the otherwise "automatic" trust assumption. The self-signed anchor approach has the advantage of not bothering you when you choose not to be bothered. I recognize that by allowing individuals to create self-certs, and then to "personally certify" (say) Verisign's public key, there is nothing to stop them from performing other mechanical CA functions. They can certify other keys. And other parties can rely upon that certification at their benefit or at their peril. The alternative is to make the very "existence" of a root-cert become the evidence of its trustworthiness. That is, "Only Real CAs can issue certs, and this is a cert, thus it is trustworthy." Building such associations into the (expected) protocol mechanics of PKIX compliance does not serve the cause of safety. IMNSHO, ALL trust calculation should occur over the *nature* of the content, none over the mere existence of the content. Only CAs can issue certificates? Fine. Let there be a billion CAs. Let "trust imply useful-CA", not "CA imply useful-trust". ( shades of Ed Gerck there :) Bitwise, OOB appears hopelessly problematic. It demands prerequisite trust in a channel that cannot be secured computationally. (Even the promise of an inviolably tamperproof quantum cryptographic channel will not serve to establish the identity of the party at the far-end without a previous agreement on a uniquely produceable signature.) Perhaps OOB security can be approached only "statistically", akin to those web sites where each visitor "ranks" the postings they read, and the most popular posts rise to the top. (In retrospect, we have something "like" that already. The "popularity" of IE and Netscape largely dictate the population of extant root-certs. Unfortunately, it is a peculiar sort of trust association, subject to "revocation" at the next software release, and not reflective of daily utility.) ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix@imc.org Fri Jun 30 14:53:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24172 for ; Fri, 30 Jun 2000 14:53:35 -0400 (EDT) Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA16112; Fri, 30 Jun 2000 11:51:38 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Fri, 30 Jun 2000 11:50:01 -0700 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16055 for ; Fri, 30 Jun 2000 11:49:59 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA07774; Fri, 30 Jun 2000 14:50:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <73388857A695D31197EF00508B08F2988A3C17@ntmsg0131.corpmail.telstra.com.au> References: <73388857A695D31197EF00508B08F2988A3C17@ntmsg0131.corpmail.telstra.com.au> Date: Fri, 30 Jun 2000 14:50:09 -0400 To: "Manger, James H" From: Stephen Kent Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH Cc: "'PKIX'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe Jim, I support Denis in his desire to have the TSA check everything it can (syntactically) in a request. Not checking allows the TSA to sign tokens that are just broken. We have seen many examples of broken certs signed by CAs, so I think it worthwhile that we put language in RFCs to require, where possible, that appropriate consistency checks be performed. RFC 2459 has a few statement about relationships among extensions, which gets to the same concerns. We could put in more, or collect them in one place, and make for a better document. I may have lost track of the counter argument here. Why would one not want to have a TSA do the best possible job when it comes to ensuring syntactic consistency re its inputs? Steve Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16055 for ; Fri, 30 Jun 2000 11:49:59 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA07774; Fri, 30 Jun 2000 14:50:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <73388857A695D31197EF00508B08F2988A3C17@ntmsg0131.corpmail.telstra.com.au> References: <73388857A695D31197EF00508B08F2988A3C17@ntmsg0131.corpmail.telstra.com.au> Date: Fri, 30 Jun 2000 14:50:09 -0400 To: "Manger, James H" From: Stephen Kent Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH Cc: "'PKIX'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Jim, I support Denis in his desire to have the TSA check everything it can (syntactically) in a request. Not checking allows the TSA to sign tokens that are just broken. We have seen many examples of broken certs signed by CAs, so I think it worthwhile that we put language in RFCs to require, where possible, that appropriate consistency checks be performed. RFC 2459 has a few statement about relationships among extensions, which gets to the same concerns. We could put in more, or collect them in one place, and make for a better document. I may have lost track of the counter argument here. Why would one not want to have a TSA do the best possible job when it comes to ensuring syntactic consistency re its inputs? Steve Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15316 for ; Fri, 30 Jun 2000 11:19:04 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA11357 for ; Fri, 30 Jun 2000 11:19:30 -0700 (PDT) Message-Id: <4.2.2.20000630090719.00aa6de0@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 30 Jun 2000 11:26:08 -0700 To: PKIX From: Tony Bartoletti Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-Reply-To: References: < Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:34 AM 6/30/00 -0700, Aram Perez wrote: >Hi Michael, > > > > I envisage you saying that an average client is a no-brain moron (NBM) with > > a tendency to trust anybody, and it is our sacred mission to protect them. > >Yes, I do believe that we, as non-NBM and security experts, do have some >moral responsibility to the NBM to make their use of our systems as easy and >safe as possible. >I am trying to be consistent with respect to PKIX. In PKIX, by definition >and whether we like it or not, only CAs issue certificates, not any new >service that comes along and wants to issue a self-signed cert for itself. > >The OOB validation issue applies to any PKI, whether it is PKIX, SPKI, PGP >or whatever. Aram, I do appreciate the sentiment that standards should avoid making it default for people to ignore safety (though there may be a limiting tradeoff between "easy" and "safe".) At the very real risk of appearing ignorant, I must ask "What does it take to be a PKIX CA?" Not a big CA, or for-profit CA, or even a trusted CA, but simply a (minimally) PKIX-compliant CA. Does the PKIX standard mandate social compliance in addition to protocol? If, as you describe, the current tack taken by most folks regarding the validation of root-certs is the "Null Option", then it cannot be worse to allow individuals to create their own self-signed anchor, and "certify" these foreign root-certs as they please. The software should comply (that "easy" goal) and I cannot see where safety is reduced in the process. Functionally, it is not far from simply encrypting your browser's root-certs, and having it prompt you for a pass-key at each root-cert usage. It provides both tamper-detection AND control over the otherwise "automatic" trust assumption. The self-signed anchor approach has the advantage of not bothering you when you choose not to be bothered. I recognize that by allowing individuals to create self-certs, and then to "personally certify" (say) Verisign's public key, there is nothing to stop them from performing other mechanical CA functions. They can certify other keys. And other parties can rely upon that certification at their benefit or at their peril. The alternative is to make the very "existence" of a root-cert become the evidence of its trustworthiness. That is, "Only Real CAs can issue certs, and this is a cert, thus it is trustworthy." Building such associations into the (expected) protocol mechanics of PKIX compliance does not serve the cause of safety. IMNSHO, ALL trust calculation should occur over the *nature* of the content, none over the mere existence of the content. Only CAs can issue certificates? Fine. Let there be a billion CAs. Let "trust imply useful-CA", not "CA imply useful-trust". ( shades of Ed Gerck there :) Bitwise, OOB appears hopelessly problematic. It demands prerequisite trust in a channel that cannot be secured computationally. (Even the promise of an inviolably tamperproof quantum cryptographic channel will not serve to establish the identity of the party at the far-end without a previous agreement on a uniquely produceable signature.) Perhaps OOB security can be approached only "statistically", akin to those web sites where each visitor "ranks" the postings they read, and the most popular posts rise to the top. (In retrospect, we have something "like" that already. The "popularity" of IE and Netscape largely dictate the population of extant root-certs. Unfortunately, it is a peculiar sort of trust association, subject to "revocation" at the next software release, and not reflective of daily utility.) ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08142 for ; Fri, 30 Jun 2000 08:38:31 -0700 (PDT) Received: from [192.168.1.57] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWZ007RU4LXMC@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Fri, 30 Jun 2000 08:34:47 -0700 (PDT) Date: Fri, 30 Jun 2000 08:34:55 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Hi Michael, > God knows I was trying hard to stay away from it :) You can't keep a good man away for long ;-) >>> >>> Inescapably, there must be a good OOB procedure somewhere, but >>> each customer would need only the one of their choosing, and it >>> must be of their own choosing, of course, unless someone else >>> is willing to accept the liability of making that decision for >>> them (show of hands?) >> >> If you find that one OOB procedure, let me know. I far as I >> can tell, you >> need a separate OOB procedure for every self-signed >> certificate. I raised >> this issue quite a while back: try to find out the root certificate >> fingerprints for Verisign, Thawte or any public CA and try to >> validate your >> browser root certificates. > > So you are saying that we must prohibit self-signed TSA certs for the lack > of practical and reliable OOB mechanism? That seems to be the root of the > problem to me. That's partially true, but more to the point, this is PKIX, where, by definition (whether we like it or not), CA issue certificates. > > Well, the same argument would have to apply to the most of self-signed PKI > then, as your experience with Verisign and Co rightly shows. > Following the same logic - should we temporary freeze everything, 'till > there is an OOB that we all agree to trust? > And consequently shut those authorities that do not seem to provide adequate > OOB (or so we reckon)? Who should we start with? any suggestions? As I stated to Tony B., the issue of trusting anchor certificates is largely being ignored, by choice or ignorance. That does not mean that you must freeze everything. Right now the obvious OOB mechanism seems to be the NULL one: don't do an OOB validation. Most folks obviously trust Microsoft and Netscape. If you are satisfied with not doing an OOB validation or trusting in Microsoft and Netscape, then continue with the status quo. > > Out of the bitchy mood now. > > If my clients community decides that my OOB is adequate - why should you > stop my clients from exercising their trust? On the other hand, if a client > decides that my OOB is NOT adequate - it is his/her right not to use my > services. You are right that the clients (and/or relying parties) have the right to trust or not to trust any particular service. But should be make it harder for them to make that decision? > > I just don't see why is it of any concern for us. I would hope that one of the purposes of defining standards is to make it easier and safer to implement and use, and hence our concern. > > I envisage you saying that an average client is a no-brain moron (NBM) with > a tendency to trust anybody, and it is our sacred mission to protect them. Yes, I do believe that we, as non-NBM and security experts, do have some moral responsibility to the NBM to make their use of our systems as easy and safe as possible. > Well - doesn't the same argument apply to a NBM using "any public CA", which > did not happen to be pre-loaded into IE5? Yes it does, and look at the problems that were caused when all those pre-loaded certs expired on December 31, 1999. > Please, be consistent - once you > start talking about NBMs, there is no difference between self-signed CA cert > and self-signed TSA cert. As for non-NBM, we should have some kind of > reliance into OOB and general intellegence of the clients (not a very > technical argument though, I admit :) I am trying to be consistent with respect to PKIX. In PKIX, by definition and whether we like it or not, only CAs issue certificates, not any new service that comes along and wants to issue a self-signed cert for itself. The OOB validation issue applies to any PKI, whether it is PKIX, SPKI, PGP or whatever. Regards, Aram Perez Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06433 for ; Fri, 30 Jun 2000 08:00:50 -0700 (PDT) Received: from [192.168.1.57] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWZ005JG2Y669@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Fri, 30 Jun 2000 07:58:54 -0700 (PDT) Date: Fri, 30 Jun 2000 07:59:09 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <4.2.2.20000629162526.00adfdd0@poptop.llnl.gov> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Hi Tony, > At 03:03 PM 6/29/00 -0700, Aram Perez wrote: >> Hi Tony, >>> Inescapably, there must be a good OOB procedure somewhere, but >>> each customer would need only the one of their choosing, and it >>> must be of their own choosing, of course, unless someone else >>> is willing to accept the liability of making that decision for >>> them (show of hands?) >> >> If you find that one OOB procedure, let me know. I far as I can tell, you >> need a separate OOB procedure for every self-signed certificate. I raised >> this issue quite a while back: try to find out the root certificate >> fingerprints for Verisign, Thawte or any public CA and try to validate your >> browser root certificates. > > You are right there. In general, our browser (or its distributor) > is the effective root of our trust. What a thought. > > Classic regress problem. You want a secure channel in order to convey > the items that establish the security of another channel. The only > channel that you can trust a priori is the channel that you have with > yourself, (hence the SPKI approach.) > > Hypothetically, (assuming I just give up and assume that my browser's > root certs are "currently" valid,) I could create a self-signed root > cert, use it to certify all of the root-keys in the browser, and thus > establish myself as my (personal) root-over-them-all (solely to prevent > their tampering or replacement). Beyond this, when I felt (for whatever > reason) that CA XYZ was no longer to be trusted, I would simply revoke > MY certification of their public key. But what would be required to > make such processing occur (for what little comfort it might bring?) > > How might I force all chains to reach for my root-cert as endpoint? The issue of how to trust anchor certificates (using my previously stated definition of anchor certificates) is largely being ignored, either by choice or by ignorance. There is no one OOB mechanism to solve this issue, whether you are using PKIX, SPKI, PGP or any other PKI. Regards, Aram Perez Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01678 for ; Fri, 30 Jun 2000 04:33:33 -0700 (PDT) Received: by balinese.baltimore.ie; id MAA23249; Fri, 30 Jun 2000 12:34:26 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma023156; Fri, 30 Jun 00 12:33:53 +0100 Received: from baltimore.ie (lease212-21.baltimore.ie [192.168.21.212]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA06567; Fri, 30 Jun 2000 12:33:53 +0100 Message-ID: <395C859B.E13B5085@baltimore.ie> Date: Fri, 30 Jun 2000 12:33:47 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: FRousseau@chrysalis-its.com CC: ietf-pkix@imc.org Subject: Re: CRMF encValue Field References: <918C70B01822D411A87400B0D0204DFF22D74B@panda.chrysalis-its.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Francois, As I said yesterday, I'll check what the folks on Bob's ca-talk list have implemented. I do agree that handling pkcs#11 tokens is desirable, but I would guess is lower priority than not breaking current implementations. So pkcs#11 support (if different from what's implemented already), could either be added to 2510bis as an implenmentation note, or, if it gets complicated, in a separate "pkcs#11 key wrapping in CMP" draft. Let's wait & see what the developers have done. Regards, Stephen. > FRousseau@chrysalis-its.com wrote: > > Steve, > > As agreed yesterday at the PKI Forum meeting in Dublin, could you please check and add some > clarification in the next version of RFC2510bis about what exactly must be encoded in the > "encValue" field of the EncryptedValue structure, which is described in Section 6.4 of CRMF > [RFC2511]. This clarification will become necessary in order to ensure interoperability between > components using hardware or software from different vendors (i.e. clients, RAs and CAs) that > might use this CRMF "encValue" field. > > As discussed, please note that hardware cryptographic module vendors that implement PKCS#11 would > normally use the Cryptoki wrapping mechanism to encrypt any private key that has to be extracted > from their module to go in this "encValue" field. Since Section 11.9 of PKCS#11 v2.01 mandates for > wrapping a private key that: > > "Cryptoki Version 2.01 allows the use of secret keys for wrapping and unwrapping RSA private keys, > Diffie-Hellman private keys, and DSA private keys. For wrapping, a private key is BER-encoded > according to PKCS #8's PrivateKeyInfo ASN.1 type." > > I hope that the type "PrivateKeyInfo" from Section 6 of PKCS#8 is what is currently being > encrypted within this CRMF "encValue" field of the EncryptedValue structure for today CMP > implementations. > > Regards, > > Francois > ___________________________________ > Francois Rousseau > Director of Standards and Conformance > Chrysalis-ITS > 1688 Woodward Drive > Ottawa, Ontario, CANADA, K2C 3R7 > frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 > http://www.chrysalis-its.com Fax. (613) 723-5078 > > -----Original Message----- > From: Francois Rousseau > Sent: Thursday, May 25, 2000 3:42 PM > To: 'Carlisle Adams' > Cc: ietf-pkix@imc.org > Subject: Encryption of Private Keys in CRMF and CMP > > Carlisle, > > In Section 6.4 of RFC 2511 on CRMF, it is indicated that the EncryptedValue field "encValue" is a > BIT STRING, however I could not find any further detail in RFC 2511 nor in RFC 2510bis, which also > use this syntax, about how to create this encrypted value (restricted, in RFC 2510bis, to be > either private keys or certificates). > > Am I missing something? > > I understand that RFC 2511 EncryptedValue field "symmAlg" tells me the symmetric algorithm that > was used to encrypt a private key value and that Appendix B2 of RFC 2510bis mandates that > conforming implementations MUST support 3-DES (3-key-EDE, CBC mode) for this. However, this does > not tell me what exactly is being encrypted. > > Is it a type "PrivateKeyInfo" from Section 6 of PKCS#8 or a type "RSAPrivateKey" from Section > 11.1.2 of PKCS#1 for a RSA private key since RFC 2511 EncryptedValue field "intendedAlg" already > tell me the intended algorithm for which the private key will be used for? > > Thanks in advance for any help. > > Francois > ___________________________________ > Francois Rousseau > Director of Standards and Conformance > Chrysalis-ITS > 1688 Woodward Drive > Ottawa, Ontario, CANADA, K2C 3R7 > frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 > http://www.chrysalis-its.com Fax. (613) 723-5078 -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA22878 for ; Fri, 30 Jun 2000 01:06:18 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id RAA14853 for ; Fri, 30 Jun 2000 17:06:36 +0900 (JST) (envelope-from kongqy@ec.cs.fujitsu.co.jp) Received: from vishnu.ec.cs.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0006-Fujitsu Domain Master) id RAA10580; Fri, 30 Jun 2000 17:06:35 +0900 (JST) Received: from ec.cs.fujitsu.co.jp (cath.ec.cs.fujitsu.co.jp [10.34.199.204]) by vishnu.ec.cs.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.4W5-04/12/98 EC domain mail master) with ESMTP id RAA01987 for ; Fri, 30 Jun 2000 17:06:35 +0900 (JST) Message-ID: <395C5506.D233574B@ec.cs.fujitsu.co.jp> Date: Fri, 30 Jun 2000 17:06:30 +0900 From: Kong QiuYan X-Mailer: Mozilla 4.7 [ja] (WinNT; U) X-Accept-Language: ja MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: certificate chain validation(policy extension) Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Suppose I have a certificate chain consisting of a Root, a CA and a User certificate. The policy extension in the Root certificate contains one oid of 1.1.1(critical) The policy extension in the CA certificate does not exist. The policy extension in the User certificate contains one oid of 1.1.1(critical) Assuming all other data is valid, is this a valid certificate chain? It appears to me that the algorithm defined in RFC2459 would determine that this certificate path is valid. ----------- RFC2459 6.1 says: (e) Verify that policy information is consistent with the acceptable policy set: (1) if the certificate policies extension is marked critical, the intersection of the policies extension and the acceptable policy set shall be non-null; (2) the acceptable policy set is assigned the resulting intersection as its new value. (g) Verify that the intersection of the acceptable policy set and the initial policy set is non-null. --------- Personally, I think that all of the certificates in a valid path must have policy extension(critical or non-critical). Am I wrong? QiuYan Kong, Fujitsu Ltd Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA22292 for ; Fri, 30 Jun 2000 00:50:24 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id JAA20102 for ; Fri, 30 Jun 2000 09:51:17 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 30 Jun 2000 09:51:17 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id JAA05099 for ; Fri, 30 Jun 2000 09:51:15 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id JAA17820 for ietf-pkix@imc.org; Fri, 30 Jun 2000 09:51:15 +0200 (MET DST) Date: Fri, 30 Jun 2000 09:51:15 +0200 (MET DST) Message-Id: <200006300751.JAA17820@emeriau.edelweb.fr> To: ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Currently a CA can have several key usages indicated in its cert (or in some cert given to it) EXCEPT you can newer use a CA key for time stamping. Why is it that a TSA needs a more restrictive handling than a CA? > > I envisage you saying that an average client is a no-brain moron (NBM) with > a tendency to trust anybody, and it is our sacred mission to protect them. > Well - doesn't the same argument apply to a NBM using "any public CA", which > did not happen to be pre-loaded into IE5? Please, be consistent - once you > start talking about NBMs, there is no difference between self-signed CA cert > and self-signed TSA cert. As for non-NBM, we should have some kind of > reliance into OOB and general intellegence of the clients (not a very > technical argument though, I admit :) > > Michael Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA20309 for ; Thu, 29 Jun 2000 23:58:50 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id RAA20418; Fri, 30 Jun 2000 17:03:57 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 30 Jun 2000 16:57:31 +1000 Message-ID: From: Michael Zolotarev To: Aram Perez , PKIX Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Fri, 30 Jun 2000 16:57:31 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" God knows I was trying hard to stay away from it :) > > > > Inescapably, there must be a good OOB procedure somewhere, but > > each customer would need only the one of their choosing, and it > > must be of their own choosing, of course, unless someone else > > is willing to accept the liability of making that decision for > > them (show of hands?) > > If you find that one OOB procedure, let me know. I far as I > can tell, you > need a separate OOB procedure for every self-signed > certificate. I raised > this issue quite a while back: try to find out the root certificate > fingerprints for Verisign, Thawte or any public CA and try to > validate your > browser root certificates. So you are saying that we must prohibit self-signed TSA certs for the lack of practical and reliable OOB mechanism? That seems to be the root of the problem to me. Well, the same argument would have to apply to the most of self-signed PKI then, as your experience with Verisign and Co rightly shows. Following the same logic - should we temporary freeze everything, 'till there is an OOB that we all agree to trust? And consequently shut those authorities that do not seem to provide adequate OOB (or so we reckon)? Who should we start with? any suggestions? Out of the bitchy mood now. If my clients community decides that my OOB is adequate - why should you stop my clients from exercising their trust? On the other hand, if a client decides that my OOB is NOT adequate - it is his/her right not to use my services. I just don't see why is it of any concern for us. I envisage you saying that an average client is a no-brain moron (NBM) with a tendency to trust anybody, and it is our sacred mission to protect them. Well - doesn't the same argument apply to a NBM using "any public CA", which did not happen to be pre-loaded into IE5? Please, be consistent - once you start talking about NBMs, there is no difference between self-signed CA cert and self-signed TSA cert. As for non-NBM, we should have some kind of reliance into OOB and general intellegence of the clients (not a very technical argument though, I admit :) Michael Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19672 for ; Thu, 29 Jun 2000 23:42:30 -0700 (PDT) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA11679 for ; Fri, 30 Jun 2000 16:42:52 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0lYHny; Fri Jun 30 16:42:04 2000 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id QAA24211 for ; Fri, 30 Jun 2000 16:42:04 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdErDBt_; Fri Jun 30 16:41:31 2000 Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id QAA00130 for ; Fri, 30 Jun 2000 16:41:30 +1000 (EST) Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Jun 2000 16:41:29 +1000 Message-ID: <73388857A695D31197EF00508B08F2988A3C17@ntmsg0131.corpmail.telstra.com.au> From: "Manger, James H" To: "'PKIX'" Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH Date: Fri, 30 Jun 2000 16:40:55 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Denis Paul Koning provided sensible arguments for removing the unnecessary checks by the TSA on the messageImprint field. Michael Zolotarev agreed, as did Terry Hayes. No one disagreed. However, the latest timestamp draft does not reflect this agreement. Why not? If more voices are needed I add my agreement. If details of specific text changes are required here goes (apply to draft 09): 1. In section 2.1. "Requirements of the TSA", delete item 7 ("to examine the OID of the one-way..") and renumber the subsequent items. 2. In section 2.1. "Requirements of the TSA", delete the bracketed text in item 8, i.e. the text that refers to item 7. 3. In section 2.4.1 "Request Format", page 4, delete the following sentence: "Its length MUST match the length of the hash value for that algorithm (e.g. 20 bytes for SHA-1 or 16 bytes for MD5)" 4. In section 2.4.1 "Request Format", page 5, delete the following paragraph: "The hash algorithm indicated in the hashAlgorithm field MUST be a known hash algorithm (one-way and collision resistant)." 5. In section 2.4.2 "Response Format", page 8, delete the following text: ", provided that the size of the hash value matches the expected size of the hash algorithm identified in hashAlgorithm" P.S. The changes do not prevent a TSA rejecting a timestamp request if it knows the hash algorithm is bad. Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA09700 for ; Thu, 29 Jun 2000 19:26:57 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id OAA24820 for ; Fri, 30 Jun 2000 14:27:48 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96233206730218>; Fri, 30 Jun 2000 14:27:47 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: Re: algorithm OID esoterica Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Fri, 30 Jun 2000 14:27:47 (NZST) Message-ID: <96233206730218@kahu.cs.auckland.ac.nz> Ari Kermaier writes: >This may not be of interest to many people, but are there any >legitimate/official/semi-real OIDs defined for the Blowfish symmetric >cipher algorithm and the Null cipher (for completeness' sake)? draft-schneier-blowfish-00.txt has: 5. ASN.1 structures and Object Identifiers Blowfish has the following ASN.1 definitions: blowfishECB ALGORITHM PARAMETER NULL ::= {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) algorithm(1) symmetric-encryption(1) 1} blowfishCBC ALGORITHM PARAMETER CBCParameter ::= {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) algorithm(1) symmetric-encryption(1) 2} blowfishCFB ALGORITHM PARAMETER FBParameter ::= {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) algorithm(1) symmetric-encryption(1) 3} blowfishOFB ALGORITHM PARAMETER FBParameter ::= {iso(1) org(3) dod(6) internet(1) private(4) enterprise(1) dds(3029) algorithm(1) symmetric-encryption(1) 4} The parameters are the standard OIW parameters for block cipher chaining modes [OIW] and are reproduced below: CBCParameter ::= IV FBParameter ::= SEQUENCE { iv IV, numberOfBits NumberOfBits } IV ::= OCTET STRING -- 8 octets NumberOfBits ::= INTEGER When used with Blowfish, NumberOfBits should always be 64. Peter. Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08874 for ; Thu, 29 Jun 2000 19:12:36 -0700 (PDT) Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id AAA09576 for ; Fri, 30 Jun 2000 00:55:59 -0500 (EST) (envelope-from arik@phaos.com) Message-Id: <4.2.0.58.20000629221438.00ab3d20@mail.phaos.com> X-Sender: arik@mail.phaos.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 29 Jun 2000 22:21:53 -0400 To: ietf-pkix@imc.org From: Ari Kermaier Subject: algorithm OID esoterica Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed This may not be of interest to many people, but are there any legitimate/official/semi-real OIDs defined for the Blowfish symmetric cipher algorithm and the Null cipher (for completeness' sake)? Ari Kermaier Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA04008 for ; Thu, 29 Jun 2000 17:26:51 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id RAA02829; Thu, 29 Jun 2000 17:27:14 -0700 (PDT) Message-Id: <4.2.2.20000629162526.00adfdd0@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 29 Jun 2000 17:32:53 -0700 To: Aram Perez , PKIX From: Tony Bartoletti Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-Reply-To: References: <4.2.2.20000629145854.00aa9c90@poptop.llnl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:03 PM 6/29/00 -0700, Aram Perez wrote: >Hi Tony, > > Inescapably, there must be a good OOB procedure somewhere, but > > each customer would need only the one of their choosing, and it > > must be of their own choosing, of course, unless someone else > > is willing to accept the liability of making that decision for > > them (show of hands?) > >If you find that one OOB procedure, let me know. I far as I can tell, you >need a separate OOB procedure for every self-signed certificate. I raised >this issue quite a while back: try to find out the root certificate >fingerprints for Verisign, Thawte or any public CA and try to validate your >browser root certificates. You are right there. In general, our browser (or its distributor) is the effective root of our trust. What a thought. Classic regress problem. You want a secure channel in order to convey the items that establish the security of another channel. The only channel that you can trust a priori is the channel that you have with yourself, (hence the SPKI approach.) Hypothetically, (assuming I just give up and assume that my browser's root certs are "currently" valid,) I could create a self-signed root cert, use it to certify all of the root-keys in the browser, and thus establish myself as my (personal) root-over-them-all (solely to prevent their tampering or replacement). Beyond this, when I felt (for whatever reason) that CA XYZ was no longer to be trusted, I would simply revoke MY certification of their public key. But what would be required to make such processing occur (for what little comfort it might bring?) How might I force all chains to reach for my root-cert as endpoint? ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02506 for ; Thu, 29 Jun 2000 16:26:30 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 19:28:03 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF22D74B@panda.chrysalis-its.com> To: stephen.farrell@baltimore.ie Cc: ietf-pkix@imc.org Subject: CRMF encValue Field Date: Thu, 29 Jun 2000 19:27:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE221.AB1BCDEC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFE221.AB1BCDEC Content-Type: text/plain; charset="iso-8859-1" Steve, As agreed yesterday at the PKI Forum meeting in Dublin, could you please check and add some clarification in the next version of RFC2510bis about what exactly must be encoded in the "encValue" field of the EncryptedValue structure, which is described in Section 6.4 of CRMF [RFC2511]. This clarification will become necessary in order to ensure interoperability between components using hardware or software from different vendors (i.e. clients, RAs and CAs) that might use this CRMF "encValue" field. As discussed, please note that hardware cryptographic module vendors that implement PKCS#11 would normally use the Cryptoki wrapping mechanism to encrypt any private key that has to be extracted from their module to go in this "encValue" field. Since Section 11.9 of PKCS#11 v2.01 mandates for wrapping a private key that: "Cryptoki Version 2.01 allows the use of secret keys for wrapping and unwrapping RSA private keys, Diffie-Hellman private keys, and DSA private keys. For wrapping, a private key is BER-encoded according to PKCS #8's PrivateKeyInfo ASN.1 type." I hope that the type "PrivateKeyInfo" from Section 6 of PKCS#8 is what is currently being encrypted within this CRMF "encValue" field of the EncryptedValue structure for today CMP implementations. Regards, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: Francois Rousseau Sent: Thursday, May 25, 2000 3:42 PM To: 'Carlisle Adams' Cc: ietf-pkix@imc.org Subject: Encryption of Private Keys in CRMF and CMP Carlisle, In Section 6.4 of RFC 2511 on CRMF, it is indicated that the EncryptedValue field "encValue" is a BIT STRING, however I could not find any further detail in RFC 2511 nor in RFC 2510bis, which also use this syntax, about how to create this encrypted value (restricted, in RFC 2510bis, to be either private keys or certificates). Am I missing something? I understand that RFC 2511 EncryptedValue field "symmAlg" tells me the symmetric algorithm that was used to encrypt a private key value and that Appendix B2 of RFC 2510bis mandates that conforming implementations MUST support 3-DES (3-key-EDE, CBC mode) for this. However, this does not tell me what exactly is being encrypted. Is it a type "PrivateKeyInfo" from Section 6 of PKCS#8 or a type "RSAPrivateKey" from Section 11.1.2 of PKCS#1 for a RSA private key since RFC 2511 EncryptedValue field "intendedAlg" already tell me the intended algorithm for which the private key will be used for? Thanks in advance for any help. Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFE221.AB1BCDEC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CRMF encValue Field

Steve,

As agreed yesterday at the PKI Forum meeting in = Dublin, could you please check and add some clarification in the next = version of RFC2510bis about what exactly must be encoded in the = "encValue" field of the EncryptedValue structure, which is = described in Section 6.4 of CRMF [RFC2511]. This clarification will = become necessary in order to ensure interoperability between components = using hardware or software from different vendors (i.e. clients, RAs = and CAs) that might use this CRMF "encValue" = field.

As discussed, please note that hardware cryptographic = module vendors that implement PKCS#11 would normally use the Cryptoki = wrapping mechanism to encrypt any private key that has to be extracted = from their module to go in this "encValue" field. Since = Section 11.9 of PKCS#11 v2.01 mandates for wrapping a private key = that:

"Cryptoki Version 2.01 allows the use of secret = keys for wrapping and unwrapping RSA private keys, Diffie-Hellman = private keys, and DSA private keys. For wrapping, a private key is = BER-encoded according to PKCS #8's PrivateKeyInfo ASN.1 = type."

I hope that the type "PrivateKeyInfo" from = Section 6 of PKCS#8 is what is currently being encrypted within this = CRMF "encValue" field of the EncryptedValue structure for = today CMP implementations.

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078


-----Original Message-----
From: Francois Rousseau
Sent: Thursday, May 25, 2000 3:42 PM
To: 'Carlisle Adams'
Cc: ietf-pkix@imc.org
Subject: Encryption of Private Keys in CRMF and = CMP


Carlisle,

In Section 6.4 of RFC 2511 on CRMF, it is indicated = that the EncryptedValue field "encValue" is a BIT STRING, = however I could not find any further detail in RFC 2511 nor in RFC = 2510bis, which also use this syntax, about how to create this encrypted = value (restricted, in RFC 2510bis, to be either private keys or = certificates).

Am I missing something?

I understand that RFC 2511 EncryptedValue field = "symmAlg" tells me the symmetric algorithm that was used to = encrypt a private key value and that Appendix B2 of RFC 2510bis = mandates that conforming implementations MUST support 3-DES (3-key-EDE, = CBC mode) for this. However, this does not tell me what exactly is = being encrypted.

Is it a type "PrivateKeyInfo" from Section = 6 of PKCS#8 or a type "RSAPrivateKey" from Section 11.1.2 of = PKCS#1 for a RSA private key since RFC 2511 EncryptedValue field = "intendedAlg" already tell me the intended algorithm for = which the private key will be used for?

Thanks in advance for any help.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01BFE221.AB1BCDEC-- Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02125 for ; Thu, 29 Jun 2000 16:06:19 -0700 (PDT) Received: from [192.168.1.57] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWX0010IUP2R2@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 29 Jun 2000 16:03:03 -0700 (PDT) Date: Thu, 29 Jun 2000 15:03:36 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <4.2.2.20000629145854.00aa9c90@poptop.llnl.gov> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Hi Tony, > At 12:40 PM 6/29/00 -0700, Aram Perez wrote: >> Hi Rich, >>> 3 Repeat step 2 with "every" CA a potential customer might know. >> >> I doubt your potential customers will want many CAs. Again, for every CA >> they want, they have to have an OOB mechanism to validate the root >> certificate. > > I don't think Rich meant that "a" potential customer may want to > employ many different CAs, but rather that he must deal with the > union of the set of CAs trusted by his set of customers, right? Yes that is correct. But that is the PKIX model. > > Inescapably, there must be a good OOB procedure somewhere, but > each customer would need only the one of their choosing, and it > must be of their own choosing, of course, unless someone else > is willing to accept the liability of making that decision for > them (show of hands?) If you find that one OOB procedure, let me know. I far as I can tell, you need a separate OOB procedure for every self-signed certificate. I raised this issue quite a while back: try to find out the root certificate fingerprints for Verisign, Thawte or any public CA and try to validate your browser root certificates. Regards, Aram Perez Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01478 for ; Thu, 29 Jun 2000 15:25:15 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id PAA03046; Thu, 29 Jun 2000 15:25:27 -0700 (PDT) Message-Id: <4.2.2.20000629151343.00ad4490@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 29 Jun 2000 15:31:06 -0700 To: Aram Perez , PKIX From: Tony Bartoletti Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-Reply-To: References: <395B6DFB.67374B30@caveosystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:40 PM 6/29/00 -0700, Aram Perez wrote: >Hi Rich, > > >> Why do you want to force me to figure out the OOB mechanism for every new > >> PKIX service? > > > > I don't. I want it to be possible. Surely you see the difference. > >Yes I see the difference. But the more possibilities you have, the more >potential for security breakdown there is, i.e. someone doesn't do their due >diligence with the OOB mechanism. On Aram's side, I envision a large enterprise dealing routinely with signature verifications of all manner. In such a case, it would certainly make sense to have the TSA key be similarly certified, rather than invoking an additional OOB mechanism. On Rich's side, I envision a dedicated operation that had purely a need for a secured timestamp. In any case, some TSA must be independently trusted for this operation. If the TS-client has to form a secure OOB conveyance, and could do so directly with the TSA, it does seem "unnatural" to require that they instead seek a CA to trust, and require this TSA to have their key certified by this particular choice of CA. (Otherwise, their choice of TSA becomes restricted to those whose keys have been certified by the "trusted" CAs, if any.) Granted, for future RPs who need to make verifications, it is a question of whether the TSA went out of business first, and the CA second, or the TSA outlived the CA. Are we betting on relative longevity here? ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00961 for ; Thu, 29 Jun 2000 15:01:37 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id PAA18318; Thu, 29 Jun 2000 15:01:57 -0700 (PDT) Message-Id: <4.2.2.20000629145854.00aa9c90@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 29 Jun 2000 15:07:36 -0700 To: Aram Perez , PKIX From: Tony Bartoletti Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-Reply-To: References: <395B6DFB.67374B30@caveosystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:40 PM 6/29/00 -0700, Aram Perez wrote: >Hi Rich, > > 3 Repeat step 2 with "every" CA a potential customer might know. > >I doubt your potential customers will want many CAs. Again, for every CA >they want, they have to have an OOB mechanism to validate the root >certificate. I don't think Rich meant that "a" potential customer may want to employ many different CAs, but rather that he must deal with the union of the set of CAs trusted by his set of customers, right? Inescapably, there must be a good OOB procedure somewhere, but each customer would need only the one of their choosing, and it must be of their own choosing, of course, unless someone else is willing to accept the liability of making that decision for them (show of hands?) ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00438 for ; Thu, 29 Jun 2000 14:38:29 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id OAA03749; Thu, 29 Jun 2000 14:38:24 -0700 (PDT) Message-Id: <4.2.2.20000629133613.00a9f950@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 29 Jun 2000 14:44:03 -0700 To: Rich Salz , ghilborn@csc.com From: Tony Bartoletti Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Cc: ietf-pkix@imc.org In-Reply-To: <395B976E.CCA3AC43@caveosystems.com> References: <8525690D.005E86BD.00@csc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:37 PM 6/29/00 -0400, Rich Salz wrote: > > If the CP under which the CA operates says that it certifies identity and > > binding of that to a public key, then that is all it does. > >And that's pretty much indistinguishable from self-signed, no? >Actually, it's "less secure." Self-signed is proof-of-possesion, >while the CA you describe means "I trust that you saw >proof-of-possesion." > /r$ Even a (supposed) CA that attests to POP is of no value if you do not first (1) trust that CA, and (2) trust that you actually have a certificate issued by that CA. Both sides of this argument make good points in their isolation. I must apply a (naive, dumb) usage example to clarify the issues in my own mind. I imagine some poor soul who discovers they must rely critically upon a particular timestamped piece of data, the timestamp itself a critical value. While simultaneously demonstrating my ignorance of the protocols and procedures that might be in place, I think I am not too far off in recognizing that the following "logical" operations must occur, in one or another order: 1. Obtain a public key value for which the TS signature verifies. (Call this key the TS-Public). (This establishes that the signer, whoever in the world they might be), possessed the corresponding private key, and (we must assume) effected the TS signature. 2. Obtain a certificate (self-signed or otherwise) that hopes to represent a binding of the TS-Public with a set of name- like attributes. In our case, the name is "TS-R-US". (My boss TOLD me that TS-R-US is the TSA to trust.) So far, so good... Now, what are the possible avenues of attack, for which either "self-signed" or "CA-signed" is intended to be a better remedy? In order for a fraud to be perpetrated, we assume it is the fraudster who must have possessed and signed the timestamp. An attacker, knowing our penchant to trust "TS-R-US", would need to a. Create a TS-signing key pair (easy) b. Formulate a certificate attesting to the binding of this keypair with the name "TS-R-US", EITHER in self-signed fashion, or else by another ersatz key-pair/cert appearing as the (well-known;) CA "AnyCerts.com". (Yes, my boss SAID to trust "AnyCerts.com") c. Then (How?) circulate/distribute this/these certificates in such a fashion that the poor soul verifying the timestamp in question is sure to run across them first. Of course, in the case of "AnyCerts.com", that certificate is itself either self-signed, or invokes a further chain of verification. But eventually the buck stops. Beyond the mere mechanics of verification, there must be an established place where the buck is to stop. That place SHOULD be anywhere the RP chooses it to be, I would think. After all, they are the Relying Party. Similarly, each RP will need to apply the "discovery procedures" that they feel serve to satisfy their own operational and security needs. In light of this, I am not convinced that any one "solution" has a hands-down advantage for all reasonable use-cases. Comments? ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29457 for ; Thu, 29 Jun 2000 13:58:21 -0700 (PDT) Received: from [192.168.1.57] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWX00JS8OXKNC@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 29 Jun 2000 13:58:33 -0700 (PDT) Date: Thu, 29 Jun 2000 12:58:11 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <27FF4FAEA8CDD211B97E00902745CBE235E2EF@seine.valicert.com> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Hi Peter, While I mostly agree with you, this is the PKIX (where the X is for X.509) with is by definition hierarchical (or "parochial" as you put it). I'm not sure where this notion of "delegation of authority via certificates" comes from or the concept of "trust me, I have a certificate from XYZ (a CA)", but I certain am not a believer or practitioner of it. In a PKIX world, I only want a CA to bind some identity and a public key. I will establish authority and trust via other mechanisms that are not necessarily tied to a CA and/or certificates. Regards, Aram Perez > Rich/Aram, > > The OCSP model got it - the control constructs - about right, I > suggest. There, a key management model was embedded in the RFC that > leveraged both hierarchical control systems theory (2459) and > non-control-oriented constructs for authenticating the public > keys of the responder to the service user. > > OCSP used a specific set of concepts for orchestrating > the control relationships between the parties. These went > beyond the notion of "delegation of authority via > certificates" - a parochial construct from the proprietary system > security designs of the late 70s and 80s - a reflection of a certain > era of designed-in integrity for distributed systems. > > TSA should do the same as OCSP, I suggest. The simplistic military > security model in which TSAs are "granted authority to act" by > a CA is doubtfully sufficient for the Internet environment > that we profile here. The commercial, political and > practical realities make such a simple model as impractical > as the same model was for OCSP. > > I doubt we would now have the various validation networks that > we see popping up if the OCSP standard had not had > the flexibility to adapt to various ideas of control, as > decided by the deployment community. OCSP > enabled us (a significant OCSP vendor/user community now) to > deploy switched, proxied, cached, pushed, pulled and delegated > forms of validation authorities (OCSP responders) as the > risk management culture demanded. > > To engender a successful, commercially-driven, multi-vendor, > value-adding, open TSA industry, we should perhaps follow the > OCSP lead. We should again use interworking-standards consensus to > help form another round of open, Internet infrastructure. Ensuring > that there are various models of control - that relying parties apply > under their own models of risk management - seems vital: only > those Internet security standards with the required degree of openness > in the control area seem to get adopted in practice. > > Peter. > > -----Original Message----- > From: Rich Salz [mailto:rsalz@caveosystems.com] > Sent: Thursday, June 29, 2000 8:41 AM > To: Aram Perez > Cc: PKIX > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > > >> Why do you want to force me to figure out the OOB mechanism for every new >> PKIX service? > > I don't. I want it to be possible. Surely you see the difference. > > Without a self-signed cert, my service has to either > 1 Run a CA, doubling the amount of private key material I maintain; or > 2 Go to someone else's CA, who might be a competitor, and convince > them to perform the due diligence necessary to certify me as a TSA; > or > 3 Repeat step 2 with "every" CA a potential customer might know. > > I don't believe it's reasonable claim that just because it's a CA, it is > qualified to certify TSA usage. "Trusted to sign end-entitities without > these eKU values" is not a feasible trust model. > /r$ Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29438 for ; Thu, 29 Jun 2000 13:58:12 -0700 (PDT) Received: from [192.168.1.57] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWX00GFQOJJ6D@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 29 Jun 2000 13:50:08 -0700 (PDT) Date: Thu, 29 Jun 2000 12:49:50 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <8525690D.005E86BD.00@csc.com> To: ghilborn@csc.com, rsalz@caveosystems.com Cc: ietf-pkix@imc.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 GHilborn wrote: > If the CP under which the CA operates says that it certifies identity and > binding of that to a public key, then that is all it does. The validity or > security or accuracy, etc. of whatever service a business operates under that > identity (e.g., time sever, ocsp responder, web information server, etc.) is > NOT what a CA "certifies." So isn't the only "due-diligence" required of the > CA > that of certifing the valid business identity and private key possession of > the > public key bound into the certificate of the TSA? The accuracy, availability, > etc. of TSA service is expressed in their own policy/contract with their > customers, just as is the privacy policy for a web server to which a CA issues > a certificate. Well stated! I'm sure there are a number of web-based stores that Verisign issued certificates to that are no longer in business. The same will happen with TSAs, not all of them will exist after a few years (whether or not they issued self-signed certificates). Aram Perez > -GH > > > > > rsalz@caveosystems.com on 06/29/2000 11:40:43 AM > > To: aram@pacbell.net > cc: ietf-pkix@imc.org (bcc: Gene Hilborn/DEF/CSC) > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > > > >> Why do you want to force me to figure out the OOB mechanism for every new >> PKIX service? > > I don't. I want it to be possible. Surely you see the difference. > > Without a self-signed cert, my service has to either > 1 Run a CA, doubling the amount of private key material I maintain; or > 2 Go to someone else's CA, who might be a competitor, and convince > them to perform the due diligence necessary to certify me as a TSA; or > 3 Repeat step 2 with "every" CA a potential customer might know. > > I don't believe it's reasonable claim that just because it's a CA, it is > qualified to certify TSA usage. "Trusted to sign end-entitities without > these eKU values" is not a feasible trust model. > /r$ > > > > Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29012 for ; Thu, 29 Jun 2000 13:42:42 -0700 (PDT) Received: from [192.168.1.57] ([208.233.228.110]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWX00GHQO3Y85@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 29 Jun 2000 13:40:48 -0700 (PDT) Date: Thu, 29 Jun 2000 12:40:31 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <395B6DFB.67374B30@caveosystems.com> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Hi Rich, >> Why do you want to force me to figure out the OOB mechanism for every new >> PKIX service? > > I don't. I want it to be possible. Surely you see the difference. Yes I see the difference. But the more possibilities you have, the more potential for security breakdown there is, i.e. someone doesn't do their due diligence with the OOB mechanism. > > Without a self-signed cert, my service has to either > 1 Run a CA, doubling the amount of private key material I maintain; or In my opinion, this should NOT be an option. > 2 Go to someone else's CA, who might be a competitor, and convince > them to perform the due diligence necessary to certify me as a TSA; or This is the correct option. That is why they are in business: to certify public keys. And any CA, whether or not it signs your TSA key and whether or not a TSA can issue self-signed roots, is a potential competitor. Look at all the non-CA things Verisign is doing now days. Besides, a CA should not certify you as a TSA, it should certify your TSA public key. If I want to use your service, I will not go to the CA that signed your key to determine whether or not your TSA service is valid. > 3 Repeat step 2 with "every" CA a potential customer might know. I doubt your potential customers will want many CAs. Again, for every CA they want, they have to have an OOB mechanism to validate the root certificate. > > I don't believe it's reasonable claim that just because it's a CA, it is > qualified to certify TSA usage. "Trusted to sign end-entitities without > these eKU values" is not a feasible trust model. See my comment under option 2. Regards, Aram Perez Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA26953 for ; Thu, 29 Jun 2000 11:37:42 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 0487337; Thu, 29 Jun 2000 14:38:21 -0400 (EDT) Sender: rsalz Message-ID: <395B976E.CCA3AC43@caveosystems.com> Date: Thu, 29 Jun 2000 14:37:34 -0400 From: Rich Salz X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ghilborn@csc.com CC: ietf-pkix@imc.org Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: <8525690D.005E86BD.00@csc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 > If the CP under which the CA operates says that it certifies identity and > binding of that to a public key, then that is all it does. And that's pretty much indistinguishable from self-signed, no? Actually, it's "less secure." Self-signed is proof-of-possesion, while the CA you describe means "I trust that you saw proof-of-possesion." /r$ Received: from ponyexpress7.csc.com (ponyexpress7.csc.com [208.219.64.208]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24908 for ; Thu, 29 Jun 2000 10:11:44 -0700 (PDT) From: ghilborn@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress7.csc.com with smtp (Exim 2.12 #1) id 137hrA-00045L-01 for ietf-pkix@imc.org; Thu, 29 Jun 2000 13:12:04 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525690D.005E8712 ; Thu, 29 Jun 2000 13:12:29 -0400 X-Lotus-FromDomain: CSC To: rsalz@caveosystems.com cc: ietf-pkix@imc.org Message-ID: <8525690D.005E86BD.00@csc.com> Date: Thu, 29 Jun 2000 13:11:27 -0400 Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline If the CP under which the CA operates says that it certifies identity and binding of that to a public key, then that is all it does. The validity or security or accuracy, etc. of whatever service a business operates under that identity (e.g., time sever, ocsp responder, web information server, etc.) is NOT what a CA "certifies." So isn't the only "due-diligence" required of the CA that of certifing the valid business identity and private key possession of the public key bound into the certificate of the TSA? The accuracy, availability, etc. of TSA service is expressed in their own policy/contract with their customers, just as is the privacy policy for a web server to which a CA issues a certificate. -GH rsalz@caveosystems.com on 06/29/2000 11:40:43 AM To: aram@pacbell.net cc: ietf-pkix@imc.org (bcc: Gene Hilborn/DEF/CSC) Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > Why do you want to force me to figure out the OOB mechanism for every new > PKIX service? I don't. I want it to be possible. Surely you see the difference. Without a self-signed cert, my service has to either 1 Run a CA, doubling the amount of private key material I maintain; or 2 Go to someone else's CA, who might be a competitor, and convince them to perform the due diligence necessary to certify me as a TSA; or 3 Repeat step 2 with "every" CA a potential customer might know. I don't believe it's reasonable claim that just because it's a CA, it is qualified to certify TSA usage. "Trusted to sign end-entitities without these eKU values" is not a feasible trust model. /r$ Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24519 for ; Thu, 29 Jun 2000 10:01:14 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FWX00C01DZ5U9@ext-mail.valicert.com> for ietf-pkix@imc.org; Thu, 29 Jun 2000 10:01:53 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FWX00COZDZ5CT@ext-mail.valicert.com>; Thu, 29 Jun 2000 10:01:53 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 09:54:55 -0700 Content-return: allowed Date: Thu, 29 Jun 2000 09:54:54 -0700 From: Peter Williams Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] To: "'Rich Salz'" , Aram Perez Cc: PKIX Message-id: <27FF4FAEA8CDD211B97E00902745CBE235E2EF@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Rich/Aram, The OCSP model got it - the control constructs - about right, I suggest. There, a key management model was embedded in the RFC that leveraged both hierarchical control systems theory (2459) and non-control-oriented constructs for authenticating the public keys of the responder to the service user. OCSP used a specific set of concepts for orchestrating the control relationships between the parties. These went beyond the notion of "delegation of authority via certificates" - a parochial construct from the proprietary system security designs of the late 70s and 80s - a reflection of a certain era of designed-in integrity for distributed systems. TSA should do the same as OCSP, I suggest. The simplistic military security model in which TSAs are "granted authority to act" by a CA is doubtfully sufficient for the Internet environment that we profile here. The commercial, political and practical realities make such a simple model as impractical as the same model was for OCSP. I doubt we would now have the various validation networks that we see popping up if the OCSP standard had not had the flexibility to adapt to various ideas of control, as decided by the deployment community. OCSP enabled us (a significant OCSP vendor/user community now) to deploy switched, proxied, cached, pushed, pulled and delegated forms of validation authorities (OCSP responders) as the risk management culture demanded. To engender a successful, commercially-driven, multi-vendor, value-adding, open TSA industry, we should perhaps follow the OCSP lead. We should again use interworking-standards consensus to help form another round of open, Internet infrastructure. Ensuring that there are various models of control - that relying parties apply under their own models of risk management - seems vital: only those Internet security standards with the required degree of openness in the control area seem to get adopted in practice. Peter. -----Original Message----- From: Rich Salz [mailto:rsalz@caveosystems.com] Sent: Thursday, June 29, 2000 8:41 AM To: Aram Perez Cc: PKIX Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > Why do you want to force me to figure out the OOB mechanism for every new > PKIX service? I don't. I want it to be possible. Surely you see the difference. Without a self-signed cert, my service has to either 1 Run a CA, doubling the amount of private key material I maintain; or 2 Go to someone else's CA, who might be a competitor, and convince them to perform the due diligence necessary to certify me as a TSA; or 3 Repeat step 2 with "every" CA a potential customer might know. I don't believe it's reasonable claim that just because it's a CA, it is qualified to certify TSA usage. "Trusted to sign end-entitities without these eKU values" is not a feasible trust model. /r$ Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA14477 for ; Thu, 29 Jun 2000 08:40:50 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 0336766; Thu, 29 Jun 2000 11:41:31 -0400 (EDT) Sender: rsalz Message-ID: <395B6DFB.67374B30@caveosystems.com> Date: Thu, 29 Jun 2000 11:40:43 -0400 From: Rich Salz X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Aram Perez CC: PKIX Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 > Why do you want to force me to figure out the OOB mechanism for every new > PKIX service? I don't. I want it to be possible. Surely you see the difference. Without a self-signed cert, my service has to either 1 Run a CA, doubling the amount of private key material I maintain; or 2 Go to someone else's CA, who might be a competitor, and convince them to perform the due diligence necessary to certify me as a TSA; or 3 Repeat step 2 with "every" CA a potential customer might know. I don't believe it's reasonable claim that just because it's a CA, it is qualified to certify TSA usage. "Trusted to sign end-entitities without these eKU values" is not a feasible trust model. /r$ Received: from mailcity.com (fes-qout.whowhere.com [209.1.236.7]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA26164 for ; Wed, 28 Jun 2000 21:05:34 -0700 (PDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Wed Jun 28 21:05:44 2000 To: ietf-pkix@imc.org Date: Wed, 28 Jun 2000 21:05:44 -0700 From: "chandrasekaran natarajan" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: chandrasekaran_n@mailcity.com X-Mailer: MailCity Service Subject: hello world ! X-Sender-Ip: 202.144.10.93 Organization: MailCity (http://www.mailcity.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Hello all, These days I am not getting any mails from this forum .. Is this forum On ? chandar Send FREE Greetings for Father's Day--or any day! Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA00546 for ; Wed, 28 Jun 2000 06:06:45 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA01572; Wed, 28 Jun 2000 15:07:17 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 28 Jun 2000 15:07:18 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA24636; Wed, 28 Jun 2000 15:07:16 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA16858; Wed, 28 Jun 2000 15:07:16 +0200 (MET DST) Date: Wed, 28 Jun 2000 15:07:16 +0200 (MET DST) Message-Id: <200006281307.PAA16858@emeriau.edelweb.fr> To: ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: Re: TSP-09 I forgot : The text says: When the accuracy optional field is not present, then the accuracy may be available through other means, e.g. the PolicyInformation. The text does not indicate the default value for accuracy. Appendix C says: Security considerations: Carries a request for a timestamp and the response. The response will be cryptographically signed. Actually only a part of the response is signed. Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA29045 for ; Wed, 28 Jun 2000 05:36:49 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA01318; Wed, 28 Jun 2000 14:37:30 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 28 Jun 2000 14:37:30 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA24549; Wed, 28 Jun 2000 14:37:28 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA16846; Wed, 28 Jun 2000 14:37:27 +0200 (MET DST) Date: Wed, 28 Jun 2000 14:37:27 +0200 (MET DST) Message-Id: <200006281237.OAA16846@emeriau.edelweb.fr> To: ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: Re: TSP-09 > > Modifications to say that a modified Token may be returned when the > status is one (grantedWithMods), e.g. when some extensions have been > incorporated in a way that is slightly different from the request. Note that the status is not part of the token, and it is not signed. It should be made clear that grantedWithMods can only be seen as a hint in order to indicate to the client, that the token may not be what had been asked for. Anyway, a client has to verify all the fields in the token, thus this status doesn't really give additional information. It is not specified in what situation a TSA would set revocationWarning (4), -- this message contains a warning that a revocation is -- imminent revocationNotification (5), -- notification that a revocation has occurred and addInfoNotAvailable (17) -- the additional information requested could not be understood -- or is not available That latter I imagine to see in case of extensions, for example. > It is now time to send this document to the IESG. There are still > opportunities to make minor changes to the document when it becomes > a Standard, at least six months after it becomes Proposed Standard. Hm. The text references a non existing specification: A TSA's certificate MAY contain a Subject Information Access (SIA) extension [son of RFC2459] in order to convey the method of contacting the TSA. The accessMethod field in this extension MUST contain the OID id-ad-timestamping: At least, I propose the following change: A TSA's certificate MAY contain a Subject Information Access (SIA) extension [son of RFC2459]. In order to convey the method of contacting the TSA, the accessMethod field in this extension MUST contain the OID id-ad-timestamping: The following comment should be changed if one uses a SIA: -- Authority Information Access for TSA Besides that, I do not think that a SIA is necessary, it is sufficient to slightly modify the AIA definition by saying that the exact meaning is defined by the definition of the access method, i.e., whether and how it is related to the subject or the issuer. /P Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00218 for ; Tue, 27 Jun 2000 03:43:28 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06289; Tue, 27 Jun 2000 06:44:06 -0400 (EDT) Message-Id: <200006271044.GAA06289@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-cmp-transport-protocols-00.txt Date: Tue, 27 Jun 2000 06:44:06 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Transport Protocols for CMP Author(s) : A. Kapoor, R. Tschalar Filename : draft-ietf-pkix-cmp-transport-protocols-00.txt Pages : 10 Date : 26-Jun-00 This document describes how to layer Certificate Management Protocols [CMP] over various transport protocols. The key words 'MUST','MUST NOT', 'REQUIRED', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. This document version corresponds to the draft-ietf-pkix-cmp-transports-03.txt published and discussed in the PKI Forum interoperability mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-cmp-transport-protocols-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-cmp-transport-protocols-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000626112350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-cmp-transport-protocols-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-cmp-transport-protocols-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000626112350.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21097; Mon, 26 Jun 2000 11:38:17 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id LAA10970; Mon, 26 Jun 2000 11:36:22 -0700 (PDT) Message-Id: <4.2.2.20000626112651.00ada240@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 26 Jun 2000 11:42:07 -0700 To: Philip Hallam-Baker , "'Ben Laurie'" , Bob Jueneman From: Tony Bartoletti Subject: RE: Do people have something against RSA? Cc: ietf-pkix@imc.org, phoffman@imc.org In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F408EB7E@vhqpostal.verisign. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I have to agree with Phillip and Ben as well. The USPTO seems way-behind the times when it comes to "software" and "web" inventions. If you were the lucky one to first think of the idea of coordinating web auctions (eBay) you just about have the market sewn up. Just try to start your own such service if you want to know what an army of lawyers looks like. They (PTO) seem to think anything transferred to "the web" = "new invention". At minimum, I would like to see such "patents" awarded for at most a one-year period (i.e., adjusted to "cyber-time".) With an adequate review, that should give patent-holders time to leverage their IP into a market advantage. But if all they can produce with their one-year head start are lawsuits, "times up". ___tony___ At 10:17 AM 6/26/00 -0700, Philip Hallam-Baker wrote: >I agree with Ben, burn down the PTO. Patents are in any case a sixteenth >century method of supporting innovation. To equate them with >'capitalism' is ridiculous. > >Since when was appealing to the government to grant you a twenty year >monopoly an intrinsic part of free market competition? > > >The problem is that the US PTO is systematically incompetent. The lack >of prior public review utterly compromises the patents issued. No other >country has such a ridiculous scheme. > >The lack of public review is doubly iniquitous. It should be possible >for me to determine through due dilligence what IP claims might impinge >upon a proposed product. The closed review permits the 'submarine >patent' strategy. Keep the patent in process for ten years and rewrite >it after the standards have been set. > >The poor standard of review at the US PTO hurts genuine applicants too. >Hold up a US PTO patent and you don't have half the credibility you have >with a UK, French or German one. > >Anyone here believe Unisys deserve a patent royalty on Compuserve's Gif >format? Compuserve were entirely unaware that their standard might >infringe. Had they known that Unisys had a patent they could easily have >avoided the specific inventions claimed. > > >Has anyone considered that a person making a bogus patent application >might be held liable under a private suit for conversion in fraud? > > Phill Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19716; Mon, 26 Jun 2000 10:19:41 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA01649; Mon, 26 Jun 2000 10:19:05 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 10:17:51 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EB7E@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Ben Laurie'" , Bob Jueneman Cc: ietf-pkix@imc.org, phoffman@imc.org Subject: RE: Do people have something against RSA? Date: Mon, 26 Jun 2000 10:17:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0019_01BFDF71.12D65C80" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01BFDF71.12D65C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I agree with Ben, burn down the PTO. Patents are in any case a sixteenth century method of supporting innovation. To equate them with 'capitalism' is ridiculous. Since when was appealing to the government to grant you a twenty year monopoly an intrinsic part of free market competition? The problem is that the US PTO is systematically incompetent. The lack of prior public review utterly compromises the patents issued. No other country has such a ridiculous scheme. The lack of public review is doubly iniquitous. It should be possible for me to determine through due dilligence what IP claims might impinge upon a proposed product. The closed review permits the 'submarine patent' strategy. Keep the patent in process for ten years and rewrite it after the standards have been set. The poor standard of review at the US PTO hurts genuine applicants too. Hold up a US PTO patent and you don't have half the credibility you have with a UK, French or German one. Anyone here believe Unisys deserve a patent royalty on Compuserve's Gif format? Compuserve were entirely unaware that their standard might infringe. Had they known that Unisys had a patent they could easily have avoided the specific inventions claimed. Has anyone considered that a person making a bogus patent application might be held liable under a private suit for conversion in fraud? Phill ------=_NextPart_000_0019_01BFDF71.12D65C80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyNjE3MTg1M1owIwYJKoZI hvcNAQkEMRYEFEFJSZGIAaHjblw7QPz5BvcWoc5PMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAXl3OQxdPPBnK2RrX66MHsBxV2A6brLtzBbYnfkpaZmjr6VRJSOswsMqMqFaq6XdV b4GLxf2NQirTpMxys+vneQy2u+P0ArssD3aF1FKcPUjpxfpcWUE7RDGjF+CHFGpNPe3IltpcyfAS tjabxF9XAzH/6mpp2D935lwvUwsBG/YAAAAAAAA= ------=_NextPart_000_0019_01BFDF71.12D65C80-- Received: from maex02.security.com (machine111.netegrity.com [63.73.77.111] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11519 for ; Mon, 26 Jun 2000 07:47:08 -0700 (PDT) Received: by maex02.netegrity.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 11:03:04 -0400 Message-ID: From: "Lutz, Lisa" To: ietf-pkix@imc.org Subject: unsubsribe Date: Mon, 26 Jun 2000 11:03:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Received: from postino.blockade.com (mailgw.blockade.com [204.225.93.196]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11079 for ; Mon, 26 Jun 2000 07:33:48 -0700 (PDT) Received: by mailgw.blockade.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 10:36:49 -0400 Message-ID: <60A30A0BD275D211B8F1006097E472851AC2F9@mailgw.blockade.com> From: "Mason, Shane" To: ietf-pkix@imc.org Subject: unsubscribe Date: Mon, 26 Jun 2000 10:36:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDF7B.F61DCEF0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDF7B.F61DCEF0 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01BFDF7B.F61DCEF0 Content-Type: text/html; charset="iso-8859-1"
unsubscribe
------_=_NextPart_001_01BFDF7B.F61DCEF0-- Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10060 for ; Mon, 26 Jun 2000 06:42:59 -0700 (PDT) Received: from [207.215.86.188] by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWR00F1NKRYCC@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Mon, 26 Jun 2000 06:43:11 -0700 (PDT) Date: Mon, 26 Jun 2000 06:43:50 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <39565606.3DB590E2@caveosystems.com> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Hi Rich, >> So you want any user of a PKIX service to have to figure out a OOB mechanism >> for each provider of the service to verify the self-signed certificate? > > Not at all. > > I want it to be *possible* to start an independant PKIX service. > > Let me turn the question around: why do you feel it necessary to force me > to run a CA? I've never stated that I want you to run a CA for each PKIX service. I think the issuance of certificates should be handled by a CA, not every PKIX service that pops up. Why do you want to force me to figure out the OOB mechanism for every new PKIX service? You, most of the folks on this list and I may know how to do that, but I doubt my mother or grandmother would know how to. Regards, Aram Perez Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08820 for ; Mon, 26 Jun 2000 05:44:48 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA254580 for ; Mon, 26 Jun 2000 14:48:43 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA06442 for ; Mon, 26 Jun 2000 14:44:50 +0200 Message-ID: <39575042.6692BACA@bull.net> Date: Mon, 26 Jun 2000 14:44:50 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: IETF-PXIX Subject: TSP-09 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I took advantage of a pause on the mailing list about TSP, to post a new draft now available at: http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-09.txt The main reason to issue a new draft was to correct the syntax of PKIStatus which was missing one line, i.e. statusString PKIFreeText OPTIONAL, :-( At the same time, the following changes have been made: Turn some "shall" into "SHALL". Modifications to say that a modified Token may be returned when the status is one (grantedWithMods), e.g. when some extensions have been incorporated in a way that is slightly different from the request. The status 6 (KeyUpdateWarning) has been deleted since it bears a different meaning in CMP and cannot be returned in our case. Modification of the sentence about multiple private signature keys in section 2.3. to get the following: "A TSA MAY have distinct private keys, e.g. to accommodate different policies, different algorithms, different private key sizes or to increase the performance." As supported by Steve Kent and some others, the current text to specify that the private key MUST not be used for any other purpose has been maintained. Peter Sylvester noticed that (in version 8) I changed in the module, extensions [0] Extensions OPTIONAL with extensions [0] IMPLICIT Extensions OPTIONAL but I forgot do do it as well in the text. I will fix it. It is now time to send this document to the IESG. There are still opportunities to make minor changes to the document when it becomes a Standard, at least six months after it becomes Proposed Standard. Denis Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06076 for ; Mon, 26 Jun 2000 03:45:58 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29344; Mon, 26 Jun 2000 06:46:31 -0400 (EDT) Message-Id: <200006261046.GAA29344@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-time-stamp-09.txt Date: Mon, 26 Jun 2000 06:46:31 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) Author(s) : C. Adams, P. Cain, D. Pinkas, R. Zuccherato Filename : draft-ietf-pkix-time-stamp-09.txt Pages : 22 Date : 23-Jun-00 A time stamping service allows to prove that a datum existed before a particular time and can be used by a Trusted Third Party (TTP) as one component in building reliable non-repudiation services (see [ISONR]). This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. An example of how to prove that a digital signature was generated during the validity period of a public key certificate is given in an annex. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-09.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-time-stamp-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-time-stamp-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000623134944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-time-stamp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-time-stamp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000623134944.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA29159 for ; Mon, 26 Jun 2000 01:08:02 -0700 (PDT) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AF7AFE0150; Mon, 26 Jun 2000 10:08:26 +0200 Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Mo, 26 Jun 2000 10:09:19 +0100 From: "Peter Lipp" To: "Michael Zolotarev" Cc: "PKIX" Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Mon, 26 Jun 2000 10:09:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.A287CEE0--"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.A287CEE0-- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It is not a PGP-model. I register my direct trust a self-signed CA > certificate - is it PGP? Of course not. So why are you saying > that trusting to a self-signed TSA certificate is PGP? Because if every PKI-service (TSA, OCSP, SCVP, ...) signs their own certificate, and if I have to verify trust into each and every one of them separately, and that smells PGPish and not PKIXish. Strictly speaking it is not PGP, but if I extrapolate and allow you to register your direct trust into my personal self signed CA certificate, we are very close to PGP, aren't we? And I don't care about the data formats here... Peter ----IAIK.SMIME.MAPPER.A287CEE0-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC 2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9 ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy 2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE 6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx 2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7 rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8 lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3 DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI 7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG 9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6 Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25 sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9 l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q 19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6 ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1 OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B 2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1 2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64 vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMDA2MjYwODA5MTlaMCMGCSqGSIb3DQEJBDEWBBTlQN4ObuKIfPpb UO7tN+O9ifAJpTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN BgkqhkiG9w0BAQEFAASBgE2PpajNd8YRSpMtKRYFXKNOfbk7zHL00T1uLQ0eEWFa wjMA4DMG7ty54+z3Cx3/8KtohO1F7+Mcxv/6ZC8+zCcw5LBwfq4Y0Tlp7jFtQTTY 9dI241hXRtLfQXzddZTfoWt7E884e41pMeix9yAvgEJ/Ru/XgICdGgZJgBCt5LS+ AAAAAAAA ----IAIK.SMIME.MAPPER.A287CEE0---- Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA26461; Sun, 25 Jun 2000 23:12:59 -0700 (PDT) Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id HAA21923; Mon, 26 Jun 2000 07:16:40 +0100 Message-ID: <3956F4BF.AF5170D7@algroup.co.uk> Date: Mon, 26 Jun 2000 07:14:23 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: Bob Jueneman CC: ietf-pkix@imc.org, phoffman@imc.org Subject: Re: Do people have something against RSA? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Jueneman wrote: > Sounds great, at least to the young and naive (as most of us were at one time). > Unfortunately, although the Soviets tried this system for 80 years, and the Cubans, > North Koreans, and some other societies are still trying it, the jury has come back with > a verdict. Except in some closed societies, normally religious orders, this system > simply does not work, and can only be sustained through a very harsh and cruel > dictatorship. Those who have talent either opt out or become the bosses, leaving > those who cannot to fend for themselves. > > If inventors cannot be rewarded for the fruits of their labors, then the entire structure > of capitalism is without a foundation, and all of the IPOs and stock market gains > are merely the Tulip Bulb mania repeating itself all over again. > > Unfortunately, it has gotten to the point that filing for an invention has become > the kiss of death within the IETF. No matter how good the idea is, if you patent it > the IETF will go out of their way to make sure that it isn't standardized. a) Are you aware of the IETF rules regarding patented stuff in standards? b) Why do you think that patents are the only way to be rewarded for inventing things? > The inevitable result of this is that either (1) companies will stop inventing things, > since they won't be rewarded for them, or (2) companies will drop out of the IETF > process, and ignore the standards as either irrelevant or explicitly contrary to their > business interests. Is that what we want to have happen? The problem with this "prediction" is that although its premise is demonstrably correct, the consequence hasn't occurred. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ Received: from hitpro.hitachi.co.jp (root@hitpro.hitachi.co.jp [133.145.224.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA25896 for ; Sun, 25 Jun 2000 23:02:38 -0700 (PDT) Received: from bisdgw.bisd.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id PAA12186; Mon, 26 Jun 2000 15:02:36 +0900 (JST) Received: from bisdmail.bisd.hitachi.co.jp by bisdgw.bisd.hitachi.co.jp (8.9.3+3.2W/3.7W-bisdgw) with ESMTP id PAA03481 for ; Mon, 26 Jun 2000 15:02:36 +0900 (JST) (envelope-from kawatura@bisd.hitachi.co.jp) Received: from localhost by bisdmail.bisd.hitachi.co.jp (8.9.3/3.7W-bisdmail) with ESMTP id PAA05432; Mon, 26 Jun 2000 15:02:35 +0900 (JST) (envelope-from kawatura@bisd.hitachi.co.jp) To: ietf-pkix@imc.org Cc: kawatura@bisd.hitachi.co.jp Subject: Unique identifiers for certificate. From: Yoshiaki KAWATSURA In-Reply-To: <85256905.0066D323.00@csc.com> References: <85256905.0066D323.00@csc.com> X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000626150211O.kawatura@bisd.hitachi.co.jp> Date: Mon, 26 Jun 2000 15:02:11 +0900 (JST) X-Dispatcher: imput version 990905(IM130) Lines: 17 Hello, I have a question of unique identifiers for certificate. Is there any general guideline which describes which unambiguous identifiers for certificate should be used? For example, a combination of Issuer Name and Certificate Serial Number is used as the identifier for the actual public key to verify the signature in PKCS#7. Additinally, a combination of issuer name, subject name and subject key identifier is also used (this is described in draft-ietf-pkix-technr-00.txt.) Thanks, ---- Yoshiaki Kawatsura : E-mail kawatura@bisd.hitachi.co.jp Business Solution Systems Development Division, Hitachi,Ltd. Voice: +81-44-549-1713(direct) Fax: +81-44-549-1721 Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16013 for ; Sun, 25 Jun 2000 16:45:14 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA06200; Mon, 26 Jun 2000 09:50:47 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Mon, 26 Jun 2000 09:44:25 +1000 Message-ID: From: Michael Zolotarev To: Peter Lipp , Rich Salz , Aram Perez Cc: PKIX Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Mon, 26 Jun 2000 09:44:19 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" It is not a PGP-model. I register my direct trust a self-signed CA certificate - is it PGP? Of course not. So why are you saying that trusting to a self-signed TSA certificate is PGP? Are we trying to limit issuing self-signed certificates to CA only, PKI-wide? The same arguments apply to any non-CA service, such as Attribute Authority, don't they? > -----Original Message----- > From: Peter Lipp [mailto:Peter.Lipp@iaik.at] > Sent: Saturday, June 24, 2000 9:41 PM > To: Rich Salz; Aram Perez > Cc: PKIX > Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning] > > > > > If I take your statements/conclusions below to their extreme, > > then anytime > > > PKIX comes up with a new service that uses digital signatures, > > that service > > > would have to issue its own self-signed certificates. I don't > > see the OCSP > > > folks requesting their own self-signed certificates. > > > > Not HAVE TO issue, but COULD issue. Most definitely. > > Yes. And I could also issue my self-signed certificate, and > you would have > less problems trusting me because you would not need to > bother with the > obscure cert I might have from some CA service. Welcome to > the PGP-model! > > Peter > > > Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA13765 for ; Sun, 25 Jun 2000 11:57:20 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 08688107; Sun, 25 Jun 2000 14:57:45 -0400 (EDT) Message-ID: <39565606.3DB590E2@caveosystems.com> Date: Sun, 25 Jun 2000 14:57:10 -0400 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aram Perez CC: PKIX Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 > So you want any user of a PKIX service to have to figure out a OOB mechanism > for each provider of the service to verify the self-signed certificate? Not at all. I want it to be *possible* to start an independant PKIX service. Let me turn the question around: why do you feel it necessary to force me to run a CA? /r$ Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA19446 for ; Sat, 24 Jun 2000 22:35:07 -0700 (PDT) Received: from [207.215.86.189] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWP00HJQ3G2BY@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Sat, 24 Jun 2000 22:33:39 -0700 (PDT) Date: Sat, 24 Jun 2000 22:34:32 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <3954903D.57F4EA14@caveosystems.com> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Rish Salz wrote: >> If I take your statements/conclusions below to their extreme, then anytime >> PKIX comes up with a new service that uses digital signatures, that service >> would have to issue its own self-signed certificates. I don't see the OCSP >> folks requesting their own self-signed certificates. > > Not HAVE TO issue, but COULD issue. Most definitely. So you want any user of a PKIX service to have to figure out a OOB mechanism for each provider of the service to verify the self-signed certificate? Regards, Aram Perez Received: from imo-r16.mx.aol.com (imo-r16.mx.aol.com [152.163.225.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03939 for ; Sat, 24 Jun 2000 14:37:18 -0700 (PDT) From: Scruggs01@aol.com Received: from Scruggs01@aol.com by imo-r16.mx.aol.com (mail_out_v27.10.) id h.db.5eb4e6e (4247); Sat, 24 Jun 2000 17:37:11 -0400 (EDT) Message-ID: Date: Sat, 24 Jun 2000 17:37:11 EDT Subject: Re: certification for pki To: jean.med@arabtrust.com, ietf-pkix@imc.org CC: cscruggs@kpmg.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 109 Jean, There is a process called WebTrust that is endorsed by the American Institute of Certified Public Accountants (AICPA) and the Canadian Institute of Chartered Accountants (CICA). WebTrust offers several models of audit and certification guidance including one for Certificate Authorities (WebTrust Principles and Criteria for Certificate Authorities). While this process does not currently have "international" acceptance, many past AICPA standards have gained that stature. If you would like additional information, please go to: http://www.cpawebtrust.org. Charlie Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA17128 for ; Sat, 24 Jun 2000 04:40:04 -0700 (PDT) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AE2412C20058; Sat, 24 Jun 2000 13:40:20 +0200 Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Sa, 24 Jun 2000 13:41:13 +0100 From: "Peter Lipp" To: "Rich Salz" , "Aram Perez" Cc: "PKIX" Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Sat, 24 Jun 2000 13:41:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.261C1BF8--"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <3954903D.57F4EA14@caveosystems.com> This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.261C1BF8-- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > > If I take your statements/conclusions below to their extreme, > then anytime > > PKIX comes up with a new service that uses digital signatures, > that service > > would have to issue its own self-signed certificates. I don't > see the OCSP > > folks requesting their own self-signed certificates. > > Not HAVE TO issue, but COULD issue. Most definitely. Yes. And I could also issue my self-signed certificate, and you would have less problems trusting me because you would not need to bother with the obscure cert I might have from some CA service. Welcome to the PGP-model! Peter ----IAIK.SMIME.MAPPER.261C1BF8-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC 2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9 ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy 2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE 6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx 2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7 rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8 lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3 DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI 7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG 9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6 Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25 sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9 l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q 19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6 ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1 OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B 2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1 2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64 vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMDA2MjQxMTQxMTNaMCMGCSqGSIb3DQEJBDEWBBQFNfktWnD8i08a B+mSnLCEDIV/FjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN BgkqhkiG9w0BAQEFAASBgBmxRfjyDq5HaNk7ibRjoba4TjIS1kwNXRCz/KmH2N70 by7SWB7gWcE9KSn+HYhQqnAk6sRwKjrNNmTXRweHc1SJmP5Hc12u5nbO7KGuX9Su qryyJ7QLcV3WVRWiSu6e9yJRg5CtZqJE06H5/ZFnggRaLHz8GgDX7yup9luQ0yfi AAAAAAAA ----IAIK.SMIME.MAPPER.261C1BF8---- Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA14928 for ; Sat, 24 Jun 2000 03:40:28 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 0313444; Sat, 24 Jun 2000 06:40:39 -0400 (EDT) Message-ID: <3954903D.57F4EA14@caveosystems.com> Date: Sat, 24 Jun 2000 06:41:01 -0400 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Aram Perez CC: PKIX Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 > If I take your statements/conclusions below to their extreme, then anytime > PKIX comes up with a new service that uses digital signatures, that service > would have to issue its own self-signed certificates. I don't see the OCSP > folks requesting their own self-signed certificates. Not HAVE TO issue, but COULD issue. Most definitely. Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11343 for ; Sat, 24 Jun 2000 03:12:45 -0700 (PDT) Received: from arabtrust [195.39.129.32] by mail.arabtrust.com (SMTPD32-6.00) id AA207B200A8; Sat, 24 Jun 2000 06:14:56 -0400 From: "Jean Abraham" To: Subject: digital certificate supports? Date: Sat, 24 Jun 2000 13:11:51 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Hi, What are the applications that does or does not support more than 4 hierachies in a digital certificate. Jean Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24639 for ; Fri, 23 Jun 2000 21:13:32 -0700 (PDT) Received: from [209.77.88.197] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWN009HJ50LC2@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Fri, 23 Jun 2000 21:12:22 -0700 (PDT) Date: Fri, 23 Jun 2000 21:12:33 -0700 From: Aram Perez Subject: Re: Allow RSA mandatory after September 20, 2000 ? In-reply-to: <39531B2A.56B1643F@bull.net> To: IETF-PXIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Hi Denis, > Up to now, the IETF WGs and the IESG have mandated the DSA and > Diffie-Hellman algorithms only, since the RSA algorithm was > patented. On September 20, 2000 the RSA patent will expire, so this > allows the IESG to reconsider the issue. > > I would like the co-chairs to raise this issue to the IESG, so that > for any Standard (not Proposed Standard) issued after September 20, > 2000, we can, if this is a WG decision, mandate the RSA algorithm. Great suggestion! I fully support this request. Regards, Aram Perez Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24627 for ; Fri, 23 Jun 2000 21:13:31 -0700 (PDT) Received: from [209.77.88.197] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWN009HJ50LC2@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Fri, 23 Jun 2000 21:12:23 -0700 (PDT) Date: Fri, 23 Jun 2000 21:12:36 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Hi Michael, If I take your statements/conclusions below to their extreme, then anytime PKIX comes up with a new service that uses digital signatures, that service would have to issue its own self-signed certificates. I don't see the OCSP folks requesting their own self-signed certificates. Regards, Aram Perez >> >> I don't agree. As the service provider, why do I *have* to deal with >> the management of two private keys. It's way more than syntax. >> >> We don't need to "push" anything. We need to not prohibit it. >> /r$ >> > > I fully agree with that. > > Guys, > > << I feel that I've said all I had to say on the subject. In this mail I'll > try to put together a little summary of my position, which I know is > supported by a number of the list members. It was taking too much and too > long - this message will be the last from me on self-signed TSA certs (do I > see happy smiles :)? Denis, it is really up to you now - put it on vote, or > forget. >> > > I (quite frankly) fail to understand the rational for the draft to introduce > limitations which necessitate extra entities and potentially more complex > environment for all involved parties. All for a sake of extra purity of a > concept, which is already pure enough. Probably my position is too much > 'engineering', but this is what I am, sorry. > > An example first: > Imagine some Business_Domain_Managing_Authority (BDMA) that wants to deploy > a TSA service for its members. Would it be Ok that the members express their > trust directly to the TSA? I guess so. > > With the client's trust expressed directly to the TSA cert, it is irrelevant > if the TSA cert was self-signed or CA-signed. Referring to the arguments in > favor of signing by CA - yes, I agree that there are benefits, thank you. It > is all perfect with the assumption that there IS a CA around, or at least a > business has a need for a CA. > > Now, can anybody explain the BDMA's manager (a stubborn and slow guy he is > indeed :) why the organisation has to buy/setup/employ a CA, if everything > that they will ever need is just a TSA? > > << I know that the previous sentence may get me sacked from Baltimore, which > main business is selling CAs. :) So the standard disclaimer is right here. >>> > > Mind you, out-of-band TSA cert delivery is as complex, or as simple, as the > one for distributing a CA's cert, should it exist. > > As a conclusion: > Using self-signed TSA certs should be an internal matter for each domain, > each TSA, subject to specific policy and national regulations. And a hell > lot more. Therefore, the draft should not encourage self-signed TSA certs, > neither it should prohibit them. It should be neutral and stay away from > that slippery subject. > > And it is not far from what the current draft is about, as it seems. > > A minor fix- a sentence for the security considerations section would be > something like: > "The TSA private key must be generated and used ONLY for signing timestamps, > and possibly for internal key/certificate management operations such as > P-O-P or self-signing." > > Best regards > Michael > Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06477 for ; Fri, 23 Jun 2000 14:33:31 -0700 (PDT) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A7AB19D0128; Fri, 23 Jun 2000 23:33:31 +0200 Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Fr, 23 Jun 2000 23:34:23 +0100 From: "Peter Lipp" To: "Michael Zolotarev" , Subject: AW: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Fri, 23 Jun 2000 23:34:22 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.8A03CDEB--"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.8A03CDEB-- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I guess the problem is a common misconception that a TSA is always a > subsidiary/sub-service of a CA. Not necessary. TSA is/can_be a service on > its own, with no inherited relationship to any CA at all. Sure it can. But I bet it still will have certificates from some CA (more than one maybe) that trust the TSA for doing their service properly. Do you really believe the average user will and can go and check for each and every service provider if it should be trusted? If he at some point really consiously decided to trust a certain CA, it will be close to a miracle. Most will accept somebody elses decisions, maybe preconfigured by the vendor, and if the SW asks: should I trust, he will hit the "never ask me that question again" button.... Peter ----IAIK.SMIME.MAPPER.8A03CDEB-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC 2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9 ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy 2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE 6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx 2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7 rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8 lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3 DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI 7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG 9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6 Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25 sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9 l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q 19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6 ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1 OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B 2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1 2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64 vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMDA2MjMyMTM0MjNaMCMGCSqGSIb3DQEJBDEWBBRxCE72xr47V3Mr SVFLlPFfOZikgzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN BgkqhkiG9w0BAQEFAASBgMiIJYnloS3RWMW4oAn/jeFn8V6nVPjyWfgnSWnK2ko8 D1cqCS31beJePiEa+7eFjgaz/luEEngzEHWmOIZLwg/fg9JQPUuWx2tDByoyp6IE qdolRWRFIja4CYOToMUGmoXv1UqO5Lv8qa7M5bVS+JhMFyQvNwCoSrLWJwL87AgN AAAAAAAA ----IAIK.SMIME.MAPPER.8A03CDEB---- Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05949 for ; Fri, 23 Jun 2000 14:11:33 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA09861; Fri, 23 Jun 2000 17:06:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3952BC34.498B6D2E@caveosystems.com> References: <3952BC34.498B6D2E@caveosystems.com> Date: Fri, 23 Jun 2000 17:04:53 -0400 To: Rich Salz From: Stephen Kent Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Cc: PKIX Content-Type: text/plain; charset="us-ascii" ; format="flowed" Rich, > > >Stephen Kent: > > I've always asserted that self-signed certs are just a syntactic > > convenience, not a generally useful way of ensuring security for > > transmitted public keys. If we agree on that point, then I don't see > > a lot of reason to push for self-signed TSA certs. > >I don't agree. As the service provider, why do I *have* to deal with >the management of two private keys. It's way more than syntax. > >We don't need to "push" anything. We need to not prohibit it. You don't agree with what, the assertion about syntactic convenience? I don't think it's much easier to manage one private key vs. two when you have to distribute one key visa OOB means in either case. It is a lot cleaner, and it provides a straightforward revocation mechanism for the TSA key, even allowing delegation to an OCSP server without further violating the notion of what a TSA should be used to sign. Steve Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05216; Fri, 23 Jun 2000 13:25:49 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA28112; Fri, 23 Jun 2000 13:26:24 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 13:25:10 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EB79@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Paul Hoffman / IMC'" , Bob Jueneman , ietf-pkix@imc.org Subject: RE: Do people have something against RSA? Date: Fri, 23 Jun 2000 13:25:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0032_01BFDD2F.C163D550"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0032_01BFDD2F.C163D550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >OpenPGP *is* and IETF standard. It has the same standards level as >S/MIME and PKIX does. You may not use it, and your company may not >sell it, but please stop pretending it is not an IETF standard. Paul as a matter of FACT, PGP is NOT an IETF standard. There are in fact practically no IETF standards. IP and TCP being some of the few exceptions. SMTP is a standard but HTTP still is not. PGP is currently a proposed standard. Recognition as an actual standard is far from certain and depends in part upon market acceptance. The status of market acceptance of PGP and PKIX is NOT equivalent in any degree. In addition X.509v3 of which PKIX is a profile IS a standard recognised by the International Standards Organization. It is thus not a 'pretense' to claim PGP is not an IETF standard. X.509v3 is however a longstanding ISO standard that the IETF has already incorporated into widely deployed standards proposals. Phill ------=_NextPart_000_0032_01BFDD2F.C163D550 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyMzIwMjYxNlowIwYJKoZI hvcNAQkEMRYEFHrpdZOO+nm6oP1K1A5Ux9FzGoUFMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAtUdabFDLOo62qvQ8jes0neFMY7goxEOKR3mDrS6jEXYzx8gl7VYLeMd7BRhhraah luXD59P6IyDV8yKZc/FYExwOSyn6Id6TfY2HASP9CfKZ169dxyqT6XuOYvrnn7E92iqQ1PIrgZgq o9hzcqTPauCpmodfMpyjfXgXfMbY55IAAAAAAAA= ------=_NextPart_000_0032_01BFDD2F.C163D550-- Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05045 for ; Fri, 23 Jun 2000 13:25:20 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FWM00901JETII@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 23 Jun 2000 13:25:41 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FWM008O1JETLW@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 23 Jun 2000 13:25:41 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 13:19:02 -0700 Content-return: allowed Date: Fri, 23 Jun 2000 13:18:53 -0700 From: Frank Balluffi Subject: RFC 2459: Use of Key Identifiers During Path Validation To: "'ietf-pkix@imc.org'" Message-id: <27FF4FAEA8CDD211B97E00902745CBE2E08BA9@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Based on my reading of section 6.1 of RFC 2459 there is no need to check that key identifiers chain properly during path validation. Is this true? Frank Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04759 for ; Fri, 23 Jun 2000 13:19:22 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA27872 for ; Fri, 23 Jun 2000 13:19:51 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 13:18:37 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EB78@vhqpostal.verisign.com> From: Philip Hallam-Baker To: PKIX Mailing List Subject: RE: Do people have something against RSA? Date: Fri, 23 Jun 2000 13:18:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_002D_01BFDD2E.D7428C00"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_002D_01BFDD2E.D7428C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Summary: Unless we modify the drafts to rip out the mandatory DH but optional RSA the PKIX and SMIME specs will inevitably end up being recycled at DRAFT stage since otherwise our spec will not correspond to reality. While we are at it a good purge of all lossage related to 40bit ciphers is needed. On the patent issue, yes I do begrudge folk a return on their IP. I have yet to see anyone go out and hand me (or CERN) a cheque for the IP we put in the public domain. The fact is that in most cases a patent is the kiss of death as far as I am concerned. If you patent something it means that I have to talk to our lawyers if I want to use it in a design. It is usually easier to work out another way to do the same thing - as some folk on this list have discovered. I don't have a problem in the case that someone genuinely invented something worthwhile. In most cases however I'm reading claims written by some weasel that developed a better mousetrap and is claiming the idea of catching all forms of vermin for purposes of disposal (excluding weasels). When I was at MIT one of the Profs made certain patent claims which had they been made in an academic paper would have been considered plagarism. I have noted a distinct decline in said profs patent prolixity since I made my position clear (and no it isn't anyone the folk in this group is likely to know - unless they spend time reading bogus patent claims). The fact that DH expired two years ago and will not expire till the end of the month after the next IETF does not appear to me to be a sufficient reason to absolutely reject RSA until the second hand reaches the top of the hour ushering in October 1. When the argument is that we all need one default algorithm to permit interoperation it aoccurs to me that ignoring the 100 odd million installations already shipped is ridiculous. They do RSA, they don't do DH, it will be five years at least before that installed base will cease to be a constraint - end of story. Phill ------=_NextPart_000_002D_01BFDD2E.D7428C00 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyMzIwMTk0M1owIwYJKoZI hvcNAQkEMRYEFH+Sm18nCSnNakQInZxMol59578mMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAKZxDHtrhgk83JApyx50nwLVZAwLPY0IYTCB2mxuPdxpT4SCtvpxDSDVcLLHKdx1S tW6Mp8UTqXumVpEzs7fgmvaqyZ1d7PuAvlpildU8TgB9OdfxkyhHBuIZft3/mZhNjS62G6TkJ41B EakEEiveuA1BmCcVXdz8dnCq2lgnqU8AAAAAAAA= ------=_NextPart_000_002D_01BFDD2E.D7428C00-- Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01292 for ; Fri, 23 Jun 2000 13:06:43 -0700 (PDT) Received: from [171.78.30.107] (fixed030-107.bbn.com [171.78.30.107] (may be forged)) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA01892; Fri, 23 Jun 2000 16:06:55 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 23 Jun 2000 15:58:35 -0400 To: "Bob Jueneman" From: Stephen Kent Subject: Re: Can we form certificates with just name and e-mail address Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Bob, >Steve/Clark :-), (hey, don't blow my cover ...) > > >>But presumably there would only be one > >{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="kent@bbn.com" > > >True. If the intent were to create multiple leaf entries below the >single entry of this form then the justification would be better, >but I don't that's what people have been suggesting. >It's not that I particularly like compound attributes, but that's what >I was suggesting, rather than having the rfc822 be a leaf under the user name >DN. That's what I mean to imply by the plus sign -- exactly like most >people have been suggesting for name+serial. At least the rfc822 name >component has a great semantic content than a serial number. Yes. But, what people were suggesting was a DN with ONLY a given name and surname, plus an e-mail address. That's a bit odd from a directory structure perspective. Obviously we would not use the first two components as RDNs under a root, since there would be no good way to separate the database base for people on a large geographic basis using those attributes. If we used the e-mail address as the first RDN it would allow for meaningful partitioning, but because the address is a composite value, it seems wrong too. It would be more appropriate to use the DC attribute to mimic the DNS structure, then put the user name as the leaf RDN. In that case, though, the given name and surname are redundant, right? Steve Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00604 for ; Fri, 23 Jun 2000 12:30:09 -0700 (PDT) Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA26578; Fri, 23 Jun 2000 12:31:07 -0700 (PDT) Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 12:29:53 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EB77@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Frederik Loeckx'" , ietf-pkix@imc.org Subject: RE: Allow RSA mandatory after September 20, 2000 ? Date: Fri, 23 Jun 2000 12:29:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="----=_NextPart_000_0025_01BFDD28.07BA6670"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0025_01BFDD28.07BA6670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Even further, why wait till September 30? The patent sunset is sufficiently close and the deployment of RSA sufficiently widespread that the IESG is not likely to influence the situation much. I strongly suspect that MOST implementations of S/MIME will ignore the mandatory support for D-H. The IESG can issue Canute like demands but the tide of deployed clients will not head them any more than the sea did the King. We all know that after Sept 30 the IESG won't have any rational argument for not recognising that support for RSA is necessary for S/MIME interoperability and support for DH is not. It does not take a game theorist to determine that the IESG has no negotiating strength in such a situation. Coupled with the various pieces of mud bubbling to the surface of the swamp with various obscure D-H related claims emerging, the IP story on D-H is likely to be worse than that on RSA after Sept 30. Phill -----Original Message----- From: Frederik Loeckx [mailto:frederik.loeckx@utimaco.be] Sent: Friday, June 23, 2000 7:46 AM To: ietf-pkix@imc.org Subject: Re: Allow RSA mandatory after September 20, 2000 ? Even further, the question could be raised if DSA and Diffie Hellman need to be marked as mandatory if RSA is already marked as mandatory. When RSA is already present as a common algorithm, there is not need for DSA, DH to be mandated. The standards will more reflect the actual marketplace, when DSA and Diffie Hellman are considered as optional. Frederik Denis Pinkas on 23/06/2000 10:09:14 To: IETF-PXIX cc: (bcc: Frederik Loeckx/Utimaco/BE) Subject: Allow RSA mandatory after September 20, 2000 ? Up to now, the IETF WGs and the IESG have mandated the DSA and Diffie-Hellman algorithms only, since the RSA algorithm was patented. On September 20, 2000 the RSA patent will expire, so this allows the IESG to reconsider the issue. I would like the co-chairs to raise this issue to the IESG, so that for any Standard (not Proposed Standard) issued after September 20, 2000, we can, if this is a WG decision, mandate the RSA algorithm. Denis ------=_NextPart_000_0025_01BFDD28.07BA6670 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5 6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I 98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh 1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz 7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6 xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5 NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50 czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g 23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9 vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDYyMzE5MzA1OFowIwYJKoZI hvcNAQkEMRYEFK4WJnQy1u5i55nq3OIhKoie++3JMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3 DQEBAQUABIGAI9LpyEQKTpP6/JI43UOI0zLkYqq9nf85Den7+h3Irf22L7FpxeEQmdpza8w/Surs 6mA59CsLUHMq63n4pP7miQLxDbl+tSeQy4a0IwQzW6uuycopvvLaDKIt7l+ONPdGmv5xp2PWCGnE wxqHxZrB+iKWwkx834bfns4I4JQ07/AAAAAAAAA= ------=_NextPart_000_0025_01BFDD28.07BA6670-- Received: from mail.moh.hnet.bc.ca (mail.moh.hnet.bc.ca [142.36.56.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25861 for ; Fri, 23 Jun 2000 11:30:02 -0700 (PDT) Received: from moh.hnet.bc.ca ([142.36.11.183]) by mail.moh.hnet.bc.ca (Netscape Messaging Server 3.61) with ESMTP id AAA60A3 for ; Fri, 23 Jun 2000 11:30:11 -0700 Message-ID: <3953ACBD.E4F94255@moh.hnet.bc.ca> Date: Fri, 23 Jun 2000 11:30:21 -0700 From: "Doug M Williscroft" X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Trading Partner Web Certificates Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This note is to elicit feedback on a PKI model that my organization has implemented for web delivery/collection of information. We call it the "trading partner certificate" model. The trading partner certificate model does not attempt to provide the full benefits of the grand PKI vision but limits itself to browser-based extranets. The solution we have adopted is rather simple but - due to limitations of existing technology - not especially elegant. Even so, we believe it to provide significant authentication benefit at at significantly lower cost than other alternatives. At the end of this note I describe a desirable new function for certificate management (at the browser and/or OS) that would provide broad benefit for extranet applications under this model. I believe this additional functionality would be relatively easy to develop, and would quite possibly find a large market. Our model: 1) Establish a trading agreement with an organization through standard business processes which include contractual definition of obligaitions. 2) Issue a trading partner certificate to the organization. (In our current case the certificates are "anonymous"; they make no statement about the trading partner. This is not a necessary component of the model. Neither is it necessary that we be the certificate issuer.) 3) The trading partner installs the certificate and private key on all browsers that will be used to access our services. (Most of our trading partners use the IE5 browser which allows the private key to be flagged as "not exportable" from the computer - a highly desirable feature in our from our perspective.) 4) The trading partner registers its users in our extranet directory - and assumes responsibility for managing those users - including assignment of access permissions within the bounds of the trading partner agreement. (At this point user administration requires some intervention on our part - we anticipate fully externalized user management in the future.) 5) Users connecting to our web servers are challenged (via SSL) to provide a client certificate. 6) Users presenting a valid trading partner certificate are challenged for UserID and Password. 7) Users presenting a valid password and the correct trading partner certificate for that user's organization are granted access to the appropriate services. To impersonate a user an attacker must gain direct access to a computer in the trading partner organization, and gain knowledge of a valid userID and password pair. We see this 2-factor mechanism as offering protection against password discovery (by attackers external to the trading partner organization), and against man-in-the-middle attacks based on URL hijacking or DNS poisoning. Desirable new certificate management functionality: It would be helpful to our trading partners if certificates/private keys could be centrally distributed en-masse to all computers/user profiles in a trading partner organization. Currently, our trading partners must manually install the private key to each user login account that will use our services - a tedious activity. This task must be repeated prior to certificate expiry. Fortunately our trading partners are willing to accept this administrative burden because they consider the services we offer sufficiently valuable. Comments? -- Doug Williscroft HealthNet/BC Architecture and Standards Branch Ministry of Health Information Management Group Telephone: (250) 952-2497 _______________________________________________ Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24798 for ; Fri, 23 Jun 2000 10:36:58 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FWM00801BM6CR@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 23 Jun 2000 10:37:18 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FWM007COBM5TP@ext-mail.valicert.com>; Fri, 23 Jun 2000 10:37:17 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 10:30:39 -0700 Content-return: allowed Date: Fri, 23 Jun 2000 10:30:30 -0700 From: Ambarish Malpani Subject: RE: Generalizing the concept of id-pkix-ocsp-nocheck To: "'Russ Housley'" Cc: ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE2B414CF@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 I am suggesting that a CA does not require you to do a revocation check on that certificate. The reason a CA might want to do this is: a. The CA has rules which say that the guarantees associated with such certificates are more limited (e.g. utility certs in Identrus). b. The CA "knows" that the cert will never be revoked [because the CA controls that key with exactly the same care with which its root key is protected]. c. The CA is trying to protect from infinite recursion [e.g. the OCSP responder cert or maybe its indirect CRL signing cert]. Do we need to distinguish between a and b? Or should the CA do that in its policies? Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Russ Housley [mailto:housley@spyrus.com] > Sent: Thursday, June 22, 2000 1:45 PM > To: Ambarish Malpani > Cc: ietf-pkix@imc.org > Subject: Re: Generalizing the concept of id-pkix-ocsp-nocheck > > > Ambrish: > > Are you suggesting that the replying party should blindly accept any > certificate that contains this flag? Or, are you suggesting > that the flag > indicates that no revocation information is available for the > certificate? > > Russ > > > At 09:26 PM 06/20/2000 -0700, Ambarish Malpani wrote: > > >I was recently having a conversation with a collegue and he > >asked a question. Here goes: > > > >In OCSP, we have support the concept of a CA issuing a special > >certificate to an OCSP responder, allowing it to respond on its > >[the CA's] behalf with a special extended key usage flag. > > > >We also allow the CA to indicate that the responder's cert does > >not need to be validated by having it include the > >id-pkix-ocsp-nocheck extension in the responder's certificate. > > > >Why can't the concept of including an id-pkix-ocsp-nocheck > >extension in a certificate be extended to any arbitrary certificate > >to indicate that it doesn't need to be validated? > > > >If this makes sense, should this capability be specified in > >son-of-rfc2459? > > > >Comments? > > > >Ambarish > > > > > >--------------------------------------------------------------------- > >Ambarish Malpani > >Architect 650.567.5457 > >ValiCert, Inc. ambarish@valicert.com > >339 N. Bernardo Ave. http://www.valicert.com > >Mountain View, CA 94043 > Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23150 for ; Fri, 23 Jun 2000 09:54:03 -0700 (PDT) Received: from rhousley_laptop.spyrus.com ([209.172.119.209]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id JAA15606; Fri, 23 Jun 2000 09:53:51 -0700 (PDT) Message-Id: <4.2.0.58.20000622164315.00ae4ae0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 22 Jun 2000 16:44:46 -0400 To: Ambarish Malpani From: Russ Housley Subject: Re: Generalizing the concept of id-pkix-ocsp-nocheck Cc: ietf-pkix@imc.org In-Reply-To: <27FF4FAEA8CDD211B97E00902745CBE2B4149C@seine.valicert.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Ambrish: Are you suggesting that the replying party should blindly accept any certificate that contains this flag? Or, are you suggesting that the flag indicates that no revocation information is available for the certificate? Russ At 09:26 PM 06/20/2000 -0700, Ambarish Malpani wrote: >I was recently having a conversation with a collegue and he >asked a question. Here goes: > >In OCSP, we have support the concept of a CA issuing a special >certificate to an OCSP responder, allowing it to respond on its >[the CA's] behalf with a special extended key usage flag. > >We also allow the CA to indicate that the responder's cert does >not need to be validated by having it include the >id-pkix-ocsp-nocheck extension in the responder's certificate. > >Why can't the concept of including an id-pkix-ocsp-nocheck >extension in a certificate be extended to any arbitrary certificate >to indicate that it doesn't need to be validated? > >If this makes sense, should this capability be specified in >son-of-rfc2459? > >Comments? > >Ambarish > > >--------------------------------------------------------------------- >Ambarish Malpani >Architect 650.567.5457 >ValiCert, Inc. ambarish@valicert.com >339 N. Bernardo Ave. http://www.valicert.com >Mountain View, CA 94043 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14448 for ; Fri, 23 Jun 2000 06:26:23 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FWM0070100J2R@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 23 Jun 2000 06:26:43 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FWM0070L00J2C@ext-mail.valicert.com>; Fri, 23 Jun 2000 06:26:43 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 06:20:06 -0700 Content-return: allowed Date: Fri, 23 Jun 2000 06:20:05 -0700 From: Frank Balluffi Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] To: "'Michael Zolotarev'" , Peter Lipp , ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE2E08B97@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 According to RFC 2459 and draft-ietf-pkix-time-stamp-08.txt, the decision of how to terminate the most-significant end of a certificate path and obtain the most-trusted public key is up to you (i.e., is a matter of policy). I recommend that section 2.4.1 of draft-ietf-pkix-time-stamp-08.txt point to section 6.1 of RFC 2459 with something like: For more information about validating the certificates in the certificates field of the SignedData structure and obtaining the most-trusted public key, see RFC 2459, section 6.1. The relevant text follows. Frank RFC 2459, section 6: This text assumes that all valid paths begin with certificates issued by a single "most-trusted CA". ... The "most-trusted CA" is a matter of policy: it could be a root CA in a hierarchical PKI; the CA that issued the verifier's own certificate(s); or any other CA in a network PKI. RFC 2459, section 6.1: The text assumes that the trusted public key (and related information) is contained in a "self-signed" certificate. This simplifies the description of the path processing procedure. Note that the signature on the self-signed certificate does not provide any security services. The trusted public key (and related information) may be obtained in other formats; the information is trusted because of other procedures used to obtain and protect it. draft-ietf-pkix-time-stamp-08.txt, section 2.4.1 If the certReq field is present and set to true, the TSA's public key certificate that is referenced by the ESSCertID attribute in the response must be provided by the TSA in the certificates field from the SignedData structure in that response. That field may also contain other certificates. > -----Original Message----- > From: Michael Zolotarev [mailto:mzolotarev@baltimore.com] > Sent: Thursday, June 22, 2000 10:02 PM > To: Peter Lipp; ietf-pkix@imc.org > Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] > > > I guess the problem is a common misconception that a TSA is always a > subsidiary/sub-service of a CA. Not necessary. TSA is/can_be > a service on > its own, with no inherited relationship to any CA at all. > > So when NIST starts offering TSA services, it would have to get a > certificate from some CA? Why? Why wouldn't you trust their > TSA certificate > directly? > > > > -----Original Message----- > > From: Peter Lipp [mailto:Peter.Lipp@iaik.at] > > Sent: Thursday, June 22, 2000 7:24 PM > > To: ietf-pkix@imc.org > > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > > > > > > > I'm not convinced it's bad to issue self-signed TSA certificate. > > > I'm just saying it might not be a great idea. > > Agree. I don't see the big advantage. For one, if I want to > > trust a CA I > > need to go through whatever steps are appropriate. If the CA > > offers/recommends/uses a TSA, it can give me a certificate > > for the TSA and - > > having already decided to trust the CA - it is simple to verify the > > certificate and decide to trust the TSA too. So what does the > > self-signed > > TSA cert buy me besides the need to go through the trust > > decisions again? > > Now consider revocation - do you really suggest to set up a separate > > revocation-scheme for the TSA? I simply don't see any > > advantage here... > > > > Peter > > > Received: from ns.secuve.co.kr (IDENT:root@[211.55.106.125]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA11402 for ; Fri, 23 Jun 2000 05:10:10 -0700 (PDT) Received: from secuve.com ([211.55.106.121]) by ns.secuve.co.kr (8.10.2/8.9.3) with ESMTP id e5NCB0P01181 for ; Fri, 23 Jun 2000 21:11:01 +0900 Message-ID: <395353E9.FD4471B7@secuve.com> Date: Fri, 23 Jun 2000 21:11:21 +0900 From: "Youjin, Eun" Organization: SECUVE X-Mailer: Mozilla 4.71 [en] (Win98; I) X-Accept-Language: ko,en MIME-Version: 1.0 To: "ietf-pkix@imc.org" Subject: subscribe Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit -- ============================================================= ------------------------------------------------------------- Name : Eun, You Jin ------------------------------------------------------------- Technical Director. SECUVE CO., Ltd. ------------------------------------------------------------- Phone : +82-342-726-0830 Fax : +82-342-726-0821 Cellular : +82-11-9968-0287 Address : D-217 SIGMA II 18, Koomi-Dong, Bundang-Gu, Sungnam-City, Kyunggi-Do, Korea E-mail : silver@secuve.com URL : http://www.secuve.com ============================================================= Received: from FW-BEL.utimaco.be ([193.121.107.230]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10591 for ; Fri, 23 Jun 2000 04:52:06 -0700 (PDT) Received: (from uucp@localhost) by FW-BEL.utimaco.be (8.9.3/8.9.3) id NAA09677 for ; Fri, 23 Jun 2000 13:55:01 +0200 (CEST) (envelope-from frederik.loeckx@utimaco.be) Received: from (belgien1.utimaco.be [10.7.0.25]) by FW-BEL.utimaco.be via smap (V2.1) id xma009670; Fri, 23 Jun 00 13:54:56 +0200 Received: by belgien1.utimaco.be(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id C1256907.0040A245 ; Fri, 23 Jun 2000 13:45:51 +0200 X-Lotus-FromDomain: UTIMACO From: "Frederik Loeckx" To: ietf-pkix@imc.org Message-ID: Date: Fri, 23 Jun 2000 13:45:47 +0200 Subject: Re: Allow RSA mandatory after September 20, 2000 ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Even further, the question could be raised if DSA and Diffie Hellman need to be marked as mandatory if RSA is already marked as mandatory. When RSA is already present as a common algorithm, there is not need for DSA, DH to be mandated. The standards will more reflect the actual marketplace, when DSA and Diffie Hellman are considered as optional. Frederik Denis Pinkas on 23/06/2000 10:09:14 To: IETF-PXIX cc: (bcc: Frederik Loeckx/Utimaco/BE) Subject: Allow RSA mandatory after September 20, 2000 ? Up to now, the IETF WGs and the IESG have mandated the DSA and Diffie-Hellman algorithms only, since the RSA algorithm was patented. On September 20, 2000 the RSA patent will expire, so this allows the IESG to reconsider the issue. I would like the co-chairs to raise this issue to the IESG, so that for any Standard (not Proposed Standard) issued after September 20, 2000, we can, if this is a WG decision, mandate the RSA algorithm. Denis Received: from stonewall.baltimore.com (mailhost.baltimore.com [195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA29229 for ; Fri, 23 Jun 2000 01:26:47 -0700 (PDT) Message-ID: <61922E6DA745D311A42000508B2CFD14B9677B@baltimore.com> From: Paul Halliden To: "'thayes@netscape.com'" Cc: "'Paul Koning'" , seidel@timeproof.de, FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt Date: Fri, 23 Jun 2000 09:27:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Terry Hayes wrote: >A TSA MAY choose enforce restrictions on the imprint, but the >standard should not REQUIRE it. Agreed. The question I was answering was "Why should people avoid using MD5 - other than because the German Digital Signature Law says so?". Paul Halliden Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA28587 for ; Fri, 23 Jun 2000 01:18:32 -0700 (PDT) Received: by mystic1.trustcenter.de; id KAA03791; Fri, 23 Jun 2000 10:16:43 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma003785; Fri, 23 Jun 00 10:15:58 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id KAA28179; Fri, 23 Jun 2000 10:17:28 +0200 (MET DST) Message-Id: <3.0.5.32.20000623101727.03831100@callisto> X-Sender: jbr@callisto X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 23 Jun 2000 10:17:27 +0200 To: , From: Juergen Brauckmann Subject: RE: Private Key Cloning In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA28589 At 18:24 22.06.00 -0700, Les Nightingill wrote: >I suppose I should check, but perhaps someone knows, too, whether an M-of-N >secret sharing scheme for disaster recovery of a root key is also >non-compliant with the German Digital Signature laws? Well, this is untested yet, I guess... . Private key cloning is explicitely prohibited in the text of the law, but whether copying with secret sharing is the same is not sure to me. As this is a law and legal stuff, you probably cannot check this issue yourself, but you have to test against the authorities:-) Juergen -- Juergen Brauckmann Tel.: 040 / 8080 26 311 TC TrustCenter GmbH Fax.: 040 / 8080 26 126 Sonninstraße 24-28 mailto:brauckmann@trustcenter.de 20097 Hamburg http://www.trustcenter.de Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA28110 for ; Fri, 23 Jun 2000 01:09:30 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA24328 for ; Fri, 23 Jun 2000 10:13:05 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA28904 for ; Fri, 23 Jun 2000 10:09:11 +0200 Message-ID: <39531B2A.56B1643F@bull.net> Date: Fri, 23 Jun 2000 10:09:14 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: IETF-PXIX Subject: Allow RSA mandatory after September 20, 2000 ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Up to now, the IETF WGs and the IESG have mandated the DSA and Diffie-Hellman algorithms only, since the RSA algorithm was patented. On September 20, 2000 the RSA patent will expire, so this allows the IESG to reconsider the issue. I would like the co-chairs to raise this issue to the IESG, so that for any Standard (not Proposed Standard) issued after September 20, 2000, we can, if this is a WG decision, mandate the RSA algorithm. Denis Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA21703 for ; Thu, 22 Jun 2000 22:28:38 -0700 (PDT) Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id PAA49336; Fri, 23 Jun 2000 15:28:22 +1000 (EST) Message-ID: <027401bfdcd5$0a02e590$8802a8c0@eracom.com.au> From: "Simon McMahon" To: "Michael Zolotarev" , "David P. Kemp" , References: Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Fri, 23 Jun 2000 15:36:22 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 > > > From: Michael Zolotarev > > > > > > 1. Self-signed TSA cert. You have to evaluate your secure signing > > > environment. Which is the same for generating timestamps > > and for generation > > > a self-signed cert. > > > > What security-relevant information are you expecting clients to derive > > from validating the signature of a self-signed cert? > > > A client would not validate a self-signed cert - it would have to be trusted > directly, as an anchor. Distributed and cjecked out-of-bands. Why the > question? > > Why should the TSA self-sign this cert if no client will ever check the signature ? This cert could be signed by any private key and the client would not know since it trusts it directly and does not verify the sig. Would you really abuse the usage constraints on a timestamping key to make a signature that nobody needs to verify ? The TSA may as well use another key-pair that it generates to sign this cert. It can then make a normal self-signed cert with this new key pair that will not sign timestamps. Then clients who will not check the TSA cert's signature can just install and trust the TSA cert (not self-signed). Clients that insist on checking signatures on trusted and/or self-signed certs can install both certs then trust the self-signed cert (not the TSA cert) as if it was from a real CA. The TSA is effectively has its own mini CA and will only certify its own time-stamping key pair. Its hardly a full blown CA with all the costs that go with them. You could leave out the possibility of revocation etc. and you would be no worse off than the self-signed TSA cert scenario. > > I don't agree. As the service provider, why do I *have* to deal with > the management of two private keys. It's way more than syntax. > Because you are trying to do two things with one key. Producing timestamps, and trusting them. You are still *having* to deal with these two seperate processes the difference is with one key or with two. If your clients dont check the trusted TSA cert's signature then you fall back to only needing one key. Simon. Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA19624 for ; Thu, 22 Jun 2000 21:29:17 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA00375; Fri, 23 Jun 2000 14:35:03 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Jun 2000 14:28:27 +1000 Message-ID: From: Michael Zolotarev To: "David P. Kemp" , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Fri, 23 Jun 2000 14:28:26 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" > > > From: Michael Zolotarev > > > > 1. Self-signed TSA cert. You have to evaluate your secure signing > > environment. Which is the same for generating timestamps > and for generation > > a self-signed cert. > > What security-relevant information are you expecting clients to derive > from validating the signature of a self-signed cert? > A client would not validate a self-signed cert - it would have to be trusted directly, as an anchor. Distributed and cjecked out-of-bands. Why the question? > Do you expect clients to have trusted storage which could > hold a bare TSA > public key, but which could not hold the entire self-signed > TSA cert??? > No, I do not. The clients would store the entire self-signed cert. Aha, I see it now: phrasing in (1) could be misleading. The signing of the self-signed certificate is not critical, as the cert must be validated out-of-band anyway. You only need to evaluate your secure key generation environment, and the security of key storage and the crypto engine used for signing timestamps. But the argument still stays: using self-signed certificate does not necessarily make the formal security evaluation process of a TSA any more difficult, compared to having the TSA cert signed by a CA. Regards Michael Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16750 for ; Thu, 22 Jun 2000 20:39:48 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id NAA07411; Fri, 23 Jun 2000 13:45:46 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Jun 2000 13:39:16 +1000 Message-ID: From: Michael Zolotarev To: Rich Salz , PKIX , kent@bbn.com Cc: Denis.Pinkas@bull.net Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Fri, 23 Jun 2000 13:39:15 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" > > I don't agree. As the service provider, why do I *have* to deal with > the management of two private keys. It's way more than syntax. > > We don't need to "push" anything. We need to not prohibit it. > /r$ > I fully agree with that. Guys, << I feel that I've said all I had to say on the subject. In this mail I'll try to put together a little summary of my position, which I know is supported by a number of the list members. It was taking too much and too long - this message will be the last from me on self-signed TSA certs (do I see happy smiles :)? Denis, it is really up to you now - put it on vote, or forget. >> I (quite frankly) fail to understand the rational for the draft to introduce limitations which necessitate extra entities and potentially more complex environment for all involved parties. All for a sake of extra purity of a concept, which is already pure enough. Probably my position is too much 'engineering', but this is what I am, sorry. An example first: Imagine some Business_Domain_Managing_Authority (BDMA) that wants to deploy a TSA service for its members. Would it be Ok that the members express their trust directly to the TSA? I guess so. With the client's trust expressed directly to the TSA cert, it is irrelevant if the TSA cert was self-signed or CA-signed. Referring to the arguments in favor of signing by CA - yes, I agree that there are benefits, thank you. It is all perfect with the assumption that there IS a CA around, or at least a business has a need for a CA. Now, can anybody explain the BDMA's manager (a stubborn and slow guy he is indeed :) why the organisation has to buy/setup/employ a CA, if everything that they will ever need is just a TSA? << I know that the previous sentence may get me sacked from Baltimore, which main business is selling CAs. :) So the standard disclaimer is right here. >> Mind you, out-of-band TSA cert delivery is as complex, or as simple, as the one for distributing a CA's cert, should it exist. As a conclusion: Using self-signed TSA certs should be an internal matter for each domain, each TSA, subject to specific policy and national regulations. And a hell lot more. Therefore, the draft should not encourage self-signed TSA certs, neither it should prohibit them. It should be neutral and stay away from that slippery subject. And it is not far from what the current draft is about, as it seems. A minor fix- a sentence for the security considerations section would be something like: "The TSA private key must be generated and used ONLY for signing timestamps, and possibly for internal key/certificate management operations such as P-O-P or self-signing." Best regards Michael Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10095 for ; Thu, 22 Jun 2000 19:03:07 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id MAA06673; Fri, 23 Jun 2000 12:08:47 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Jun 2000 12:02:17 +1000 Message-ID: From: Michael Zolotarev To: Peter Lipp , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Fri, 23 Jun 2000 12:02:16 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" I guess the problem is a common misconception that a TSA is always a subsidiary/sub-service of a CA. Not necessary. TSA is/can_be a service on its own, with no inherited relationship to any CA at all. So when NIST starts offering TSA services, it would have to get a certificate from some CA? Why? Why wouldn't you trust their TSA certificate directly? > -----Original Message----- > From: Peter Lipp [mailto:Peter.Lipp@iaik.at] > Sent: Thursday, June 22, 2000 7:24 PM > To: ietf-pkix@imc.org > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > > > > I'm not convinced it's bad to issue self-signed TSA certificate. > > I'm just saying it might not be a great idea. > Agree. I don't see the big advantage. For one, if I want to > trust a CA I > need to go through whatever steps are appropriate. If the CA > offers/recommends/uses a TSA, it can give me a certificate > for the TSA and - > having already decided to trust the CA - it is simple to verify the > certificate and decide to trust the TSA too. So what does the > self-signed > TSA cert buy me besides the need to go through the trust > decisions again? > Now consider revocation - do you really suggest to set up a separate > revocation-scheme for the TSA? I simply don't see any > advantage here... > > Peter > Received: from cymail.cylink.com (cymail.cylink.com [192.43.161.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06505 for ; Thu, 22 Jun 2000 18:30:49 -0700 (PDT) Received: from hurricane ([10.108.20.6]) by cymail.cylink.com (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-41860U500L2S100) with SMTP id AAA22064 for ; Thu, 22 Jun 2000 18:27:06 -0700 Reply-To: From: lnightin@cylink.com (Les Nightingill) To: Subject: RE: Private Key Cloning Date: Thu, 22 Jun 2000 18:24:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 I'm curious on the views of the "key cloning detractors" on the notable disaster-recovery mitigation benefits of cloning. While the indirection solution helps with load-sharing, it still leaves the root unrecoverable under a no-clone policy. I suppose I should check, but perhaps someone knows, too, whether an M-of-N secret sharing scheme for disaster recovery of a root key is also non-compliant with the German Digital Signature laws? Les Nightingill Cylink -----Original Message----- From: Michael Zolotarev [mailto:mzolotarev@baltimore.com] Sent: Wednesday, June 21, 2000 5:19 PM To: Jeff Davis; ietf-pkix@imc.org Subject: RE: Private Key Cloning Jeff wrote: > The whole idea of having a private key is just that, it is > private to a > single entity and not shared across many other "clones" of > that entity. > > IMHO, and it is very "H" in this case, cloning a private key, of any > nature, is opening yourselves up to all sorts of repudiation > claims. If > you clone once what stops you cloning "n" times without > anyone knowing > ( regardless of what procedures you have in place ). Part of > the basis > of "trust" is that a private key only exists in one place under the > strict control of the owner of that key. The cloning procedure becomes a critical part, I agree. So the authority would have to certify both the security/procedures of its operational environment, and the security/procedures of key cloning. The same scale of precautions that currently applies to keeping the [only and single] key secure would apply to the cloning process. If you suspect that the cloning may allow a criminal-minded high-privileged insider to perpetrate a fraud, then for the same reason your should similarly suspect any other security aspects of the authority operations. We must always consider every particular case of key cloning, instead of dismissing the whole concept. If a particular cloning procedure, executed by a particular authority, using given hardware, in a particular secure environment etc etc can be formally certified as being sufficiently secure, at least not less(!) secure than the rest of the solution - what is wrong with it? If you can prove that your solution is secure - that would be just fine. Why reject the approach on the basis that it MAY present a security hole. Following that logic, whole PKI would be extinct by now. > > I support the views put forward that maybe the TSA root should sign > certificates for level 1 TSA Agents, of which there could be > as many as > required, but all of whom have a different DN ( very closely > associated > with the parent TSA ). The trust of the Time Stamp would then be > through a normal certificate chain and that only being 1 level. Maybe > the TSA root could then go offline leaving the "work horses" > to perform > the stamping. Re-issuing of new TSA signing keys would then be quite > easy for each Agent, with only 1 out of "n" Agents being > offline at any > one time, update the hardware signing module and get back online > a.s.a.p. > > I may be well off the mark here, if so, just tell me to shut > up and get > back in the cupboard. However, as I am trying to learn this stuff, a > little help with my waywardness would go a long way. > I'm also new to the house. But I've learned that there are two words missing in the group's dictionary - "beautiful" and "shut up". Three words, actually :) M Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA05607 for ; Thu, 22 Jun 2000 18:22:52 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 0149118 for ; Thu, 22 Jun 2000 21:22:58 -0400 (EDT) Message-ID: <3952BC34.498B6D2E@caveosystems.com> Date: Thu, 22 Jun 2000 21:24:04 -0400 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: PKIX Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Aram: > You shouldn't have to, although this is the model that most public CAs seem > to push and/or encourage. As I mentioned, a possible solution is the the use > of "anchor certificates". Seems a little complicated. I don't see why I have to introduce an extra entity involved, or extra certs involved. Stephen Kent: > I've always asserted that self-signed certs are just a syntactic > convenience, not a generally useful way of ensuring security for > transmitted public keys. If we agree on that point, then I don't see > a lot of reason to push for self-signed TSA certs. I don't agree. As the service provider, why do I *have* to deal with the management of two private keys. It's way more than syntax. We don't need to "push" anything. We need to not prohibit it. /r$ Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA01846; Thu, 22 Jun 2000 17:42:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Thu, 22 Jun 2000 17:42:06 -0700 To: "Bob Jueneman" , From: Paul Hoffman / IMC Subject: Re: Do people have something against RSA? Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 6:07 PM -0600 6/22/00, Bob Jueneman wrote: >I don't disagree that PGP can use DSA. And if I were building and giving away >a product primarily to advance my own notions of social justice, >freedom, and privacy >for all, laudable as that might be, instead of trying to make a >reasonable living, I >would certainly pick a free algorithm also. But we were talking about IETF >standards, not freeware. OpenPGP *is* and IETF standard. It has the same standards level as S/MIME and PKIX does. You may not use it, and your company may not sell it, but please stop pretending it is not an IETF standard. >I don't think that the issue is one of large companies vs. small >companies, or even >individuals or nonprofit institutitions. We fully disagree here. Small companies cannot get reasonably-priced licenses for RSA today. Even large companies who have business models where they want to give away free software (have you ever heard of Microsoft, IBM, and AOL?) that happens to have good security in it cannot get reasonably-priced licenses from RSA. That is a business decision that RSA has had in place for many, many years. >Instead, the issue cuts to the very heart of t >he value of intellectual property, and whether someone, including >you, has a right >to make a profit from their creative endeavors. That's absolutely right. And, because there are freely-usable alternatives, we can ignore it. When the RSA patent expires, we can decide what to do about RSA vs. DSA. [ insulting assumptions about other people's motivations snipped ] >Unfortunately, it has gotten to the point that filing for an >invention has become >the kiss of death within the IETF. No matter how good the idea is, >if you patent it >the IETF will go out of their way to make sure that it isn't standardized. Bob, you need to get out into the rest of the IETF more. There are many IETF standards that use patented technologies. The patent holders have granted reasonable licenses to their competitors to use the technology in IETF standards. >The inevitable result of this is that either (1) companies will stop >inventing things, >since they won't be rewarded for them, or (2) companies will drop >out of the IETF >process, and ignore the standards as either irrelevant or explicitly >contrary to their >business interests. Is that what we want to have happen? The same argument has been heard here for many years, and it has never become true. I won't predict why that is, because my prediction mechanism is probably as badly flawed as yours is. If you (as an individual) want to drop out of the IETF, and/or if you want to try to convince Novell to drop out of the IETF, you are welcome to. What we want to have happen is that useful, freely-implementable standards can be created. There are many other standards bodies that have different agendas. Spend your time in them as you wish. --Paul Hoffman, Director --Internet Mail Consortium Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA00890; Thu, 22 Jun 2000 17:07:59 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 22 Jun 2000 18:07:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 22 Jun 2000 18:07:43 -0600 From: "Bob Jueneman" To: , Subject: Re: Do people have something against RSA? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id RAA00891 I don't disagree that PGP can use DSA. And if I were building and giving away a product primarily to advance my own notions of social justice, freedom, and privacy for all, laudable as that might be, instead of trying to make a reasonable living, I would certainly pick a free algorithm also. But we were talking about IETF standards, not freeware. I don't think that the issue is one of large companies vs. small companies, or even individuals or nonprofit institutitions. Instead, the issue cuts to the very heart of t he value of intellectual property, and whether someone, including you, has a right to make a profit from their creative endeavors. Because the Internet was originally paid for by the US government and member institutions, individuals never received a bill for service, and hence they tended to develop a sense of entitlement. "From each, according to their abilities, and to each, according to their needs" was the credo of the Communists, and to a degree that mantra seems to have been adopted by a segment of the Internet community. Since I "need" free movies, free MP3, free crypto, free computer games, etc., etc., and don't have the artistic or technical ability to generate them myself, I should be entitled to casually reach in and take whatever I want, without paying for anything. Minor details such as copyrights, patents, licensing fees, attorneys -- these are just impediments created by the "suits" to prevent my instant self-gratification. After all, these things are just bits, right? It isn't as though I was stealing a car, right? Sounds great, at least to the young and naive (as most of us were at one time). Unfortunately, although the Soviets tried this system for 80 years, and the Cubans, North Koreans, and some other societies are still trying it, the jury has come back with a verdict. Except in some closed societies, normally religious orders, this system simply does not work, and can only be sustained through a very harsh and cruel dictatorship. Those who have talent either opt out or become the bosses, leaving those who cannot to fend for themselves. If inventors cannot be rewarded for the fruits of their labors, then the entire structure of capitalism is without a foundation, and all of the IPOs and stock market gains are merely the Tulip Bulb mania repeating itself all over again. Unfortunately, it has gotten to the point that filing for an invention has become the kiss of death within the IETF. No matter how good the idea is, if you patent it the IETF will go out of their way to make sure that it isn't standardized. The inevitable result of this is that either (1) companies will stop inventing things, since they won't be rewarded for them, or (2) companies will drop out of the IETF process, and ignore the standards as either irrelevant or explicitly contrary to their business interests. Is that what we want to have happen? Bob >>> Paul Hoffman / IMC 06/22/00 04:27PM >>> At 2:55 PM -0600 6/22/00, Bob Jueneman wrote: >I'm still waiting to see piece of e-mail that was signed using DSA and >validated by a signature that also uses DSA. Start using PGP. >I'm glad that patents don't last forever, but we shouldn't begrudge them a >reasonable return on their hard work. It's funny how we never hear things like this from anyone who doesn't work for a large company. --Paul Hoffman, Director --Internet Mail Consortium Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA00153 for ; Thu, 22 Jun 2000 16:12:19 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 22 Jun 2000 17:11:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 22 Jun 2000 17:11:18 -0600 From: "Bob Jueneman" To: Cc: Subject: Re: Can we form certificates with just name and e-mail address Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA00154 Steve/Clark :-), >>But presumably there would only be one >{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="kent@bbn.com" >True. If the intent were to create multiple leaf entries below the single entry of this form then the justification would be better, but I don't that's what people have been suggesting. It's not that I particularly like compound attributes, but that's what I was suggesting, rather than having the rfc822 be a leaf under the user name DN. That's what I mean to imply by the plus sign -- exactly like most people have been suggesting for name+serial. At least the rfc822 name component has a great semantic content than a serial number. On the other hand, I guess we could always revert to the imfamous MPEG of me and my cat. But instead of putting it in the DN, I guess we would have to make it a directory attribute now. (Just joking, of course.) Bob >>> Stephen Kent 06/22/00 04:28PM >>> Bob, >Steve, > > >"Since e-mail addresses are >already globally unique, what does the given name and surname do for >you, from a tree structure standpoint?" > >Well, e-mail addresses are presumably globally unique, but they are >not necessarily >one to one with an identifiable person. Two or more people may share an >e-mail mailbox, and very often do. And one person may have more than one >mailbox, and many do. OK. But that does not justify constructing the schema we're debating, nor does the schema in question match your examples below. > >Likewise, there may be multiple Steve Kent's, and there might or might not >be multiple c=US, sP=MA, l=Cambridge, cN="Steve Kent". Yes, we need to have a DN that distinguishes among multiple Steve Kents. In your example above, a postal address would typically be employed to identify me as a specific residential person, or a binding to my employer would be used for me as an organizational person. >But presumably there would only be one >{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="kent@bbn.com" True. If the intent were to create multiple leaf entries below the single entry of this form then the justification would be better, but I don't that's what people have been suggesting. >Even so, that DN might be globally unambiguous, but not globally unique. >{c=US, l=Gotham, cN="Clark Kent"}+rfc822="kent@bbn.com" >may in fact refer to the same individual. No argument there. Multiple entries in the DIT may correspond to the same physical entity, ad would usually be true for residential and organizational persons, for example. >And both e-mail postal boxes and DNS components can have aliases, >so {c=US, l=Gotham, cN=Superman}+rfc822="Faster Than A Speeding >Bullet"@DailyPlanet.com >may also refer to the same person. Sure. Steve Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA29714 for ; Thu, 22 Jun 2000 15:58:58 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 22 Jun 2000 16:58:34 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 22 Jun 2000 16:58:24 -0600 From: "Bob Jueneman" To: , Cc: Subject: Re: certification for pki Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA29715 I attended the recent International Common Criteria conference in Baltimore, mostly to learn the answers to these kinds of questions. My assessment would be as follows: 1. The Common Criteria, and the fact that 13 or so countries have agreed to it, is not really a criteria at all, from the usual perspective, but rather a meta-criteria or specification language for laying out in some (excruciating) detail what the requirements are, and how you have met them. As a process for convincing yourself, or your industry, that you have thought hard about the problem you are trying to solve, it is excellent. 2. The real "guts" of the issue, however, is not how you specify the requirements, but what the requirements really are. And this is done through the Protection Profile. 3. Unfortunately, there are as yet very few Protection Profiles that have been published, and even fewer, if any that have been widely vetted and accepted by a broad segment of the user community. 4. One of the best examples of a good Protection Profile is being hammered out by the smart card industry, with the clout of the banks and credit card companies behind it. That will almost surely emerge as a almost universally accept PP. 5. Some of the worst (from the standpoint of universality) Protection Profiles may be in the area of PKI. It should be obvious, but if there is substantial disagreement as to the fundamentals of the digital signature law of the jurisdiction, there is not likely going to be any commonality regarding the Protection Profile. As a result, I would expect that if say Siemens expects to sell a PKI for use in Germany, they will eventually have to get it certified against the German Protection Profile. But having done so, that may or may not carry any weight at all with respect to say the State of Utah's PKI requirement. And vice versa, for someone like Digital Signature Trust if they try to sell into Germany. In other words, I wouldn't bet a whole lot of money on the Common Criteria being a roaring success, and especially in the PKI space. And I say that, even though I'm a firm believer in the value of an independent evaluation of important software components. Time will tell bob >>> 06/21/00 09:47AM >>> It is not a choice of CC vs. FIPS. The FIPS 140-1 testing pertains narrowly to crypto modules. The CC evaluation/"torture" process is about the system/components for certificate issuance and management meeting its security specification (security target and claimed PP(s)). A crypto module is just an embedded "engine" in the larger vehicle. To continue with the automotive metaphor, it is not a choice between auto emission testing vs. crash testing vs. fuel economy vs. performance testing, etc. All of these tests may be required for the consumer to understand and compare what they are buying. It may be "torture" for the manufacturer, but when the market (or laws, regulations, etc.) demand it, manufacturers do it. -GH pgut001@cs.auckland.ac.nz on 06/21/2000 11:11:43 PM Please respond to pgut001@cs.auckland.ac.nz To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: Re: certification for pki ghilborn@csc.com writes: >One internationally recognized avenue is an evaluation under the Common >Criteria/ISO 15408. Such an evaluation up to EAL4 is automatically recognized >by the (currently) nine mutual recognition arrangement countries. Two current >problems are (1) that the CC itself does not contain a crypto module >evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus >and evaluated Protection Profile for PKI components. Some product vendors >have undertanen evaluations without PPs. FIPS 140-1 is officially US/Canada, >but also widely recognized. A third problem with the CC, for those who haven't experienced it before, is that it acts as a form of torture for companies to determine how badly they need government (or whatever) contracts - the more pain you can stand, the better you've demonstrated that you need the contract. I'm not just saying this for $generic_CC_bashing, from talking to people who have gone through it it really sounds like an incredibly unpleasant experience (when I used the term "torture" to describe it above this doesn't originate with me but with the people I talked to). In terms of achieving more or less the same effect (the certification that is, not the torture :-) it looks like FIPS 140 is the easier path, and it does constitute a de facto PP which the CC doesn't have yet. I'd go with FIPS 140. Peter. Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA29167 for ; Thu, 22 Jun 2000 15:31:51 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA09740; Thu, 22 Jun 2000 18:32:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 22 Jun 2000 18:28:43 -0400 To: "Bob Jueneman" From: Stephen Kent Subject: Re: Can we form certificates with just name and e-mail address Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Bob, >Steve, > > >"Since e-mail addresses are >already globally unique, what does the given name and surname do for >you, from a tree structure standpoint?" > >Well, e-mail addresses are presumably globally unique, but they are >not necessarily >one to one with an identifiable person. Two or more people may share an >e-mail mailbox, and very often do. And one person may have more than one >mailbox, and many do. OK. But that does not justify constructing the schema we're debating, nor does the schema in question match your examples below. > >Likewise, there may be multiple Steve Kent's, and there might or might not >be multiple c=US, sP=MA, l=Cambridge, cN="Steve Kent". Yes, we need to have a DN that distinguishes among multiple Steve Kents. In your example above, a postal address would typically be employed to identify me as a specific residential person, or a binding to my employer would be used for me as an organizational person. >But presumably there would only be one >{c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="kent@bbn.com" True. If the intent were to create multiple leaf entries below the single entry of this form then the justification would be better, but I don't that's what people have been suggesting. >Even so, that DN might be globally unambiguous, but not globally unique. >{c=US, l=Gotham, cN="Clark Kent"}+rfc822="kent@bbn.com" >may in fact refer to the same individual. No argument there. Multiple entries in the DIT may correspond to the same physical entity, ad would usually be true for residential and organizational persons, for example. >And both e-mail postal boxes and DNS components can have aliases, >so {c=US, l=Gotham, cN=Superman}+rfc822="Faster Than A Speeding >Bullet"@DailyPlanet.com >may also refer to the same person. Sure. Steve Received: from [165.227.249.13] (ip13.proper.com [165.227.249.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28904; Thu, 22 Jun 2000 15:27:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Thu, 22 Jun 2000 15:27:16 -0700 To: "Bob Jueneman" , From: Paul Hoffman / IMC Subject: Re: Do people have something against RSA? Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:55 PM -0600 6/22/00, Bob Jueneman wrote: >I'm still waiting to see piece of e-mail that was signed using DSA and >validated by a signature that also uses DSA. Start using PGP. >I'm glad that patents don't last forever, but we shouldn't begrudge them a >reasonable return on their hard work. It's funny how we never hear things like this from anyone who doesn't work for a large company. --Paul Hoffman, Director --Internet Mail Consortium Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA28217 for ; Thu, 22 Jun 2000 14:46:44 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 22 Jun 2000 15:46:22 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 22 Jun 2000 15:46:24 -0600 From: "Bob Jueneman" To: , Cc: Subject: Re: Can we form certificates with just name and e-mail address Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA28218 Steve, >"Since e-mail addresses are already globally unique, what does the given name and surname do for you, from a tree structure standpoint?" Well, e-mail addresses are presumably globally unique, but they are not necessarily one to one with an identifiable person. Two or more people may share an e-mail mailbox, and very often do. And one person may have more than one mailbox, and many do. Likewise, there may be multiple Steve Kent's, and there might or might not be multiple c=US, sP=MA, l=Cambridge, cN="Steve Kent". But presumably there would only be one {c=US, sP=MA, l=Cambridge, cN="Steve Kent"}+rfc822="kent@bbn.com" Even so, that DN might be globally unambiguous, but not globally unique. {c=US, l=Gotham, cN="Clark Kent"}+rfc822="kent@bbn.com" may in fact refer to the same individual. And both e-mail postal boxes and DNS components can have aliases, so {c=US, l=Gotham, cN=Superman}+rfc822="Faster Than A Speeding Bullet"@DailyPlanet.com may also refer to the same person. Signed, "Leaps Tall Buildings with a Bound and a Half"@novell.com :-) >>> Stephen Kent 06/20/00 09:13AM >>> Stefan, >Steve, > >Thank's for useful input. Just to round this up, can you confirm the >conclusion that issuing certificates where subjects are represented >by just e-mail address + givenName + surname (and maybe also >country) is simply not possible. > >The name must simply be combined with a serialNumber attribute or >some other information that makes the name (with e-mail address >excluded) a reasonable DN. > >Right? Well, its possible to issue certs with any sort of DN. The question is what makes sense given the semantics of a DN, not just viewing it as a string of AVAs irrespective of context. The question I would ask is what would the directory tree look like given a proposed DN. How would the tree be distributed and managed? Think about the schema with those considerations in mind. For example, if one uses a geopolitical and organizational structure, which is the common model for DNs, we see lots of reasonable options for dividing the tree and determining who is responsible for maintainign what portions of it. On the other hand, if a DN consists of an e-mail address plus givenname and surname, this seems rather odd. The e-mail address, as a single attribute, results in a very broad fan out under the root. (in contrast, if one used DC attributes, as mentioned recently, one could mimic the structure of the DNS, which is well suited for separation and distributed maintenance, as the DNS has shown.) Since e-mail addresses are already globally unique, what does the given name and surname do for you, from a tree structure standpoint? Steve Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27706 for ; Thu, 22 Jun 2000 14:12:28 -0700 (PDT) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A1472110046; Thu, 22 Jun 2000 23:12:39 +0200 Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Do, 22 Jun 2000 23:13:33 +0100 From: "Peter Lipp" To: "Bob Jueneman" , Subject: AW: Do people have something against RSA? Date: Thu, 22 Jun 2000 23:13:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.D38462D0--"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.D38462D0-- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob, > I'm still waiting to see piece of e-mail that was signed using DSA > and validated by a signature that also uses DSA. It isn't that it > couldn't necessarily > be done, it's just that it would be such a curiosity that I would=20 > be inclined to=20 > frame it. You did not insist on S/Mime, did you? :-) Peter -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.2 for non-commercial use iQA/AwUBOVJzV957bAzp9yvZEQJpCACg+kFddmAtF1sQLcxsQb08tuvEwUAAn33F cEdI+b9r5DlcFZOZR6yC2MQb =3DbEaT -----END PGP SIGNATURE----- ----IAIK.SMIME.MAPPER.D38462D0-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC 2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9 ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy 2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE 6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx 2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7 rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8 lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3 DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI 7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG 9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6 Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25 sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9 l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q 19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6 ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1 OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B 2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1 2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64 vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMDA2MjIyMTEzMzNaMCMGCSqGSIb3DQEJBDEWBBQ/i1ZRD+w5COw7 9cM6hVYFk6tY/TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN BgkqhkiG9w0BAQEFAASBgJXgdAkoIEwjh6cRhyFIvtUWzUyPGjpZFftbgpI5uHNT rNgxnYRj6fHTi5JqpzHDDxTGl5lDCobGDzTu4of1x1REUBOVv+6i/sRreNeHB8Rw SODA4+ZuyJCXrddfEjugoUWums+oERrslP9hOh/dBipiEja0HZ+dyct9jOdoiHU7 AAAAAAAA ----IAIK.SMIME.MAPPER.D38462D0---- Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA27286 for ; Thu, 22 Jun 2000 13:55:54 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 22 Jun 2000 14:55:27 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 22 Jun 2000 14:55:21 -0600 From: "Bob Jueneman" To: , Subject: Re: Do people have something against RSA? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA27287 Amen, brother! I'm still waiting to see piece of e-mail that was signed using DSA and validated by a signature that also uses DSA. It isn't that it couldn't necessarily be done, it's just that it would be such a curiosity that I would be inclined to frame it. It's exactly like when all of the coin machine vendors were forced to change their machines to handle the Susan B. Anthony dollar, only to have that coin sink like a rock. The Post Office (and only the Post Office) issued them as change if you bought a book of stamps, and anyone who received one got rid of it at the first opportunity. In the meantime, mandating particular algorithms that no one uses adds very significantly to the cost of development, testing, and documentation, not to mention bloated code. And piling on additional, "standardized" optional algorithms just makes things worse. "The nice thing about standards is that there are so many different ones to choose from." Fortunately, the various vendors are quite free to say "Nuts to that" and ignore the political correctness nonsense, and many of them are doing so. RSA may very well be the Lavoris of cryptography -- the mouthwash you love to hate, twice a day -- but their standards, including the PKCS suite and S/MIME (along with Netscape's SSL, for all of its warts) have been commercial successes, while the adoption of IETF standards in this space have been lukewarm at best. And they (along with Phil Zimmerman) were the ones who were standing up to NSA and refusing to back down when the government wanted desperately to put the crypto genie back in the bottle. I'm glad that patents don't last forever, but we shouldn't begrudge them a reasonable return on their hard work. Bob >>> "Christopher Williams" 06/16/00 11:35AM >>> OK, maybe RSADSI are litigious and awkward to deal with. I don't know, I've never dealt with them. However, let's say that I implemented a standard, say TLS, and only included the mandatory cipher suite, DSA with ephemeral Diffie-Hellman, SHA-1 and 3-DES encryption. You know what? It wouldn't work with anything! Everybody else's implementation uses RSA so mine has to as well, whether I like it or not. The reality is that RSA is mandatory and DSA the nice optional extra which adds spice and competitive advantage. As to whether the future belongs to RSA or maybe some recent innovation like ECC or some as-yet uninvented scheme, as Microsoft shows, it's not being the best that makes you the winner, it's being the most widespread. So, given that: - RSA's patent is due to expire (news to me, but welcome news) - DSA has patent issues in Europe - Everybody uses RSA anyway; very few use DSA Can we please start mandating RSA in future? It will make implementing standards much easier and remove the FUD because I haven't incorporated support for Diffie-Hellman! Christopher Williams Software engineer, NetLexis Ltd. http://www.netlexis.com "Intelligent Trust" Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26863 for ; Thu, 22 Jun 2000 13:36:35 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id QAA29237 for ; Thu, 22 Jun 2000 16:28:36 -0400 (EDT) Message-Id: <200006222028.QAA29233@roadblock.missi.ncsc.mil> Date: Thu, 22 Jun 2000 16:34:01 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: OgKp0bhJ2vWpkO0jtilCTg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc > From: Michael Zolotarev > > 1. Self-signed TSA cert. You have to evaluate your secure signing > environment. Which is the same for generating timestamps and for generation > a self-signed cert. What security-relevant information are you expecting clients to derive from validating the signature of a self-signed cert? Do you expect clients to have trusted storage which could hold a bare TSA public key, but which could not hold the entire self-signed TSA cert??? Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26622 for ; Thu, 22 Jun 2000 13:31:17 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5MKQgX06011 for ; Thu, 22 Jun 2000 13:26:42 -0700 (PDT) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FWKOZP01.XI2; Thu, 22 Jun 2000 13:31:01 -0700 Message-ID: <39527784.1BC470B@netscape.com> Date: Thu, 22 Jun 2000 13:31:00 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Halliden CC: "'Paul Koning'" , seidel@timeproof.de, FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <61922E6DA745D311A42000508B2CFD14B9677A@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul Halliden wrote: > Certainly, as Terry argues, collisions in the TSA's own process will always > be a concern. Whether or not end entity collisions are a concern to the TSA > is application dependent. As a minimum, collisions deliberately created by > the end entity would be an embarrassment to the TSA and affect the > perception of it in a public dispute. Again, I would argue that it is > safest not to make assumptions about the application. Embarrassment to the TSA should result from failure to provide a correct and secure timestamp, not from the content that is being stamped. If you are worried about embarrassment, perhaps you should insist on seeing the entire message, rather than just an imprint. After all, the imprint may be referring to racist material, or plans for terrorist attacks. While I'll grant that the imprint algorithm used (and the appropriateness of the value given for that algorithm) are important for the functioning of the process, I don't see any need to have the TSA enforce restrictions on them at the time the timestamp is created. If the primary goal is achieved (correct and secure timestamping of the imprint), then a dispute resolution process can determine whether a reasonable imprint algorithm (for the time) was used. A TSA MAY choose enforce restrictions on the imprint, but the standard should not REQUIRE it. Terry Hayes Received: from stonewall.baltimore.com (mailhost.baltimore.com [195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA25708 for ; Thu, 22 Jun 2000 12:36:29 -0700 (PDT) Message-ID: <61922E6DA745D311A42000508B2CFD14B9677A@baltimore.com> From: Paul Halliden To: "'thayes@netscape.com'" Cc: "'Paul Koning'" , seidel@timeproof.de, FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt Date: Thu, 22 Jun 2000 20:36:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Terry, Michael I agree that finding "meaningful" collisions *can* be substantially harder than simply finding two arbitrary strings with the same hash. How much harder, depends on the application. For instance, if a strictly formatted message has provision for a 64-bit randomly allocated nonce, the task is no more difficult. The point is that, as security system designers, we should not make any assumptions about the message and it is therefore safest to assume that creating a set of meaningful messages is not significantly more difficult than creating un-meaningful ones. Ok, there are many cases where that will not be valid, but... Certainly, as Terry argues, collisions in the TSA's own process will always be a concern. Whether or not end entity collisions are a concern to the TSA is application dependent. As a minimum, collisions deliberately created by the end entity would be an embarrassment to the TSA and affect the perception of it in a public dispute. Again, I would argue that it is safest not to make assumptions about the application. As regards the possibility of actually mounting a "brute force" attack on MD5 today, I originally said that "this task is far from trivial". That is British understatement for "very difficult". As far as I am aware, the largest exhaustive search was for 56-bits in 1997 - and that required massive distributed processing. Searching for a collision would also require large amount of memory / storage (one has to store the variable part of 2^64 [meaningful] messages and their hash in order to have about 50% probability of having two identical hashes). So I do not expect to read of a successful brute force attack on MD5 this year - but I would not express great surprise if it happened. Regards Paul Halliden >-----Original Message----- >From: thayes@netscape.com [mailto:thayes@netscape.com] >Sent: 22 June 2000 19:13 >To: Paul Halliden >Cc: 'Paul Koning'; seidel@timeproof.de; FRousseau@chrysalis-its.com; >Denis.Pinkas@bull.net; ietf-pkix@imc.org >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt > > >Paul, > >Addressing the first point in your message (a client >submitting a "cooked" MD5 >hash for timestamping), there are two points to make: > >1. Finding collisions in MD5 is still hard, and finding >meaningful ones much >harder. >2. It is not the concern of the TSA whether the client has >chosen a form of >message imprint that will hold up under a challenge. The >TSA's function is to >associate a timestamp with the message imprint, no more. >Whether that message >imprint can be used later to convince a third party that a >particular document >was reference is more important to the client. The client >should choose an >imprint algorithm that will meet their requirements. > >Addressing the second point (getting the TSA to generate a >colliding time stamp >token): > >1. Again, it is difficult to find meaningful collisions. >2. The TSA is concern in this case, since a collision could >result it a token >that indicates a different timestamp (probably an earlier one). >3. The TSA should choose a strong signature algorithm that >will provide the >appropriate level of assurance for the required time period. >I suspect that >many TSAs will choose a signature based on SHA for this >reason. They will also >choose key lengths depending on the desired security level. >4. Since a large part of the timestamp token is fixed or >guessable, t is >probably worth including a "nonce" value in the generated >signature to make it >difficult to force the TSA into generating a colliding >signature. This value >can easily be incorporated into the CMS SignedData object as a >signed attribute. > >Terry Hayes >Netscape Communications Corp. > >Paul Halliden wrote: > >> There were two potential issues with MD5. The first one was >an indication >> that, at the time MD4 was "broken", MD5 was expected to fall >to a similar >> attack "in the near future". That has not happened so far. >We do not know >> if that is because the task was too hard or if it was simply >that no-one has >> got round to trying. But it was the reason that many >stopped using MD5 at >> that time. >> >> The second potential issue concerns the size of an MD5 hash, which is >> shorter than an SHA-1 hash. If an end entity is able to >create two messages >> that have the same value of hash, he can submit the hash to >the TSA and then >> subsequently claim that either of the messages existed. When >challenged, the >> end entity presents whichever version of the message best >suits his argument >> - an adjudicator would not be able to tell which was the >genuine one. Whilst >> this task is far from trivial for a 128-bit hash such as >MD5, I believe it >> is the same order of magnitude as finding a 64-bit symmetric key by >> exhaustive search. (IANAC - so any cryptographer / >mathematician please feel >> free to correct me). >> >> This potential attack is, IMHO, more significant for a TSA >where one entity >> chooses the message and generates the hash and a second >entity signs it (as >> part of the timestamp). >> >> Regards >> Paul Halliden >> >> >-----Original Message----- >> >From: Paul Koning [mailto:pkoning@xedia.com] >> >Sent: 19 June 2000 16:00 >> >To: seidel@timeproof.de >> >Cc: FRousseau@chrysalis-its.com; Denis.Pinkas@bull.net; >> >ietf-pkix@imc.org >> >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt >> > >> > >> >>>>>> "Joerg" == Joerg Seidel writes: >> > >> > Joerg> Comments inline. >> > >> TSA implementations MUST support SHA-1. TSA implementations >> > >> SHOULD support MD5. >> > >> > Joerg> I think there are good reasons not to use MD5 in time >> > Joerg> stamps. They should use a strong hash function in order to >> > Joerg> achive long validity periods. MD5 is likely to be >unsafe (=not >> > Joerg> collision free) soon and is already discuraged by german >> > Joerg> authorities. >> > >> > Joerg> IF we add a section about algorithms, it should maybe read: >> > Joerg> "TSA implementations MUST support SHA-1. TSA >implementations >> > Joerg> SHOULD NOT support MD5.". But I think such a section is not >> > Joerg> very necessary. >> > >> >IANAC, but from what I understand the currently known attacks on MD5 >> >are nowhere near strong enough to justify that. >> > >> >I don't have a problem with the current text (SHA-1 required, MD5 >> >recommended). I do have a problem with text that implies >that MD5 is >> >bad, because I don't know of data that supports such an assertion. >> > >> >Also, it doesn't seem like a good idea for the timestamp >spec to give >> >very different signals from the other security specs. If >there really >> >is good reason to say these kinds of things about MD5, >let's have them >> >identified. (German authorities are not a good reason. >Cryptanalysis >> >that shows weaknesses of interesting size would be.) If the issues >> >are real, changes to MD5 text should be applied across the board. >> > >> > paul >> > > Received: from c004.sfo.cp.net (c004-h028.c004.sfo.cp.net [209.228.13.45]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA25584 for ; Thu, 22 Jun 2000 12:27:36 -0700 (PDT) Received: (cpmta 10974 invoked from network); 22 Jun 2000 12:27:08 -0700 Received: from cs9341-212.austin.rr.com (HELO tuvit.net) (24.93.41.212) by smtp.tuvit.net with SMTP; 22 Jun 2000 12:27:08 -0700 X-Sent: 22 Jun 2000 19:27:08 GMT Message-ID: <3952689A.BD002B70@tuvit.net> Date: Thu, 22 Jun 2000 14:27:22 -0500 From: Roland Mueller X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Paul Halliden CC: "'Paul Koning'" , seidel@timeproof.de, FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <61922E6DA745D311A42000508B2CFD14B96779@baltimore.com> Content-Type: multipart/mixed; boundary="------------C8515E6EAC751FF5702124B6" This is a multi-part message in MIME format. --------------C8515E6EAC751FF5702124B6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just take a look at CryptoBytes Volume 2, Number 2 which I'll attach. As far as I recall, MD5 was considered broken at Eurocrypt 96 Roland Paul Halliden wrote: > There were two potential issues with MD5. The first one was an indication > that, at the time MD4 was "broken", MD5 was expected to fall to a similar > attack "in the near future". That has not happened so far. We do not know > if that is because the task was too hard or if it was simply that no-one has > got round to trying. But it was the reason that many stopped using MD5 at > that time. > > The second potential issue concerns the size of an MD5 hash, which is > shorter than an SHA-1 hash. If an end entity is able to create two messages > that have the same value of hash, he can submit the hash to the TSA and then > subsequently claim that either of the messages existed. When challenged, the > end entity presents whichever version of the message best suits his argument > - an adjudicator would not be able to tell which was the genuine one. Whilst > this task is far from trivial for a 128-bit hash such as MD5, I believe it > is the same order of magnitude as finding a 64-bit symmetric key by > exhaustive search. (IANAC - so any cryptographer / mathematician please feel > free to correct me). > > This potential attack is, IMHO, more significant for a TSA where one entity > chooses the message and generates the hash and a second entity signs it (as > part of the timestamp). > > Regards > Paul Halliden > > >-----Original Message----- > >From: Paul Koning [mailto:pkoning@xedia.com] > >Sent: 19 June 2000 16:00 > >To: seidel@timeproof.de > >Cc: FRousseau@chrysalis-its.com; Denis.Pinkas@bull.net; > >ietf-pkix@imc.org > >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt > > > > > >>>>>> "Joerg" == Joerg Seidel writes: > > > > Joerg> Comments inline. > > >> TSA implementations MUST support SHA-1. TSA implementations > > >> SHOULD support MD5. > > > > Joerg> I think there are good reasons not to use MD5 in time > > Joerg> stamps. They should use a strong hash function in order to > > Joerg> achive long validity periods. MD5 is likely to be unsafe (=not > > Joerg> collision free) soon and is already discuraged by german > > Joerg> authorities. > > > > Joerg> IF we add a section about algorithms, it should maybe read: > > Joerg> "TSA implementations MUST support SHA-1. TSA implementations > > Joerg> SHOULD NOT support MD5.". But I think such a section is not > > Joerg> very necessary. > > > >IANAC, but from what I understand the currently known attacks on MD5 > >are nowhere near strong enough to justify that. > > > >I don't have a problem with the current text (SHA-1 required, MD5 > >recommended). I do have a problem with text that implies that MD5 is > >bad, because I don't know of data that supports such an assertion. > > > >Also, it doesn't seem like a good idea for the timestamp spec to give > >very different signals from the other security specs. If there really > >is good reason to say these kinds of things about MD5, let's have them > >identified. (German authorities are not a good reason. Cryptanalysis > >that shows weaknesses of interesting size would be.) If the issues > >are real, changes to MD5 text should be applied across the board. > > > > paul > > --------------C8515E6EAC751FF5702124B6 Content-Type: application/pdf; name="crypto2n2.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="crypto2n2.pdf" JVBERi0xLjENJeLjz9MNCjEgMCBvYmoNWy9DYWxSR0INPDwNL1doaXRlUG9pbnQgWzAuOTUw NSAxIDEuMDg5XQ0vR2FtbWEgWzEuOCAxLjggMS44XQ0vTWF0cml4IFswLjQ0OTcgMC4yNDQ2 IDAuMDI1MTggMC4zMTYzIDAuNjcyIDAuMTQxMiAwLjE4NDUgMC4wODMzNCAwLjkyMjddDT4+ DV0NZW5kb2JqDTIgMCBvYmoNPDwNL0NyZWF0aW9uRGF0ZSAoRDoxOTk2MDgwNjE5MzcwNikN L1Byb2R1Y2VyIChBY3JvYmF0IERpc3RpbGxlciAyLjEgZm9yIE1hY2ludG9zaCkNL0tleXdv cmRzICgpDS9DcmVhdG9yIChBZG9iZSBQYWdlTWFrZXIgNi4wKQ0vVGl0bGUgKCpDQnl0ZXMg U3VtbWVyIDk2KQ0vU3ViamVjdCAoKQ0vQXV0aG9yIChQYW9sYSkNPj4NZW5kb2JqDTQgMCBv YmoNPDwNL0xlbmd0aCAxMjg4NA0vRmlsdGVyIC9MWldEZWNvZGUNPj4Nc3RyZWFtDQqADEQG cQDCCiAbDEZCAbjmFnIyiAzQczg2BQSDQaEwuGw+IxODRUhFQGi8jDUQQIqGYGjgbweDS6Uj SBDabC6UFQ2g2DFQ5TyUwUXDmBQY1g0WjAXDAYyoxg0tighikajAUHIUi0Z1Y8nAUjYUHQ31 QZCghCmtig81+wmUUjEZig5ikulQlA0iySDUWh0UQEuLCA0wclQc1CCFneUwYmiAtl2DGSLD IbQyaCCdjUb5Ub5c2A0pg2RyUjS+VSwbTiYQjVDOE5bKzqgRWlDAZjQQFSnz07g0UFYQE8QE wQFUQY0iiDlQsWcoQE7i8cQEIQckpc6FiAuDMZQIQFPo43kCDr8qBDkQegbCkqGq8XrVYrJj UXDeUZ2FzuFfT7CAZpQz7Qq2+oYpeGwaPqGaXs2FwZIaEAWhkHL6hw9CIAaljRpMGK9tylgb qGGb0IyhkKPQGYZhcHAZBwEAavo7iFtkpTKtopYYJyp6oiGKS0BuFAsigKi3hwFAniOKQgig JAkqmuq7ryngXMqI8pMS/0VQO6THsiBo4ykGrXNxEilBqygZtWMadhvFKUKaGQXKays1xSGc VpSuEphw3AbzgGAczcGL6JchYbBwvtA0HPoQKem8CxaptFULBDbNwpsUhzB8DqW288KUykW0 bSlOw41IbKYhDUhgysOQQGwctxQ0VBxNwYVdWFGAaG4YpwGlIVtKdcTYpYa1ZVYXK2zk2sXQ 6N1zXcGhwgUOWahQQM/aCmVrEAZqahilUE01joSytZBzNFSymGLK0bEEcWncd11TBtM2ZZFu 3nCTTQ5BsRVym99TxFIZVjEAcBtQNMJRc10TzQFnqUzdLYc+9eVbPE4PsjleRZaaFTjeSnjm BooqgyAQMlL8yzE1cyzPNM1wQzbFwRTKUTW1Nz0tYGbWvXWc1JP84zRbEJhlBzFwmuGfBwpW DvRDmlTRpqhhrX9D2LFuqUBX8QKa9Cn63qzF1UGSUWkpYaWM+gaBvrWLVxVqhv7sMU4Rmm5w Alu7Vq+mzMqz4cRTAu1hcGkUBBwU45nDlBhjrXB8YGFuJfuvF2NCb/oXFb6ttpMphul+0cFT yltfsM4BxaXSpoyvFbaham14Gmj8TFPYYwnGwb3w1F0unFV8TOFAYm+gaqJxNwQlPHjeQp7O vrVlBd0gTPjRn8Q4mpSiPRnHs4E+ux6K+vwPtFvA14GAYdjPPzcTjkw9zc/3wb+M32RQ1c7R s2G15brWkaPIKa9sGJ6CGk4Ts6V7iuWRslS4yhLyYGWJkJwy9EiaiWoTByDlq7VT8gNXOr1S D03jvVhA+lxCkXqNMUOudhr223NMNSn1qEJHkOBQQ7J5kK3AogdC1AGELU7w9Pqg9uTPXAwa g43iJADYGsmS6yqBCWoKJmBsmiC5O1MuGVovZppuD9PqKW8taiKlbM+Q46lPcXozocduvJ2S DYyG2cNHBj8BVcxujq9JBCDlapwQK8WFaHFwOPh3CVXKgEGk2kPDeEDfpGRHP6Z+Lavlas1k mA168lYuwDSnAmLSIJLPlfFCBowNGEvhfORaMQNjuykV+3CEadY5yydyhI3BT0OS2jiiteEv F+RXRbBtXrHkaQJZEySKEEIpJhioTCCsV2YEWX4bZjyKVdpoP0nlgj5Wlmfd/N2FUiJwLAVO +x5sJm5Tnm80SVjBlrO/mzGhyaKp4s8kzJ6a0TJMxPgeymCUzyMzRiwQeDDv3DqBU+6Sbbtz /mLRgnhr0KZzNxcfAhX6t5czUg04dvCr1LAybsZdxqyCU0iSnSRfiLE0S6pQgdj0kHpUdYap JPDWIEwqUJHlArQ6aoqd8nmhMOzKPSodQpaNLZNTUPowh7VSTMVMSmDVibA0X0SWRVUodFqc Szq3Rtr6CajVfpO7N2s4arkKrM+yhdSq1OGrPPVbrHkJpsWMakzT7KutkJwouXVPWg14qDU2 qhi1uLehVU50tLIGTKn/BFldAihRWoKQag6A3JwdBzEGqJcE4VUs1ZycB3ClxAhmlouBSm1L oWPXmk8Gj+rptdS5Q7aq719diZRWdrFuGUpOal1UL45Vgt1cF+QNKQqHNuvtUbUEJIhTxc2P K3XDRLKbdKzz9X2MZs5dls1216VgNu71jycJcRovGf9hs2GxlwRSqt6VNiFITWlOioBC6XGp pFfZ1RpmCJTfY4MGq07/yusW/GlyrnY2taQQpnLtKPtxueVVeFGrpuzX9OtuNpLv0Qqmm60i 0lampWTdO95rp+N6LggjAaxpMYqvHi10qryX2jNrDGT2NGfT+ZPQCyKY5oWUmmXBEB3cKt5s 6iJZEnZ8YwczkxqUaCaOgV/lGcDh1kR4ai0Mmbt7uxBJw/kGOWAaZfa9HiXWZMvtlTdmRetJ W2qQywgeS+SM0mpyPE3MeeMPN/ylU3BqOHDQplRgBcTjs5aAXE5SPOhZXLicymYmZ9FBM7Qm DZ0JM4+urn06ci2hUUTGj3pModIk8Vr1IQ5htn3d5jPpqp8BVVWaFzKomQbtCcQjnTdPItiI bQmeuXDJ9SIFn6yUnaVL7sryAwHLDKTt37PtvblgG8bWPvzzHNjaycDXKh0/tpib/pDbZTjh CT0C8xq8g5COAju8eRRoDkCgeQos6frrPdr00j9Jhk/gvfM7tK5ZwXi+NCxT66mklipMxQ9O a/4Laqs/DsrqmofwnKULXfZNZ9sHAaU7UJ5gKnMi3HaQPg5DwW968IWr1nAVVZEbcwQbxrE6 x2PbIRT3lZOC1Bj9KnSzB2L9nYrx1wWofoM4GAaYjYpYm5DYascjJ02Dbuc0EW6lDWPtsWEE 4M1I1afQ9bSIl01alMNdd8tWaDSIHBOkNOzFxp63Vu3bsk+i3nvc9ndIThK6r2yurKUc9PK9 qm72p5O41DwkI7zK4l14nU6KpXrrxZ3SYRKZXalqf5WZMDubTNgnkHndlj9H2Ti6pz9drO+k cfRnJE4HQuGcnimNHr8yr77ORb1XppxyOQLpT3RTcwno9c+ltvj1i/C9x8T20POrdGRZ16NC skV+sz0tn4vFvhtp0hWLHfNd4Y/ZbQTIbaOT+7IF6PjGuvmKPbn9SfP5Ac4u9bzTzn3+cfh3 pzwixDozQ1kAXkP0/4VefAUMUsKI9gkEp29Wjkp+p2l0Voi4+XAUcUNuwCbmahAo3MpWfzAe Tq3MXGVQceRhAGw0UsdUTibioqrAs2RUWKwjAM24buXSxKgKdST+XsWcl1BYePBwWsnBBYO4 Z2sOWmQqcMkiXiVZBOpEV+VMZCIsYOfwr4XIJTAgVOVquUXxBESmRwsWX9AeqbC4nDBMa8TY fAYfAXCXDMJRB0xvAtDPBYJo1WfCdjB2/8ZAXY/oNmAaQGV2NMywM0gMv0QeBaegTYJeQuJY Q6gIIOKPEUL6IOMAIEMUse88skZcmk3qzGRAJsIXCWQas6ReSzE6baSmykQmbVE6sKkoaMwM bMNxFWkXFS+QkUVXFkZ9FpFa8ulXFxE6S0/4YPF6qaPSV5E4MQ63Dw+lFzGEM+0xFjGNGE63 FrGMdSIQPpGkMoV429GjFaRZE/GZGtG4QMyLG4QQVi6NHIcMkTGJHRFehAdTHYPTHBE6t9F4 MQaQKfHqpEhMmIMpE6XxFhH6MQNdG8lZHXH8v0notrFa1xHafvGuTsRUjQgK49H86MjQBk7d FGU/IuUPGuzLIIvnFEMQymlWLgVNIXGyylIzIEUOIWyvE3FbIhJcAaDEmURoIGSkSoTABBEm 863i/w9CUY32lFFazHIi57IMMRKNJKITIpKUnVKbGKO6L26HGAMQzAdiU3KtIxJajyJdJFK5 JBCLFRKvK6gLKSyMJTAPKkWtB1LQ0cjRLXIWuBCpFPIXFPCoYNLvHS8aQRK27VHS6QRTL/Lw XXLeYM8tLfLo8bLe4AM1CNFHMdKJH9E24LHfMpFLJfLAupJm3SdNH8Y4vQuBJjL8vQNrNJIi nBG7ICpE4AO7GdNbIkvpJjGJIkThLJH1MylYWbJib9FvNnHmNTIaWPNZIw4LMnHsIM5bOQO7 NKM/JqZKQ0CMQ4KCJXD2Tqi6RItIPsMqtIXWamacbGRmKDEWKMSkfWPQN0N8CkCmCCPYPcSj EceQIMMAYjJ4MdJ8/AirKCgwU2TsXQ34doZuV0TbQAdubMZ8WGfs2qL7JmcU96JTQYKJJnBY iCdjQkWtDgrSVkqoJfQ0Tc8uuQ29Q+JTMeT2TRBYRWahFCqoPOdm2aUFQPDXIKQpRLRknoV4 xwqpC25mmIbdRWRgsLR8QrRKZyUXSG8QTaeDHwrrSIQLGylQPSh8usWHOaPShywaegcEvwhA axSicIWQt8l2U4XQaoReXEhRTKbYM6jyKZTJLqXuIWg5BaVZTmQ4dFSMWnTs9iVEyWXRT25m evQUXQbccMwgTogRLUKUX8cC0okjCBFmRo3NUhGGfIceZzC5AONMT2V7HVUsaoIUc2cy4rUK uQc3HKTu/ZVMsa/qmZJ/P3Ew/0jKUMVZGaUes6zBVpMSk+6ei4VY4WYIXQQcRNRKvMo8l0uo 2rRXWMXQ1AutQDQQ1cWQusJuYOcq0+RhSpL8w2rrSoW4jWvdUtUKJdWvVCntCIV4RfNce2uR Co3VScovQtCoYyxQKbI7VTCgaOIEr/XvDoU+kiaOyzT/XSd8bMSzLVYJS4xWKWsRAOtdYWfd UuRUo8LhGs9icfL82azSUw6VYxBanUyws2TdCA+ezGU+VJH5Sct0qpAMaNSIr+T8bVLVZciA cyNNB2zGc+QVCoeMxQl0aFZ296c6YmxIUsegiCVYpQReUgT69hRmIUuU7VQiY4i6tGvexxQY XWxBOEpyVeX6djIGcOUg62M7XLbDa6fSQKJSuoTMdieOaquca8jbbeUA1aouUBQAg1B4Kah9 Bu8kT0hrE3ZkXXDI283fVdP09BVi9E7+frRA72oeP0aoM66ZcgxUcUVONNWgxUhCM7RXRu9d I7YvUA+iyLUmUPTu4K3FbddA6sYtXbRirgb02DaabVAxI7QQ9G1ZTLdwxVUKLgWnQYc0+ihn dheE0kM+ifOlOoNOAa1eVQRIP5SIvHO+IZNueWRnFKRsP+KcKgBQCYCCCECeSSBSPsBQSGce SMCkCSCKCmLoLsPfJyBASrI3J6/smc5zEusrKEAa63Ws1I8kqiU2O60STiS1GYj63GQUQakz a8I7bWyLgbW7bAUO2qndf9Y7Ihgs+7Vax8/vVhf2gw9ecmxAhaVQTWg091Igs2hMao7UUtgW j8aYvMYPghgYb0gOKqUs0LgCWxE2fXgBgOV0ZlhVgjhwrxWjhikzUEaxTEywTsjAV1S8zlOx HbhzidX/isRAwHh3izg4mXg9fxKBcXf5CgasahiVQHCKXOWnjTFvXS+vjdAOUyVZgWqu/4do NNgWg4d3F/dhIgREMqhCWpbWiEPRkGu6yUITRnkQzlUW/iPSdSrSyna1UqdUzlXTHvHcQa3G ymVfTlkkzaT8W9F/kmcGwhHxlCy6arkFBiWnh5F84g1nUco3jNSdlhHaevBOQKdjI/bKqjBY Qdl6Yi+Kko7czbmJQ9ReahI+V9RRmXbXW7X2hOcNb3hXSJBY5lkKk/Q8XBDPIgivWvl2d9nB Z27jnHl7MHiAi1NPWbnVQoadlfnfUrmFlWVONxAPnqzGeHBdHwY4d81w8OPSYjkmT80zBZdT n2KW0ybDdRoBoM5ncPjC8+3nP4i0uUsLM8drouWRozjtbVTGjdhsvgMWkBjiXckZZ+cGIdpH CO1fhhi3pA0EbiymdrZ/pe001KwXpXl6RhDKjS3LD9p8rdTdpFWkQVRRoxh2ZqdrTmP/h26g Vy2CjEfVWbqijCNq8CzJZLTcbND8UwxwfXqDlWUy28j0Ntio/abwQlnkrg9ZrYJnqjZ+j6gE yUKYXgxOUhIhLJqBE1m3LJZ+fhj1IUwXqyXRrssRqpq1rlDzEpVfcVhCm2ac4Rjcm3Nuwzjc nAY+cPmZUWmls0hzYpI+Nc4AemZZZMfwp/YoyUVg1ttXHPrMenteWJtdkgyIpS/UVPjriMp4 lFCzsympt9jalEjXs0XciNgXCnb5oXjQRBhYqwcnjQQmRxaep7uiJmZcX2hmwbl9BIXXoXkx top4uBb2ymf+qwQlmYT8kip7vSJmeGU6r+yK6m3JkWTwZzZzWlgCuunth3lop5snWbv+7ifv s5riWCg/wKwyywabM7KM7Uzbnns0bYmk3Jwah3BkyxUvwxlEejbssJwPj4qIO5wPk+uiWRTZ M9xM83jA5vjFhAyGwKnjhXhOMni3iThMnVG6n3tvhlNUvpspt5NUXcpJlxIu0pwXwGMm25iT yEMmUowNx7iWMmVVwriejWP0t0iDwiyXIbWGVXWbi9NVGtRhI+MpHbolxdoo51jIsulEiM2p AG2NNny4M2+Q2ESyzbyVXCuRv9gNIaRRUNh2mxAGtGUHndw8vR0Phtx8ItgWbbubhvi/sdcT orzaP0uQjHD9qu0+Uowbo/D8hmtjgXpJE08hpbDwzHHPpgdNV/GIaXtuwHc11fqsjkjy5J1h 0yIdl71W1JqQJmYNp7xQrcbUiLz12HpyfXD9qZl709031sKe2C0ccZprwT2m1nQOzkZyjJZC xxFJVT27rMV8QJrJ28g0tRq2zl3Pqh2g3sKGtRsRlfgrjbsJ2B1OLh3qzu1LjR3rWk0xjrum sR2vwPptsbPzg/sgyG4M7Vt30k33dRxnycUF4hmHtS4KvojhtHs/dcU5D9s8XRKbqNtZS/5C 8DIgYPrN5LsPI7Q2YtBJuSV9V2Qd0jhk8acH5N4k6H5FuJIa8uY1htuV580ltvueXWYz6Hrs qu8b6P4qTMNNRDux0TMMfDlefT6U6ss/xJM9vP6Mbnl7vXVqeHoee/6X69nsUE8ss+Jlv0tQ 58V9qFz/1vOFttyNwI7ITfxLpZ4eZBnSjNM658XXrTwu6QYtXrwZiB6mRjlXw38SrO1xzsjz Kb8VM9xEXWe3DDk9pZ8s+17zS5zTErfy/FEzazwF7i56tq057q+ai5uH0k9cXBsPyd8/sf0t sjCfXZ9LgC9HyRgLh69x950Y/f8L+Dcv+H3wdA9mhno8Wa5nTAPti6QJIaaonZtQV3+kRp8Q 1wW89d+Vh2//+SfD0H0SnAa3tF0I+R9n0rzZ9tC0KJ4Ac6m1Ce1ejhg1WjCgJp9b1LCKQlbB pR1SBwIAORcORwNBAMRmNxcMBsNoOORkLhoMBnB4SLhkNxrD4jE4rCIENhoOBAYwaMYhEopB xoMYXDYfLpbH5aLhqMI3KBgLhmM4cMZqNxsOZLJxwOIkMRlLIiMpaIDZRqQMBxS6BERmMZJW oUNRuN6ZEpyOK7X5YM5fG5NXJtZqBaBvW6PPKdLBpCxjB7mORreaBdxhebWOZ2MxzfhpgL9h JsMppaBjGofOxqNrBVxdVYNg4iMZyNIjmqhJ5TILOLhvh5jEqJQBrPBvHxxAhgN6sNNfCYra xwNptiNzsb1voplxpaNFWuJCbCOdxReVC+ZQJcMhhrbJGKHLJ3ENlSBrie4LhsModvIFhsRO 9BJKjOox5vHjsXO6r44ZP8Z95BYsE0j7KsGakBszy9IEvi/QGiQZOwgTIwUpDQKI3iFOEhEJ QavSuhjBSBPMgy2JywzUJWkw5gaKIGiEKgGheIwYhgg4QCoMwGoUHLDBBGUZQs2YQJ6zIZJI GjfQKkgqDaBsZLy7smhANcloWsAqJMFqdopJA7gaFApCKKYiiCKQhiQEAgicIgUioNQGiLFs mR2gcniXKSNjuEAti7GQyAaOM6p8g0eTiGrzIrQQxyUkSbNqEC5qqjdEyMHC80cGSNqihryU mECUoI0YbKQHIboNTr3RuncCodUoQBundWo2lKWpJVsS1g7rtpNWlX0agSyI3XUc14ulZu6p 9KrVG60MMsFjtG2KeVFYUYocqLbIGx1hSGitrO9YSG1miNusO+Ki25bEcowGCl2s590UIsAb pcrywXQw7/2s8t6Lu8yHWeGSUU416M3WtF/qIHLfPFXOC4BUSeMrViI1avIcoExK8qGzKhU5 iynpNRSb3pjq8qiNAG0zUGKLuoSiUjTWKIUGyqU/jt6Zjmdq1cGmD5vWeKN8uNWZ+jCtXLij XhjUFWPZAdOZW7eMyHWGnwoBsURVPM9z7P6RR3rzKULr6SyUHC0JupeKokp8lI08iIY5tWSR u16hqXZqo7K1Aaoru4G7yjSKsZVqK2qhTe1VVyV8KzKYXQ3HCb8tAYOPTi0ce0e88nwLcqzZ 3Dcbzm5K/xlVK6G3Ibzs9OdNyGrgbrIQT5PzKUBsWwdPsVEb83ye04iLrorsnecDVyzN6geE Ua8DxP3ePlJthQG3GHCVrm8NSNenFmKRR+AoWr3fLxqq+e/ei0IhVS4Pk5zf3opuN/YsilpM 2dNJJ8ib1N+qnew8ilPPMq5s1CP3rO4YQ/4sD9DwQGLKSR+plWeGZR+YwlraHDI/JMSkGasI LsHIioR+7QAbKwg+WRThvkGvzekysyMJyMNvKi+xVsFibLBXQVVg5AjbNoMoZJtMOyinZKVD k1AMm7MJhszE5jx2duBYSeGIMSHAl3Q7A4pBQGDlwBmQZ+pvVYLKg2UVcYMHJuVJeqY0qQ3w vUbQuEjL4QaqbU7G9cbgIxRuXoqhDUdY4qcMKWZwTMzGEJgS34pBX2KR/e2RKHy8jAvPSK+F 4BRXXOwdk1xQLXzGu4UOkpGJr35NwYuCBJRBCXtoZGaOUxDG7PcUsaNaYLilRclcpck5DJZF 1kC5BGJOzHR5RLLyMhGDmOOb3LAnBSVSOWmOe+ZJLX+k9blL2Yi9HQzIl9MV1kyJQG2dWTZ3 BUZKp6di1t2jXVBO3UM153SHTKNdjGQiUhJygESIKpwlxgZeGelk11vqHSykbn+QgzLvW0yj Peh0jCo5RFPmcQokci3uzOV6XVvrJkOwfaTN9yZDpPFKeg6UhckaEnIPLGsGhYKEkuM9CQzN KTRzja07MmztZ0ybnWjKdp1iJO9WbJ6Ix5FGT/qCzJ9xA1TSzIG+FTx7zzPQjbUgg9T4DEda KUpIzxCBq4JPVRvivTJVYNQwB+oM41ViN7RKV5a0Gl0b5LWWFbazVflkQyuL3GdrZbLVOvBR H6rfr5S9g51YVFKr7GY6xVkhmwfSY0y5GVFuBfOh06FiwazHfYvyqaD12sCm9EOWS7WEmbq7 ZyDjDyf2LXzQ0vyljMrqtZZVpjgZUslq6RGozTjUHbqBbhRjDmZVJtcbqb9wa4pGh8z2qZvn 0QuaDWK5sB1/kkrZcx9bSGlVidrDI7ZSmBMqt21WmU5aaN7nRJpQknJ2SeIm/5o9W6PEnvbE 2b7e0QokOsqqHURiLHEfXfuwqQUhxEiAQili7XDIawNaFqcsmilrKzgyPx/iLGQec9Y8RCDX sVIdhi0iGDyA1r88tEN7Wkv3J2Z4n97UCsUI7SfCBSDDOBxeUs96C6sT4n6gohR5sUESJgQg 4hT4KEwwhFSk+RSfpBIm/czqmyEOWkEYCDBJ8mSCIUdcixd1RUiK2T6kbMDMnQIur6b+XykL /Vgka2GIMZveYQedqyKXXzkkvOeTKPKcO5k8Tchd/F3G9nmZ5LF/J/qEIxLRIUtjPFNVJbUk +fl1SobjLDSWgDXktKIe83EEnvaalhp0o9sdOFoIaxTSBbzyIFefRO+UoIraL1DrCM0cVqZz axnac1Nbz56vTTlsedJLa7vNnlQbYZOknPLbtik+Z5SeZRHLZ0vDLE8pPP9jJX636yPepkld B6HbKcs87cE08RKaoFXDbrv9DbqAbRhRS8VSZZkjtBlblGHUdlht5VRoaYbdWVZjf1KtcZ1p nJh22e9kmRivIB35I9BlxtDUdydSVno50pQgk68Yaqw1TxzEW6ducb1NCPVsrz3rPIbmtaGj OVF8hcYblxU0NT/eponWOritS+4huWWHEjIsi0rOLYWury02vRsi9ZRjkIGp+VIpOHd3EoJc RBSlcCUGhl0Z1RnWUhKkLugPD5KTRQH5kRwhc9+fFaPBGXnxvOm8e6Hu8o2G4I3Gk8XN/9wG cFGNo425R8GIMOg2fqd9uojWFMZ4Mjpbn6l8VIqiPvbLQsH8ldTuryMJwjVM65FiLkYJwRqj cgaOlBI+KJFvP5DkFv8RokpLBzkaEmBQEMJ4TgphVTUmzKk6wqBEdeCgJgKVRgoCp8QGgKAg /I+MEn24KQuhUCUm1Fuw+j692PeqnTbGzKsV7Rv7hPD7qT/EQZax16BNmm8qBOX6S2wqUzwx Rv6ilqKIpFwlzSv7RbVYjhpRj4wD/hUYniR7fhiJaAgz9go5X4rD2RXJeTiBawwz8xyRiEAa Mhfr7ooQnh/8B4jBTcDYrLGxG7ZxX57KyhWgzxeDsKjb9hYMAYrLOTaonAvMGEFqFBaMDYih jEHBeBHBHRj8HpRpYoEDaqLxRr/IjcFxvkJJcpVyf0JrjhGKLg9hQhoUD8Gr77OS8bO7XjYy dTPhG43wz0GpHCvZtkMYvpVhbZXqvMCT2T8hSz80Bq0gqrEIokN6Lh3h8A4R46DcHypA3Z3Z h5ZhcImEOyEavz+kJAjCKB1KbxXMNsRT95VkNJSkQxfsSz/sQIopkziQ5h0Ygh4JG7GRZg7q y8IZ77Dr/MOA6sR0VkOojsKz8goaLiKhprm4vigUW5WcM0QQgqWRpptowMS4sRdZfab0OKKE AZgaIJLEC0ZBdcUpVkE8GsacUKvZE7org7PDhLX8MKA7RsagzJTyUsMZbBto2aNDqqoZgo1R vAgR8BvJBpuSB5eC3AySGL/Ip5fEfJ6UfZSjniWxcYy0VIp0gY4iMsfsgbNMdEfEhg+Jvkdx uUcMWciamMba8jhCm8b7hYwLRL8zDZyiT0j710Aa1ZGMdkPEOgg6ZIuMBkBA6CXBeJfslhGJ BB50hclsnEGqUCrkm4gcnJCxjZGJAhHUT8gpGIhRgDiSIAtZyaoULJh6pMqEFT7zIAqwiiRh eAkJHRGLccUzICQsr8rcRg9slou4kcJg1EryZKs0VcthqspQ7T/EuMlqiBYxVBA0uagTFI0E mUrsVIq6ZAkKjb8gxIj4qg1BykR8rLTKAkRcp7h5u0RclIlUuCiMlomSuzm4GaMsp8zZfr/w rcrQhhbYrqe8KY1A1MTYrRZCT5ORWa5hoqh6kZdZI0K0uYgsGphJzs3UfhuhEyW5w0fktM1i WIy0Y4+Iy6ZI8s5SI0scrRUD8xfaN8shAZWY3MNU66hhto50QULjYjpDXzpT7aromRTceY1S j5D5os9SaYlBok2SF7ghDs9s7IvAvwrSGsFahYqwyJKZbcaI6BpI6RWdAZDppFA5a8/9BUSo lQ/9BKWSB0i6hJcKFs96WCkAw5eCFCZqehcKSJtorQ1qgjE5VjsM3yghUZX7UzzBDou5usA5 08/UMcfkm1ACKsA8CdAiHTmEPKqc9EGpsxt4pVIVB5AcLcjMLrYsb08rYIpQhUET+aF4vKoB 7JYNDKp1LBbch6WCsyGtLo8kfwhCD8F4u7EU+qyFKcAdNMjDXMbkL1Jz7VKBBa5sw7Z6+Qzq MNPCXg0EYL90elL5yxaNLTK1QhZgmSeTG5oCodRSXjMBVse9MbRlOw+UnTolOEjUbsjlJ6dr Togk6hxkUaLAgYlcAY3qXjPyOMOdSjSxcNH9LzThD6Y9QwoBI0OFCtPVU1SYyzRjTsk1WTug oEH7Do+x5K9j/1Y0cjW9UpIc25t0+pIotpX9XDgk8L68L7hTpYzxiys0s1PJpK3Ev9Prfdcc ylKrSwwB6tXQz1dctYmbSzHqeVco94rxolMVXzS1bxddYVbEjbpNOidrarNVKlQTex5DDtdp RTDlGdMlghA1TDgr61gE8lgSTxWhBs08TljCX0F4j7i41VIAyI3J5NIAtcDZ6kGsmzm5ncPA 2Q9hisTcUQ6FltmUOzOIg9lKR8xtnVkthUSllB841VnoyNjxvkTFnVo9mcbNYZawvpdcXziK jRu0U4nMAYlCB0WFnxaEuEWo6EDbEUutr7hkD8VMXVnTNMXsTllFtUccYlnQ31sVFE/1rgwx ftAdlCKhT0Ziz9p5/8YaygyNqlpk8FJc8T7EMDhYxhBskMcgkiT1xjk0dKpoozIcSdQQ95v5 /9W1zdftV1zQ14uNfNMgHF0Svbm8g6WF0wzNzkgSWAxlW9hzRiDVydYTrwn1QMd5ACF6LlXT zxFpF4y5GhGxUIjZQQ8AEBf9LpGRJJJYEAM5KQnAgxKoBpK4ha2AKhLZLoEAKZMwEF8AJl74 IQEAJ4EAKV74Kl8t84EAJIEAIt7oEALiswGr3b0B/4vL0agjkxQSeQv8Iszz19596t68DBGh LYLb4wNAMoEAOgMoMYNANwNIMYMINgEANwMoO4OYNgMoOmBwOQEAN4M184KYIIEAJgMIMQN4 OQMIOmFYNIMoOYFgEAMJ2INIOwNIOYNIN4N2EOEYKWEoEAImFuGoKeB4OoOQNIOgPIFJAYFG GYJINwMYFz6D6T0F4d/V/om01JGQ44m2AF5r2BGZJxrxKL2uHmBwNwOgOd+xF4oBGb0YohQQ oh0+L5mQit5wFAGONpGAq14l6xyw8QFpeRGj4BLCR97RLgKmBd7oOmFoOoOeHwEAJoIl+pNd 6w9mQWQj3+TF7F/N7YIIM2D+Gl8+B4MuNRM2DwMIMYNePmN9/JGw5BH4FuPD4AFAGWV2Pz0Y Fopq/mQeL+TmQ+T74IIoMmJWFd+ZSwFJDoGIFGNgGAFAEAJwN+B2Kr6eNxEOP+XopeWmQpLg G+XOOBG2WihYkmX4jeYOA5LgIINgM+F4OgNANuSIKoOAMmFoMuV2bL0ZgpoObuTgFAHGcOWF 6wg2c+b2YWdWBWBmIwMeJGJQPOSQIhL4LGfOcQBp9WbmWuTqMl/L2hDugWP+Xigoiug2dN6t 5t7YKeRwN2ewOQMmeeeue+iugY0J3ufz4GAuRGjwGekGXZZWWeTeQz2ejeRGUAOmBuRgJIOY MOVeaWDOFwN1+wrGoGYGW2KIOYOmJQOuauS+bGiwvOm+omjpLgz2nuceQOguoOAb2gJ2DOSI E19oNwM2FYNuFuHeqOrpGGfWWJtWgujWnOsePQG2s16yD4EGkuoV6r5QNwNwN4OuKQMoNuU+ Nd+xN155JpORrxOgpZO5GOSYEC+QgxQgyieYrwh20eL4qIKZFd4II2LBG1Aoh1/orouwEBd+ YGMV6OlGRWRmlWR+SOEWSeSpM2UQMuEGGoKWU2VAIOVWVmwl5N5GL4m414jaDe3GsWhILgFA MeNANINwOoMoMmEOHoOAMIM+BgGYLgFOypFt/5TZJSLdrQ0e1bz5F4nOP+z1/pGRf4pZne0m PIJAMIN2SIIgN4MQMW42rOvBNmNwn+P+6Br15LneL6lO2l52hGRIFAI+42uuHuKOuYOWuurO Hl7uI+JOJZM28+KWJmS4wDEWw5eRDWk2BAFAKGZYxIFAFwJ4FwEAIQN4PF5RHgip0+a163GI omc/GWQ2T2hIIgFpvbKPHuHgN2GfDfEPAXFhNm/Jr2z1/40G6mATFJf+hPAIOYNAEAM2x4Mf EfAeGgOWBgM3N4OO8GNQNmiGSG8IkoOQPIOGFwM+FgOANGCd+xGWX+jRLCvfDIOGJINuJWG+ GPHmKOGwM+JWCoEGHQM4N2R/N/S+CGyOGOUmyQOepe89+wKgFRKTA2dWBOHIEANAMPM3PPBH EGZeZuBnTGCQNwM/Hj46jIFAN4FOaAEHRYFOWgGwFAMoO2yepGFoEAMWiGeGHPIvU96Q4XDO 72D4OAN+HXNmUgO4MoMINeDHUYEHVvFW42e4MmGeeGBgMIOAOANmGAMnU3VDFJiHDPV/M3NH NXbvfOBoN/Z2Bm7gNneOHWHgFvN+HWrHAQOnHnMoNHemogh2AhLFb/DPNOKXNmSOCoOfgAN4 Mehu4+SO7gNvbWDGNWSO7wEAOwMOJOx24HdgOXiPiopek6WQyXDIMfPfPoN/P/d3QQMeGnd/ eOCnjQEAO+JXM+SAOuCvOyUgOuCHmeoe3YFHb/cO4wEHOQOoNPN+yXlGKmS5BBsXLo8Uz15P C/m+dF7eReBnfPM/jHNeu+4QgwO/WHcuNQOQN4MnqHWWiAKWHnmbP/tRLgKXR+rBPAzwLvu4 h4xhGnQWSPuuSPdnS+RwOXBQM/YYN/bHNGFfwI03DPyYMnZIMoNgN4OHr2o+4OGoOe42GG4G EeHXRoNnlvV3WHt/NQFviOnOPBK3iuPF7fo3AW8XEHu+NOHXZQEAMoM3EGo/lXnXPmleCoPI PW73zHdn1nqXmxaehOSgGgFveINftv23ffjOu4OfHmSgGvdeRmrHN/XXdmDHeeS/amnN6n3o 6X374IOfqAMeGPjoOQgAgN5mEBNIg0EBpNx0OQpFoyGYoN8OHIoMh1MZlMggMR5EBSNJ2Mpz OggLYxGxdhJuEAxHI5GIsFJdKhKBpUFQNGAuGAxhBUMc6FwxG41EBUO4NLYoNJzEB0iYtGYx ixhjx0NBlEBtN8kEBmho0GQoMpxOplhZsjxpNpwNhlNtoOkaEBoMJzNEzms3nIwo9Bv1IBoo Mx1NxjOhpN5uFwgJ9YMpygsHFpkyMhul2vFfw2IxRupxhORlFJUNQNGN+1Utv0+hEuGIuoxU NtKFBcGQ0GsOGo5GgoyAgGQ1GwtMRpkplPFz0GfgUEg0ILgokEir0nGhdLgpmU0m04Botnc9 GVHpNL3G63m+4FZEBTMpjOujEBIu5oEBBNhnN5y5A0DaEDpimJAgu2EDLDmNIzjcuiOr0mzY vKFrYhmo4iKEGELMEFAnCSKYqBeJwpiCFgQDYMK5skOY6jEkjkDquaNo6p73DmNkFjQOi1BA 0YWtK07wMCpIUDspq6QIIMKJMGIupk0zwwkEEKBdDcMPGGIcL+oSiNm87bty3YWhqG4bBQJA UhgFAghSnyxisFIczUIImQQMqRDYN44QcjwtKyNwzxMKA0jKOCGhaGgcBQPQ8jXEwwjcMkIN QF0JwrC6dS28aevMwb4DEyI5I8k4cSdIEo0rKdLipK6eBoGNOvRML1t+KQkigIqDTtBUGLoh Uaq0sAwriO7+jW59gBAIo6x+71KUtKtMSGwY5T0MtIBBQw3jU+KS1tXCTBlU0oBk2IbBAGYc 2kngbXOoEuKLWMwPVMYZUUkjR0AyEGo2kQ5QUxanW/XIiQoGy/UhSVnSlKkrPDTYby28SeBn DciYGg0KXtZGMCJEzRoytKPDhFscLxPlTyFTVOhQISujmMsUMiOdBXyMuY0fSNkjDGI0P7Jl xBdU8qQmGQXXdVsNZYIQyjM/qtJcHKjDGN42ZMz6nacyQ6WLASJIIrDRjLA9qsMMinIHU6/Y bdYY1hDjo68yyWZcyIQYSEGXDnmGZX+kwau07m7jYriSBbqmrDTH8oSEoYZPKwSl4A0Fkbi6 c4BsGoUZ5uarSYG/A5yjY4ZgOoyDfw+qxxZq98an23yJyes5+4OqLa0e9ucwrDsSxfKiIozp 7nlK+p5eMObqyW8b1vgw5mkyUwOu0Z5ulmnbMxokpZqLd8YnOJhgGV3S+4OeKxn7LTxayNwa O6tjL86HJQiynKgEAx0Oio8jgOlIDCWoPRpFnONU4u8naXWWHRBajgNZWjNH4d2Z5gL2SWBh BAzA/xI1kIpf6GMNYc3iKZgMTwlDLDIMwKefENAbg0lmg0HcyJWgwhwLcoQjbvjghmDSv8kr XA3t3UjCF8D4WJHjBm5BIhwUUFeh814gaNWxNkDe2ZtBBGOomd8dGEJgTAE8BgupDivzkFOL lDt+BHm8O1De7ckbkzOO8OdE8yEW2WHDOKcc5Jyy0Ruie5YFDMCtBbBwhQGDgWhJQbW0ZpCG QbxINsnCRpZE0goUORAFAeZJo9PiXJHjiGrsBK+7Q9ztlDApTNG13RnXWE2bWqtDEQ3YGDd6 SyPrwC6hhJERx6soWzN3NCG4N0UzDl0RSsCLZPIwJEWWtV/D+yShciOb1c4cg6ltgvKgxZjQ qHue43dGM1SWFNcWkF76mzZlBfAxVliLCtRPVOC8IwMTytvDMA1oxugQGBQwCgIaon+BvCEH kuZTp3zxXPPQBoNAXLqn0YMk6TXBmjDCGQjxow4H9Do2glhwQxUSDXOM8IN0qlGbYqyEUXQY A2J+kQhQZ3f0KBA9pZKhiRlybuHIxIYy3gghhBcuzVpNUXpxEJiDLIcHuZBTaDgYYPECJYQY ozeAyFNPk3shNGSEltdXCEFAY0UtYkOaeeDEaEA5NlPmtBqV0SNJaDcHFZzaIZgKkQIhI0Fw sUAfU+4IAjGdlnCBKE8IS1loXWg1pfgZ1sJQDWuBtYhzJMHNsrSCa7rIgfG+CTlCmv3Mi/0h SPDFztbAVmY8X0tORBQ4UktUwzJtc1Do+QbCSn8f+U5X8zZ/hnDlDMNEmAam/MaEGW5m4Iyr L4w+EiXpZHODbDM0Ico8W7VFAstAZysPvb2GEM8Gn7Q6DwRq6i+i8veMHZcOz/yzs0p4GgNI Yz8BtDqV5UBXy7w9h/KRGIZTGhCRjU60oN2IocOCG8yBki7M6gtZeCMsyt3xJLfOTxTTP0gg IDWR0lK7EkUgHREwaQXX6qvg2+RWr8P9lm/9HhCgzLXQUGIt8x5YnAh/DrBD93VYSd8dMrEx bNwWDgGGHayLWYrXySUuIc8KTlhJgF2N2oXn/WSHNYcDq93nDYWc7aJg73sp2cGgs8iWlHnq URSoN0LUNLIHgppzCM5foPmJKNIgZZmVUtGk05lNFDeOkSJ+EXZEJirjY+cKDDS4DeGkMgYc XYgCdgQrWOw6R0hGDA4kJisn0NFo9rphacaXp4zENgLQ1zBDuSw0ZZozFxIW7MhtgZ4zzzhW 8oxq9ZEtBoQgG1IjZm1PGDKMEXYEIcCgtXFbe2fn2coEQN4YlQU4V++lmKepfkbTvehFMGrc FQpBK1SoMzZpXzyDCtzLLdW8va4M/h/isBtDmY0JFm7mq/dwtcOV7iVoqJHVjTLd4aI4q9X+ 0rb9gZ7NtE+qYc38PwhkfsMtHYLW3Ia/OZwb9yhwt6ClewKN3YkWxhAxcHUZN30jAMvqWyLb L2aYkNwQA5hrjWC4ORWSFAuMtWEBoRQqANICDWVuZHN0cmVhbQ1lbmRvYmoNNSAwIG9iag08 PA0vUHJvY1NldCBbL1BERiAvVGV4dF0NL0NvbG9yU3BhY2UgPDwvRGVmYXVsdFJHQiAxIDAg Uj4+DS9Gb250IDw8DS9GNSA2IDAgUg0vRjcgNyAwIFINL0YxMCA4IDAgUg0vRjEyIDkgMCBS DS9GMTQgMTAgMCBSDS9GMTYgMTEgMCBSDT4+DT4+DWVuZG9iag0xNCAwIG9iag08PA0vTGVu Z3RoIDQ5NjQNL0ZpbHRlciAvTFpXRGVjb2RlDT4+DXN0cmVhbQ0KgAwEBnBsCI4NGIgNIggR KhggNUMFw1EB3EAzFw4Gw0EBNEBbLsCMgNOMFFwyGI1GcPgQwk4xHIylggMZtBo0Gw1FwwGI 2EAxGQ2F09HIgm04nU8n0wG9DG1FNgNlVCGM9n45ptEEFRqdDq1AqlPrc3nM7r9Bp1QBpiBp RhEDhAwHMZGY4i9zGgylc2qsuG8oEA0lw0lVjvs7GcyGgxoY1ilRGIwGguGwyu2LxuPuOTyu Xxg3GEryGSoY3n2Y0Gizel04yr1qyOTGOmwOuGQ1hORjA5jl5F15pehjMJ33AmlxxgzGut39 Bw08oY43uu42Rl28G+118/GHXGnZ3084/WF3Yi44F2J7Oj73ZutDHPBxgx6UXpo5qvc5PL+3 l/IxrijAcISGb7vy0bdo5Ar/Ny0jZp894YI07jZNo96YJ9ADYtY87KBmjjRs4y0OhtD7nxEu wZrmGTJROjIcPdFcWtGnQbJgu8XxAuKhO7CC8Bw2AYKEHAZQVH8gqEHLCxUyi8uepq/xSuaN pk0b7hkmUmQGuzRvQnMjOHLi4rmyMfOa1TIrmHC6xwvLVDMhDIoyHKVhnIYaqKviqvSwiLzu 2E9w+ik7N/JzIUDPtCBnRafz2GsiT8oc7UaxixUIGNJw0GLZJzSNMJ9Q7J0XFKqUmqrJhqG8 FKEGknVOidVUixyZU1VFYsEk8TVDWDepdOyl029M2VwnLc2CnqKWI3Dxz2sVlITQ7GUexSXW LSk+WSwYbooqrkz7XFf2Zb1Brm3lAJdIE63KGlzzndT00ew05RVKV4TFNKMwhLz+NHMkRven NQLjL0LLmGFlys8tWxxg9oLjKFBvQHDCtHJKsQ7ic0SEjKcQ69cdp3dmPOfGswLlHUNqfOr0 Uxkj00hBa83bdL+5leV0TpSOJrUMwVAaIQqAaF4jOyhIqTgoSKJaEGku4nwZLmigqJsgQqDk t6CBQGQUioNQGiLoKBIS6+xhAJa4o6EGBhdbYQNAji+QltiKXiqIp5/oOh6KEGjgbpul6bIo Qagie+aon6JPwh41pNqDsipAAWpdTGpDuBothQIYpBSqoUCyKAqCeIQsioIophSFoapQGIUd OoIZhQEAqhT1/Yib2kS9t3HYBAIvd9jzfahB4YY9+EAc+N5HhBt4wQBSLoqCUgq4cImKV6qI iTNCjnIJMoC7Cpy3MBALjEoT4YqBAJHe+Hvn2CH9QQCcEAkhB+AghAJn2/mIoQCuCAKb+X2P pfS/0KT7QnggCM+2A8AX8PDf0/gIQIIEwHfw+mCr9H2Oneg9I+hM4Plgbcq1wrU3pvdaq+IF ARQyBpDoG8OTqDvgofKbdzgNwcAoDmCkGDsQnBvDoGV570WvtBJkRYhBzgbnKKMVI0DbomN2 AanZsShCKE2VTFVpsUmgNCaI4hvrUYQECioT8GhK4TOSJ2eJ8IDQUBBDEG8OodAQBSCm/gJg YY4hyDDC8OQaQyw7a7F4oEYE4HoaUQ+RCfmxJFhKTaNRoY0OWjeG4EAYQxhhDIGUNoaQxggD KG4OwaQ5BvDcG2UMdA7wuDQGmSwYSaBvDbKgOQYw0hhDYCCGAZwwhuDSHqPoaZTAsjrHdrjX iBAtMY1B7j2SXAwBu0aSkeY9x9hhIAOZCpsh0DQGUEAcpAhlDDLUNElw3BkliG4OYdQ2B0lc GcEELZRhzmFJYN4Zpiv4CJH0MMxwGhUZ9M9ArfIVBTDKGMOsfw6B5BSY4FExAkhuDGC6Yk3J vBjlkHCXoeQQBmjlOcMs6AxUcosQqUUqYYTZnuCCksdggxDelMmZcTAqTOK8TKNoKA4B1DEG yTwLQ1hlo4GMOQeQ4QvDmHkOcQQ2gub4GiUodQzzlhdNmcAc5xTkBAHCUoZ4+BtmJTunsngw gtn9TIk5vG+U2NnNKN07pTBzmJViTobpxzZl7OijE6p2TuDdPCrAcpRhjkDMSlz+Y9QwmtH+ QNW5S1mkHWgvTUnsyRMBTmUcm5s1Lj6GUFs9wW0WBbOOOlRKjQvq8GEOErZPhlDwHAMocp3V Yo7DClk3QQBilCGUM0LpdT4pdWcEEyq0zNAbJGNklJ9h0lhQahFCqOV5IUHSbNCKlyytiHMF 0/mwEmIoRY6xAiPRTBsS424IDcMQcGXJwoLUPnZnAA1u8XW9SGAbGJpZkS7ngPjI+E8KgnBl DuHMNgZQ6RBDkCCl6RAUB2DCGkNkesIQuujOemADSZXEjQ9lzMprmBjjpRGjwcg2zBlNP5oc hWjJwv1fmMkODAqpv9M+Qr3XM1FqOG8IQeYgyCa9ikpbfE4GTYmQ+mr3m2xtfGGmvFHZwTer FT6TNcJXznkuGwNmFwW5EIphqtcJ0ATPLFTnJk67C25iBOW584A3R0ulRqpcxJxzeDDg7CEe sCz+oA9po2YTSuVcvg2W9t5vBXBSq0FEMA2BkBboYlQKA0ybf9ocGwKAyhikvHTC+KSZYriS ZSROR3MBowOHAHQLwXh31UCkxIKLtwduOUDUFwzk5faqgAFAcg5hhBdRgNoL9dS4j0HMF9ps c0jx6C+7cg8gX2mSa4n2R3JwfpyEa204gx1UDnmaS5Ww0ydiDOgNwdQ226wTSujAcJsXCy9t I7eSgUZzsdK7cNTgqTdujOB5yRQUQtqXH8MUc6Q6ZKMGENUMML57xo1LPxs9AAor2Ga2MobC V4ytNyqNU54ykoPHTEuE6/7La9wqNb3OGqxpyFeVuBZL52wjT0MucgyQtypLiWO6rG0rotnq gLfM/FyKLvAN2AsCYGwQTSXtuZvTgDiHWQO4bc0cdo7CveH6/Bn4TQExFbgUWHmpYqP02Lbx y41LAN0spXc24lN6F/PHtIwoJoGjAdrYggDRXmn1f3nA34gG+pc2ZO1Tjpbomndw5Bn4HiPr N/43SunlpEOvNumdO7/yJ6YLdoZf67HexE1ew2NkzJbwnVZMdQj6DqfxriE+YMpl+5FOJKde sTHzz+PvL612l3FzB1iOzjldN4KE4w1h3DDQxAdD4AB1hdN4Gp3fFuYClSEO4bw3uoSxv1+2 FAUg375MQIb+DeJCBr4sFBiwagvTwDUFv3DQ9u/KSn9CSstwiC4CgMwYQ8BcBTigI2KshJ/m fNctdgWuXg5ggNgtepZP+G9m+j0GDiHplm2pFnCCKLympHDmxj/HFrjpnrktAtDEbNLIeHYu KI5I+PEMtJlgaC7LiHVOgpnO4t4g3KOJwJNLsiKpWJ/CME8CfQWmoPNNfJUM2q5J/L3G2FGQ fQXntAYPYI3A3g4A4O/PlpdN1JfK4gWPUlctaCJwft3DuuuJ1gzvEKlp6qVIYrIl8iVwksvn MKuIbtEwotdg2JsvFNYI1AbEgQtwXNbQYgzI5qEpvMyvKKWPqpBjqMYQ1wvQmQYvSMQNCJ/Q HJEiBJFkVL0I2CbMbrTsdMeJAxICdpEwIiKJFkSjAgcHwCbHMKQoXOEEYNXNNv+sgm+sWwIJ GifCnmmoTCBCCLLJJo3KIpvqDpUijMPA0K5NCAQLOIgrfu7Awg5pyw/KJMqJzJcKlMmN2PcK 2Q8PdAUO7psrdJQnnFMNcgyg7A3g2I5p6pfqQqnRfpYKsOmuKJvKVpNLVLmKzNYOSCUxtsqO LJ0JQu7qJJOJUptg3tunOAaxxsSg5A1s8KOLeOJMQA0u6PFsaRtqlg8uWN0McLmK7A2RqxjA kJepsgiA3gxNzK/RmJsnUO+MStJJ6Azx7oiM9vXwYpfLevQs3AyMHSApspXRjpexqJ6KVJ8J YMHLGKFxlxug0O3QOuuRoSIwrqTAxxzoWu9KSwoqdsIsEgmgiCdJ/E5GymxRammGDsZjGugp KN7pvPpyFxlySSTLYyURuxmJ0A6PppQAzSILqKnAjJSKlymChwPAUKLN9MmRjoWpwRHSHuOx lqStjSORqJ3JPy2A1zAGDnwJKA7rWJygzyJLGg6smg2g6tsiFA2quA3u6J0RmqsNtwhI6OdJ uzLMapKKsLnsKLfuJJwKRKOIWy8uJs2yUxng6xowyqnAhI5xHpBuSDunwOTuHzapTR/TfRHS 5xvpLIXrapapvTQRCCtvqA1xhpwSmOfQOCzOHypu/AyyPOCLXPSz1zNI+rpptCKpvPAtSCKp ezXyiTgu3JImWqcynxpSfJYKNLZJPJ2JxpLwoMpMTA3N7Jut9TqgypQzLMxzaLsJ0w/J6JTJ zJ0LYA5O7g4MmqfMDuWJOg5pwKuJws2qy0KxezBp6pLo4zkT2sQT30IO2JWq/rNyOJ0JVpuR gJeA5AyPbTlpoR9yCy3tzPrIeq/IavxjIgZIdCtrOqliKoYTwLpKqzSg4UGR+M0JuSKCdgby 0I3MRzgqOzhyoJ1KTCBrdo+JcrpSuCKSfUCzJA6rIORutGDwmnMStAUictXMFMmq9x3unSAz 6JLoYvMO+JvJNqfPBOBzsMCpNLbxrR8U9nHpKRBR5J8P+P/G+iMAZjZsjHsnMAhoYiUgURNM dsennNYNmtPCktQ1TAUUfpyukzVpAg5zXTGrcLnvttKyYnpAWj0Fwt2qbDQwYs2I6Rk1OiOy uuon1SRAQUlS4yfTNSC0BuZg008wAHvUjqcsqJiTOu6JszuA50MUPg5rYSI1zJdJLQ4p6OYU 0g6RAP3JNu6A2QnzXLtSvmlyxCfjnC6lUHDTyju0Xxfuqo+UrTsV8z1V+SB02ylU0ziUOSgS PVvTlkJt4ShKK0cRmO6OlRwOJA7vtocpiA0yiQZvtnWJiVUgctLLCTgJNSduKqTUxE0x9rcW MSPy3HTKnAiJAt1RlJuMmWUnUHOg6QRz5g7z1Jcg1uzg7g3UxC5Wdz41AIaDEgZAiHTT5uhv fSrLcJQp0KV0tzQLeJ2NvOJJ3JUIagZ2cganuIVLpJYNfKdrmOassOpVVNspxA4T8KSSCuAs IWyzrzY1MHvRenMN/pQgzpuSh1q2vJVssMrviKlOlNMg6I+V3AyqnHcHWzR1cWqgbNopKJUN spesmKwJdI/zOyOz1zTw4uBqRo60OApTPM4yUz+wOzMI3PSvI292RpXuXM8JvUz10pUKWNvs 6MrLfTDJMssKQ1PtOv/zlkbsbWugpgsVPxYk4DXDHVSskOHx2XDzDVOJiAoOV3bJeXLp4pAq iA0rdOLQi3wMuxsWD1wnIqBXFwZSgzDKV3tAsUOrpyVJlNKqrsmSOLCTurXO7zQJ3WRKgg81 h1vtbwl25tAqsJxzSLpRnA3sBrbz4yfXkpvKsJ1JvWk0pIa2uHTYBzKLtW3vFrkNo39jEUXt 74RxjRyRwJuOyJy4BT527KMo50GpcT1p6A22NOeoUTA4Mw2uWXQUtOhrXpQp6WRVC3NzR1xz 5PQ3M4P2pvnzByCp7zctup1gxLOM2pbpcgU2YzHg3rUrVpPJLydT8gwvEJdO6IY3EoUq31fg 0rVu63tVFKP0fTNz5TDXCJ2vLNnvWwvXTI3AnqEqOu0040DSpxA3zSettunT50P0QsmpN07V 7rIwtsNntE2N4AzJSg2pdZKA2oYYU1igUTQXg1FTJMCxjOAo6LfYywbqSwapN4+SZU9lGN4J YAzqfTTLaT4pTVnqS5Yt9Y0Y1J3ObUtTTOECNgUYK0jYa3xwYyOLSyN44o+Y5rWu6QhxliYL +qnpvPo4NpyTx4mi5UXgoKuqvuCKSsAg7oXpLKIwyV7RlT4qSgqpfY9p6KFzLEJTyHJskpKK VghgwtytIvEJiAqgXAlqnZfzdRgZ42/NdMnJZUwSlzlYmYbEextpMQbJOpYYpgyYIKi43AaK H2mJXSpg6yqp4PZPPJrpA0n2q3sTnQYghpWreIAJbJU4FAQTjrZGzJcMmA1g02Px5QoIYV7J fSkO26TMwHtFUwY12WyAQA63ATsJ6A8Rhs2xi02pYKrqstsgWq96YJbWRI+4l380ynMZY12W QJuYRqJSqOB3QYYA0QnxjOIzf2bq8sLi9DfmmCMHHrKwO3+yrogalO1LbNxpaI5JsuhiLKrq +yVWYrpWH19g4YKq0ZUJnwuoVV+t7Y3Ie6RghLsphiK7Cz8Jsw3CYNLYTo6UzqPZKTYIhXEz /Tng060ZY61RjaOVzpspW7crs124Ix5XDsoVKJ1qr556IWVpQA8IgqQJ0a3YOJy3N5Azu6JN yo/gyPEZGrhvMwvDCqcy1V6xARkTRuK3I3qL7GJVaI3VUVWROPbVYv/jJm2nsNA33rYJzqVJ LJXW8QUiMQe38LkM+2D5joVZWY3NE5XYjxkOOqU1fKL1FlN1Vsc45LWJYpZzhvtFVPkbF4+6 GizU+t47m5b2nUrp2J0Y92+WYzRTSKfKgzu6/A3TwKSg7qFZu09irN4Qb1s2QqLsPOAOBS6y C2jLNqDzot9nYVOcQ4ZwOuTcLX+zoMrRyxzpUKnNDIzwRIepQKJQTY8XmwaHOIepxZhps1b8 U8k6u6HYngUV+piHOIcwnw4wpwnpXQyq5qpQx0vrbXZO/JcId4+idi9Rt7fw/zC5OrGzsHUN KxGo6KSxX1QMWX7XxRMsc1WrG3ur7b+tLOaLbI+wijZiJ37j0vXSmwY6eOwafQzVpAigWuPp c9NtmP+3qxZbIdWNkJAgWqQwDtdwEg29VNPEh9SvLLuiAg1lbmRzdHJlYW0NZW5kb2JqDTE1 IDAgb2JqDTw8DS9Qcm9jU2V0IFsvUERGIC9UZXh0XQ0vQ29sb3JTcGFjZSA8PC9EZWZhdWx0 UkdCIDEgMCBSPj4NL0ZvbnQgPDwNL0Y3IDcgMCBSDS9GMTIgOSAwIFINL0YxNiAxMSAwIFIN Pj4NPj4NZW5kb2JqDTE3IDAgb2JqDTw8DS9MZW5ndGggNjQ4MQ0vRmlsdGVyIC9MWldEZWNv ZGUNPj4Nc3RyZWFtDQqADAQDEQDAXDmCQIlg2CGmCiAlQ81QUXDUQHeBwImiAtl2BGQGjUYD QXDKLDeRiA2yGRyWLDUciA2A0pg2BGebCAjg0Zi4cDYaCCNx2Pg04zaSjKlQ+BQYZDEcjKmC AxyulDMZRUYVIYjIbC4YjaY1YZVitVwcjewWKZA2yjCeja4QO02uYzO33G512v2G726y1mRV yvXa2mIGlGGCCcSK+jUbCAZjkXDSyyqWWoYDYbiAaQYaDUZ23HC4Z5DPDGwDWLTORQYbjcca nV62WbDZbSUaPXDCDDMYwQaard6Tfabg56s8G/6/kcKsyaCc7N53LZWvZ4c5QcjPR9fLZExg 0aXWg+DszPy2qlVL0ZHy1+07Pr8ztfLc9cYQTx/GDtyGYcNMGTOvUHL8NnAKwQO7T2KWGa1I Q4TzMlCLkv67aDu9CqDuS3qDOrDkJBA5zgIJBQYJ/EjjxMyUBKg8TbufFwXBsGagw+FzYwTA UbRxGUdskygZJS3rVJGoLJpLIqWNVBLKBwHEfsGkshMqHDmrgF0kSsGksOMnoYwAyigKk3qe vnK0yuMkkxSenwYtm3qSO60clBxOLjBqysusu3rHsjJTLN4BozMykoaSSr4cJgzCRLUG7khn RdGt7SFJK/RMzUPSMTq+7zR0eg7UUmsFJxXAUQ1KGNTvGGoYoMG0Hr7U7XVgnzJVoyNXyPRN csqy0SODLdfVK1ipVdYcuM+ksbtJZVfWZSdd1u+lY1fYVYqXZgbWxV0Uy2zjPWuglLVG+FyR XS7hNAG6XhhddxtMG0Y1FTsrBy8rjPZYruX1cwZX60wazklivhvDclNPgrSzdGlusi3s9ssq UFYhNlzysGFsTnKslY3cqWSTAVGUIkSevbGmSzBcLOwVAqWOjYsBZgkUnQeygYXy4yDSlkdT OM1TWUCtTLSzfkk6KGWj0RRSfUrQoVAaIQqAaF4jM6ggqUMr6LKaEGuxIpeloqEAqJWgQqDk nKEw6h41qRpbOio8YthQIYpBS4IUCyKAqCeIQsioIophSLoqCUnKcBbhCfBoyO0iIpC4KDui kK62YqDuBu7CoEAkBAIoQdHz3RCHz4QCcEAkhB04ghAJnR9T0IQCuEAp9h2nPdKEApdkJ4QC N2Xfdx1/R9j14hBB4Hfdfz3mdX2ncdGLisIJw3EbYiiEbekKSXgzvI84FHR9wKqhfR0XfdGg iYpiG3scSgicLDGqooeKnJBQGYUioNQDTKNeIerA5QIGEJ7Is2dxROXLNpc2CgKgaAyu3DoG EOgdQ5ggDeGYoQRCLBBDMHQMocgQBhd6GUMYZQ3B0BAEEOkFQxhrf6/9q5XSBtmUNARr8BFg g3MvApu4b4VhpDcHUMoZAQBmDkG8NoIA4BhDPBMGMM2rBGLDDdrcACDlTh4VIsTYYFIgVY2a B4aAwhzDREkOobgxh0DTEIOYLAQB0gkCCIgZgyxnDSGINIbA0h0DzBqDgZoiBkiIGeJwcgyh pDbFAMoc4qECBaao0b+QGgtRAVtsx45MJbQ25oBoKAuAoDFIsN0iIhBlBaHcMIeQuAphKG6J EdIJx3jyHOPcfY/yBg3EmQsh4SggDnCgFsVAqNSbSeMgyrCYygBREKJAcJFSMkdHMN8wQzhp DtCqDQboJyjDvHkNZVA3hsj9LiIQLZFS4DnMV/wDZjyhgrGwMsrwXRUh1AMgSwUbNCbM2iTz lYHwRhHLWDMJgzhvDfEgMcZp6RzjNCwMIbYhSIloCCM0aAQB2DCGyI0kJ3zxRAvSMkoZegyi pDUrkOAGtha+2FgjYGAtliAG6lMVjItaUMQY0Rs5OgzRS2Z/QL5IrNIJT+oMlgUUonfPkgUB F6NlBsnGmhK27AgkMGYFJSgUR4kVCslUjw5yOoPOScwaZ0Bug0GMMYdQ5BzBc2YFINwbTPBS DB8k0pVPxkuVk0IIJJmmqE5dL1JQUTbrAGGtUFoYBrhHEmJcTZCSymAGOcs543hugzLgNocA 2SBDEHmY0yJPTNgfZazodY3SnohBYlVipA0ZjTRyj0jwQSjj4HKOgZJWwlheGGGMr6bw2p1P BqQKKbTvhrTmllPH8OSk6fugT45hBoDeHUNkSJSkyDCHKKIIIVXXDOGiuIVw0R9gnXylUWIc lZNm+K5Fw7mRZuc+Kq4PSBgyNnWiYUbpzTkDdMVw7iZJk9p9JSwcmXMzKLAu6krdpcBkhGCk FrAQURHmsCC7Ycw61aS9V0NIYw0wqhYHQN+FDWAot5aI4IMQURym8Ridd2A6QZl7Rym2A7jQ MwYSNubm27BPDfW+hob6JSydrVsGQKMRzehIFtVgXZhB1DPFEOeJaIkXgnZa7F2gy18pElsH BUpnBmyHCmWc16KTbwzRcNsRJGB1ibcOlcWVWI1gFUq5MNKcXsKRnlyV9yBlyjlRebweA6V8 kmm0i1gZKuSgc+MNuNA02egnL0rEcg50Kyda2tQZQ8BwhRCKaIcm9V1DKHaN8GLP1zBuCie+ OkoRcn2VJm1VZLyZzJJxEBWLDBJhZfyxUGtRVqmkG8MQbAyxNDvBKWkJLLVnrTOqR9aJ5wst laPHjkzN2GDNGuNtmY4x2sXWoNOEqOhpD1hjK4csQwsmHZoMscgx7D1Bta30JZzT3pDaQzZk ZnUEkVHaDIbsjEqDrQ2jAb9RWtyxfwM4YQ4bkg1W4EAa+DB3DZO5/+YTfZkgfEe74d4+hsw1 BOQk5sMREohBOb13Y1QXkVpqIkKaIX8Dvde7O2teybcvg6Z0ig4h1DTwOEwZA5UTgtiHDUig whrBbHSJeVI08stRpYPEu+ec+uiDG6bdpaZDq2DMFFolJ6wru+SgmAN24UVgCjhMbohSCoxG eNO342dys1EnIcibgRuwE9nj2Y7Db15NxKz2Ielxw7rBnE3J4Shw2PcCCV2pA2oj4G6Q/W5Q dggl2IsuF43eG3JNvK4aeI96gzySOnfgzyN9HWGOmJ8K5LDJXC9TWM/QB1pAVAJJIEkrBQEj u0wLQurhF0nUjrYmV6DnWm+WfqnEZ98pHXCIF9cBjrbKNXedxd0ouE0IgNAWhmonH2QOZpzB vIx0eve/XJ8AgfLgM+xt3Rs0rsqrERsMhNhGDW/0sUiQCIomDOC4KeBoDkiQC2BuC6rioI20 66kqgeDEj0DGjs3Q4I4c8avOlOjkj8scvAjYDkDyDg7000usy65O54S2YCsMDIlSw0DYDehi 5ImHAejq/8DlAAlVAIDbANARAUkS5q/ygmwk44x2RASk28iItsus/bA4+63C7mzo+kSO0AlC DQ+iuKNBCwqu9YjS9yuIpYMEuelCz2iqivC4bKvgBaj42w7so2o6o+io0WbK0cwSLA5AlC3q rUu2DE6IDYhYDq4miUiYmDCquKShCwBQ6unWrTCk71C2pYvesGfJESuaT4vgeqJHEmvpDZEs ri2A4JDqqowdDwksuiKesMjOw4Dawwjotcou6utU8WrUl7EwzsJ6KCvgq0uUz7DWNGvsfIv4 zgjc3S3W8sBBDEzqa4MrEZDQuWz8vrEtCQwqWusAwQktCUa1Aoj+o21GyG3HFihZFzGcJjE2 qABpE8p3FAksqvEcrEtsiIDgtVBlBoDWxskGDSDwiO0UaLGysFG2LXD2BQlw3W00t7HMJ4R1 DMBQ1NF/DVEzGEsGqvDe3HAEBAkU5k73GYz8UhIdGjGBEzEZDdG+uuDpHqxqrilGCM76iJGs K6SrFQ0gS2YQsMyusUhSjknC7qzZIWUpJDGXIivnHbEqqUvwcwliiRIWJIchEshJHYKQW7Ic vwVeKkzMhI/EKDAFFKKyJjJocmVOgawagSge/ET2ledvEIDgDemG4cjkDChCse8QiWDgDSgs gmieDIkMlPAi106417IKnAvO4UDDL48cjq2UlO9al6zcrEkclfLiMYm0m5Fena84PHIMmrIW NVHREsCbKkINM/G2sNA0Dm8S2ChWmuhMmG6GhU5sl62THxH0JkhUDO9bM6LUNPIdIgz5IlE/ IoqUB1IWQEgEIFOMRIaySw1wBRNDKJGmIOOHDMRABqcrM0BAvxM6JKZ2vhOfN/KKKQXyITEs ygylO2BqaXIdO/DTPDNHOmvgC2BkykBdPrKHN/GaLcR027O9NFOlPIqUC3IWN+NFIcpBPBOi NPOEf1Acnwa+qe1q0GJ6+C22ui26+0gmtkmA2OhS+fA1GNLwj9GSIuj+jS03Fel9H7KZIjPy SINXJDP9JLDrRdKpLCwUsNDe3Ij/RDDktrPvDTPypdDyP2bnM0CSCsipSEIEbCOCNmBiNFOa BVKk+mgIK6IJSeucjC58xeIvMK6qrKiet0/AjrNQhQDSkI3rGsQjIC0e/iumBQ71THQzDio6 oS3cjoDbBxTmo0to/5FxRY+kSHPXP9NI0DGIkgx1GuLBTZSGivLITFLMnkgkrVFo+W+O2Gj+ hG6WzY8Qj83rTjT/Pwz9RcJNIdE5HXOhDXEYBZRmNg0bG00hMDBbTe2aoK5bR+vWuKJJVLP7 VTEyUZIdQFUBDXF5EsDTP9QWfGC6eqJMBSJFIMhK1M0Wwujm6em4jO3JJUoOyQjy4VJRJU0U T2wPIEf1VDSA+kS3EZVPRjOpNMv4ovGMo7R6/5KzVu0Ook8lU9Fs7pM6QFN5HTE7V9E/EZOJ WHEpFBOQbKBqM6h9OaCRP8zHWLIGY3Ou1yS2k0mclGBhLUB1O1YMizWSRABumbSNSQnegQKn ZQVgIE6A+FSlYEUNOSa/OSVgNHYbQoxfIWBaYmhssDPSmaf1YfZgKRYjVMBRQGMqUjIdWPaG KdX/SHOtVkN9G6lDY5Y9VEuKKyY3ULarHVRjPVE3aPY/HaBpaUvhaFQRDXaLbDaQOGKkvhaZ bTEyaXYkf0kmleB3O2JRKfYnQKgbNNPZGkuKNULLEZWFaxEzbdaXP9cUfFOrYrQtaoBRWWBS jkdHO3PHcXabaTQBJqZ1YqbsB6worqBiBZPqBdVYx1VypYJ7a3QNcYhsvg34f/SoIEQIMii+ +u58jEsM7WDYjOhZW/HtMcjrHi+eszEjeRX7UXYBVRblYHDMquv5CO0UqoMjRtCYm8zS8gou +5T60ug5M6OJEZcDJHE/a5S4DSBcDLdnXOuLZkIfOSaWIIW6LVZxC1c3Z/aNbbdjNBUJPhah cgkzAnaqlhY7VwitRbIdbRPbOjbXEslHbbbNEtQPgbGDQLE2BTfaauaypY94h3dsrobAOBd0 ctcisMCGsurQ+/IyCgmGDrBgBbhS2k3FSnQe+pdubAqpQpFUx+lCCnLZLcgnUw+TLyiQ+47x CmrVM6TRIdfxefbJC8fJAqmGiQ7mhMtQ8CwI68YHUZIGVg/klC+dEhiTTjIWaLXVa9fzejUP MosQridfI8uKT3V5Es2isw7neIy2iZJiZRi9JqODILjHeRjKszKkUzik7Y2tNrUw81GO5Ne/ GXdVgTCtIavhSPSnjZKXeqMpSfj/YtamsMDo5yqxTOq8xJWytUgzOKSqvgCxP9KovhKXcvbH P1V4RrEsD9DrOqsAVjEtlfc3ljEsym4VHJlZOOBBfke4NZQmn/a7YDigz/bBghbFcRE/bLc6 cmWwcsBRkxaGNVSbIdbzlqKdO7UawWgYgeBBmBmjPfmzOqa014k9gIlElhavfcpYNUKAfDgh jVnaIqSjf3nIMrf6qVm9mjnATzccWJYqBQB3gRDHYHbBP24Af1l0neuiUak7b3l/P9o5oWZB S2ntQc97hzPTftmcmTlAKg1+2DW2jss6yG2ug0DEmGDko5TjHIlit8sbNtMO82neklVgcnWA mc8fjvhW8Zj0nIs7EfkI3BTi2EDY6cDItE/g16tMlCm3BIKpBnLfqPhUrSgzXre7DjkKiEvK ojBYhs6C2WDCiIgzXemu1AhEyQousYuAnG5YhMlYkDp1G+rRrXpYmdLbeO2Sgm8e+cDG3cu3 XhkdR5kiDCDEDfU5MSy+/gyZsfXlkjIWT3afYmTFS3oOpbYQbAbKRuuccfZQiBZfoRhugIRv macfDLS0csqvqW+5TqyHRLTydWrU/MjajkiI0UYPVfXI25ckjov43rLfJ65zBUjMm3mOKnmU OhmaiBifgtJJmmqVgjoHcbo7c3o/gDakLnYzntohPyOJP5n7mhu1YHoDbZu/oKf1XXfzvjmp f5bfSHZHtFZMf/ZQa/ZQRubCPDmcBRtbvfZjtLOSRu94UHObnHmtbJgmqVnZwUKRvHb7obbx aQrpCxnhd3NMChYg8JgzDqMpo4wrO4crc9b9OwdlxjnvdXZBoJv3u7n9wwp5u5vrmrnxmvwr vrxzcFu3fRu9wmKRmxOpBbv8ipwCIfwHbKXGjBZdKlfhYSIsNOn2JSjDoZS3ofaRf0NhQvos kjl7opvDn/w1xdw4BTwlx/Hbw/yWY2krOxxJc3czxPowaLZ6OiZ3w3S3xnkpDXzzEtuzyJol a4k7Sfw5EvoHzFzQqVouf/ozLBzHoqlDwv0RzjmF0Bm5pGqbtfhCUCYJhLM0CRVtIWKzs+f1 zvn+NZyXjAwfjaovNmhjS6xCjSoywyu28QhUwkiQuBi0r6i3LC668KyHL6otNYidMP2VI0uw gnBBsQyygwwxXqo65NK3CQ48cesN2nCjrOs1Bwv51tr1riwkiG9JXrsmjo20BRMurGytvSz8 wNId01fNHb06ugkznjlBYxnVIyipbflwqV3pDXxvzLqDzP0wBR3xOB31xBvLno5ooelotiDC zYourHRRMXNwvJDrN2sAKz0xQscygeCYoUmGs+mE1E6esrrC+/qXeNjI3BCRqFuO67UjTheQ u7j3hpqUg5rKo13FRI9br4iXL9quNqsNRBs3DnfYeWrUouyMgkhIociRJ72tVu+SDbIW48qm sMDhhfhjqREh5m+bqc7n3FSmK/b5UMjt6FlIqz2Gkn7dk+mWP228oKrB6dkh6hlXlqQFbqlD tH02MWvhVZqCJcIp4b4PIm0bl9oMqL4J4b0mcv8j4Kf1v/x1lxGHlmlHsKlw2SkC3OxI8UDY uFUSVuBzuNTbszW18eiyKywdldlhVXR+vr80lD9lHbjr0ll3XT4ZzT87333/clWigmmysRmI jTmN8FwYbLfmBASJto+Fvt1fx5arx9xpwpnfXTzr8L858PoTKOf1zf+6bjnNYm13nT954fPD +/zpakk+gfLV0FoihyRryleba/yMBQIAKSoagaLyMMRkIBiICoZgaMBcMxqMxAMIYRAaKCTA oJBhiNoVDIdEBiN5BEBqOBxF4yfo5BYPCYXDYeLpLIBbKJVLBQVpfHpBM5GLpMNYrLIgMhuO YYYwbORcMolDDvGR2IBBP5jIZpEKLFaIMJAVIwKJdA4eIKgN7FPCxWo/XKGNhoN6PZJqMInT YyXBSLpeMYtg4VFqVQZMLqMVDbaSpTogMBjM6qKCIZTcICEbzKchAYTcZM0bzmczKbDDnTmI C2Ni6IDMbzroRAcNMdTIbxaYzebDYaTmaTebjnL4sLRjEaQLrFY8rsc8dDQZRBvDacDkZdLw syZtmYzp3BAbzMICaRKMdzT0qzaI9MpEDZKLhxRoteBRb/dB6D8a8u6MKgvSxsgmwaucBoth QEAeqyLoqCU+SwLGsr2o6rahJqGr7J4s6COOiEKIy/ULrjDMQw4/DALQFoZK8ozkOUvDIhgu zHpqkrFsqLgUCoNDgBA7I5jqNg6BANLrt+7QQOkMMjOk6koDe7I2vG8oms6NY2DKFqXioFS8 hklcbssMI2jOLgZBiGg5DIFgQDvH4xjQEAyM6NI7SXKAQNMMY6jk9Y8ysz4QDQMI5jRL0wPv AoYKYKjnu+8LhtgOQ3yq9bVtnOw5DYPI0jcM7q0u7DtODSjvDc8DuBZRSnxpAlXuYGaKUhBI UDG0A3DfIwxOpUA7DeNYytE6DzPQFy/KxHzqDNUAyVBUTyNq27cy7B8Iy+xynQEGbKIy3jfO A7jV0QN47tXJsnunUbryFU7u0lVlRjdLq0W1AS9KojLg05YjPtWMLqjkPI4DoN4zjkMI4Tk2 tADa9c8OpadMvGO43TfQ2A1cklHX2FA7jKMI1jdUwXM0Ot1jKNLPWc0Nos+Njhuo3Ml13I0t jC0Q6uLe9F4+MeZNM6I31HcV4NXac941OlU1W4cVwuu0MhuFymIs5IZBqhYcMUEAahkhIbBy G2vMYtKFogHO0hANa8hghNbR7djeOIOg5Drp43OMqIaITGOwUfAMaW+FFp6Y2F5OHnsP77v7 k8C5YYMlj9jOwMNV1yNm+Blvy1cgGXBVlydasrhY4N/XNJuJQtD85z3AdCpF9wVg4QV8z44O wFIWhtw3MOmMgU2wmvO8exXZRm5nKbkMVBOsMVQWj1/j8i/EpOy8PNepz/kdEFFgO08Izydc nudj0T7sq9T2cuM42/KMfz9B742jK6Q3jIOeogbrt9NYKiDcozXSjNgIS6EGTZjGgoCYG80h pw8vze8TwOYcGRBremWgpLsH6OSeYZVcJv2kKDShBJ6xZTrKlO2cOEzyXBvLbipFVTqzPnZh a+l5bhYQrjcXCQ6cN3ZtycQ051cQC8L5W+gp9idGBB3Dk7xNThlQvDQg8WDkE0ZsfekeEMIb AQB2i6HUMr/AihUAaQENZW5kc3RyZWFtDWVuZG9iag0xOCAwIG9iag08PA0vUHJvY1NldCBb L1BERiAvVGV4dF0NL0NvbG9yU3BhY2UgPDwvRGVmYXVsdFJHQiAxIDAgUj4+DS9Gb250IDw8 DS9GNyA3IDAgUg0vRjEyIDkgMCBSDS9GMTYgMTEgMCBSDT4+DT4+DWVuZG9iag0yMCAwIG9i ag08PA0vTGVuZ3RoIDc5NjENL0ZpbHRlciAvTFpXRGVjb2RlDT4+DXN0cmVhbQ0KgAwEBnBs CI4NGIgNIggRKhggNUMFw1EB3EAzFw4Gw0EBNEBbLsCMgNOMFFwyGI1GcPgQwk4xHIylggMZ tBo0Gw1FwwGI2EAxGQ2F09HIgm04nU8n0wG9DG1FNgNlVCGM9n45ptEEFRqdDq1AqlPrc3nM 7r9Bp1QBpiBpRhEDhAwHMZGY4i9zGgylc2qsuG8oEA0lw0lVjvs7GcyGgxoY1ilRGIwGguGw yu2LxuPuOTyuXxg3GEryGSoY3n2Y0Gizel04yr1qyOTGOmwOuGQ1hORjA5jl5F15pehjMJ33 AmlxxgzGut39Bw08oY43uu42Rl28G+118/GHXGnZ3084/WF3Yi44F2J7Oj73ZutDHPBxgx6U Xpo5qvc5PL+3l/IxrijAcISGb7vy0bdo5Ar/Ny0jZp894YI07jZNo96YJ9ADYtY87KBmjjRs 4y0OhtD7nxEuwZrmGTJROjIcPdFcWtGnQbJgu8XxAuKhO7CC8Bw2AYKEHAZQVH8gqEHLCxUy i8uepq/xSuaNpk0b7hkmUmQGuzRvQnMjOHLi4rmyMfOa1TIrmHC6xwvLVDMhDIoyHKVhnIYa qKviqvSwiLzu2E9w+ik7N/JzIUDPtCBnRafz2GsiT8oc7UaxixUIGNJw0GLZJzSNMJ9Q7J0X FKqUmqrJhqG8FKEGknVOidVUixyZU1VFYsEk8TVDWDepdOyl029M2VwnLc2CnqKWI3Dxz2sV lITQ7GUexSXWLSk+WSwYbooqrkz7XFf2Zb1Brm3lAJdIE63KGlzzndT00ew05RVKV4TFNKMw hLz+NHMkRvenNQLjL0LLmGFlys8tWxxg9oLjKFBvQHDCtHJKsQ7ic0SEjKcQ69cdp3dmPOfG swLlHUNqfOr0Uxkj00hBa83bdL+5leV0TpSOJrUMwVAaIQqAaF4jOyhIqTgoSKJaEGku4nwZ LmigqJsgQqDkt6CBQGgUioNQGiLoKBIS6+xhAJa4o6EGBhdbYQNAji+QltiKXiqIp5/oOh6K EGjgbpul6bIoQagie+aon6JPwh41pNqDsipAAWpdTGpDuBothQIYpBSqoUCyKAqCeIQsioIo phSFoapQGIUdOoIZhQEAqhT1/Yib2kS9t3HYBAIvd9jzfahB4YY9+EAc+N5HhBt4wQBSLoqC Ugq4cImKV6qIiTNCjnIJMoC7Cpy3MBALjEoT4YqBAJHe+Hvn2CH9QQCcEAkhB+AghAJn2/mI oQCuCAKb+X2PpfS/0KT7QnggCM+2A8AX8PDf0/gIQIIEwHfw+mCr9H2Oneg9JqJMzIk/OcU9 prU3pvdaq5ZzIbw2hwDkGUOYcw0hvDdAoOobgxh0hnDUN4ZiOhEBq1xrzQyvt8ThCFpcISwN MTW4WEzkizE+fCA0FAVA0BlBBDINwZw2RYDmHQMocA5kKhqHSK5NIWQuhhDKGgIIXBvDHGsE EPYfg1BZEJ6YLTkt8ey5MxLfHxAoDDGOOkZosBvkMHIEAaJBhoBAGaG8OYdyEh9IaH4NAWhm DCG0NIbA8gpBwDAFEd4OgNCoz4lx3XuQqDDC8EAYpBhlDJHOMsZwzBvDYGwN4dw0xbIqG8OU sw3hwDKHIMMOoaBzBYRWK8rgwx4iITJoycJTxUDvMAMk0AjRFb6Ywor2AGxQO60aFRCoxhhI uDIFoYg0h0BAHEOoYQ3Q6DoHkHUeCfAtNdFKPsgHLgoC4kWIILV2A0BROwOkvA5xYCEG+XAZ Z5RzmJMaZAbplPPejHmPYVI+k7PFFNzFATCOooLIIMgZJ2w7KMG9zgOAUBkDrLpwdGHpN/Ie 4EHJLiKA2LlE4mwKDEx4iQQ+ELjmmMHp9FSO7XZworBBHo9MfJwypo/IGkVA6ShjDyGMNgaQ xxZDQGkMwdA5gupoXEocICBIsboDaErVGQxSQA5NtsU4qxXoXRKYsx5JyLDCHaLAYgyhlDdH iarVa5k7BuSuuwYw0BvoWG6ZcWo4ggkMHkmlEbBRoDaC2wzPpxTkioHAOsYJZ2ADlZiTUX5a TpnXO2Nwco4Qws9Uyw5iGjWJNm5WKgc5gTnDdLOykWJLScDxL0M8cwzWfhPYkGCsa7UNofRG SEOKK3AlmGGk9KYaXMqoTKFBpbeAoDTGOwVXQy2AlmHQN8r4sBjtSHC9gZ5jBwrDbVr1t5VN 8QACgMYYZc2Yi/bKLYLn6S1i8GWeAZQ2PkMSDIFb5S9Xev5VMsxRa7BksJIiGFloz3apRRWl dMKZAynwRNpVN3CmJg+d+D8JqgYmqYnJsrYq1sHMCZWpNoXHyBnlLPCWJgWg3BQDxzlPMigp Rs7Gs80XEN9IwYsn04AUBzm1NxOCvjvkPo5hYGBt5/UAMSSvDQbsOTnK2GWsZNA0hyDHTGVs eAWkYNMTKqFjJ+12DnWHNYYrMZXmlEYBpGCUF2yplapkRCl6Cy0dnKkbrIXcotWapmcyJkbq fPuqUqXBXht3P5zAVwUofBQGUFMorLBhDXFidFXLITFK3Q4NYIJj4e1NKUgWd6pTiSFhWcUf 67BNiBZyNUMaVXVklG29hCg2X4lNKgnenbdV1hUGwOuA5jxYnbGOXsYA5BuwBFkOgcg6w5Dr C/Sl+ZUa+lSoyu0VosG4nVQiMlpJ3aAyenAppxsqBYyvotvq1WFzgfHj+EQOLXh0rOC09CQi i66y7py3L3tqRUl7SncIdsAB1ixviaZUm2A0evVIFASQrb/3yQhkOXHs8FlcHMOFXZ3bdpZK UFpQgbqQ4hnm5zUMwzXmDWVvkZwxxphfsaNsb44wxu9eLMMw69xgkJDWW+55fzBBBC8M95dv aI3U9pZddguX+kZxeX3WuuTFDmFwFLztEzb0C309GheWRUCDyjj61Wc5UmXx7RhE0+5UCF3j v5GyOd87dEPuHKadeB5IEPwnAeQ8jy7KPxLQvF958BinyoRKl+KyxOFPadCE87e0VbT3FXMB 3rDY7WgcnaSi20G7jFXQ9SyIrO2R2TfM6CWamvuvJeT9v9CYxFuVN0+iNcX8lfprEPaN5mHe GxOjxshrgAM8wPdBtr917Z/p8exU6rIq2UNwydCfx+W4MaKLdckpczXmGIVFWi/GHoQSYa0Q 9d+q7Mud6rSrmAUOgPzvLsnOPjXFUvDuSN/PiOAMsjKO9uSAtu/PJEPtHOSA0vIwHwLO6qqJ VoqAunyAUQKQHkgGyvKwMwGvGE+QLsunMMjM5qXCeu2PXtWA4OYg0vcJeuFidCYC7PnCzGpN preHMJ0KULliYAUAzJinUEVNSp5o5vYMiMNPYDpPLJBqwJdoawdpSrDsKqqLRHMAqHOEsJBA xIuifqzJSqhsbHBscCUCdGpK4LnnwIVP8AQL0pisBIwA4JloaJDpKuiOyg3NnLbluswrkOsg yutv6g5NuIxg6g4AyNsgyMDH8J6g4A0xCtoDuwhOKLxr/sGv6g4K9KKKVJCuiIWRNrmoToVN ivrIyI6pzQSAGj0MUiBRbCfjFifgaqdHDO7QNCTDTPOKOmDnuL+gQAdAewCvepuiJgcNDOSP BwVPNCNwWnsnYgVwROxxaDXEHvgu7xqO/xhvggQRtJtC7OPjGGoQFPKgjRgi/FOsqRuPiO4w HjvwTxsRpvQQHCTRrPgvPvMCgQVx2PgvIRxPJEiR2xsSAwDO/yCsqAiR4G2R5OSQaRzx6uUj Ptet+yJjQMpwJRaDByBsqQUx+QVjFiZMqQQyMPQR7OVFHxovKglyPSKvKu2R0QVyYu6pxOcs KsisjSEIjidk8RyyRCTvotDyJyUwOyiRjoqO2SAw2DuIRClkisdqqHHr+vWJiuOu3x0tBNNM qR3yhRhRiMvNgJApzNaOsg3vzAWsNJiLgrCJ3LpIurqJIsROxgygXAzw1KMtLDlKnqNxiqPr +gsAngpSoxmSBuPvKRsSaSyi/QOwvqPLwJyryy2RRy4IwrCMyp3OiqLA6J5J3ODJLLZTRtnN LDswgCeQ6oqMRJNy3QoRaCdTHreyJzBOCHYzMsALfNxIwzOS5TPxLKxtYOlI1rPObEaiKQgD ZrRLyJfJLPxy2vzJlNbPqI1qVONNrNtJCAxRVpUiYtQAUTRpevcM/OrnUDZqXqFNWLty9AUA 2qWCgKXqYr2sTJSqbCBHAxoHCgbimw5HtE2HusYqhGlw2moQ4m3QERfvnqAO2o6RaDGGJvgu TRgx8p/rLOazACYCMzBqouIswpLLHAwuzLku0RGqyptG9m+oPokiBE7T+D4qkq7osAgg6TRg xg10MUESqUZImCMUBTxP5IqAnurAwwbrZAwvXNlgzJepZuipcryq+xUL3ujTtLurbROPgK7N kMRI6NhCKTMqKJmtiKur/rTNaP1owLHPaTwjtrGsAJluDJmosA7r3qIoaJPCBg0rAS2Pygzp HA0sNJ0AwgxS3OFUtntQPgULHiLLYOgA1v7zQLNIsMNA5r4A0rBLss0TRpOJfUrOmsvzXpBT uJ5LHIsM1QlocpXrMOjtxqvMRNl0pKuvrJKTNJiRVteTLoqAxg0twpbg5A2vktctNOIjGvwg UAjM2rWU8NaIYg6g2osVhTsVpoYgwgzosA4UTJFUJidSZRsQGSTxqyziXMwUCu+yMvNGlDKO SA/I8NclqwFyJybOeUNIzNasAA2OFjZ13TnFJq7QBoxuipe1fsNJlpeIzJaVVA8I4r5IdrJg ws/11vfCsyzgUVxyBR+lq2MQJ2KwK2MSTWNuUz9mmHCgak+lU0AxfgUAYUDq1AQWUoPlUsXq fwQsfs5D6DyzmzJvK14WQE4JxWe13PK2NNFQVxroqWPyXQVzdQMRg2TGmkC0hWZCN0a2XsZ0 fIQkC2WDlq3svMvzyAusDNRCgtStTnYrHKHK8rfVpz1QkpZveSwJumlvO16xy2FJHA5g219n 1JN1QAz2dDXTBPTNeToU8A01BTSv1pBg51pLiJGVFWmuPxcmlxckCm6FF0a2gGvJUyiooSP1 6TJG2SOSQ2giTSmSSxg0Fml0Fi6i7HVUFsYWsmvXLCH3MTxnVWWITXPynwwMwwQxl0Jxn1wo qWjpt2OXSyQPK2mSBSXyRyVWoSy3WiH0FjF3Yjb2sI8XbxcHCi8iZXd0ayWRmW6ShydyIyPX TPKvkyp2uKeWZDoUhzKlNzoAjJgTsNiy6NaUc0mNZ1npGU/0J2q3Vyy2pXvgcjLgc2bIqXam 0UYX43w35RfnxxllNplgxLSo5pE1+jJs7TCVGQiOyA3qvMOpOXFr3NINjQzy+G+AUk6QzQ0C Es9pdox18t7pSyHJumJWMXkPQzJsqAtlNgu2dGozm4QJBP13iJv2ixsXOsvWiJ+XjyPVzMw4 hAaWcJnQbr0JZwdtKjGCOJ9Ymp/qrnUE8KDRRxeQRP+Cfyoqztc4QKQqBYzDeMqw+HBifOx4 2AZY3QumfY5KRnU4640lJ49TZpZgZ4+qMpq5AKB4z47Iw2ZCE5DPzDAu2S/npKoM7VjzCrGJ AtRRe20NUJbs3pCUkUcy6KVNlpLKFgz1pwoAzPYI9HWIWTsUnxHOFNcUQM8HtERq7ZVozqFz Qrs4tqvK+I2zTZgxF5Xp3ZY5apDVRqqzYKwusZgVqS3A5WF0kwcU0odp7u3luPfHC4xYpKAL yScSyxvTKM9Q+IxiUsHDADnZKLg53AX4+AUyGgjZwm+4xPS4kOxg0g050VySwq0tD52k/Z4C Ell55wCAZgXgaZL0D6DKiUY34GoWqonqqRPNf1e0bNiLS5jqLLlTsOioWvqztuNxATGSX2dj cYe16wIwXHY2c4cxm2hUPEWQf2fYnM5XPqn152jaYzbvnpUkSzyOsobxY1uJjJcsGAQRI0Nz gRSFguh1qVmp3QjwloXocNbzAOBYw4QJUmOq7I4M3xHX+TsLBOtg3PaVQofZW5mQRVvvg2R2 kPNQfPgzFyuIaxaMo17Yp3SGVPg4r4iYvi5jlJ8444kpsiUsmabTG5xPSCJZy4n15Yx2MyPO RSmjQ5PWl4hwataZiwdIa40iUsDAkofVnr/vrrHQcrAM5J9rF5dtNidj60vX8a439x6XKNBC dF2WRSJki3jUIMPNapezsTPJlg0gXYW40ig2E07RaHUvJ7aahbBOB7ajI1lbCxFOYMDRaDZF 46g6etK6fooZy4fXlFVTbgUbupWwbQcPcZWAy5hrLA01ppl5oNK7fklbrTC6PTQowJ51cUSR BxE0Uuuo0WDVCAy79Iroa08P4JUkbs9JiNVaSKI7w3S72peg3NYVa0qUtaCG+wemRTd6SbdQ oRubISXwe4E667hAaXjKQgUsDMDsPTMr/qF1+idKjTW5pNSrUA8ozcEIbpzgz0TQtoa6mV96 n5nPubnjstljlSAxDD8s9WDIsU7aWOUlUWUvg71QVvDbCbQODa/Dysp7MYn2h6gbMcxPNb2c y4sbQszTS7RxK6rLCtKk1FlzWgb3EIscPvcJ5JEUzcPcQJcVbNj7c5l7dwR3UWdj8UMrya7X kyUGOx5u24vGvI9bED+TnDnaypgtYNlzPPc2F5WJN0r6T0soazuOOJHpgcJqPToVEWFpet7I x8Nqc9Kc4PC7s6Z017GgbbHqM4dE4RvSfbyIqc2bz9mbM3Sc5PkM5D0MpNM4xoUoqIrNro55 T0dNZzQoZIv8Cg0IX1tpWqyZvvFZ9oj2t0Ym2mJqk3gUCuxgY6B2SQD6KURUC0nrgxEqI9EJ FcQxYVqv+Z6gZZ892pw51cgOJ5zZ7xg51JwUH9/KUJfeA629E0p+C38eDiL6IeFOU5+7/ntT DSoKgd8a76C0M0HzQ8PpJTpK8LiJroycP+B9FcRNJo8GwHpiDiEiLCbxfE8C7C+DaeiCxm7m gPMeFpviHiiuRHCqeaMibXDzyRRz1lFnYY2Hio9K3di+sI9etAUY2AZqz+exfeglcG6d5Mwe jCfFH8fDNelG8pt3zRanC3L3v2qyY95swifxaRoxcG3WaT/UBdovQe73ugQRc0K++0h9asKn MAtgYYiI9Oc9ilFvebIu5CZx0jcWUfDWW4ffFe83cHCiUjs/H2Wgtga7DGvee+12ZLFiTiKe 3/ZtCe5m8SBfSxb/Ge92UDTe/UCqZ3UfBfGfCfg2wfEfeOU/F/Gm6fhfIJx/Jb3AY/LDZiNK gGt8W/nfPReFpfZ/l/SfnfTXvFuFU/xUagtgcfXmvmg/ZDlx1/bCEejkbfa+k/doife/PfgK 2gaCAC4aiAqG0GjCCGMGigQDMUlQ1A0XkYYjIQDGCGYGjgQQiERwbjmBCAajYaSOCwssQ+Ix MYxyMFSNDiRx4QTSBjiByWTwOUjAXDAYTGFFsUFsZF0Ui0YjccDYUDMaikulQlRKKRaYzOO1 2YDQbSOeSiDCiVxCsS+LxmNzWvSMYjWLWOfQaEFSFUcYjGlWgilQGjSgTsaSIZQODU0bSTCi 7DiA2A0pg0hYCXTC2Tiux+RjQZ2K5WSFiAaSy01rM5ubiCQ6AZaKzabL2uZW2BzbNTqSaG6w eg0OEg2jFsZ0qmU6oDMbVSrafaVzcRewa7YWeWxTMbXNbi4XLd6/e3e8lsYjS+xG/4HByQZj fHYgG4r2e7H5HJ5W09mZ27OQPPLEwTYJI2SsuejbVJAkTCPWlLYrQ2atttBCRt0GsAvC36iO Eo7zKWpqnqiG7mKulzUO1BCLhqGMAQYsrrPzAztrega4huxkWoW8jzga9MLpIw73hAxIbsWu QayC+zKMs7EYv4m7Os+nYZM0n7goY5cHwLCKOOi1spSpF0CLVLcnNzL7RKAoUNOGGrjQ+5Ic RG50txQuMVzO3sHOvMbMzK7sbLlMEcw6vzAR9FTPsfIcihjRKByS/EIT628ZtJKKSBisLwys 1kxRM6CvNZBVMU0gkwyzPjtT8nKd0zNEMuC4YbTc5CohzOUSxjOsVLFV08xfSVVUo/sU0BX1 TRyG8dx69YaqHINFpJZ76slJUYTJYcnv9S9nJ7ZDxNHONUU/A8u1HbrqzE/UJO5VlpW8n9YL xDYt2VD1asFXEtNS6Ly1LdFf3VJtss0uK5hheC7Ss8gYWXQz1hoHDDPg+WI4myFq0jJlsQnb bOhy8FkIZW9x11c2P5DBtgY3SeOpu/2QVfNVYqOHFaRAGgY30iuTVDf2UXTVF1xlYmDNJmNN 3mvTitNZjOhu+mKSI0moSRjMl1S/eCSgzocRwFAYhhT2eo/UWu6/les3ZSrdYjHE0uBebhhz m6oBoGWd3JLmfV4/2vaDPeh1XYrSb/PIt4bpuHs6G0j0U+OprBx1H6va+W3bS3GUFcGwZ1ks 6S7bywUFPXLWFl2vNIG1BOHsNaBuGoUM9vOyNXO3NcB02tZdGvVc3eTx6ZQr1M6GtHSFyDFh p42rPvrHBa3jz/JLNErIrsfQVCG/RepgOhYH1CEeXUqU9avl79h2TSqrEl9xPfu+tJ7uRbT6 HeBrG3x5luLx1nxTxD/M5Wg8k0kAlqPOd02tYh/4AsJIO9Yhzn1+PadEDSBzpVgu7cw6mC0D nWlJfQ7F5btHstldvA13MGYFLacJB1/aGijt0f+j5u7F1ow1eataFTRIWQMUsylhTSjyvYgm 2V7aUIgEqYExyDb4gZxJda0w476SwQkiK7Y6a24kwYZY6dzDRjPRbPJCB4cNCmwDYrGeA8Oo uwaUrD5u7Xy4xEffBQzoMm0RLcu2x8UeDROtQ7FOESIn2JziuV9UscYUxthWwU70inDlxR2U w16RCBlMBczkiwVAiELUzHRUERnRAwdI/V8ETTSSkj+XpNsIXZJxkKrmErtn4mClLHqLylXe y2hewuMh6DAEYDuCCABDQcEWWiDOY7GIEETRoWwHJqpow+mUe5pJCgWtwJiHdDYcw6BlDgh4 Gc4wUByDeHUNwZAQN4KYDadwKJvTgnFOSc06J1PrOaek9cw5inKhtASf0OWNNqh4ZqagNwZs iKbKBcr2lRntoSyqXEbliG6ogt94C9HznHZwreWL7pQy0TuQ2hD9KJyNT/SSiJZXEMOn6/iN DUypNRmZGygjg5qA2JjEEvJL6GN7iNQ+nVJnvxMbYQM5VOzfMzbkUd/1HCoLOitHWEz8ak1E cDKeXT+CG1DQavWlyPgZvLpiYusbk6a0Dfs5iahhVvvWZIntvSKIj1IrdRKose6KkIrHNF8p eqNlNfSiqqdIZEEjr7ViBNBTukWsTV88tYT1zjePMmcdAnn1agWpecaNkGx4p/XSh57bFQ7c HRa0i8amFFKO4mqAKC5WFobVWkdnbSyMsYjSrltqvytjLZMGSK3HnyifcJykzbcU4s4Y9KrS rg2hZPUi5ip6s1GordJDFq16Stte8a2VQIsKlie966teoWNGvHW9pUY7JWIBhP+4l77MWLuV YhRrIgZN4glVQ1ddSG33rxeWXNe7/0ro1a6wTsULXfV3bXAF1L6PRcIDPB9S3+I5eFMCYoMg c00WjhymikLM3Wh7ZxuNPCFgygjXJ2pIFvAzxPEqvOA4WOpxhUp1t3ME2wKnR9nks7D1IxjF ym+Er0ZDYZe0gaU60YfJ1fO02EofJTr8WUGRpb92GbNktiVt8iuoy5lXCya0ON1tgcvH1c34 Ujypl6tdW0bZtshkqddCKy51ePiLCLLsptQvUXkw90KHEjBln7AOe4N5L0MXajLc8zP4wZmv Qmi8ZYCopeermhbPUsZtDM9YMqdZ31BcatOI7zUGUvqCa+KUsYsyAaxb2qs3WaxqQjWVfzyS Bx2DWWBzZZSHOkqXW+EMov3ItsNHMktPaEMbcNqeV2L562LWzVLxr8IiyzbO/qozD4GyJm+6 869rWqwucOKSb7YUe19SDbRMH47d1niSR2cdx0sf9b/Qh7dRb6jXWrWmqNmVKc4lPQVQeA7x 1OhTJbOaMXaOHp214NmxZpxbsHg+h9p1b2Pwy5p41G50vzk2AnIcoXJylqnDl+K4yGv5i7Qn KeMcmfDOvmBBoouvdjTrSLfM2c10rojOHNMxTaYWoTDSPrg2V5Go3kuX9qaEKbn8heMOC7b6 hpvn/Gdw3B6x0SppSMzA2bxxTV7P8l9R5j07jU6+0YosByBabUjFx41JtLmXT8lgwTzhTqqC dCd64RjRM06/AbkzJWBe6IAbEO7JsCE/hLydAaLpnwtLJfgNKYZ8qVCZMSaIJJ1zkT++6wLg Dnb0pt5IUIQDH0yyIP84BQSbndtPS+npPblwnrMDdePHDJ4ZGAznxBBMNsJQgQBNmI2EgZJq Eo2BaxExYcgygNI0Xu2uHSRuNBAC2PE0fpLV+t9npny5L/dBB98yaPqdKXJN9v836J+/Y+WD T917/z/TMn6sjoLgckYIQCWN8IGn4w4SC7EJOdgRSVG+eYiJG/gY0RsTI8A9WMdAQM0q4Lib eLWKA/6K6DWgeXmLum4KMCoBSByBwBQDCDEDYDKIuBctkVGJs24pGUamsWQmyXkm4BQCoDRB YDaDKDmDmDCDPBYDuDeDkDIDmNMRWBoe2+2RWOUI4k5A/ByCwC2DSC6BADC+kBADqDmDKnUD SDcNNBu1A85CedW8+8w69ByDCBADIDSDMDMDK+kDcDoBBCMDJDmNMMGJDCcBdChDTDWIXDCB ADKDCDGDQ/OnOnTBceGICA1lbmRzdHJlYW0NZW5kb2JqDTIxIDAgb2JqDTw8DS9Qcm9jU2V0 IFsvUERGIC9UZXh0XQ0vQ29sb3JTcGFjZSA8PC9EZWZhdWx0UkdCIDEgMCBSPj4NL0ZvbnQg PDwNL0Y1IDYgMCBSDS9GNyA3IDAgUg0vRjggMjIgMCBSDS9GMTIgOSAwIFINL0YxNiAxMSAw IFINL0YxOCAyMyAwIFINPj4NPj4NZW5kb2JqDTI1IDAgb2JqDTw8DS9MZW5ndGggNTkxMQ0v RmlsdGVyIC9MWldEZWNvZGUNPj4Nc3RyZWFtDQqADAQDEQDAXDmCQIlg2CGmCiAlQ81QUXDU QHeBwImiAtl2BGQGjUYDQXDKLDeRiA2yGRyWLDUciA2A0pg2BGebCAjg0Zi4cDYaCCNx2Pg0 4zaSjKlQ+BQYZDEcjKmCAxyulDMZRUYVIYjIbC4YjaY1YZVitVwcjewWKZA2yjCeja4QO02u YzO33G512v2G726y1mRVyvXa2mIGlGGCCcSK+jUbCAZjkXDSyyqWWoYDYbiAaQYaDUZ23HC4 Z5DPDGwDWLTORQYbjccanV62WbDZbSUaPXDCDDMYwQaard6Tfabg56s8G/6/kcKsyaCc7N53 LZWvZ4c5QcjPR9fLZExg0aXWg+DszPy2qlVL0ZHy1+07Pr8ztfLc9cYQTx/GDtyGYcNMGTOv UHL8NnAKwQO7T2KWGa1IQ4TzMlCLkv67aDu9CqDuS3qDOrDkJBA5zgIJBQYJ/EjjxMyUBKg8 TbufFwXBsGagw+FzYwTAUbRxGUdskygZJS3rVJGoLJpLIqWNVBLKBwHEfsGkshMqHDmrgF0k SsGksOMnoYwAyigKk3qevnK0yuMkkxSenwYtm3qSO60clBxOLjBqysusu3rHsjJTLN4BozMy koaSSr4cJgzCRLUG7khnRdGt7SFJK/RMzUPSMTq+7zR0eg7UUmsFJxXAUQ1KGNTvGGoYoMG0 Hr7U7XVgnzJVoyNXyPRNcsqy0SODLdfVK1ipVdYcuM+ksbtJZVfWZSdd1u+lY1fYVYqXZgbW xV0Uy2zjPWuglLVG+FyRXS7hNAG6XhhddxtMG0Y1FTsrBy8rjPZYruX1cwZX60wazklivhvD clNPgrSzdGlusi3s9ssqUFYhNlzysGFsTnKslY3cqWSTAVGUIkSevbGmSzBcLOwVAqWOjYsB ZgkUnQeygYXy4yDSlkdTOM1TWUCtTLSzfkk6KGWj0RRSfUrQoVAaIQqAaF4jM6ggqUMr6LKa EGuxIpeloqEAqJWgQqDknKEw6h41qRpbOio8YthQIYpBS4IUCyKAqCeIQsioIophSLoqCUnK cBbhCfBoyO0iIpC4KDuikK62YqDuBu7CoEAkBAIoQdHz3RCHz4QCcEAkhB04ghAJnR9T0IQC uEAp9h2nPdKEApdkJ4QCN2Xfdx1/R9j14hBB4Hfdfz3mdX2ncdGLisIJw3EbYiiEbekKSXgz vI84FHR9wKqhfR0XfdGgiYpiG3scSgicLDGqooeKnJBQGoUioNTVgjFhIG2ZQytypNfVgcps CB2ytncUTlyyIEbNmc251vQMgcAoDeCkGD5Ayh4DgGwMIaQ3AgDCHQmQZQwhzhQHQNAZQQBi hWGkMcJg4BwDkCkFqAYNBhDGGgEAdA3ggDgGGHLAQUB0DmCALgKAYhcBS/EnILTVGjfyA0Fq IECQUAaCgMIbgyRMBQDKKBF4YBuDeHSGELoTgshjCsMsYQ3wlhdDAMgZQzQkDSHQNMcwQBvD NEGF7/X/hUakQZVkVnNgohYGUOEfw4BlDlCePobg5xujrH8MYYw6hyDkGUNwY4YSAhNCWEgb pJFUDeGwNgaQWyEAbIZyZyYIlgXdFyRklSqRfhjDCD8OAyhzDnHGE0SwwggDmHmRobY/yBDK HEOslI5yXlhLJEBKXLAoDvC+T8goYBjjnGoN0SpmzeKoGiEYboSBnBBJ8M4aZGhymNJ+ash2 zHjiyls7LmouzgksGmO8n4wwrBAHUNwa40B3ksC5s0LwQQkDtKsO0xISBwDrCgO4bw5BkDnL Bq5XYBtbli1IFAWKPQBMi1pQysUVPiBQFuk9IKVFIMnAdsz+g00xpTASmj93xIgJjPwFAXZd wlDFKMMQdJ0zEoIGagwY4+TTnLJmf04olSwioZVSIIKsxWclPkuEiouykqpOiPQbp2TunhGq eVDAqBoDrEuPMYJ1yloeG6VAcpVBsle/6kbk1ZS4laHOXU8J2xxDrKKMMQpkUSrrC6w0z5o1 RDcGENkyJlRqDaC6erly2VCCCGatkJpkB1j2GEMQbIYPVKUHOSIYw02WDSHqaQbrWAzjcHOV dF5KxLrIGieFnawNLlxMmZdRZeggDMG+g0YQxB5rtHuSUlKJ2NDYHauspLJBhr7IWQ6Wz9y4 spb6QMmblhyDbSc2dM0BNeIfe1EhnQaoEgaSsFARqdUhpWT5gL+H9RNpiVynhoKQUuDDfmma e73ECwUCBSLZb5kkItA6J0sL4NfvgDcoN8y1YTvsCzAN+m4s7pcGLBFPMGtfwaDggxL2A31i 6DHCzZcMNlBwT3F2HWzYfxDTM35or/RdD1iekWLbiU/n1UGfE12tSLjKCsEGPaeNCSjkEFAa 8iX7BpVulwIAe5Rr81e9eU1m3uivffLJSAbrdytgDMMAcBZFMrgWm8XcD5vgFgnGhD8GyJbF hLHcXQZYzwWCC+CrFd30w9F3EGeM437aWUHEuacU58bKDE6+LtAYU0HX7C979LmhwhorQIKN Gv/o/o+mmQKXZDzxTvOV8yY5dyherERqkxOQzqCgMmUs5FAfDrvV2qKUYiyNrPXcUNTkMN+V OBKwWbYwbSeObU3IYa+UMVnNewcz7DgBnnAZpsq5IXgZGfjdqHxLkzQahAb6FRuilmLERakN 0uvxq/YyOjY5B3RYaY4Qg3yrhVCWp0obKRSioaorxUqu51rBAKoU4A211DMHIN8zJjyNkeG+ SMk7KRui/Yuh1GaNxL2wQxF68MrZ32JuCkTBypthLKd8n+MMK1+VuaOBBAiythS9fDCm8NHb 5S9mZ/WJt8Uz5g1/mTjzPc10Xzd//Odnc8PK2Xn/Ntl6pxEC1IhYOncNzPyzb+sGuI65j1jn zjeo6d6ns3naKzPLu61mDluqsWrO0n0mnnSyHthLl3PHGpe3bMNN1VsHg8t4N6D3bb/eCK96 13ljvmcgaIQyCiA4EXN0chyi4dxO8qZlZLhsjM+veh4+IrjfK23qP9mppuPOvnZuzvomG6t1 DpwSsDLVCXUpLLWXt1K/0EWCvmbNn2J/QbLeVS5OT1jZs9W5pN/7KK6IKQbnfJKQOdiYgS8u 3ZQEE6N1UOhYHKxIdJOyjkDgf4sO1gGd+U5Mk093Ly3qEGKEkRroB0k+DKjcm2hoiADGl4qO lUDaosjUjComDkugDMhWDouEmu3MyWS2Kwlw/0DoDunghguetIk+k4nkDSuqhwDelEmEtyqU Dkj4rQIuj2iAkyDY3cu6r+2miwmuKkqEmChRA0s45wa+IE2eYqLq0WkQV8+0CQ3cDLAaBSXo 1Mus+aksnK4ynWtUBA/Cl0g+rWj+DcDYDyikmtAucygqm1BgtJBMhk/0laDoug+ADEuYh0By iSh0M4fIik+kveIGyAQCbCwoxkr8NAQCq4kQ/qzOBelgN+lunyK6wmf0SIN8lggS7iTEwaQC 02vsoYCCjQjqr1DStUvSr8ioJ6NOq4iqzq+wcqPGkQ/wkWsMjYowhgnQuqsYh84khCng++lY iIiMnIsIDaDqDYqVBqms/skQ84BQlQuYDnC+BSNYBQoYiaCeDEmGiOBuBRFonQham4h0JMBQ hg38MYiOBrG+hOj/AahEhunXDCakrALmcsrAQ2/yDLA2DKlAnMogokooDdAUIuo0o4BcjKCQ kkhgDahOrYnmDKs7BuqAcqkWqO4krqDao0hg89Imm7FulbALAWlKsW96DQnVGIu+XgqDDLAK DZE1G2sMDgDehIhQDbHoDQg2h2g6o4hMhyMnG+ru/9G7GuDeDIsSmJFgqLHYcuX1HmnOiMh8 rYtmmJA+rYDaiW+6h+mKiYKwBkqqhIDrGWhtJEcmBqbmkXBMDwDTIM/E89LLBMonJgnGtujc tYBkkmjA4vKaDJLdI7IWNXDIi7LgDOlBHohotvE0DYt0iDI+nUmgmCuU4smYDIDSDMDNIInG tisuDHAcDgDpK8RBLAlwi+ssmU38m7Dgk9CWDI9yhgk+DCoCIvJk3TJ3IIka9Qu8cuyai6hI BAjuqUDTMIuRAOk/Mik9KEiGkyk+hFI5IOh8DWt8DdIWlwCkCSCgCKCaCII4BwqI89OmKCC2 ByC7B+f+IE68RrFQLAKglwtCtGiLBYiWiaieBTLejG2VI6jEBmjKiNILM9L8jDF/GDGHETFM 8OiuuHNqbtGUrjGbGekwocoqou5M+K64pmUg6Mi6pM8qv2zYfE86jBG6BjDvQczgxEOWa9PE zOD8qxM3EJRGf1Qo5a9gNhQk3Qt+m+lWsGl088sst04QWG/q/mqBJKi6qonClAnJRjKSrOrS DKnenimMtElS40IGBpAmvAwmkXPsuUDSDwjioYCShRFe2svPIqnauZBbPuDotGsZFuovIUr9 DEODSmi6hkDGDWDuiNJshZF6rrA4hcmQjUke0wruj+o2lSsYlAoHAlTXHayYvFQUnUj4ssBA DsssDqDLO8imKy3Mq+i1LCi6CMo1DQDemEDStSl8DwnEsIj8t+39TLOShTNUseiG93BrPBFO +uWJTcBRRoqlSI/IiA4K99VOlQ/GoJFqDIoGuUuZBYDRSiN9B1AsrClxPShQ88nQjBCuj2mR LLP4i+DLGXC/BfT0kyhc/+iIk/M1GMlwuxK5WgkuBAsrJhGazeIspmaEq5UtPGN8a02oiaBo igzSOW8zGMvBNqBRLMh+rqmOmADnMtVDH2j3MpUfUjUnEkSg8S7RVoY2itFWltVsresMozGC jClFBYnTW6k+mgDSm6nQo2hNWJYajmstP9R5YAOCrEbtMtG6BmBQDzMxM9C+j4hq5IDWoZCU DvCYkkBSByg7ADIrMmtgiKjUkFHMj3KLHdYFAKqMjsjnYizeayp4Mo0KgSQIMiKBEwggkXE2 dCDwDDAStUzTEmIfbAzW8TXmgdIbPMlNbWDLLYqU/FSImBXRQMugjvYSDlYXULM0vBYw/vVs qVTihMlY3c3UiGrnZBRmngt7WMr1SBASk/VAjnOalqZ0lxV7b4kDOmItNutRTEIy/HWPOWtI ChSEDSDqDbK9aolwCgCGoZU4hyzezGpE0+IEvgaWOmXo5sCI+o9XDzYsv7Hgi1B1DKy88+ez QezI0iIoJRUui7RLFFM2Jinzew13RW7K3yzXQlIYvBeei6C20wqItYIE5OME+tRVeQ2AytfW BoqIy+pjd82yRqy2ysBgDwN9gHEhbbCDdXbCRIWY0W4elxaJWMuanMuXcfA5BdQWhQ5OWG9N fnQqzU34fJLRUZYdUg+Y2vQ8pkp4M1QkBQCSCtbaysB05PeA0MbKgwNmVfbIpLfpf+fFdsqE C2BgqJeidHf3RAIOOHgADwCCCCBiCICICCBqCK5OMoODeVg5RY3zfqpcC3OsdGy/iIzxf4Ld iOIS13gCByBxiYCMCEKg5OioK/esqy1lfDh224f1fXiFi+8co/jEKyXzjKzPgCCILSCCCECM CMf49Ta7PJitQnjrftO5i8dliK9HjJiSBiCMCCCKUSCEBhjcfrjiaEuIzPfE9fizh412C2Bl jzknjDiNj/iSNYCMBgCKBiCHEA7uxFioTypdlK2K9Vi1lSVhfzjA5bj7kspdgC56CECEO28L eopFjeJKZ3jllHivfHmBlQzOC2BnlZmK2/mPlhmSDwKwNiMsUTinkYytl85dQtm1juODmJj2 gDnDiRnGBsCEBuCCXoByCFk/jhmplEqDmvlNmzjtfVfxklm/j5lfntjMDwVgM2UmBnilkUpF l3kbh1g6VjnffUK7nlkop5j9odkDogKwBsCKCIW7n/mmKDmroHkdo3f9oOpeBrm9nmTzkrnF oeBuKeBwSIBzePosUNoxnXkfi2VZpBldp1pIf1kEO6CKZ1p7pZlCIrmtpjixoNfsBtpvpCpF pHkBqcDxqjlsVYBrqFlypnqLl7qPmFoTi/q9f7p3pKCINCBwCGJ+BxqpoDqtpho1qy3DmDm2 Bvq7qXpFmRofqDn2BoCJlpnTirqNplsFnhptiHrjjHrnrFnxp6w0BsCDr3pc+gUazPhbhe3I vDh/iDiHpxmPsmi7gCK6CCCGLKXdnSY3g2i7tLg7rDfVlXtXsvUto6BRgCBqCMVlmaBuCHpY NONHpe13t1sApFt4peBjnltZiNtduHnICERuVgMttsUapduhmwynftm7t/sNq/pniSBoCECC zXoprRvJulgPbgUCYIxhh8kWrfRkDbImhLFvc5VMhLhJUlpw1UVYT4pduVplponLgy8PrZsl hXPklhX8Vi13e3rSwHRRezr/vnQtfMS3Tc36o7hO1VhneEyqO8ME1LwZuiv3fAp+lxiButuv qZungDkNaQCKM5k9qGAbipbjwXeRxlXttQkXlVutuAR0M3iSByCHk2CLoplw8e67lBFLuczP xfxAzVydxnh/urtXxvsPszteDwXcBkCCCMKjn9yByE11y3yLy/yPYFm5yXvTf7yNpLjYBkCG CMBwCJoq2Ja5ouz3CE55biaW8GgcbsCmCQCCiojd0ggugzhcNiBQCCCY5AjAd7OhOkCJjfk9 hO9hbd0QBBgSgwxa0CuGrEBRv4dv0gipARYRwGuUqe/E/I0MIE40Dm9yuDEDP+q8cmq2qEsM 48m4ofc2mCsIurFvPsjDTzBiocKBT2kcrko1LyRC+1dMoYobILU+hQk/IMDkDWtRCvcEDSDO lMjumPNv0f0ixk+LDFtulxS7VGiKn/VOvK/MsklAlEnLgvH85Lcx21FbR+904v1qsKksjVNU nLGBGEDShDIqhvI0tqvJ21ENFdH4ov4HJtNvMdMhMl3EuYjB18BACChQtVAjT+kylQDv4NIc i7AbwHQSsihAi/1smHbzciJUDCDXHAhRAbcDMejzXK4jP4iDVenC4ssukyjxMiqhColN46hR 5FOB3/a1O/XpRT2JL2bt0uBki9cJXTMZctBd5hKSkmqgkkrWhomOiMh0KhJ1HyuujiilVlQA ckRAYRGRNukz3T3WnL0oBiJEBR7F0yCZ29v4mHXH7nDmDfDVW7LSiOgyDeonKLBzUUm/MuiE DOkmDguAhq/OlADOhcjcDF48nBY/cdMLAODgj3AglYo7UPBwS3T92MnG4tKAthBcoMl+97I5 aJ6AlQmEmDS0hQDnJl9bAOhJcOODQHGxB53UhOmIm3JjUFG5G9HAmMtKtPVEJVJmTE15Mf7g 4P3mu+ODfSg134hhOyhNVVTjAD9HAIuYDYud4rFxOEm921PKCoIAdwaWxQMxachSMRsKDedT cZBAdjKcjmaTebhAbzMICQQRSORiKCtCRkMhQQSYLhAICCcxAbIuZxAYZcczqYzRMzcYTYeR aKS6VCUDSoKgaMBcMRkNBAVIEKIrLjRNBAbjedBAYjKZYwdzecjWZYhDToLBAdDREzKIDTLq sIJsZjMaTGaa4dBSVDVRKMMKbAoIYppazob5mczmZcRZ7TcDpCBuKK4Z7RGY3HYSMcjI6VJp QLqBQgaLyMNxAMaaZgaOBcMBqIL8MRcMhvr9ZrxrJRANhyNhdryobaPp9gLpBsBAawaLaQMB hqKdAxQRq/MxAKRaMhgKDgb8QaTEbDLoaHSKWMhALdluRzTSJR9bz7+DckeDpXIrF8teb35h o9D1N+GT2io97mPi9DohQtC2pmOg6DCMY1v4+DzvS9cBvc+DnQSp7xDCMg0jcmTCwo/0AQxA j3ua+UFDGN42DYtqLDclyNMY8a9Qq/8LwFFTlxYGb5hQqY5pyMyHDGOkaRM2ceQC9kNRY6Cn outcirON8mwtKEMwK6UQIgMIQDMhqEBa2sFjQ8kdxRH0pPjITooIOAwzOGiFqwLYXT4Ls2RP Hsoy/KchjaMI6JxESZDDLcnxTDTuDkxQxjk8CxUbN1BRXIcRDTJaeIing6jK0EdCKKgGoCAN ZW5kc3RyZWFtDWVuZG9iag0yNiAwIG9iag08PA0vUHJvY1NldCBbL1BERiAvVGV4dF0NL0Nv bG9yU3BhY2UgPDwvRGVmYXVsdFJHQiAxIDAgUj4+DS9Gb250IDw8DS9GNSA2IDAgUg0vRjcg NyAwIFINL0Y4IDIyIDAgUg0vRjEyIDkgMCBSDS9GMTYgMTEgMCBSDS9GMTggMjMgMCBSDT4+ DT4+DWVuZG9iag0yOCAwIG9iag08PA0vTGVuZ3RoIDY5MjMNL0ZpbHRlciAvTFpXRGVjb2Rl DT4+DXN0cmVhbQ0KgAwEBnBsCI4NGIgNIggRKhggNUMFw1EB3EAzFw4Gw0EBNEBbLsCMgNOM FFwyGI1GcPgQwk4xHIylggMZtBo0Gw1FwwGI2EAxGQ2F09HIgm04nU8n0wG9DG1FNgNlVCGM 9n45ptEEFRqdDq1AqlPrc3nM7r9Bp1QBpiBpRhEDhAwHMZGY4i9zGgylc2qsuG8oEA0lw0lV jvs7GcyGgxoY1ilRGIwGguGwyu2LxuPuOTyuXxg3GEryGSoY3n2Y0Gizel04yr1qyOTGOmwO uGQ1hORjA5jl5F15pehjMJ33AmlxxgzGut39Bw08oY43uu42Rl28G+118/GHXGnZ3084/WF3 Yi44F2J7Oj73ZutDHPBxgx6UXpo5qvc5PL+3l/IxrijAcISGb7vy0bdo5Ar/Ny0jZp894YI0 7jZNo96YJ9ADYtY87KBmjjRs4y0OhtD7nxEuwZrmGTJROjIcPdFcWtGnQbJgu8XxAuKhO7CC 8Bw2AYKEHAZQVH8gqEHLCxUyi8uepq/xSuaNpk0b7hkmUmQGuzRvQnMjOHLi4rmyMfOa1TIr mHC6xwvLVDMhDIoyHKVhnIYaqKviqvSwiLzu2E9w+ik7N/JzIUDPtCBnRafz2GsiT8oc7Uax ixUIGNJw0GLZJzSNMJ9Q7J0XFKqUmqrJhqG8FKEGknVOidVUixyZU1VFYsEk8TVDWDepdOyl 029M2VwnLc2CnqKWI3Dxz2sVlITQ7GUexSXWLSk+WSwYbooqrkz7XFf2Zb1Brm3lAJdIE63K GlzzndT00ew05RVKV4TFNKMwhLz+NHMkRvenNQLjL0LLmGFlys8tWxxg9oLjKFBvQHDCtHJK sQ7ic0SEjKcQ69cdp3dmPOfGswLlHUNqfOr0Uxkj00hBa83bdL+5leV0TpSOJrUMwVAaIQqA aF4jOyhIqTgoSKJaEGku4nwZLmigqJsgQqDkt6CBQGwUioNQGiLoKBIS6+xhAJa4o6EGBhdb YQNAji+QltiKXiqIp5/oOh6KEGjgbpul6bIoQagie+aon6JPwh41pNqDsipAAWpdTGpDuBot hQIYpBSqoUCyKAqCeIQsioIophSFoapQGIUdOoIZhQEAqhT1/Yib2kS9t3HYBAIvd9jzfahB 4YY9+EAc+N5Hha34QQBSLoqCUgq4cImKV6qIiTNCjnIJMoC7Cpy3MBALjEoT4YqBAJHe+Hvn 2CH9QQCcEAkhB+AghAJn2/mIoQCuCAKb+X2PpfS/0KT7QnggCM+2A8AX8PDf0/gIQIIEwHfw +mCr9H2Oneg9JoZX2+JwMiTOEZYGmHxcK1N7RQG+IAcm218IDQUBUDQGUEAZAyhzDSGcNwIA 3hmBAFIJIUAihNCIC0npAg0hzhuGkOQZQxh0DYHkEAYgwhzDKGSHwbmuNeIFEg9LfHsuSJ2a GFoDYyGhJXDEFEQoiRGfICgMIbotB0hq4M5YLQxBpDoCAMoeA6BlDdDoN8PYfkdCIDQLgKQX PqDeHcFsXQGhUZ81WFyknHviBQGUOwZQ5ApBu6wFhNJChjDYHWQkg4fRAjtDaT6mJNhjkFH2 OYYYph0DSGMEETw5h1DYHSJgYZPxIBrJt570ZJs+jTGZ7saVGRsDoGENcgiFBuDoG8EAYQxh jDeHWa0cQ0SPBBNcmk4Q3xYlGG8OQIA3Bvj7OQMc5p0SSko9OZpLgYF6b45YFEsg5TRDTD0O EwgwhtDLIEOQc5FyjjnHWO4bg6htDFJ6Vcu5ux0iZEuPweJItdmS9pAc+4ZSBjpFkEAZg5Bv DaRecc2CKBcBQGadUfptBooqHQO82KBhylsGwMobCt0BhzQueklSdm3jPC9yrlwUBpBcGWRs rZhqbk3NmJ5PwbECDnIEOAc5GxuiLEeJIIA4SvByCgN7qDbgoDIHWWQc5jvSnrJae0/Ikx6j 4CANEV6bB2lsHWHMcZ20Gh7DmPtKpBSLBdJJvTiG+tRhI2I5yqbIQqczKWU8qa4Ueg+UuELa GlwlsmDZpsKo0n0pFDOO9ZYcyzpMGEOk0QxhrhuG+wM7Y+h5oPOMNET7YTUrLNqXAY5bVFe0 Dd8EmgwhwDgGyXNsA0yFiZIeIwNZRhiDrH2vM3KDRMp5VImgbJz1QeGEmLkHaPzOjXPwOwaQ ykWkPK2k9Pg8Bpj3c4OkVL40PvfNkN0tg83DnHFANAbg0hxsBZtr1cyd2ktTXmnMvotUTBBN 4O8S4bTkivL2g1vLYW8htbC2VtJuYSuM5MlNInMW4irDYNIbayhvk6GSRsQZCxBDTJ2rZHye hdlIG2wkgYtSFrjemfBcrU3yq3bCVFFYjA0oYGahE46cgtpTN6LWIptBriZXvCYZZBXGpjRc Mko47YfrzRp8qWMP3yiyGcMuayV0BwGHINt04gByiWGugIZwQS9DHR3BdRie3JqZW8OYZpfE 0DkHkOE0b/y3lzNm2OW5GhUBSDms4bwyBhipHajWG4chzyDkWudqZ40EijJ4NIerA5KmiHTJ t1AiE6kkuWyJPznA0UI1JqhiKl2qk8GWmVVw7w2l6GfOGO8z3ah7fLRWsqr3Vz/OHE1Hp6zL e5PydpW5C5wnXhTF9zQy5BpNnS5dzbny4ulUGaef4d3/0FR+fANyizQDrVcOc8dyw5lGHeGt VwwykDZc6VOVocxL0hH2vYc6baKDdoHE5Q0nQxcxuyHtGon4IidFnGoQZtzqDJn2lsPt81kl 5LMEAa52h3DZJG9GDHKWpzeGXM0d6J47ifdywmneMRM2LNmX8nr/y4x1S3E9qdqTChsFMJAQ YkX+i1WCI0SKs2Lo9CO0NkkIGEhTr9TZMo2BJiBqOWYaaexU2PNKigY9G6PDeGengcA0aTxi HCT0uNX17i5tioxPHHyXNnsGbnBYl3RDdwiHWS+I7IDqGYM0ucMw12fHeVENtaA16S91yZhe LAoDbDsNEfathp4Li3P8UN83kkQRS4kPfS+nwp5fLMwdTd/tR5w0tS3MSFDKC0O+nqTzeij4 jGsNIbBICaEF+FbcMzYCFT8NnTAWe3ntJcGFyLUhDjnQeXFDI6Nmp4HcMYeg820C2DOUYNMf UaxZNet0NcJ6fhrxOfPYvBQwn5zvlUtdJJdMYu5NRpGgjLsvVpdrWphJ4tqpug2AyLjJlv8I 0J8Jnp+P/A8osK9K+PhuIufiKo+KbJeO8IouSu7u8r3ImLnJpv7IWPdPBsVAUKugyg6gyA3s rKGqVMWq9r2pupPgbAbgUN/u6wFphHUAbKqqpnYAyuOJXwlItKAvrK6JlmjJ+Lug5gws4Jsr svKLhroMbpuJBg6A5K3OfusGvLGmjE4LIOttdGniUuvoZApNiNhvGsFGhAjIQG+j0GlCHw9w 2nBp8w4NtIzr1QYAtgYgunUE1nYAjIhoAj6AYIwIAPVJhgcKquGqbPGNOg5MaH5AkgptMD4w gnZIAgiAyqdgUxLA6NSr0DGAcFIIwHVN7nsq6MjwqKmJDghqVKDA5JZJRgrgUk7I5OHM+pro egiAXAhgXJRggqyvTCrklLFr0IwRXiZRYmoIxHtHBPPgtgZREgWkiKzqwH7LpJ1JcKIgdHnL 0IPiZQ0gGkpjviHgqHso2g0u8H6JrAyu5I+IqAoM9PQujLAs1iEgjKApbQEA4RzJJAWkoFOx rxZntOKp+JDgpPmH+rzJAx9r8gQR/MXo+McrAgiq/JTwvIeqYApDYgYJFrGQ8LPG+iYFcw+R 5oZJGgmIoNpAyyFyYC9CKSHxswKJMqmAnJ3LAs6RdMYLsqKApgxr3PGpRg7A3g2JGjrAbpRg pxnA3NwAUlWgUAWgrAUjHJNg5PpgzvquYu/jxHugUCYRoydEXxrFpRsSZxaivRbnMP0xvxwg UAmpGvouCvqIgpGvuA3PvA0vwItAkJGglvxvyvztLo7vlPmMixXRYS4yIJ+rpQxQyPjHnLOQ 8R2rPidFHi7HsIZAhu3prghMAocyWQ8k4DJjTSZRaLUpRgZKYAYqFxoAbJRrmSpgZJiQzI0C gSYgQSfS5ihqkRuP2RFGoS9y+vpTAApTBPurYzDOpH1TFTGPzA1zFAyg8uSRMTJy3zizLSfm QmjP8tguIPit2ugwrQsMQwtuzriOMJGzWzQSXimzRx5R6AggyK/Q6pqydT9RXzyCJy5Ixsjm pHIwKOxJ+TTtHJrrxAzoqSBn7TUJsM1k8GtzPTXR3kmjszSxRybIowDyhpAqMoeyjg4Skp1y lg0t5gWx4DszjTZvOQYJBRfIASsStQfyuyvywpPSyJRy2TdqyA4SpzgMijb0QG3DJjeGjUEi zRDAay8zmghJGocIeghLbJ1qGgQAgy+pzosPppPKvUwIestLZotsQCtorp3qczxRq0DRZTzC Ur1oZMrqMMnJEz7UOz8E4CmmDii0RT/UAK3pq0L0Iyou40KnzVFO4HyDEk8Hi0OyXIRTRRsU RPqqPAWksCJ0C0antECwYUSNpHaAZKq0Tyi0VKVUWMp0X0cubAQSoSpAQFU0jSrs9SspPStg YSuvrQpwYSvltyxUhxoAZTeUkCrgaVPDhMixqTK0DyIHJmDxDAbUrKz0sIbpqUuKKUv0wgQU uA50yAw0zTBSouDPEOgKZr5LuOYJkTKS4VpzzDut7z0rUrWVyPEQOT2JDIgLq0/QzzPrHIRD PlO1Cz/o51ESjUMUJ1HCUSdWDyezyy5qkqjttqmAit8g3u3UInh0NE6MirO2CipVQTSRs0Ry b0TSiUUxySkVYSmVZSnyozgnU2T06UEK6qmAbgbv1Ud1dytDE0fywJi0hQsUiNNMoUjpGmoA ZgWgZjSVoV5Wc1qUpwXP9KmAtnOHWAb2uAUS8iYAUAkgXVtgiKCgzguCUAaROJGn8IcIdIeO UKAymNyKTqZxMV+wy2R2CR3WqVRS6DIxbgUVDWF1WVIUJVG1JDAUIVI0NEgTW1LiECdSeT+I ZJR1TWWUUUBVOw33K3ACdlYvP0V0WoAWZSnVaWajAjlSrUeVeqqSvWuAaVjWkRoAYVlRpJkJ 6gUDFgbAWi8imy3U53QGDveAUAtgcVsgUTEgQAiA3gxKJp/qAqvohqwwPo7MqQbU9ItLuV9O gPiV4HpW/2K0pV7QYOMCFImMWPC11JCgWqUHOWjLyW+IWW/IXifTSnMAlQe1UAUNIqKzTnOX Z1F2H36XJGWLUX8xRsNLmAywiga3Z3cnpD0COGlw/E7CBDcFUHDHvERxuAcy8jv3lpG3nXoQ Tg3TBTUQLvF0+DJx1JkR2WSjZiMlU3LAUAjU3oAIfqcOmHevEydCdElV506zjkJNDHMO3RUg UUI1+ULPuKJM9AyQsxgCVK0A5MuJwg4YDYZDXCsX8WU1OGvD0DlCZw/AaEYVbjoNfKQSgnx3 Mwm1VWW1Eyj3wgGj0KkYLHCkCjTxXxBJ8DnPP1XylXT0dVaypjQgc3W2g1e0fXYmJ3aSyzdX cVb2nin4JY7Cdw+CBYLqsjAltw4XjjIxEqPQ/Y8lBjaDvzRYOQKNg3mYS3opcYUHepAJBIcI tMnsf3vX0p2J3OCX24fqPIv3yWdqYonryAqg3UWAxODP5JsgxKtqeIopRgnoo3nqKS2NbZSZ M4y49ZOlWrKibZQxEJJZSw+49ZUF2Q4Y/2LwXo2ZXXn5YXp0wA2IgA5sLo6KfImAgg3ZZT74 ZCkk8YbXGzUzVw7WSR3UnjF4bUiKYAZqiVOkWWqyf2Lju3B5sTeJG5s4xZt5TE/CBE3ZQRDx vZyHC6O49jaiMY1p8E1rU534TXpA3RmUxVyKf1zKEzD1xJGx/JBMwVbOqIjv7HFI2Ikx0n8Z oJBAzpWzCItJOqE1+SKXqojWBQ736rP4Z060RYcMdgp4dvgon0B16XiMU2sXjAiuIpX1f4mM b4nKCgxYo4ppQHWJ1YsA34tR1yW4ZTYWERsnMXMWVphqzobVV0U2p69WKV6WLJ72rpNXSWYy m5C3VDdZE2gM+5GVU3Y0gyx3a0i3cQoizXBpQxwDXI459sKg4OfLXvwpuA5OdshVaUzV+NQq /PTAw5lsQg6Z/R3MGCeHuEAKYg6UkIcrYAXA1pfQZpO4UJtAXKJ3I2SkyYE07WsxRuR7Wp1I qbcrPjJ050RAX5lAXghgngpgkghgXgxUx6agygXydCOXAIzgUM9O8A2gyb1VLWSjXEiYK2Ug XSV5tVraTZOlFjXY15QgZ5R6N4v5N5zkIDE51FJWMnMAoYBKzxkpG0AIKJ1N9pwpaPwy+AlJ GxgC9Km6eA5R0goKCOCqf5fPDsiL0ZhbERaMGyggUIsQFKbML3sN0rnT6V1uS28z1wPUvuRt 9onpAsxUJphQQM76p4Y6EEc3LMUWMgUR/WOpGr9obAZPwvmCPRdA3AzQ6JZU2Y6SF7tD66xP AnvbpZBUvPwyjg2pvN18eApxKR+bm2/DOFl1N0wAhgm2kjebO3O87iE72y1CURIiUD0aSb/Z zFB5Oigz9YOZQzl5tZNAQYLjadHcGp88ozpMcMdA6THobZcT3wsuRtlpaA2Azp1ck8l2+6rE yDaWE1DzWXO9XifXiE+o2WG4CXFYnUMXFk8AYc66rGyyZ2VUSqr7B451XUW2JaJbEpNVY3UZ DZKSq2mCLjQ2oCq5FbKpPteWibM1jy2DGMij0dFcE9GCBEsQ/LLRD0q6SdKdLGnjLdM8Ho2q vyQKtvjo79RNRz4AW9SrDOhdUs9I7A2qvwlsE7cSznvYzrUug82pZomSTgjAhpFifjE3bx8K ETCI+uQOjSPrA0uJhMyvNpNSMOiLdyOq/AxoqNMRXxhraAjJ1RgwgUdRms9KgS2DXdyaOdF6 PCfkgaQse935uZTil+g6VCd0Co2dOApd8dPm+d9taijd+s4d/od+ApbeB9Vog+ELDOJlNtDM xp1+IJreJI2+KeLFMCUJR+Tg5eOUwPir2u9ImeRROYwt6QYe3e4eVJteWxUxLIr+Y+ZkCp+1 Z+bxn+dZL9y94ZumxAaiXcBxDgb8DZMfG+jCf/IdM1SPPgppG0gVfgwwaJBNPNMwgJGgnvKo bTCKTT3JfJcO8JPgZQgc3NY11x04k3fnYUI46tsp8D8o2YVqNNaCOUvgpgggjAi9ObsSXiZa s4c6uMpavIbazWPNH4mnzSdYh2dHJjAPPybA67kH/Rg3Z65uHa64tx3Ek6Fc8437BY5Sjdl7 HWZyF/19BZhmqpNdpjrAcdt1eA5CACkYjYUC0rQIYjQUGU5GwwmcWCAYjkcjWInA4C4QDIcD YWjIcjcXCkulQlA0cC4YDUQDCWiCUywZjaXDmYiAqG0GigtjEcF0UlQ1SgXSyXS6bjMbjYQT aizidDCVDUaTg7g0tigsikcDIUSMYCgQFo0GU3RAQEqNFA0mU4HKBQo9Hk1xEwm4yWmNFMym KGCmPwS4DMcig8ikZ16NEggwIbDgUQcbjUUEEmCAuYkYiAwiA3m4yi2SSYGlQVA2pDAaDerT s7mE8iA0GE5mg02fOGwzm85Gk6Gg2iA7740CA7GHemExGwyiDmWff5y8Z46nQ4dWR0IGi8jD EZRKcGbS6fU6rW5Uycc3GMynMQbcQEM5Hk4HQ3mw3mfY5kZZsgjqOYxvm+rMMSGochkoKhu4 gbwCo8QYhqoqQJeKgiJ2iImDKMY6DqOTmicN46Pa943QUBoWwjCYchBFMVpxC6XCoq6siGN4 2uvEY5BAKYxra9YyoiKa3tuM6/hqyCDBSGrKIYhy0ImHIZoujKYBnFLVJGkqTiKKgGpAGYXB yGzvhkGkwhw7wQJ0kAaTEHDWTNNybNYNkvhzNyfBwjYaQkG4cT3OyOJEHIYhnPk/UA50vzhM VDT4GwXBpR9BUaGdFTNSNJ0PSqRUvPdMhdQFA0ZT1MNWlVLo3RoYzVMyRBkpVV0jMcy1RWLW DHRk81dW9ZUrMNC0PV4XVxVcwhtVVQ1HY4XWTUAaUipdD10jlkWUGgZKLMlF2tZ1sW1Tdm2F PltBhOFV15W1zXRaqOzFbkzXZOtShdVt1pVdFBhdT9y2LTFLVPcNH3dU1oW1clO0dYds4Xbt G3JM0whrblKpS/tbYnitGBylV4hpNwZ1/jii0fiVRUVQQcqlaOM5RUiQKkG1ezcGGNpAGOS4 Zmub0KFwb1lOVi2TbsEKLfWQaHTk7zDe8+TRNWVWDj+oO/OwzNOkEJT1PipWZNiK5/XuvZTO 8/bHSVKbNsVbKkjlQbDOmu49Msx3ttGbO/aqnblMzU57juub9uiNopSWP5Zk3DZbuYa1VveO 8ZoWgXokHI4/N1mcte1TwljHCpTvs+2LNW90jp0zc9qO19F1W67PW0JBhxXYT5zNFb32uhXF lWt1PN3ebXwUz5/kc22dXsw8potg6RhFVale1wTF6E721meXX7lWc2np9+bLnCi2xpuiZVmW iZOgel5jSXnTfyocY7il8blSuO3POPiTPmGIfdkT8CUp/WgzlxzMGwvDgI9VrTnFoNkVI1gB oQkvHcNYZtB5RCVkvZyDIyZMCngzM2DZuxLCcmoPAVJQpLw1ooPLBYq4KAqFlBAW89pZkRhk ROC0qTFCWIuBqhRCxOwwh0DoGEMYawQBkDeiQNyIkTs5JsZuH0QEYkqBgodGZOw8hlDoCA36 H4hlmROtogae4posiCCgt8Rg6BpDGGENkOWcpkilASKkQiMBsjdEMNJnw5xjbSUyM6MDURWO /FkFAbwzAgCaEQi0cnqHfkHEFGULwxHVPfF0MaNz2onNSxRFsdo0IXh1FaLELw5RDLKjsMZ+ A5hlOyUNFzeZQoviDKUGDszzgul4C4+BvzmhmOqh4MsT2fkVlrD+UchZcynJ3I0lhtQ3h1DZ Dg7UpSJqHknKSFp54mnOM+kZHZfocteKXMmO4KA0o4OYG2GwZQyS9RO8qSUopCAoDvKs5oYY cvAT/OiZYKJNhsj0HOPobgWofoMHOIobg6TGadNuE0iDZm1BBMI9cbTPnvj+dpZCSKAT3Q+H EOoaUPzxk8m+OpKQZuOkJLiXUiJoAgjeG4EFDA00EpSvKkMlIrQuJ2X4ECAJ4GcPdPw7S2iQ T1lsheRJoAWmvMPNdnIOAYGsolTCQ8L6MIcoORqGMxTtM5BiDcqtWZuyICQE0IIQwQS9o5OV 6VPYqy5qACiJsXT7B1DGWWa0smWKTrpUE2MwAQIfPZQ6YyhUWUSBQXeOAeY2xvjidplkKaJF ZLeQIG8iQzlwSwQsOYc0tGkS6A0gIA1lbmRzdHJlYW0NZW5kb2JqDTI5IDAgb2JqDTw8DS9Q cm9jU2V0IFsvUERGIC9UZXh0XQ0vQ29sb3JTcGFjZSA8PC9EZWZhdWx0UkdCIDEgMCBSPj4N L0ZvbnQgPDwNL0Y3IDcgMCBSDS9GMTIgOSAwIFINL0YxNiAxMSAwIFINPj4NPj4NZW5kb2Jq DTMxIDAgb2JqDTw8DS9MZW5ndGggNTg2OA0vRmlsdGVyIC9MWldEZWNvZGUNPj4Nc3RyZWFt DQqADAQDEQDAXDmCQIlg2CGmCiAlQ81QUXDUQHeBwImiAtl2BGQGjUYDQXDKLDeRiA2yGRyW LDUciA2A0pg2BGebCAjg0Zi4cDYaCCNx2Pg04zaSjKlQ+BQYZDEcjKmCAxyulDMZRUYVIYjI bC4YjaY1YZVitVwcjewWKZA2yjCeja4QO02uYzO33G512v2G726y1mRVyvXa2mIGlGGCCcSK +jUbCAZjkXDSyyqWWoYDYbiAaQYaDUZ23HC4Z5DPDGwDWLTORQYbjccanV62WbDZbSUaPXDC DDMYwQaard6Tfabg56s8G/6/kcKsyaCc7N53LZWvZ4c5QcjPR9fLZExg0aXWg+DszPy2qlVL 0ZHy1+07Pr8ztfLc9cYQTx/GDtyGYcNMGTOvUHL8NnAKwQO7T2KWGa1IQ4TzMlCLkv67aDu9 CqDuS3qDOrDkJBA5zgIJBQYJ/EjjxMyUBKg8TbufFwXBsGagw+FzYwTAUbRxGUdskygZJS3r VJGoLJpLIqWNVBLKBwHEfsGkshMqHDmrgF0kSsGksOMnoYwAyigKk3qevnK0yuMkkxSenwYt m3qSO60clBxOLjBqysusu3rHsjJTLN4BozMykoaSSr4cJgzCRLUG7khnRdGt7SFJK/RMzUPS MTq+7zR0eg7UUmsFJxXAUQ1KGNTvGGoYoMG0Hr7U7XVgnzJVoyNXyPRNcsqy0SODLdfVK1ip VdYcuM+ksbtJZVfWZSdd1u+lY1fYVYqXZgbWxV0Uy2zjPWuglLVG+FyRXS7hNAG6XhhddxtM G0Y1FTsrBy8rjPZYruX1cwZX60wazklivhvDclNPgrSzdGlusi3s9ssqUFYhNlzysGFsTnKs lY3cqWSTAVGUIkSevbGmSzBcLOwVAqWOjYsBZgkUnQeygYXy4yDSlkdTOM1TWUCtTLSzfkk6 KGWj0RRSfUrQoVAaIQqAaF4jM6ggqUMr6LKaEGuxIpeloqEAqJWgQqDknKEw6h41qRpbOio8 YthQIYpBS4IUCyKAqCeIQsioIophSLoqCUnKcBbhCfBoyO0iIpC4KDuikK62YqDuBu7CoEAk BAIoQdHz3RCHz4QCcEAkhB04ghAJnR9T0IQCuEAp9h2nPdKEApdkJ4QCN2Xfdx1/R9j14hBB 4Hfdfz3mdX2ncdGLisIJw3EbYiiEbekKSXgzvI84FHR9wKqhfR0XfdGgiYpiG3scSgicLDGq ooeKnJBQG4UioNQDQitVfmeQtIIFIkWBiRYFqrDOhyDKoV7RBnuECbgQJtsEwQELVgb59Bbj YkugMftHRFkCICgUrAtRFoHNTPISQkyLjYQkXg2WBaCoVQPCEYsnCBCvwvJQVldwIISw0hQ2 WFcOTrwvQCcSGUJgQQ1idEchhGgQHkKku5mhFiVpeMjFiEZbSarBYQyiLR5EVRjhATMmrVGr NYIG2ZQxXSpxyjEcNsrZ3FOTRU5Y1RwTIuafG692IR3lu9ei550BG3pvnCgCAIgIHnOhfiA0 yjXiHqwOU2BA8d20NmPG2lzYKApBTCDDUgQRgwhjDoG+BwZH+v/auWGN7W4pxzIEsEGwOCek WjwC1EDAWzShCCHMEAaZiB3DKGwNgIA1huDeHcNwLAQB0DQGUEAcwyhjDqHINIdA8ggDeGaa c1XeykKoHIPIcJVhzDyHMFsrycwLhA/kBsvktlbk9PVEBWJggNBQHQMobQQBhDcGScc1gyBp DMGYNM2g2TenBOIM0qZVzcDcGegcDiqBsDfNgNk34HBsDDQAMgLp4BUak2mT5YD9z9c63pMQ KA3gpBg+SaobA4TTDlKkNYIA4Byb0DemQZ6gAtLKCgMoc5iBpDcCCicqpWVMoxQAMYaJnUcD PN+gkrnDuJpQ5NSM/Z/hvp8HIN4bQ30AmKG6gEDg5h0rXU6ilUaL0DmIGEEFbgyhhDlVWsob wxTvf8A2r6IExViDZQGaUo3XhEpHXgKc2Ztzdm+HMOAbw3BzlZMSak1p4SxK5HAhiezTv4f1 Yx4Nc6LBnnhAu0kJ55v6CGGgMMygy0XDLZ8I0smtKGJ6+Fszkp7UtkA3Yi83Q0VOqZQQMYab a1lDSHqpIIAxBlqlQMO9fAyBloNKua4dQxzvq7PW38TzVQvnoiC4koQx1JDmGYOsy6n0VDKH IOdJrBpQltJlgku2zNonuVKQAKAk1NCDT8NMy5wzjmMCAPNew5TllKqwGE0q8BuDqG26uEcF 4UBBdu5tgn/1fuHcQ8dw0N4DDbc+hIZ5uzEDZMakldqfV8rhguzuEpHWPdvZKblEJUXhpPSm fKIC2YDorde2dtbE24mldmYl85WXcBAHUOd18chntvfW2t0buZDn1PeP+J594ClDhjDV9blT JoNlcModgygukdQGzFb6dh0yxbSuAaQ20/DfnANttw6BzzBSpy6zskVkyzluneMbpUGzRhvN YbM2hpzfNYMdmM8YYDLNKzuhTVx/vZWcOAdQ6UjDTZi54ZaFysrhA4OIdQ0ytmnWTKWEbGSm mLoSwdhViVigdZcOWM7vXVryG8OoZw0UfnAG6a1AK2XJxxnqvIZdY6zyoGaVmhaxY5onWjK1 cqoTcD1qizFEaDzXxXbbXEpIFtLI4DELt+H/yYa/JhYINKwx4n23OUIVJyYQxjmrW90dzVNw XrkrpMcrZUrwHavlzq2agN8THAe05raxDCGTO9DZr6WzhQOgs19FBowbSKgFb9xZJ3LnizHF H73FBRpkN1DKit7DbZzam2sI5wqKDkFE36RVAOGCjLRjNGW1BbqUOVl5scr22Z8FF4ns4kvV maf3BuXWZ09OTLWztG5e0hhnSVDM2cf0vrvdPStQQJ6x0aqM1KBYLqqG+hucShUEm+HAMobw 4WJIvfWa1TA7BvDZnCg1TOKb7lDt61XWtU8InFwoGeFaD6zKppqbgYtTeRrttzAewdXZUu94 7cd16q5Mtv0fBoYco+Go4HcOYOrdAxKDb2ShUyYrYWnf98fNA6eb87y+oxrAaAo1vfWScsTI +4ic1+JwNYUmSWZLwleJesN2BkgJCAJQUgtMsSgFAQg5XgmsESmdRvjhks0G6SZAp5b6a1cK 9TWnN/aUgDf734ECU1CgDKradgzkCa00DOrOvqq0oKkmLUNONG/i32ck6urECa4iDUmsCKDY DWtuDEp2qqDoBaCQ1kD0qktbAYNEvMMrAgcmvWfGKgLABi/2/CpqCCDlAsqaCWzkCYtuzsDC km18N8NG5kTELA/0+/BkBQCvCS8yrY+Eoq0IvGsKpcfIM8XnBi/6BRAoDorglQrYtzCgakxK /sfGfYRqBtCs/ECgDCvidgDKDypFAVC+Jy5lDIMhDOpqscDa4kdqBSLkqQ0kq2IgDe+UqMBm 6MBAC0DCweqAvG3skuluKkKu98vUbmpWTE1En8CCrgp+qS0Emk20m2x00ivqyirMoExyqixc Dctqng/gvOl5AiyK1CrE9StstwJkxkBAto5Cuqtu6g1pEAxymc1ODEsS7aYIrE4K5a884S3c 4WBAC4n+nJFQuWmWtRFoxEsIpSS2O6sQ9Wms9cw+qSDG82yoDEm/Ao2GqYJ0u07AriCmua0E oUoa4oQgrECC0Cm4DGoII4BkC6C4BTFzHAtqs0uoDLF6qYDGDYDqu2oM548yz6sSoBGxB+Bp CCzOvczk4A0wswvanU3QrwCaCSCgCmBawer47UnC2gyqmwoNIEzBDCnyxRIsn80C9cm2ms7o 1I1M4O1W1a2G5E8SmIu2oY2dJa50ty16yIcsvUcqzO7IzUwW78y462mI0zIhAAypHUrxJMwj HMoHIfInG0N8l4lC1LADH0DgDDGJJwnFKk46rqpG2amtDymVGW7446zq4pBYBRHUr2r8mw5o pLFYieMEuCcmXEwGCu5M8Axy44DCxWzwDGp8vq54xWDcva3Q0W7Ay60fMGnlCDAiVNJmBRFE wi7M0o7Q5CgcDMsSlVKyqas66eoYDPJuqWmImdLDBWczEqiCyRLUsSmkDmvAuTLvMquYmsto mJF4qaoJMiDTLSxm549q9utEJia+Ji+2Isly+m34nybtNK++RuUSBQrQ2i++KeXpCxJFJJK4 0I/ALCBsBQtrAMx+DQDa+Wt2+atE+eIeidOybAJgk5BXDEbs4UN9POM/BmwQmWKgIRPCO6Bq f2++JgK6BQ41MdMjNTC8ezFaIq3gnpQLGaVhQQN8BQwOm5QYO2BlPCLE6AXdQmKAqFQu47Mk zczhB9KU/ulFGaSJPO+lPiCUDq2cLoO7PCMg+Ol0BhQmUSBjQsDq43RpQ1RxQHCk4UaXRJQV RRSIBpPCTEpqNfSUBaVeBvPjRm1RRq5BQ2q8alRCwm8rSxRNQXSIfgBaRuY2BQNfPOQCBk6M 6S0cypNK0m0q0ukmgCJ4SkIOVkIHUQTwKkJWQCT2ByBwayUYIPUmLbUgLASjUWYPU2JmQgQE IQNGTjU6YLVAQ7VHUmMqVZUwNkNNU2TiaLVZU/VcQCNnViJ9U8J5VrVgSiS2QCQqRejkTiQE LKZcg+QOK5V9WMKpV2T2ODWVWLHrVoTpVZWIWbWOJIRtVvVUSiQSBvW1WBVxTINGPGQhXDW4 l3UVWoRrXEl1VWTtXBVRUWJ6RTWPWfWHXfXtWaQgQjUUTjXrUvVpWFWVYDWO+5V6ZRU3VPVt XpXhX5V5XTXnYHXnYBYnV3VDWtUQMgU2QgSHXyJJY5UwBwyNWUtJWnUOIMVfVSJJW9ZGNUcf WVZbV0iWRrXyT2M3Y6BwMFY1ZxXXUOiBHqTiT2K8UIQCl3UvaGJKRtZGTbZAThZ0TpX/UYjk JmDMakQCL7V6SdU3UeJ+R1Xza5VNa+UjWVZhVnUOYPbCJLYXa/UlUoSPUUQCLVWhUXbiWRUO O5aSTwXDY6ByINWJbtb6SENBanbOTtb+MrcMIrWBXNcTZjUWT2YQZgMncLZNVySfcBV6h6jk QDb1Upc5bxbnBfWVdDZGPlb3dNazbBdKS3VZdXbLcjcxX5bJZvYfU/a/cDaUOHaNdzV6JJcn ZGT2BtafeDdwTpb2TRWBeOVNYkO7bGLjafYbdwiBaYTiJJenaBcZW4TbaZdwNUXpZYLXd7Zh eTUtcpZIIramTRYFZSS3b2JJIrVNVdbfYcO9coBuMoNlW4MFeXbTU1f5e3dPgBcFZdasakjY +Ylmjia+gsIEh4RIJRQEuGOSwGs00Cmmz47wCfMvG+DODDHUm6muvqzgruqWmUys+C4OnHLj B6sHQ6vRNCJGczR0VeBkBaDFhEtQrRS6BQDIvi3DGgDu5Mr85OvdhYqaLCI+myDS6pTWzCK3 Jmbs3Ww+DSxc0GriyaDOmpH+KpH22NOaobOepG9IrInCBSqODMzUxWqAQg6nSngo38n9FSuf MAsmogC2Bm3mdWoLIMDIsWnMCZLUlYpGqiqSeqhem0Dkgc4nKScm302AmyrO0CoLhWmpLixz DyDcz4wyJk9Wmo3QsY4ogTClh4qNT5h/IUmIDmDQ2RNQ2NTINnhzixGglYJU22gXSa2etoqa LfHCxDSml/NHioxaxfi6+AqYDqumu8nDjUwi4avtK+DuDSu2JUr5FSojL1jkBQDmDDjUogDD g+qY5VkVkYrg4KrqqoqsDS1iqSzkCEm+ytBJkdgphon89M5ZhXGZTcIFIEw+x4suqYDoye0w oJm1FiTFLIn8qSzxMhl3LjnK0EmmmznXnamPlcoM1g1ko1hcxHKVEqNDCkxjC08AsSqViQIG BSqFSUvGbCa+bCNOOEPLQEBQBwnhEbgcMkBqPONDQEuNJDJHJKwgs41stVK/ljhwm6kmcYVw nlhjSo5lh2/SSJh9iAvukmVuITEciFTIXGcywBX3MTMXG/nO1m5Uyu2UrgxzmQwwuvGTn0DN GNoVL5Mugc9cqk2Y6G6PNKmJDzrThGoCIulYm5gvKRo8cmO3GRlsxzjsx+m/n266wawbGE3T H06fiGtu8W4s8anIz4z80A0Eruo1A4De422ZHUxjSHmnlA6+y4DZJfKZJizKrEDKDw74lU4O vubM4CDwvbFrE1MolZMtMw4w6QDdNy0NcAQJto7C0eBBUDNPUG5DHUmo5PjI5VrfuQVNKbnu 89tJtMm+5o5s5yrKu4obKouo9cyo3O4E0sqBnovVN3ign4wHrfvRGAnJvtGW8nGa8qMYDThK 9BEq0QlCwergrQo0qZOM62uPlBiGoauSu9H0xjA5jIoPtgnvrnsasoojmdHLASmLKvko1PwZ n2zkyDu09tQIrGtXCW03mVqJILLlMypnPiDJETkQBrjRPjOVoYmuDpIW0sq46rDBAkwHHGnS 1PFUo/Qyz9LW5y3oimSq3vgfq6YCT2+scuNYrFI02q42zVoE8ErfNflvwS5ruFhXkG1M4owF N5rm6cyvLXF8yxkY/Y7VNWvq1ou8CCoKgcDvwFMPikBQCeDIo+D0DWDfxzpVQjtFMi8BPxWG tEM1q1RABRy6CM1Mm2BS6BLZj4oAy0wiyDny630hP0lpqYpbqdFfigLmwHjzj3AJzNwXGXNg nItR1EroowyWDZu1hnoRN6lDi1oKqa2MsA1OqZw/hGoKuuCKBaxWwS1q9qtClpCics5mtpFq y0BbwUDeCAvsDCBdKs9r1MUNVCKWfEBRyiauazOqbLypq4+bGOjwlE1Y8Fg614lhPzgWAbP4 IFP9q69tyxEknvEofGC2BSBwBQBj4QBQC6+/Z3T4CIzlEyDXnGmkCazkCOp3riYC+QmkCCBd BxDYszhVKABACh4RPiBcCHBzDbDfMFEZVyKlAe/nDlEqUawHy6xWxdMkDulZzsr4msDnnbMe mM2kqUoUp2y0zkwKBB2l33BdEstNEwDI4h3utb6jq75pMMRATxClHUCG5upryS8MDeqzGees kgyulTjb4TyT7QJMXz1L6gOWTyfEbsmlLSy0mJaKqMNimkCmwQtwqBZ3jevG3fBeNn62vSnv xWCt0WqQDkpEDOmlQaT3qXa55nZhBUsNzacv2B4Mb1ELRWVZ4b4epj4wCOr4++6ADI7ABSJh 3S7ys7Mgoaufg+0Dt10h2mjiK/Rj6mbtHeDT4nHx4R4SpMvHgU9xfijl3R4+2ThT6wMp6l8X FhKX8arEKh7+xr72IGSI3eJJ6x5lBQ/l64S2Bu+yBR1f4eaXRMzl0J0N0RIzvz0yo0wXzD1B znGUswzl9332BkIAMRcNxgNhAMBAVCIDRQQzkeTgdDeLRSVDUDRaMRyLhwMhoIIyLhoNxjCY WKCEeToZTnFYuLyMMYNJSoZgaMhcMBqOYPJowMJyMJod4YLBAdjebBcMaMbjeLhlRjgYTPLB ANYzOJcDZgNxBNJsOJyNZ7AhkN7JYrINRkMhAMxyNRdZCobQbCJLQBzeRAa7vQaHDCuaDSbD KIDoaDLW6BHrdIbZPIVDDIcjCbTCdDSY8ZUBpj4FkZ9QBgMLcVKIWxQcDKchSLRqNhQZjfrh iMhRmDcY8ObzMKS6VCVf8dINCMslCxbpNNCaIKMTh6qbtaYTYaT0ZTJneLkORo6Dp+ebjqbT FrRAZjSZTZ24txM/xrn38mKDn6zthzkZTNhjGlb3Iuxr4u85KfsA5yGDSNzEMUObDvUM46v2 lr3wG0D5wM5jAhQNI5hApw6DCMTDKMOY6jGNDuQI48DNU1jXNg2TaNsGbcjC3bFuC4cLvk0T 6jQMMPvOMo3RXDEfuU5gZwSFEcM0MY0qnAD0trI8fPohbmPEhg5jeNrDs1MAXK2IoqJuG6DB tNKBrIuwazgEE1htNoQDYBopga+IZzhOq7Bkti3z6tE7TwBqAg1lbmRzdHJlYW0NZW5kb2Jq DTMyIDAgb2JqDTw8DS9Qcm9jU2V0IFsvUERGIC9UZXh0XQ0vQ29sb3JTcGFjZSA8PC9EZWZh dWx0UkdCIDEgMCBSPj4NL0ZvbnQgPDwNL0Y3IDcgMCBSDS9GMTIgOSAwIFINL0YxNCAxMCAw IFINL0YxNiAxMSAwIFINPj4NPj4NZW5kb2JqDTM2IDAgb2JqDTw8DS9MZW5ndGggNjM0Nw0v RmlsdGVyIC9MWldEZWNvZGUNPj4Nc3RyZWFtDQqADAQGcGwIjg0YiA0iCBEqGCA1QwXDUQHc QDMXDgbDQQE0QFsuwIyA04wUXDIYjUZw+BDCTjEcjKWCAxm0GjQbDUXDAYjYQDEZDYXT0ciC bTidTyfTAb0MbUU2A2VUIYz2fjmm0QQVGp0OrUCqU+tzeczuv0GnVAGmIGlGEQOEDAcxkZji L3MaDKVzaqy4bygQDSXDSVWO+zsZzIaDGhjWKVEYjAaC4bDK7YvG4+45PK5fGDcYSvIZKhje fZjQaLN6XTjKvWrI5MY6bA64ZDWE5GMDmOXkXXml6GMwnfcCaXHGDMa63f0HDTyhjje67jZG Xbwb7XXz8YdcadnfTzj9YXdiLjgXYns6Pvdm60Mc8HGDHpRemjmq9zk8v7eX8jGuKMBwhIZv u/LRt2jkCv83LSNmnz3hgjTuNk2j3pgn0ANi1jzsoGaONGzjLQ6G0PufES7BmuYZMlE6Mhw9 0Vxa0adBsmC7xfEC4qE7sILwHDYBgoQcBlBUfyCoQcsLFTKLy56mr/FK5o2mTRvuGSZSZAa7 NG9CcyM4cuLiubIx85rVMiuYcLrHC8tUMyEMijIcpWGchhqoq+Kq9LCIvO7YT3D6KTs38nMh QM+0IGdFp/PYayJPyhztRrGLFQgY0nDQYtknNI0wn1DsnRcUqpSaqsmGobwUoQaSdU6J1VSL HJlTVUViwSTxNUNYN6l07KXTb0zZXCctzYKeopYjcPHPaxWUhNDsZR7FJdYtKT5ZLBhuiiqu TPtcV/ZlvUGubeUAl0gTrcoaXPOd1PTR7DTlFUpXhMU0ozCEvP40cyRG96c1AuMvQsuYYWXK zy1bHGD2guMoUG9AcMK0ckqxDuJzRISMpxDr1x2nd2Y858azAuUdQ2p86vRTGSPTSEFrzdt0 v7mV5XROlI4mtQzBUBohCoBoXiM7KEipOChIoloQaS7ifBkuaKComyBCoOS3oIFAcBSKg1Aa IugoEhLr7GEAlrijoQYGF1thA0COL5CW2IpeKoinn+g6HooQaOBum6XpsihBqCJ75qifok/C HjWk2oOyKkABal1MakO4Gi2FAhikFKqhQLIoCoJ4hCyKgiimFIWhqlAYhR06ghmFAQCqFPX9 iJvaRL23cdgEAi932PN9qEHhhj34QBz43keEG3jBAFIuioJSCrhwiYpXqoiJM0KOcgkygLsK nLcwEAuMShPhioEAkd74e+fYIf1BAJwQCSEH4CCEAmfb+YihAK4IApv5fY+l9L/QpPtCeCAI z7YDwBfw8N/T+AhAggTAd/D6YKv0fY6d6D0mhrcb4nAyJM4RlMaYfFwrU3pvdckTs8T4QGgo CgGgNIbA2BpDgCAKQbwzhhDuGEPLXGvNDK/CEBp6GlEPiQT8G5KwbJrhS4eGAKAiBlDgGEOQ dA2hlDcHQEAbwzP2DeG0OAdQ6BlDlAAMYaYuBjDLEIBprmDlFBatJqDfHskuO60ZywKAihuD OGkNwZY0SCDO/R+oQg6w1DJIaOELY5ggjqROO4VHsgoCqG4NIdo0BzDSHQPMX4whDDDDcMwb w5SaDDHByZ9JJR2KLJaFcfQiBhDsGkOYLH7P4SUjYnwVQphBjhCNpcJTnI2iXCqPSE4YOYCu CkGoMAUSfDQCANYZQ8hzlERAOoc4vHLBaGKT8uQQB0DQGUEAc5uxuDgHQNM4obygm2ER0zz3 ovTkmSuWTk0hN8j6HQN4IAyh4DQGGbs7pOTWmxOkMsWAxzVoLNoMUhA3AgDCTQN4bo3SpnTI KN0cAqM+j022Kc5p0RrDhOeNMP5tBmDSHKbxRgwhknRGUMUNwxgufkG8i1F5PRkDZOigYLaQ UiLNP6GMZw3SeozPN00ugxylqCGQEE9AphYl1REEFE4uTpDRTyitAKtxva6A2kIDZIMHb45G PSjIpy3iyHWqUoQ0htDaHWQc5aA0DoLQeTc6JryhDnQ0OVD6dBUhpNoNwb4z1FhWgByZiakA opoHMMYcp3hlm1SaqrpgsUYqWHQOQdQxzuqaGEN1VLOWDqXOiQVjpIAzj5DEO8NKHkKi9LgE FWquUVDgHIN8nKKhzDfXgMlh5z2gm9aO0oaaM2Oj0XKydugyB1nRWKHdFQpV/piFsGgXZdW1 hra4Ok2riXGkGHObVvw3xgIUHO6Fk7q3XoCEoN86Alw1DTaii1qSjTZDKGyMIWwZhdBdHBvT iG+tRhI2I5wNAcTJapC62brbRRcDPSaTUgLOunrLEQpcRk5NlbFg40624o1ouiT6FlbZ9S0s 0HCT9royBys1J6hONp1BsvLF+sNyZGhmDNGiLk7pS39qpDcN1RKy1narZAnYOZYx9sITQOQe Z22olLNm3V7qrS6s5RkNkobfhhubVENlFg6B0zMGu6ELmpZQNm5WGNlbL2ZtVQEMgYYzggxs G0MMgptV8oNN6v9CrBWEsNfF7tI8WR9sRScN9Mb3Tmt1nzNgYw10KitNoM4b5DAgDJWCnQSa KkwTpm8qpMpmgomeniacXI0Agt+6g2YKLghpppVSi9UQ5OcBkCgMoZg65ps1O7QGfbxW3DnV 8O4ZQyT2elWetM+q2GI1ZP+gsXpTxpBIQkNsNYb1NozpLYtVAxSLDZryiuGJBTo2WGgFmjMo GhxfDGQNwqLUdkBUF52HwjF2aMnAnR0iZPYhi+UxeCAjRFb6r475D5ZOYDgGzQMXaBh0qhDi lTtHWRnDwHTaTQuA4KTgehcPCAUPlRtwzhycCXOO4k9l8cV6XzQBqCiqFxd15+DLUSDtaFgs TITPmPD3tHwxDHcHWdnLAkKoqGEMVxYvEYIpQMOAZbS7Qt3cWmBHwa4GfpyLJtRiq73BQHfn lVLBhlDbOXbeHbwznorN3rkgrcTaDbpOLwY5u5Ma9k4oe2XLgooBoDX5QAUSh0AG6QevyN86 t2GGbUpdfgtQLsKmcoaJ9Li3vsOWfKVUy1/E0FHQJ7+CU32iQIbsj0P1BG4EG3SjSEndhzz0 W7C37zTnvNmtLMB2zNEHssMcbBxkXn/Ioc8D1lmIQ+YyEGNtSwmwdx74gUBB6jmv0NzaEw/l DWLpniec+enRVZ8pt3aA5BReadcVp3Twk/EHoPgkJZTqTQHp9g6HTVt0rE3SkY32kGIspuDe 00Jo441m6olEzej2rWe8pI+wy+K2oaluw4lK3Kw6/SBqBS8im0kEjO8S2C9czSuWdQLqBQtI DoDq8SBu2Ep0CekG5GydAgcmBqe4j6pm+Ei6DCDOnQ0qsSosDgvYzM/8s27ik+Jov4t+s0jQ k41UKspKuS8onU9Co0nQomkGpcx63iw68m084u64/Gtgj0Nmsms4DysI+YBA+0sY9HB2tQzZ B+ve7gz4twoshsp4m1A0oA1VAk3w4u2IhslC7c4qDfEKDwlw9ukOqs8mDkDIh+xsyQnSjADo 8ArMZ8kgRu1bEkdQBtBggUkErmc4NC8k0ADW1CovAIq2DZAO02pQ9HC8/+DfBoqMBgBufAj6 omBA7sqo7wm8tQz3EgIqiBBA70lQnRB+8eyPGEKNGTAcT6im6WtStI0OrEy0zGk9CQv4881C DqhyDumooEi6pewC+I8DFucE0aNKzocxFYqsnC8o6472c4Bwsos0m2De6y9CtMoq9oDm6yjW pcDHFssexUwoqQcwhoDO46Rs9OqCk4zSzYDmDW/ctu8pHIsuyxH8wO6CxGwaJ+OcUwKa+pIR AexaMQ7Q0jGepi2ehsBaDWsWDuuGDqDPB+0MqarEuWwww0w63oe0Bg8Immm0/SBktEhw38y+ /SJXA0k4pgucorCCt0om1CpopckG3RHQ5Ib2b6lcmK4EOcVVJMaq0guSCm61Ba/mqcqu5cJk 4GiOcKaWiWLAeOJdLIUlByhihm3Ehwh0h4h8iBDqv5CrEXDk+AjAxulQzUdkfglqlvDYCQt0 xtEwIEkmQe6PDM6S/a0UohIylO78sGqoqam7FVGfEmzKzOyOvY+Epu5+sG78swnkDCDhEw9U QksnCKturFI2nah49CpSDSDHMQoA6W96s0DSDO6iv9Gyy5MipOv4onDLITGmoy0yjO14i8uA h6/ACADG+YtIz3MgBc2gDq+aa8bAjiIqbVLqQ2IoJsUWOCVQLGbuaA5I5eLiKHJCTsIEKeaa hUj8noBnLc5Mb8ImiTP6cKLq6shPPnQAzc4BPxLuRM4QlaaMQABQMZQJLgOuJi5mhjQgiG4a xC4eInQo6OBQNdQ2iNQ64PRRRDPvRI5hRMI45VQG+ccnJCMXLuhPP+Js5WBRRXRKRUJ85UDw 5dRkJMVbSLMzBsJ3EA5WBSBAB7J/QjLeiMaTQQaYcKMJPmKfQdR/RgxBQLQnRrRRRua9JAmK IEJwWlR6xScwC4iod8jrFAg4nuiJSub7SyJmaawgJ0IoZUxSBRTFRHTJSeKWVyaMku/SBglY N+XikmL1UWhiBklYJ/SecekueLRxP1TWMCTocLP8xSkgSce7TiiodQLyj8dQNwda5HTzQLT4 cAcKNwJ9S/UHULQlRpQ/QymHRzU+dUI5VHJNSBSFRmQ+OzSNSRUPSXQ+ye4SBSC5WkBSuQz4 keNmMQlePTMyJ2QGumnI6coW9oCLQFDqP44Y4ExEO8bKlk5WKCBpWZQ4ImT64QfGJXSoJ6Ls nEvKl1Gc3K5GjqMZT/W2n0jyJ2RKsmjbAU6+ouI2nDCVANAQDFEKo1YZG+tTAXBm+Kuilizl EAcwnBX4nSDqDEsDA8/Yl0ppFikKw4uM1mp860oyDIzA7pINWgj0TxYVYspTZakPZejSou0t Egp1TlJYxs8pJ0uTNhZnOnKFF08Km8itDqno1tBfTug84bT0aRQPT7S4+maYMtVzXlRZURUx UnRRUbUeJUI5UktlRRUsrKbFUzRRU5TTWA+hTYJSaYtlTgdjGcsWi9aqMTVe6DVjLhVmIfT8 KfVEcJWLV1SSWqPy5VbjbvU9byMCBuOyRLTchUfGt09pHi88iu/ihq9QelYEImPq6Mn2J2Bk +uhi/mB0oYi9WOjiPLWVRQCW3/RFV2N5XakuB7dtLuN5Q+fGDWBdeQzdcNUNLgNtc1eMdirF FQnRXKCLQHeYKBVla7VoWScUl9UHd3bJK9bwxLVBc2Ppb9SpaqjrHvaxPva3QMMda8boNuaY J7bHQjSTTVcwdUKKmRb8wOBaO+djaOobdO6EKEiaJXdZYOMldg/aqa9pNKw5EcnMxsuurrHy 0EjOpmm2Do7VDqpNacNDAgti7QoHEWjbCAjDKMi2DLEukEBapMBa3CDIDIqDKYzU0zIsx81E uLNdhJQuhiqsBdWnV/P2BsIEMdQYhUrSxZQxJYvZNc7fHEnMnKsw4q/OdNhFCSty70tImqDn Fc2e1/Y5ScNjDQoKorEcnGwCDM/SBiuBJsDQzG33aGtVaW6y2gp0CvZtY4LM1ZY+zoBRZYjT YlFgoKkE1DesBnZqt1jGp41HJoIq3FKAj0I2snAPNi6hEfEiiwnRTkDK30DSjDD6sxHzN4jG 6yqWz4rJHSe0MKinismqpmkbH8yOoLEhEkDLWmosm1JezTIzGBEtl41KDdAcPzHYzmsm8asE k+rlH9XCnOsG1ojQ268a9llYlKndHzlBKBBU9cDGnYzZNdPOnwNcxZgckrLMyIvfZqi5X8BA kG649oovdsUCiTXcoeoahzfGTgNcOVV6/Ar0nSwukAw1WwIwOzgae9desnEdB84upisCBa/4 sLlqzWzal0kEDU61EYoE5C9C0Q1VZ01bX5mAmpAYrqiuuaw4s5kM1smlA4BSL+/aBSmk6hBE 1sBoBRBLoM1+TtBUDHgQ9VoepLBaDKp0CEzbk6JgOkl0uyh0u476DC8/HBkriuDUoO0Yj6nV Iw3a5Ci4qZKkjDiK7HDqzQqmw6CxnOwTLgwZU/P4Ptc6+qhfnbrYjEtCuZH9n+bRrliUIuUe xTLLiIs9DrKu3fK0jgiXLnQUbaUWNdJMcwqtFKBQCxVha1QLUAJns5SJQUBnR5Qfr9LvXrRR rds1XmTtTNXdchUPBxn1gdeKe7QztRe1XmByuk5VtdXnthV7crLjS0iWMWQgMTUHTleGXgev RRSPf1WaBveBIOrSwrl9SpnwN/uhV7t5bKO/ujRTd45JXVRKNBSZXcfKYPtIbYU65VSrd7fj s4aXs4O/R4UXtFTDr9saiVS4ibtBskcM4TSDStWbe1t3vSMXRdXcITXTUONNti4TtDA7wFXn wbQ/unBssmBBubd7cibYn7QrAhSjnO+ffNrntDR8e1uzmXSgsRDulxnkqss+6fnwL9wcBQCX vTdzXdeFwlbLxykvu3RLxrttfiV9xryBRnxrQ1x5RKKLwLudt7t+uVEXD4DNWwMmjoOTSbtp XQ4BvEhEXhV6BXvTfnQrW86SfHkzszy8IQMpxrzFyfbLzI6PzQI5XyPrpQowxqlw1DgukI1F lKyGxsi7YCNlYLW6ZaimnVZMmwDndmovKNEcsDh1dsRXyNwNxrnlKNCaBavEqU1D0kMSJXxn cvtb0vV6Bi3mrKBaRYJOIpoauiwrGd0eMSBkDg7504hp08w51AL1vBcOxEMZwRx/1NcpnPdS U71WMo6OkgMA1aCoc41vFrpyja8g8Wna32i2vVB9CzFdAQ2eBACwCfBQ5ygPCVloedezfjWy bbydw3WbySl1sr1VfSJl1fddzO2Eo01/df2si9aB3RTxtSiMJ0SVu12Jzm8lJ93Dp4BQgP3P sztuiMKb2FRB4PXcNcb4DQm67g3glRRgjqMmrV3sYbIU8MoDxhI08SdhI52wxv23FbFfDrq2 pjhAoD4X1XHuCkvg/rE0ujkFJOskim73EmnMv4s47UDk02rFEd2p5Yov2yDn5fkRnPMtnTy0 zlBwsnJZqsDCD1z4hpAw6mjNry/+7ipNmr5rUvob2Ytmcx3CgPH2jQz5Kim08uJR3ypojTph YYKNjDAqvVZIssitqL56hdih6BKG/i38rForovIxo001mP44oY+QwCIq3g3EBA+QtRNtFvKF jRSgncDMlD5mi82d77N2uT0hsPKQ01h1aREIq2DqmznPBrHYND7aBQCRnd2+7UDdpoc6i8tE BTtC8XoLpYiwdQag8Mv6roi6kXH9l/oL4h3ULxxqtrK3THLgjr+t0NdaO75+cnSh5R6RIsl0 oHnJoKnVJu2PDt+EuT02yRkuyi7R1sm91wxmw2kPepDwyDIIDqIAbDoIDMbzkIDoaDKIDCdD oYTGazLBzobxSVDUDSoKgaMBcMBwNBAVDuDRQczSbjObIWbzrAzKdjKbhAbzdCzsYTYaTIII vGReRhwIBjIzMDRjHhuNRAMJGRJMXBmNBjPwbQRiMqJRo6LhnTKcVKgKDxVhsLrBTRBZ6YNB vbBAOBnaJGbZMaatWBtWypR6Taqdf7dQxwNboVLsWxQLBARCKKRaMxwKCmKS6VCVVyNWb5R7 hTqdcBqMBncbnTMRJjXec3e6LfaRoLVf9GN7jhtRdhQXBRrM5r6PHpFYbHZYwDc/atEMbhcs Purxx71ndjgKJThqMRxdMLz6iKdZQ+BXa/arFURmNqr0tb1I95eIDcUIDgYTTBzvCjdlswDR a5i0KY/6vKe/yPBgGS9pIkyEoWhqHoiiYQDalw3DoOaGBAMY0DeOaZhaOA2PtCwyjwgcHogN aEDeEAzjKOirI2kw2jCNw8p89jxK4GQXBotLzt2qb1qAzatPG98frGKCzLo2S4BmHLThAGob u8FA1N81yuL+2S/yg3Ephy7wWwPBCRpKxTGMcyr/smLD+MyrEjK45LQroGkErpKkrCXLLqS4 2anBoGceKYGsxNyqLevY36uOE80lSYtM7LbPEpyrRMrz88dAMDQQaJFQ8rC48Ecvcr0kvQ9V N0dVFIJM+j7DkOYXNY2zxu2GC0hiFwZKWuM9Sk9Tt0SwKmhcHKiqcNaOzOkwghAlA2xCMqrQ GG8fBBAYahkHMCzK16ShREo6JmlCbJqMyrV5XVtV5blvPPMqtQWFE1sYMadJYMirI8Gwbttb du2+j7SWdewiimLDGDQMI52sjwcLfdy0YG88yYLcKTDEMqZ2jDg7v24+MKWrWBXiqDFIqEGO BAOz7sgGYZhQOg630PM4AbHgYUHil4QKFA0jaNo6pvFd+o+Gq95PoES4aOo5joNKZYgj4bKH pkgIlG8PDCOUN1q465slAQZR4HKqW/g4qIUEA7oNFSK2tXgaBzgN34sqFwWcxU1iwECZjGOT ILkFA8jhE+co8GoatLrO9YONoyjmOYwxdlg2DeiKrR4GwbQFvGUQNjODjTDA1aggY6bfqoZh vb3Hq6GAYY0FAsCeKUMQoOVq5HXgZhiovY5phqaQbt24aQ7WfbzZsF5VFk18AN3BMhq/DcRn MeOZrHQwLjHZ3pcQwwnyfKxdzgXBvX3mdEFAxcyiOwoyIoqKRBIQBv10JgbKinP6NsGwBoUw GkBADWVuZHN0cmVhbQ1lbmRvYmoNMzcgMCBvYmoNPDwNL1Byb2NTZXQgWy9QREYgL1RleHRd DS9Db2xvclNwYWNlIDw8L0RlZmF1bHRSR0IgMSAwIFI+Pg0vRm9udCA8PA0vRjUgNiAwIFIN L0Y3IDcgMCBSDS9GOCAyMiAwIFINL0YxMiA5IDAgUg0vRjE2IDExIDAgUg0+Pg0+Pg1lbmRv YmoNMzkgMCBvYmoNPDwNL0xlbmd0aCA4MDMwDS9GaWx0ZXIgL0xaV0RlY29kZQ0+Pg1zdHJl YW0NCoAMBAMRAMBcOYJAiWDYIaYKICVDzVBRcNRAd4HAiaIC2XYEZAaNRgNBcMosN5GIDbIZ HJYsNRyIDYDSmDYEZ5sICODRmLhwNhoII3HY+DTjNpKMqVD4FBhkMRyMqYIDHK6UMxlFRhUh iMhsLhiNpjVhlWK1XByN7BYpkDbKMJ6NrhA7Ta5jM7fcbnXa/YbvbrLWZFXK9draYgaUYYIJ xIr6NRsIBmORcNLLKpZahgNhuIBpBhoNRnbccLhnkM8MbANYtM5FBhuNxxqdXrZZsNltJRo9 cMIMMxjBBpqt3pN9puDnqzwb/r+RwqzJoJzs3nctla9nhzlByM9H18tkTGDRpdaD4OzM/Laq VUvRkfLX7Ts+vzO18tz1xhBPH8YO3IZhw0wZM69Qcvw2cArBA7tPYpYZrUhDhPMyUIuS/rto O70KoO5LeoM6sOQkEDnOAgkFBgn8SOPEzJQEqDxNu58XBcGwZqDD4XNjBMBRtHEZR2yTKBkl LetUkagsmksipY1UEsoHAcR+waSyEyocOauAXSRKwaSw4yehjADKKAqTep6+crTK4ySTFJ6f Bi2bepI7rRyUHE4uMGrKy6y7eseyMlMs3gGjMzKShpJKvhwmDMJEtQbuSGdF0a3tIUkr9EzN Q9IxOr7vNHR6DtRSawUnFcBRDUoY1O8YahigwbQevtTtdWCfMlWjI1fI9E1yyrLRI4Mt19Ur WKlV1hy4z6Sxu0llV9ZlJ13W76VjV9hVipdmBtbFXRTLbOM9a6CUtUb4XJFdLuE0AbpeGF13 G0wbRjUVOysHLyuM9liu5fVzBlfrTBrOSWK+G8NyU0+CtLN0aW6yLez2yypQViE2XPKwYWxO cqyVjdypZJMBUZQiRJ69saZLMFws7BUCpY6NiwFmCRSdB7KBhfLjINKWR1M4zVNZQK1MtLN+ STooZaPRFFJ9StChUBohCoBoXiMzqCCpQyvospoQa7Eil6WioQColaBCoOScoTDqHjWpGls6 Kjxi2FAhikFLghQLIoCoJ4hCyKgiimFIuioJScpwFuEJ8GjI7SIikLgoO6KQrrZioO4G7sKg QCQEAihB0fPdEIfPhAJwQCSEHTiCEAmdH1PQhAK4QCn2Hac90oQCl2QnhAI3Zd93HX9H2PXi EEHgd91/PeZ1fadx0YuKwgnDcRtiKIRt6QpJeDO8jzgUdH3AqqF9HRd90aCJimIbexxKCJws Maqih4qckFAchSKg1ANMo14h6sDlNgQO2Vs7iicuWbS5sFAVw0BhDoCANIcwQBLDKHl24ZQw hyDGGgH7/X/tXLCQNsyhoCNfgIsEGwOCekWgSiBKTZnNt2CuCkkQKAygpBg+QO4YQ3QTDoG8 EAZQ2hwgiHMNIegyggDpBGCYd4oEXiaHMNAbyMBpDcRwGYXYKBzfiTkFpqjRv5cm5WB0T4JR ODQGUOUTYKggDdEQM0HIlBiDZE2ETVgjFdhM1uABB38P6DXBkFoc4OQeDRHuEhkWtKGTRAKM zdgQQSDoGEMYawQBvi2ERwgWAdxhjGT1RgIIxmmbM5IgysIYQ1BQHeJoZJOPVJMCkFoNgUQT DXHMjEaohRtjfLQGoKV6AogtHOCYYQQR1DDHePMlQ6SXkzJsM0YQqNSRADmVoDZjBvDbE0N8 T43RODyHAMoLmzBoDrBYNME44hlDnIiIIaQwhsidEQOobgyRuDnJefUe5ruTJTAwsC7oaTci lGsMoeJMB0DZBqWBKoORbDFBqZUhQ8yHkTB+aE0pNScoBNhsx40QL6c1NyTwUwsToCrPqfk/ gyRaDPGyOIbQwwakvIWSpVIOhlDMHWe0bwwhkBbSGBcDqZSbDlE4O4bwXR7IEC0rJkYzSrKB QcFAU5vBlDoGmb8FpzBvDhM+J8WqPhmp3RijUHaOSWkxJqZtUJTRklS5egcDpORwi3FINNHJ xSVDIHafkHYNBzDzP2I0Eq+z1ofEUPFYw3xvjA/4BtAUQVUgcHOrYIJ8hpsEHKRE1AQBwDfP ENMeIm0YDnOgIQdYoxNm/EAEFmpv1FspZZLYMXK0koLNuXIaKkhiDkG+ocbgdRUKoGwMNXo2 Rrr/PCeQY5wVooxUZtNvGdFSpPMajYaIv3Nl/E2odnw52Ep4HIOQaZ4SbtcCCYBKoKxKpBbd qQLUQJioO3aLVO4f0QuBRyWU8A3TCb0DmXNjrITtjZXoOkbpbYGDdPW2YdA5N6h6HUMYdA64 VVhDqa02DV1YDfWiv8+Z9hyofUkMYaYkRuloDGK0TZ13rxLS7FAeaZXWqxivFtSwuQ6BcGcF wLAQUpC4CmSsFplSMj6VyE8gTRviBRHit4IAxBvDxkyEsjyeNlylU+ykYysmzqkjWuqIAb3a lcE6LEFA6YEhzkoEFn4NBuDKGKoAb5100DdTOhNrwQBqnXBO8oaQyYvjDVGulVUtg3JjdvP4 IMAzsgnlrJ0gGJyDm5bEN2WpHZPKyxvTUlIh2ctDSmTYbrGzNp3lSaeVw8QhcO4lxhlSLSnj K5K+1uW5yuCRm0MdsqI02p1WWdk+5lBmsjTYNgP3SRtmWGm0GhMGhwnvh9yazqTt2tlEAOcs MKg2BiCjIgb5bFhBQGQMljQyxzDqGcNGRI46lDPu2N09YlxNr/SkLG2AUBjk5P0OWGKuyczA /+qNU66goCNZEEGlo/woR1poFEQINae4iQzib4ps2Ym5HgN808eXv4hlxPckn9BG4xlwgxrN Rw+ibsGLc+wzRaibyDkWLJgRhhJpdQwLTKGhrnKiM3DN+2Ukbxk1RJtNSrWDtt8lFeH6zj5H 7LhxNNa7N9VQ8fRo9tha+2GGak4AtmJWCgNfK8nqxBjyibnB+q8+KQgHt3aO1SA5agHrKIO9 OWBQarkvayDmXyl2npEfdP94Ir3rKQMo9wpgGQJWBaiLIQaF2abmP/A+KKDlLLPh8t+C6Fxy kfmckA94f6DuRxO6+GhH4jjJoO6lSyYbPlkgspPVY33dQxsO6+p9f1b0XFOVWU7AQ9sJYSSe VLFAjs/ruq+JhQ1/yXkoWtl8t87zIKPN+9T54X3hSPO8Lev4f23giY+5Bn7v1XsVcccLB0+k lWAQef+D9IpBs/SUEt1mr0ydAJ6tDgDDaRCPaMZPabTobXKo6lCT4ED1D7rLpyDhYIzo7+7p Qlzigi6NqLcCIrJ8MCj8Llr371ClLuAFpF6UzhTRhFKNCbjNiLKtAPLPSYSwQqizYOrawO6d q7yZS/qe7KyoSTTfiuTXDM5LbUT/igzqCIAMjNzSQN7ATAhAjA7GaSoNwPKsrPrCbCqqTcbg jDbCQMLK69qlLbC65y41C7bH6XyL7eSCbGaCzVDViZSWgGTVyTTWCWgGbI7IicSLcGbDa6xL ZnbqCb6J7cxvcJzPTeCISIi4Tc7AyDiTTnjJrjI7j4kCz6MDAqR8SSjZSpbizqZ7LnrjIuL4 kEQirtySkHaJ6nYyAFoMSdqUTtsDMI0FiFqrCjEK8JyZQoEWLBTnCTSJSJidAJKLacK96poO QMgObIiiLmSozrQ7K7aN7YKfrBa0a4a1ANr4DuLjItRbriiICeoPKJi9zNqWANiez8Ir8Cbo rfkb0UrLkD7iiySCoOiCytUAx+sBMW6VRLYGsFy7itkHqaKt78JOjl8ICv4OEbaPMbsSr4SQ Bg7uscih8c6K4jEdSe0CoECN62x/6MY1UcUf4BsaabZuyJSfsfSQyRCDrc4G7f8gyjzIkUC2 azcZKcan4NzDINKTh4JvQGgGYFCp7qjpLq5AQ08hYEC1qdyarqiMcpTW7RcgBLjSCJrQUbDb 6dqjgMy4cboNgN4N4NapKNcCIrpGrusCr8LpchcVq70iTuQrL0cCkeT2D26UrKUEpwja7MJM TEMkyVcgSrEsUskszSr9rLgkkcTKUtj0D/Et0TyH0HkUZxMebUEtUVEyD9zl0ybKwMqpK2ic CcSpYOCDqroMaoEmEqJnMqjokgDtr/xu0nknyTkP0Di5CCKwTAYrCYYsrA4M65bO0XsLELQM 647P6orqi3A/aMqBwMqz6ZafM20DsxTJ5PcEDor4sC728zyusVjmKK60oMsN6SoNizS+ERq9 wMMGzgTDE5Z7KW8W0qsBiXLDbfTaC8awYOSDUAYNkJyhbBIOjuDhLM0FhFK/IFAKhvRMQFDc yHqTaz7c4Grf6zbYzSQNKarMQFDms1QNgOiiCJsHcdbSSxKfS8DBbRMBSurrRDcJiwM/iWwp QFCi0g6acuTjJg8TMtpKsz8m7Jco8S0ekDLKQOUJqb0u70KQBMLikYQqjnSccCJPcTsEMzk7 0Vcop0YILTsqIqFFkFjNNBU/a0EmCMbA0/yIDAgrDA9AUsTBTgQFLA0MDDiHqvSndI6fVJMY UM5Yk56bjkacYMQMrYMK00qOCY6Ik97DM/EIFNwN6doEKdKHc66QCgK36eCOL8IrLKMI4rbR 6BzEyNzFMLbPUULCKh8la78NtIELC0c1CvoOskMk9TlMDXS+7Xqbi5Spc2rgs6z4LuROktcV M76Sbci5DmSiSZsQUA6HUdEjYMtEtIMUlIbJ5YdYpyRuytUl7CrAyD8iT/CMYzU18BbNBzKB 1Mi8s/qniLat1HFSpQxmlHlK9a1H08DqKDS2IObDapMjSKlaVLtakibn8TEkzioOUWTCi8z8 Ins7U2I0SrFdK81ZNdyTSv8tBa9ec7tetKrooFrgAN1RdXyPYtSUpGzicFkBK7dIFJUudIrh dPKWUiNelJll7otJ9QKpdKbW0zdjbxVbB8cYyLc07CsmU1M1bcKHs8yONU0Wjy8wUQj/1TFV UNqvNdlZVfaN9Z9f6eyi8ly7sQZFK31iVddilG8IcBzqVfVfkLdf0jkQY4MgbbthCdtI9dds lNNdts8bMtBPcxsCkTUpFjjutj7gLCk+Efg+VWxy9qVX0Z83MCMhUx1YlLK76ZVmNPcsTnLH oi8ytrwPKURidcjM8wrdoM8V0JrK1zSTSPLPsVzUqmwOijkEzJhrLJ7sqFQgRAgyIuTk7zBE A/arAKjaDhoOTZgoQN6fYNktr6gjIEF3ZEgqL7TrUJKBzNkOCJULav9kVRrEbIsvtpjOzPgM 4FluBx6rDPCCc6LdqtNr8gqwC8i80oEIi+hybpkJS3yfaRAOSwSCyv8MYNINidqnCIjgCI61 yJrVCyNsI5Lv0Mz4zLz5BsppZXZgj7QFCWgGCqDxbMkwZyp/QGLx95qAj9ZUI0T7S+70qSiN a0iLUfK0S96D8sd7LIQEFLieoN8+LWkeswT0pEFiDqAM7PQOah4FI8tY9DSKiYTCoGQHFZ2I SpLUqZquFdtGNMuJgGVGra85hqTitvcDxHUtdwMvFwbppLc2Z8idrOEoiCyTixoMy5apbeiz yJq96v7YM0+HUk4oMk16i30WWAVEMIGAwOGBFlscFe07dyjvcJDj2Faf6W58lHMelnsTbLj4 4gRsJAI6YqGC+DODY0WDo1eD6bmEKyjyD6pFwzpV75bzGP1BSdCWw1irKIiiNEie0h2HNpws Fxa+5rS3hMS3wOzQycDDd+E/iiEysO0PDKzLCeEPcvx/6y2HwsF6tQCb2QrBrBaRCdF4aPVe ABpHuStwVn9yuZjWDcqLaLWbKUQyjttxeDD7mcA0Dij6Gcj70urot8uedmx/T+2Sz0Tt0wdX ODAFLImQmBCC1nbplyeCCAWTL7A8psoGhxqGD595gqeEliGil3yBOeMCI37uuf+e78TurI+b raECJMNYdmhrmCOiDypDIixLzlrzGDArGDSyjvOUTtuUjv+EWjIgQz932jj7SSmc7LF8tLwr Mf0+t4BrSvGdQN2bJ6meVYDjIkkpb8Glukrimfeq72+hjhd0Grj2TikPsG+A7BuhWcGlln2l 2h5sD7BKIzwzmT2nECLrQ2LoZ8Dhee2MjxTcRrzwcBen+U+EYgQyemZWWT2q0b7278bousmt +rr3IFME8tKgzMqqkqw7qrEGGJU31rSoQMmAglQMKnQOIOqICrqS6rsG17dQlflEMIupy3Oq Cbl71i+cCqeMVHtjtbJ8lkFkUn4N05NEeAKezmjm1vlIVgYhgnuyJ/S8e1gMLer8NcU+k2E+ zbuK1dTi+tqVDKQIMVNhybiTYMSS6LSdlvSjypKdsE4yOzdT0wi7YIwNIPFV9I8Q6fku788i mfqbmv9Jb71oCSkNjaEXd1t04NDI8Xky2x927ELKTTusuCNYwEHBDm91cWhTN0aM16mX8k7v lqXBaJ+k51s8a0Ny9JEbtnFKNnWcEWr9NK2ykEct6/670OPDtnmHrvzJb8z928zu3C1oF6mg kYCXSDPB62UCJT7inCvG3C5/XJN1TkN1l0yJ+lCmqid/zczMJVPD8q0JaB2GU8lPHFq0aNwN q1yxUoEm6Dijj2rpXJ+rfKVoAFHKsXelVnnO2gDzjusE5ImMOXuM9P6GyHFOyHh8ifsmDDqC bEbc6XCtDqQM6z0s270mE4Di+5z1dJu8e8shepAPC9cm+SbJ8d2t3P7n/QboVg11MtBp+cew GuAqeTQ/b7BgOu5ImUDvTXenr8moF3IyReD7GTuiyu1qXLbJQM0UEZuQ7kz97he8nCyg0z9/ +QGAeQebGQycWdridqAzbjwFFUTG64N1dKFzkuDPSCaPKaNfqcdR8Wd+tF1P4FCdqC17iN6d AJyhbQDOwMsJzUshyeDdsxOsFaxPed/UHast9z3DIrAGWtbN4rAGcWhPaUvHyNNRQMuOsdNa KezGNq9ivaFa0um32rjpfQMflhsFVA9W8JHEXetBQJCN1RFFPiadCG4uTD1CMhzc7cfgqIPC EzCQFa7uvanKXa1e9zsV1q23SpqcicyMGpaVHHy7BcS7d7zdoMc/oOFXypSTCPK1Z2vHPqWb /hHo2rPpHUMz7euF6OOGSeXi8gNxd6lqSNdzANtAvl2zgpAmC3Z8YLhgIGu8nwGSVIQi1Ims Sqr0oFGIV5NJT/A6OMw32gnrnr3sCyPsXm9qyvijnMyRDJUAxlHMXEeM6rHvXDOxxq+/6SHQ jwoEAFdHtTvEBEC7T+a7d5+kH2DhfKPVfv7pvxzI/KuMDUUx2MfAjjW4B8YFq6pSNY/U6QA5 buoJcVNv/231C7bIl1MP8K7b6fkflTn0yHSTEuO3nCf31YmRg323HPNhIEG1SeHsFnerThYK H68DTqXWO6SM/wIFAgBGLApKhqBo2Fw1EAwhYghEKGgwGMJEAxG40ihUNoNFBLgkGF5GGI2i ogKhmBoxhkrisMiI3io3h8mjYoLgoj4NkIxGUlk4NGAuGcKhhUIkcKE5nckGMmlFBGtEk1Ho pjjhcFIunMqF1NlkqEAymUVGtQmlAhI4npUqxbmwyGg1IIpGtqFAgFJdKhKnRGhVNn4yFwyG Q4htGoEmqwoMRvM51Od4gt9kc+lGCGw3GeHqguiUkKh3jhlNxjOR5OB0NJvNwgN5yMJjNhlE BpyOs2h3NBpMZoEG9N5vOZlOc5FozFw3GObFsTzeIoIxGo0k2iFBhEGwNxkN5tEBwMpyNp1O hh1WsyUgI2GwEoHPJGs9otHFBwpUiplOtHTqWItzXNaOg0NoOY4Ni2g3jMvC9L4naevaBobq Esb5o4Nz7srCCghoHL+voFoxDSOjjBiHCuhswzmqEqa0OWHLqo4MQ2DeMY1siMLthBATSBBH A5ju8LIjK2LfQxB79J4FwcOUzkLQw/Kfw3DsmhREERBAOI6uI87WyMywGhqFwbByzcKhQpLJ qXL7mveGAaxfFTnvoMQ8vSvr2SQrocMNMz7TS/EvqguMqJvL0NKEHKSTNND1Qy/VBQ8q6suM 5AcBspoWsxFigzc0DRLcKgUp4GQUDeFIYLuO40wDAcesaOzaC4GbCLyvbKSOn8JSWr0WBQgS coeqSGJmGcUBAHDkIUjSOI9P9HJ+rleIYsAZs1Y8w2UjdOBs562yrU0UBQOQW1rBr1y+icUT LXs/UbKCnoSHLqQqqqr1mzYzjCNoyhZO0HS+5Fi0VXq52dd60THdb/Lu2wQDmOo4Dg4QyjJc oGubMN5Uw51Ns8GDnusOg3t+145DKMY6DZOo0jI0jVDNlcFDnVo7jCyIzjTWDWuw+6/yRMMO UiFAzuCMl/UBCDBMJPletI0zUXIybmwkG4ZOZjjoK6GVPI5LjXNg2UEDlHuj58n6ET3XjEMY xzIaPZ7LyUwkqac07UtW1rXti2YXJNVtDP094cBrtT6DCMmovUmEIRNNyGomsSFRMhT4p6GT pozbSSqCHNeDXi9OIlGAUCSOjatuOuxx2ObbJyoK4J7FT4xfrIYY/0cBPNAAy9cwYadiifZx YFvQrW6wxxwEF95t1PeMn1/fhB2QZdoqnRjQN47hBIA2DZHve9h6Xg+pXo1jKPIWuGMI5N78 Ho+n6q0dswFPuuMlYDkOf1hSFvBhQnV5CF0GFofC/BTbozzHlRqCAIgRQpkDee754BCXyO1d uaFGKdXlsPDkqsM77oJvCgs8Yjj2HtPcDZCB8UFH4uhfoA0tzyX1ohDobAOT/H/B5Ys9CEMF SjwxfukF/b/Qav/N+jiHcEoVwiKO8RjzICOQJNiGtHTfzJuNWEscigNTMkVBi8Es6voIEGiw 48wYN3JRbBuhIv8X3MkccSxchANj4xLh8RwMZrA5w1DqyhvALIVQGbWbpHhOYykscmCA6ciX BxvV9IYzxUnIRoi05QGpm5GrZfk6KDDDDitSOQDYGCcHxvxic/OBB2UcHcDbIGUsB4MFuRkj SKgYw0hwQHDcG4OAUFagGC1CQMHLggBoRgoaciOBGDSY9kxFStLOVwe4ihLD3uUbm79ZMYQi mlbs14yEHknqBhWsUwzC4GhTf4DkFBA4Br/QgQg+RDZ4SKBoTMiMiVlqcMAYsNYLg1kTDWDI nIRQqEpBAGegwR6DPaJU7YEATQQANQ5GwhwM4wHLfEks7IZQGhCAaHGiUayHRfeUmBblIymh spMZsGi1qVUtJhS0zdKgrggDcYmhBDKFFNDSQ0JRDQ1ELOS9uYlDwQBbC6QwMlHy0A5jWusl YLgcg5MKQ0hgYyNuzqksaS7go6Ulq0okwxUSJkXBBSospyKxSKcIck6laGP1brGDOrxCq0PU rlIquiSqv0qDEA0KJKQXHUe1UipVTHOVPqtUKqdVSWVYTADIqCZJFRrqkWKsB8TPUWsqhKqh MKVUesCUEmFhSSgxqSCCpdILErWJY5yqjTKrkbsCROwlR7U2rqbYq19UrY2Lsg4RMIMkS1sT CZkmFWTpGDuKDUi9l7QANCnYCg1Oah2FtzYiqVvKrW+scQ24Jhbt1jIikqjFWbxVOrHZpFBh q4GCvVWwzCe6zpgmFeOehQQcUYruia+J079X8AbX+2tg6iWGtVdqp1rru2Ntkb+5Vw7mrIuh WC5dxDDSiMERa6N07AhCoKSGySX1dXFJZZ56KHCET1OpV0hNxZ8kmDlTgxJbCOTnoHQXBFur W1QsZb+x96Hg2UcIRh39yUwWaY+U3Itg7MWhupaTA9p7s2su3gyqODrgW0sFbfHd9iJkjpY5 1MR0qwVxLKi8GgOD34LvqWVMLgzqIcXTmauCyZRzEUtYN29cMw0nzpmWuwDSUZWwXj62F37Z pgwvcVDhgsj4WwlWMrlyL64eLRaW3Fh9DXcyzkC8GEbB3NK4pYhVykJFDyZqWr7hL/ak0grO RSJapakmNV8q2rta6UngDnSmqXCazV1q25YNNSbDIVrk5dg3B7Cr45SNzndeGD19rMie0tZ6 32Toza+sLB6ycIcjNe0L9bEaBqTcu2w53Uy/p3LGP9FYQ3ZlW3e79E4PuDtHWxQqv3K1fpTb Wl956c3roi72+NRbG1/s/SWo9Kbp4FgXL29Me2L3vlvRmk5FXEydki4VzK5nv0tSrTG7eC8W 4PxiS5gk3mbOmQjDlmTBZLnpzCkWUMP4hCNiNCGJcH4oJ7mtNsdcNGeq+ss+obAwqrDoGUPC I2pOvpOxiqQMDQH0ltLg8PTen45zAiflwMeRA2J7VnNGeddTCrffbOJ09Z9jJ7nchPaAY5G0 GWXP/Ye4X1XhprL/eOwVsIwSPst9s8IvKjywuGb03JK7cVHwfZPGeHnpf7u5EvA+QRP3HQmC tPbw4Rxnh1lSMA4mFhbYGTLn+mJ7rrbFziELF8RrT18uyhen2Vv+RXpjBlD2dqr3ZE/Waz3P WO/aSvcaM3Fs0uvwvTuE278Z1/vvoa7sqiYGfyfq+19imPWfy3Ker+fsW5v4ielW3XYHk3Fb e5ayDwPBO7uDfu1Dtz61zvsen39/f232fOOSuKMrv5tQNFuPuFPgvkPCwDPyvSvTuSLqPAMx Pdr4JLszvKPmihM7O2PHMWi1KpQKu5M0rOq3KUuvwJC6wKKZvOnCDMCYNwvejNrlCJk3OHvH QSwWExQXAYETJ6r3L7I2MWtStgq0EkouwXmrQVCUD4pQtWpij4NTrIuZo6jpjBFqvOQlkxNW q9qps3taJLsWnfkJwrmrQsnKQnI0NBwlQiwXCZIzuPI3QaLKlKl5QuwWrKngqSK4QgQ5ElQ6 QiQ7PYQ3O+KOudOeD9OfLFugJ6MjNwDlCEliowp/nXHpK1PvG1g1icgqAVCOKAuvLRnNtaiG glqDKeiGKfiGKgizKGHbCGKIMvwejBiFFLmqC/vMCFGMFsKNrpAGiAgNZW5kc3RyZWFtDWVu ZG9iag00MCAwIG9iag08PA0vUHJvY1NldCBbL1BERiAvVGV4dF0NL0NvbG9yU3BhY2UgPDwv RGVmYXVsdFJHQiAxIDAgUj4+DS9Gb250IDw8DS9GNSA2IDAgUg0vRjcgNyAwIFINL0Y4IDIy IDAgUg0vRjEyIDkgMCBSDS9GMTYgMTEgMCBSDS9GMjAgNDEgMCBSDT4+DT4+DWVuZG9iag00 MyAwIG9iag08PA0vTGVuZ3RoIDczODgNL0ZpbHRlciAvTFpXRGVjb2RlDT4+DXN0cmVhbQ0K gAwEBnBsCI4NGIgNIggRKhggNUMFw1EB3EAzFw4Gw0EBNEBbLsCMgNOMFFwyGI1GcPgQwk4x HIylggMZtBo0Gw1FwwGI2EAxGQ2F09HIgm04nU8n0wG9DG1FNgNlVCGM9n45ptEEFRqdDq1A qlPrc3nM7r9Bp1QBpiBpRhEDhAwHMZGY4i9zGgylc2qsuG8oEA0lw0lVjvs7GcyGgxoY1ilR GIwGguGwyu2LxuPuOTyuXxg3GEryGSoY3n2Y0Gizel04yr1qyOTGOmwOuGQ1hORjA5jl5F15 pehjMJ33AmlxxgzGut39Bw08oY43uu42Rl28G+118/GHXGnZ3084/WF3Yi44F2J7Oj73ZutD HPBxgx6UXpo5qvc5PL+3l/IxrijAcISGb7vy0bdo5Ar/Ny0jZp894YI07jZNo96YJ9ADYtY8 7KBmjjRs4y0OhtD7nxEuwZrmGTJROjIcPdFcWtGnQbJgu8XxAuKhO7CC8Bw2AYKEHAZQVH8g qEHLCxUyi8uepq/xSuaNpk0b7hkmUmQGuzRvQnMjOHLi4rmyMfOa1TIrmHC6xwvLVDMhDIoy HKVhnIYaqKviqvSwiLzu2E9w+ik7N/JzIUDPtCBnRafz2GsiT8oc7UaxixUIGNJw0GLZJzSN MJ9Q7J0XFKqUmqrJhqG8FKEGknVOidVUixyZU1VFYsEk8TVDWDepdOyl029M2VwnLc2CnqKW I3Dxz2sVlITQ7GUexSXWLSk+WSwYbooqrkz7XFf2Zb1Brm3lAJdIE63KGlzzndT00ew05RVK V4TFNKMwhLz+NHMkRvenNQLjL0LLmGFlys8tWxxg9oLjKFBvQHDCtHJKsQ7ic0SEjKcQ69cd p3dmPOfGswLlHUNqfOr0Uxkj00hBa83bdL+5leV0TpSOJrUMwVAaIQqAaF4jOyhIqTgoSKJa EGkwoEAZLmigqJsgQqDkt6CarAAUMiFIqDUBoi6CgSEuvsoQCWuKOhBgYXW2EDQI4vkJbcil 4qiKef6DoeihBo4G6bpemyLp+o79qifok/CHjWk2oOyKkABal1MakO4Gi2FAhikFKqhQLIoC oJ4hCyKgiimFIWhqlAYhR1CghmFAQCqFPYdkJvaxL2/c9iEAi952XOdsEHiBj4AQBz4/k+GG 3jhAFIuioJSCrhqDyr0h4qCIkzQo5yKTKAuwqcvzIQC4xKE+IKgQCR33ib99wh/YEAnBAJIQ fkIIQCZ9/6iKCAK4IApv7fc+t9b/wpPvCeCAIz74EwDf08R/j+ghAggXAl/T64Lv2fc6h6L0 2hlAcS39OTZ2yNkOcU9prU3qPfBQHYMIbg6BhDOGVrzYIQlLb8nA1yMGzvae4hJvz5HZBvDM 8+D7QgjQiaMnAxhljstVe2CgIMN4lFfh2SZVRK4pOYdkGkOYIAyBlDMGkNwZQyAgDDGEOgaA yggDgHIN4YgwhiDSGwNIdA8ggjaGEOkSHpRXJlE0hBGDlkci7FSK0OYRpwL8DSLjfntvlhiC 16EgQWkwJPEKTJ6ZJPgU3EMBoKA5h3DKHKNgaI/AgDnG4EEqowhhee1+JS3IsnoBuy2RIZw3 hvDJIuJcOoSHlBnD+SbsgyhuDGHIPIcA6BpDeG4EAbw5BhDGGyN4Zw0h2mTJd6cmVqsLk6Su IBLi5OWlHH2P8piBzbjfG4OUapZw4CNLZv6V5jSjl5L6YEWJhg5LtF18syZlzNmfNGac1Zrh lBY8QNsZg6hzm8A0Fq5TxTjk/OYGz4nLgojbG+OMc46x3jzHudU85BSNAaeiYsUZPyKlpIyQ kj5IxAkoG6Usp5UyrlbO+Nc8qJtDnsnBNQMCZS7l7L+mMwaVSZYkjYEFGJylDSc+OUdBJmTO mhNKak1psTtm5NKk87JtTclfKeoFS6hkIPQYsn0iQxBvDPRGfswk4VON+VaqT25zSQlECirF Bqt0Jq8GUFwIAgzSDCGSGEMoaRviM4mMwZA0hjj8GWVMNpaBUZ9Oajk6ZXWLm5KgMMzCFRhD IG+MwZ55BnDkGWVYao5zTiPZQOczw3VzjAGi1c/ZBxZs5KMIwWIrNJaUQ9pqmD0EUBscJqRN gUBLrrSqEpMzIk/N9cxg5E3DvcYnKJ8oZo5BtnlNUN1qbyBwlOG0OsM6DzSqCEYu0hCgFDag 9mKYcLp0zImn2gTsg6huteGyy8aQ6BvkBCCJdv2/o1ZzIkI1+4skuBrf6l4O4rAtRZf0ile3 uFWqs5mnsag2B3DCHmWNOJTSoJpNRzoOQUBydSpuwAYw6BsDyCkyoKLD2JjVYyGMM4a20IfG aS0SbguUOVX+yllg6WYj5KqP9vqVE6JhQGl8Valz+kc26v1/7TxitVbmeQd5qRtmwHOMNsgx ZEDaGENdvYkuqYUQnDzkyd1Gb85KcyjKrUet5aiMFuMbVbB3KyVwYw3h1DZGkNVEY/0/lMGw NkasVVoDFHsM0eA4SWs3Z3Pb3EsV/DhaueWiozY9sVkCx2Q7IxWvqDAG5RXKUvfOiyKxg0lV R1rEBrhCrz2VsvTvKeW8GNIQ9IjLOEm/rVwfJ98sYKJyZotnY5Mn88GhaNR21OppZZPDkHIN IYqv5syJXOzAc7V6HjNlGMBNI10M0QGXW4NY02pitkm+05KO6T0rgciGkJWYmDgRWN00sRhz xPGHW4MpgVrWCeKpE/Mt12IRMSfIKNbkrhjGkO/B8MkpzrVHa85a/8J4W+YxPDq1UqIwaao9 L641zolxWlRrkC1vpeC7jesFfXWhQacHFy7uzmVTeAFAVwUg3BxYAFIMHZSqrNWWZOUY32ip 1aV1KHwUR74/KvM2jI0hzDKGW8mB6JkCzvObbcXgxdXBBaPGfUI92wDnHsM4YQ270fRewMYa AQd2DTKcFJywUUN4VjlNPh+rWKDnnG3NE99Gz7aCieEfMEB0tNwC1+irR9WBAGsMse8qX0Nc aal2vrpc2v5Ru/EXuDdVjjZiZOT5f5zUwoU7OHslV/DvHnwEsgxYB7/kT0sWSsqTwhcSWhQq XECcHCJVpTbnyj9XPTLhcZPNLuuSg8C7LuQsBQC2wMzo0RwzGHQOdhwk3n7LGkNIZsMsSyX7 wp3laP2vIrKfq+q7RuFLTPjoSFfOhvXqYPsOLC/ERswOPsENFOxAQPOg3vPr4omJbiJiYwDP roruLNqG3C5OSJPNfLxA3ryQBIeCTlIPlrim3CZrkjKjalpLurotmInOfvuGyAbDwC9PwmqF JLPvxvyvbP0IzP1KGqPqxJ4I3uwtGgQO3sMjdkBwQpyK+CdiisQgUIYg3v8sfv/utAWumvSI koQtjgGimjKuMstQEKVQFMsKbONDEiKQGqGvfo2wInUgbrAA5tFsZC9AUAxsoNFA2g4Awsjp MKWMOuSwqjYq/pqtyI3uAQTgGpDGFpEw1QOQ2G3QFtoQ4DbulgbJSKGwHwmoatIv/MgrHvjQ xr5LqDXD6NlNfAuAZAbgZwaiTCVRYIpiEt2qPxJJMmLQpqXrhwWPnmmLuLlLuC6jXPqwaPWI sl5ugLsEFDpQeognIEAHMgWg3nUxZsYxDMFL5xnjKLjtfL9RnNmiJk1vXmtHuOmOkCBu9LDH 7JpIaozpqg2Q6I3qIxIJXQKwyr6jvudNfRhvmwWnBRkohRlRqxmw1r6QbiHrrpimVlUOiidj HNQxsxtjQRvL4xwphintaKXxzSGoswPGJiOP7DQmpEAHKG3s/u8u9wnAyrLR9sfg3qtMyI2t 3o8O3x7gQA3QtrBojN8tQHvtskhK/usLSNxAwtKg5g6gxxAM1CjM4MoQ+QIrMNGP1JWPNJoo ag5AdCFIjygSiHuDFukSlQAMZsYI9rLJpLbLcLdJWsEqUyHDfrvwVyCxinBicRkpISFwNqZR nyHoTmnjcS/CdPqrwsZMNHWwSryuOzHr1MZDBPxtpr6xXxgqpkhHIKOr2L3KtwjuDyfsES0r Sy2oYwnLXs4KUQyLqChCguYyBvmSSJhiURcvYN2oYscvcCmyAzNHtyjiZQsR9gzNGCKsTvCu mgXL4m+m/nDQcCfjnGoJDOiq/gmA0vRH2Awg7NTCqgcAWg2LWIrToCfiJmDjuGnnCTqSFg2z yLuToi9CVz2RmAQAhI8uazawbPtyIOgmngcMKSKiUwgAkTuNTIxoyozsDR+tjKVLlxKxhTaH ASDLkLuEsHBumTARbRoT4jEz/0AoWOjSVovRtOluoA5RvolSPInRxwDSRxML+FHqaq+SMHZS YP+0FurgyUUpMxlnCSUqoM/rGshP+wuusrTJrLeAypuIwt2g4MCA8tTI8qGo8yZNPGwN9EJJ 0Q/wSsoA4A3s1NxqvuAIYymg8g9R+I3s3g8A0s3tKrRRUIayytAJVxJDXDQyQtfTd0Nl4U8x FjAQsUjSlzUKuAxIZozKGo1ynqHycspOrNpiMF6TgIgmjSWDS0tzTLTAyg8L1LzowposcJWU upWL1Axv4vBo0xBA4L2xCyyx2K+u2nMr3ymvAgzAzMXAWxQA6LDulOmOnOoCKpot6nOnWo/o xg5pltxv+o9ox1Dg2VPojydKJMkLOihjQy0A3UzN1A5tDpTN6tKOArbyuLLvQUE1aIYqcsZE VMeHiApuyiPgZguvJVqlMN+JR1bp4qPo4I5IjLDgqVHKQrIuOiFStuyA6A6uCvho7gyA50qA 3VXM8v8A6g5A3KGqEAtgYguzmJaLrzoiwCfga0QQfDuzhqOghpot1Ix18pXU1021ztWUiMop Vzd1BQAMctPsPnvKOy3I1O/vBqzReUGPsQymIQDSCGwHA0KiKCUCljlUNRzwbRoksDckFvqq NRr0SRtwdMYvCuoUUmh0VuLlOpE0XzBR0SBUaHvny0bvYwk0dO5DCTLPcDPxEwRRFk8OTzTo 1PHpYvMIZtKtX0GpCKWQDA6RbSHw3gQA4g6rML31oKzsZCUnZR/KVTfRyIpsI2oCTWxqXgXx JDB3LrhRbWkvoSESKCgHDPxNbgYNciJk2M8CUnvRdOfRopi0AigSKUQjGx3tyJrA1zLq226w qHwGOs/q4g8MoWBtvwt1aXA2h0HCM3QgUT3XNC/XQny3F3Gqt3HvL3KJCXLWjUJXSRjFBwQF 8RmTAqmSHXapQluxqu2WsSMnOw8zGWQ25JA2wLqUW2yRbMNXQVJx2SjzOovKsHaw8rBKEKuq F1/NAu4ym3GKG3vRnucQDAmgwg8AgrGRbCMTcHMqGoxAy1O2GJp2HxVwLG/pMidPdxFJR3qT 9ItR1wfx32B4JG/4KJE3DXqiT3pVEowt/W94STWsFqVWkyB3DjKPXnM1hi/pSOnnZNyA3gxg 1itpkgzw7YatkXpWH4dXrnZWBvRTeJMDZl4YACdx3IXJsLc4rql2wiMW0JR3f4dY3yW0t4GU 1Awt2rXyng2I/rIgt14pWOUp1RfDJiZPeUa4LYMJfgWw8g7QKuLYOQDAuAUXPjf3pYXUYMJm 6wDAWZKsl4cYj5PqX5O3BZNZRNfYt4XsKYeJgWw3EIp445VYkJEguAU4hZXX9tbEixa4uXpY hYTsu0Z4Wtip6OIYd5JEPnjYdZhGqqOmnwWLj3S2llJjKyF3V5KiVQ3Ip5U5M2ziU5kNcY2R MkbXQqNCfIXA1gV0+XYwDZlGwWOz+zDC7E8SF2N53iXCZESwWogThNQtss/KOgpozRAPA0k3 FXGPNzSr4ZSzn5jsIYjvUop3PaGMuzcAUXM4X3xmmjviEjQQZXVDE3WJaDBwYXYMKqX53G1T oyAruIVRqnynOgagUXe4pQnA3g8I+SqpYo/psI13DW50W5DnvnKUgqOpox9A3UqrIpnu9x8p WV3qTzU1MuvLeO/2IEJWdJRg5MA0mqxU2o3xJCdaLAqYj3OXE2eRSwu04wl6qvAN3pVg20wa f38YhpCVcyLVJgUH1uH39T0ZaZk4jjb4Y5v6hq/5nyC5o3yDzxlmmLm5raQ5sE2JE5uWzMu5 yZwaRJ6ZcbLoutsj850Z1XNDGNZaIpR6U38vW5vpE7Q5ZbOKMjEUazxMZjF3J4TR/4zbS3p0 NmlzCi8iEicvqTraht9q/rDgp6FQtvLsTKTMELb1yV9Y9StMMiqYyieWSpR4/ZAN3qT19IyA zSZpnqzYwYqY1PAal2hS6xnwz3w0+bBJEgWtFA3UrqKD6Xo7qjZtQ46OTvNSoL3w6PgSsA51 So/uAbxuyLSu/0qad4qafU55fwy58YtZWxM5ytQgUAV5Y5u0WJ84laQgY5rpwOoTxS6TXJCR l5L6IR17DI7P1Z7KKMrKojXZz27rPnMgmAyg6VhjHJSI1A4UnqTLQq4qzTGCew9StMes1A6y YqTg8tFgQR9u07q6AJRgiHTgsYgpZOqJpbxuAQhI1I/641xOWWkT4WlAQCVbGUZSFgZ7M6VZ 4iVCilU3UibHy4oYpP1zLj7772sb9QsAquyPQKP1t1xwhrYA5I8PCJIV2V/uqpZYwAW8Dg5a rVqMP8Lap8voZ4pNTcqgp8ruPrKvAatqcNgI+av8HublfXpayXNX/YyahVLKjZz2dtFxSY8L FRTtWrIIj64a5dTr6SKJE9V7W5fa+L+b3NbbAZl4Y9Y787Dcx0J7EmmnVm7FW7H5wmwaSZDH KaTuTIXDltYCJZ2RY7IaR3XC7aTXZJRiN8Jr6QDbWcNRb7JaUd2ZNCcTZIp937K945tJR82X aTojliEsK2RNRZzmtgQAexfMNtrW7IWmt69uWr+Nd6/jF7A5yizTh+D9n6NRktZruc0drc2s KXX9t90x2AUEgd/54i6nDHV7g3dbrbioGJqPAg8O9Unt5P49fIskhwDeIZZeJqXgebD8ydor uAaUAePpiyFjQeVbekYczjLSFqUOf3YROQkPQVMnaww1hgbRQVp4xCV6hKO04dcsws0qdppe N8y5pDAyLjcc5pR5r9y97NeDG90muHk2ObeT0icSKDcXcrocXLqzok7CBekOieYQgAnA3iLV 9b+Q7bt1HP8o3t36jyuatsbWJ1aKQtOtc4yjZ0tpTo9MidOODdQdMXfIww9u96mMoLU+a0nr VA6Adarqqmt0q/JI3/TdH1VJsO9rHL319yb/Rg8/a2cR2HM8qnUsYIPa6ZgdoejFB+PFkjvy F8M99fCeVk1+jvwRmZJ5PDvwDA8YjlW43tsnCM/5a+EAQdOdi+eCJ/pDajTnV+QxfJzDaM8D TQr5YbdihgQCADAQQIYwIaDMYC4aiAaDQcwoQFQ2g0UFwUCkqGoGi8jDEaCAYxEzA0bQqFwK BSWFwcaRAaDWWwuJRQuDMZDCMRqODEZSCRA2Ci6QyiQQYZx+Gw+ZRMUHicxuOjafFSRwmYSe IkQGluKikXCArikcDMUGUUjAUCAxmE3CCajIZGYwmM6G85CA3nU6W8ZiA6Gg0nMQHA5CkWjg UG84C0Ul0qEoGi0bi4cDeQi0Yi6+lStQkYDAbxE71uy4XMDUUHQ827UmgwnQQYEWCAwmw2G8 7340GXaGQ7GU5HMw4UZYjV3UQGU8HDbmnYX/A4PhimGijGY7IFQVZHPDLN6PUmkxnU2cMQHM 6HI63Q6nLa4M5YrgaouCkQGLVmY0ng0m4zvON42t4ODhjo8TyOmjIGu07gXBgmzRNIMTnLwM zdN4IgiimEA1jKPKxMQr4qMAwTTBixAyjI9YysEv8MQ1DkPBANgyv8v7GsfBbts8kIqPA/CQ RENA6jm2Y6DCNb+v+uYxryNzYDfC0XBBDMNw6PIWyaNrmDKxkFQYhIYhsqUfIpAUnteNI3ra wj5Dk1TaDcMkLraMI4OYPMlLw9sLjm2SnzBBwaTI8A7t4M4yue11FN4MozDMMq6DS38YtXGk bDRCsqQ0LDZju5w0UA7YWx4j8yhQOUWDhSLnjfSrzjK4YxjQ2botfGdYvQEAaoWp6OBwqaRh iGYXByqSBM4igV18qNggaqyXoGrLSBAGyPregi3JsgQ2P/HDIJ2nsepGlobBqvtkK1UkHBkH KIjHMwQWZMVnMyGCP3SigeqeFqbqEHNgMwzVp2ReFkPAGMT20m8Z29BVw2dYlBqxZIUDbeap XHZ4XBug9pYq+7nDmF1mNDjSlWkgiBBmG2VhjlCZs8GEevAIc1jGNg6jJPQpDKNrhjWOeMXq hKeqIgoQZZlYYJUiKJzDB8IhRKosPONC8jZOYxN5IkUhANUiNgMLBTW3g76xOeu02KeSQUgW BM2zt2NCKmDKEG6ZPAIy7OSPAwy3Glajc9FYznKLaTuNk8v8tQ0jg3a7jE24xjXUWNs/YG6o pWYwv7PSLCGIQhvqv1XSq2eyhBs7yTnO08NjVvLR5d3NanTiv6o2MnuAuY6MFAk3wO8o5cUE A3PEMvi0/G8vx3d/L4TqXQiG2ex7WLAW+m5I3DGOQ8jhA01toNsnd90oQZ+OY1y8jUGXWz7N 3h98IVPPUpuZzvdjw2Hl0zK76DXnADSbVIxuy2pVey6J2Tz0wg0ZoRRGr3XvoGP9AVGsAH1J 6DuosECqQ5nkfM/19BdizPNY2DEGrmTRlcf+z8OkAjalfBAElNh0wWg2PCeN4YKQbAxBQbM1 yJgcgoDIHc6ZNiyuqMArMwZwAUgziGddHKgVhqEIoGYuwbTBQIe1BF7z4E1FtLWW1rYIAzv5 DMeR4rPn2I6hO3hqRzA3h5a8chVYcosByDahd4yawWnpUnAMNh0k3qaapG1MD0nRPbglGBNb bSNNIaOytlpIAalWac5cHCpjwBBfQf1vh/UmhuN+8eCJvHDu5OiyI856S2KIUq5Z953kIlcT 8HoMsMoaOIOYeJNKazBIUDaGkM4aDYRlMIo53jkjeHIOVC9OS343HdbyRRKYZFHOefCW2VKn HztqOGhOVz3gWqXDOX9SqRXZFCKO1JvjyQ5zNVc2pK7ZELBzQCbw/QeGvBiL1CNVJak1m/kQ jtBzUUylclMk9XCmIZBBMEWxvrf0uOCBAFIKcngiBTCSW8GoKQbgyBQYIIVGQjBFmk+5mT8U GoPJ6qdYhAg0uAZ8jVI825DKcgsCAOqcjgOKT0/9ea4ifsvY4xQrQKErtDY0Zgh8cG4MEgZQ eKzFgwmrjKTxYE4kiu6iUeJTJa54x8Sqq8tic0XTrZnFYrhhDDAxBuWUFsGznI1qCjKI8ODe TYheaZljFj+teZ2YUGZZFWPFDNX4tCAV5HYKgTxepD1or5qUh6plRWB2UBYU8IoVFnggCOA0 GjTCGQpqO+i0UDiXWmjgGwBoUwGhCs8RxkxPwcIOKwZkGUcLbkLt2QwHFvZMrZISDkoaHHLg wpfCsFAVAUsABQkhPSTHyzSM8DUqTAgartqkqdw6U6ypXjautl5fbtXcWS+8GlL14AoS0lxM 9N4wlPMyDYywILzu0M7VMz9yzSVurgYmO5hgb1xThWeaT7wbMBMzdu/VyYHmtgu66oB/inph wYQq9FSS8l3Rcn6rtaW3LFBkQu/K033szako5SCklKVLQUwInhH8TrJZlhGc06JuhTU7hck1 5sG4bpbipU8IoPKrLo6W+ixWX34yDg+ypq54qyVpktduGcHMEoPhFWxsEaNjDovwGVuLs5PW mChhIOJysOI1bcGBWCBXCh6RAo4NSIEzYsU/N1uQXW7IXnJlGdc7tPy3fy5TUmQu+s3jHOyD zQ41v27WDZwDeZ6twykEFwrsZ0JtoNM2ls3rSt1bwiC1tOZjKXhDRB0cREaX7mTJ2GsH4pO+ RQNwdQ2tbLulHMQLr7aPzMskrkh4vGGWMCiCaKbrGaXvrHLONtCqnQEHM4UsHJBvco0JBRma 4Y02CupmV/iuJTDCb44Bwq/HGmkZkG9hdnZCvdRIN4Ykjn9kgA2zoDSAgA1lbmRzdHJlYW0N ZW5kb2JqDTQ0IDAgb2JqDTw8DS9Qcm9jU2V0IFsvUERGIC9UZXh0XQ0vQ29sb3JTcGFjZSA8 PC9EZWZhdWx0UkdCIDEgMCBSPj4NL0ZvbnQgPDwNL0Y1IDYgMCBSDS9GNyA3IDAgUg0vRjgg MjIgMCBSDS9GMTIgOSAwIFINL0YxNCAxMCAwIFINL0YxNiAxMSAwIFINPj4NPj4NZW5kb2Jq DTQ2IDAgb2JqDTw8DS9MZW5ndGggNjYyNA0vRmlsdGVyIC9MWldEZWNvZGUNPj4Nc3RyZWFt DQqADAQDEQDAXDmCQIlg2CGmCiAlQ81QUXDUQHeBwImiAtl2BGQGjUYDQXDKLDeRiA2yGRyW LDUciA2A0pg2BGebCAjg0Zi4cDYaCCNx2Pg04zaSjKlQ+BQYZDEcjKmCAxyulDMZRUYVIYjI bC4YjaY1YZVitVwcjewWKZA2yjCeja4QO02uYzO33G512v2G726y1mRVyvXa2mIGlGGCCcSK +jUbCAZjkXDSyyqWWoYDYbiAaQYaDUZ23HC4Z5DPDGwDWLTORQYbjccanV62WbDZbSUaPXDC DDMYwQaard6Tfabg56s8G/6/kcKsyaCc7N53LZWvZ4c5QcjPR9fLZExg0aXWg+DszPy2qlVL 0ZHy1+07Pr8ztfLc9cYQTx/GDtyGYcNMGTOvUHL8NnAKwQO7T2KWGa1IQ4TzMlCLkv67aDu9 CqDuS3qDOrDkJBA5zgIJBQYJ/EjjxMyUBKg8TbufFwXBsGagw+FzYwTAUbRxGUdskygZJS3r VJGoLJpLIqWNVBLKBwHEfsGkshMqHDmrgF0kSsGksOMnoYwAyigKk3qevnK0yuMkkxSenwYt m3qSO60clBxOLjBqysusu3rHsjJTLN4BozMykoaSSr4cJgzCRLUG7khnRdGt7SFJK/RMzUPS MTq+7zR0eg7UUmsFJxXAUQ1KGNTvGGoYoMG0Hr7U7XVgnzJVoyNXyPRNcsqy0SODLdfVK1ip VdYcuM+ksbtJZVfWZSdd1u+lY1fYVYqXZgbWxV0Uy2zjPWuglLVG+FyRXS7hNAG6XhhddxtM G0Y1FTsrBy8rjPZYruX1cwZX60wazklivhvDclNPgrSzdGlusi3s9ssqUFYhNlzysGFsTnKs lY3cqWSTAVGUIkSevbGmSzBcLOwVAqWOjYsBZgkUnQeygYXy4yDSlkdTOM1TWUCtTLSzfkk6 KGWj0RRSfUrQoVAaIQqAaF4jM6ggqUMr6LKaEGuxIpeloqEAqJWgQqDknKEw6h41qRpbOio8 YthQIYpBS4IUCyKAqCeIQsioIophSLoqCUnKcBbhCfBoyO0iIpC4KDuikK62YqDuBu7CoEAk BAIoQdHz3RCHz4QCcEAkhB04ghAJnR9T0IQCuEAp9h2nPdKEApdkJ4QCN2Xfdx1/R9j14hBB 4Hfdfz3mdX2ncdGLisIJw3EbYiiEbekKSXgzvI84FHR9wKqhfR0XfdGgiYpiG3scSgicLC01 GIeKnJbS8YUOCFIVA1NWCMWEgbZlDKwKnAhYJYmwtncU5NCDZnNgoDuGgNIbAyggDoGiDIcA 3hzDoC2CoaQ6BlDcGkNwZwQBrDKHkEAaQ5ggDCVQN4bQ4QYDwCAMwdQ3BjDoGkN4bn/wBIEC 01Ro38gNBaiAGJFnNANBQG8M0Mg2BsIGZEMQeYSwxikCCIcAiuwFa2A1Rb+HJAohYHmL7V4C NagOS6M0UAXRfBaqkiwLSsmRiSiBDbliDJiidBMIjhAsEXDDDGFEJQ3BkDKGSDQb4vQAjAVy AxDGexxBQGmGwcg3h2gzGuAZkY3E8R1HFu0gwpvVJMClLAKIYwgDkCmPANgUQmDPBt+MSgYk kjvEdsz+mzHjRAdmJ4KAwhnDDCiEEK4WggDmGUMIcgxhoBZDKRckYAxskpGNMjXpfxQDgHIM szw5SemxGCUUlSemjfFJkOkrw6TihTBsi8JA0AgnEC2OhXVRggiMaab8f1sTFDmHAMsPpHgg DfBsMocgQQeDmHMNIYoMQyDoHQMIYw1hzBcCAIQdQ6QyhiEsMIbIYBrIcGGRcXwqNSRADUqU xQpBvDEHMNAYSMQoDIGkMYYYSzVlRIWjIdA60lDZC4Mgb5xwyDJI6Z4Yw6hyhJGqSVLXLoEg lFCY8yQ3TLp2GYM1DYTQ/pLNaR1Jg3TQocGMOQeQ4UYDdSUPNEoYhbBkF2asKJ9VVpcWBysE 62TQolCmDUHJ8BlDiHUNM4pHBuDqG0MVDaFRTDWG4N4dw3UKrWGiD8JqWV9K3MFy67qsgohv VyEoeJ30JsjC+zIZQ8BjnHFyKYMovtha+2FMRaiXg4J7E4lYKC5RfgQ1+BCcZeIkBuZS4Ecn g1RoZQ4MNTZGz7JISaf0vo9pbibaKV08ZbT0q3MqkNDJn0WoxRqGIdw3h1DZU4MoZQ22sDLZ 8nMfkt2hie3ajMFgyyekdFmfEsgcy1tOGOFEKqGAgCwE+WQMwYAod8G+gwcqfRAq7ZMEFQZc 1WRAuK/EgKst2wFdOncP4gzVkPa7DbhAWhQCLLJVgKAoS5m1GJrjZbctlTErtBVzY0SgjbJV WN3Z2xzkljeUZv37ztDXkKdMYyDGiNm+KPjmX+GqyFNuA8mMn5JlDjgpANsjTfBRbaSVxSHw ISJlNEizMgBcBRlvMRoJMB4yhnXHVAWW3eC4CkEAPZz5Kkqcub0Scg5gyHlLPeiHr5gNnKNI +h4zgrzzKOPBoJe0Au2b6JDdQUSDxlLRwrh3E6EjHbgh7YcyNiT3kDL82cw6Sa+QKBC3WxW8 bNcHOQa80ay0jJU1RQZ26W0VlwpBrM76XyIZXSj48/zVgrQ0FJWJauwjnEYGmEsbBG2DGPV8 mNjay0WoZa8pgUBMb0zoFEqk9hS3doGLxp925z1NJPMRPbSTt3VorKOOZvECt0DncJomha7i gF6UG34D61IyXS5NMNdQOBRuPfGS1cb82ZozZT4olpbKW5Zu27s/4yY2CjbMTcI5y27GHSSf J2t539mLVXAmylvbLwZsvFOFaQzFmrWxAilXM1zzu4PFtUbmR1s/bnM+Ma4ytfnT8UOSApBZ HRIhq7s6cjOHzOnT5Mb93Jv/ZOz+P6eu8HwHvXtj8/4zmbmXY89OQzN2rtm5NkJO6Z2KdGeu O5m3d3br+hZMdx772Dj0fIkOb5GVgGvajJAyxVEKIwNQUBkxkaJ8kueatgx4bFYSAsgc92Bz /h1xwbrUuTxTpGs9m5Vm/2ctOI3ySMstFuLwLSgTGqbCTDEudtJVn/EiYF+CR0x8YCgNob5Z FK8ve6SFtt7+dbCDjNxItw8UKxcT05AgcGdZt0Z8dHWzWG27wwt3b9Eax8Ps3v+iNB7ez1Oz M3rdy9lkx/Hl2zf6aIiE6c/c3QBAlU1tAGKwIEDYhU5a2QLi6YDa426U32m+bsBADEvamui6 C2BmC6ioDm+Y3uiMTQ62+IvugmDCDghuDSqWDokgDsmiDSpUtWDmDqmmpEsKhgoUrSyQiIn8 jyz47Qv2BQCCvWDK3cnMtgtOhQkamqvaoclib2nGvctWqSDc3cpCDmDChcg2p8heDo3cBSRs lctcn03uiKu0ck7OY2tE7OKwtKrCkOomorBZAqsUvehkJUv7CUIugtBqvYvcwCnEDCDWxaCm Cwvsf2cmS89ohRDvEDA8rioogyDC+Wh4pCi6h+DaDK/Io+vKg4qQkgk0hujU3uw8LWcygnC3 CvBonuhmDbDyrSIuvbDspunNDmvkhuDehdA9EzEOXCJjCCwsp2p6iqhcrSpykYDCB1C6hpD/ Cq8cb022pCtbFbFegzFCgxDIezFKL8tLEyDch+sIhmjSBamemjBqp8vSDWrysywWDOhMoarK meq6vqr4iURAP2tKhHD7CK8cnMkYDmrYomkbB2LcJ6SSNUpif0XCj0kEkJFjD+mcviDbHWBA DssWqIqMhcv+obF0hMmemrDnGmi/DM64cmkC2gKwBksiousklQsKpVEIBclUNGdWpDBwokhs gwqAxcDGhqDgp9GycTG28WihDiDKmqDKrAp5BVG+qOhfJyvkrGDDEixYpuDkDIDumjKOBAtm hMr2gDFKLhFOigrJGIsKgzCxEymcoMkbBssGDOorJdEZA8DMDpKynEmqp6//LAalDSicPHDY +QnAk4DMhJKnKcDqvOtghhHAhVJdKtKxK08mkchIBApuhisis9HqiYa0mELAtImKnCk6hNIo hmlgiChVHlI+oSxMJVFWmcvAnmDREOtEoFLGmMmQvJK4DwpvMSh+nMjTIjHMDQo6CLEyDkDO wTNgpUDImiDIDnF6VhMEgpD4nuoKoODSDMhdJcDeocniDShugzJdD9DsqSIuDKiqkfF6N9On J6q6DSkYocqDIIauaykq6IuM6E9SRIXo/EwlKSrEh6nHAgAa9EKnQMQIV2NE/FDS6nDZKIbs C2BiC6lkt8BkBQCnOKk8szOYBACyb0ia5QBSwiKEpVA8qiBS80mqlUBkdfPclgwelpBoxQsy i6hmwQDgg4ocDMliMmijAe3uScBwKkn+phF++KmEtLNMwSoqDgmeDqqSwskWhqoeoaDapAwu iDJkKxJpCHBgrYrcpC3cIRIIn+SjSIaEaW9jHvM7HsS2j6+SrtQojqwgBQCEo6pIpMDmpQrM KEo6pmpqpuDulYwjRXJSCbClPAoqhMrY+aBiBRTCwxGUDuDKDSDODRKCIYJ9SG63SMoDNqS2 Bqbm+TOUqeqiqnT6wqBSQIBQDNO6lkBu+UpUtlS2MvAW5+KzSG2JAm1CliNY5Qw2poDFC+By wihiCVCab08sriDY5a7IPYZ2namqCUpUDrK+iU6yOCNnSLTUiTDSa1BMraLoQOmqK6BmlUOC QJTLSFTQIrW7IUZ09pA1TnSGwKCVTwgvBhQ4muxrOlRFRIpmmRKyjVSGBRUMKUCQsuoSnC2q 8soWoOpDJcvGq6DolzXZU7XecmBtLGbsthN6hADTOAmbHKmlOJJmdGCGrarekhTGBtMmi83u 6SIYPkOGkwDQouDgB0BeBeDvZ6DGokDNXXZoIJW5SPTdCA1BZ+BdBpObIso4kaDqBeD9CfUe DfYFCzWczEMoBoUikxXWiONFYxaNERTZXkBpXoaWwlT/ZCnGDomrVulGL6TynawrEerLJ6Db SuhOp7RpQIMpW1a8n2T2LK03U8u2ibIYfGC2BrbQwKCao6CvWUkzHfV88tYOBkCLKUwQrHEI mZI6mib0lomnVqNGCbWrIAqkresnYtU3XbcNDRM49oCCDqDPN8BASJXKO2BnZebM3XQuoODR b2rKCkDKg8liwKpCCoCkjwUSmqCmmmDeDfWbFIpc9oi6CHJ8pAslefKYtkmqCGmigxBYsyCq hOk8DkokDojUYRYNRKhcKgXyjm3uCKarAKIMe4IUksfQPIYqBo30IsJWS8UDf86WLaJqWCOA QEuxgCRVgSjgJmJqaogFPsjGjCuMPcYqMKuaRARUctIQVk9odwc8dedUCIBAded9hMemfOCg w3hObMdClzPwzWIEWCQI6IgdbJhCrhOalijxQup2D1Syszcyb1VjVdh8LKBQtXiQlzJJBIc7 RSwLdTGxJdexG+hQDqvrZi9dgq+6OVdvQWubL9DW8UtKCgk4DOnEojBzLPhOCcCmdYCwuYKk hBOZOchpiwscqWDuntNocs7Ol2tKwXbxPDRow1fOokiCbAw0hnNEohLaDIwtLrOWDdWuw8tL h6kdiRjdMSgzEvioDKBalRIIiLB807XAfGCpRBVjlDlGcIhehihmriqIwsitYGoTH/UtQ5Aq DYDeo0KpPBR1idBHB/cTiWpvGlDrOfjawWlgvCDQtpEImqs5UpfPLOnEvs7OmJXCgzFcDchd FDO6rgpDRfPhHhRokRHYsNkkDDLrOUilPXHwoJNfNNh5OdlLB6RrB/g6+SCTQ4iqmqhPFg+W 3W8uqXlBUVlFYliSlog7CeBmijkgkdj6lxDLmLW9HuyxaPDamLVcqjArUqsIwXloqjbvAuhK DlJ+DktXEusNUpPSsqsvL2AbkxkBHvcSbtoLh/oPmlk8w1LfLicIo6CNO6g1ldJdF3EkDJUy qtm29oxOwwrKDMhwonXzfUxZOuwRO1VKhrm8+YjwBxp7lihlBcgvqar7kEmLMPEkmvEYxM99 kXDnkJmEskopl/EGmmq4wTm1HvKI3qCGCECG2jmDRyskrCkaDEozEGzkCGCMCEz/T6vaDoDg pAh0viDJsUo1r6vypjMBjNCCzkCfsfsi+XH+tdR0hJLbR5RBR+mdSZPEcJJADRh8KglrLQpN UvYq3uLKT4KULBU+xC5CgnBcqlBihjpTEykc8G1S/UjOkSoagwDCwA/07IJJV20RsCdPQ7uY UMJI/6jODhPBPRCVuXAAjHAakxscCEn3b+03BImMmvu7U1Ak0RvEoMrRLbQIt+2ebSgntGeV K1A6khummSDZrZTKT2NGjxn2069BCDlWODVivYBBGMJU+YTFrHoTPDledxFTPOljrEgykYk9 l8oM8xou+HB+oHBMpCCSCEI3wEpLA8ofjWrHLbEZkIqinkpDnbLqo6CerTPXEVCDwtp3VikZ JBStv1i4/2jGQikxRxR1l7rwKopuhROVoqnvFdT3r5vOUMcYIPoxXha6mLqNu0CbKQDcpvQF uQsNPdQ3RorLu1qPoVkvrSKAtLoZSlHdG8pDy1jchQDGDZMSwxkatetj0JzvJNVGigokk8Bb qNpdLREmgyKABaDFMqsTBjVRAsnosjiRra8xM2LAJTrXLqskwWDbPgDJqEdwwpnQwwo6Cogs hj0v0ypD03kts5nnFRVRuLBUhjk4mhBrrvmAi7UZZVkPQ7MrBxHd131I+OtLnRLawEwWp1eK hM9spCDkh5oGhVRsh1CanolR14v0+T1gwtkPEZwBwu1HoP1msMoXynyNwwlokZrIoYw7eqmL ugDlulup2BBiw1zRnzwYj1XgMuxDNAgnqKoc+WnEtdiRFdkPrksNNFjUtmw0CDjgCS+4SrPz dvP2Ui/EiZo2btjnXdjyvTE6gz5SphK4xPVeRvfaCEguisCZHQhQxVt2ezZk6A4fQSRJQNhy u9wOouhQCADGDyrQDWBdbxQIjKyOi/foJ4VkIPhALkTgKkJWUmTQ++bANUBz7AJn68LASibA KyNkYKNOPkVZ7SR17R7KMgQ6NGRsMr7f7mU/7R7uOGUJ7afsNn7uSj7Z7oQD8Ee+QCMl7pXS bAuugiNOT2QOKkKAWaM6PGNOTCjD8qLKZgNOKyIR7t8eZcpgRr8V8H7R8/9N8E30RsKoJ59K RsNmJgIrhB7mjz8V9p798X9B7f9oRT9J80Kl9/7B8wNZ6x+GZz7J9hbl+SS37B8B8ORISH9T 8N7R917f+N739mO57z+Z7r+n/B71/B60MgU2NOPZ82yn9t9gVT6yiOgj7m9F7f618ILaNPa3 6yZ77l9gTJ82BiIALhgNhkIDYDRmNhgLhqMRmIBsMYFBINCIULhuMxvEIkMhtD4PCYkNRxG4 iLo9IIsMhcMRjBYuOJfFYTLBzFJjM4OZhVFhpLRwOBANRuLqDQjbPoxM6JRqDNBtPxvTKKNI dUKlVJRT4TPxzJaHRYHBYSNZbWrGIDHFqLX43TbTIRsOKBQrhFITdBpFKbVofeRde4LTRqM6 Fa8Bgo5GI1UL1OIlRxBgBjT4JKJnCbbYMuMpniBtZpdMJZnoLcq9nNLmajS9JAqvXddi8loK zMIlfqxdcXutRvIvGY3chmLojMIXwqhNrANRyLhzhuXLelzuh0rlEuPEIXhqFcuTH+4Lu9UI XhaFFxj4pD1ht4vV7IR1hpzefbppJIZfPvYPaugYM4hYaOw+YbOg+zyMa9qihup79PQ3bKrs ukIt/Cawqc74Gp4+avP4n6ZIKpIZhqsz8OdE7/Pm0UHpujEVhm+roKu50Dwc4aERmHMahyqq dR0ujyudH7TyC8kXKKySQxnIavoExsZLo0ahyeGUohotr+LpK6NsQGjRKZK0Fx0r0ey5LCfo +u0fQ0yYaTU6s2hu8UvzjNjihqikmTvKriqssk4Roh7nOLAKhRlMLBuigSny/LVF0Mp8mSnM VJURJsXOKGSwSlJE8MCz8jyc4seSNT0eUJRlTJpHcep/PVTho57TSrWE9vmha0xTBUNxK89X zc9rcxBYT5u1MSzLi+aWIbVVlVxEqWOVXiUvzPL7LNaz2p/KjnRDIESw/RdwSNDsSwPDDnMi p8ST02d12NdF4R5UNT3eqdFo7Tt3xReq0xKotvX+ijEOtfyJWWhKF3VgiyIuxV40AyeIP4kb GtBAb+LM5TwMDjc3YW3kbMwv+DvtA7PIfg2BTFlKrvbA9/Zfk0b5c2Ga3oszawNnV7PzdMXL NieY5GHKpTJEqzO3b7GRzcUELfVcC6gh1QOjXzCuNMSfvK9tpvFpuvWYhk5W7aKGuNsOjpbt DcvtUsYhq87+bjp+50bqSfwJX0d7hXtWufB02WbpN34bwu76DNl2Q3DohCoBoXiMjYYhAKgz AbAAahAGAQI6G/OQqoYZJhF/OCopPPcshcec6EA1gaFtdBgh4qDuBoUCIIopiwEA7jeOo2DI FIqDUBqFhkGiChakYZBzy4ieQgQYIL2/cjmMoyjaFgQDSN3i+P5PlhB5qGef6IGi2FA7DSOQ UhbuYUDoOowjYNg8hSLoqCV6flPMec9AKj0naOWeu+sModgyvvBaVEFAeQQPZDc9kFj+n+P+ fI+YGr6IBuygK5d3D8w3ggDEGUEAYXwwYgA+eAT0nZvUetCEEUJQ6B0gWCB3YU4UvjhXBuFr 0wYO1hA7kOgaAwhuhw7wFwXAZpXhSg0jYLVZkCOc+mD8BwUBUBSV8FDwAQBuDKHcEAbQ3hkD KHOCz/YePlgC+mF8QYDQhDeGYEAdA5BpDgGwMoLYcw7JRBmNsHY3xCeu/OIwdHfwLDLH5/8b IWRWhhEMFEZoFBsDeHAMoZITh0kZICR8gorwhCSEIJsJw5QmfsHMN8nYewcgJJIOEp4JQ2k0 9+OoaJFvGhVI6H0kI4SSDGHUOUpw3SIDIHIMIZg6AuhSEVyJAQ1lbmRzdHJlYW0NZW5kb2Jq DTQ3IDAgb2JqDTw8DS9Qcm9jU2V0IFsvUERGIC9UZXh0XQ0vQ29sb3JTcGFjZSA8PC9EZWZh dWx0UkdCIDEgMCBSPj4NL0ZvbnQgPDwNL0Y3IDcgMCBSDS9GOCAyMiAwIFINL0YxMiA5IDAg Ug0vRjE2IDExIDAgUg0+Pg0+Pg1lbmRvYmoNNDkgMCBvYmoNPDwNL0xlbmd0aCA1NTA0DS9G aWx0ZXIgL0xaV0RlY29kZQ0+Pg1zdHJlYW0NCoAMBAZwbAiODRiIDSIIESoYIDVDBcNRAdxA MxcOBsNBATRAWy7AjIDTjBRcMhiNRnD4EMJOMRyMpYIDGbQaNBsNRcMBiNhAMRkNhdPRyIJt OJ1PJ9MBvQxtRTYDZVQhjPZ+OabRBBUanQ6tQKpT63N5zO6/QadUAaYgaUYRA4QMBzGRmOIv cxoMpXNqrLhvKBANJcNJVY77OxnMhoMaGNYpURiMBoLhsMrti8bj7jk8rl8YNxhK8hkqGN59 mNBos3pdOMq9asjkxjpsDrhkNYTkYwOY5eRdeaXoYzCd9wJpccYMxrrd/QcNPKGON7ruNkZd vBvtdfPxh1xp2d9POP1hd2IuOBdiezo+92brQxzwcYMelF6aOar3OTy/t5fyMa4owHCEhm+7 8tG3aOQK/zctI2afPeGCNO42TaPemCfQA2LWPOygZo40bOMtDobQ+58RLsGa5hkyUToyHD3R XFrRp0GyYLvF8QLioTuwgvAcNgGChBwGUFR/IKhBywsVMovLnqav8UrmjaZNG+4ZJlJkBrs0 b0JzIzhy4uK5sjHzmtUyK5hwuscLy1QzIQyKMhylYZyGGqir4qr0sIi87thPcPopOzfycyFA z7QgZ0Wn89hrIk/KHO1GsYsVCBjScNBi2Sc0jTCfUOydFxSqlJqqyYahvBShBpJ1TonVVIsc mVNVRWLBJPE1Q1g3qXTspdNvTNlcJy3Ngp6iliNw8c9rFZSE0OxlHsUl1i0pPlksGG6KKq5M +1xX9mW9Qa5t5QCXSBOtyhpc853U9NHsNOUVSleExTSjMIS8/jRzJEb3pzUC4y9Cy5hhZcrP LVscYPaC4yhQb0BwwrRySrEO4nNEhIynEOvXHad3ZjznxrMC5R1Danzq9FMZI9NIQWvN23S/ uZXldE6Ujia1DMFQGiEKgGheIzsoSKk4KEiiWhBpMKBAGS5ooKibIEKg5LegmqwAFCgBSKg1 AaIugoEhLr7KEAlrijoQYGF1thA0COL5CW3IpeKoinn+g6HooQaOBum6Xpsi6fqO/aon6JPw h41pNqDsipAAWpdTGpDuBothQIYpBSqoUCyKAqCeIQsioIophSFoapQGIUdQoIZhQEAqhT2H ZCb2sS9v3PYhAIvedlznbBB4gY+AEAc+P5Phht44QBSLoqCUgq4ag8q9IeKgiJM0KOcikygL sKnL8yEAuMShPiCoEAkd94m/fcIf2BAJwQCSEH5CCEAmff+oiggCuCAKb+33PrfW/8KT7wng gCM++BMA39PEf4/oIQIIFwJf0+uC79n3Ooei9NsRCDnLbLm28myqSBQkbqWNvJYG4IfJORSE 5oIXmTNvCxvTQmiOJb+UAmcPoXKqNc1JqhO0JvfMYUEmT43MOufg/p+oRAQP6gTFKAbswQBQ BBFKDLvnoPSbC0ExySUStMMYgMmUJ1UnlRg0w1wOY2lcjWfQuyJW3A4TEY5sxMo7A3jwWOPR /o+GTMWaqQJdY6yEZbHJX0fyNovjyDWRsdSkpskCVWPhOi9HZBquw8sZSyybOPJ0rMPpQoFk ATiQTTJNSok6UJEsiZIAgleh6WRpiVoAlrLFphLjlpVKlKqXgNjBstlqfiPhLkJScO+V6ZMR jsy6k8fElcxJoSAklM6Xs15DyOJcZYu03Y6zFlyVKbMiJtn4kNNmZE6ZFzmj3GYiZlZsRJZa jaecwFZk7noZVYTH59m4mrGeP8ciME4oHLOgxlJTGuSFPqTpE570OnpHIyYN5UT+dhNgnSj4 6m2jLHIqkpozw+pFJ+hMaCxs9nMyyP6j5ZxqPQDeYzEqC0tbdTU387zHUzp1OCWlMI4ScPRQ +oKZIfUwqNLqfFQ5aVFoqVKf0dKnz8JlL838ZaYSFlpP6hFVSVF2qYdSUBrqMUAq9WWWdWKq R2JRVepsba3Q+l0nibVc6IHoqdXioNPpqkYJ4SuntOZqmujxWKnFNLC07nXS6j9jJsWOnlWe bBTUbR8M/Kik9ezrpspOpicZ5bPTmRrSRl8kaLygOTTcxyqKMnzpDOYjANp+2wnXQeuR144z miHP23VAHVxGjqYwGlo5A2cn/PWO8nGo3GphVSu1YbInRnDTZMVLGgQ6b639wzSzIk/OcU9p rU3qPfaq+QFASQi3riyp8lYV3ag0BQG8OQaw5t+BSjC+YdwwhyDJF96ZAgWnJb89u9Ibg6Bl DOHIMOCQyRbwYGYOjXmwNDK+35OF37vNkvCaAibh3uF/b9ei+Ekr531JoG/BAaQ3B1DLffFQ IA6BoDK/a9b/woXuBAHAOTqXPBvDUGUMYdAWPPg/DqIGGCEHoaVgUBoKHzpYCmHQMIbgW4UA bgPJgIMBnpydMpFWI8nhkv7g8M19AQBSCmEHIoRA0hmDMGkMoLQkBlDYGwNuVci5VweFLO2D Qy4PCgHUMQbA0hjBaEsMoecsBUZ85oOQeQ4B0DfgsMIcA0B5yiDPLGFil5KRq9l7blDE5ifK HcNOM8ZY0IVgjBWDA6BpxjjMNN9w5h1DaG0MocgQBvDNgDLOocukre09xFt5jSuWyfnnBIcg 0hhDZr0NwIAya1DGHIMuCSt6Vv7qkNAbci5qzYCDPgIM7aG0nofRrPmtbGiXegMYdcegyBuC gO2Ndrup3oCjSWlA5h5DngkNt99KX8v9qvGod76BrxYGcgYcg3h1DhlEGoKS/govvnEOXAdg aO2M0Zy4KAyYRDoCDgOfMyguyxgI1xPtizKjLEwFAVA0a1BBmfO4bw78E1YGTIWtdZbTwbwg joYQ8lXPiUYMu2eG8ry5gTl5XnIchxZBYMIaw2bl0pjviAY+l4P4LmXomLME6WwdtTkm63uM iiY5nrQb9yBwDgG/sgIAsgpdWCgNIcQ67TCZrUMPdu8Xy6rr7NOa39hhDFfTBt9M5Bz47uwn eIu2goDDfcMYbwW6B1TmjrYZgwhjDTobKm2sZ8J4WC6LOPQZutDKHbWQdQ5hs0ZvvIvCr6+R xC+LkOs9Wca4D2gMOEgQBoDDg8MXS9p6GDbqnQOMu4bnDTukMZNN5b37U5MnZgOZbX36G/f/ AQy8D9vt7w7+ty7VDntfbONQ2bc2djMNvJuAZXa+A3j158n8Cvvz4MzXbbDsDuDwIObITFTB 7kb4YOjlT+7lgyjL77blxAByht7mTmjGrHJOwlbHjIDITksAoMq+z6DrgN72DnzcgEAMTy7m zM7HsBrp7LzqJHpvxrbsjXYN4ODXbxQNjGsAreL+Lo4MTo4OcHL0QMwPLhomjSLSbSrBjTDd T+7/MGjdzMQFDHgNL5rWLe7WwOoMYNDci+4NbRYgYMoN0HTWLFTIrKIGTBgO7TbcwNz7zdMN LtSZQ0MKcCjZTywNzB8NcNsN4OYNIM4NzBreTF7PcPjFINoOEHjbUOTSjS0J4McOsKb7Q7rY jkL9bGjXS+8FUArB73zGsK8LINMLbPYOoPD0bZ7SLm7vrIboLyEKLdkKrW8L0MD4ry7moNwM 8RDB7rwOTKjqrMjKjm6+jZgOgOcBhsEBzlzUYsx7zkMC7VrsrWD58BL4jVDO8FMUTbEArVzB 79Laz2UT7pzYcCAniJcCbZLUzyzkr04irhcJLBZ1IHK+biTijiwGDjDpTpkXaKYOoM72TkpL AFp7DFj3TdqZSNryoKbKsYgIS/sFTBh8wFDnD97VEf0d5zYFIGcfR0B0R8wxJPBDLFT/7Hp3 TK7I7/MCMdkMrrwLgFL1UiDnLWMfzmwMoPEIrs4OYN7XTWLXTVrpApqBjeTvEeslKMElYGBq EKr07XjFkFrZjoLcjxYOsdzVkDjILIYhS+4MIOwML0cHbGoMziANrToIzJJv7jwFANAOgOgO AHQF4F7gIMgOYMQMUZLOTpYFy+gM4F8s7C5v49BPpqrA0ZS7SHhOC7oh676FxqAjCIjj8dgK AJYIaAYEY/IF5/EJbSjhiABzserhYOYNEHDYDATqDUcKrOoNkcDkoJoJIKkwDT6HppZsjDgn woIpsyMSx7DmQIj17O0HDXTBDXoMyLMysy8zMzb77hjIsd8DjSwNr+xsDj0S0O578SzUrmT5 smzVwOT0Dr0YrXkR8JrS7mr6rnz2DrzzAN6+jasQjBz7MOx7xyTMETDJ8IT87xLxbWDx0Q76 AN4NbcgNwN8pzkzBIOE8TgzB7VDGcSi80KrwIOjhQFrMjo73C+00lBLGk1jck102DaQEAJQO r2h5FAbB5OUcrlsc42cPEdcCzVlDE0cHDPct0Mrnz5Do71rHYMsHEHjIrFgMYNgOtHEcs1B7 jYkGsRcHk4b0sqbbDucYETro4KQN7rMRIJgN4MYNb40YE4sOoxFJLJ4Jy+jBINjIoIQOTvru AIbiL0brLg7wwIYNDSIObaDWsXpvzmtB8dRIQormQJ0gIPMMs4qAQIYJIHbGTaEEU/IKDmra IJr6UXbXdQsd4IzQM6b/DyQ7pyEdQ2bZRzMHTaIKbITeTVLo4JIN0sjy4OjeZ1sLoOkooFoG wFDGr3zocvrKoNIPTBroMfAyrjEhFFwyTqbJ9DFE8FLo4IkrzGsmcMsnjabwwKgJKAcUJ+07 0QlTMlYqtYoFENEQjaIIczk8rTDo4IsnLXcLEMoOlRLctCUqzxzaFZNMBCVUAFAJoNMMTooO gPLy9QoJIIQjzGLzLBDiDaLe7Ia+krsRNgAJsfBVVYMlUWbmVNrXLGNcT78SM86KYOULz5zI cQ0w5OQmTDa8Anwv7D68iZQ78KsaUBTXdAjGLw0d8H0A7ajowitf0IldYhTnzFdbTyQ2MKsI 8JMLEDje9JrjLNDe7jcqY+dQsykywEEzAGIFjLBLBhQhKPsc5NjytfwO7c8W7ubBLFdeTSgO DQ9pU8bFUQLnzWEqbqtpjvB2MpDAMGDYk1LmUQLGKh0w8Zlrk+4FB/QM8MtUThEoDIU0j58/ M58btdbXdhbsDGlI0GMZxCTd7J4OC/rWL0VzTBC+6/jnjodjEJkzzmzqtxtLTF7GDX8WR7iH zmT5LzM7jhzwMNcE88DSkQDKkPjsTocd7S8RjQ9XrGMv91yZRnLmUztQkG0770IMr1QJLkt0 LcgNknjolwkMzBjaMb0ArVbBtek3tT0CrkN0kzohYMbKrFMnDWt6b815s8DF9Dz4sQTGkF06 lidPtzAFEHje96zIsWsL9fwI4KYKYFoIIKAJLIoI8y2A+BNPNfDa78DXzCd1061/d8zuGBFR AhTkt2cRj8dddyLagN9+VAmD0nsHLBNehVMKtBsL704Nr1Tmj2TIuDMz0EDgcEb5MoMAjKjQ oMtelP7kLucQNb8oMd719Kz2Ef08ljTQ6KeBLcljrmtoD/cD1kLLDDUxggROwgQ3BVDEE60C TLLMFzBzIKwFK2lWtprGNp7w1qM5IhMm9dDIb57reHmD8RrQNYU7EO1wLWjjLaFM4it99JeE LBF4gNz/r8dtlVrQDB7qrrOFeC0OzkDJ4mDpLcoMq/tEuTIptFUB7qIlMdh/WPT9sfkmrhzW 7XK/sejfgFI3gFFq0fTVtIVIkJLHhzresHD8GPjI809yp7mFr7r41SbgjuGONqYqtIErsr8s OIAEDvttyAV3jMi/0WN/DJ7ocwAmRozDLUSJstst8uIF4O+c8ji+QFzjYMIF12YF+djrMvDY DT0xIuLD8wrJ8w5vme0xc2xPwgQxaXzED/RzIJq+h1LesDDHpTa+bBd1dEIKYF814Jp37I+e ub5tVkuLwu83WggnZIVF1T8KoKDiGh4ObGDacd+iWih/7k93rg4Lh11UrbGidEjWNTOYNvC8 tTwxcKoODeWIrGtVLZsM010sDaNc9slveRcmE8Tk2mjGrOzIWKxyl2DkNVrFWKDPL0cXC+7b D0LGkcAEEMwi1/rOz8rVUd74GCubUhUdjFQFrQ0M0acG8HLBgMUVVfjGTF7ksMy/sRWEFb71 SBkUuINiR7jemkV8jJ4IoFurjaNzVLYMNwl0DXbGrBL8QMgHSBjiDFdSmogOQIGo1PmMukEa DJ4I8MrOTIoJ8HINwKeCh30nMboOYJupDNr8cJNUkH7GtSIOeqpkMdkb1wjHqTuWZ/DFUMzI e2L4mx22+rtNoN25db9PIKU8z3WC8dgJk4DFkfDEy++kp2sfT8epDlWYDLlFeUZSc3zF0Ecd 7BbnVos72vsoOlgJOirPeqFgi/8F8c0GT7jkLiGadQt5sHEHWvL0jo+zOVUrjHdK8M0AUbYM 8g94+kFwLqr5oMmA8gEgWwlwfAdBLwzM7eUEbOLe+sgMoize8PlhVB7qi+8nEnWO7uFzUYDQ 76bQFv29OUUZwntwMaW++irpWlGykHsIrN94eI96jW4MULM+O/1I7UlYpzLrcd69QKiBtf19 UqEY2RVeQKQIwIewjml09hchAxrlzqkRdMsh1A4MtBLqtglVoNIMUq0JLwNsEbT/zFj57PnF 6JvBkazF8QWlTuFmmazMsToN7HzeoMjRmWW86MBORs+f+jglOgdlQs2MkPMKp/VmsRMa7ktm bVnIR/9o1JldeRW0t5HKgFEgINLn2ud+Tm0H7bDBFEr5MJIO7+NsnMjmt0FN8bfNGUjysd+r jabM7eN1jonEjedWjVXUzak4D9+u7fVWlh52LyGxCZQx2F00VDU5zuGHlDmSLachraYIzBkO LazuDGNUjSb8e4I7uS4FD5LXgyeLU2o7mgBuCIej47pqV8cPWg7bHacYMHnc0qORVEOQdSrV jxUErGrWvVlCOZ+eUHl+ebuewyYoufJzOccuEuWc4O+dIFGddO2d0nueFOwF+A2luektE2bD KwzJrYvk8s67ZOCorJqJJt7LZPpVJw1lRxJsxxm00S9lrVkDJErLDAcGB1dP9y0pcdmXQ2a+ crUD7pa+00wygG47LLvqLL8djrfqwGq+cEzGoMLYA1xMvqEpkGXql2MFdtXpw10jojnsPuB7 ZzN5p2vs/A+vEHjYBSouXt/qXpHuUTOmlU9ecBvr3sBaXvbJ9ncI0JEXfpwz5PvvXxAFGJ0J 087laNgu3zkc/xVzLZ0UkLYEAF31vpxX1Fv0vuPercuU+SkZYnY/n2TA3z880KBsCsxIHw7J zjEL2EMZLLA3aG8gs3Xyc61wNwdwt7f0QHA8X3a8urETbGv1tvwk5J36863et6jGd8D+77RA fvPyXxEO2DFcd02bLLI5I/P67/TvWlUrDrt1f0SOH0n9X0wGIgAgKh3BooN5mEBiMpjN5tNJ uM4pKhqBowFwxHAgFoxFw1GQ5gREisCggoMIgLgzGQyMhlEBmMJjOhvlIyGcSikcGw3GMajk ekBUkQoOZ0MJuMhhORkF04BpFKgNgIANZW5kc3RyZWFtDWVuZG9iag01MCAwIG9iag08PA0v UHJvY1NldCBbL1BERiAvVGV4dF0NL0NvbG9yU3BhY2UgPDwvRGVmYXVsdFJHQiAxIDAgUj4+ DS9Gb250IDw8DS9GNyA3IDAgUg0vRjEyIDkgMCBSDS9GMTYgMTEgMCBSDT4+DT4+DWVuZG9i ag01MiAwIG9iag08PA0vTGVuZ3RoIDUxMjgNL0ZpbHRlciAvTFpXRGVjb2RlDT4+DXN0cmVh bQ0KgAwEAxEAwFw5gkCJYNghpgogJUPNUFFw1EB3gcCJogLZdgRkBo1GA0Fwyiw3kYgNshkc liw1HIgNgNKYNgRnmwgI4NGYuHA2Gggjcdj4NOM2koypUPgUGGQxHIypggMcrpQzGUVGFSGI yGwuGI2mNWGVYrVcHI3sFimQNsowno2uEDtNrmMzt9xuddr9hu9ustZkVcr12tpiBpRhggnE ivo1GwgGY5Fw0ssqllqGA2G4gGkGGg1GdtxwuGeQzwxsA1i0zkUGG43HGp1etlmw2W0lGj1w wgwzGMEGmq3ek32m4OerPBv+v5HCrMmgnOzedy2Vr2eHOUHIz0fXy2RMYNGl1oPg7Mz8tqpV S9GR8tftOz6/M7Xy3PXGEE8fxg7chmHDTBkzr1By/DZwCsEDu09ilhmtSEOE8zJQi5L+u2g7 vQqg7kt6gzqw5CQQOc4CCQUGCfxI48TMlASoPE27nxcFwbBmoMPhc2MEwFG0cRlHbJMoGSUt 61SRqCyaSyKljVQSygcBxH7BpLITKhw5q4BdJErBpLDjJ6GMAMooCpN6nr5ytMrjJJMUnp8G LZt6kjutHJQcTi4wasrLrLt6x7IyUyzeAaMzMpKGkkq+HCYMwkS1Bu5IZ0XRre0hSSv0TM1D 0jE6vu80dHoO1FJrBScVwFENShjU7xhqGKDBtB6+1O11YJ8yVaMjV8j0TXLKstEjgy3X1StY qVXWHLjPpLG7SWVX1mUnXdbvpWNX2FWKl2YG1sVdFMts4z1roJS1RvhckV0u4TQBul4YXXcb TBtGNRU7KwcvK4z2WK7l9XMGV+tMGs5JYr4bw3JTT4K0s3RpbrIt7PbLKlBWITZc8rBhbE5y rJWN3KlkkwFRlCJEnr2xpkswXCzsFQKljo2LAWYJFJ0HsoGF8uMg0pZHUzjNU1lArUy0s35J Oihlo9EUUn1K0KFQGiEKgGheIzOoIKlDK+iymhBrsSKXpaKhAKiVoEKg5JyhMOoeNakaWzoq PGLYUCGKQUuCFAsigKgniELIqCKKYUi6KglJynAW4QnwaMjtIiKQuCg7opCutmKg7gbuwqBA JAQCKEHR890Qh8+EAnBAJIQdOIIQCZ0fU9CEArhAKfYdpz3ShAKXZCeEAjdl33cdf0fY9eIQ QeB33X895nV9p3HRi4rCCcNxG2IohG3pCkl4M7yPOBR0fcCqoX0dF33RoImKYht7HEoInCwt NRiHipyW0vGFFWBSFQNTVgjEWa0oZWBU4DqwLURYsTYWzuKJy5oBoKAqBoDeG0MIcwQBBBcC AIQZQ5BzDeG5/8AWrlhIG2ZQyAmvEPhYRmF4NgcE9ItA9EB+2zObBQEENwYQzhyDCG12AYQx BviAHSIwaQyhzhKA0FpqiykWieRVpbZn9Q5gmFAMIbA3wbDZEgFjrXjL5BnDgEAVQphBibAd r8B1glAJJDVtBYClwSgoGgMrqw5hhDCGN1IZQ7xIDc6sNwcw6BpDoHUOkeQzRGKEGEOkeIMS HDHFt24Yw0gtiaQKKZo38uTMvHYMobgxxLBBJAEEkY8hVDcGkO0IA5yIDyCAN4ZnWxBDEHIN IZAzx5DTBqCwdQ5hlDICANMgwwxNCo1IFqIAYw1c23YMcwokBtBaGSJYaQzhumICAMQdQ0hs DJMcM4IAzBpDNIuUZKpjyKDK9UkwKQcAwBRBoO8Ww1zmDlBd+IDZluXVZFgFEqiqSjkWHKWk tghy4l1LyPMkZ9h1DOGglUxIlB2ksGMN4bA2Bll7MpqUNypOWIMmKaEE6NB1DkHQPIYQ5Bkg 0GEN0xQ7hlo4C2RdM5uhnpdNiQsHQghthGGeQ0qY8UggieOZqW0U0CDoHIMsGaVSmkQCCYMw 6Y1QlOCCbEkKKQYDnPmWseo+R+CdICQVSIbtzh0Fx/qZYng3QIFwFMYQwkqj6GiY8eQ716DH RSVFBA4TCopWOu83w6SagBP6kKW1Gx2kERecIbJ9RLDQGyWcuZAVbmmHChNRo8wWDpVyXQbq xS2DyG+lValiNah1X8N4aZSz6gvKeoQbpyh0pqGyV9XJ0BmhBQYEAa5j0ws/RoM1wAygsqRQ OqMYZHWwo0GySFy5T0zs5BcOFHZFggmHaOsYQw5B5DhEi64ZLWFdrZBMItKg3hjvHeUEAcJ9 ylotbiDQZp9xCKgDkgV5r6RLoNB0I1+6kVLN8ZGOwSqZB1pdLOiFqqJkQDrNyz9/TIyRl/N6 cE4pyEXgzKkMs1rWIppOCgOERsH1WgvQ+LtMpThnh/R66tnyTECvheSJEPwwhwjxCHEpW6BV 9i7TWrUqsjxdDhS6Sgacl3dxCG3EYYpYS0oQHaX8iIjRMsXP/BB2Y7THtBWSPsf5AwjkJIaR E7gQBQn3jyIWaAh3ancHKtUWG7BTDLNOXVLJ5AyBRGG8WOqNhvDOHkFINAZ6BvO60N4KSygo nHbhs0eIjApBaUoFGiF8goBdP2ThWcFP6S3CikhYF3Z4jvTINcGrzBtlniO7Ybw8wg0wDgFE 8Aazy1xEyegIJRhsm0GinM3Y9hiDFJC2UW9QAgk7FZyZKXLYoo3bKWbrJ70xDFR2VMXZDBhl nYGPGaZDyJu7I2hEjbV5dpC2Y8dJQa3rBRbeSIc4OhJkHhqDUhojbXslRyVN49umMldHnGEu 6o0JxKDcmMdq+7ijzfTQ0QIhbZ0bw+0dVeLbCDXi6b3BsSrYjtlINuVKEVjkRvff9lItwioq G6Q+aIRx5kdbqLtY5VYlRVBJu19NMJiBRxOIOugUqRnqCCqEw6XV/6Q3oHIKIlh1i/Pav1FA 0Bht7FvO2mdAVRDJZkMso5+z/hva6Cdg9ty/jxMUMWEI8BpoQGGRUFoQ6fsW1drMKgGmUhaQ KNzFSoNlgfHePObuhBtibCcyMBSGNf78QJYMZYHRzxNQIKQbw5wah5NiEPMpbUEoXyWhsvYz ytlfCGWWjsSbscuDWkcOrB0HiHEWI+/arBhmLQThFd8xX9KlJGVFd5Yh4sVAHsmpeGzR3nCO SPTdMg16h0rOyXgUdM4lnCWkg74aYjLpu8uhdDzsonaPKmVgUrdBRJpw7icvQ3crUpEBWKBU 8laHqbvEMzWR3xmrc11q7puCMAzI+pwvUq+rZA0MgmtN3tUMTurpig3A3rRpVJBgypXpBg3g 4JRpupEINAyA3stpzJHA5pMKDJ0LZMgsFH+A7ojA1oOoKuIs3uKCLrVJxJTqOA3iMOkqog5K /sqr9J+PWH9nJigKBKXLVLsKCQVg5QarzQlJ8sdgyskQQu4wKA8KcpsL0QgjVpPPlQMpdA3p iucA0spJTp7pZr9OftcLaqCJxpDIgAxuYpCrPpVO4OxrGjfOzAUILQyJsMlqVspOYN7JNtnN RNoEQCnvLPMINK/ogg4A0uZvctxvrwZMIqJKKN1KENaqXINJaxBtnpPkQIZKBOJMUo9rKA7s +pyIwqoMsJYoRowgzMKpiogMsrcIwpuAzwIg0tlIRsDqRN3InP4wuIJqZJirtqZJWrcIOgkK +MQg1LYpuJisxN9JvJZotAyOvngqXKoKOLmQgxgAUAoQooQIhqZr6g1q7LsPLpeqEKzpiOrg 2wXNxg4g6olw4suIAiyk+DWCDxDEtjTqBKxoLCMLzIjP6A0v7MxwRolOYQTI/QnNGqxsiPEL FpODVJPHJMECuqnIupjssLusjODRsOkphu2NwrvQSSGpzo/KNA2g2pEJ1OFPWMvxhnOm9OgL aoPvOg3Iws2xxqEPQtbAWgbOgyeHaq9A6JzqbJigiJ0OfgbgUSlIwglA3g0ISP1rGHJuRQFq TNVAmgxgmKoyjAlQxpHvMgytEOGNGAhg0JdINAmpEQexunPqXItr0SsPjjfKRm6gUKzuEOtm 9s7DTuoJENbDLNGPNqoCMAngyLMA9A1g3owgqJ5SiJIA5sHLiHlg1ogwItHy8N2tTw8NVRii ISxAWsGAxx6JTAopwA5x6Lqs7DRNPNmtMkax/FWRhvCSUSGJDyViqILyXg6SYpsJMQsOBg6A wuOsxuJPiicxPtSCRsTvsM0ODuYKbKOw4MHOWQeLaIhJVIjQotlrKIkJ7qXxfNSnMvYQ3pKJ LMxPhAyzVJSOaJbMKwOIwqoumOcS2uwsrQQt1vjLGlYMFPlKagytWx5MBCLyhG9gygdTftMS iNJrctLLxgdtuxHAxt9slg3Rkgzw7StOzJpNHyhtJMPzvuBTSPtmAvvMdogMfA80LQBKipRv tgWkb0WRHpkA2P1Hsy8jhv5okpIg2g50LSWvYxeIerKA3A6uSxyUT0YL5g6u0o/OOtEQtCtv XnxpFq/pWzVUiQptIAYt5pLMpJI0RugKYUis6PZJhs+JZULRi0Pxfo7U2qVPUpRgzq9oQJyO 7IAtQzbRQKmHMyuNUo7QXtyM1ruurxOLkrZI8g5slrZt0JToipFQpqWOkAyzmyLDTRDRgKSx EU6QdweoQowrEOPpKphK+VVqtA5urrS0JpGQBthM/UrlnOeAUA7pELAQIQpRJoggQK3M0Amg 6piwXtLongaNNgUtOrmNf1TvgA6OiDPujpkzPnL0BoJpxrkrguYLvIkLxq6IwqazfupQwg3L MPbus1KwJKauYUrUAHLkINVQMwMNuPgpUwxgyoOgrvzyoAygUtfuESVIlJi0qvnTBsBKXNEt cVSINJj05CwJnqBT8LCvPtxz6g6KYrsIMuOxIsRiLoLNgA2JhrvJgpxMSgaN5SW19nbsWr5g y17VVpjA3SPpupxgyA3NdLR2WIOgnskR8Ssv4sho82cWdCsAauM2azC2TQcJug6g4KgOAT3S 5oiLVLRgciLVtzmy8yNtTyuo7LgKoVvV6rt1WI8uSOTVGTlwY1gU4xvnLMvw81ILhKZA8q+r gzupUwV0FUDNXNvA0g8CVPmA0KYwJKjvWAUP9typ3U+znRC1Ajgzct8JTxsJEUczjtxwdOlq KVfg2xYLVKEJjt0IMVNtnSLzbkvKnXMU6s+pZwnVXQMJ7W8o8Qav8XF1E2ASZpnN5AyU7NKX Q1vtwLQKoUEWSyQpaQMt8ou0zXjoLMSoq06UpTgpFxjMesqsQrduWW/qK0moQw5tx3cWuTQP lP+r5utyoPDoOgmtLinuoVKWrrQWSrqKDvz1lNPysO8IUmtu9myo2iBECDIiTI4mzCVzdAoL qJSvEgjIUPGI2CHoD4AgQGAmhYCxgqmMTgkrULVPbu2OwpkXuuTXwQYPDgQLUg6wZ1zL0xRI 7OrresqJ1psNhPTpuwfzvXNAwpw3hQ4xq4TXQr0jNtVTkA8CHLzKCRMNEungWt+TANcS0YTT rwcJvJdAxp8pvpw0JWQwD2IjfOG1CQGrVKsMx3cP+ommwmvmwlJiDCLEiE9o5IJgYo1vHCMl cigkiDBYLG7N7uMqYr5ofUR33AyK7psJYpt4atLysAWmSXT1OxQVPktq5KBJJpJNlJMKZN7H lpFJYpsXiJfY+wRupLyqp1MsA3xnL3VVRSGtKJj1IO4UkNG2zV3rPp9ra1JgxNrAxqOsg0ss UKXLiRlM0uEIwqCXOTCzsqtUaXQofJTSX4iRlTzjfT0oJoKsNuJKhJFxFqNrqPaZXzSItouA 7oNQAV0xtpXZTEQDRKBMP20sqrzIMpYyX36I80XJd10pj4jXwpC3GJFqkURSXWMtEC5TZ38m sX9oDDZo2j6CpAbjQ4LG0odAg3Do8qzszpB4yJ3AdI1iejR4ACwF4CBjz6Fk4vBCVm7M54s1 jutjy1lnMNA2AnyLxNMNFUWPwNEAYzDx0pis5g2vYxyM9U3M/aCSNvGIXmvoXlglYY8IHsEI cW4xhNVTJlWX0ohSdIRJBsNs3NMECPo2BrwJbIeIfQZAmWrPapdIlq7CqTAOntCMeMfQTysV OIo1PWvl6KBKNJCupTkJSJZsxItIuIvIwIxRl5PKrMNwcQKV0NhtipisR5z16IuNavp0xbBi qMYPy67zkQ4P7vyJYIRggKZawoggXSW38Uew7nKodX2KtXRojJJ3MWrVLKCAko9sy6KP9Z9X c7KpBvyt1KZwEzRrRtiA6A4AdAXgXg77kG9NFgXQAJBbR7RI+gXA6wWp+gimqu/HtiEgQCFi pCMIDiNjyCuIUCrPXCBoUCZiamqIBYGu9Y3Cp73YJL/YLH+om6ioXGykCCYgcIF6HEtjttVN KsN530mJTYTpTqwpurzPyzkOO3l1gisAZbZbaKzK0Re5Ejf50opvXOGtSExKBaLpFgXJ4DRg nsLZ2O48EJi54LtwzpHJ4AZVD7ZqyszbHLIIR8RCsDRgptxuLYZOCqoPc3mRJUpXwJUIespX HbrCkCLCMC3AbvFitkdCLCVkvcoCstU70Gpmq39aiLHYICStUoXvXCpIG6SHtCDHuCBG4U5o dVDyFwSyVpNlECpcNXonJPqzgSYOw85GA86Ghc7Now8ziOEcgpUzk3dU/c55GcNtoamQ8rBW 2yKdE8+9F9AOyyApkISSK9Fc68OIIodZ7zrs9pEpLOl8+Fg9O9G9LnLG7Q0CsOgvEa4dOc/9 PQhKB0KTwpKg2dT8/IqdPKBwcKe9edK9PdHRRz1zxWaJT9h9UpP6mTcphz4rZxO9N9Kdm872 MxBLFk2k8tMtR4LzRI7XKPcJx4eIkdmdaR/S9KnXNWFQeQEdq9Ud09nc2HxufScM4XQLV9Zd rd5nJG7bWa1Uxw4tQdZ9fNoJ6s907Va9J95eDpP1cwWXYg4WgineHdGZHOHXaSlpTg6d0eHz oC5rIZ8v+J3eP+MSM9VodXfVYJaKVXhV4G4+L9Adbrg8kmq7ugQbwgQGEDO8qEVeei2iaiAg DWVuZHN0cmVhbQ1lbmRvYmoNNTMgMCBvYmoNPDwNL1Byb2NTZXQgWy9QREYgL1RleHRdDS9D b2xvclNwYWNlIDw8L0RlZmF1bHRSR0IgMSAwIFI+Pg0vRm9udCA8PA0vRjUgNiAwIFINL0Y3 IDcgMCBSDS9GMTIgOSAwIFINL0YxNiAxMSAwIFINPj4NPj4NZW5kb2JqDTU2IDAgb2JqDTw8 DS9MZW5ndGggNTMxNQ0vRmlsdGVyIC9MWldEZWNvZGUNPj4Nc3RyZWFtDQqADAQGcGwIjg0Y iA0iCBEqGCA1QwXDUQHcQDMXDgbDQQE0QFsuwIyA04wUXDIYjUZw+BDCTjEcjKWCAxm0GjQb DUXDAYjYQDEZDYXT0ciCbTidTyfTAb0MbUU2A2VUIYz2fjmm0QQVGp0OrUCqU+tzeczuv0Gn VAGmIGlGEQOEDAcxkZjiL3MaDKVzaqy4bygQDSXDSVWO+zsZzIaDGhjWKVEYjAaC4bDK7YvG 4+45PK5fGDcYSvIZKhjefZjQaLN6XTjKvWrI5MY6bA64ZDWE5GMDmOXkXXml6GMwnfcCaXHG DMa63f0HDTyhjje67jZGXbwb7XXz8YdcadnfTzj9YXdiLjgXYns6Pvdm60Mc8HGDHpRemjmq 9zk8v7eX8jGuKMBwhIZvu/LRt2jkCv83LSNmnz3hgjTuNk2j3pgn0ANi1jzsoGaONGzjLQ6G 0PufES7BmuYZMlE6Mhw90Vxa0adBsmC7xfEC4qE7sILwHDYBgoQcBlBUfyCoQcsLFTKLy56m r/FK5o2mTRvuGSZSZAa7NG9CcyM4cuLiubIx85rVMiuYcLrHC8tUMyEMijIcpWGchhqoq+Kq 9LCIvO7YT3D6KTs38nMhQM+0IGdFp/PYayJPyhztRrGLFQgY0nDQYtknNI0wn1DsnRcUqpSa qsmGobwUoQaSdU6J1VSLHJlTVUViwSTxNUNYN6l07KXTb0zZXCctzYKeopYjcPHPaxWUhNDs ZR7FJdYtKT5ZLBhuiiquTPtcV/ZlvUGubeUAl0gTrcoaXPOd1PTR7DTlFUpXhMU0ozCEvP40 cyRG96c1AuMvQsuYYWXKzy1bHGD2guMoUG9AcMK0ckqxDuJzRISMpxDr1x2nd2Y858azAuUd Q2p86vRTGSPTSEFrzdt0v7mV5XROlI4mtQzBUBohCoBoXiM7KEipOChIoloQaTCgQBkuaKCo myBCoOS3oJqsABRTYUioNQGiLoKBIS6+yhAJa4o6EGBhdbYQNAji+QltyKXiqIp5/oOh6KEG jgbpul6bIun6jv2qJ+iT8IeNaTag7IqQAFqXUxqQ7gaLYUCGKQUqqFAsigKgniELIqCKKYUh aGqUBiFHUKCGYUBAKoU9h2Qm9rEvb9z2IQCL3nZc52wQeIGPgBAHPj+T4YbeOEAUi6KglIKu GoPKvSHioIiTNCjnIpMoC7Cpy/MhALjEoT4gqBAJHfeJv33CH9gQCcEAkhB+QghAJn3/qIoI ArggCm/t9z631v/Ck+8J4IAjPvgTAN/TxH+P6CECCBcCX9Prgu/Z9zqHovTaGV9vycDIkzhK WBph8SJuHeo98lyQm/OXBQFQNAZSBhyDeHUNwZAQBmDYG8N4ciaBvDcHQMIaQ3BzBAGENwIA yxFDlEwMcNgwhyDKGEFgIA6Q1K2GkFrXmwECBaclvz24Xn8fG5gFAYoohyc6DAFAeQUqtBQC wFMcIllbiq511oZ4qQ7jyHMNoYQ2BsBAHMMobYkRVBBG5LAKIgBtiyGEEAZA0xWDGHSIMcoP gNCoz6F5lYYxqDmGgN4d4kBnIrKYhUSokSNdSbMFAZQ5hpDJE+KcWQxB1kKGUOkrwxBvj254 MkSgwhkDsGWNwNgbAoi/J2T73D6xpczL+WobpVRbhsHcMoZQ1vnNuCk3AKIlBlmTEWV0TZtP 2iTL8OgdQ6R/h5K+bT0HpSelAU5yD5AUBVDcGmZIcpah0jkDcG8dYlyADnEYMztQZAoDMCAN 9DQWgyoOGYNMUw5gub9FyhYYaGk9ohK2QNDHUtQpHROez05owvT7GkFETI/BsiUHeVkRg1w2 DHFWG1EwQBwDZEyf82IsymDrNcM8WQ2zdl/NiME+HuMHb8gByjb5qUxjdGN2MUZsSJieHQOc WQxhvDaHCeEypDh5oXImsMXY2RVjkDkHNCKdzxDlKmO00JQVTfAniUYKAxhsivUOpNCYeBhD HWOHVTQz0cCDE0N4cInyHiNJcO4YQ8lbivMWp9LSdvin4HUOEWg3x5DRISiMPogRuLzQiyNk 5NAgDEGWH4d4+UPizTajIaAQWniVROjFGqV1QjPKNzMe6LSQh1Dyddkq7hwhrVmR9cQaAoBd Hd2T+gzBlItcCjMtIlxWh7EGiQbobXOBSouZ1w5ouTLM5aUkRKlBvoXeGk7rYbBmvIHQO4b5 Jw9u5fYuss7xxCi3FYMsWb9B1jch+10Qpah4uvXp7gNXvVUNLfAFAQZC0SDNcG8Fp5kkViCG uj8v4iBzB1AKHVbQkBQrbEGzte4XFDBoSumATbERIk1KWWlHAkzqi5ZcNga7L2ZleGaHERcP RahrIjD0X2v3EK9hrEExrxXNDTH6IlvQ32CiVfqIVSw22zoFOAigcL6B0sNEvGb3Ab2gAaCi Swc6gWYIqGmLZRg6yqlKG+sGTZ10fw/m3MmZrf0NynZ47rRoZTryDQvPVZ7r5TjEa4nz2nuE xr+EaHAbbezKhtfy0slsP6iyZa+JtH7LWYiVYKY9pMnBlqfGKMmmoXpKr/eYPGbLBTJDZRwJ GotZ3ip5EsM8R7IYfu/liHMgJ66LnyZHR0arnBpuhMqWND7qXWuxR2nVX60BpiVTiydos857 iMGLMEWYrhzk5Pezxkc5WAtPJettigx5PizOuQYctgQ5iVKbNgZK7huDWUaxAaIkYJzfe5Ht fOIKMphEyw5NAw12lTD3HYbM9WZptsQNkOt90kkRwAMsPMuzcm9lJsFLa+Rnn3nMMmrqOQ02 JseQgc7Sy7l7U22Uwg5TF1DeKW4cwx13DFKnN4KJ1zmq/OmJ3C9BRcDhDgM8UQ20bgZp/J25 LNbAzfC9qFf9SSVDTqeK2qbJarsqHLI+r7Ngg3RbGJmgLo29tRw+F6Lar2qxkiqhAYdkyv1V rK2dtQUl/8H4WJsqM90qpFle8OzwyXsZ9xBTdxundWmVti6Pi44gpN5t6PHOCFRF8/eQO2Xw 61L6rDaXYaQ2SWmxK3zADeIHie/xMmVMPD8Wp/rAOcTA6BsszWOstgsJbgspEfuGriB0A1HD XsfMa/hprLFYOctcu0+tnxuV8TCOguCHRwIvSO88GDDKibGlWwLlhM2Q5wM2NtSJt7tqTkoX 8UhkCIlsg4qWiKDSy6nW32kIDWmCiqmKB+3Asy2O6gDkDy5Cis/guI4k760yhkyC1mw8yuiy p8sUoEwStkngiWpotKuWrQ0G7e7ijs2k9076aM/4MQxwhkno6sDq3YoykODgsQloizBym3AT Be9TA848DMzYC4BQqehCJkaMhILwYWaqe2w2DbAuhCKWhG90JgUKI4jGPSjKhawwBgBuKKqu tonM4yiCC4BSkmkBCGKMiezQjmdamMkAv7AHDqJUnIK2iAiVCYuHCecSb/C8VaI5CqzmCDCx CcCMhEb+jHCnDA1ue293BpBlBs7MDe9ol8DnDc5ui4rGDcnOxQDckI+RD+rq5SJotOyLAW6G pq9oDY+uxq780eDyDgozFQsyxEiohuhytGp8wOm6okiEwWiEsksisE+eh25cyoSE2qBQ42iq 8s3c6o8gt4kpF0DKimybAQyLCOtOh23cDdGe3mRKr+2SDO/EiaDKz07zB++7ALFOniicDwzv HrHpGMy84KDLHOnyO6e8hkDE4yDLFClohszqDGqO+8iSw8niiasEuYtKrGkKDCmCijFM36De 7GKdBuzmkQkVFPGS+4q+4zHora+EtjB+uc64fup2DcDc0AkOsw74J2MApgDaDq5LIwhyzYnW +4l40DGGyep0y+qDIzJQxTCOi23JJuO7DQhkoWk2B3A9KEDY0C8SiImytLAPKRJ9I0iDJekq tKDKDxIAr65mBQskkyyc4yIqm3FmkPGKrNB4x85UoDA815KAv7I8hgpgDyiuoEp+mUtODg3K v6t6uWish5JamUpq4Y5LHYxG6S5Sz1Fq0fK8+0hszsq+iXKAi4CS+KsQfou4k0ia0inc0pEc b6b+cMaWhOOcByPQ/wjUf0CuvSvwm9NBA9NU0mnjEHEfC3EMJcJlNi/oJ8YmhWame4KsxqNm w0w4i2hyDOt4ua6w60rTIul2iU6uDe6ylokQh4yUrJFqwwU22qmqsjB6tik1F0DHGu5K5Ym+ MSBqvSrmiU/U5Sl5CIiUDaxkRYwIxkwpEur+zA3Ko8DCqXCzEeI5CibVOQT8IEKeabOa92wu jUCaiI5qjkmY28k7C1EKTgIwJ9EU92xxBqNDJAfKI6zWBAvMIs0PMgvsoqjgruxG+Ej8zYiC DS3E8uk6BbRKBBDCxwjNAyJ3DM84y7Q2h3JsSIusnZCRIMiXCU20oqBqBRJmy6/JN+nfHsCm kSi89zRRSQNC9+n5JI8WurBC7a1kubB249PivKkOrIhskGm1TxF2kNPeoywm3kxpRURuxysz JciIkI449arvHtKLISIqDCiVEcKBRGIQIwMcezCsClKXFOkMCm9dFMw8qeq0ImIpSLDGpdGl AAsjHGqahsCKDiDrU2DnUlOITgX3UwjUl0syCmkuBACgl8rQCm/dSuBmdbNQBaCJMEmXSzT+ emBbVvVM1w85NyBqjg4azaDnFODGxNSqrspOrmsutYuqDJWaaFQdUo0uMpDGcyCo8WoeDqlp Q6BSTXRAnvRFQgIwOzEU76zlRbA6nWpBW8jGurS2ibRnMJUap/OzQWuHSEbdSJErEyO6w0uA rQzEkGkNMfYQyFHeiEv6DkDWyBY4icnO42m5L/WK85FQIHK81LWvLgiIp6oinWCHQWjYlsj8 iGl6j865NzQ+1owocoewphR2kq+5PG7otG+EiuzYlfDU2SyYDmwYhwuWlSxUoTL+QmquilR8 yYkcuqkiiylqDZL1AMi43WsErE4ssE49OsDoiyzUwamamfUAe4TYpgDoiiz0t/ZGyI2CBACD SsiE9svNY8hsiQDIl5ZynomEoXVnBi93TQzm+FM9G6yfQa83QhXS0ye2czNyjo5SvMDnXkoN XqhBOHUoMmKLX2LNIGjUeIf0Dmtq+eDkDoo4CbJ4t4qylks242p8DUhzd2oPU5VnSDdVYhDE 01QMqvDk48rfd2Bw9G9LXKhDQfC5c3XWhmDQwZdHJsOXdNXNEgTgVFVwcovgfKliO6w2xJZA krJsJyoQu2IszrbysRFM64CiDrR9aaDdYbfJWijMJ2LFbwi4u8o0o4CEDqD0D1KayHCK5tNM 1Jfa6ux5MhI8JTRYBQoCdqoOszO6oKurdvRfGUqAhs2Sm1GOvIjYljSyivW5LgrGooL0ogm6 9yaqhlCYMiCCCbDciy5GDc5LhyBkB0/sChh4BSzanikpCYBpiIBhiNFBUlesb/ew00cy08lt Js8ZepdRXwJ2aVVOn085Sk38xkjGmasIkDTFJI3St5Y0iUDE3jWcIwqlgAmlGlYO0TA9O+6z QXTom1V7Y+4Slfj5aPAu0ZA2jU5wygj3EkwJQQwKc6djYxLeyEvpcPZHXaUxejXhe6sykRbo pY2mw0rux/jIi5YCmVYLA/Tei5ZqzKruDJZyCGrJLSqrgyrMrsf3LDDYkcmasyzE1nV6kRIZ UXk/jWmGoOo4Ck9eDhhsr+kRHnS5cFXCsOzY9QCK8JbSjzLtcximThirgCBgos5iPhdccyCm 4ywYc6ofdJSyiyCmuXi0mbi5fEAaPROPjDnHQyqrfOdkCI+kpVSEmaoivJkFfcrUxWDzeDYb nxeRSNDIfApen433E4ingQlozYvNgk4TIKh2lQDIi25ujfWs9gtjald2dbZm+taCr+m4DEza DIlODch+1jKcmwo3NbUpNgIehKTsIENuVQhZBm849RWpSyxKz/MROFczC4hLQlp+aeMxNs76 chPQN5qKi4hokudSmah4seDdVikNNyNMkhZBqVToCNUgzZU9CVXDaBbqa0fAYmr+CLiBAmDh VBCYJQoqJWCMDKDFiiynXvqcL9jA1wKdkSfKCgsEiKsyp9PDLgoWDq0KiJYaTkbfjteXRUMS r+6TFyiNU4rU3IqLUgt4DM5JfvDgsODYDPR6i263dvmADDltTNFuznUUz0loxWnWCkCSCgCK CaCJjOIEt9tPtTH3O+zU+KkNjjZQfFPQqshkCQiYiUCIDeDEzMqaiysek0y6CEvokQqDMhtW BACEiqDpPPOdckcyChpSlmvMtpKtJWi5qZChC4STVxXYBSBsoOy221RDi7qcPLsPc6dlCYkp uMh7uQiJh6efwDUnQgKbrpEUBQCECKCCc5sHwEb+NdUvEUfK4tvtUpEkJPVLYiBQCYCSCeCd VpUoOpwKqjvZwO6dMU3YDfW2Jo9BMhDdYVN0khuW52tksyClvDcAh220vVlC91xhofn0w054 ia+ECK49vMDStPCxV8hwinMvpwvCvPTi3IhqsPutkPIDdcBQCPKQkHJkizCYCLXJwdUlvub+ KaOVVwBRrUvrrav42Prts/rzHpxdQgSnxjSiCngoq6jcymjGOzjthujUCZG6nejcMiwICc0A vAlflorKrOiECmDHa6lyBACsj5qRb+N0LnqZm+eoorXVeU/7sVe0hsJgPifxZtljZzZ9qRrO lNGEibTDmK4/y0dSrm0ADfyW1teTEs77QysAy/ECa4BgjGJkCC6vsEbBsJzrxNVw99jHdxJ6 mDBPO+k1IsoSkJtGrapzjk90KaNvydWlFtv684lo6SlPv4oPvLDUkz0qdaiJB6+UqWkcof1G lpLaDTF4KMoyqyoP2RTJqI96/7lwsxAGrBtlUTteDKxXyKiaCk+ovq+ECCksefQECnyxq4q0 BRDqBvDvOFNdVti/p6JObfNqMCJWO/QscQbKP8cZojeXA5LLHvLbvT0YcoZzDCdXDRSPgJLg m4zykLVEWqSBeR6Tn0NDmhLrzDLw1qOaKL6Q7L1hSTGkDfL0nXL4qeMZNoIT6/6VYlnG7NMV MEircebBDCKBEoIn7BnE94hkudMPMTI6ymOozj6p70zne2h3MbVEOo7L7ZDH5+znjelWt364 XZ7WWl8MBRMop1Maz0tJ64SKJl8c006dM5B9M+4z64JjxP7z7b0g86hsCdNPssymMYYn0d8x 7aBRS9NYymbEAaICDWVuZHN0cmVhbQ1lbmRvYmoNNTcgMCBvYmoNPDwNL1Byb2NTZXQgWy9Q REYgL1RleHRdDS9Db2xvclNwYWNlIDw8L0RlZmF1bHRSR0IgMSAwIFI+Pg0vRm9udCA8PA0v RjcgNyAwIFINL0YxMiA5IDAgUg0vRjE0IDEwIDAgUg0vRjE2IDExIDAgUg0+Pg0+Pg1lbmRv YmoNNTkgMCBvYmoNPDwNL0xlbmd0aCA2MTQ3DS9GaWx0ZXIgL0xaV0RlY29kZQ0+Pg1zdHJl YW0NCoAMBAMRAMBcOYJAiWDYIaYKICVDzVBRcNRAd4HAiaIC2XYEZAaNRgNBcMosN5GIDbIZ HJYsNRyIDYDSmDYEZ5sICODRmLhwNhoII3HY+DTjNpKMqVD4FBhkMRyMqYIDHK6UMxlFRhUh iMhsLhiNpjVhlWK1XByN7BYpkDbKMJ6NrhA7Ta5jM7fcbnXa/YbvbrLWZFXK9draYgaUYYIJ xIr6NRsIBmORcNLLKpZahgNhuIBpBhoNRnbccLhnkM8MbANYtM5FBhuNxxqdXrZZsNltJRo9 cMIMMxjBBpqt3pN9puDnqzwb/r+RwqzJoJzs3nctla9nhzlByM9H18tkTGDRpdaD4OzM/Laq VUvRkfLX7Ts+vzO18tz1xhBPH8YO3IZhw0wZM69Qcvw2cArBA7tPYpYZrUhDhPMyUIuS/rto O70KoO5LeoM6sOQkEDnOAgkFBgn8SOPEzJQEqDxNu58XBcGwZqDD4XNjBMBRtHEZR2yTKBkl LetUkagsmksipY1UEsoHAcR+waSyEyocOauAXSRKwaSw4yehjADKKAqTep6+crTK4ySTFJ6f Bi2bepI7rRyUHE4uMGrKy6y7eseyMlMs3gGjMzKShpJKvhwmDMJEtQbuSGdF0a3tIUkr9EzN Q9IxOr7vNHR6DtRSawUnFcBRDUoY1O8YahigwbQevtTtdWCfMlWjI1fI9E1yyrLRI4Mt19Ur WKlV1hy4z6Sxu0llV9ZlJ13W76VjV9hVipdmBtbFXRTLbOM9a6CUtUb4XJFdLuE0AbpeGF13 G0wbRjUVOysHLyuM9liu5fVzBlfrTBrOSWK+G8NyU0+CtLN0aW6yLez2yypQViE2XPKwYWxO cqyVjdypZJMBUZQiRJ69saZLMFws7BUCpY6NiwFmCRSdB7KBhfLjINKWR1M4zVNZQK1MtLN+ STooZaPRFFJ9StChUBohCoBoXiMzqCCpQyvospoQa7Eil6WioQColaBCoOScoTDqHjWpGls6 Kjxi2FAhikFLghQLIoCoJ4hCyKgiimFIuioJScpwFuEJ8GjI7SIikLgoO6KQrrZioO4G7sKg QCQEAihB0fPdEIfPhAJwQCSEHTiCEAmdH1PQhAK4QCn2Hac90oQCl2QnhAI3Zd93HX9H2PXi EEHgd91/PeZ1fadx0YuKwgnDcRtiKIRt6QpJeDO8jzgUdH3AqqF9HRd90aCJimIbexxKCJws LTUYh4qcltLxhQGIagpCoGpqwRiukDbMoZWBU4ErBLE2Fs7inJmbbM/wJoaQxhyDfBUNwdIA QCauWGAzWzyJVfEQZMRFnNPjBAFwFAZAyhzguGkMQZQyAgDSG4ED8YBwFa01xPj4m7hyDyHA OgbwhB5DpC+DsOzIw9hGbN8TdgQAyhYDELgKQWO3DgHKG4Z4dAtf8nyMBpmzP6gmA1/p2wbR XBdEuD5QYnECBaYKFD+ktn7jPCYHMKHNudDQGV4IaQ5BzDo7UFK7gUBvDkGsOYaA3hwBAG+H ASQ3BmkUCkFoNgUBtDCHQNMknPhpDJF2FYKAZgwh1HI1RJoyk5csiAy8KQUBNDCHkEALYDBK DqG6NkboCRNgOSFUb+I7Fba1H18gQYcBlDwGMNMng3BnIvIqRkjg4AuBAEsMoeQ3BviSCAOg YQ2Bri+nuPctzVGjfyA0FqII8OWnalsrDZnNgoDFLYIgYQ7SimyGENAbpsBQDCHAMsg5Iw4k cRgNsLw5hhDPC8lUtQQQzBAGiUQLYlhUak/tyZoZ6RohdDiG4IA5hpDOG6TodQ5QviyGmTlD w5xZDCHWUYb6ZBuhrEkPAdJsBToIGENdBQ5xLlUS6Vs8TfQoPHUiecsg6hzkBQsOdDaHkqDS HiUgbgyh0DvNQOYIAw1fDCCCLdLpnhpDtIAMNOKJh1DSGwMlRJ0RknXRyE0x3xhmDk3oGMiQ 2zgj/SubDvQ31TBBMqF0g5JRZCnQWtIIArSHk1TOkMtQUg4BkCiLIQgwhyg44dxNRZWV1S2U uV5YF3UfBQFCldWgyhsrBWwJYYQ00NdSHmGYcppQuhhFyikvoeTBjDFCVoKAqR/dSGUO8RQ3 RLjAns2cY51TFZ1Gdu4aK11aDZcCYEIiemjii+SFlKKFw1DCGaJIciL2BkAHSP8tpR05uRV2 RcvbQTsu/XO6crjxwmOHaq4826SUJsBJ2iIbr4W1gvVuQAbA3zSDFWGGlJKTUoDpSoMtcox2 jclUglM8EQIblkHMPMhAyhtq/JyW1FIb1QDHhisFX73YCkfQWTsgKRhtkVe27FzYAk5ulK1E CebTwntVJKQAZ4MB1khgascnqF2xhrUGW0nL0hpnFRGWwbAy1Aw1KuOs7J3NaqXiGdUyL3V7 TjIkOoZw0WAsLkmvYLTJ5sDhV8O9gQU51kBKO3smFYAowYTLB8Nqv5dxICkGtmZsYBDzKm/W Qo8lgKhaqF2Og3SEDljeicGAwhkDHWGQta4a0oDlBgO+oZCFUx7dqr8N6M0btKZGWWM3QhsC OGGTlsKS0npTSukgY4/5RDSGa4BXLhE9fDcUOF3IQqGNhMSNAPdj7PKQ/eIAcQ27Oicaqj14 QVyYYCDR/sWc80FwzfeD+yIRRgYPXPDkaNt4/g/d3aCOtpVIOzCmKVtaSY6m8GjRt7yqSSDG GymmPMDBECm6/f03ZCh2DqGyrVe0IAooxfeeJncg2kRTrSZAYQxZc4HIAOFA6hVgkLra+k1Z Hw2DZwjTWN7zQ4pVooHPGNIYbzDCa1VD4NggtdDWS16gxhvDbpicFBQ2w3Dfg4M8toiggt5D HFgbqMY/qLfudzmb+2oj5GjouVpP0IlFKTEmJsUUBs7J6Z3J4N6HrTBsOs4g2aPx/Rq/mYp5 V4BR0cNsW+kW1wnKDW0luYhvDvF0HVJOkVbotNGcAb6JyAosGTrMAiyp8MKTGdeHp1ZlnkVK WVIYs622rE4nrXri4nhmGSFwZAeB0iGGUH23JgqZ2lv2r4cA2BhDHhOG/U6xw63XtZT/rJ19 /DfWkOXs/a+33pL/a27qjcdjNadeHYQUS7sTwWDcGLYBvDNWCUvqZgoCKlEDEwZw3xXyp7i7 zZbw+TBB2P83xoCbsUMSTb64r9oN76Cgj6SDz6iJwkhyC4qNrH6OY2AiznjIRLZSKj5uwJKQ rfz7yoSIoN6TA7yFrAqQr/S4KERmj5RyQFEAb2z+RQwrK1L+rprNyQq37dT/bawki8C4qnSD j6aEDbqH64qLL9CEQgw1jaSTahihzDMHrewnkI4FkIZQ0BxHUCCdK4ql0JUFgtw1baTEK1SL KRS9bG75ykgMrE6sQODwSsrG7kqsiDD4KGjzKdg5cKqoyuq1SLqsTYDqaigOAOrka2qP6GoO YN6SUBkAwGKOCYKOQrLWiYpfTfi1aoSSTLKSjsaTrsqFYrAgSxrF6Lj2iy6vqLIIqaKG8MyL jyTUjnbMC4oIq9yCwOcQ6Jja0HLjw0UCp8i47fzlqRrl4O6sIlSbytDmiiaWyqCLgN6p7Qzj J7LOjSLjxeDSbIzEYOqiCzq2qUivTpCwDPqF7CqSL8qsb4L8LLK8qCycTL8Oz7Lr4kZzKeql bo4OQMir7tKJKv6kbWwKoJabB1i7C8wNilbT7LYMq9Ebh1brEdLrhLbSrEaTzC6b7c6HDlir yawi8YCP6uCLMQh6LUINziAEClcOTvRtKeoOCRSQqUDPLAy7ENIMqrQMkWRq5rKYIyj1ggSB JAhXaU5swlbDzvzAIEAISbyIqv4JkU0LSBJr8nAG5agtSFBtCO7zyesoAJy5S5kg6QiZ4Oqb 7wTJTXUiysSg4MoFr8gMzkqlbWJya0yerh6bwmQNKoLu7+yiitbgKgoqiISIjp7B6W0rrTav 7GctDvLWQrcXDxcV8iS5DoqF8MzkTLj+8rbDCwYIUrZ6Mr74Kzy2kxKTsVcdRyZGy1TWzwQM yhjsrLLo7mLkSRUTCSSsStigixSlC2CvQNMlzzEhMCQubEaizO6kicKzzwq9QMylUwLCbAzW ySkrMh7PqlSUjGcdLeLIbM7sSQTVakoPEYKDYNCr78guhBjxbmL8DTQOoMaTytMuUlzHr4M3 DjxCE0K5DCzGE7qC6IaIrqCC0kExizrYT+8MKTjBAEAPLLqgyIstL5ihcmJrDaxVL1iVa1JA Ql4paBpsqB8m57YhIEBuDMcXB1ky6gqTBggFCcLWC+4pxYKMbRbz0FC9046P6ohZo0aMYGkC idZuyLZvQG6RM0iqc0y7dEpRAqVFBpa4s1D34MU1aT01tF4stGLb1GjDqd06YFDUiskSc2VJ dE5oVIb5c2k2yRoNLO9LFINLVFSVyZCQizqTAy1EU4KVNGCudGZrS6k6Zu04bOY0VETPSOYH DQS8yz57NE1MYitLdFa5E5Mh0rcJaAQpxDdGVJ7vg31KQLYF1SgLoi6t67brVICudFNIk1oO gOU8k8y17vFRdTdIVMskiNE9Ktb4MblJdRtJ1OSNE+LYD8lMVTlQh8aC9EFPk+svYM6C1N1J lOFR4FClaqE/bN7otXFVE3MwqWU/6W1ASzqodTRgNQVTsaDvzqbwAMsWQIpqtCwgx7ghQhgj QEA8hiqPcKgzBLxQNdi1ImYmpYJCApwiwldd5Cte4tompqiAcmaESAspQ9xio2VChtAxhyZF S04G4GlOgFB1R0R2x6Z151QIh0Z1h1R4R6AjZ5x6J4AJyHUmqBQgVepJUp7vcn0XAKStCF4O iLIJjXTO6UC1hvTnKR7OJ26lz3zdNQEZ66jvwIi2tUCGVRKGsTs5r2kg6vTUVUTDEpBr8m9k xipVlhEtUqSNAKSUFlqtLVdKkygOjLi9VmTwMQihCfTkyDEkyqCGqkYMMtKpDIkd4MscaQrk 82D8yrQjCG9pqQlp7YDoqskP4NiCwFrKkvCIckUwk3Tr8abNDB7TYOANCWzPKCzN7FTys8SU VD8B1PrGK2LCjwNscUKzSHUkbSYuFrKTbHb+7LirDkatQNi9LC1lz+zWwMoOzp6fbyVvrTc8 YMdxdMyNDC7YDCNtqg51YKgKoFpzwLArQmMzCTwM0c6JMWLDURqo6WD0kqa5ENSwqcSLLULm LCYKdnkx9obTVoyJNpFutpSWySkOTrc3JhC1Vv1UFwCQCFgKbhgJKK7c0YCLcxiDbCae53tl 1r7ldF0wdSFLaZAKoKYIoJwJILB2990T6WwKYPLwKwoNIOse6HCXTu4FIhAFENrxDBzxaaN0 6ja1SzqQEQjKM7rWziExyQE0jX6iE7t/gKYJIHS4ERUIiW97K0kRNKS1iG7t6cUPTk1wk/DK gOeH8JjaxYcIyEosGByFQIagt6d6saytkuyvbjWKsOq/bDxyr0QuF7iNFvqRTsiUEfC5EerE 6sDYE1UyuKCLLTcwLArHyAUka0pudxy1KWWO8DCnCtCUTuoNir68bXTwoMQNVuoOjV8xKQF5 418tKuzWa1SqDTIMqNh5b8ro6lSqCLK8kazYErM8Lk6z0cEg2OYNsKGBlVVKatkcWLjYuLyi aG8eb81xD4joWR9BMRLa0RhGs3LkCNAI116GUx96WXTUNJKHFKi8jxkpEHELpLYGpyqZB1uX N6maSiEjqL8RKMj7FSC6qWTFiqcaqGuAytYPLJGU8twNSp8GcvrtqCziazsN2JNMGJeTSeUd x8dt6is2rTbOdPjYTR5fOEwoSS7QIMr5tD4p6zQEF3ND7nMvsVGJS2C7E1yG0hC++QBMWNaF oMqginElyQuVCkjk74Ms7HCr6brCiaLLiLIM7BzCNTOP8wgp61WlwOemF/VPMZLNwqmLkzWf wN2jwOZ6qVmoWola2nyCOZVKbYCZigk8rCcPiQDxaF0uSlc0i1r4IMmUOTC6uaF6l4TIeq+c WJisGRjygM2Zt2N0AM2fsYGteXaizGwOTYU2uqgtwnpJIwV7SO70mNKpqeqFjAzLjUWkWpjt 7Ll/6trUedrKOVGuKsLXsl89kdaCLv2FDxSUmtIgTo4Nzuead68HuILaGIeZDjy0aeqSiJMr y2DJUZM3tKkNWXKF+KUREJorqYeK4rdiCw7BDJAqitbqkgko+MYrKc+dBEFh2FwxjJaSE7qs upugGRiLIMqZ6wMYst8rLyTGav+rVwt4OgQrtiCZ+EYHAGei8MOXqQTcSTWScuWAzwAMSG6U mMO7AFKTW3ar6p6LuFmdOq4IIJwIiLIJ4KSm6GoJwJ5zzGuPaRUWInW7KmK9dy7LWgQ/d1ai mVAMiLLwSfaFz80X6W07uzuXO867Fu+ju72wd1ESK7Cx+XCvbnNEaHFG6TKRM2DcW+cUA2OE 0Ee17IGIlKCO7r1SBU6WV810bPqTqsd4F4u4ELQyj/7z6d2QXKG5GHh1gN+SOSeuKleAWT19 iL/LmMs3OYrIuQieuAOF87UbwPTCdwqQnDuPe8dFiHAIIKYJwsAEAF8oIIpvOWiM5u0lzo6T CTSUaaN66+47lkqKcpggYGsp0nhy9aCeoJ+PkgjouSl5KscP0QF4NxF3zUVUM8rGGJLhCF3E LMhy/OZ8c5GAjNSvqrSQsUlYK10VCaQKiy6yYOYNZ4KS4rzv4MoE6r4KGJ14KbTR+klxipR8 cS139/HV7NQGrQSUutIHKK6aaRaUjJTQFPm3aHMGsEiBAvpWT3YFCFgNAOgOgOAHQF4F4O/f ay++aNuMfd9QTri602oOksyRQM9/8LS75KWbUROZSKVy0/jfwMStyuHAGS2jAPE2E2upur+8 SL/hgoOdDDzWmxeNZu2JAOz4APIFsUk9TCaWit7KVS69wEHcIED5ykqUA0czHAazMZhxPG+N LD7NGaLG4OYHfmkfIFwKabD9z5wFIsoFANyhaDeqB/7QKr4IyGjGy2FpODHBNlcSPbPVpvTc lwDQCvqQFmxMSRMryv8Eb/gBoygyYoK8Pefeve/fPfYO/qSTQFwM6hvwL5oF4MykoF6+x7Le uKlqQjPTEnVq9DfOTsJux17o4OHFr8trtl/mlstmiXgrB/5G4FD3rlC9Tqq33BFEtoFlSd3i AFHMbQysHlat+G15NraHHziQnrHAbcir6RzKLk6qvuWKhAUWsFHvPe3fAF65xOOc8K1GtPOi bOYroFDR5ROEwNgMcWLpqniGgOoF4PyLlrwOnxRxMmVBebYh9Bwi1CBsRitlHTtcZtwgVDSO 7v33OA/8rKVZtMgEAgBUIgNFBCOp0NhlOQgJhhNpwOZvNwpKhqBowFwyGgyEAtGIuGoyHIgg UXkh3BpbFBoMJ2MogOByFIxG4oN5wN5zMpkFJdKhKi8Zjcdj8hkclFAupQgMIgNxlO8Ui0YG QzGdEFw0G4xkkDFBpNxmORhOZ0OpjsxyMtSoMajkekEirtBGAwjhUlAoMxvhZwOpiNhpMYtN ZlPNsqlDuFGucqMcyFo1HAoPJwOhvM9jOBow44GNJns/BpFKkmM4NGY5GguHI2jg2jGejht1 A5GusHA3EA2j453IgNm124xHA43YyFw34vA1HF1gxq+u5PL4Iz5w56G7GdZ7PV53W4w27Y07 vNHAu8HaF3F43e8/pG2rGHWEHgFwxGOv1dV3XWG7WNc3b9hm3Qxua4b8wEjMCOY6zVuw6MBv 6HDVvE8LtvY+sKBdCz1Bu8QQQNB0OPoGocpBALvQrEsTvIq8RwgEETBcGDfutBCORnGsCua/ 7WxzE8dwa5z8SBGkbO+5cZhk5b7PTGcXRC8z0SVE8Yvc56rxnK8pxi2EUI470ThlBMvhrFLa owGEAt49EGOqHKMBq7MvwzOCPhpNjYuo2qPt416PzXMLauRObo0DNDUuQG8GTaGUQTg7bJN1 R1INq1cit22MEzhB89PXTgGjMFTahs+8lP/DLaNTUytxzVM+VY5MEhq/8ozhVtaP/JjjVk3z dVrGkAtS/9M2DQUpNTKzf2PNAaLrU7jWajlnoxPNXu4q9qqzANghq+kDW3a7do/RjdODcU2I /DNtuI8LkTIjllNxSl4QTEQc2LMt7UHXzfuleL6tbWbXuQGDs1lV1yPW5d8VzQFswbgd3YXW 9S2jTTkze4UOTKjFzYlB9mSs+lOvvFjWZK2rtz/jL0zhRcQS/l9CJA+kvhjSzUz9mSMZyq87 qzkd6YlOVu2Xc80yPSlrZU+1fxlE6raS60TuVaTz2+9uL4oyWba3WWu1hrdRgagIDWVuZHN0 cmVhbQ1lbmRvYmoNNjAgMCBvYmoNPDwNL1Byb2NTZXQgWy9QREYgL1RleHRdDS9Db2xvclNw YWNlIDw8L0RlZmF1bHRSR0IgMSAwIFI+Pg0vRm9udCA8PA0vRjcgNyAwIFINL0YxMiA5IDAg Ug0vRjE0IDEwIDAgUg0vRjE2IDExIDAgUg0+Pg0+Pg1lbmRvYmoNNjIgMCBvYmoNPDwNL0xl bmd0aCAxMDcxNQ0vRmlsdGVyIC9MWldEZWNvZGUNPj4Nc3RyZWFtDQqADAQGcGjQZi4cjMQD IcjgXDYZDYQDaDjUbRIWjIai4ZjIYiA5GUGmYGkIqA0XkYYwKPlSSDaHjGJQKBTCIR8aTAaj KFQwYQ8ZDQQFQ2g2BFQ5UaHwOlDAYDWhmMGlsUEMpCkZjcUFkoFQUjEcCgnkcpEEoEgkkMUl 0qEoGkWTz+JEcGx80iCBEq8CA1XgXDAcDkQHcQQccDahE0QFsuwIyA0ajG/0GFwmEDSoUUaz 8cjcZZUaQ+ciDNxwcxKGRuIVAaQ7O0LU0CoVIaDcXDeobHViCc7ccx+GaEbjccbyYDff5WDj GwCDacfkwzJbXi7WH53K3LKa2EDbgDntUKpaUY5Hs0ChaUcRHK5IZ5jSZIYZSGDKOcPnZCfj CO5X7KyG4QDYgocoQGKet+3zWQKGsEOmHChO4hr2hc1rxIKhwYthBMLN42wcP4/wXI0z7rRB BDlqe/MTRC4MKta3iHM3DbhBs1jXOLFwbxtFcCxA78awWhEGtBEaGNI/b+oYg4cvgqQ5sg+y nQQn7cBAzT7M63LwNuqEBp2hErPqh4YMFL8NvsG0ywEyDhBnLc0zWGrhBvNCOBrAM5tvOsKB vNbxzpDbJBkz89BxDTzy00jQhxHMuSs8aNs7R0qy8yFJOI84cR3Ngao3HbUS4HNPNJT6LwoG IZTzU1Qsk9bP0i29TzHPzi08F1PTgFwcSJW6ZS2g75tnS6Hve5QXLA9KNsCwUl2LZVdhzZsm 2RPD81vZkiotVaHhtALYhpaVFwqGENo3cLBPHKUW1HCtxQGNEozDYFyMFLF5yLb0zTbEdU3y 5FOuFJt/sFPTwW/agZzk0ODyKp8A0AhAYYQitG3HG16BphdkBnaaD41dIGygGqHBvJQcvsnd 7AbNSOBjadz3eyEC5fLeY33kkRotY6DIlL7bVUyub06mEy5hd2cNtPkxzmhWftvDdK07kuT6 lAcoO8hFRxEnKFKKimOQQ+2uzYxF664iiJtCxGKVxGGzbZY9JvzuDayK36P7NMrP3BcWwBiz 2haRuj5XZocB6zKbzytxDJWlLerAbeOs8fY4ZBxr2WcdrcXX1sr7OJvlqc9xCD47hG14BsGM SK1sA9XUkXPnC/YXpQ6Fdry3MInLNEWdy6FSfljbJ3fIa5WGzXZ3zvj7L5VQ8PliNzLBHoxs v6E+NfaL1xy/tbKnXvJ9Luy+J0XI6xkrostVLM5Z9Tvp+wKJT9F/IPQEAbvlkzzohC7+jbnz f6ZRkyd37vzfy6Z2L7CNH5gKm9mydyhQAT86I1UDYAMTeqbKBxPwaHwN1A15JvjvkbTeUKEZ yDvnLgaVJyaBTiIoWRA1r8MHdouMxBMn6DXUG3V4/l/aCDhQ/KlABNS04hlQM8RxtMOE5v5P /E2Biw4lgzikZI5ESjJRHQoTmCcQYumIg6rgrMYYUQ2QcgoicaFjvtPylBHZt2TspI+UU4au 4ytMI+gOO5FDvmSVJHE8CgkKxiji8lVshX/tFOZGZ/MJl2KugEbgji7FgoTiLJCITLolKSZI kVEESibKzWpKGBxtorQ9lNHdPyNERprlYuVhxlIikOBsaeWZQo+S2g+wR/JDgYPJcEbuQ6B5 hwtAbJQGC/jdH9TqiN9ZoWNHFmedKNsjYimhmsdJ+0jyOJUfxHE2rUX8RFlROR/z+WlSym4U +CZtlRyJPfFSYEC3InENuTJxalp8P6VC6aPcyTjsnoAmyOCDF2NSKKiBCqYlHqWoYbVXUXEB qHVwiKigDT1ojTfRhNdG1VJ2TegGkDS0Ep+ZDSWQihAQUbBm75USVqXKUfIVJzFDaaOMo0x9 TL41Ns+p2iOUhnFSU3IjIlVNJCD1HQoq8/NRpSOgMBS1YMCz7K8IVRsi69FhVPOWsZZyyaqG mY8s+sbHYkLVYhUGtC2lvVjJkwhodFpBuCXRA6hEG67rwo1B6hzH010Lr8lt1K+6LP6dFYVN lIGBudYBRtjUPWFGCsgxNhy1qbNjsss5khxaNnlYzR+LbHWeJ/ZFRojZm1HRYSPQtoB3k+pH oq8RHj46dKNNFOS25MDsN9sMss9lvrFmhQO+d8lFSNuAYQ5FeJhyOKHda96hZMGO2EQq96it vIbsobdb9PbYru0Go0gVyqY2yFFQSge8DZEB3cZA2ghV3G42cRhfJuyzm5lSvtD1vAILuN7r suK9LgbhU2QK4q4VFcD0JuPeNrT96dXNvI5wyzwEr4OvK6NgF7Uqnrl9e091vcNGCQS6yHCm 7/RbgWaF2Z+cSwLMNMbF69MLKiphUt3bwjTsuTsxa9F1KYORM7JVUOQpUTBwCvvHdL1zODvb kBDZB0A3tmkRBY+UwGrUJzBbJ2WaeZJTYZa+9D8w5VuNTrLWVkxsWavlkhwNCeZgM4ygEALT hLhJASIKZdVyvdyiZd9xK5pYEdGaMlZhpcQhKgStsdJoLrDJWoOCJuyVk/m2tQ4ZxdKzQhWs g5pUtN6XOmpnSKyMRHhBBoyQr8Zy58IOjbVk6dBEcuCgmeeqc+k7pEfjUB/IyOiP+fhAeh0K zGm5FnXCwY0od1UjCbiHdexbkJsyZclbwIk1we6SyyEVbR2s61GGqinSuR3os+aFVHJBPzsR hSQFZbmY+kRFyhDBbEQa6JJiTrTkCIIQYhBCorGqzgRMiqpwWtgJ2RIkJIyjapL8ckgQa+Gk fM5xQEASylQfQCYSjRoT3kfTeT8mTmbcFOQDCeJhxbkLINHSOjhn3EVSKhy4nnMGWcyMK8eQ vKmWPye8m9ApOeeMtPWcWKxkiZdD590ZrKfioc6QgUKKzYyPGkQKwrpnVCPm0ZpPrqd16Anc Y1yAiHYEPbF5O1npPZwaOAMKy0z3WyCm27byczB102HW7qYXu55SFdimX3xJhglw6eIke/wa 1+r1T8Q1pTqPpe+Nb90vvhwkVdE5/31IhUvMdGN6k3m3Zend8t5wPmMAeZ+FIj0PKSmT3oF9 W+BXZzU3pS9M++6/JzSkG5tAA9fM/dn9j5FHkBkS/yfj5algCbz5fIoFc/qXxjhy6mT0Eynz E9/Uotu3nPIm00V49237qyPvgNDEUoiRBC5AgLppYynHLcGeM+DNjp133JceOYL+iBZbqW/w XE/onga2w4VxAAKybcQCQSZI4AisagM+v/AYOO4G16P+ka/pAk5s2IPm8PAaTqM+1m8DACwe 1wxY5ABmzfAmz5BK5yp4+pBA+LBKI/A0PYggWQT41Upe+KuST4v0Sk4AV8T4xAVwd3BqcAKE /+/0T0MwOLCQ5zBixch3AATBBysWZKpY9qZcoC/jCu8KMCoglG8PC7AG46Qq4AOsP45s+2OS PeNtDQTYOQVwmMPel496JgnG75DpDeNUlu74Q+jK+GbdD6jwywgAN+6kOsI8oChGTVDCaAka cQt4stDmV26q9OM7DMUYQgbKWWWMPeSlEqo1Cs/mzgMnC1FEMK/q/6TY/OJMJQJUJYKGJIVV Eo4sIFFmQg7+uSisMKVSm+KGKLFg4qL24kP2SOCoKkBQCkCmCCBSCoDULeLi4dGEIE4wJ+pe IU44OsOY6lF6hoMgUGRCpePsgaS/HA4ABkP2f4S+tSPKMLHQL/HUMglsgEI7HSIUZyR2/0Ze L/HbHxD4peJgcurXH9H0m0aCZyIS8OQO1MTy9gURHEZ0boMMP7IhHIZZIm/nF6OGe2Sy4HGu 08dxI7IzImdfJFF4OOIk85JNHqXcbySkeKI66QRCZa/FJjEorW7LBO5mUIXcKgbAXC6MKCue OLJ+QmI6J0xQ84Y/KMcuZdJCe65mI6o4YLEc/nKkJ4ZDG1IfKutIr4+NHRHOY+4GM1HNHcZK xQS/DsRUI7LOywZyqxLMh9Ia1o8PFmUIVs6vBoIjBs8VLpHcuIeyZyIi/0J4ReUKaLABMKg+ VgtOW8L+h+pezeRCa/DbMgPKIQhEIdADF4tYI+koN3ByNu6qnMPu5OOZNEI+puXDNNHGKhNU OxMiqEeCqDNXHcVcqKznHOSymEnwIi5PMKIpJSmSdNMSUYWNEAItJ2eme8gAcvOUiYM/ObMh L2ZRMZOlJ2apM8OWPwI66un0meR2/mIYZdOEnwY1LrO8foZK6lLsl+V2PNKOkqpSquWtPism sWquSPLYS6so6QYs/odBN4emmFQAVkOK84RkxRQKR3KIlRDXKaQgM/McY65BL2O8WHQnQfHG 7cfqM3LqOmeygKZNHOSq/EkyV2StJYMoj4ngMDF4hgtJDgXC5BH3Jify6DDWcAVlOtRxRo4E foaAYGpfB2IUkopfH1SIgci3RTMucBSK6Q9pR0cuMEgzH1MlNmSgQTQjJOPuwuWkX7G4uoyw 02XC4BG6UsJXOXNZIivbAFFRHHK6y9Bs5PK4sMaKZ3Iq/8g9PhTOTYXiXaMjPYaUtayy+VHd UGyUmAPhSPEo5su4VG5nH2qczbFaJSJW4cJcIKQMQCJoN5MwJwJgRA/mKe/IKEKI/QKZGsPN GOKmBQCYCCCECeLKBSNwBQK8LALECkCSCKCmLWLbGhVQ/bMeMFGyQy5AMAh8cyOsKy4BWQhi 7ylQf4YUI3ItC6jFWnTYQIV3WvVJRcQGO5AtW6X2ZGTTVGUwOKM0SZCvVIbmTO5Y6NVJIsYM zxWxXkykyQ6xWSU7Po8PWcd3HLALXhWoUtCnRTXiUsXiQaqE/0YmIQMOwvYUVVYZRaqBYUn8 MKmDCGZwqu7cYVKRXGMhWjWbYHYgIcMO5PYO8fY1YxZI50OJWOhMf450IbXMVxJw+9YYU+eK ZbIFYwkZKI0tQVYyIZQO56RHaEJsbe5ET5Y8a0UKhhI9YaPKQu6hRcYUaAe8ZbCNYxWibzaW 6lYaU3aLa1aZWQKDaeSHWbLPHuwPP/X9NmTwPvbVX1K8mAuhaalMM0wOZfZ8V2RUS+9hMhYy lM50VJaaeTLncNYyQBL7cVZ+6sI48jW6IlIRcEWXOEZyMBZhW3T9HlMfWOQyf4M0NdBpWRSd ZVdLdDbYkLX7bsPS6CVPauN9apdhX6eIUQ50J5dsQqNINc5bYbapbtWO7ovE7KI9d2mWQCa/ Q3X6hMk/J/UXVIPKIkbAv7Wxembo489dekZ2evEZZYTvKINVXxYbeSbpfHdaIeSsbMKzXhZM PxerXDffJxLE5nWQU3JKX7fSW9J9eZa5H4rWcmSySJdlfNeXbTYwmAyQ4RDlbNZ2SZfkZ1MZ fYTXXy2wbMMPYZgVeoUZH/fK7c85g7YYaLay49grVJZe4IQNc3hTKVDjZGh9JdgRaaPnKJgH WbDbhBMaQ/WlZSa+RklxXqUshGePX6Js/obK6vPrYyIoacZYvJHDiZiQlu3/VHDsNHioITZq NOdovJIpVI/yjWO7Zq72fqmXc2mQfqPXebWzjVdKhMl6j4Llg8XORCfqIvZyjIfzjnhGL+bs iLj5b6T8QDQ6X9bxHafqUJisMvNnQ6f1f+mDM8SqrfdkY6fpknZQaVE1kAVlZRbtSpCjftbX jERtk9X085h5bnWer5iJiDYbLuwvlbfTdOcQQZIfdNHjiybtXzdPjNhwWjkISTf/kfk5iilQ thio6jf/lhipd/axaKjguJi2UyjsXPXXXPD0NFYFjbivjzIskpHRfTlWmS49TxbfDekvm3m+ MNYNZIr5PBg9YowvPA+XYaIaqBnA69YyZIX2mepfZRY+vFDgU3VGQyk+sE3/fcWq54oYIToV nGnwmDg1bomSmBg9oM55DgQPlFoXDeZoo7iFo9RRZrIsSgo3YvgK7coWdBn1ecs83zfsuSZ2 Qg2Lc3ewpsUZe3pkIkucJXjYTes8Jhp9khh1p7fIlsplpzoVfwpamlgjqYptphgTRQpJpZf2 plqtqJgDNpgJg/eVq5bmKdp5BLbm2xpo7bdBgkqeUZhOIdrMhNouL+yQV4iZYngAqfrhj7hr qbb9jzhTrPXCU+uhpxH5hhr+3jWbhJpeQrq7hyrXpNM1h7ZIoWwPldncwcTLiMWLicMDPfoB s2zCg9ijiOvig9i/iuIkS495fBi5ChDLZrjDtUytWw72/xsDIiv0PdjfWy1tt2Pe+ovTjoXI vi6RuESJuDr1j+yzuLj7kGxTH5kWUOKgUfXW9LNmQSYneGL+tgQTN9f/ktufu9dkOIQvu7kp WQMAxIPka3XzWeS4PLlNWeptsjlVX+clsxldmewvs7szqnloyyP3lvdVtCRflNdO/xl+MDAS h3l/mJwBj1kru5Gtclv1s7vySNmhTkUPbBlGSqjKBaIriQ4Wz3S+6FqnWex/RRvricx2U3hh ItS+U9jQ/8QZPhW6zQeJstRQ/9xzs0w2yzO9fsOgzDyDf+7bx5ALd3yOzDx7v8+dxLQJdM+c Sg1KlvkW/pXQz4i2zpWw3q2qN/hhew2JZrpu1dDjfBzE1zm83MNCebabGu3XzVb6Sa00z6Q1 XgNsQ03gW7kzNlziqvEleBCCz4TTd2M3y8bHE7YaItzr0TbAQ+INz/DLw4/IIU1VQZqnu9A0 Rhgsre161fDXbMre2JYMQ+ez1Jz6ZM0gz6Nr1So62H1Zh6QymE1mLBbnqY2I0Zqnqhy0SHlN 1w2qTrlmd21L2FmHRc292NpTA+3OIZs0UaKE1UMPx8PN0+RHcklHAy18O9XgJ1Bu18UbsSou 2J3Db6UIQv3JCJW7z2XDpjk62S5ZjYR2rW1UM3Zr3m1ws1bBqE/FBxABcXBOjeJKJPUtFhUy Jsn1U6Js6qN6J2J6qMgbVPGCQNGGKaQDVYBaSSOKCoDuAbGTV4CKCCCkCGCQBACCCcCJGbGe Lg4m4e4tGqSMKFGzDaRaqMfcOsUUeBWz5wTFroJWX2zxOc256BRgNz58TW8K+mIXpoV4QD6S aXppHRKyhh6gykRKR8d9NUStC6Rz5sWuM4p768S/7B66dMU57GVkNRNUVINKVB6W1fIPkn7U 48pYPH7l6XWoqmNKVz7wTvHu+96MtSmQNKIoNhroeSPSfkXEcvqEWMPV8WudlL6+WiWaU3u2 TzjmW/8sWk8I6CnZ82XENp5p4fAEX2Xj558CYkZX9R6Xzzx+9UmZ8scB6Jdn9bBt86Yl81VD 6Rih90VwsxW0Yb8ZMeOq/4djroPB9wQP8qUktMZGUkc59AZWTAM39Ia1Y2Vx5qqXYJqEqn51 Xl+766xYZwp56N/GU7/L76+EWIYB6F/WVv/bp7Yr/T+Gn0S//p9kebHXBHIEWrZABqIANhcN xqOBAMhwNIGMRkIDaDRrAoJBoRCoYMxANRuLhhEYOOBmLoYNIyOIGOBzH5DIxAY4gORcMo7K pEMpINhgLhsNhjNBkNRBOJ1PI/ChsN5TLqFO57CBqLhqM4bQhgNqBToGORvGZgNBjW6wORrQ JdBZiNo/ApsIDZEJNVaaOLVcozG4JYLkLhnO7rA41aYHe5bELtf4RGxjfLNMrxGxnM7NBZJh 71M7LXauOMdkJhUcAOBhDRrnY9CIFo8HQhqMIpedRbdVoY/iBvGKEMYZH5NDKBZqtaIRu5/g 41IhjmeFvYFILjiBzouWM7jAp3GLL0bjT55BuLGobWBoNLRZhmM5TWBlR+JJoTraeMRpBrbo 70NezHBlKfoN9ZRRcHKMP2/qKqgtDLoHAaEo4v76BiuiEJCHIaN6kwbsSmkJLIwgXIS86QP/ Ca+wsvCFPCrbiws/0LIalw5gaqwXBosTZv+HKUoeGwZI4GCMMpGyUthHQYR4nygNg7UEpC4c jp1BKFBhIEXx0rTMyfKMcv+giPqeqS2Rep78y2vSGyZMLTJEtEgyyzKBQvNUqRo48rqfGTMs Q14GxcGy3ycmMwxwmAbqJAgZTCtr+I4q0iy9CyRPDRbYK6xsayukypOAzVKS8nadS7CCYyNF 6NqOvElVCNEXvYHDpv+hCHVTDkZzO575RerqQTEGEZU2kwZNrXNdrbFwbyFIlPuGh9iTXSAG 2VOCsBjKFGMmHD32lQ6FNqzNrJSG9s28/1qq3byB3BQlpJdcgb3ND9iBBclV2okIaS1eDW1M waCSze9QUYp6tX4GdBX8ga+U/CagX1QVMJDHNxqfhb/KlFlm4hg1qpi/t9LHbb6oxfTE46Gr h3S7QZ2o7SE3ep6UQ9NuT5XWOXJ0v+S5lGiq4eodJx/d8S11Gme3TYse0znq21RZ0tLDaVky npdMq/KNyBk3LKalaas2o2luoUHIYLw5dpXJr+wqhmtm69sDANYg1yKtjuv66kTzTFuTBxdV aoLXM7wqAh+9Xo7+ovEEDQVjTDk3fSVqcVdNeuQmuEo2/LmpiG+3coHL7u3fPNLjCPMXe3at JolikRjQcPpYl3Dqt0CapJvVLpohKgb1kdqIUzSt9anKo8H3d1y9w6vaKhT89unNjQ+HOVdQ +MMZVx6dXk//n0t5ls5H0bK6LJENcx7zAQltyYSHraz4TW8aPTDXDsfy33cMnMJ6KiUw8P4D Ab9vAGsYOkygvRBnAJcPgswvJj2GL9LbAkqrQUbPEgM+lo7/4JmATI/9eaOYMPEg24MjcFQc I6XpBBKMI0YqlgZBp1Lg18QNg+mIGatUXObR2a15CfwGnPYKXGHKUUAKJMzC+HZFlHrHVDDy EqPoIlths7SJkJyYA2U8h9JcOycqkWYqiGwOFVvkVcQ+Lqsi8q0S9EpXBWFdRABi5d75HFgp 5h3CE/wNjnqvK0hwzUdY7xOIEkOECmonNeNK0aJsRT/yFiIWKPULoVyMi84M6jAozssBypiS ZW4nEbJA9aK7zkOHpWZKCEamIQyHjyh6U6UUXLRd+8xfBD1oo6kVCtaJFlXRIBBLcqB0kVIO l2rqXp9zau9AbLwqKrIqFbl5IFnssydQmMHK4qDzJVpeVQtGNq9E7EiKQq+aANJctRm+W2aC 1XLNYWiSE+0qlEzMR4VAGKHjtA2JIS6dc8kPO7ZVPkm0OCOTwhIV4/za58Awm21BJ8mo5BCC oA0F4Rloy7BAFQMyLydIXBgCCjZ1GqggPETolBB1BEibWFQh7y0JUVJcCgIYTwnBTCqCkKga gGpPVxRsKgRAGhbBQEwFK3gUBUqCDQFAQai1DCTTAFIXQqBKAaEWh59j8GTegiEh5q0suDJy fA8ZOTzKYjabykBJitLUrGySm5hSP1pKBSEpBcScq+INXBzdJCTOdJdXYptJWAUgVG6VXybS 1nxP+oOkrrCIVdPtSSwhJKtSlschxENVDQ1Wk48Msry1PLrQ48MtqMj/gxR7Z55NIDO2lIE8 4klhnnWTtYYOw0B7BvXtbJxY1niCENXohy3NeTLVrt9aUmD5ayzVWpXNRVrjW3KQ1aI0Fcn1 WokTcQgaYatI8O/VdDSLmRkxrvXQnSyCII6crZOsJGUIohtqSwGpCiNWqdicRMBsr2lrIihw sd6JLkZOXfu8SOUNX5WqZknK1bIX1cHW4jN8FfkIwYWW9ZmcGXfvOQjA97yM3mvC+LARg1UF RJjGnD15MRIQpJcXDV7yOSUwxiM3uDmi1zWrfSkyHsaG9ZZFTFMicEocx5gGtRY8gWlc1jrG 9sJ7YNKhg+v2SyypPxdk+yCSsSZHvViO0tea1J6m3SSwJDUcRthmWCz0doMn0NXVyQRbkYyF JzBUsyEzgUliufSGd2y1KhzxCPHsy0vZ4v6r6KclDYZkZhbWK6WIoZ2VDoyUWL4Kk8RiR/OM h09EhInmAheYkX6aILpwi5QUnmlsSWtGDmDz6nnui8tRM77k3VHYjPZQdZ19VHN8pWt68S9K mRsqpV3xFIK2pwr2ZqzX7KUmDOpMC1pMLhj002pC/ZmJgXstE9tq49NqgZF72y8VdL4jAxml jKlARgZLcxj0NbGwNucoJp7rGgKmafUxnSkqimqRR1CeCjzVzYV82xiGrN6rIjA39bXJGpIs cfhXByQnM3NPMqfEZfaEKGdbT6HOL4emBto72vTw7ZS43W8R6ZjIwPbr0+CtVOAzsbeI0JKV OH835CE2xEkB2eI8UrnXN0F7FTag+vyIdUoXtqhnhllNV2r6Mtkr+nETbURSr4uxuUWrNR0a BTGl0brNjaUi5ObVG9i04Zonqh+w0r6teBhMbT7Z1tXktRBINhdz1aohgWerDk3uLF7ThP90 d/6A5vlPhNzaTrMwPSUh09pZzrJyxpsKzUj7awLwZHPLV+rvHYvUS6S+HXLZMGTH36zA1iu/ DPd75tDQX3x0/W4H21L4srrmnK79ZbJGTryr1yJDxn2RJ9udaqHMdqb4qzfj+ROM1lG2wuCJ eby7/gJqHARtLF10kSeG9fZ8TId8SUPgwV/CgDiaeN+zjsY1MzsudHPE+p6RULeZ2c7cpDpj B6dcJ+hOU8iL1iK4vKeyqz5JBSwRw6ETiLSMBCQ6FC0jvkAIlZ4bRRU5/4hSGavq4qMMCwvR WR1CMyBprzEgt6OJdrJ0EiVh/79r87r5r6RL7ROSM7OLODNpTL8T76E7YD8zF8GKBokxka5r 7aE8H790AsFcCj6SHb7D0sHCjhGohoFpbJXYOQMoBoKaRDC7Epv8LDDogS9KRjpT1KS7Jq+S xSPImT2AtaUjACksL49kNjLhDUNbd7BAEEM6+zgw4cMa+Lh6tUMC9kPIoBCS8C6UOsQcLMOL ECHZMEEa8cLaRjFDjAsQkkMZHjcLGEOw07B5w4pwwaPJaLHETCPIuS60ScOyTjIMLUT0VDIz t0U7JLpLJcPbJzvETyP7KcWsSDK8V0XTLcRx/yfKzAnSO6WSeLMrTjNBLybTgEJqcxIbN77S CqajOj+UZShCAcCBUMZbPLP7QyY8a69LjDQEZwkI8sAiWyYTRr5KXiKEBhKMYMZqhqh6iJQq iiixF6jkfItCcQg7HilABqjYM8gClkgDzQhoKgO6noFCVwEAJoIIKQJIJwIoEAKEh4JYK6pA hIFALKpqp8goxIrYFqNonYrancgp+YKglyrpushABoFAKQIoIgK4J4J4IgEAIYJIKkjimoBo KgFUk8f0lSgIlMlqnwIYFInCo8pAGAFAEAEAFIvYFBCTYMjqqAxA9SnSniuZIklMl0kRHgGK mimwFsq8kMkY9UkyrpwsrslcokhKoYIoJikA44F40YGssg/gGcsUnsn8tsggFAIwIILEuYGs uosUKIhgG0vY08fKjoqCkBHq0kx8f6ro3Ev4OQOYMIFoNgMIMQOYIEzAMIFwMYN4NsvaqUgY nrOM1QEAJYBohoO6YMhoEALYLqjYMim4ho8yjYh48QoE3ZL0K534EE2Km7chhImc3s44ECGZ KMK6hyiAIwjAnse4gyjajauq17mAjEykginwKEmAKYJ4KQFIFon6ocqoBoFonJLUkRGKGaiq nk9Y/E6kt4IwJIKQKYKkm4JgIIKYKcvc+Y6UKCbc+Ek0+aQCishKnwKoFwKYF0igJ8/UpAHK o4I4Is9Mek6aiqi5HVAYEE9wGlA0+R5ahE7wFAKAFIryo4JIIlDM6Ueyi89yslENEcgcthHc g8t4JoJoKYFgEEiMo8nk1CjYI8b5Ic2am4vI4Yvb/zdCWlECKkx8KkKwBs6CiJC86ii8H8xp w0x8fg80yalNBUhQIYN4OAPIOQNIM4NAOgEALgn4nqea/s/IIIEAJkzoN4OQMIOlPQNIMoOd H4MIEAMgNIOwNIOYNIN4NwEAN4MwEFOoEAIlPlQYKYMoMYOtNQOgPIFJAAFFH4JINwMdCAII NgNgEFNVNgOgOdVAFK0gFFQAMoOU8pk4FAOwMoMgF1F6ZlDh/5BcfKNpXx29L4uiO0xk7s1S 0cfINcl1UIEAOgNFRAEFRAOYOoMoHUvaucfk9xkcokrRHc+shVOBCdWg1ioYNAMoEAKYOlPg OtVlR09NYIwVbhMMkwFAJoIgoAIIMwOlWQEAMNbImNbbuFetb74FMkl9S4MoN1NwIIOldgMY NdAM9h7lelb0gpIdcIFFcYoAKldFdVS9TINNTdRoM0vdeQtFi0+MlwIgIoKYLFiYv1Ahvdi6 n1jlcoHCo9N1aFdIJMzIMIMdeImNedgli9Es7kt4JwMoO9PtRlUIOYOlkYOtfsvYztLqicfl Y1MUgcgSnUt9SNSddlkFTFTQPIEAIINwNwN4OtUVQFZ9dFbNEDMlldBFE0oshZGwrdsFSkp4 G4FFS1slkds1MwNwM1WVhYMYMtF9LNXqic682VrI7qiqlLzQtFu9j1dIMNtIOoMNU9SNwlw1 WckQGdWFttadVlnlaYNwMldwOlWb0oFAPILgqQGspAGwFAOc9Mn1jB4du8zgOQM9QFN1zQMg hwN9qAEAOEKlqFNdRVd0p8kQGQFE0gNoOFqdfwOdkNst3Uvo/EktBdWFW9hlH4MVNQNwM4NN 89Z4N94NngOVt9dIO9PQNgMl2Yn9FV0lVgMdWZgV2IOFPoM9PYFt7ljCYFHAr9jt8AOANFsw OYPNqAMoNtVlV16QMoPAOFWVVc4lkYNAEFxAOQPN/9RVRgOAN4NgNIMdTipyqF3anUoSW9hA NoMINdWVQIEAMVd19NQFVmDFM4NlzN1d+FQgMtW4NlM4NthYOkvd3an16gNttlwUpYFFXWFc gc8yaMtJHcomF5LUltc9dM0lwtw90wO4NNU2G9dNdF+gEAJVzVzmEAj4Fo6QFluM907lg0rg lyn1OYrdPmIQJoMIOdReFEp4mSo4OtQtPtNQOoNtH4JwN4MQEAJGMwNmOmKuFsgilQkmLwKd zQEAI1PdUVRE0lf+IINGQONFheD2C94lXF9YEAM1tdWcnmFpNEt0lwMwOuM4MgMOB9H95QN9 Q9Qt9VtgOAMNPdUwMuH94t8oMoMIMlaGUoMmJd7pkNMinwMgMt/4NFCFzEKl04EGQWJFaF9I M+QoGIFFdGb+WN9+IlWQPNRdxWS97tg+A+Lst4O4NF49dOE9w19YOoMddFVl7NwNklfugNtW IwM4PIHWWAOU0ualG8oRHmTd8F1NV1v1zVzuB9nYN+IQIYIoJ4Heh00uIWbOItM9f1PuAlr0 hV1N5VV129R2HeEdzt6F29/c8t2GEOAFPeBdWQFJVeKdeKrtq6jcfg8Nq0ygjiCOL1zAltRd 0NxFdIMQMt9AN1VmMuaIOl+VQmXtd9R94IN2AeWmeiSmL1WWm17IOdRNRdVl9OIWqoMNqYNO XNU+QGQQN2QgIORFkYN+sim1Iiik1cfM1yiYJoECm5j4sxLU3pR4iYv04OxRd48pfuxwkg2q Ik58eYI1Xke43Nx43NERnzuFydjAukrqbZXeL1OwJwEG1wJ4EAKu18m4EEiexEie10/dAEng t4oCjdYJLVLg+MfaL1re4EJyu6jdZmF09VEtjQI1PWqFhloF4d1dgIm1mdbtlYFFQtqFNWHF qNRe7Fgdmlle5+a4FF9Odk8pBwFGGW8QN1H97OeUj1bW7VgtG8t+Y14Ig9ktt9RG8m/FmoFA N1pYOeH9h+oCoWKkj1LAtFLUb4kWowg6/drVjtMdrt71hGReRtf9ndj9PoOG/+R+SOSeM+uG TtRmUFzQMeUYN9XUnijeO284/E7mLmBMl2p4M9PmdWcu6dqIN1a2rODlZ+ruXmB9kuiO5tBA 8thAMczmtlt14mG8KmGdtdN2teturHD4EAO2Y952gdkdt28estjFA3HFhHEuSWSlH99PKGvt 9V1IMwMINttdVlddzWdmafM1EskqltM1TIOlH+QAOQNeSVM4Nd9NVlUNfoOWMPIOJNztQW6/ PuTNhAIwMINIOXO1hnRFfoNgOfGKmxaImPCjwQoIju45uljVZ2Z+ROEeV+sWtNU/LWEeGwOl qdP1ztVl4nJYjiedhGZvK9qeG2MOqV01Plft1YMtt2MuM+U9W9+GiPJtjVM+EoOXXOvWg2j2 +mIfO2sAEANFtgMkKgMncNOuwEvm5xHeTYl3JtpEhWglTIFIm1WF4umGOQGoFAN8pG7ugGDW uGWUimY/et6QOnA19/TPTeVeEuWGI1PXetnPBqqFx1YCjfVC984cf9uty2PQFAIXKwNfOlqF H+jAFANltmgOaXKuZwNfXub/N/lObN4tztU+WPemedjCB+e1y0t/JGG3Kl7NW+ZGqFiNdmM1 VFhWEWt2DeM+qvJeTKk1HUl2NV4tPt5Oh+YVzPBXZnZ3IvOoOGH9Z4NOJF9fqOL3A2rlPXQ/ Kl12Z9dINObOQPUeKxHVy1gxmGe3HOL9SAKdO10GMdxNf4NgO+r+cOZXUNRtqe+ffvGVuQvX GqhFjvj8Kl9GCF99tU2IMVswMfm3H4JgJciYKF0Qr/flV3fd1gMe+PXuJXnW5oFAr0wq94Gg FpAEZ806h4gIDWVuZHN0cmVhbQ1lbmRvYmoNNjMgMCBvYmoNPDwNL1Byb2NTZXQgWy9QREYg L1RleHRdDS9Db2xvclNwYWNlIDw8L0RlZmF1bHRSR0IgMSAwIFI+Pg0vRm9udCA8PA0vRjMg NjQgMCBSDS9GNyA3IDAgUg0vRjEwIDggMCBSDS9GMTYgMTEgMCBSDS9GMjIgNjUgMCBSDS9G MjMgNjYgMCBSDT4+DT4+DWVuZG9iag02NCAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlw ZSAvVHlwZTENL05hbWUgL0YzDS9FbmNvZGluZyA2NyAwIFINL0Jhc2VGb250IC9IZWx2ZXRp Y2ENPj4NZW5kb2JqDTYgMCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1R5cGUxDS9O YW1lIC9GNQ0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbDSAyNzggMzMz IDUwMCA1NTYgNTU2IDg4OSA4ODkgMjc4IDM4OSAzODkgNTAwIDYwNiAyNzggMzMzIDI3OCAy NzgNIDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAzMzMgMzMzIDYw NiA2MDYgNjA2IDM4OQ0gNzQ3IDc3OCA2NjcgNzIyIDc3OCA2MTEgNTU2IDc3OCA4MzMgMzg5 IDM4OSA3MjIgNjExIDg4OSA4MzMgNzc4DSA2MTEgNzc4IDcyMiA1NTYgNzIyIDgzMyA3Nzgg MTAwMCA3MjIgNjY3IDYxMSAzMzMgNjA2IDMzMyA2MDYgNTAwDSAzMzMgNDQ0IDUwMCA0NDQg NTAwIDQ0NCAzMzMgNDQ0IDU1NiAyNzggMjc4IDU1NiAyNzggNzc4IDU1NiA1MDANIDUwMCA1 MDAgMzg5IDM4OSAzMzMgNTU2IDUwMCA3MjIgNTAwIDUwMCAzODkgMzMzIDYwNiAzMzMgNjA2 IDI3OA0gNzc4IDc3OCA3MjIgNjExIDgzMyA3NzggODMzIDQ0NCA0NDQgNDQ0IDQ0NCA0NDQg NDQ0IDQ0NCA0NDQgNDQ0DSA0NDQgNDQ0IDI3OCAyNzggMjc4IDI3OCA1NTYgNTAwIDUwMCA1 MDAgNTAwIDUwMCA1NTYgNTU2IDU1NiA1NTYNIDUwMCA0MDAgNTU2IDU1NiA1MDAgNjA2IDYy OCA1NTYgNzQ3IDc0NyA5NzkgMzMzIDMzMyAwIDEwMDAgNzc4DSAwIDYwNiAwIDAgNTU2IDU1 NiAwIDAgMCAwIDAgMjc4IDMwMCAwIDcyMiA1MDANIDM4OSAzMzMgNjA2IDAgNTU2IDAgMCA1 MDAgNTAwIDEwMDAgMCA3NzggNzc4IDc3OCAxMDAwIDc3OA0gNTAwIDEwMDAgNTAwIDUwMCAy NzggMjc4IDYwNiAwIDUwMCA2NjcgMTY3IDU1NiAzMzMgMzMzIDU1NiA1NTYNIDUwMCAyNzgg Mjc4IDUwMCAxMDAwIDc3OCA2MTEgNzc4IDYxMSA2MTEgMzg5IDM4OSAzODkgMzg5IDc3OCA3 NzgNIDAgNzc4IDgzMyA4MzMgODMzIDI3OCAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMg NTAwIDMzMyAzMzMNXQ0vRW5jb2RpbmcgNjcgMCBSDS9CYXNlRm9udCAvR291ZHktQm9sZA0v Rm9udERlc2NyaXB0b3IgNjggMCBSDT4+DWVuZG9iag03IDAgb2JqDTw8DS9UeXBlIC9Gb250 DS9TdWJ0eXBlIC9UeXBlMQ0vTmFtZSAvRjcNL0ZpcnN0Q2hhciAzMg0vTGFzdENoYXIgMjU1 DS9XaWR0aHMgWw0gMzQzIDM4NCA1MDAgNjg2IDY4NiA5NzUgODQ4IDI1MCAzNTIgMzUyIDQ4 MyA2ODYgMzQzIDM5MiAzNDMgNTc5DSA2ODYgNjg2IDY4NiA2ODYgNjg2IDY4OSA2ODYgNjg2 IDY4NiA2ODYgMzQzIDM0MyA2ODYgNjg2IDY4NiA1OTUNIDc0MCA3ODEgNjc3IDY2MCA3NTIg NTUwIDU0MiA4NDIgODAzIDMyNCA0ODkgNzU4IDQ5NSA5ODMgODgxIDg4Nw0gNjYxIDg4NyA2 ODAgNjE2IDUzMyA3NzggNzYxIDExMTcgNzg5IDcxNCA3MDcgMzUwIDU3OSAzNTAgNjg2IDUw MA0gNDAyIDY4MiA2ODIgNDgzIDY4MiA2MTAgMzg4IDY3NyA2NjEgMzAyIDMwMiA2ODggMzAy IDk4OSA2NjEgNjYyDSA2ODIgNjgyIDQ1MyA1MTMgMzYwIDY1OSA2MjMgOTk2IDcxMiA2NTQg NTU5IDM1MiA1NzkgMzUyIDY4NiAzNDMNIDc4MSA3ODEgNjYwIDU1MCA4ODEgODg3IDc3OCA2 ODIgNjgyIDY4MiA2ODIgNjgyIDY4MiA0ODMgNjEwIDYxMA0gNjEwIDYxMCAzMDIgMzAyIDMw MiAzMDIgNjYxIDY2MiA2NjIgNjYyIDY2MiA2NjIgNjU5IDY1OSA2NTkgNjU5DSA2ODYgNDAw IDY4NiA2ODYgNjg2IDY4NiA2ODYgNjUxIDgwMCA4MDAgOTQwIDQwMiA2MDQgMCAxMDI2IDg4 Nw0gMCA2ODYgMCAwIDY4NiA2NTkgMCAwIDAgMCAwIDQwOSA0MTAgMCA5NDAgNjYyDSA1OTUg Mzg0IDY4NiAwIDY4NiAwIDAgNjAzIDYwMyAxMDAwIDAgNzgxIDc4MSA4ODcgMTE0MCAxMDIy DSA1MDAgMTAwMCA2MjggNjI4IDM3MiAzNzIgNjg2IDAgNjU0IDcxNCAxOTQgNjg2IDM1NCAz NTQgNjc5IDY5MA0gNjg2IDM0MyAzMzggNTk0IDE0NjAgNzgxIDU1MCA3ODEgNTUwIDU1MCAz MjQgMzI0IDMyNCAzMjQgODg3IDg4Nw0gMCA4ODcgNzc4IDc3OCA3NzggMzAyIDU5MCA1NDkg NjAzIDUzOSA0MDIgNDU3IDM4MCA1MzkgMzUwIDU5MA1dDS9FbmNvZGluZyA2NyAwIFINL0Jh c2VGb250IC9GdXR1cmEtQm9sZA0vRm9udERlc2NyaXB0b3IgNjkgMCBSDT4+DWVuZG9iag0y MiAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHlwZTENL05hbWUgL0Y4DS9CYXNl Rm9udCAvU3ltYm9sDT4+DWVuZG9iag04IDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBl IC9UeXBlMQ0vTmFtZSAvRjEwDS9FbmNvZGluZyA3MCAwIFINL0Jhc2VGb250IC9IZWx2ZXRp Y2EtQm9sZA0+Pg1lbmRvYmoNOSAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHlw ZTENL05hbWUgL0YxMg0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbDSAy NTAgMzMzIDQ0NCA1MDAgNTAwIDgzMyA4MzMgMjc4IDM4OSAzODkgNTAwIDYwNiAzMzMgMzMz IDMzMyAyNzgNIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAzMzMg MzMzIDYwNiA2MDYgNjA2IDM4OQ0gNzQ3IDcyMiA2MTEgNzIyIDcyMiA2MTEgNTU2IDc3OCA3 NzggMzMzIDMzMyA2NjcgNTU2IDg4OSA3NzggNzc4DSA1NTYgNzc4IDYxMSA1MDAgNjY3IDc3 OCA2NjcgOTQ0IDY2NyA1NTYgNTU2IDI3OCA2MDYgMjc4IDYwNiA1MDANIDMzMyA0NDQgNDQ0 IDM4OSA0NDQgMzg5IDI3OCAzODkgNDQ0IDIyMiAyMjIgNDQ0IDIyMiA3MjIgNTAwIDQ0NA0g NDQ0IDQ0NCAzMzMgMzMzIDI3OCA1MDAgNDQ0IDY2NyA0NDQgNDQ0IDM4OSAyNzggNjA2IDI3 OCA2MDYgMjUwDSA3MjIgNzIyIDcyMiA2MTEgNzc4IDc3OCA3NzggNDQ0IDQ0NCA0NDQgNDQ0 IDQ0NCA0NDQgMzg5IDM4OSAzODkNIDM4OSAzODkgMjIyIDIyMiAyMjIgMjIyIDUwMCA0NDQg NDQ0IDQ0NCA0NDQgNDQ0IDUwMCA1MDAgNTAwIDUwMA0gNTAwIDQwMCA1MDAgNTAwIDUwMCA2 MDYgNjI4IDUwMCA3NDcgNzQ3IDk3OSAzMzMgMzMzIDAgOTQ0IDc3OA0gMCA2MDYgMCAwIDUw MCA1MDAgMCAwIDAgMCAwIDUwMCA1MDAgMCA2NjcgNDQ0DSAzODkgMzMzIDYwNiAwIDUwMCAw IDAgNTAwIDUwMCAxMDAwIDAgNzIyIDcyMiA3NzggOTQ0IDcyMg0gNTAwIDEwMDAgNDQ0IDQ0 NCAyNzggMjc4IDYwNiAwIDQ0NCA1NTYgMTY3IDUwMCAzMzMgMzMzIDUwMCA1MDANIDUwMCAz MzMgMjc4IDQ0NCAxMDAwIDcyMiA2MTEgNzIyIDYxMSA2MTEgMzMzIDMzMyAzMzMgMzMzIDc3 OCA3NzgNIDAgNzc4IDc3OCA3NzggNzc4IDIyMiAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAz MzMgNDQ0IDMzMyAzMzMNXQ0vRW5jb2RpbmcgNjcgMCBSDS9CYXNlRm9udCAvR291ZHktSXRh bGljDS9Gb250RGVzY3JpcHRvciA3MSAwIFINPj4NZW5kb2JqDTEwIDAgb2JqDTw8DS9UeXBl IC9Gb250DS9TdWJ0eXBlIC9UeXBlMQ0vTmFtZSAvRjE0DS9GaXJzdENoYXIgMzINL0xhc3RD aGFyIDI1NQ0vV2lkdGhzIFsNIDI3OCAzMzMgNTAwIDU1NiA1NTYgODMzIDgzMyAyNzggMzg5 IDM4OSA1MDAgNjA2IDMzMyAzMzMgMzMzIDI3OA0gNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYg NTU2IDU1NiA1NTYgNTU2IDMzMyAzMzMgNjA2IDYwNiA2MDYgMzg5DSA3NDcgNzIyIDY2NyA2 NjcgNzc4IDY2NyA2MTEgNzIyIDc3OCAzODkgNDQ0IDcyMiA2MTEgOTQ0IDc3OCA3NzgNIDY2 NyA3NzggNzIyIDUwMCA3MjIgNzc4IDY2NyA5NDQgNzIyIDYxMSA2MTEgMzg5IDYwNiAzODkg NjA2IDUwMA0gMzMzIDUwMCA1MDAgNDQ0IDUwMCA0NDQgMjc4IDQ0NCA1NTYgMjc4IDI3OCA1 MDAgMjc4IDc3OCA1NTYgNDQ0DSA1MDAgNTAwIDM4OSAzODkgMzMzIDU1NiA0NDQgNzIyIDQ0 NCA0NDQgMzg5IDM4OSA2MDYgMzg5IDYwNiAyNzgNIDcyMiA3MjIgNjY3IDY2NyA3NzggNzc4 IDc3OCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA0NDQgNDQ0IDQ0NA0gNDQ0IDQ0NCAyNzgg Mjc4IDI3OCAyNzggNTU2IDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgNTU2IDU1NiA1NTYgNTU2DSA1 MDAgNDAwIDU1NiA1NTYgNTAwIDYwNiA2MjggNTAwIDc0NyA3NDcgMTAwMCAzMzMgMzMzIDAg ODg5IDc3OA0gMCA2MDYgMCAwIDU1NiA1NTYgMCAwIDAgMCAwIDMwMCAzMDAgMCA3MjIgNDQ0 DSAzODkgMzMzIDYwNiAwIDU1NiAwIDAgNTAwIDUwMCAxMDAwIDAgNzIyIDcyMiA3NzggOTQ0 IDcyMg0gNTAwIDEwMDAgNTAwIDUwMCAyNzggMjc4IDYwNiAwIDQ0NCA2MTEgMTY3IDU1NiAz MzMgMzMzIDU1NiA1NTYNIDUwMCAzMzMgMjc4IDUwMCAxMDAwIDcyMiA2NjcgNzIyIDY2NyA2 NjcgMzg5IDM4OSAzODkgMzg5IDc3OCA3NzgNIDAgNzc4IDc3OCA3NzggNzc4IDI3OCAzMzMg MzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgNTAwIDMzMyAzMzMNXQ0vRW5jb2RpbmcgNjcgMCBS DS9CYXNlRm9udCAvR291ZHktQm9sZEl0YWxpYw0vRm9udERlc2NyaXB0b3IgNzIgMCBSDT4+ DWVuZG9iag0xMSAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHlwZTENL05hbWUg L0YxNg0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbDSAyNTAgMzMzIDM3 MSA1MDAgNTAwIDgzMyA4MzMgMjIyIDM4OSAzODkgNTAwIDYwNiAyNTAgMzMzIDI1MCAyNzgN IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNTAgMjUwIDYwNiA2 MDYgNjA2IDMzMw0gNzQ3IDc3OCA2MTEgNzIyIDcyMiA1NTYgNTAwIDc3OCA3NzggMzMzIDMz MyA2NjcgNTU2IDg4OSA3NzggNzc4DSA1NTYgNzc4IDY2NyA1NTYgNjY3IDc3OCA3MjIgMTAw MCA2NjcgNjExIDU1NiAyNzggNjA2IDI3OCA2MDYgNTAwDSAzMzMgNDQ0IDUwMCA0NDQgNTAw IDQ0NCAyNzggNDQ0IDU1NiAyNzggMjc4IDUwMCAyNzggNzc4IDU1NiA1MDANIDUwMCA1MDAg MzMzIDMzMyAzMzMgNTAwIDUwMCA2NjcgNTAwIDQ0NCAzMzMgMjc4IDYwNiAyNzggNjA2IDI1 MA0gNzc4IDc3OCA3MjIgNTU2IDc3OCA3NzggNzc4IDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgNDQ0 IDQ0NCA0NDQgNDQ0DSA0NDQgNDQ0IDI3OCAyNzggMjc4IDI3OCA1NTYgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDANIDUwMCA0MDAgNTAwIDUwMCA1MDAgNjA2IDYyOCA1 MDAgNzQ3IDc0NyA5NzkgMzMzIDMzMyAwIDEwMDAgNzc4DSAwIDYwNiAwIDAgNTAwIDUwMCAw IDAgMCAwIDAgMzk0IDQyNSAwIDcyMiA1MDANIDMzMyAzMzMgNjA2IDAgNTAwIDAgMCA1MDAg NTAwIDEwMDAgMCA3NzggNzc4IDc3OCAxMDAwIDc3OA0gNTAwIDEwMDAgMzg5IDM4OSAyMjIg MjIyIDYwNiAwIDQ0NCA2MTEgMTY3IDUwMCAzMzMgMzMzIDUwMCA1MDANIDUwMCAyNTAgMjIy IDM4OSAxMDAwIDc3OCA1NTYgNzc4IDU1NiA1NTYgMzMzIDMzMyAzMzMgMzMzIDc3OCA3NzgN IDAgNzc4IDc3OCA3NzggNzc4IDI3OCAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMz IDMzMyAzMzMNXQ0vRW5jb2RpbmcgNjcgMCBSDS9CYXNlRm9udCAvR291ZHkNL0ZvbnREZXNj cmlwdG9yIDczIDAgUg0+Pg1lbmRvYmoNMjMgMCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5 cGUgL1R5cGUxDS9OYW1lIC9GMTgNL0VuY29kaW5nIDY3IDAgUg0vQmFzZUZvbnQgL0NvdXJp ZXINPj4NZW5kb2JqDTQxIDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UeXBlMQ0v TmFtZSAvRjIwDS9GaXJzdENoYXIgMzINL0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsNIDMwOCAz MzggNDU3IDYxNiA2MTYgNzk3IDY5NSAyODkgMjg3IDI4NyA1OTIgNjE2IDMwOCAyMDggMzA4 IDU3MA0gNjE2IDYxNiA2MTYgNjE2IDYxNiA2MTYgNjE2IDYxNiA2MTYgNjE2IDMwOCAzMDgg NjE2IDYxNiA2MTYgNDg4DSA4MDAgNjk5IDU2OCA3MTcgNjc4IDUzNCA0NzggODIwIDcxNCAy MzkgMzE0IDYxMSAzNzUgODk2IDgzNCA4NjINIDUwMyA4NjIgNTQyIDU1OSA0NzAgNjg1IDYy NCAxMDkxIDU2NCA1OTMgNTg2IDMxNSA1NzAgMzE1IDYxNiA1MDANIDM1OCA1NzcgNTc3IDQ3 NiA1NzcgNTE5IDI3NCA1ODAgNTI4IDI2MiAyNjIgNDcwIDIyNyA3NjggNTI4IDU2Mg0gNTc3 IDU3NyAzMzUgMzk5IDI0MCA1MTIgNDYzIDc2MCA0OTggNDk4IDUxOSAzMzQgNTcwIDMzNCA2 MTYgMzA4DSA2OTkgNjk5IDcxNyA1MzQgODM0IDg2MiA2ODUgNTc3IDU3NyA1NzcgNTc3IDU3 NyA1NzcgNDc2IDUxOSA1MTkNIDUxOSA1MTkgMjYyIDI2MiAyNjIgMjYyIDUyOCA1NjIgNTYy IDU2MiA1NjIgNTYyIDUxMiA1MTIgNTEyIDUxMg0gNTkyIDQwMCA2MTYgNjE2IDU5MiA1OTIg NTkyIDU3NyA4MDAgODAwIDk0MCAzNTggNDY3IDMwOCAxMDAwIDg2Mg0gMzA4IDYxNiAzMDgg MzA4IDYxNiA1MTIgMzA4IDMwOCAzMDggMzA4IDMwOCAzNDYgMzM3IDMwOCA4NDMgNTYyDSA0 ODggMzM4IDYxNiAzMDggNjE2IDMwOCAzMDggNTAwIDUwMCAxMDAwIDMwOCA2OTkgNjk5IDg2 MiAxMTkwIDk0MA0gNTAwIDEwMDAgNDU3IDQ1NyAyODkgMjg5IDYxNiAzMDggNDk4IDU5MyAx NjEgNjE2IDMzMCAzMzAgNTE5IDUwMQ0gNTkyIDMwOCAyODkgNDY0IDEyMTIgNjk5IDUzNCA2 OTkgNTM0IDUzNCAyMzkgMjM5IDIzOSAyMzkgODYyIDg2Mg0gMzA4IDg2MiA2ODUgNjg1IDY4 NSAyNjIgNDcwIDUwNiA0OTkgNDg1IDM1OCAzNTAgMzI1IDQ2NyAzMzcgNDcwDV0NL0VuY29k aW5nIC9NYWNSb21hbkVuY29kaW5nDS9CYXNlRm9udCAvQUpITElBK0Z1dHVyYS1Cb29rDS9G b250RGVzY3JpcHRvciA3NCAwIFINPj4NZW5kb2JqDTY1IDAgb2JqDTw8DS9UeXBlIC9Gb250 DS9TdWJ0eXBlIC9UeXBlMQ0vTmFtZSAvRjIyDS9GaXJzdENoYXIgMzINL0xhc3RDaGFyIDI1 NQ0vV2lkdGhzIFsNIDI3OCAzMzMgMjc4IDU1NiA1NTYgODg5IDY2NyAyMjIgMzMzIDMzMyAz ODkgNjYwIDI3OCAzMzMgMjc4IDI3OA0gNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1 NiA1NTYgNTU2IDI3OCAyNzggNjYwIDY2MCA2NjAgNTAwDSA4MDAgNjY3IDY2NyA3MjIgNzIy IDYxMSA1NTYgNzc4IDcyMiAyNzggNTAwIDY2NyA1NTYgODMzIDcyMiA3NzgNIDYxMSA3Nzgg NjY3IDYxMSA1NTYgNzIyIDYxMSA4ODkgNjExIDYxMSA2MTEgMzMzIDI3OCAzMzMgNjYwIDUw MA0gMzMzIDU1NiA2MTEgNTU2IDYxMSA1NTYgMjc4IDYxMSA1NTYgMjIyIDIyMiA1MDAgMjIy IDgzMyA1NTYgNTU2DSA2MTEgNjExIDMzMyA1MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAg NTAwIDMzMyAyMjIgMzMzIDY2MCAyNzgNIDY2NyA2NjcgNzIyIDYxMSA3MjIgNzc4IDcyMiA1 NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1Ng0gNTU2IDU1NiAyMjIgMjIyIDIy MiAyMjIgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2DSA1NTYgNDAw IDU1NiA1NTYgNTU2IDUwMCA2NTAgNTAwIDgwMCA4MDAgOTQwIDMzMyAzMzMgMCAxMDAwIDc3 OA0gMCA2NjAgMCAwIDU1NiA1NTYgMCAwIDAgMCAwIDMzNCAzMzQgMCA4ODkgNTU2DSA1MDAg MzMzIDY2MCAwIDU1NiAwIDAgNTU2IDU1NiAxMDAwIDAgNjY3IDY2NyA3NzggMTAwMCA5NDQN IDUwMCAxMDAwIDM4OSAzODkgMjIyIDIyMiA2NjAgMCA1MDAgNjExIDE2NyA1NTYgMzg5IDM4 OSA1MDAgNTAwDSA1NTYgMjc4IDIyMiAzODkgMTAwMCA2NjcgNjExIDY2NyA2MTEgNjExIDI3 OCAyNzggMjc4IDI3OCA3NzggNzc4DSAwIDc3OCA3MjIgNzIyIDcyMiAyMjIgMzMzIDMzMyAz MzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzDV0NL0VuY29kaW5nIDY3IDAgUg0vQmFz ZUZvbnQgL0hlbHZldGljYS1MaWdodA0vRm9udERlc2NyaXB0b3IgNzUgMCBSDT4+DWVuZG9i ag02NiAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHlwZTENL05hbWUgL0YyMw0v RW5jb2RpbmcgNjcgMCBSDS9CYXNlRm9udCAvSGVsdmV0aWNhLUJvbGQNPj4NZW5kb2JqDTY3 IDAgb2JqDTw8DS9UeXBlIC9FbmNvZGluZw0vRGlmZmVyZW5jZXMgWw0gMzkvcXVvdGVzaW5n bGUgOTYvZ3JhdmUgMTI4L0FkaWVyZXNpcy9BcmluZy9DY2VkaWxsYS9FYWN1dGUvTnRpbGRl L09kaWVyZXNpcw0vVWRpZXJlc2lzL2FhY3V0ZS9hZ3JhdmUvYWNpcmN1bWZsZXgvYWRpZXJl c2lzL2F0aWxkZS9hcmluZy9jY2VkaWxsYQ0vZWFjdXRlL2VncmF2ZS9lY2lyY3VtZmxleC9l ZGllcmVzaXMvaWFjdXRlL2lncmF2ZS9pY2lyY3VtZmxleC9pZGllcmVzaXMNL250aWxkZS9v YWN1dGUvb2dyYXZlL29jaXJjdW1mbGV4L29kaWVyZXNpcy9vdGlsZGUvdWFjdXRlL3VncmF2 ZQ0vdWNpcmN1bWZsZXgvdWRpZXJlc2lzL2RhZ2dlci9kZWdyZWUgMTY0L3NlY3Rpb24vYnVs bGV0L3BhcmFncmFwaC9nZXJtYW5kYmxzDS9yZWdpc3RlcmVkL2NvcHlyaWdodC90cmFkZW1h cmsvYWN1dGUvZGllcmVzaXMvbm90ZXF1YWwvQUUvT3NsYXNoDS9pbmZpbml0eS9wbHVzbWlu dXMvbGVzc2VxdWFsL2dyZWF0ZXJlcXVhbC95ZW4vbXUvcGFydGlhbGRpZmYvc3VtbWF0aW9u DS9wcm9kdWN0L3BpL2ludGVncmFsL29yZGZlbWluaW5lL29yZG1hc2N1bGluZS9PbWVnYS9h ZS9vc2xhc2gNL3F1ZXN0aW9uZG93bi9leGNsYW1kb3duL2xvZ2ljYWxub3QvcmFkaWNhbC9m bG9yaW4vYXBwcm94ZXF1YWwvRGVsdGEvZ3VpbGxlbW90bGVmdA0vZ3VpbGxlbW90cmlnaHQv ZWxsaXBzaXMvYmxhbmsvQWdyYXZlL0F0aWxkZS9PdGlsZGUvT0Uvb2UNL2VuZGFzaC9lbWRh c2gvcXVvdGVkYmxsZWZ0L3F1b3RlZGJscmlnaHQvcXVvdGVsZWZ0L3F1b3RlcmlnaHQvZGl2 aWRlL2xvemVuZ2UNL3lkaWVyZXNpcy9ZZGllcmVzaXMvZnJhY3Rpb24vY3VycmVuY3kvZ3Vp bHNpbmdsbGVmdC9ndWlsc2luZ2xyaWdodC9maS9mbA0vZGFnZ2VyZGJsL3BlcmlvZGNlbnRl cmVkL3F1b3Rlc2luZ2xiYXNlL3F1b3RlZGJsYmFzZS9wZXJ0aG91c2FuZC9BY2lyY3VtZmxl eC9FY2lyY3VtZmxleC9BYWN1dGUNL0VkaWVyZXNpcy9FZ3JhdmUvSWFjdXRlL0ljaXJjdW1m bGV4L0lkaWVyZXNpcy9JZ3JhdmUvT2FjdXRlL09jaXJjdW1mbGV4DS9hcHBsZS9PZ3JhdmUv VWFjdXRlL1VjaXJjdW1mbGV4L1VncmF2ZSAyNDYvY2lyY3VtZmxleC90aWxkZS9tYWNyb24N L2JyZXZlL2RvdGFjY2VudC9yaW5nL2NlZGlsbGEvaHVuZ2FydW1sYXV0L29nb25lay9jYXJv bg1dDT4+DWVuZG9iag03MCAwIG9iag08PA0vVHlwZSAvRW5jb2RpbmcNL0RpZmZlcmVuY2Vz IFsNIDAvTlVML1NPSC9TVFgvRVRYL0VPVC9FTlEvQUNLL0JFTA0vQlMvSFQvTEYvVlQvRkYv Q1IvU08vU0kNL0RMRS9EQzEvREMyL0RDMy9EQzQvTkFLL1NZTi9FVEINL0NBTi9FTS9TVUIv RVNDL0ZTL0dTL1JTL1VTDSAzOS9xdW90ZXNpbmdsZSA5Ni9ncmF2ZSAxMjcvREVML0FkaWVy ZXNpcy9BcmluZy9DY2VkaWxsYS9FYWN1dGUvTnRpbGRlDS9PZGllcmVzaXMvVWRpZXJlc2lz L2FhY3V0ZS9hZ3JhdmUvYWNpcmN1bWZsZXgvYWRpZXJlc2lzL2F0aWxkZS9hcmluZw0vY2Nl ZGlsbGEvZWFjdXRlL2VncmF2ZS9lY2lyY3VtZmxleC9lZGllcmVzaXMvaWFjdXRlL2lncmF2 ZS9pY2lyY3VtZmxleA0vaWRpZXJlc2lzL250aWxkZS9vYWN1dGUvb2dyYXZlL29jaXJjdW1m bGV4L29kaWVyZXNpcy9vdGlsZGUvdWFjdXRlDS91Z3JhdmUvdWNpcmN1bWZsZXgvdWRpZXJl c2lzL2RhZ2dlci9kZWdyZWUgMTY0L3NlY3Rpb24vYnVsbGV0L3BhcmFncmFwaA0vZ2VybWFu ZGJscy9yZWdpc3RlcmVkL2NvcHlyaWdodC90cmFkZW1hcmsvYWN1dGUvZGllcmVzaXMvbm90 ZXF1YWwvQUUNL09zbGFzaC9pbmZpbml0eS9wbHVzbWludXMvbGVzc2VxdWFsL2dyZWF0ZXJl cXVhbC95ZW4vbXUvcGFydGlhbGRpZmYNL3N1bW1hdGlvbi9wcm9kdWN0L3BpL2ludGVncmFs L29yZGZlbWluaW5lL29yZG1hc2N1bGluZS9PbWVnYS9hZQ0vb3NsYXNoL3F1ZXN0aW9uZG93 bi9leGNsYW1kb3duL2xvZ2ljYWxub3QvcmFkaWNhbC9mbG9yaW4vYXBwcm94ZXF1YWwvRGVs dGENL2d1aWxsZW1vdGxlZnQvZ3VpbGxlbW90cmlnaHQvZWxsaXBzaXMvbmJzcGFjZS9BZ3Jh dmUvQXRpbGRlL090aWxkZS9PRQ0vb2UvZW5kYXNoL2VtZGFzaC9xdW90ZWRibGxlZnQvcXVv dGVkYmxyaWdodC9xdW90ZWxlZnQvcXVvdGVyaWdodC9kaXZpZGUNL2xvemVuZ2UveWRpZXJl c2lzL1lkaWVyZXNpcy9mcmFjdGlvbi9jdXJyZW5jeS9ndWlsc2luZ2xsZWZ0L2d1aWxzaW5n bHJpZ2h0L2ZpDS9mbC9kYWdnZXJkYmwvcGVyaW9kY2VudGVyZWQvcXVvdGVzaW5nbGJhc2Uv cXVvdGVkYmxiYXNlL3BlcnRob3VzYW5kL0FjaXJjdW1mbGV4L0VjaXJjdW1mbGV4DS9BYWN1 dGUvRWRpZXJlc2lzL0VncmF2ZS9JYWN1dGUvSWNpcmN1bWZsZXgvSWRpZXJlc2lzL0lncmF2 ZS9PYWN1dGUNL09jaXJjdW1mbGV4L2FwcGxlL09ncmF2ZS9VYWN1dGUvVWNpcmN1bWZsZXgv VWdyYXZlIDI0Ni9jaXJjdW1mbGV4L3RpbGRlDS9tYWNyb24vYnJldmUvZG90YWNjZW50L3Jp bmcvY2VkaWxsYS9odW5nYXJ1bWxhdXQvb2dvbmVrL2Nhcm9uDV0NPj4NZW5kb2JqDTY4IDAg b2JqDTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vQXNjZW50IDc0NQ0vQ2FwSGVpZ2h0IDcw NA0vRGVzY2VudCAtMjAzDS9GbGFncyAyOTQ5NjINL0ZvbnRCQm94IFstMTUyIC0yMjkgMTAw MCA5NDUgXQ0vRm9udE5hbWUgL0dvdWR5LUJvbGQNL0l0YWxpY0FuZ2xlIDANL1N0ZW1WIDEw Ng0vRm9udEZpbGUgNzYgMCBSDS9YSGVpZ2h0IDQxOA0+Pg1lbmRvYmoNNzYgMCBvYmoNPDwN L0xlbmd0aCA0MTMyNQ0vTGVuZ3RoMSA2ODENL0xlbmd0aDIgNDA2NDMNL0xlbmd0aDMgMA0+ Pg1zdHJlYW0NCiUhRm9udFR5cGUxLTEuMDogR291ZHktQm9sZCAxDTEzIGRpY3QgYmVnaW4N L0ZvbnROYW1lIC9Hb3VkeS1Cb2xkIGRlZiANL0ZvbnRUeXBlIDEgZGVmDS9Gb250QkJveCB7 LTE1MiAtMjI5IDEwMDAgOTQ1fSByZWFkb25seSBkZWYNL0ZvbnRNYXRyaXggWzAuMDAxIDAg MCAwLjAwMSAwIDBdIHJlYWRvbmx5IGRlZg0vUGFpbnRUeXBlIDAgZGVmDS9Gb250SW5mbyAx MiBkaWN0IGR1cCBiZWdpbg0vdmVyc2lvbiAoMDAxLjAwMSkgcmVhZG9ubHkgZGVmDS9Ob3Rp Y2UgKENvcHlyaWdodCAoYykgMTk4MSBBbGxpZWQgQ29ycG9yYXRpb24uIENvcHlyaWdodCAo YykgMTk4NSwgMTk4NyBBZG9iZSBTeXN0ZW1zIEluY29ycG9yYXRlZC4gQWxsIHJpZ2h0cyBy ZXNlcnZlZC4pIHJlYWRvbmx5IGRlZg0vRnVsbE5hbWUgKEdvdWR5IEJvbGQpIHJlYWRvbmx5 IGRlZg0vRmFtaWx5TmFtZSAoR291ZHkpIHJlYWRvbmx5IGRlZg0vSXRhbGljQW5nbGUgMCBk ZWYNL2lzRml4ZWRQaXRjaCBmYWxzZSBkZWYNL1VuZGVybGluZVBvc2l0aW9uIC0xMTIgZGVm DS9VbmRlcmxpbmVUaGlja25lc3MgNTEgZGVmDS9XZWlnaHQgKEJvbGQpIGRlZg0vQmFzZUZv bnROYW1lIChHb3VkeS1Cb2xkKSBkZWYNZW5kIGRlZg0vRW5jb2RpbmcgU3RhbmRhcmRFbmNv ZGluZyBkZWYNY3VycmVudGRpY3QgZW5kDWN1cnJlbnRmaWxlIGVleGVjDQS+B8e52IWg3X5m udj5LtHCXQ6Io7h2q/FwzrXmINvvgyoRjhwACbvpwcf6Zg4At4TnfwVSoA20g7yXSAdlwd7q Mtg9m9K0U7TORfZciNTTq77L3gEDVax2BizIWtDOaW6bYl/LnuRlCFdTVp9yLvUvAiPskZEz MeCET93pSlWfsFUR1lwXwwgjxCzqBhqAVALniq6N58tHd1KRNeqPzwHSxiZIk3GuRdXky58B D3M4EXxWucS6oKcawdgafZOjH22P0z3Ob/HujELPrOKM3lkOCPMZVJnuC7OHhOElviSBXDoz UbBvxC1OwfzVMZ8onvAl77pQ2iQkdls8YgASi563WVo8rWHNeqLq5UB3PSRSbXFywFuinLVj PkYLHXLa3hKecNfjtTXjXVH5EbfbwPSI+1P0PpDhCXFu/OnvDIbdUOFh/ici0VaDYoUBWKEf mNe6aMDWrZMcTaJad15CMEGlvcMqEvOw1L/KMhyBReLR70NDI3FwN69WYCC5ts7QhAn6z348 snZmz32T7CbafSrhOCPld43rpcl/6PH51Ssyt/GWNO69lEI2inbZfvFnjFukZpF259u3eYyv aHW0xmj8G6PySiygo/zhJqafofvW4lq37fbR4phciTG8D2+SAILaxn08Cjsf9hPu+J/MTXRc LO6mY7GuXWxHxn69f8iH+YoJNy4f+ijm9dyPOLzdtrv3aTZR5McgYc8539J42maUdysP8nIx Pps/oeA0KH6h8GNma8elEIWr+vHA0ua8n+xMLvHXeYspngQNAnsdeir56EW73z6Z6taG1LYg xPaE7mYsVNlaMCBKY1lrY8PJiVyAV/NShbSSwRB/Mbp2fEHwKjUiMW+GWn7RsNBNnZjtiV09 TZWejZ/cAl/BnNgWzfY7K5VJ5uGVpMLkOXOY2d7QjlueQkPtneG8GtzOp94fzrOxg3udWLYC f5cSlT1CQ0YLJpnmJZk68CC0GErxplv8JAv2I55VaPv8Zpx0qFJaRHn4AcaC63mqL1y1Mj+w 2xo0qrXFb4k7PnM2C/71cO9wmuTQrlQh5CA5xA3Ri06y79zaGEhx/758Gw3XboOuanPG/gVy 3i1fkEhgWosJ/slLDyAEIN2J4irMwNI/BR2OjdfKbkGvpGNVKcKcUuMEx1ppul1v05bJP75y mSUJZeHGsc1bRBsORsxhp1aqx6jMuROE4ZRrLlEhD2I8S9oWILrRPehzbzIrssL+L03zu4hw EmxZVxfKWqDl5I4AnFcb8flHxtbH0BCUfnQJjCP6d/QoGM0Cj0qhGSk0no163zuLXrwTQo1u OkiReWPeHef5y2IrzSbuLwc/2CVl9eZ6GlLWoGb2c5qJVbnIJiGpwU+wpUUeQabt/yxlU7f8 F+4JS+N9k5EfFwtGuaUnspwgqFiFE/pCtPMQaQe6aDc67fHqYYwf/95Pk8E9WsuiUDdyuYpe /sIsCef5pP2Y37huysAeBnuqlLgbPeFtsT/x4K2Fkz3G3EsdzuEiUr4Mf6gdah/hKFf4DW4y OlwbWCQCtiVKPhQUXR+Cxms6IypchnFU4g1BJjyE1h1P2nZUB3EMfd+bqRXwEHK1BOdarS8+ 1H17qvN9n+BPfSx1zvE/0Gsm0CUBmFi90InTcCoorsJknQS7DU3JCRU4jArJkyPILU5hNhoE M4HmLpES/H7Lt7mq1nz8oMxDHt/WPRJ99NQ8R4UR0b3K1Yf9Tof56y8x15N/R74jRQVdP7qa fu6W92+ivvYmWDxrQPBzJMjRHALWiHHvz+n5gOBKi9Sf1FBTCZjUFIo6Cx5cmdFtfMVbezNT k+j+SjNdDAms52Iw7AH4JkMKwHEaZhwiFiBVjgD/Nv2WfShFsOAf2GTqsyKJcYn+DPB+o7Su IQ6ik9xUbdF+ZuAiUAbcd6pr/ffuWdlsPQGyaN4AF0C609xDC9QXQJ9Ng9dDTSdInNCB25oQ Njs/SyRXREFHXgL+jvFVqjpxwowMnz5gafyqRMVCs+6FghqXdTjLBJuc2vOTfvw4cg/sYvLA D+xskxfobn2KK6fU5Xu/qWPfm0Btv0sGBeWpQXvmm65QN9FQhR1XgpwSV/9Vt7uMK11XU4aa tcPPe9ba7XpoueKhOzmWii5Z/CHq5ipMAbyBZS+mSKA+D6Ju0tkdQHxrGfl/7kQTryAzCIhL OQlLou6f9DMaD/yQXgu5sFs916M0HsZvjlcpqxvcT4dzwnh/KlO53Aq0PeDyfJESTK0cN62K B8UuaJSOJ3GNQ6x3Cg/yOV6Ghb8h7QZ49UXu99xh9Nr9AGrzrcCHiLqM1ssrdNiUhGwumnWM ptGPM0oKzy11hqWtUMv1KTsjf340BH0nuhiRqlRFNCiCEezeQZrMGCwjymU8kwMxwDF3tk8Q CQKfujAvd3en3XLtyJNCpDVAUDCRruVTHW9yEBqtqtvV+WmA17f2bi6xG8TcpdoNtnntVmfz yNNSRFrCc5Pq2G/v+tfw3zSZvnHcNA7LSIrTLRCR4DH7qmVUeUDwbadwyt24ILbAwlyUn770 UFfxjRLpMRbLNE4175gQ+KgzM1nEeHnZNutb1ql4gQFiVmmqNqJYbgNGgiRGJ7CAbZeUtIhp aOdcuUACIjWWBlJLPFyFKTG2JYi5TxxRemwkjTEQPY7Ea90T6TYuaBwLUzysNLwT8Qyu+Xwz HYnKKxLboZccqdKbMI0lGObhVTNA03GdCbKdfUuIVcNOgGS2EMTKkxYzPqDipe45OjEbgrYH nfETi6vnn93AAB4N1XJQL3yZc0/CPKoL8mKwe9p3U9tMX9JEKSGGCuBccAZhqDdPk9GyM85h +j/clTSKhQW9y0iOcfL6Ptu21P5gTYmqVOLqLitSXGPZPnVzJ6iwTXGjx+scEIoNm/ha9tHM GpOodi7O+kwWGmOXOEc3C7q2/RGbHkE516MH/IMyeJSit4QlpDxW3cilykfHeSaJIdCmZZUi iQIxxVDkXJMrlwhwuyVHw1z6jbHN8sNqgg7sgWENE4wQTb33PunK1yac+19InrxcywL+8Kbv /dJ1PBSmKQeDEYE3ZS7qeN3b31W7vwSFkJ4oaZs5uqnRubY1eArVeAzwmZA0ccKf6uh4u9dF B3PnwdJ88Pmk3aEa/vHP5D+4tBE7h6Q7y7aPyh7uYcHssZBpH/PaUCF0pUx+OS6jW9vuF+1j eEANxL6gK6AaU5I2OP4MSM3h6tVl/QAxLUlAas5VtGYdCbc6uAkvB6a0h7h1nanLoPVM2qOF wi0f+XurFdgAEAnAsAE+hzlcNTfdBc04D0BR2YXEZ6kHMD6qXI7LqI0n6vFlt7s1TYe/YBTf nHH1eKPJg4UDI2qh5DjFuhQcaK+68kRA41QN88YOggmzUa9uVD7+LsVgw5c8CA1A+h1ShGkp 3+I8MTa7rWf5VJb+b/rlyqLlR8HKPdy4wfsQ7nXVuUqvJODY1DPcemTy9ca68sdhvn5oZOuN zg/ya4Ay+pbH4/X8SRshljXoPeYXKNBWRLeIBJO1CllwgyF3Ro6SS6l49QNjebbR9R6HwkLl WVr3qACZ3s/9s2MQD7zOjUuikGnwPjN3154CB1SsXCfwCMOmR3a+xbRGS4ODECcSDjoEIpKU 1BNNc+SsKurU+EmnlF3QmwtC34lq0eOHfW9NqkYr9rda4FjXjpWHb/+jVBna6inWDSdZYQ/R 8qCV7zKKI7oqWTiBOEQK088T5JB+RZiY8p4H7+PKFuFMsBA3GqlNh3q/Cv1O79jevJFn0eeD 7GaJk5JFsQYx56j+8jsaM8ilFFJ/pTSiU2b1/Dzdm4bEdUJ8rbOYq03GCMqzNbW+iq5HPImt PbWmcYa25gZdGgWY32ET6zTdIRp3YfKh0ku74bFqs7cX4Wv+8J+vtU1ioE8j9UXGfPHl9YBR c495MUJ0VCYUvRE530Ae++iM4IzZL6ca9bQLtMCkJBZIovfo1ZzHZOJkRTfD/9DUE4Uv1rSz 4+whTj13RSEcUYIHcvw9xTcPL08n9+BKlr5K2cmXNB2i6OCfj18fDxfDsJB2gocrTxFqzBLf 9JeN5z90nWG2+6qpuQPhciMQfjgBSfNprh9z9kJk8vV4dWCmUIXgasOJtiA9NWZFQRirwGjZ gCCV1x2tub4Pe9uKVe5AIbtWNSdMjM31tGWCBh5Kz7SL3fharqmnRlnPmX6aDvJHQVuEe4ce AOevmUjBbxbUFd6tOfwwJJmIMkq99t7pkkK3ZnNEQPRwyeJOCip5G7L3bANVuLusWiRCkOnv P2/h6yPC8/6oHObAqKqUGmn29zCP8u/mp6qoCwPBk/xi8IZVuT86+IsFGvOgs0RoP8lveG1s Fyw/dJJZrnaWW8RN9AYI+ccr2F4TW6DTyQec7cdfH4h5ZrG4idn1BikRoZYNku8+VyVMM8jw flZmzIKdghSLTqb1fIkopyZTvXZR6AE2hY012dSRgrpM1u2QYBqTkRsNdWbljso2DX0cGYHa UkNwc0HZkKTc2JtMTZtsLE6P8AUEE9KCMudqZWVk5KCTulGvLPcVb3q25s8tUH+/a0yz0NQj YqfY1WWZwCwzlWNGvhN6FbZVY0CD6JWvCXuIjNiJEENt0YqdVUU4/J8hozrhiyOnwHhAX3CS 2vo3Dts/iMsJSpqNFRcEvO/Pc6SJLui9TC8J5ovvzHQtCL3PdD1lVNq2mKlnDVBDeVwDpisZ D2NuLDkDicnxluGyUgS7Jj0c6Ai9531FKIhPvnAeMmBlqihw8Ba6hKNGKFFtpfyM8JGUqJEh o4wrrMVKVzj2BaVbk3FBO/bn43XUEymdqdQm9k4DbWsIe0opJ0Hv7NP+5oiUrdbe0n6KqotL UchR+TI6qVsK4LCmdQBtcfrNV6g0wsTiEAOtoR1EPJXipS42PbyR0bkdcahedieuIl3qjr/a IMoosIbQzdX0Ri6Q5FCL/Df9hheiwld1PaJcFk3zWawcnYUStdqoxnHlYYImD6zBNPEIcRFi /1kGdmXNyRgX40ThMGmhrbtUdDznGaibcrWzm3pD7BeyZ3PMxIogbvdyvchoMojSMkwgJq7w 9PLnV0b5jQ/mb142bWDMRdp1/bq97B7N0siJT6S0tkNPFti6dJCILtnGpt2/fHNGs6oBc8Ok wyxMXZuEPVFlSd1hHFSH2DnFQEUrCXDXZCy999AQjBpF//pVaWKhtLPwe+/PGzfdUorrUkYC rssCp3S2SV4KlBUzaM0iVPIPkwaF/FeR37xer+QVfXlqKtpwL5kS2EqS/lUB0spsOeEBX4N+ pSKZmlf6Ovx6iJzN+FPxZH+MSo46vgd/my3+VZwXPOqdekSiM/aFwIfnK57svC2E1xJ9IeCz ngti5BVzCIPR/MRPko/GZkBFNrYIp4SfPTE9UfKWA2S9oo5wzn+Notj3kfXjiOx6nbAEElLm QPhY3lDIF/Z2NiRRgTPe4m0Pht3D1KKc4IrVXEoyy2mLI3YRj7FYeWXPXtMUzKXl6dirjSwI VC24Eu6vKOUR2Gl90NkIoLqFmiPzfafWZvXPVzdFmNsLrXuwzo9jbpehkjzlLn1bomm+2mn9 fxQJvY5bDV7MigyfC2ry06BBZK91Drtc9TPtIKDvTHforAVLiOQvcvg28bRInnm8O3Oo+aft uSYtBLLOJs4+N5NoeJAoG09YMruFPiLCC58jYyBM1EE2oDzIJO0T7o8o9g/PtbYocrVyHl/d SgYwUmuWexsaOkxxxT7VpnwsFSDeda28HeuNz1l+Sw3Tfv2fZh9SDj4lsuB4CCOMEbqXYyNw Foqi1ifFL+nKyr+iySh8NBA2bMaFJgPWprL4e7NLSXJyqZ7VA/fFwaUEDpL54SNGfvXtswQ0 MB1wC+GtY01RInKpvghervyy+9AbiZiIZbtREhdEngnYQR0N5CGfhQQ3tQxcZsJnmZK4h4Gk kRm+Yiz78M7Vr2RrTjSEfwOMu7pKH0jiwTtpXvSET+7Zp3zh/ErrDsRi/ih6tGWGFJl8T5HB C7qhkmKuyBBX4paVJmtBIL1pGXz5PiFB06W+g1o59889LkJz29VnYthF9k5Y8xE8KAR+6kMB /N35kp76nag4cYgtjHgQx5se44iujnJPN0x9rzs2s5lF/qD2ClJ+9dfqCp1GtFmuz6yoPTpO MAmmAIYooZrMX/rUxTizRvLmApySwSGffa2R72ztSi2XWiutvbOausyM0JUUx2yZJH8Kv4LC 0X68QgRRxwTXkQGOy4AE488P1w/MYwMPVqWGqmQBLA8fWpppp8TkveHK947ZSFbOyD8p/hmp l+Ix3aEbq0G/z8uF1OiwvBzJ5zM0nOAelnBnkLTyb0dqkCQDxcAmZA0N724DI6TzEmv/+Qx+ ijZn1Gq6B5rFUvJ/UHyujuXtBLIACKMVbZRMD50X+169hnLOWdjtubJ3r+N8iMAYL30BP8/G nRFBBPm3G0R8HMta4182hUbFy/cKOhkwysMwm7TzqOmsrBPhye6vIU7cSbOHOGQ13e2m76lE H4XuVU5w8o9bk1R/Ll3Ddpy8pJAWsVtQET+i8F9SeyDZIAkH+2QW65pqPsVd8LYH4nujD+OA bvdAJdpDCe8kAeAVpQfLgAICgv2lpw06iy8Oy+A5XVTluQyx+mblotJ9fF3wejJy3R0Z8iOB FmuQUsHAl45CoTK/KmvETjOHIUHaFxO4Xmo20Cl7k+fCFGgU/Mh2plETpt0RDMDqkK7vL7ZU GLmnRX8pT3pVnv0iKC2iZZXeHrtd1GnrS6mm3q4v3KBhULQyNTqL/ebLa4IvBNMjJEeQhdot wHf9CEkAKNtMlqG9ApdsN5WYu5hy1HkkpuozA0ONtdRzXGd7/I1/jPqYku4Gf2tSHQEvS5c2 sK+B8iF4wf9TE3Zya04aIjwqXSg9BMX8iF/lW9yme12zzBILevDnYSYpscVMySsjG+qVBUEt /kAbExHeviLoOVfHRGZ0tCtMGBBhYd5+lvle6ftHv5/pUBOTM60G9WteQEtcidY28e3vsOVs enbMgI6E6Szq8iE6eSb824Z8grEvVRIzJtfCAVy1FdyBpxtdGt5Pzg7R77sm8dFYtYrTI4gX X8rcrDLt8QU/5v/Yg5In5KTYOkjchg+XenivOz6/K7alpryRjt4101GAvYGXsxFnDWoRlCXN fH7UzjPSzCm7fip0t/dYkvE0EAn7L98uJVZds3JOSM8KwXHouFTQ4PNEXf/jowxXlJWU2XRB ocYtCXfB+sJeZM/S5yV/ctzwXFVF2D6yqeLlOG7/S9NF50evHySSmlX+F0/2GfSmEx7KWiBz FOkdtj0UrctbFSRYcpLJI6UTHj8/9EgNsW1yPrp/k08fWZNHD/kyp9YrCf1cOcLzZw1YRVkM FeZ/5qOuQtPeV8b/ur6qxiwcMwBuDqKe8CZJxHlIOFNmDO5SZGasauzuw6bO0201b6Nfq77k 3UtQs7IWRzJCf9PdR3eAnZV9EBaNr+mLOEiNbRPFoZeQZXga+hu+dio39wuM+MaqTVGq7eQ+ R3uT18VSGYkIHZ3p/3A3NciD5234jfGvzwskGA6IOaovXrHShVe7vOYGRHxjMik+UsMvxRYK zdZYN2BqqVoNb0nUWHqurCbNUQSc7zo58W5MD+9GOm0VaCyvJpY3iY6U57aW3p5hxN3XI+mA 28UrzfjK4Fsy4fmOdrxAIdlQ/7/NLoEnBuXIG2UmQB19Y/Oi2xDtgHHprP+CVQ7MuUTQQoC/ UoQ8OUHahX9ws/RdKqkRa45DLV4btVPokAVYDKRXGeVKBUDO5QFWZHPCU1kedcZ9JcAC3uHI JwWBk5dTExcIhXIRT3zGQg8BBhqgzhfXZG/k5jPucx2Kz+NXjgq5zh+YUzSg2rMbE+IJrYht K3HmVpT4areBT9t6bTkKunEl6PyJiswIDsy6dE3liQY0lGpZf/CIzomBvrYaomIIFwlGWa1V KsnuUjfRYgH/dMtNiaHvBHcVCAuBNgwnBAcFdw28A1b3+wS1/ceYHPUWSpXizI6jVm5iDhVL 827m3FtXdq5BVulfe3aPALhqbh/Ph35hHQZ03LJaeudgUiHHyvlEfYOgstD7/UZ0AK1Y7YQU N9LVl25tgQZyNp12NXyRFLd8NQdMS1H7fqH0W4T7CC8r31IQPqYn2AcAoE4/6jqLU9p7LlFr U+z5Dio/OZyyO2iF8Phf5Zpn6BZVR4AOlI4hpy5AXFG0yCbalssiengLoFhqY5xoqEivThbB 1MbQ3OxlxoOyNW8Y1LE8AjLjFqiAm8OQqGV/ZhEfWn4uyPWcaO/MDdXH7+1OlyAosDLY8PXu MV7g7iQV+kus3kXtvX7Bgi+FKxU+M8CXk7Y9ePXZYvZ4QTmNl/GOfF4w77HYzjiM3By1NQ2G 3t6KQiQ43+0qOa1OkF87YNINcgs/XlUcmEd9Zk/MpH1PCoZpMVkWe2X7uiiNx/xWYmQDPt36 bgA3TVT8Lj2t8ssWZRSYH4QlgSRUUdyIEunJZX3MkHkx9VzOInq0eigLZdtkeutfZsBEYIEp yHFyhGIbOKtzUglDZndttXYxyQEnWqFInaLs2gm5AiN+8quxC1zxi/U1IKA7BsVOQM/S6Ek3 8EQiIPk89AahMuej7BKcj4y6QZ+z4EQmItuU5DkkbHOMQgszYwi+sR4X9o7T6ugqiRq4pjNT wdSPOdcFSbpYsuQWxO/NT3iTlizeZ1Y9c31K84pPDK6iEHUPFYvL6eSPCarppk6OjHOZ8LqX ye7kIngNtw64NkYl4VekKjpgDZyQJRPem2y8UpHMT14NhWKi2FqE4+IaUegXPgtVJVnX47cV f5zhPdy+2qgKdfcctwvc3sxIQdlM4jv3a3IXo1iJdkIfSICo8gxOi9YHt3X6h5QKGnC+sC4g klnkH6nEG82Mh9rA+jwnMpgGc7CqsyI3lT2iMoEvkVzKYuhh6aCqcrN626lfTbf1VPY/fGu1 0B7RjUQhI34QO9KHxa10CIDsSheM8JzIViOs60KW7z7A95JD/fPMYob5JEut+bgOzG1O9YE9 QP4tJN0SNx8uKSh03ZWatsrlTRHKeG9ckhbTVFZHUYaJnwg65AwlDv9q7Db4Ja3o1oh/Z5f1 MbZOa7c/S/D2AR7FEA4TjHqDv9TLkpxfYyoOHhVFp9AqKxWaYj4CBjK/PsNKJ+NupXXX2xBZ +nHdKRPaX/SpWUWejvbkVfItVf+qbfKQ2tu7ekn7pVC1Yk1OLhOtrFB3P/txi5/CQ0/cLHcB Md9cjTxMQB5+KVE91SmafgEjYD96ouWi8C9YuQFFPMjZgPl7JbrDDJiSnx6T1vxyvHLkOJj8 7dIBWLJ89xk8TETxRGiv6GxX7F6fdh0pfi/nDpyLZgKc9v0iFc2fD0DwxpaHFHnQirNogrI9 0KyHum6ekZk8L4nvBAKTsc9is2AJrrZUiJU3y3B0o1jDDnUENr5RtIvs6LsNjHl7OgMpRu2D taU66CzeOFv8pp62CCCK2X0nhn69JVoxNER0vuqJNy2r8lDTwOoGHykR9eslpHrR+g0RtJ8B jiOoXiVADgcar/wL/UY2veLMUwsqtxE+vkqKPQfW2XQDS5egub+GmsJzWLvIKOx6NURj7QBU e+YCtHbYq5B8to22Wd0YrXR+CMn/IIxVLHMY5e+hVsA3eHSj3VwhnJR9ckjQnBZU064Jz62i rPJdqWu9ivi4vtvL89taRdWtZiswdPROn6GsQGY7jhljAuopHKvVGJy3o/Y4tvKWLUmkebyY MNPSdIT2mvYk16kE6xQq60CNbhx6HZ6x66IiotJLp7LwyudkmbFTjhFuV4tdLkuboV2lOYJb l3kV4kzkFbeHXCL1PwbE4XkLl023L4MXYnl0w+YxRCSKSsSV2Yl3DUevJ2x5+eZFT0Qx8uIp 4MtbSlsrSN4k+B3qTgyZk/rmpmYLDjhukkDEAiC5N/Epmz0aDqP0BneZF6ekXmaE46kOK7PM GvDByZKqNl3xqj3w+yH+sRq63OIb18NzfhfsNvQeTBoW1NPkyJivQOKTLxGaBfA6JBTXZEfd hgf4hBY7Z/4HtlhrUB3O93QtdB7l+4m04MB9UvcRWYw7ER5ukxSNxIqAPNkxEdcVHAAmPjxt zqiwVsCA6IN6+NfJYtd2xZWtt7/e4M+I323YdpT56TnXtWoAB1f28ILzOd/s8GfpKYSwj8y9 UvwM6SPxP/V6Y1v0bZlsLcwvPDtAgKhpZBS/0Io6CyIyOs5KgLOu7Pi+xBdlmT6PCbU81lQE JIXtJB0wsF9SOeAQr+NxQ08Ibzh7SyCo7qESmJQs10t6p6xJ568lsOTTQNraf8nTWpTrdfeg 2C3tdIExoam0v1EoH59fvBmQaSurxxSqADdSX19/v/NXaLyGmD1aH70YSKIyYcji5a9eqkp+ Efi74G6jroXYOSMQ4tPcD3CS4me04q+zrfBAEIEKyvNmAzEQ3UH/0F9iQVI8ltWu1FBLg+l7 kJXcezvvRuaEWHuPcmBYZ21mIwuBVhm92lOfh+WiIr00oKEjQzuTNpRtC93PdAERzIGo3UJb WQDNusGq5F6x2HAePF1M3dz7QtGksaDBss3hkmucVDFVfmZlKje3Lmy/X19ZQLzGjf9pJuuZ n1fRagm4afA70IPnT0PX9qQKM3J9rlJ8x0s3XTyv9BgCUpUfGrw0p3riI7V6nSud8+E5AJMY hsWfhYAxMfOJEutIU7X7CeVgnzOkSR91Q2l6TR/ni2AgaaX2tNligFRx0XZGZVtdjoZotDDt GtamCG380N21Pe9XkP7HegCLFZg7o48czFl2HQAo3xwOb0j5NlDiULVeeXe5MNDHtpSbokeq ch1+gT51fAJritY7qpjlCF18NihNJMtw/yA8BjgE+wVKP3KcTO3SXiEd3/GoNPxP4SzOObZQ UzWnytau5u9PUUsodySa2QDhqHIGpBA1qzDmWgi6fENHgPqnzWSM7Lw8vTTkoEY3rz6jT3KY X0+wwvdzgtVkzpcG0B1b1ZlejJTJ52DGrGSfCBn+Du6nmb4ElY6nZ+hxDSn7rLeV2eam8Q9O fQRP6qNHc0c0BpS3y450LmiVbkOVSZFqDkAt/OUWTBh8n4DBYcgeVt+drQbgnlbX/caikyuP PvGhmxbVrRfDL6RjeKX/lTDkF4kX74oBs97mWWvYB+9J1R/mmZETjex8Cx+7haIA/QDFEIhE H+sLSGp7Tm9cG+a5Cg0Tx8hsSbRhzF1ghlr3VbIEpy9rLKgClZFB4M8fR3vRBFip3OOGJYZJ GgleFAuyXpPcqObRv4uZV2Xlc0ecChmtruzTTrNIFoqH67b+EwCnmMsCmR5MFljnrLIRmkFL Y9g42qKlv4PCoQnF+X6jy8zzBmE3FnjTj1D4p1nxg+3nxdiVkUr16lMFaleZqLlWT6BJrcw7 3O2kpABEjAF+W49C68s+0E/QfFh+rD49H35sFJhSugZULozBpvCKZl1ZdWDwLScnsWXTwJ1K CnABfs+I+/6hESH5MKdac3XU5RJO5UPr7KSy4DwyyDSN/Ye4qlz8F6a1WYnVFF35c9mFzacC XHcDIrF2TVpTAyF9lwjNxuab0TEe4V2ZiObXhOOY4VGS8/AS5oI6xUazefEi8tpsQsDs3XfR 2FhuTaCAXIvsedxpoftwWJqL0Y7KHgumiLIT4DCEoobveV0bspOAlnYCiAgfdY6PZhp6NLbZ c0WL9WlbnjfeQof0G4MHhslaWM1I7PqZqhg0eyNZsJp2NcLTQEeldd6FfowC2KZ2nZq3/maz kRAjT3bAFY2QRsGedR9hN4s968rmghdkyJfU8AHoehMG5iILABdeAOTgFGHveas58BbLWnwM GcdwR3vvVDJdpMZfu6ay70LcZffAaMD5aqnSIrqNzDTl/2aicofL7wqSjD7XkJ/UtYLDYLEt 3Bn2FhSsHVNiUML1Q/ffAkXySexVSehTNc+o+gNj9sRq/BXcVJJYfy+ueIrE0yAd3NNlHg65 04dMCUk6u41R6LEdq2GlDAFECmqZBYEvH7C9rWnpGxeL3WosEVg+T1t/FsyoP0gQN8LVri4C bUsUJFHhxt5Td4CzwmueRHWwtYt/OLJQ1jgQvoXDZu1Z/6OQ7SzcY6sL9oi/9wdBjtMiFf6w 0UKHY4hVED0znr5h/ep9H3L3EULnB/kAN7dZXAUYNZEWi0wGEEI81T3VypYTvasl7MZ/DrSz 8wUVv9o2WYFArBqT6Ny9APP8I2GRIYckTt1tQiWnQvEgCxAYWF6U/BrImTNWrKbmwL/9qqkq Oq5WXPRDLzx6OJnJtyoBGxCQEI+WMknq0V6v/SJbUdZb7Bf03gMjHWa2yVQMBp2zmZWyBsm2 h7VL3bJeXHf2iIbBWoo1U5L0izIJbp6DXodYXzyFautiW8QUC95YcWVGqWq4g98W5x2SECAX E7KPms11+HNbsCIytWG+iufYLCKSMIbOi+JIjE5dKexeukq4NzBg7uM7If++tIseHA7dt+BB 3mNLdu9tQHpns2ocg+Iwiyl73sqWhEFUvkhgmAZ3jhIIqYVO05hnwdNlbJFj/rWrZBQWqoSV v1tuA7K4kDpz2eQvPf4EYtJan8tRVL5ZpiPJNF1TjxQV9vDF/MSHtaFKa6irOwD6aF5b+3po EtvsqQCEbfPOg2++S/1/BtdajRbaw0Y26qe7tqHycZzU6PVAM+orsmbVZTD3wzEk05Mnqhei wRU+TWm+W7p9fnuirysAbxMRXtinyC6E30e1umdDoLAZTSdAfG3f52fTqsWaXLK1RCrVPcZ/ BFFfz9G1rQ7tLv4egT9ICy/grLHEdRujZl1xJuT+B4nb+UlbhZJ28TWqomfZMEobCJehXZnb i7Hvzsc4IEd4yARGF/wfR1+D1D1Odu1dJCl6t1l+Cx1jnIB0Gm92XmW+M+vF6j6pkrpCZ7XW 3+InHOhSBu6wVXRzdKGJt342BJDsDcygCfpatR4pndl93Ix41PdN/3YDaksYrid+kcAg9tqW GStPV3I5hpfPVj6RZlXYMDV+spl+dGJk9en+zb0ARRjalwnPpM99Up8VjUjnLBXgVRXZFUqq SR/IMI4pKdMn5crW2Jop94yQBs6wrvz27PlMR1Ts8XVqe5tmcHJTXqLUl8UrX4cb2KbPTfCz zTMFSLTCXHKGwngPxxjKPqs7K4zonswKZpVjljdQg2zjIY+SkoUegJYzrAFsRH+OOk3KVUmx z/LAzsqI0eEJjroK1BrcljlR9LyXBUWZD5+OmCIqbmwPiY0CWtsNTpK/gPusZ04+qECsKaw5 kmwLaU14saVXdhUJvLmOZnbMGH1JdeijCMm9HdUcftl9YybltKk9A5ivdtNGGceFziCBzt9V 9LMP7HbjOfCilA7KMHbMvoKuh/fddWG3Ck1XJ8NgZHAqpmzQ99Pd83w3E1yB4MG1ncIfLfJF DMoHTirKOi+ppufv1GrKwyVaqjKJMGAKvaJm1wLi6eEcaIpHcuJTQxgq94EcyuSVG7HZN6+l 5IJ/EGWpIpH/+gpphsm4mWar+ggN/Fy9qvoRQR5qKhWQSiTCAFL3cU8Z4iXW0Ln64tGAd3va U8mT14ZNkXFbRKTxu92z3BYR2+9iVMDh5zbAnIJa36z6wKOzwxGedrs5RdvTtLwwrrSsz1+D d4DVQCF5l0fvH46+qWiATlFlxaH/EtTQTz/kD0ShnxcB0h7DAsuzt7qFNYHeQdglI1L58kMv ECfe6idY+whBopgKv3+rnPL3dOvgB+hq1pr8cD4uNKG76sDSg4q2VKPsC4yiNSGVY617Hm/B dCq7bjJ2V3RKJldTgAShS1NQy+G/RINRjgXvDwNvChyTtb0Aus6eElmjeWK+zvsfwUsknwKf 4hmrJuf2FLGZSeES4n6p1A5F66ewaz8m+xQjdTEJGj9diZPyFc4QVRP9efoiQnS9lPQxcI7P SXVchzS7JdKhvO05hoTOZw5LJmCJ2nTfdmkoqtyLb3KEvndB0zKsb0ldTglFVUP+PXYo29CY lEvkKNo0pvf5NJH22rbch6ZAxjX3NqvNNE5rhr7sBD7RD6PeV7q+gYvJMYCezNyqp9tZIbVA RSpEe0iYLQuxK9ISA43/NkPLZZLuq+QahtUw66S+HmdENjI1vPJjYZib5zqoKvqD5i6Lf5Wm 1F4CG35HJtdYaXGbSbsF7Lf5Y0On5o6mS3BF6Zr5HmU9Ux5sfpY5SQML9wRQpXXmAsEDpOoY 4csTXo1F2+M9l2eWJxFRH2d0ItmIyFsNYDzzc0Uu9v+Tu9ohVFX3+4QPDIhEBDBbKV2dmdLo 82ZzxRFVT2025NWDWs9iBfc2IPwa0qdTxVZ8vgR0gJK+W9PindCP1jZQBC91h/vTe3tP8UWu bFXgpeEFjO+XLZS9+H19uT8NTnsT4sx8NCigJRgMgGdcdIUZLFu6AOesZVU3BPYu2FXFY8p1 kyr39g+ArT7pzWsADNC+oSdDbQ5Q5BxOBf3s8zFtLci8Bnpgxgy1VsoAg/mzDOhCyfeKJgZl 3m4pv1aYbuA6ekrYQase1V9rlCDa/hmi9OFP0oXb163bPmqqroNo3j678HQsDz4tEhcg/oOe 2/wv6mRCK3yDWaHr9LSCCLNpIbNtQnygIlF+Ja4VkfLHTr/eGSAUKqVSJpaEtEEeq2z20Zj/ Rbhk3ue+cSaF8H5fS7EOhNlrR9O2qnOGRUSY1AyIZm/NGiJQlk/Y3YvK+J2/KAKOJjIcqcrs 6XjIxtJDEEJKJOnW1g3wFuXAsaRYFV/N8tpRdnqnfleluII8HkCWWupdkitIT4coKVGS91UM 1VAeuxds8lZpU5/8Zk0oywfZ9VJSltiJNuAO2RnW2z3Axhw5ZAmvrq+JAQ0pGifwYPmS4BGv UdA5Kjjr3+fhhI8bVZYf/YMXNRzLCYdN8dv36bc+dsfz/88ZRxcogKnbS0ya09w/1qN1aTdq 7W3CDotjdGVnrGc5hZqBnF7bQX4XGQGOAMXMKzwlr8235qgAGg9oeiRi+8qfzG20w/YaQlJy mamTipmWH980UjLDpvACcxJuw1s951OEFm7LIiH/8exTcu+HJb8KqSEB7+8voggjMyQw8oXJ OKgBVMXvB4y+ABXKA3GB/+24Tw2ZFXVL02hmVW9SsNrCF960irwSfiMTk5q/evISCiT0Zx9y 87busI9mjFTO7gWsZHHQ6evgqnv0Ni3cVvBls24hqm7L0v7VDL0K1ZJIIzNJWjktrKYjHpir JWn59hXy1LTmt+DASOVF64e7O+QJd6g7SGpZERL1D8TEuBBlT2s1ehh9N0ObZpoQK+PqlHyN sSzfS/uIv04oegAufibEbl2VctwAekdEheTIam1LxNfz2G7xyCD3fMY0IawUJLy7UyOyUvZF EG5ozJtmo6GHY+Cxynt3Yu4wMaQXHufro4KapcZC0xFVIt8Y58oUqSeOYEjJFx8GY0cQXd2K UcXZ8D4a1YklR+nK40cC3ejM9kFiz0vZPNZCsngu93tCaEkHiKwJH7qM8bmfFs97vzbeCZYK Q4AG6drg1T6W9jmhUrBTEIkcNZprzYcBGDN0smu8re6dH6PB7y0vL1dqHpRV9qNak2UDynq3 UaxoDcOK5z6837Yj6y7C9tvl6UmSJecCzZKtp0pVUsKPkWyHBEQIDV77SOfhjBY2bLxcnMO6 9/BhNTQmxgyr31OVMOkS/5OU6BywcZm6jzOBvaYN1vCi/Q/Qm8mqWxTA3WgOniJ/8iNwb7In mP8PC92sOkMgWTfzDpzs+YznDCf2xFcEC/Kf9UZzUccUe0hB2FfgHnoEK+2LjCZqvzr4FWld jui8CFbXODN4R3GYWola0Ef8D+tg3hOM25oSHqq1FIjlgNVZmuWZRrm2zFKCsdTQRmxDhOGT N/04AUFcw7ci/TrAXtP9AGFg4kU4AkDcsbgTnXEoqmgB7c2KXhEcyvUBc7niCclW1F/YnErU wviQnI1UsCOrHXGIn7PRSgwd43AFVgPZOXXTvjz3jqkPUbMZnUcKaUtfYaMPsq/lU6xe4bQ4 TuviXFCcpdUQiyr71LAt3U936KH4E0kludnN2nxJbO+6+UNev9C+65xjWUNVjGV9KqetjAZt nc/OIhs3errnpLRhhaclY7U7WrDNh4L4Y6ladkDm5R5d0HQ6lyngqqIEDq+Fw3U1xvr6Y+hd N+unTZ2rLEh9G0RYN6CyDoK3V/cfRzoENRjLv5J3AteDGGeaJa+TGsIITl9JiWrp60JMYLTw N0mFR/5Xf0QcxFwpC9xh7GhHB0rWovDUrnMQvNrF7sWozv/KTmtY3MEBuhCuieBC/eRUtctf KwudclOK6XeXzzXxTugQNM9NYOJhQX5cOA3/IzM4WFnnACqojQ9095z3ctZVJTLewsnP/Kga GUPKp5VDPJluRD8qwyaA2kaQ0B9IykQk1078vbbxoKaY9zrfcjWeoDu/RNo3saUbZJbs+FEx lsTz/ZENK/P3l0XfdISI+TRNCb5qHcGfVLHgP03ivVTES3DKhXsGoBVf7kRjoGh8m1F4itH9 GA3aiegwGI8dCV+cxsyhZYg6wGTntOZX21/VJ5ajwnUxaldJeAyMMh4lV7AULqatgAjdoNud egzZdp1TmvpVQzAcd6IcycdDnMkgPBkpURpkMaYaVVsRVfc+uD+ncjfIZnLIinnZFalBMGgA t1b+U5cxw/6UJFJBe2mo15PNLpgom7ZcXvvm+6b0AG4a1tIdOJTee82E2k+B64wDQAs1W3mx 45+WhqGPEPJOII8Wf7/BlynCrIs/DNE3Q8dRXXTlKHBkDwB8ar6x7fTco60NdFi4Qljuzsmq sJp55VYFyvpZj7LdFI6FIPGFbeMKTAt3nUfpWb3Ovqbna47/nqGPxvnTjFbacBOHCoqvxVtP z3bYeILXlZixZkIdSp2fqYc3bs7/j2rjrzxQRokSKTMJ8QVunJ3ksJD0qyRown3TPrMdPX62 +RfSTfhEbD+qxpUuQ+ofc+d9yuuBcuqRgoLaG5OfVt3Kh08PN6WeqL2hwf9GfAIvN6MYOE5N 0F62CqF1AYJOBELTDG3gptkXaMAA6z3Ffzqx1SMBNPzOIWugWoyrtvxg5u/u5kzaRXMyT8uM 0VbJjv5Cx0JZk/sULDGY2pCULQ8wganFl+15cCaBzdkMVoQzsAt9H1dAuI+AePupXc5kDCgc v/jwA1AZGFeao/i8yGK+GIOT8TCiik3fSQCZDrgbYzwV1ntVFk2o4qKlB6+uq3szWBjtXDBf /RoKV2Yn+3nHAI1Ha95SU/PFw7vEYvfmFItNVSLmEGOJ+M9cJ83MyuTN+vYjxh0B9XiKM9kp SYUQKEjupXWYKvZIL33Qq7DlCoRRDmi3iIIanxS/iXHlA5LmxaL1hBx9LPdQqERwvb42fV5U lc5TQVOl5n/SqGmhZ7aq6K6L0+vmz5LMNb5X+HLThaX7f+y0qeOQDhLDbfm2h379qLIzNaxb wEiUaPA9gJprsnE84YnutPrRpBduZQ5YxDg6LZ+IAomw4exxc6/kmWkbozu1mr4BMMnkF+4w 0iPzZe2+54xeYravkeJ9aOnx187Eg+0dSDiqdmhPpulYuAK6Ij+y3N5BRVMd0hD3L2cQTh08 EwskMe6rjgTwn+uXGNO/I1dTWZZI/Oka9LVNpQ4+HrHHQLOuB3o4yVxXl+2sUlodd9MpK88d oreWTQVoZeQZFnlS4u06nPP5iGc63IQePXXGIKZo6g2JBzjoycaGJGUUzIcU8eFmQSO3LQzk Qjtdvjr201i0MBRwyHJxIlG7xhD6Xk7Xa1Zw3o5oyuFT/K9s0nW17a3ZVo/R2XA+iYmBd8/z 4nk/aBLYi+u0nYFxj31wZWc36hJS+S6+tU6wdUeWBMVobOTgROJEptHhMBs0Ej09aVznInbd LbRVGkMsi3PaGaXiJ5jXM3ogmsgtJnIrNI42t2KKel7A96IWXmxRspS8WpHhKyucVImLqbMo VgXPZeiHZP4gbuuDxJqyfGljL8Y9XZapODqY8QrGjwfIQtcdP76n5MM9SBl058J8a3D51jKp tPxgjIEUDdJpVlxfMp22O4wKvc6WZ4dWIdI52nPAqkpXMeMx6JK0Ftc1vJK9jvVmAeeZmJ0s dJEi6wO+i6IN8qMBkegsmVR+kcuGBlZVmeeJ5Cxsn/KG4aWgXtkjZ8kzbDdql+B8EOQiWrHC NeMmZpa5doHyt3KcJqZkL/vkP+GKAehrNrUdztGqbaZw4evxRKJf1HyN7FhFOEatl46WBwSS ySOlDa+hfAWODimZfARsVPfp31nT2hdjYPDnzf7RNmgisNAv7MMu/ft3TVvRsQJiibw54rwj vp34mcp0svDxZSfT2GNV9wp4r4i+mVbB7TSVGW/9oWphbGLRVGOYcu3yfLiJkQ/6/VGMIE/0 aFe4uQ/fraYiJHn+AkpX7sstIbnzJXYbuZk6kaI/hHLuz9hzBMwCZG/iMnkozQPfnsKWTMCI OysIXH4dwhoVwoQcs1527Zx20Q9U8RqNcA5YZhdHH5ORXw07eiLsmkm1RVMUgPUAeabHjwOG gOHHQlF37b2pEDtAiLfjdclBY3GGw/vA5pYl25jekbk+g6ws/zwq1JtT36w6EPyqaWK4b13N hXKCTq2gTQuqxzOuID5IZyh/ypfNGI/HM9gLcFaIwcS14jwhVfNhvlUKN1XUi+i6vWMymt7h MjH0zRMRiJvwen8ydVBbNTkG2PfNKas7pjOMTTefufCwkUz0FcsDOTB8jx+iZ5k/27AwxwBE sZW61P2oSf7J8booMoWefSEO/xVaXCq8mzdLyiMU2Qtg1J7LSK5QVn1arx3St4Fyo3vY9Ynn T6RIKspUm7Ga4toQ9KFH+kX+5O1bZCA1pz2C6joVqKecY8cCIAzrMv+z4/plquDlBVMTXDSR 9Zuh4/YIki+GfDR017ZqoMOjaAPMdU8Up42dOQklNrugub+i39eC7pWa3dLM85gi9dNUFLXL VKmqcKe/dH8W0sCezKYbN2ibFSwjZvNcJTOR46UT5LsLybnSfUNGM9nUD9S1qMdYHvz0d3yS 9nnkS8YjdjUqnXrtlRH3tOuSQzymdaRGoE3YyKHtC0JEX53b2xBkZsJdewyNRiyyCjdBNNcx gx9PmPLH+D1IUoV5MgYLpLJdj11GVCQDRH9Bm/o0cQP+Dpp3UuTsDKMO/O2qn62yENTj+c6d SbvYkd0zaNqnVHHVy2shNDBow6SdqVWZX3gXCEaWP5nrT9o11V5yqsBWR0uBg2bVVWQzedgM lkWX4lnxZCV4yYiw669fGTtfXXC729Wpnyhq/Nh1R3t1fcDInucu2hjE9FwzJCNZly44Kb0F iE6KICRZK4eWJ5ATdSHPKK8VTFzkaba/UWYYn6nYa5MSrmHPgZzjmlAOdTNF9pPnvZRoyXn6 INaGH54ZuNtO7i6rJn/IV5d4v9b5Vjoiqj0dIF9k919AFX0u716x7f8H//6X7vaVuWwAU2At StZEG2nTlvkOHCSzT0wLef2120GHtBKmpHM20NDrCQ0+1mqcltlFi2zU8AoZehN0Z4Jxdrzn mD2Hr/QfCL2KAFR9+c04WCaNcE+/ODn15ls9nbj64A2uf+jBkuK7TLfoA9qI4U0o42oBquyw uzpDUs16TIk4MmyT6nceseimROR7oVALM0f1aUIHQrvP6WmnJa1as2aRdpte3GaYRVgaYQkp WFMVrKnvUw5i5eiAOZoGrUOOVmwcex90hZGcKADeM2cO9E48o67nJpNXhwqAn0Uqdws/0D7v +atZs6g4DZ7HpHvsyHIqzyGohZk+p1nE+M/7dlu/qYkLHW83131FdwcjIUrQXRoNQd98w7oR ytJJUwmb1csEQ28iPFTbjljt6Ud2YR6LR3iZ1wgN9fqLs8TqbXYxQmYl7W+TJSyVyxlaEuop 5s6Ki4+OmsrOpc0kdOD/BnxJwqwmm1sQPoX2tXHc76HonNWkR6Hm+96o5x1zmYbcfqCDf7cz Il+JJHM2mOmNzg7WZ0JcC2JCl1yN8ug0PJGIdbq/HNYpt9jnm8MoX8o/7vaxyVMmMeklDUdc +xvAIr87zXfda9DYee7bQ66GRfPtpqOGkmj9lkjgulTihnzRc9ptMzXYGIPEiKHkoZhPfrSv EfSlS1Aa6XFBPerdi3WGYGxKp9pyQ/Wn3Ji0EU0w5CAyS/kNao6lqEimFoKVxM4HO9hUVAdu xQ8YNTcIiloV2csyXtomn/PVDhtYYpP1qCN5mZeGGJnsQ0mTibOFJSl6/6Y6jiSbhclIjZjZ lmJF5jxyER1U8SWPh+/5Vt0RvBc3ClDEXCZSijYhZaN79Z1aaE5YmEJsnsZuO4KwDT+E2Ax2 uqn08ZCHfzleJ660AOyMO8yncjeNZjKG9y6FtUCteBw4z0IQz3Py1uDJJBq5vpEUbu1AuaOB 9OvVJgtsPk3EZ0tCLtF/FD3mTDyH/Qls6og3I4NkVpdgJCNNlpL4DgGv+mg9QrKeVinl8t8q UWAT9Q6ThtxphsrB4kLiOmW9ZAg3bjH5Fn74DI52khlyAmS08EpDu/h0OdQuQCMRgHDrcOEq D4HmjxToYFWkL18SU8zdmI6mRXHA9ygsGkdvDNejKQfpS4xYJSfl0F7ghtW0olwAci+fZeCO hGMefF99ECxLApiokhyE+ZPBSnJnvCUenOGFulmteBv5ANKpOOp+OPyKkj7f2AX6+v5MowDG PwWdQMo44kM6PPWT7wPY6TM8iwXNWiTX+Zy+rxak4Cq8WDjs8vzsuqHdZcP0Gyn+D9x+nxj7 /aYD+5HzL9Ie0+ru3lk3yBBKr2IvbOTq+4ibhy2ZLcRWZly8WZBxHBq+Ed5l5dkkWBhEeqhI ucn5wXPtynYGzzXha7vdL2yYsbcDjEDNO6TfimPEN3s8vm7+dIKG8X5RpzUo0C17C749CVYn lK+Ir9A07to3PzbRsb6TXjjqQ5LrUyI4jn5iMsyHUTYQr76h8jPtUUySHEtefw/EOPwU/l1b TLtpqhOJPtR1b8TUcKmIRpNTI+mAl+eSqZeLo/prlxSqiLwcMgFMEjWTwNeSRixHUT1ZJoiT HA21iDLDcBftyE+1exO2f7ThIHd2LpYcFDmIlY0neeixdwIwNgr6tVVh4kzOIfL468GEW6YP Qb6LURnCKfOOo/DWcmfxUgS993IEuHtImL7qKETPBV+Cvd7MVRKWCK9zG23/b9k3YDHRcdA9 QT8L/E6rQXCpG51ofQnFoMB1R6qrNTUPhRnRF1sxjOhiMs4K8HwlYCXyJH8XmJMrsa7VqyBd JJL8Vv0uD2SLVwEI+xYgVp8TeU0vASsOvM7VgCnAaOfVOz4yAbr+D7n/ApYNdtgGD76KRAVz n1LRpWNGVbxUgm3nRf75QzP5uWXLn8+gguadbNE9eqzJV1fZLBX29CHzNbdxhcWf2dUcx+3U zpHmDv9cdM7T1yGYVPfa3A4CeyOSXe/53dvyMGYD6MVhJEhXWBzEHzCL4UBs7BRRy7SuBkJB /0X3Zts/nWa91ThY1/voG+zf3pKuPRDPpivXa4DN/cARSlMq4+Qy28/b7f6oFVstds0fhHJm rcqikiIpQ/xsd6QvoYVsf2FPchMJOWYOtKjGuuNPE47wHE+vnzdvFl+HqwJp2ai+UXDkVki7 VP9WdgkqTy8t5leAf14KEO1htw6BLDIJnsLShemr/OYyNcp5P+YBz7GANj1eSeLY2qSN+dbj bqEeuE1HU8UNKmyTZHDwxKKdZ41gFq/7hUZ5P+D3I2YXp5zUDLOpTgOGPruJD5EvZdHwf92D ZadkMJHVIFV1xN/THi5Q7aXEJkqsdPAoQggsyNLig+BqTAZgCj3wnDplgyOvcPPgu/ihRu3A ti7rHkD/+i2BYIIPCsp6FvvjR8VXHg9H7y02OGhmigISdEGgLN434AYdrGtkYCAwdGAUYWa/ HHPsu10hXFPieRVxigp0ujI92zgVuBa0M4X8aTp0ExGamCri0DV8cw/ewwiMhMknqitG8CKx REBCQ/NJZWwR7OGiDV+PO8tF22cNZimU2YvAggjlHXNJh/c7HXCQrEChZQcr8PIpqgblptLo P5Q8S3x2vgOCw1Am257evZlqjqlwNWW8vjFE3JnQu0R8IPiNbaTgy0+QTN/DzUqRyjXKFbLO SKz+1RsRg05ADSWbnOMoIZn5633DU3oSf36KASO/XByMLXSqLrlyPj1SX4LSHbEeTd0IGbAd 7Q6QOkMSPqawnRUbzQj+UxIFBvdgYfn46ZWEJazpPaICEBuOgccU235DADeBCUrLkuV6gGc0 TqGGyf6bOCt+w0s/oSiaRsACGXy54vNFZ3bJkniXxef0bNhQIWB+rMy2PfkyuDVOnRhp4HUJ RXCNPztCYJLZOeb4/fD30HaaE3o4Ytsqrz6bTu/6AgYH8hL2M8QwH9kp6mZXtw1IQhyhXSSY heuaQqevO4sVvgRoWjwHRYYmRMdV7Q/O4IAJdqJeck2r7lCnGxfXfjhDre4BR1F82ELlLcr9 8HUodFomAyvMZ159wklkKc04zVTeM2uVC9BdmhObulgB0BqEhKBEW2iFRq0Fzaq3p4I33nmL RX01AZ+ItCIcXCoar0ieFPD6a2qIm0QRzcrxa1nvNtCbH24dxWT1iws5geDJEwgKCJYx6iZz oYBhSLs1RAe9PgkB2ZAttpPD2Bn+tzEWummFjPbh4XERHcyQpSi9i4t2INzjUPQLx7Bx22LP xlaThrg+4javzPeQ9yBn5S2YlzSY82Sp/MiSjcv5vOt1pyeDF5n98owg4AMrJCuJxZkUfk6E x54yHGOF+3tDWuPEMcwwVMkI2OrtExmeUfNOZK0Q+d0M6w73Oh+VBl7Gw+DKw2EgvRI21z3U eggXyFRqFOpM6NdxiVNHTQZ5JDYX8fGfEaFu8G5kBmUw7DBCNJmphvPL7SZzShWRnloVM071 s4HbdgnaGkZvbPnwlg2Qss90mp5QK9QqRdeN5o2kE2TjAJNuW8OWCPPSRIrmg+w7s2mVNCnJ LxYXHRyWEObDOdTmIftKxpdsmaKQolDr2RaYnZgOJ1IrVESVoRLmF0v/ngtrt0p+af/zt0U5 ujHbwv8QsSBpAEGxdfreF7/kZnS1Z242aJzK0LnwquQAGJ9ZZ4BauDRs9O12nQn7Dssz9O3c RFX7aVoGE5iEevK8mbsWyn1iNYDarUsma9TqybXQXRAUzxCCjc4kK2bTlt4GZ39Y32gFlqPb lKYtbTvxT2jF1fUBFP8N4SSYorn8M3VkSSTBwhDznRU12U9Peip+TyZKrAHVER+NqOJIzAZj FgJQm+xQpLMzWVylRnmtddXOxxRjmDaYEhHcc908QY+/m8FYX9+vV45LWf3fJESBjgXorz7h 24+2xz0qqCAeppOosYeYdJXyCw2JetWZpp6vWKaeUfx5/mt+Bc1H4NcYnaEyV/tDcWivWsRV /8RaejPxxULRoiJ1oBiEQiwlHrU/XpOZDWepiMzp1P+tHuV1DKWfkQrJjYW2IggbLP2lM9Xx wpUYp4DyOWvr1XtDdbsnntDLgpRT6EI0SlYx1fuWgti5JHVqBasb+KQ/ajJ4ql2hD3SsOATc YxpOabfwdaxED1FgRTp36d1xSNL1CyA4ECuFtEEbGlab/6mA8qwhIclLnDk+mLgKuUnZhy9u xQ5jBJcRMu7nH1m6+hii2MIFkjfTp91xSGw3xpNlsbMj1J7gsbArF4GsrNgBm82Gb/7psmek ekCJULc0IhRdQu5QsrOdCF98clDXFVSnfaPODubj3WjdoGo8jV2fxqq15E7errDaYssmqNZH oaShtRaXzknD8nJvs+QUkDk8cQ6OgM47F/zaDPdA7Q1opBp5FFlNaZd0rDbnpimp8BRzLnOY V2TEl7zTf/XkLRj40N+hm7UaJO0jj/zRWszGnUdfF6MCTH0pVhMX52J+S91EtNXh4ZaX5yZ6 9VPbgaWE6gIeXOb9d8CL1S4ihKVJgLi5XLBSpWyWjtq0PTdhNCfWc+vGEFh6rnH+sxslIH35 y099xpmJlIO8dtDwA2xSIYbozrFb117SuxD13aLW8UeyNtvGPSUGKTk1B/vlW+WKud+a+Krn DIKYrWVjFqYp+RC9DpEvRHz5T8G7QDfx+MiKs4DpP5ZZL5hPTYiKSQDF+NGhtrgm8830JvJd bJKrdK4481DCpr26mmEqLnrSYq/43J5MEQAMCBzGlzXMlAt/yZXLWOfU0IzKTWRQt/HquQHE DabFJsuMyS9wCP/4E3WyrJzOqGV86S/M2qu7OpSCa//Z9DoL9lQj1NikO80LL9SlcWCpq/YZ zj58VmRz6JceAcjRfWryVzRIwYphFciaIRBaQoisIFbexeYrw5v0d2W24g4Arivwpx9A+tYz WFxIsMI95Ngbv5r/6kByJMVQN3c995syGFjnL2V2OTGdHdNLjxR8juVQMVpDt8hMzr51OetY gQQK4/LuTbwK3KJZhydhF+MPWKAouHPNYP7eXANTJHkmORjJ5H/UHqGayZJzzeMYuyUzvzIO M7S8ZS8fip1fVajz7BNxJSzEVPp1T3l7fWUKPSxH3JKRj6BCCdxb69C4vL+8fIpJ8EvhWpIn hMKgzm8U9pOaTf9ytW+0GvRjBUZ2DMLNRHdfc9CzcOa6HnZeA0mpAeW2YOKfT7YI2poF2y9Q p7sPm26bDEUZcjqWFTQ82cVjdlRzuU1dV1UPcYcjUPqg/fHqTPv7qQz1eRKgjVY1/f8pxltA eymZXKjEODWKbxBCNyITLvHTKjAXLSZ6Rna1As2STrNK8jkcgpQ35rWTbAs1m3KArI/d9PXn oND8yJR9XG7sqW4cMH1vIqDyZ+Mbc1OwZWFEHgEfIMYndWZjB0wPVJFMoO5G1Mfogh8yRjVv VAOpwKHNn8MGZV3rAHDRvMUP3yNJKl6gf7tgLAnzzfZLODQTcv3eSo0Rd4ivcG23HhakNMcr MEUJ8OBrX2V0HYvR9X4EuqCjMegkYXs/wURWRFS06ypTBNS+rH8q9pcD7E4mtXOLAx/F8ESw MQPkXeX/kqWk1r31dbzvWrMuam47q+svxtKIRdFZ9XJHYDSkce0POYSQwVOvfEP9JyfuUWDs e8u98pmJb/Es6EQ8lYVOa/qxSNkkYl2Lwut5fMQhYKubVuJZZLCiOzP+uws/ZHaoawWyfsUH 3TFyHHj5Jc4oUdmx3AWNSBN0a+Ty4zXRAwYTHW0QW3ks9wrTGOvq6t/D5Vg4uL08lLhrpztq pfGEIqOOPZp9HOICwaGnAemixoyIlWN1jaB59rdtKuVOgapn28NLkDgT0Qcsn4iMWbqnQMq5 dVm+WSsCVmexaMpjVjq/T+PjLoTa5ox6knGFjKVxJtt7WxwXXqY5FDDS1oZM0uY2/RUfX6ie 4tXVaFiYjhSRJos1A2w22oPw3C8OmX15INjeuBa01OmKgUzW4JLD/RuHLO046CQ9O54s/XRJ lxS0ygRrl+xXgQCvOimYh9S9GCG/ATEGXLVU58kf3WONNWqx5kF4u5vwWYiH8aZiqcLhG57W 00iOzSgjIZvLtG0ee6WZEhUvKQspTLyx6RWERKMvSbZyR6J8cW6HuGN5ssjfXdHpCKzwNnXk EHcAjzDTYa3pEOli25i0zkknRsXPOWu2tzIILjBFhjZ3Lr5W+FUqN2wxrKNJfuI1vNmcpS92 y8qOB7kYTd3piEcjuBjAaTMdcRfnMrdMyK4gGgJ9aDE6VNz1LeCF1DrFxfT/xgWaS4YKkPMZ 3NmW9rl5gMyg7r0dSbFg2BSIKFOLSi95OjPvSq/3tzDjTcC1FB+AAqGi1AZdAFa8oVtzSM/Y ZG/kHH7jU468RQCoxdLOQO7pr0MgwqI+qEGiupagk1ZLyLCECK8Nvi+BiaoP1+EvSYss6Xxr CwRvXjfTWaBi0vrAZ26qE9P6gz7hM1UusUfkcdFngQ5/kaKc+iu/3qTFV7Kp9u5fOJ61nAqz GSRJIpsJ4ApVSk4GFIkEEpTpaxGE0O3aSYcRrXIy2ZV9l1qlbv84bKl1IMvsQsFX8gXhWReY 0NWKIkj8roeje0TXLdGAQUjF+fIFg0kzp65b8aOArFg8N69ivHWOESwSP2NGuSYW0gynuvlW +EqrlY9Bt5Y7LmgN+ZuokWOEdrzka/YhGkXhNJ9skrjgrs/Plz0rOHCMy70OyD2wknScAwfI X8W0HvmZDT7Sa10SvpXFF3KbOHj8cAuSGqBaqsw72nAjC3AaDhBTALl3i370cHsgWbxZAvt1 2yWh3uzOxzXo2TQo9FlNGWz/ff7zlXkRp02ufwKtPO458FcmR/lVB4/BrkhZfvYJFiiFwl2D EK56c00aq76NalLg3wk0kdhK/DIbj3Ja4AS27BnC890jcPga+DBGjbRGsaL/HtgTdZHtbvBc Szk7mGe3gwoWMOsU4hHqAgoMhX6S9s6AQEn6t/WPp7AIvtCu1DcmiL+PaDx40W5jsTYIC3Lr +oQwdGGskc5udKd7UGfG279Za8TDMGIWke31nmma32b3oxALFVvFlW3XdE+7cDle/zH2Uehu m2oEXvzZ+0G6c07YqjXewHk+cfl/Sw/mwIiGG/sG5bmyWS5fuVyrCvwYeUPmHLNA0IvgQi4A DO904uXz7uX246Wn+vZx3ITXnzKSRIdx6j4MSMDbYH9MQDmf+zrBzPzo/73wTuzbf6ocUNx0 aWIT+qycdArTqo6vCUApgTIutGhNgKTGcu1LM5+t4B/z357fUVJXwLtK25a0VYXHhGzUj6V1 Bd3QnGmJ9Fml0/J6aOpMq32okB1032M7x28G4QBbdFGmr6WKJxiHJaCvmElXwX7o9qAVPhEF k5OJglSPhDFvGuxKIcBzqaQBNpMvS73dVqWs3swZUBMYDSrYHrStL3ePmREiGofDdVpqxpen gMhIxsMdUJd2TLxtLgqyH003jt2jBK1j5qGr7G4BMcgMu+b/Q3Qbibo1KSYGiNVwszkACz8f 6ffPi351IimFLJyOugmoDwF90sH+6uyUP3GQmEem5mqDWIeFqIi3E7h/hNGrbRxcwh0sjrko L2PGhDvnyyZw/QhA1nidLW1LqFgrX9/LBfOrqEiWLyWo802fqZAonlvxjWUHZhSrAZT/pvv8 4/VaqWTGqCjwNuWYIAercyRawCvcxxryPgLI+nAPrsCZABhArqcuYNmMitU37yGNN77a9VtI Q42VKVEKpEp/DCxhJvVy2iwihD9BlOH1xW4qzfnjIFWDLuDuNdCF6dRaKD8ZmZbeqI2V8/Px EP4WU0RxC7m/1+6hHNljBQ8I2qEbQALtAcxp9I8U1wPCYS/q2vUmxiTPlCoLAd8vvtBKo1SY yXLrB7APiT4IuCqDn7PYB+xWcg4XB99qU68axVNA1eay+ggSFoM17BTyweeNv11dRmnS1UKD MhEL7iigoJqKrWDDhKZYgTxi+RWWL6Ar7DzMNkaVOlBLsatXiZZvihQRe/BUSGDu/p51heNm zw9HO9m6qMwbga7deMq27LnsU6dQdnypIeVb8r6oOJp1J/9A2FlMCmXvSvGZTPmcYbipXziu 6roVtKsS3tGNp+OjAcBYaPU0DxxafJ/+HbLgWtK7CZ9PZ4S03rjvjejJwGpMb9tsOzJUJxo8 jsIyZOrSA8RFnb9+qvHy0kqwsIB77cN4qvmvv5C3WOIoQCutJyGwFAwD3Ril53n2oFbYkz3/ PFlsviszzpu4VR7DJLk3O+zfQVkRG+plqjgECOi4UFS3crqlLxQn6+lk2Ht+XmtMTzS9qxVB c0QIPXDXs3XddvJT1sSbz4lpB/n+mNtu8+TaP8KjhKm5xFHUOmvdeKIX8dYQPuyj/nhM+4mS gQOfWwnVVjL1S8KgLauMKcs+dr7oPXE7NmYa24zdnL5Pb0ECGL/gt0+9qiw5zTQPJnIOPbin 3iNUfUL6ovFxVQBh1Hx1X2CJlBL7q0ysLBAvOcpflyfDPGLoTnNtNzmPZ3+Sgf+Dvx9ZELcf zsLzTBoNxjXYp2DN6y5Sbm1Z7aXC78IbBG161k0n7hisEwpMETbh2LzLfJcLTjTlrb2leDgs wxExt28SidAybVwB+tMfb3zbbcgAOAJDXu7twlUPlPGW+o2mqQdSXsy3+d4nJgHvpOGtdRPx NUw4wwystCisJwN0qKUQ+2mJHnVGeZcGiNpzhu8QAnS2eyRK+Q1aDecnLZQXxl2/D7Fq5qUj EPBEBgqdyqTbYkSu1V39U7A+IeIhnIr5IykiQVAjI3fF9C0XgYYYvLQjAxq5PkPBIgX/sLC6 F4hBYUhRjvSadYxo2aUef0cPba7NNa7rbbVu6o1JqQ+T/x6tHGrH+UwyeOR21mTSivGCgsCA U8RJMKrCv8xEnF2Dws1jn8uAvsxbFsPzQQL53JzBCyL/zLRr073xGjMcAVAXqtp5FvISmP0y jIYOhVsNxLlGeyQVFot/QyTrjchoAwLX+E1RDHz/5sv4xuqwExKfRvVNV87TBQSS6NhlvaEO 3JtiJlmA66Rs7nmqwhuoPIzixZQ5dOnIi2egBqWxfXO+8uj5TD/V+D8jeSj4Yx9AC7QDYzqL urXK7P9L/eKM0sd/YgLOxParYBzEzGgVW6EioWJkudiYoEkeqRQUkNosc0rQ9LJE+TpEzqtp RGLkwz5L81mrPUolyD5N9/TWNyjK+VYQaSisjPrOO3EIy9I4L/UEa+mAPKrISbcn4EZV5DDK zMs7Rb3i6wSHzjM6O/qRvLa9wQ/i8MZtkXKbdN0XsXQkldCJTYH6NPbQ65k/7KWBlyiO2fgT B/6vvqBxMD4SmipnMmU0n/FnKEkDlyq4Dn4xO4UN7BIEc+QQMkV1Aqb0hPwgB8SZTt4DSw2L cSEiSXSf4rlcerlDRgHEVqynjgVrsH+uTMMty7IEIngcwuXY7kwFoPUMmX77QsBpSFWCi5Qg 2iKKdEIOMQpVNh0Z7/MZ4EOaKcbgYPOZ5VPLJI3FvlZRJyihUyhXW7LHMzOLUbe+QvPW9UDU CvuoY1kiZxX3PLPnSTuvMNwCijbpVSzm1bZ2mIFIJOjiOd5DntsK+bTNk/ykzRz2CJlRkuPA AnIsxuCgRQPPPlTESQpeFqGrTsugflVD+TfWfgk3xGtUiRBU0yevwdthl7ux+tl7qmrF3hAo rM35k9VLijtPu4VKTaNyqahH/4N9bFL40DQi4QrWj42+woZlQWLguItC4AvV3FBeCqJOinWN ykhzT96G2EGTeDk7U5iRYuNWPHM61bxhXvwpUHdjSlaaRfAV57z/lKTlqkKZ1Dl5b6qCrXQa KGU6xCSdqBnozLO4OfuWeRXgc8TVe1i9ZUR7070S/jKL2TckoELRzRfN7zWzw6fSny1d5fLK YrdJso79MB6m9zEfPmlFUur+c8IyTIRLyS6tEOlncOYlwwOJxjV1ZN9t6b5srrtK8wUwO5qR YenGyffO6gJ03FuMIKFUqTCH1AAfmo6XmtrccEhxixvTK1qtfmPQywlsjt5+U8Uka1CPa7OL cvmkxmctkFGSHwwCmJHjat3kbnTeu4+FRAgzMGYm7fIQKCe2+Ajd0LqnoET8Gi+ZWUADOUCu DFkDIoLNFZNhy3DDHEyknfL0Yrw5L+t8iuRr+lqDJ9wVrXg8LDdAVrdJeSenc3TG5tBv+00p fxUHo36xvSV/2GMAFmP5OkEJz4+SHyM3Vb9DlpYpjyV3eoPs1pdSStiW5tT+B/cHJmh4xrgT J405FFvLItV+59uTcH2XXyC0DguSTKFgf1SsD1k9PCOopSc+UiSWuuIc85dRYTWaQBquE9Ci rQfHdQ4ETFO+NoAgp3pqeGphrfzLNa9F6JLz49DjI/lA40F4KN6sXHpXftasCUYQqJ7heMIV 8h9+3W6mldE0Ihrzs4XpPIh/EyPWFKXZgOdyRme2DpUiEg3tK+FsaL+JL/M4T4GZG3u34TFu ng0ej+gfA7fp1dxJyI1gdKt3PHf0gX/oeD5ANplhPTmF1jjYG6XXMd2VAAv/5D5r/mAJReQf c+mc0AluL2ACZSOnAiDnXecb4F7gXLFU1oohtGWr+YjZm9osuT+K7Lt+umtxfhHB36scytih ZWJG1QS8ZsvAJVs7xsgp4i9XuPAcA/5j8uAt8yeRhAS719IokRGaUy5MawInYyDmK5EEL/SK ld+pG6cyXm9vDp+oN68B1nv6nyPERjAWIuR8vAQtIyfxVh1jrmU9R87D2IXdnOwiTPmuHaNN xaGAt1TP/7qZuf8QAmZe4rGOJimQx8UvPdZ0l75mpEBRpwdPryQwOdsqijoFmG4f+KvrdRdn ywTk1iyS5kiwNHLGbR4R/UIX9Ag+o0dCgtnmabhD2S7aJwq7JCQY5nx8V0lgMeqAAZMSfUdl 4DrGNOVuf5LQ+TxVto8TFoGDFz2nTFJdO2LhdVaZcjpWaAgle9unQYAXcI+qsgQVuxy0K/Bu eXEpS3m0NedoZ3S/nlkRrplHzgVfS6kEBALasYvifLqPnNUogyNTGEOdFnXumqQ3bZbG0GRp Biit5yLvg8RrVo7sftnTUrbHu0fxAaGdXotLLSdMzzVe/P/aBJfawU6hNDLurUAgJUIl7alT DyfWAugbr9fWMqtn74UwSnmvROwZMzNmePtyJd2wUk3FJ+U07ndx9NSTCqCczfMCGrNNtJ/K ZHU3WeH1Ooj5gXPKqMPJflJVe0S3cY1kD8+6/TK0bzEOiSg/SpLRJRZ2gGCc5a48M+6jb3B9 cQCsYl++4UlKMSY4g2tWvI0aCgOoucM6QlsIg0fN/O0WZfki5Dj5ZENYK0lHwMsdSwD4UYfE q9PZv8Wk3nMRgAp6/ebgVOWq2E+lIZlohk+DTdDYXXJBa15XGQH1Jvgil64JyYxViFHaTKtQ uMgNZiORPlUzuMm782nn5XW965nbjHhcq8ajzSLva5Z+hJqqrCErFH7aHTPcYcTb/EeChUCX QfshzAwi6PXJHFs4AGiaw1uqtRAq8LyFr22FNQ8plXwmt1wTBmVCxTgDI3GhvFA9yFHMyckC P6h8ljqDBeh2SDRg+A1BRWVPCN7+X9kMV/JOGEEFsQmn+V/cHhluf2TMAdBwE27CWoR4AI8A 5sK78rs4fQnj4UpQMEKBGDvcWMcmeTSirAxFhxN1bGYyJXmbnh2wpoaXqQaMRKvO3YuP1JrT ITRaSOktnjgUUfHnWJCtBIjiyYp2k1zDFSSeo0jGQU1wg7q0z8ZVNInZLSr4IdCzLCMq7W4f OFh6dA1pOdgJ5Cwh0Pkzt1uwl5P3a69tK8wR5VWQzrcLqxoWXccEe+WphIMfrRc2ObcecZFO VyqyqnVpaCoebp4tn9gZO6mDyizb2/JAvm4nqqwzZG6GUpQPWg0Z7J/b/Z8SG10i8jLj3QDf 4U+pADcJR2JfqtJQ2AR9UbAJJpOQvDWbQBnTZ6TfGW2fK5RuQiqvqQNWWgtYB+sP6cBjQTVz ZXVhfs07HGiNe3sPlrQEg9un382BUbZr1qqZFxOGRA/5YxCYEprAfkIPkUvz970ojWL9TpAX t+JNfAS5AK/9E63+pY94Vj8KEclxpgkI5uVJMRA287+h7OwyIol5fNB5MGu/L+Qmlnmous8A Eh/jwWj2pNvWxXScLQTlGx8CEM+ehNUTXIBo4KCxz4xYv8LH1NwpGeaXbd/Ux/aXTzo/TLcr 48odDMQlKAxcTk/N3ijeJmsDChaLrqpCx/2JyCCXbwx54FK9zHInHITUJPknFo6Dq+rJmYPO V7W80Uiz1DEViz0ZLswbUOqV9NwTX5IV7L7DDKPG87Anz2kxxHbiLiGSFyJ1ZZ32TsdJb2SG FuRGmaY3onfaFN+8+YGM/XWhXzTXzbDRoeQkWEGBQuZ8HRHfeVIHtCr673OjWbxICiT7p1b/ jRMkVKYxEVGkHU/ciglqMwLhYaKWnUQLapuMkmBXoRLv0Cw4eLJH4KSIcc8bYNK4w8ZVnNwk a8XK3hkf22oxuwG9iF7VRwNbPmm2FYJxMktLHj8iiW9fClOk51n7tgFLGsIXRoOH77Nbhluq TwCXONKaoqoqQUJs7XQF9OJXWP5CyvDQaAWDjnGZSvImLoeRV0azBApAdIgMXQKB65G0DGVG CYCOUQdfY98Yxn3oCRKMPUB1IEwoE6Zk/jOdrdM1j/QVykSxfiZehX8lnVgbebqDnj6EZoXj Pa8LsdjpSNc6UzrcQquGwAm5cEUsSgZ7VxrixWiTyJAjMrnr73oE+SgzobUyFg66qPBUPZiq wpivGsOs1oDFATxgbFq6RGHNPN5pGdlfvBSK6OWTBfFRvPu0nMYA5fpJtO1OGBioQEguR0LB CbEhV0tJq8ZsBJd5JjC4U9RWUmjep6epfCnV7BwSegGe0Rbe2JBrRM8H7TrIo8nTOjXMvLty kLnk07wnLNvSSJo9GkyhLDoCsO9Y8cIGIYnHP/Qfn0UMCWCRgHHwO+WF1jzO5XLxcFpMV1y7 LnXhPVsV6ZmBA7m2mZLqNuBYjlpnH9wfi9UKIXd/4+Whliwxk8qHwdbF8WWw/js8lKqZchpv JeepWk9TbLI6bhGfOjggEi669X0eb6i9dOGkFrLnlGVKgGjHbIiK9gSmAN/LE9wkg6y6uKfa dBU7FmV0clS4h6VgcZJXN6UXX/0EDNqwCAHI/zw+ZYWW3V7AVnBXMoEzMyuTohNDtU5JyqQO B6A7THFR6HCuZskMsFbHEqGca2aRS0rZoR69MyXdTSQZByDsJIOx2kdA4zHIwA+4Qmd+ZiSU Er5Ac8wcgaQLlQDLh1G/JErFq/jRRBQgzI/eZznIScijQmpiE8aZlw7ROF/AZndR31HyMCc6 KhbXqq6g0jlvIA+j7+E10eLyfV3wbgDbFzXFOHfidltunmplx0wp7UZqPn0MYEArVsWGqmuF lMw5Y3GwBi9nMIp5Z+hNrthwkFaJ9fHV3KjGAU7g1nR36SjRwAqbPswFcIfr8boV8/5aOlnR b+6ZGUbAdEZ0rdEjKNRW9wq4Q0+tATbg3jJXGXWuVQTjsNVNP7B2AwLyVmixtsai2ZHPbr4C OU8g+8sFw/3obTQSQSHfEG9e7vCHtTOmMgXnoIf7gM+fvnzqpaWmfZSvnSXaWsRgM7XqSbRu rWb94fysaOKN3EQt9Dqi7BKGgDX5Q1fwSo1ZBzPjJDPyrldLNxizSZF7g2cycR4nh0impSzn az373DTmtjiAFpJxP7iZsfLM51TBkIApQJt16ZOWxkzQOftgR1krnvCsCztTodpxW87RFiVA 8DO4SsvBZvTAvR5/gN0zq6LzPAD9y5Qkc1hixz1s8/qn35lNnNYXCU3zHO/lQ/jerew9YAGA oUK8NwZTq0y6AGd1ankxJagDILCY/hu3li16XLZuN49f4wBOGBc3FZsirhu4/QIaSQMuSLZu WGOtl7mM6idNFLTRnoNHltUxtDkykVyuKFDOBdL+fkJW2vf9u/qCNlQb788mAxpjVNctjahc J13U/RNaqYGdcfYQbxLn3ygdYNySNtlcaZHfPiq2JbCsUAtrlClN3upvG0oH155tXuTAIxHh 9e6WSBMbFevDStGpmD/16MRe2v5BdypUSoRACNlYH5d8v/uWQFfVStbDzeIU2EXxuAtC+aWb s0N9tcIESd2+2ry1Ruph+5w0s6Ib8zmGwZoP6VVk6/GSZkkpc0pt80LmzF3BmqnQCc2LHZht WkHU6IFiPsu++cvOkHg8YGa7fBshH5IDMF8N9VmN4OoIj3Il+jskj6E9a4j8jSIr3MYkGYY/ yohJ+OiXxZsDoni6iDjVxaDMZnVkxymCkIwlyqOrRyLFHF95ZYJVVlbAq35roUv7Say0w5Is L5dS8MFsDBTKsoO4O+0/mmVsoEDOm+v/t27xF1Qu8J9e3im5cHeirNsCtoaLbjHV2N4I8DVV qssWeJT0jbbwX2ndNpUv+6vczeV7NmOqLtjBGCvgBkPbsXzmXd7+ev7ckltDMf5b9nlR7rxQ 2vbWKmiw9ETizVnnkmMt5OgGLYZhyTQSdI3r01KEWaLGlTn4r1IYkToFexWC6J2djYOpjMlN 6sR01PPK7f7JKxJ20jXHKhDCbySMrVDYY9NqHcUIVhodeKy+qUIveJXZVinWoHu5Kq65GYVi xj0amJx/EUKCIBgvDc20RofFcIxcPrCgGLGL2GsIsM9+apG/NSSxfXpJ/va92uRIz2h8ugW1 NiMQ6m5+d+hDdldi2G3LcwwxlBDxLbBMEVXd3S4qe4s+CWn58GXEyNEwmccQk7LPLoBvyP/0 ix4qQG7VgrZUphf5hwKTWoWKuyiVrXzvYBrIVmxwac/gRPVSsxRQExUUY/PxrrWYIK5pRhic lx3aXa5+W0icead72yMD7OITjiIBdjpEOoowkAyKU/TS9mIYbUwcXoOUAqQdzCqz+gDidJo0 M4UyMZciWNPr3H5F3VLbSyAQh4WK0GWKAcMjm2F5IJw4W6gTpFGrVnL06qFfMK/RsDVcoItu SrZbASDHpVO4vttbNYahd6NOIIVhbGvSS4nuzgIWIkk+g4GyEZ2LPwpNsTmR5nxDrRv2XVwz I8/YJbwMh6aFYfgyXmNvzSxiMafbmrEpBK4/XfavAfbYDMjE+CyFxR7NbcisHgWn/GRNjKOD w8gY0zvNzEDF3iNpD3daFvEJt7HKwmQe9K5QDqFcYDAS2pX7Q5UdWMSwvu99hV7re1Bviz6T J8uUQLUh7j+oaQP7qiPVSrfQaNWFX72Le81CKQkAmDQzOphR1Rk5MTgWkHAhtjd4Fhd7aw2E PcpMic14Z4niFNj9ACZkclxC+szIOOo9JPYesYesxLFXumSCQFUDwUwtuaaxldxFitZUjuzZ mbQsf7XLwkkhcpiHi6YkKxlPmZ534j9Zy9Ysh8xol6YxrTcseQK1cRhYxy44QY6P3eoBQk7X YR1Wsll/AkEPvIjqPOT0YsYgpnX8DWie0vCoAgNC3RmZTyYahhnH3DxVgP8uwDcu7TT3RQ9/ CjXf6FHVuA6+MXBpQqR0gQZ9Rb5cHuKNoQTnjKf+8s96MVeRhXg/OqSq11qaGt81YvaAs0pD zBQUn7BbArRQP0uQ3dNh1HcD1cwLGq8KKI9CjXYshHNfd7WolWG/f279zn42fMwt0t6sWmml EbduMDAne1hFu6OEKMyi6mZGIE5PhB88/z2jmxGq3gU3rque7OXP+WRhG7AN4SyRVXxFQAB5 atFTUNPEeh8fyuYDOjb4NVuR2NjN7hJr8vSAefzeDeM/zHas2IkRAFBXFT2obUJjgBOHNPr7 QbpEmRvOxLcONJ8ZWexxE0ojKpsNtlZRkt/PA+M1QK6xDWWVbk/5kF8KnQ9EvRV+7QXEpmXv c5Nt3NyXhYUbqZT37DfdCECLSKB3qBN2g6/MJw9W53l/b3ntUsPSHWkyWQiao1vjj0oI3mp7 /OLSEpDfaM1hHhAwlNr1PHH7tvSXn+slFiSAFksABoOjla2QPHG5pSIYkjIhB+sAEKZ+jJWo 3e9SpoGm1F4iz4d5UDOrWdf08Da6G3YCkt/1E/s44FYFs0S8HmXknPXwLckx2XyaMLTuH1Jg HhCDqNA3e07UsznbO0lV4bC3oWwtEWcrRxkfm3emAAFegQ3Q7OUXp5pai7YzISZCyyGlt3Fh jiA0J2WZsY8LHeZZLSRJG7m8WVBef2ZCCKKFI1fZZ8T4WSNEN8x1H8EL6bOeXu9fYtl0bxnr PRSZJ8wydFj0bvGeSD+qBJtMv90qVMkMfny+pSr+IwtZjGh0kl0OyLimteKed1gEoNbhT/3b cUNXYdJMLSqX8GjbCvuV1lENPDYhTY8a19SyCh3xEog3MqiuSJLLb6a44FFYGpAd3QriAWj/ 54kFKR9JYz5RoiVpcYzCNpRGdvAOzmFS+Z1taR553Wyq5vC0sg/xiPEUG8mRUB0CcamUjkJy QKpAM1sGl/tQa+BeIBO63qCXRmFkhe20l0Uo1gAeRMQcADsFuQY6jv4zh3OBBPZiRTCr6piE a5eXcQoBusOffMPXZ6yMUQz02kkKRDRa1cF8Jb3n1d0A9N/yOJjqGMMPc+Nzw7wRm3zvoL7d SDsEnLRUvmFohRA4hk5LMwdN/CK+ETMm57Lvun90/1AuDV0QWBVlaludtj6ayPMG+g588lKo UjMieBpnbKRBofSnNQzOG949UEetWonSQ1+H+xWTTvC24eS3eOROyhyKc9E3Vv1nbZUEr7hg UKpBgza+9s99CISWTh+lywyMfWAGTs8HOBDuPCwlzobY0BemjC5F/h2cPcGlpOhoYnaofk52 II1DbU4FXd9JUNmkAhBE+MHlKHM2B+advbiusYgdIxJAKT09+B0ZyaXCBFcQYmP5u1SPoYxr Z9oRKuKtpveiIkH8zc6nhFGy4DQDlbl/RMNHtY+BYv4SK/+RhljYLxg3oInRO1QrB/VM3EV6 WUDw25BN4mTND99k1/wBHxncC0vY4Fjt6oOFWXn9FAfGSl0RUYSNedqMVUCW9yc0qY7il7DY B0llvhAZnN7kyMjQSIqFrzfMXh+WUNDyDAdMFPerO4Raz3QV81LYKCBunzirXCzJpiIkTMk7 biA+KpAwe7Ye07lGS/rVKFeHNSygh4St4lw+PiupYLBA+JQq0tbTMcqAyOMghLcWSxDXXiBh 5WBmHN+x5W2Kzq9ONT1l6LwYreMjY3IKA2Grxk+m8x7rnuHPf8CeVHfsqgfk/BhZLPrrrGd5 J/D9/dlycNOmggxOP8BI0sChaqewzsA7BS4YolQQ/r+JAVTAjK/hJh9JaCriWH4hxhliw/sv OwPYL+CH703Zrn8XJbax/+/iFfbu//SJpcF3el9VNGxkQuPbshXc/IguWsHtFo+jRnGY8K7C IYlMscgeHvn459MFG7vkN8r1G6IzOu5AaOMQ06ck1smP5R3us5ZN79LXB2L42K0Qi33Fyh8W 1DyRuVoZXoe1RjfaNmVvm3Gnx56FqoPMUZm7Mu5YIb1FeMIHWl1D/uRC5s1KcLcmRojvrHC2 9TrHQjcGB5Xx5nvryLrsAeYe7f6mCMgnrblluwpCyOY9q2L9uPDynKcumokELtmF/gJk3LfG DkgusYsvkd9M7Hxi0e3aGcMJyGmR2nAAJv0fKDKJpbqr89lAIOnzd53sJMqueq4SwFga1iIM IsiIjmi+GvPOQ30UDfyNJyp+YY1gEyLDQdNxW0l70uUFB+zg7CzCiHzLwmDu/BHlu61PFAZM SwTBbBl/5oLECFVKpGYH7csxHOPsH696GTaM4xp7twJb95fI5/qRETNo7pVTWdP/Q9wWDoXq NBDk5kY3YZX6BuMxplJOZawhOHfotgSyH6U+CMcdi1mMaQvA16QJ0ps9NfsQNSX/sycm0ElE ufzJrGBaC2cHDsI4spiJ61QMcCDJTL/wHY6zxWRDPbjs+mI7GK7khfteFadly1ln6uW8etLr Dd/b+um5GAOVe7rM6C4p77oUEPD6GXgB6ebSrqqj/20gluLeoap6S69iZJ6nuWt1P07lGwZp zBfREfRJeyV7iznHaNPIhiV8zUCQgevfKkjdHTtM9j0xWSuJ5IOxLbxrGVs1GtgwLOHvVM52 NWvjiwbuOPUTXEWED6ODeeNTIgJBjudBzl8thHg23wy0HFav3lrG+gBM2TuDawhkhz3th8NW PvcYv1ClIcaFRjyHMTwvumaI9v/VvN2unTeoQ/yp70/LsLhTe2oik5biYqCJC3E3KzLsUIrR qwd5dpnsQe9G3/zknOwhwWNKeQU1/uvG2W0cKmTqxLqxpASXOg301OPEAdc9iWPLsMEM3+pM aZFmglIUip9GBeBRy/dCITH9xtVOVOmaC+z/AU7NlXG6DP2xD1avE5N9mzCkI1YhmMuQZfUt bGfv1uptx83jmVzjPVmPcw46i/vOpeENWFNhhWHXaTb6u6GozLZZGgqCXjvKcez3K0uaQVr+ 4YG3I4Q8hQIOOm3FEwooaforC81lV6t+1Hbajtm8CeDnn62o0PePg6fAfIk02E5T03X7BYgi 0Nr+bQhglES/v3hHG2Rt5WQU3fTQVNfZWcT+yPIqRUbMR2XnG4p+vS1ncC9J28lq+H/w0oVm +EokJu9cgvIvc8A7rvxEg2TYb4yKPEmuL8XhIR1QTzH47yXe6QL3+tmQIFLz4RFnybRiOqwz dpTBQ8rkDut51AQ+ybxRMVLIiPy+MZ7xqFZgzrNqt0heF22JMAnc5dAC5/z52wXk9QtFgalA Hk8NzhYp8frDQZNjbXk4dBC1f9QY3PfOmzXtoVinDUBYNbXCuWd3sSqCV/5MY51wFF4yuuzR x4FMdIJn/QJMTIOBGLx/K/VV4OZxslBWKAqehjX3MkFZEJLWyfKp+AMSrcDeC76kecCxoB+Z DD03R8MN1qQUWCjRge12g7eFQz/fNLNFCbnOvRrHCE/30sXq9lQO3yxA1BDkSCY20/uXKllm N0yIa3I4VsSBvwBXwntfq2DN0fM6Yn4nrJ9fH1bCsDBJxzVV0zrcW7iF4wnfzXKotzYt+dq9 y+K+ir7nGG73iQwNJ1zhl8zrpmzDEpZLqrqMOYcU9urlc0XmenLjsEvPCcLVNCwW4pJ5rpTx bbi923Jm/LXQ2g6rgdj4VLf1B96gqLV5WdjmCNmT0jBvim1zXJOpsnpvs6W9xUUvlmsbW1/V yp02xiXIqPRaojYe0OL3ykvhRTzzJjY/A4DFyGSi/CWp3Yst1n5ENG3ynNNqdYDWKc5ktk/e xJ7wATt6Yb2KWV4xkJudmWmyZwxl62y6QQ0ubqyULVjcErka4GuStbaCJ5/q9vUZUWAnv5Kr E+0bjqwdTntEIjqKesgYAIZGeP0wtUCFbLyBQew+EiMRFNVU75q2XjtwCGBT4T+CGnV41DYe EvYgKfkPELDhlrR4Mc4XlpNvS7HmThau6Bfi0pEZQsr+YKORxP2CKqQIYvY6vyxKfU20vjFP vTi4caOuDRVUcBIoxdJFAADVwLEfUd2ETwAOVy+A1btAT5YHwJwQubkpDEUlkb3M7DgEU3fu sa9u7u8v5tSBRzbidYakEVsMBXO2W0H8CmMwT4vA5zSPiiX0Oy92HSQuA8Aqh4XreyulV7oG Qt/5klxhwOkp4NgxaTv8AyXZdj13exOQPLE3x2ymBaNRY/yREaw2FnIHW8YpVXvDkEHRXoKk uMQTrsd4dc2eANXhm4LQNoTAAce/RfCijVJaTN/VK54VGdaohlfQ+fxS3dLPZxsqSONWWtNG 02LpIE9a/beOccwj/cqvIySp7SkTLMdI4XqWxQe4gOlEzdlNle5qU/6dTTfbu31URmu66c32 5KHr0L9HI7l4eZ0hX8saM9i8wuQzsLY+PTCnLwFC0BHO5OWRqahGftxFGUAMutgP1bpeeZ/7 1MBSYGrKprej9NFxuxbCwilzebOOFO0Cb+yGkKw+kstFBhYTlh/JXimfHC2gXck9hKQVijLK eKNbi8+xQzF6nyR4oq8GiEyC2QaYzWxrTDugIbr0SrHxxyjQJOujcsULlYWjv3rq7l94xn2H b4+z7ignEtraVAZlrdHBtKB51HBbRfPyI77eM1SBnpN53yC/dOP/6CRT+vPRfwqlvyHp1Y5H pIAcxgji3htjsJQpa8TVdgaom5MpYrzFKnA5agysiCvto2Gq2aaAk0P/qkR8/mLNcJWdAXId 1Y9MviSGt00VereYhbc1fk0hk6mGRUkq6pmzjyu1Yjli41E0tsZQFlePlecET3KFiVv0RIhF CTTCKQDpS3Rgcia617y7AgVHsgT//CnPHeFzze53kyRJTZd0LF6C/tz7c54qr9kYxFnIZ3je dddHuIkL1r/MzY9nW/ah4ErkmZbFUbXl06I8btL270XmLALUCJHorW3XOKVYGtJ9kuF2ydXg LPdm8jZg1tf1msfZ6QzVWKAIgPgt83HTIsoemiscslDSbd0VrbK2xSrYxRmXU2chNZOnKWs6 2nR9cstLw1rXlyiq2c+mSZXjvKvGNeqaVyHAGI1+ytBCf1fwJCpyJH2v6dNSf4V8sHp0fB5K /PEztSEeTY7tJoPm+wViaITEQc98eBhurWSDMM8oE6yb1pQTez00Yrtprd6tRS68Knof+bl1 ZijjkV7oGoaNT835ckdb3k8HoEZPlQEfddnLzKTYDa5WLgEch9aRRMz5qGhucKJk4jxK5pSi xIYGzcRkPZJRkfZvmCjacpFh+eTsWboUPB1twxd0VZYCMMvmCznyV/dormjAwfuJ0OsspNHN b3nlw2OGNrmlWfZz03scjxYdpiNJbVYhR9fzzrybeJSbFluxCGyRDvQ/Xo0YJlSS6AUWsq5d tt4s2biLJDPzqdxH8kq/deXOKGdAqsecK7lOiQihlQie278043c0saF071EVgZEwpp0Pcml9 RMVoYTqiUEu/AA8vEypL6SYYIuLwxkVLzaopwTwgW8bqOFgcuQs6SyO+CL1IaEq/+FKPbVmg cKqzKcb+2TTw+SRLEBgQm0GxIKk0sGBLJBA51EAyfJrrwQdJ59NrELmAMZHIgDoCJfOdn4VU 1ZRS9Z5lXa9DTuzC0BM4WZkB4R+Gv4KcxD+U7rzjqWoKgerQ+CyDKq2r3jAynd020LZSUdXt rRZFUaHcld/HQ98SWuDOBVTjs2XDxWHI4QTKmM0mNdDirVFSAvYaO+I/TexmjRDHVbpu6r2G 4YSJcFKV9UpMIreN1FoMGgA27KHH1R6bfcGa3+he4mPSXzBhSCb2j4J9kQXVwzODPVL8JP+k kgrXzxR1odXjZ48zcR8b95rcApTFXHVmsxVPI8VMCZMoQxPvQXChbzD6LyEbUB32kIAqTfme Umbjt7sv8YcJOf1EEw/POAAJa024rWGXYxLEJkxfZybA/DJr6j9FQy74paUJ/4vKViOUcbdP bSuYKwC7b4bUHEULZbXORCrqIO9kZOpmU9mdsX8T0zVZUryIlJXs8FzMAD76Zgk2PUAQXKg1 hv6ziNme0sJ49fJuV07MuK6ldHpLDvaG10ncIO4SXu1eOSNMYmS+5GLv1A7rwTlp80LqJfJq D1HLzYWHsObOfLeQJsA8NkfyilSAtT7iEhryVt6s7Z+4yepo6H1xcNJYFd0jFb0oZgS5wldZ jVJDatQK9WOK51iuAwNN+jNjFDYWVbaj3JI1TmpYMdfyFcTIJ7Ff362RYjsB0Q0O/E9kb3LO z+EwdEjOCOnIxVRutfTDUJJU6ZCblBUUl55Sq/pOBSZKPOeRtxiDjYJfHnwIJuQLKaKxSkif gRDqh7yeaXfWf5lxF9VAEtfjjmKY0FFKmLMgC1tBdL6dHjY6Q4cq0Jn/uwQqqCdDqciixVkj hTrATxgyxD+1WO6KvyQBv+HEPecuYOzZldvLtexMJ5ogsOXt18muCXo3rcIDQjrHNDLijoMH vdwPzmgx3zP4IXDIpmJrNctsJFb/NIU7RIKXTtj301bjdFjnTio3vcMdjvZkBJCOfgjUU8fg 5ErDABA49CGzWtnaA6UGC82Svpd5GvdDSt0ltgNGE3DOm21EgQ9FjzvlWreQp99xP6qO7wki q5xlZhy2fDR+5CW50DK/se1Zqsb5Cs4MMluoEnrQOBh2s3YTI9YUpdmA52c4wubQ0XNmq+Fq CRy6FY9QhxMeNZ3krtqSfmB/+PDfEQkszvAzggLKFtlqdvJVcXP8oBcWkx93AcMsFrTXbgwO /PKgrPT5SfkIswkR9Scbt57A91DO0RL+OjBPAD1RrD3/++ukcZU8wqecotQ5ZKlndW2InDQq XSz3xDydZzm5m6ZwogtSlH5dlLWbnsrAAmO32SN73OSvgE/q6Rv13g/XGZnIY/5AuGPMC8+a c6kAHnoQ2/8ScL1fbOEz3W8p0ULrr16Yr3Cf5cwm82YJWDnCt3oi6iuQF10tiVOFfh4XknRF YZ2tvnOiAYWgKKNkByvcepOonmeNYvyx/H7BVZZj7DR1eb0jBGhaPCxEI9N3RNwxUTt+ETWg nuWF9wGZlpyYP7ncRRdrtyHYYGBK+TiPyj/pPAit/Q5NEa4+Cp/TQx/3PCcqQ1T0hAimfYPj xGxr9Yfc9V+mw3vQWJyChdHqbYu/5NFRLJ/xqWQMf11tyvIhdMI/T51vQK+4afLcBw9Sb/cz 6ZMBg5dGvG5cNASXFv7lgFn3LdXZTRZf/owkNyqHREVAuGvxAc4Nbo2wjryTsu3FJSe+D30A gCnrOV0D372yoHYKRvxRjAiakalgXBiM8vuFoUWLWLSNrERITcz9WD7F48jz6UHqoYPfTuT1 UuBoXJpKhx6Cj2XIsVOnIsBooH95FTt32Glf9AB1f30aSJ1gEaEl+bta42hdxpfleVqEmYvG rQdsoD77N4hvU4REp0KJQO0BBFOwIHRGuMnoukk97bs8qo5ndsA6K494V8nD9PF3XYXd2Mqk 1nc5uCDclfqcn1EA3EvyPrDcaW2mggZ9cfYV1s1a0cj4EU8dIoVDpo66nvR4otf5vYDLWt7L jvxYWp7bhebQ/mxXTzXMBXn4/KB4LFAV5WQuFSiDSb4N9oCROJXwYqTBk5Sfn7J3UO+xUsv4 B9jGshQIoXcymO48jwi4cCX35syQE8a4LdebHh3D4aVx8Xz8LjMXqLCsCxJZRtFuvys40WDC Wfl4p3qQ1/8G9NkJpcDKHDmavZTHz98Q5bRxNIbkxpm9YDbm7Cu/N39qM0GeoK7lU+CGgYMa rKa7Wck/qVeut1yuYhkp2CYKZpbuFC0cXpblx5Dbs9Z5x/ceJFU2xICudnttbNof4knVjt4H xf2+4h6etfmIyAAjLRivQKI5TZAE5kioacbbq0R3m/bDhhGguwhqyeKnqWW645Zs8VT8qSmY 8tgCiplsYoWKLeFF0mjOWmGN8KhL1/qHBUfo0B7TYyBMdioCszmYnYpSGp9Hfwcfa3SUNrfr fZuT7F+JvfXT7noCA/6dKmWTDkTk0dQZ12k0/kUi+8e7G8LyH55smOM4P4ecsIpaK9DNA70U EnLxM3MZb71L/rWkrq3E7ICWHkezCvWY7IXe7WZ7JrlCRfDaLwn58tSmQog1n0FZlMz+rf3j uuYA+6iAoY2UO/BTNCY3fmOYPByC84dksccEadTw1jqlF1ricO/Rm8airlXGBNbox7Zphh/b VTYn4vNz0GbAULJ2YyXL02EHxItIixxwHROSWZWz39fL8bS3anyRLbRswWgqHGnnxrUSdOG6 4r9owcs6zfULubow3zhh/Ap4NSRp5s+2kfNZG1n5q/W+/xAvLr80ZIrXc1ywfoFsBUshgpmt DUKOwXFGd6OyaHzYgAogjfQLKgLFM9lLXZuyHzvbL01+AxjDRqEWkx6b2SgATnIN1itJERd+ XlbLS1UkLQspfuB+7DcjfRqgsHqw35QITuq3qVw/V4tvSkcA0+paLGT34Vp8RW03O6j8aMuG oMhr7rPxl9Pl4366qTA/cotpm/BTJjWcd503kLfXuQiXc52GDBVAMEPOR4J/8Gpk2+MsxNbH bV3Q/5wUSfrjOdtZR8ZMrGzWBgW9aKz6qUydKi/pTY3Kd3kowjG6FsSSp1c53O8sYTfY1YYB DYtnZXQS7Gswdn31ORAR27eHFTc1bZauINiEIiUUwdmSZZxtPlszwlR9Pu9XPblQfnt9lBLF xrTEBKYvZXtpei02C4d+uFLzp9gd2QCJ25Mf5AVaS82m5lKTTGR5D0HkktLUlw02ds0a1rvJ yZ6CBSv9i8qVzZHCODZCZThRM7mEdMF2cCjOu4Oj94/XAZ58nP1yCl0lSBmCpAXnZ7dJihsb XmXS590vN1CmdQpbUblnPoKtB41EUwROKe70hC7J4K3vo2cZc1qSgcMmXYbyE9aaOce1DuA5 fni4x8LZ8rAuSeSvUJtuaGY2ZWnTUOmpoCXR0HTCu3X4gpSUdFWUm9E8Ib+J9cBeeTJ1qYfE sFGZUQQQsCvoe1DbXV7rBxkMLRU3w9QZWMGo2o5p6VY4E4jitXtA3u1Xplf8fQskxR2VzJxV Y1YTz8rM1MqDuwV0ARAnV8nHTewyYJbB7d3fxuXOJd71Htao2GXy2NGv6szQ6xd+1PxVjk7j fqy1XcU1ScwIKPht8uxpdatkiSvdcrjRm47DITShGeQyf4tLoCcwoxCRe+cTFRwapf7O3hWb MOk+YyWG9zirPwB5V6jaaO3kXXyH72Y1sojLn1YRPt1v7hWh7tnN+PD3RStn4F+oX6VGN3Xw Bpjc10QSx+XrKkX6Q2I+2Iog9DJwriBX4K4WyGDyuwBPaNmp6RVPiwBOrfefvrh93baQO2q1 F+ddFIh2fsbvLmSSu+AgIdOjH5ylyvMRRLDwIYr4UJ8m0SRLYE80uRh2tIiwAXQThLlKHSWw QpmLasMxoiZGV95dg4Eb17aloCJ+4TDXBN2g8A8kT0L0mcCIJOeCaRTr2tvn21QARtecyl7l 16g7WmHb3rhWG7cJcMLK4z0E9WRti1rZWAI/HEWAorzxfcIO5u22QCsb0SS9VNsC9EBR+0yh UBCp4p+W4FOIPVgVastmJwZ73oOcAQrOfGG6jBNTJEhRCSss27lH0+RVD5SBrEIF7sFdvev6 W4WpP0tVNdNkRAmEMDXcObDqRelUJ7tj0fucgZkSG6utmpMJdG9oCiQH5O4CAbYrCV1w926t KhWIQgN/kk/Mgsxec8WhXxWK5iA9O277ROEh84R3fVYk/Qtoy/4sLNdmAcMoNqZh1K0T1sUJ Fuxot83sH7vOCfiS616GEedqXiTNMh+Squ094JEPYx8btv66aD0PbSxg/sffYtg27MrUuGsy XMZMt6x18gOxJItjZfqKar6ee53xZqiaYppjTdVoDzp2tEispWlsEdk+PM59EtOSGbjAr+Sx zQ5hMse9g34E0AuGCJyGmtuLioMn6tmjuJW39YmuPxsFhRVWHDHi4rcxZKT70ylcseS3CcdL 222aAo3sSwyl7kM7sm+5X61ENnLc+fPWV7EioRFkrlLeAoaykBYZZZbF2pmgSH7Sf6FkHCTK dzt8lqcyNk4vIue177457eco5v7CU0NXTB5f2D6IcsHHwN1Dp2O6Bsk4vMWtnyW3BzTrp5+h J51IsIzdwv7xNcfu0hU9tJ5ss0QwGpI2k2frVJjo7JY6YBq2V6T6RbgaXU9sHlfG3CQe17Rc cXtS5UW/PXEu/iwWJc35prbAzPjVMtqZkOT0c9N1W9tldAf5zkyTewDPfJKtpsC+WWh+HxD1 yRcfxw/pc5YUGJGYKwq11zJBeQWOKu+kGqlFqtofdUrKtjLk42wABzOS40lN+uN7H9Six1Tb CgWdKUT2ImOlGm8bLX1afEpu4I2G/no651CE7zjZOmM3RRo+1MXq97y6mzBkyKu4uN7YF4xd xHbjhTotGZdrEDRD9aZ6L6b2sk1PVV1tcBOPFf8WsoQ3geSAcgwrh4HmNT+8NDXAmNXH/KnS ijNHQYCqsq7xS+LJdkX6tvKjXwoxXip8ynWUYw2Kpc5sduZo03tf50njUvzAci6+Fdy6NtBL A5BFB9VZ5YO5Bol0A4CmVHQ2ce8Qv+9nVSAG5ttWsE0iFkxIp6hWPOquASmt6KMqFaNdITrb Qc5jsMWBYuMXq37wtvSjfuqhIp+5q8p7gDS+GOyqMk0f0K5knp73qXl4e9eM+o83M2WdmRw6 HYi8mELQPttTLVCI65b/JBv0YoS35XBBaUkj8ARCZBrcDWXeu4XkMbBKsYSJ7wnL/zjCukkn hmsva74/KX2s6HACYFzx4INpjA8SMeSb/5gU1DCp4QXPr+nFFZAti0VteXDggpLWqwISAE6K OOt4Ld3Wybn18ks4udjeQ6y+xXs9LC8i5ifPHgD4UDWaDozILelx8GTz69vNk+5BrLp6IWcV bfrdU0CnrXk6xuYq9k6wc5bc6fDVWCKdBiew+7JoI4mJtpsKaTBBSMQkReFOaTEA+TSCaDj7 Fi34OBbK/NHve7UDkKOaw750uqeu+yQzTtf+FpqR2iSuVZVwM3G1D67nAZkQXSLU1pjKEgtc V8E/zJOMW1SgJ1ZzrUR408MMPHJfYNjw9fG0Hc4bvK3vHTApD7ArDSi7wUpFNEE/oRcGeUHb OT4fs0+zajkEwtF/HPvZd9q3qcy7XwMtfBrlZNnG7kkSIRR0UxnC17ovJvkXqUUjVbmHAP2x seZbAXAWOPmDREQsUkvlFWtuNdT7mknikU8ZNDM0oQK+cu6DCiFtLuIOqhtatgWnXoXF0eig 2Qf9mZMBWEKHrf0zi188kBX1wn6T8nesoh04dDsNar8Niv7P3EC2rQg5xd59WBc4lLnofvrm c9C9wWScc9oh2gWcgspsEakPtNLCwiBmLqDNiwIYXFm6o2J4KRoJ3oFbpq72lnsHrK4uGpUH kkhXY98TXcgit3ZF4Ub8wxQjyQvcVxbU4S4RIJmV7csF01QfMZwdv8hN02h7/l26dEOjv5pd czRu5FJ5jzmgQg7tEmMvApr5D8pjAYaFNYQcDWcYX5Pm+NtogRlBaLGrEfKiOCFqZMlYj1nt AVmjCYd58luHMa16gKdkyoYow7dj5ppD26dsDa8l44FXPXMVM3bkdNPiYDIbvavdnAYUFyIJ SPh9ICZhWUYczTr+AHLx9kv2d6NzmIwdXMG1nWpN12PxSVQ/SU69YraErs/ctIxQZ965w6Bd fT5wP7B69Tt4hf6e+ExLObtSXbpcKV6SJO9pHQED34uNrxzp4gKe9j0Z00rirwcUTsSGtUeE we3C8AE8FssX0eylRph0JOfpzF1JN9EZvNhVha6pSEbTPzV531d6vQ1PE3ff+w444PwriQBX nTEzXki7iYIsEmWaOanIhyip3Fz8CiuFclyayDYvXD8PuwhInk9XFYiQqMhpkS54PN3auK+L BcV3CwiYQUdcboRcUwc2nFUS27QBvcWZpBbJQG5njT2dCqvoTphEZ9qQx27/qLh9fGrbRfPq 5WlQCKX8ajkvEMvMUOblDDPkXPxgHERo74uSDcxCDmnQKjU4X8Fn4Z4xSNS6a9HAtc1Nm1Bu lwKJGglQWNRupQbQwuapt1Chjq5DgbPjXS2dznHhDNG3lxJ4YQoPyf1MSoAe73l/1RDeBM14 Ttap8TexW8VodTiQLKtG0uH3QgIRCSgNe5rRooTQjlgpSh3vPFRBlm3us1yhVy23f0aYAEmv fScFJBcP0zZ6X6nF8jy9nN/HzIQtYt8ZpoUdtvgRU+TCK5WjzUAmpFgnYRPoF2L/W4dS9d0P hkvmmPe62id5yTT/L1URieN/h4k2kGcHrtcJLmYUYDneFhDub5JCx0/kENaBtb0s6iwFzred k5AtUVUegSicU1iHWrSzjvwSnVb6UXZUWn742Evj5/8alfUl6MzMKR8YkAVnp6APy94GKw2W 8mVQZZGytFiqHwrdyChppywo3HiAkiaYiWUmKdinZNArSfqdB9axDPP6SjwGQpp0mtp8Xq83 olamllMOZK+86siPInwtOubasxuTVlUfaiPzY1kJy/OZwWiWJaAFB4dE7Cl4SDXSNz8oWHkr To/df8T67Qkx5ImQIuypohByusmGNZm//Kad7aD/4J73ukCr7zAxCoM0ubgwLzhllClXct0K L1/Kn6Zp48xSbskj7lM9fuMaHOKRZbpHMFwFId1CvmaRPWrNFPy9ktAEfnpQcHu7EuD5SQCm yNqqrpqfaLQ5Lj6wz/D+BdHW8F/xMJE0sUjk3XNQViF6M+G3n2auY03i7y+MgkFwYMNZ7NeG 035dnkuLL5nHPamBkdZ+B/kwM7gMMdwprZoQgIwdz8n/ro6XryFp5PCscaaRhjj8wpwcZRbn zVBB9XcDO1FG6A3pY2sMc3AbVFLChf260naOF7w3f5sFHAk3522sLupyJBkRkCJY8e8xQs3K w8q8aPmMbCLn5zsQuyS+W5O0MFv7inHh1VN7EInf9FAm+4Da3fBc2OZYSALAKxjX8AqZ9Ory vnaTKFSyOcao3DiaedulJllXt4CdN3RmqoxkCND6x3fD4I04Qud+mQ4NdzXJ1PJs3df6vSSf 4kcS8OIVnsyYo+BMUITwRlzeCL1CIjHwy564UiFwgQObNzViwo+k+SGDoj86xitmuSzrstC4 KrTPatWM1mwqFWl/CJNzydtdNuxtvtNEYOYP3Ij+yf89Y4midlUKvYecdI19HdB2fcY8CjKp gzbNW0H9mjgjCwTYT8oksFH165FxQIgLi6QMo6MPUv42H93qiZ1VR9jYeQawaxfSbPvThcIr DYjOqDR+MRd6GquL8rJ26fPfm14QwEXdyKNIQn7lsZpqRZZhnMqxFFIzKHTT2cL2zQ3nH34U udpJC4Rf5X8+LgmsbhH7lhJMwsLZYJDsY4S+7eQ9CqalM9AXK7ClSrudx8Dl59zHFuIRJ8yE LakbGs+wRmUnLMVa/Q3MAYBelDxi6MXRsBgr9MlEh094paG1yPW6QmmXCGQIFP8PZdp7b1Vn tYr4ebvyn2xC/8P6R6d5SitWwXmgWJJROHGjRXbMmkGJacXghe3etC3QR0YSIRTFL4yAM6Ci iiksmDPXX6NpLOs8QdndQFnsV3BOoGM4qajdQFL9odoh1BAFQWyBpWMGmwOAlESq1jU11LZ8 /TAloThl6ML8rbM+RQhK5i2/gG94iQGPTE8foCYpA8CkUkzfHJTDiTcvLTmjgdirwy1f5xAs 5gwpd14Cy7Fiy8amNn/OeGAGvNgxx4iG5fPrNAYv8DHOuGAJoDiUzppaip57JkuGsHMG8HFY 2yaI8FIxJhaFt/gDGCOvz+WrMguj1YifvM9UpbsPaShVtBvvAZd/mcJ/eWH4rvNf+pZo4hBC cIn3XK8+yx/OA1TR2iSaWJ+GZA7Y2l/0KMd7G6s2/yxpmgxdNe/xVQ2KOQQ5/3xgowe250VN kLRtaOZx4zfQC4TScQoeHn7lOBbxo5/c5GpYHxI4m+K2ZhQjettgBIbvibgWtQo97eK3+YRo p+d64oar7uVs4Xiqe5BVi/8aKJ9z1mmDGlVNJtCSWjP5EqWbx+eTxM2IAeB5zAy5sFtCnlAt q91yX1yx5/n3zgrs4thu/inP6/F/AyiQ1yhz+/FGQoK/OzVBcvFhaGsBtdTXwR2WoA9E4Wtx 0C+p3Wfslgyn1rT+cRin+W9bsr3f8+3GZW913EjIpGcAwUk5JBJOKaGF3LlwEJl1FYcug9jU 9UNxK2pGHTe5Xm4m0y7cUhlCG0vbrtN80UKQMr5h1eHYP18kefoy75uy81PmMoviugKC9MAF 7MlVjW2hoJhU+5ebk+auhfBitDHb0CCTWXAeFhxtCjvgd65eai0oH2VYHNQvhYNO3WhsjqfK PXn4vfp2KMAOQi6+3MZtVdrVDLZ5Mqmp+sW4/f8Ngp6N5PYfOc5bwXDdzfdsq1kkB/FNB5jO KN6U3M4oo6F84aKTl5b3EGEkKMl7ZhQ+KyqOelZ24hcpbXSn0pOApM+PBfpnIiCgCYa0Xha9 P1WU7l1mJMZQC3WFWR3W2TJFzsIB6R7PrDMwH4AulZlrfGr8yG6igKckLpHBECzhp8Qw4BBv PusMqc0ZOHoesBhldsoXNXqJ36a8RG49q5ZXkrKsA4svNl3LkBPR7SsPd/WsH1i/lh8pPPiv 2yqHYmWiBIJdKsAuqSGfS6vuhoJyvK/5gcN2o6PoMAdotTJHLB5TX8rCW+W9B9ZH1UQY5K1V lKXbwYvDZ1U9IcjnXuycdDBtt9tVq9QmFKom93AAOwA/sOPVfX5ngrVSOBWLU2v91Q6Kr2sc 565K8s5R4v6xNpEC++ZHQOnNzsqk6Y0VVoaue0MpW7Tw9TI24rvvk0pL6SOIE0uaqH1dNumB r7D6DYXIhD7X+BLo0JOz4XULnovMbUKknhEVpXMH6JhOBHdWKoHR7bOgEenLHFLtXEEeVOxv HL1ekFy/lF9GMW8izlr2jrIcW9N3BuDfiZS7MEYxvr3dWu9UBfNi9WLkakf8oCi9fVCzMtww HjXT/to88k+dvdtthsNxnA1pDA0NK4DL/QqacB5WMY5PN0FzBfFyLxFpDxb2Pv+HqCcnV468 pOqi+JVwmrNLjfFbzUjFz+8Soj/3JQiQHKdng2roDI9yLWQpO5tH7m/lO8wfPkIxaFRsrMH+ cahH4lvavfKh+xAzDYW3uGkWYN/XU/nGN47cbA3/sng5UfR48wNkzHpUcsvxg+k3I+LnWuy1 kmhp8ht29uecWMTGDXba3s5gHtK/Jh3FBVWouzKlq7pXzl57iZZphivj3mOCfQFXntzn22QG 5fPDaLdn7H+QT01j8+nfS3Tj/C9zjEckdkfYgq0bqRUWnmHEdwKr7NiZXQla/dzxehoJIvSU B5647Hfa06sz5vHtCdHS122lAH9RGSnVqPSR9l9/QVd2cmvXdiA9hH81S7fAA8zG+NupKZmY V5vdFbzcvc5ukBwt92c4tjwtnHV4tkSrkEWSMrFQQucOlrysW1KiWxfNQeJ3NFODSPLyOUJV +DC+9GTEDJHGk5WUT58JG1O7//EiSwHmsCaIYYzAFYfMOdKYLjLxKEaTDmu94sVzbWVneKxL L7b6hAQZj6MjAKApmuforvXI7ykH4WUXom95An3oOV8jc+gGugjSHD7EpW8rrgEIW0RK8RNT 6TV1sb236sjsiyza9y5DJ9pb0ZTw0vRirts7vjA0YZ2saE6yZTYQkroOCyl8pXkNz5kn7gZO jx6m/hI1CL+x94Rxo00YEzwhqUSS0kf1giI8gMsuChdbzOERNOAr2CrE+VXUuFqB8JR1qNTM HWqDcetZHkFK1F6j4msk+/hj3VQZ0Og7QgMwpBwk8svpyTliTcoaObHyS1Nt7aTyRfu41Rq5 wShy/HoJBS+bTPt2KBakXwFq/gzUsU0oJoJCIZUNEv3K1N7OKmSavKc55Zl4UWC3RjC4e6Yd BaXkAGNAdBOVd9qFw2baUP33PGZJeKMAy0kHON6Gu9G2zkW75ACvbIIB3Gr10b3XvgodjkDf T0+NmhhKsXoHltw6oSEnW7JfZc4JCHAMPp7QUPqsIrH3LtKndwFSt6SODarMMfsysrRrtFWs EjDJbRMDffsNz34tUti7smPQKljnV966gz7tvi8XD3msNZbWR/1PyCAgY95aLbXgQWfL3vUA rhSQyMZxQTN6kcScZxOSr0dMj4MjLolq5cqpE6hK8Za3UtcPP4k5kX9d9Ys8foDLtCKj/lD0 1Zw7kKsegjscQcssrB7a0HbVWzdHnV2CZ5I88rbFWDVqD8mowvJEZNb9WXLtrUBrwG1ClTP9 mBcchvHdZ/Md9u4ys8QBfDBbyyDcd8djGOBLG3vOnOmyQ1mKhSM2cucbU0z3Jmo6FXO3bAjn ZenbVIBjy1E5X+Jy/LdodPRp+4NGGBWGsTQIk94+uzD0hQkrR/LSdIe7Qh688Meh77xvtSWD XAV5E+kyy3vdPqEMs9ptZiuJyIGgMwUnLzFtm2Zzcsbj42PtSRCzS2/pufR5dEr/q6wGmmy1 B3xh6Gv/HbaChapPlwlb08wFGOqian2CyN1zHF71jA1pvuAVJJEIuD3eewqKV9Aaz/zt3Ykr Chlg+pAfXXuGKz10ZMR4DIIjdJx+ExxSnP2vvlL9L+SjZju4dNFV+uHZiJlBIaxppxd+MQHn uL5z0vpeGgTQyRKGDYMwlxww9V7bFciylM3WOMtONFpsJybwzg4q40CB08Jgn9BBhAxzpmBb rf6jvVw+ykSaJemS7GdwB63w6sIVms+47fKKxgbUyw267G0s6op4MjstNPJJu0nOjbbatEXb aesfC8Qmr2bDF4mu37VxK3hDcJYVXt/wEHMk6pMMEQz9GBCkUQhw0pFFi6TBY3hv/KWL+Afs ocTTh5casQi+Yg2CCdx8VNnT5i+hCUYVOw3BZsZddrE1/0qu6ctH+hzRGAV/SnNwLedse2vl f0PM002UXzcbrkc83KzUmfmSxvbs9FHWE477MAaVJ13FCSIFUdlgvJQoe0HphTsn4lMqWx0t evUb2EOHTvnNVhfsg2QpGbU/JFaHdnYTLzZ4z4gLA9Dcto+KmQ+rfmtINxDH6bdRDeVW48Rk 9R5dZJwNe06A2eLYxa7/l7U5e/PUNU/34Biuies5X6sPE0+PaDdcqzJPPM54d6IoDJcUMVyv 3iXrETmyax42T0Qa8Psk6by+6Mwhmt6nIHXRxwsylKrkl3ahLuvxFFMvelAf4fePqzYIyTmr NVSiBESs4wJj9di9sKmP2u1uFP1OQLfjJkKGyrEcJ4Zt+FbH/crNR96UujEvbdXhfqtF1rqV Cey3wCbydHgyoIqZIbD9S6WMCHXbVqSGRErvLOpG23xL4CaojO4w+gBTRQgsKQG2s74jQzpv 1N15NOf7FLx8Irp8oDmmxKFCgldYULewGRYfLRRjOPYlBWyoiZlLzhEx8RQO+yCdgkRgyEM6 ncKZnFvp7EZz8AThILx0qvufr4e/yytEOb61OV29DpbMbyxK5BGn4tgaoRPj8BuNH+hfRIx4 5Hm2cOuxAdIK0cWTLRo8CkX4Mvtv5IjMuR4RW5zu44TKnzrp3AGpMERTexQE5ymvDXu5pvNe Tn2N0ABwuc3f0MWlcx/9QdoH5j8nsX4ERA5cDOErWH7Q7TeVBl9PvZASF2DrMFp5W8wawg0w xfFcCBCBsIzDFrMt2p969Y6B7ea5DuJnJSjyLNDR8FNEa62S7xP+ouR7R1iKJEtraKak189e IPZppofjgxg0cpTiON5cUHYY1It6rCQAHdwrSOuxzmXQStiOr5bS6nnnxebsaJy1huZ/UsVE hkHi6HxS1cjZihtCEln4oZGOyj3EI0R9NKdnoiM22LRysn/zNCfxlNF98GHEC8auT4L+wzQ/ ypx748PKxBR3ypNSrln9d9tTUaqfXOgAe//VSXW/d8Kfo87Rfky4dX/JtyNRhB7nJs4xDjTG pUre8wwq19pJ6DqG2PbQwB+r/v4UqwBgjyTR9JYujFRJfkIjKfDEfUKT06bMJCRCCAi04FqE UdiSJHJaoj3d5Nf9GFTlBdrTbYFs3wkPVt+h6ylwq4TOD3lSquYrBdIgIdk6Qw4oOM2VW0yC GLgagC8HkWVq/YObs/Q0w6NX8m/FoTjFTmwECAD4xxf+xVRrkJPrHIxAX28GNo4mQayhEPyV U9fwtJCnkn06Xy9JOY0DwbRW1b2MSlimpOax1ffllo7PU4yV8Uqys/+SIddt7ffEroPQAov7 rUFQiSfJyrpT5qwRakj6oxs0CCA/7gw4d1eZkKExPwXXjvlpNTzi1anL1ME+zm4ZDsYu5/xM N5n/T//jCJv4WveRju6jsSkLt1vENmF9xsbHPpGbKddUOl5t4nyRciK7hAV/wPtq0/2NLU2P 26wqeU/ozp489RkFoWM/xAtyW/qLQlTE00hW1SiNiIcNVjIOad6OeLX7tKqhuREpXG4hLTTk qLjm/7IPjFNpBVDXSjAtemq/GnpMVjgCRgRp4S/wWXDedwjBH0ELdFA0obhFltRbuy7Z8fe7 MNNMNeAMOIbaV9vNLSEm1rOY2wwFfjuwpHzjgQL35mtyCDn1lUjUUdz1r3pTrCRQt2c5KAPb g/ZTIqOZQWJ66rVLIkP7yXi9ZWXKHhBsBWjL0HmFVC5oWqNxd5GYO9qLMJ96QzUijm0o3K7J X3Y7HAoRJwvyauLQ55l7NSxY0wm23MBnSzLLzwh3/5WC5Wppgmf8vUMamZaZqg5l9aq0pPrH XjMPbOc4VhO3r0B0CTqF4holGJutUUO30OFDA9mHSb0t6od1aNvWE8L0yt/mLG0eggfYJDft 04jrF0yhf65Vbmy9Hx/6BjxN0shzXeahnqugctAx7aMD9/ZHGkAYsB+rYvIxiIUJJzget0wD PkHhjeW6yzNE+ARvmoCnnzlDxCoY/ISKn3wzZxTHjiJ/aqEAnNKXV1gi9UiTIpGVhFHSVB68 oYEcO2MI+OIzrPjj4vcc5LdTMC1J1izuHeAeDvinnagMv5SF7+opngzKqamZdD37bW0mVrka hBmYUUQTGyzqUmphMxTHreIfwznPQGx7veZ2SHkBAaJqEP3jIx1RiQ/6Uokf1+RbjtmUfqyk VIHwEqC9zxgnWUWkSLhFCeZ8b9Opo9SDhpppHa1Ie4QXymy4LCUmuAfeL7KaSZGUPu/eGgHc PHRWtqVRoAPJEfekM4lN8MD0LTeVeMNpSy1ZaNN17WiZWQLwrwayOgktVff66RvsilZ/Krmz x8wT/lDXWvYEnVILudqPZcRy08M5PlUdDWVuZHN0cmVhbQ1lbmRvYmoNNjkgMCBvYmoNPDwN L1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Bc2NlbnQgODMwDS9DYXBIZWlnaHQgNzU0DS9EZXNj ZW50IC0yNTYNL0ZsYWdzIDI5NDk2MA0vRm9udEJCb3ggWy0xNzEgLTI2NCAxNDQxIDEwNzEg XQ0vRm9udE5hbWUgL0Z1dHVyYS1Cb2xkDS9JdGFsaWNBbmdsZSAwDS9TdGVtViAxODINL0Zv bnRGaWxlIDc3IDAgUg0vWEhlaWdodCA1MTMNPj4NZW5kb2JqDTc3IDAgb2JqDTw8DS9MZW5n dGggMjYwMjQNL0xlbmd0aDEgNzE2DS9MZW5ndGgyIDI1MzA3DS9MZW5ndGgzIDANPj4Nc3Ry ZWFtDQolIUZvbnRUeXBlMS0xLjA6IEZ1dHVyYS1Cb2xkIDENMTMgZGljdCBiZWdpbg0vRm9u dE5hbWUgL0Z1dHVyYS1Cb2xkIGRlZiANL0ZvbnRUeXBlIDEgZGVmDS9Gb250QkJveCB7LTE3 MSAtMjY0IDE0NDEgMTA3MX0gcmVhZG9ubHkgZGVmDS9Gb250TWF0cml4IFswLjAwMSAwIDAg MC4wMDEgMCAwXSByZWFkb25seSBkZWYNL1BhaW50VHlwZSAwIGRlZg0vRm9udEluZm8gMTIg ZGljdCBkdXAgYmVnaW4NL3ZlcnNpb24gKDAwMS4wMDEpIHJlYWRvbmx5IGRlZg0vTm90aWNl IChDb3B5cmlnaHQgKGMpIDE5ODcgQWRvYmUgU3lzdGVtcyBJbmNvcnBvcmF0ZWQuIEFsbCBy aWdodHMgcmVzZXJ2ZWQuDUZ1dHVyYSBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIEZ1 bmRpY2lvbiBUaXBvZ3JhZmljYSBOZXVmdmlsbGUgUy4gQS4pIHJlYWRvbmx5IGRlZg0vRnVs bE5hbWUgKEZ1dHVyYSBCb2xkKSByZWFkb25seSBkZWYNL0ZhbWlseU5hbWUgKEZ1dHVyYSkg cmVhZG9ubHkgZGVmDS9JdGFsaWNBbmdsZSAwIGRlZg0vaXNGaXhlZFBpdGNoIGZhbHNlIGRl Zg0vVW5kZXJsaW5lUG9zaXRpb24gLTE1MCBkZWYNL1VuZGVybGluZVRoaWNrbmVzcyA3NSBk ZWYNL1dlaWdodCAoQm9sZCkgZGVmDS9CYXNlRm9udE5hbWUgKEZ1dHVyYS1Cb2xkKSBkZWYN ZW5kIGRlZg0vRW5jb2RpbmcgU3RhbmRhcmRFbmNvZGluZyBkZWYNY3VycmVudGRpY3QgZW5k DWN1cnJlbnRmaWxlIGVleGVjDY+QJeyENqC3pSXO6+M1he+0/MDBpaseXDL9d8FxEyBJAhzQ HvgzHzrn8wbWsK+spumNSgp63jBAC+Y2orfP1DjPSc4sDeF1WlqEt5SDIrULakX0DymSHxq+ tEanA+T02IvunhTsCd0zozVe+wBuc1L4AeSXoLFjEzIxn4nb0vE2hwuJTSO3dnOIK2pHFpmL 2oKCbfnMabM/GjuHd0IHjXnuE+8MpRLiOQS4c7jnEHfY75WPsSNVc8QeSmgre+3DQeqE3MuK PGb0FrMzT5FTW6huX80NxTXatb9UWgdyaanIL7XsDnhnWf07xe4twARWfJSmDU7qZKWnxrpD FppRWYbNUFKl+Ju+MUifHAYck6JzsKQzPpo2vL7wzus0H6dVqHa5BncxAJhrslcMPu7x866F KnuEvkAtNshG0AWLxIlgMo4j5OPGR69M8xqqSP+NSYOL5POkjwb9Vyp+zmrRVoo1CCP3jacY O6kVwVNgg7hsomZRxX8iyqMYRXg3To98Z4L96GB8dcp89K2bvjmE3C5jL8eOon84UXEl0Cd/ qdKs1WX/PMNc9AnedBPVZCsy2Ii+mwz2byBm3XdjT9A8a2pNXrk1sWyvWFKOKVKjLlH8bGe8 tBwr1uwEK8uS2ziWQONAdl0JYrQ/lThSgmHmh8BPHxqsWbiBLGTYUJkDioIlRL7RngnEXleT YYOcLlAA2JtBxytLY/njWrPvFyIQd3Ulb67Jo02xFkHG/LAQq/uwxqQo+UdhA9NbSMDVJpRa QJ5+qTqiTOWR59XYIKdlNb/0h0WWTifiNLt98nyodKMmeTbU5L0hyJyY3xgYg950oCXv7a8W SZqNwRGYrgfjKGuOrAQXeJieWfPM+ARYk3EFsihOZkiEb0tEZTeqHCbuROzupWS/9h/TdGr1 8ZWGboNz027wBxdzz1pSlFInz4MxqEmzHsv39bUadPvXw4kxCMNNmeO2vz3rrrrJRK7Jl7eP hwa2NhL4k5h18uBUQSHT+OkxB6Uc0pon5PS/PcLFB+SLXz3fsnJwafCI+2el2w1HlON/G9pU xnFQclFrLoQ5rmv5ovnpNzp0KgU97igmC3z7idyAaij8Oag/RhnI+Pu3b4CZpU+15bVVGOwL NwlAxO2MhA8cEDZyOXPPiST9uozr38FLkxRMULfEhrJ8LjQEXk7BeAIqAPgJWW+P5Ohztybq pctYHlNIpCvwjh7b1IcZg3zic4xVMsS9hIFOeR6mbYmtQvQn6MwSP9E8K7Aw4TOpCdHKxnBJ X5jgM620Qw5mBpsikcraNW8YE/6yAxPWa7dyc0LYPBZuDe6IXvlcM2CgzA/pbe91sHT/ALQ9 neqWrfNX3l1Xl/Ex8SaARDl58Ul2AFSX0yLw0lOEsNUtapq/fVf/o3iuLidfeTAX3ejv1nVw cCVYcSyDxHbt1VKBANfNtx+cMcSRrJ1GPFg5f3Ci9V0yKX30CmOgzdorevftD9WMMYxCEI/D DTtnFOQeC3vtRdSiQE9jcxyCuAYeBUbLm9p5UFTCOIrDa4Cp9qV9zioWx9XWQ0EJK8ydQvi9 /QpiWrhDzsXIA7hbrDFrQGDQNWwKFsMOHlphWRAvN7Ce21NQNvQyHiH4VJJAex+tlRFqGfyl PNB619lmJv/6Dl/zEjnI4PBmnDOuJo2iRvYso3JkQEK3BG8QLmLr+FVCzo+f2Dy7PdpgKHz+ 8gl3SOFDo674L927cO/snQvQwf9dbRjRQMBRzmQWeCtC3UocFp84GxycQbHKgFECFyq4GAb2 0UKQDz2S7/UxjfPMdQTWV9uStNbAm+1CveJW77Gzvlti+BPqQo7KuYXaxQ0aKjBF0d0ZfcW8 QJO+8k3S2wwmbLZRBnO5WgUPk60ZhwfWZNN5PP7hrubKviOAqISwjVrgbHS1wk1Od5ZJO4/n QGakz28tUBBn8LbZoDo4cfCPofyr5yfDvtJUMd12kME9GZFqe6ru5ZXOFnoL5i7tgOgGNFSO gEHFlwbR40HLvUcAps/aHkDjDkN+bgA/rNJyoH7/Y8SGevYZqySDy/osBEfoLICIOt71E0Q4 IcI8Okf5W99+JPJbrm0g9VZgfrzf0wJwc71cVhWZujg6Fa/9zseM3RQu8HmMRvSJiNmO2d2h fQFKjQ7s61zMl59hWq16/omk138dcNi3eyS4/N9kz7IgSuf5EHgyF12YsUGKKMZZjJTMwRqd 2KWBHgKtckCj5hlSbDWS6vZg8cvAHCSSnefxC/TAsq6KcSPyQWFaeG4LMej24yq7Ineh+Gu4 9ZboQpctGvhIeHnZ4rNNcNYh25TpwUTs7Tq8dPnerjBPaRFvTzBLUgeAgNrvg1/ovoOavzjf wWv7p+pz4euzCglYY4yFeK+d40ePN+t+5JXXoSxzVuqFeH8iN0wv89ips9ezhtDAPqGkoaiL +HzazZtmnatXfzcA+0qjNJAtVM/UNE2wfjvXoNkYPFxsTgF7z+K+LFw71jBg6syaD8Axrm2a NGoCX5A+H8d173GkPDMcQ+r4oSBzL/N4fJVutcHrrndG8sGRkD06CneJl8yoqIJuKgAxhNL1 WqI3Xbni/ePM7vFG864m8oVlNdxZdWprjNpcoapCzJAZC793M9+ef+O5sj7t00l4Vy5WyKzm 6oQitsYRcEgANGc5He34npoxvIbH4eq5kxVpO7BD0pWcmX5JXrnItCP6XWREye7p5lh6yqLS 5yjKeB5FSs3psjyiZWavWLgcVY8j8ODlfcrPbiuUOlXWQkxaBT2NbhQIKUExCDvGMIc8pbw6 67ewgZXCs2t5hlSEY0aEaerJ0ldb0lqTvKJAiYE7CJqra9R/MbN1wpNvHhBGzCgLD2wOMfLJ AiFiux8rrJBPmayX6adMg68TDWbkN5H1++yklG3+9/bCOFR2MEzF+o+JRZyJ7YZ2uKKKqKZr RPrAvABb3c9uxN95C3Bg0+E4Y8lnLiFYzDuWWwiLAle+vIS9haoemTBQtW39jtWeuZqMi83t AdMY6R0cfjjHT9CU2+fElas4+AiiP770Pp1MehdB+xe9rxgLuXdj2OtxKEVCkcoC5JrTSP/k Y2LTqhsOs95kvlUyf8ghi3/TkfW9eNU8r+DoT7pc6WMAvAsPabPLe6EaT/4VESkXhUSTT8xu crSRKsa17jL9Aw7+twi75cWm0bm2KclmPkSVwqUxrQp8jXGt0bNiArZfXbMv7cg51ktReh+h 709NeTltu8vlOcAFs8xFdKxtcwiZdwtiFdT2FTJlKfWPnm1qBKjpyne6X1cvPIllo8NV4aI2 E3I/s6yYry1VBNRN+0qdjcyCmD+aZK7Fj9n2blrfgW1/RF0/2CfExjmpG8VNKB6+IHc2qh1E c9eV0p+7q2/xWNR5ZGZiamgbhcnGke8avESLeDkAn+hTiuQuHzj/OtwIYWSClx8qimpLXZZU Qcuq4etGAWAOXJ070l9OPbPviyPZ0QTcCU92+Qcc2+XCCb7RZYya1Scnv1xTlHRJKlB20Qvr ukZ6gaKk+OGfdGsOQGs3T4VyxqR/dHy6p+ISWYFS8L3Ii4PcTWKyfoKTKBkgSzBx36IegNsA TLZ5x7tUvZDK7P08gWJ7jS6J0GzT6Ncag3IIoxqpXCls9NDYjBzNT2Gvjc4k11Jp/67FQumF 3fEgMKULqdC7y38BJQCJ+rNb3/jkIyI8KmHZ/YrwfKyt5hmvITYhA9drR7dTb9CWrQ9gYyHB HJcY3tqcnE5f6YSBdPT2hxmJYj1dRS9MJS+VrsVesMFV+V3nrZLk1cyY/bYjKdBYXSN630Zg d2XkWhfFAg4Am5efTpArFFnPZl/zM6fi6jdD6c3irE+JFyYZy2/jKgDvnSLrqBhVfp5p0W65 GVyQG/5MPu3DRYs4g5ByKbgOq2GwjZy1ZsgrkyRVF6mzCEGYi8BlRFq8T7yxCEfJTE7TTAFm X6w2xEKfi8qPClR9gkz1+NA13rMHECnu7ZsClC1Zt3svpn9Knss8N9hazL2G35MFFBsYIFQH g5ir2MptKIOxFGUhFcBIjiDLg/yanOMqVmZZq/ZrJo3HIex6VkLWd4KlbWyJrn3zeB/4hb3h eGfEzHRG8OORuQobLQaKws6lR9c1Xy7vTDnsEdFD2nLUhJqxZbdQsefCMv4E/kAv4ghp+slv r1jyVFbx2Z7k5veHMWNPM1MvhzUgkCp+eSCTTrFHsPYrJa/JrxYGGDS90HbZPaSHAdbev9vL GpW8On4jSdASzKqG1J6fQvVdFUcH5S6mpd1IbgMDSq7HkZAMTHs3PX/Wg5H7MPAICDtiCnpH 0OlBWGnsV4hvumHJeoMJaCTQpmLIH0D7hrPsJRnl4EiH2UN9iokR7joJ2dtI74AnNs6qsRvF zAnlOq8BMc507W3tMN0Z9UbHFFP5/uchjRWAzJ+pq8lFls2me34D77C0eiYpG72hmGS8vcNh Q/5EmXJWU21GKvsxjvXb0LvQ0Za3JjFfypCuJQw4CyxLpsvOAHVqVZhn1s7EN+FzcYH4cfzR 7gia4LP+RnKHmF98lwkl+sJkWUXlyWwFP0CaK7ZsrVc2Af2cyeu3J7QHouPmt071hJu1SV22 dGpxQWNUrXyure5ovdpOtG8ydkeLXPgz2BTIQqP804AtNrf72FrB5fnIOCM8D4LVniqSSigT kFgW3ZPQo7qVy3LsDWW9NMs+ed1E67NYGUTGEKZ1a3Ll7keAUm3LMGMHwhFpQ2SVMVDE/4Uf E95kKiZnAa8irEAaDgYliUy1F/UHnweQKV4p5nDUBTKD4QhmsA6ORzKDFkzULDKHA6iqEZsx b8/Rlw4iXqUtA3I3C8Oc/VloRLeKteCHkuw/W+Oeu6ISdw4YrvOZsx2FQaGo0sE66UXPW91b v6kxEGdq0qlDDynrqMz/ASg+xukRy2A8WEX0L4WqDhilOE0ieFgnq3mZvkopHzXe8D1vlNfD j9YLZ52XQ3QOo2Ma9POFwrnvlummgkAGu1ltmgnrO5V0JSzzevmH8aEIWT4js+n0IbRaPFHr Jl0lx5P4GMPqPd0zan+MTKSaygZA2hOfRYSdxawB9SLLrut5q6S1pB8nHWE41JHsu1+gK/uu mf7Jx3XFqH2XmZA8GkrGcanFX2TEs6yYIs8cOb4gl+6/EoMFr8M9wBnTmA5qSVOXzArSTEzY 5xHpiANhjLx1gqgTTXSjZlUUmSchyN/zI27dvR/VJzVJmb6YKicUlr+PWCoQced4PWf70hfb txibbdqw76W0AnuKYILsFmEt1U+2f9b+/L9K56YqF70By4PsbROtg0cpWPI8FJgHt0m51dDA 7+Ho9n0uIHH7lsuJNVIR/b5q9+T4ItxhbJ8nIycjMphzg21r0xZQThd4ZZrp6Fmi5b3yFhnE 1UFn41PPq1pN0KR3lo/NxiViftwl9SRVi9DNlYr7mJNwpw8Qwrw8vkdQUyNP3WjC7SMl+ZO4 1f6ctnVJA3qgmt5gBnM35fP7+6NY6H1OMcLwrEk26nsmTbaBtCSM4eBLKC9Ce2SWrNxXLyoH vvdfG4cdgCCA+9ge+aKYJ1NIPU7hfp80UtbvBFuuTaB+HomWZTNDuYax9rnitWOdCeHAah1G DhhKMY/cYVV55kpNYQzsLV+fq8K/W6F+yclAO6UZ3Au4z3d7bRl3imU6CnUDZqyv6RWqsQoy IZjB2rtjaTNEpfxJSaynCsGiYm5j5fhy4Atr7vfxZsqkmKrvHGrPFtiF88iYHBQuO17VGEyZ Y0eGiHiwRlL2S9WtR7FxChgwsB4Ysul0Gd8eZnC/ZfWwExqGlLgOzzep7gMJVe90PyHCvqXs FAAsKNPMFVquZUzDV78yW2IglgnLDUcwLDpVuCSD9agF+5cnQZiZl+db5wZmr3sH713KNQbw mmNuG8EgM1JPGadRM+BgqyIdLThINWDRpDUx5by2ISh/6DL3P/t2PsboL5tSTu9F7L5CTis5 fK6Fall/8ykDcCVIa+hLV2jNIvWhIeKxTJSSh+TPA9LnxroQnF2bfPIFFcI4e2Wo3An6d9lT zV3zd5H4R4jV91urlvkL5iFJI6+np8oW+BNeEtcTnNnXO+g9ewj1mGwvjNCoDSI+CyM34xUn hJl0jjhQNxST/UEdOtWP8/yNjtMvkw/4VDGnUaKpB3+0ZsY6C0ntq35eEG/z0+aYT0EBQtuo ne13cT50DZwnHbVkqTrLvrhuLFU5nnXy1H8n2vbebv3hjN4H4ycOmAwo9jiFMRElPGw+/F4i jzms3XOAoTurHXXvJZ8WR3Zpwta/+0tWbtvHqFKIvr0igSvkDqlztg3pBQoakdP6r96SDbQm TjH5ENXdDlM+2It4Up0ebc7JdBFiGV/7lNlSuk2lpypEq7/QIuwskSB/k7uibcoLicVPyssa MFmvAUGkRtRvgpu7arNX2tPPJwKDbrIU3KNRfqldk/hD/5fz/zb4Jfvr6nEplg4bkufy0Wty NLkNHAJqo2P2v2Ts7obMcQ/3xg2aiPZHDrk19r5768Bx+uliRTaE4RhifDw3uFQapXtDszC0 0pP+41AcDjq2/1TNE9zteC0KTsSHwI04zhRoFtzXGmHk0J/5qQ0jvw0uoCFDdRdfN8m/Sifp ZPnF3nhSK3MC+EPiRqDSI7oE4Bi5rly7ZZOl3PN7vvU4ws3ZJ+8yIGyp/DHT7EAr2oyneRmL vK7j/j3dfUtMXybLhHwYpZ9ph3veNgQmjmDxPoHc3t+Bb6VVe34jIGTzCOg8rf7brFWPOsTN MFtXYTandrM2LicM5spAY2qD2urDh3xINDYX8zJc9oGLOW2loo8mp4+a04gevhw8HJwgWjMs BVNfjgM/V7Fka83EAPnMZEtXMA9+BmJdP7AOTwAc2DxE0H/Sy2erb+28mm2qwWNOKZavdQZz AzFDKb9yhSp8ROcWJxcnew9aZjbid9eBRUMzN3q+6WIiAK5wgLmH7H/tC6vRDuCogxhs6uJg OcoW6SxYobOU13t6sgHHySL0bmL8PvVS7HBSeu/1oLeLPb64oNXYUIOsuaC3Pfb71rc5SBsp Mu0uzrXBM1wQmuqt/6xMVQdP9skQvZj4btVm2bAcUdzwXKR5xyKB/VyU/d0N683rkBixMxPm 27vkHHTlIzjd+VFvmyzkY8Pm76B6imoAFEFz3uVmOlKn/M2gEcJ0LdAHk6FOnYGRootAip2O XHhvx145UXiVN9VKrhlEwK23KBTrUz+pRpakbp1Wo02ZgmYHk9w1dFL+1dx4alhK9AgqVHUv 4Ei5AmslmghArmSzstkDShxcXMFqAXgN4mYkaykI6zjfrtWs/61m2s+zweq6nlAptsR3otve xSURi1QXTiTPyDq0vrXiHIBoS/NmyO08cH1fhDioRjv2YV1GL1GQRxffjuziIaVzcu44kCaX xwKp44g/hJJ0rbflBgUT8eH2v2WxoF4QU7czLJ/UnzUZVrJYGnCW1Iul7deCUPCFL5UUcGNf bKFbz9q5bQQAljhIwjQ0hxivcs+phQwne8vvUpIVW2g0Y31TLOOLeLNmDtkMQqDZWighC6Qh VPWUONjk4fb5GFqg8XsnvT5r+yM0k/nD3mvIPn9ihFtK7XNaQZvIg6Pt8XpPqa7X1vkBz7uH eOLAbLDR9kMIDqu9Pd0jIHr02r3vZTkZPfBLZkwWwrSZqfaDiKSCtsd6B6351bq4LMk8x8MF aT8oMMNMbiFOgmzEwTd3YbGXRG7zCj9Posxt3TiAAsDVr49zUnA7R1tpIXEMDoEUoj02I/92 CS9Ou2OkXj9D6gb5t+p4Az2cdm+9U0/KH0kFLKEjYRGEW5IFdu1dM2b9725JCAOh+vravmxk c+sbx5nWTTMkOBXMmsQBSlvo7BPVxn4aYT/UT9lzgK+FCyYtM0+Pjl3dyKf6EfE7WaXzglR1 PvsdmZ5FAirgQ1D7A34+8l9OsYedRNf9ZPGQf1aeVD6UvRPWXEXLP9rYYtEuWX5F/T3BMiMj A5pscpq68D24lCAUwevtdMrK6Qk2LdnzqcBPySS9yyJ16/5YwmN30E6+VHRFgqZADa0Hadml LLEd5F+lnhFpkZdMOAOjt7pdICDn4l19D/oOcHnn/4QhTL2emOzAP/6Y9MrQuXsTPodeVu2D 8oX0EwORPtS7xhUrSRoPkJxahmBkP86iwBuW8fRzEcxawOj6dC5080svZQN0jtcsaixuXQlo Jd8rg9fRDAGgVNowxr2ob1OI0lFJUNTwBsGyyUVXeOnhv9HFOXhyIGs+8dQYIOL8UsRvr32G wY9bS80emWBQCJ3agxruotRgDP6WyQJU9ZSMLd6xb8cRpV+B5LM164g3mSitSuseg4NpyA1f 5gROr9HZyo0C+DXq7WyiysVvVu77h0dCCamcG5GCdTQXXfg76Na7ZfJf8Fdp6MwgTSva7NU7 wzHWDwC9UJ/5LksbnSu8rU4Bvi93XU3oWIunTl6WAsZ5p6JEglX/Z5CHnO8mooz5cpFHLHId wn7bbg06jAj9vK24zvtYEs8m5TTj9bAXf89AFLAA+Fg2IitqOWsPmWjdSmo2Es8LF07dkFl6 fZyNbwkE8Q3qFuJ0hlw5OzThOtaeSZLFJthoHn7c75+PW4nsv+RpuBkmdsRtGkqKDfpmecm1 PX21tNWR1ETp4K9K9EBzoDh12wZsvktLUBfz3Ti6ajk7RMdR35Hm0ZEcYFD0ugBp/T+XyCDY j1iYqqSv3Bx5YxLh21KuE2irSaQXSX1S0zxwCzmyiGFxFrkBknzyBRXCOHtl3+EWr6C51a4I BeqC/Cj+O+3O7sEd8ezeCj//BzMndX1tYjosWGAofkh299zVHEk7ACG1pbA7DZMX7jYrMe+P 2xF7k/+ZNzhFZKYo5/Lau/MR2RoK5l/sNAkK/0XDsR5QLLU9MqQ3zPUCLjvmzf5QplNFn7H4 jJvEfN75mUcIbsxewsToyzJKhhSNSew9kqOXCPgUiJWS/vLx0SfISwLxG41HNfLHoG7c0lJQ EMhk+Xhx05TS82i3k4n2TNH0yMV3Z7UHPOsG5o2Ua+WsfWYYX496hQZZL/9O7MhJk9eWgn8n XbFRF6w7hu2bzuGkBbSpbo2iQMh+XCvewxozs+xq7lMmJHCcOIKvbfpOUYpj478krWroOVgl aHD9QBDL3oIDz8pLF0xZ/F0cus6G6DIoU++WZhAmnSoGZVerlD0ucaEpz9jLZVjTeYEhWS2z IXksr7RyjU2uDxaZqSCZ/qQ78mwMnccMhAS3BO73d3Fuox+KhPfzU0h0gJcL+tgJZ6JcoJRM ivkIqrelnxpfdRHZCSMTi8Y4UaFJmIembNF0aNiKqYuLMxBr0YRgttNF4ONTUSAsSoZrvmHp HFFskGR51hqiK3qSUh+TqlFmVZMx7FJm7k9v8ORdpv1ihdw1zqBMnk4dgkjubDA6SoXidOXa iNl/l+IIvuwt31JQjdqlqytrhhFRDiuNbY5pGnirFJqE8ZeQJIVU/Mto5+LtRRWFq8giZw79 ThPZ0PuMOmliQTl9CU8QAayVD4F9BC7Xtf1lWlP1ZeSHM5BC4N3HdW5KTXe+60tunBY4sbK3 qMUcehty7SN59r+Hn1ynKxlyi/N1xI6rAcTkQE2+3aCOrfjTxWznDcn3E3iPTIv4BoT8WSlE /iBgYSMD5tT+8VBwgWlqSR1KU3BGpAUf+SLZduwUN2oP3XNi4ZASWXzlthkZa10J6hD84EC6 AH8TOR+7BCR8uZbc7EEs6MGJFbR6InrQ6qw2P+/JsyfkbDUikA2RDshrEAxm2I3oWlNqVYBd msOUjFCWVSXycF6JYSbdReSE+LVrBMU31JGCZYaidLN319QL6cjohSsewk8xdUw4ASGIHqOc 8lLriGykr+BUQPWkXAVHyWMwCqUYjLGH5x8uXgV4iYRJrDVeZLSja4AnL0gD/XEB1tGpPbTd bOJbsUYGtyYOkXCgBRPO2ZXBux3QudtskvfZU1SCAT5OAkONgBABrM7ET+p5UmmBNR/ztLjZ vVt54x/Ei8D3D2ErTobvlLW1btEBF5mJsApL0t58xJOI0fKoxVH2qNkSIgRw6JEDlYxbfQgN N6BOUqDPbf8ERDVNpMUkb5aqOYXm9UtSRzKRz24JaN2bYj/Pp5YrI1PqqVbc4nGv/Zg2pf7l wcY9DZvVfY+U279mjWpGPpZAmxLzDyr+Z8b0mAOHMD0194PR8WR5cswgQIA0MLOI6ZwzLS/P hjIrdP3kl3WhU7rpuY2WJkEn6AAiClhuFvHVcCPgvlDg/WZ+/NjOvOnMB34M5iUVd0Q+X2IA lwUufN26y5BRHahvrouxPt8gWS6X8vTKEipqupZTxJPvmy5qD7B/iLv+ErWP/tV2P3JL8/Qs 6jo4l+VcUI+eZn5gTw5Nj1hLL0rm7/tcx7rXscSFiLFUfSyJKQc03OuAsoGr/baKhnE6Qzrw ph5wyh1byj0hMcZCGAUjU1y4pQh4ncRfEW77rp4XqW3PJBXUqBbL/xoily4T6zovWmZLEAR/ YkfjQmsU2jdjecsa8rfQle3e8RjlPGCWq1RHPEuQaBh59zkgo/l3JUQc/vpH/PbLsx2vEKUL 5CgO77TPvIXs7CZtclx3wduHCaTgy93/HsD/oe93jHUnE3qZ/iuWSRBB8ynikr/NqsLu7BIo hl9JKb1jlPD1FBGZAiYXdLULdNuxd3aLqcUpOc5Mhg3DFKMRoB01j3YIwubyQ4AQghze/VU9 cOzaaGH43MXHYYNyQaYrZSUhZX9vuBESQ0dYx2ceBtEMcSfhR1QkKsVkEIzHLniaJxyiMD4Q mKA2FRxBB/lRUs977Okf1nWA+yO4MHFSdnqgCBBO2mrNDkir7PXb+bOmNoZxEQpG+TNzQAKC TMPmtYNAgNqvviEpRb29zjpjcyTr21SemOn6DDxbobeXLpZtJZ/wBOvmdgsQgB2yZf3u/r+e tUCGw1cJiPISeHuV98DTkyw4mK5zKUZKn5slTnnkFcWjT4gSBZ3jts/1zRHm2DSJ0+G/aLZm 4g3O9Jhy5Uh2/vfRcCqrMGPEKhIyttW8yF6t2iAKVoJ6+ZSmyje13K1emxgn+eDRLMeaHosZ 27RTVoKkMGBrPPkOyxgUG0hFbO92gFdwtR+DnkyxU7SeH5sVcy6JlBxmwdlHaACWXn68AiDj 0PpuCVGiWhUb+HFELZDPVJiROBCL4PvnAMqTu03gcyb8NG1qKKCP6L1g9NDntlBltVawI5v0 la8CDDUlcJ5qFoQEIDntS7QbgaavBta8FggQ4uWL3X1JiiFptOp9PBIsR1CkLpPO8YURjFhu 5pB6A5pdVKe16pHUeMwlBQzOMy25gr68aSbDa/n1mucE0LW5lm/6tiPnn0y0LR4YLnghBeHm D+ckufLVxjDQcitY6YL0bptcLlaaxKyQHPd1iEaNUpov2W4oyjiQBnHBLIeQ5/CE/kacddWu 7VOxFDQlv8WkvpqZengdDIAxip1NAzmUfNAnimjPlDGfm1uBBo1JbLZkWMXQVBx+3AtBMgpo CevB0NXBDOSM0bWmBTg5uEWlwnmRHVLzR5ngJRrK5Sv/WogOZM3tQJGQaxWUZHkMt5pPMZv0 4/3D0yIk6sf2I2fo9Lf8nPVQsJxULyrTdkysiyHGRfUXhvHJ0Zduf0hxTMyvMOsa0e9ywOZn 3ISMcaajsKdVXqhutdP/7pQg+t7zM3B6PEToYIMZe+RZN6l2VVFC/LlgK+arVD4etIDkmXDA P/7hC4VG5CTHfjc4uxyn4UYeH1Zp6lvJNGSCsteoSAXeOKe8K7/xcIUL3CpyuS5G0i6ugk8q QjfBlfrkgNnxNtlpReRwNErQkpHCOYBH6OqsQqksmPz6c0ZxcSWmZ/Fg4b1LDaH3eTvdbYwc zU7kc5UrZMogHT+vFyFBaEPGPuPqUNzbLIxc+BzF83ZjSZptPk9yIWGIcLpPCrsAtLp6YQNE wLHrGheDWg8TY6TKt+xVe1PblmAzdkbMIfOxsDvbgNTSYotUqHzFKJC2xKg7umJV78b/ky2z C5hAKH95z1gUZH5FGmfQ/N4vM0KMdypQZ7Wy/GBvDzFSZnkNmDdz6H/82uaiwOT+cGUIbo8H hEXX0Jcacmw+Ru6664KhJ1wEX4w5fkNPjT4y/1Yooyat34vOLYZEP15r8D5pwZWoI3hQWO1W NqF+XTrTPBTVJzjs9ctgYzoUhdBBtfQeRfEtqO/EwoRnTXC1M0pcHEVwxDVablRgh+PIbYz8 1dKOxSOneEprPMzHdXsM0ZNVmHZjPL4qCUwR93+HPU9u7D3oB6FH9/aNK0Shzrz4wXKcVy7+ /+dn3u+RVZxBb6WbZVSZA8rj47qZUT3EeEohxYlyBEJ2U5V0DMarvqfYObKSGIMgNyDIhyRt WR0ETUYAF+FN/HeuDxpsp3TUoTa8yiDKk4Dzh3B2TB4Tu6nSQzm+e4QE8UW9xUxLjqlnY2ym CcGbmeUccLWAaPbYbU0Opq9nA5S0w62dzBFwfQNzNs7VTWzTsnVm66ITz5lvCO2WL5WWMMUr 7DtbjfXdWSlUO1eHP5JFxKqAyHyJrrmxkzY2ng356e7w2wD9OtgGQQ2XzpLltsExKl7LU651 3QcBzFrwrIPtgt9pnhfB7oUoxNg8YiGQW4RPKjAb5ZVJNKA/n6xC3+CBG0fkT/XbaS7WQ9L0 i+4FS5NOwbFoXohx9WFZPx2GcaD0UnrBXXuR0o6FzJqZyfejuQJkanNazq0ec+z1j9ttG4VS /UtLUxeModFMf9ypOhFr69qxGkkxENTsa5FukYnxfc6PETOiU629NBFThP+mTLKsxiwlxXDb D2vk92FxWOh5GRYlWvOOEq24KQSOi8MsPgV5qPLxLEyBXW6c1fkPpOfzq9td8uGL37hjQVCF YUDsdtLqudYngYu5JAfw7T6FKs981mTzUHdBbzRT8Lf1D5qhagdmpjcq2j2xwo/ZTTHq/rLq 33jisOynvRXCwS4IdoR14YXXta15cFKccj99vfKPj9EhY+puO9NCQDZC3zfyxDqq3iZaEkMe TT4ATtvaJO1Rl1z1cfYVnR7FgEwGPl4yLl2LN792jX1hu4+8OuE4xlP/u8JMibMr2e2XTmvR H6zw8CKBD8fX1PSYNEGJaLvs1YcotntYh+F7iRIZD2lq1m5H2HnWoJLAsg1TOkbUI34w2Gd7 Y8w8zT4UDImdOxky2o/5fXq4EWxT41wlUnzqFv08FzGD7v7AibcNHDxkLyHqUu0cI7MWND9s ljTWcDnan+TegsuhK3MYvP28G/Oq7VWC9EUdvvcNFxGdMu5M1h3YA/o8T2l4SQYbufiS3QEY U8TJj3BiBBUaila710V2I/BtW2kxoWIuqOQtybgwsY/fulJpJtthFPDcnbqExohNjq0bz/Ah xU6P9QXo1ABponD4tTwzKl196Uwz3agDOXWMCuHK5xkdz2kk+K19vba70bIk8JtRGB2ToPQc mQ3Mg4+cn3VzedGsxjrRph1WL9QZCZeY2W4pzB/gMglUSu+LwH2ESXuUXXArb/rMigIuFjAG UdQdp8v8uUy39frkz/vvl5xy0FOOitCqzGma06B4oNYJKVrRuSJ0w+2WPmrKPPKbtfKJ86oW cv0YSE33pQHvWis9r5LuEjn74keT6c4tTjNVNil4I79WuUb+i4erbOVRZcBCnyy93HJMQ8// ocIc1oWfvga9Ci0c3xJ7cNTTnxKYbdWT3d+MxBmSFFsZcE49qk4+9wukNakeGmKUEreh9Qw4 WsLhTELCKYFd0pjYa4JGWQzDQue8vDYgVnBjkA5iOTXoM7VQEBww8roB4WCHjYazy1nxV0iP QpsVUxmJsX9+s88+VZqY20POCjTXLLooFGR2XifdberEvXfQJDWM5qs+aMh6Nh2VxCom+mQ+ haiUDelK2IGHUG/wrrC17iAq2UVuRAd7WaS/gXj35gLq71ImGZnyDNOe37nRjZIDBexuz42a YJmbVhYzOuIPhH8dJtVQcOJXygzaZpqpY4ru4iW0wCt9UNMOlsMSGzpE2IJ71VAEzZit0/9m +7ohqhjE1Vd/tJ2uu59rXEqg4IIeafo+iHcgioWun/SZsHsFpf/5NG2z6GSws+aVcE5rspEO gDzbAHYc6sakioMa7jSUG779IvNMty7iyJYbQMU/v5LDi3jttnGgLEaqIob22RyC7H4Cpst5 xG3oFWXfORT6K5rqvM3fLUYdlnAtGOTbilD/usXT+wD+Vt9ms1kwocT7/ZJityO+i+0CTRGE nGsYfMLcS16+f0P+V/dNiDxF4lxFj0CTXMmIBn3NLDQU15u07Wckf0mLMtVVCCFsVC3sqscW Ort87InViDst605kKRAX/29Ng1bgNXAumQ83jOS2zfg3P/z+996XAHJitx+BKBDClag9yTFW shBVTpfbpiqtTKL55cuTsq9WYbPUt+ijwvYdbJryxPtooVihzV4PuYAICk9wraI/+E0XEtik L2Fv75Y+GWPxFPVZfiW37AaXNnbvKI7QUieK1oShrd+98bhgKY0WCHvrQF65wegm8RZcf5fV K3g+GwEPvR669X5Yh/tbj3aKrrxUzxnIQGE8kGuypdE7lzxSDcZIpZ69a8Jf2dJTPdJFvGAw TBtO/+vM96lzubMMvPKpFcLHR0+s7wf24dsRUXB/CC7p7FlM1k3J0YNUOfOnrBnMM+LrWbUO VX8MHbL8VKcfpxoxZfpaLM8e1H/qGo5LTDwdsNhGvG47Dt0JivEtHSVOqDR37XVKHAiNu6zV jh8m+7dtBKoLERQcgEi1ABZ2vyqS74oNkihvWNMAzL+EZN1gy9qu7g6uGp/Jgi+kb+aH2Zqt EKTZHddFpsJuwTREsxrDaT8bOw0RQE9X67R4j5vBYy8FH14pFg5umuzAMce/fdOtjRDFa51r cW0dPDNIp7txv4zDmVNOo9gIqqYbkAmzJbZiiFoMZRJQwlJjbIuf7mNncQSJ7oSe0I4oFobD ICe8lpXVda8dlL1YIERlRkq5ZGE/YGTFd8ntM8bQy22wsYN6ishi1JH9bLPOdas8vVvmS80y KbdWpopwqKTfiZ9aPSfQ4oCVcbfV0vR8zOlRNXj0AWKiQeBowOxel46I9q+R5xh1KeBl5us2 Ene83U6DWCuffTwcL+jW6u58VrPG1z3PZpdpRd7lQeikYe/VWEk2h2QAgslKMbSkR4T6gfQc kIYyDrnySqaNAixU1hgjwiA40+w8kNeUsNIkg7U5ae1vlWHGlFidcjYXn3G87AWSpNdO3fgL KVW8th0vnsj7lHSYdFYGxd7hvhv+AsGNh58yFkjPpnZlwEM70Tb2OjeL7FcIMMmAtpkk4ofB ex5Gs8Rdqq2iPQrDrPUTeqSuephgXAiwPNmgu+zKLEn2tUY0Gjp6mJOpWXt2AOGnEQIo9fzw 7YNvO0TKEyAO5x/dVQ2dm8fxx5/7skD124trvnRQE2BpZMbYw2wkzt8f3xyFUthv/9EokJ+D ywq+dgmo3z5h97bvFkFsFRfSmY5ZhpFC9ENkDYhLOobCR1kY5+2MeS54F6VcsN4WslzYFrgC w7lsB/HyAIPOFolCtGQ6C+eRkJA/gB2s2k8+tl4zc0AotZPdpgWD0MNaC+N50VecynToyNJG GlOxryGzREx9Y8pIZ3kpY3Os0nsQU4BLeFZh+486+/GeVzgz0iUPvQ8/GJrXCVIm6gTDFBMr an9tT557x+Ru1OfzFuf+WgNRm0Fi8oY/JNz2mGd0YmEnhkd86Z5yY0uKEkn746CAK+83LGfd DxuzbvN9ZnJBOaAxCFZpezsMmLgrRCfG4CLqHCQgWaBW4pci81l3TW3vs3D3OOZukqdn0J5J 1h0Y4yoCd11uwiQinZVEswpur/+uuescLatFDJJc6+3JUL5xVzVjq9IGAyMwXrJsq7O//A6o OjvA/r+xx3S8T//XDMnr/SBhraKOWys9RlLmTa3iywVu9cCFRunrIaQ6lf71a/wy2JPROwq3 wDN48eRfTue4C9o02BGksO6b7TdrNjSbv+A2v7sOR7LuX+jqt+PyL8e3a/cQqE58OHD7UWsO iTDKknkVjfRGA7n+bvZ9Ubt6gKTSgrLeodCI2N73MDIOpO14H33qiyJjvaRLLVrRfQXHF5nz 9FkSpB7b2qLNmKNMyM6LRSMC8p2uh1QmgxDu638FIJI2gQz83MJcetwANoIKLYj1FxbJ2KYp GZw5kD2kzPyuGY3eLCORwU0b7X4FJN6i5DR7Zdw9+D7TM0L+PvnCFczxRIy0xNuGWsPPbtfv CDzijVBdVxG/2nHYWzcvQpDQbVu4Qxt1uCV/baSJN8Ogg9jVFSVJlak25wEjIzGHjIWRdco+ 19LjBi/uPkEw/zWBdWIzygu7YJENHFtTrRR2sKm1vMVkC1uRhniaSRYodB+l2wOJD6PIbz0T 6FSpSHQBy3J/epqfJ32jYHDIcf7wzriaMfhdInX5NZgDPNGrQ0ET1keryRtk3t46qn+N29Sc fwQb009e5G+E9eLXBqLfRwlzNpg/g4dh1cKli8tD1GLGhZINF10s6Hjtn+pUyfXRu9BkpyqA HmVnUi/+mjXigpV/HHd/0FAOt3Z2URhhBp0owVgdfyrqiNOnECQfKvoVZ0k2XnUhB/4DEFeF RoJ3b5uGpnzsXJufJ+zIMxrzxseJ342QDBg8CGhhoD6yc2iWFTjw99ydKrjOxk4TlTGg00KE /RxKWRCkUQhw73iqnjuV4sg7allaoq/c923OuK7GuRe0Hp7loRthzlWmYDZzHt9xEE7IikLk mgouaP2Yl3Ij1xkkeF6wVlGNmGSd1tq/b/x6TiEOSZbvfAungcF6MzjUJ7Fqlo7uEtHNViCv MfKMA5gnNJmV11B8iDb4tKGce48t/262SdkWBJSRCpwBCRiTCqW/1Knc3efFtSW2QlMm4kNE uwDtHocRfIkh3O+Rd9QXg+XHUrcfCxwzkvvKUl5vF/2NRoHpooj4yfuVHqajXEteOmZvtQyH tQJUN8u+PCmWXYtly9j+ettrwwtE2Z3pVs77b0T5IFMph5+U//5/IwqdLtYEdY8+n943EhMk ZyY9BVGjM60/VNlSbgju8r0+3h2x+uUFLyGX6V7QpMPY5E9RNRUc5J1KZzufrt9OqwQYC3kp Mf703fN33GfvjmPcHaXLbk2/0l+2pA0e4mt3gOLUOsBHDqAbXfVaioQ9gjcQ/8Yg/AduqlbS QMxA7eZ05ToBntyCO4niPw/uXBjrCoQ5X91xrc0gMJWj8XdYsdvp96MbfDrD1yXCqrmuLYId MU5j55lDViYoxupLkzKMYoQhRjqr3ZT5TCCZuBmhONF561qxFXS/oZvv7mlrrinyTxUZ8hfL e/WuouRPhH48KwZSO4vOP/JWeY+F4Rv+71BUhgdRETQxeB5ikTryE2y8jPRuTV2wW0gAPEAz KYXLfpBWChX+5WDCyBPj0nPN2PMndenzXhDrzfhEBZuipTOTrbKuvuwELIeKmiXqSP92eSxU 4Wqe8MuD484ToBe4A/hAvN2WBFqdkEOrQt597DfbZvuO2CI0R6U33p8Ayj0OzFP/A0boPmmR Ti01FwWyY9IPeFQ7zMbxlJ6K77UKooI9srxk5vDoEnYnojGEod79WAlpyNf8hszAScFIDlvl tmiUGneuCVd15/0J910nbU6/IBJitxfG9oBBfZTJHVtxwEDPTUagP2z6UjOXZ2CWj6P/8UmO iJsJyxzRG/aht+/s0Vjgvo+zNNxjRguGxxGLAN4PJlzd9Q11KmptEvP57wUH0hYrnslh203t 3/HDwUeqds4ruVdzu+nrKLa8Ym5bLREisNkhG5GJJlmoQpP8IABcc20Hm1fhPCr0M7uELho4 1c6RBOA+zsRVIMjVTjLYx5AliZeE7UUx35SBIIfqK41Znpu/57XxVOfyr0n+LaBN+x8zE3CE J656DRhX2p6pEhtxkTwo6p3INE2frttiqkX4xc6yWNZ2/3Xgdvh4AkWhKpYO8akJ6pGkxQV2 wAiJrOKPIUEEBhsp4ezy4xbO7q80iHwREe9V7ZN2AzXG5Nw2oSL57A1JrU4sPLKwCl0Bj+27 qaLkDAbzqnMhErlaeOgw1KQPZRQoAdX/d/0nxp/T4d3zZbPZi3XjuVMv8vJlS/f8dYweI6XT KUAFTvJhiS70VMKBGuIp0ohFjFqCn4XasJ0KOWU7UiCgQZWkYFiug5opRRvnWttQNas0t5iK qs+SPcI4BXol2cJw9wvnpWEWhinLH+QUyK7+7iqVVmUv9BEEcLUl9p+iRZqAjVQf75BUqc8/ QxGYBx4zvGuUtJFMg3NEKVWzRCRk8xJM/oWwOiCCT1kmQfqQ0y0AIUR6tkcN4lcmIsJYONUj ykgoGRhMN+ycNbrmRoxPNQR+mpbaez7ayk2TH+7kjQJVcROttZ0dc2ofLYmR/hCHINR5qgc0 Um6UAufVsMrvfXq7RCVgHktbpVD5CrROelRhn0hwgiytoi8hshN2jF2uAqRBVbx5B4REG03S A7QgRbrBV0M4aRevr2x06GJGdIr474mdi2OGPM0Nr7d7O2kkOj4xMd+6V8H4XJuWGFRYh4Yz Z1OSmBKEL6Hp+D62BgKX7EkYPIKSeZVclEad0U+NvE63m2Id5XsoB7WETHTHlmhXH7V7m89P SXMyEcs5i9oUITxqwF/zQfvrWRNrJxeoqXr+EVUQVa4g0HgHmeulbR107GX8sYmfw68aQBpY IOXHUom67c2xdIDyXfxsuq0uaB6bGqOzsa+Adb1Z3WC9Ip0AheF8Z+zGDbKySCV3Y+7nU+Bu VNN6sWG42fqMiHmK1R/f+JGQ7O/LADNdJyW3F4/eBz/YPm7pIVvj8K3TBhNgz36W+bimOnza lLhgED1XxnnlLdaOg69m146rYpnqN8HI9dJD7e4eYEb9oWoqur53e+3gCZZI2YHfWkqDb5uF EUU2D0eliKnmqyks5oZ5z/zxeMbs2drEfZfg1cBmbLtyPNJP53e2buQvPWRlM7ukPq55vy+S 6jKwPqOpgwIMoQlqHGMOUZeyaoqYFHpjmRf/4Jwte2DRVDNvnzdi+ZoVRmghHCMgzp45odu8 Rpf0bLZf5JH+vnmPyREeLlFhys0o95Ec+cX+sjJK9AlFDcfEWIZkhJMOQFHrpyCbDPsSC700 pwTtzuE9oh/8kH+yijTIEKx67FBWX9TNeN0Rp9HC1LbUtnKDmv0ki31LmUQz7FqtNFO0No0f +0YbU1QsqevkH3S7hJcNaCuB7pPuxsYS8Xp7O7I40YRpwnzBgZFFnJzm57UPsbe2nfyLzeUZ hB7vzL7btZOGu6L1j9mK/eEQYHOcNVmdEHNGiE49ssstLiw7frCfTMWcs1vyN6Ux5+ZtP6UO hpcI5My1oukkeoktivQWHCfdFJz0bLCbgp4HSSIjlpWAB+6uOrX6T6l6td4Gr1kN/SWvCpFz 6VeV9Cq/2Xc7ivmEeZPeSKeI8NSz7djWcc8r8d9AQGuk9gQOf1Hf/uZsr89S7bak2Utp8O6I an+e9rkGxL1EfBr7K1DdKlOfSlaA5uYz0MohmJN3kxLUedM4xyje0FQ0Zk9jCXERjqJfdvK+ 5Ds83TF7eW89iAjvWOBHJ7E4DRsL4vfSWp5/f+cQTBDPu3wjHNcGY+9vV2HeBlrdJyKNcv2T VWPrRICp4/HWaPcyyroy0XZhG8GM0FfzmF/YAAI+yBD33Ro9BZIomcOjTH+q1n4jxqaW/I+l C7herCsUcIhnE3top+tfG8o0MdEvB3xJ6+rFWBJK2GjDZ55PbpwnYzXdbrWro6uNyl7Omm0T YCtsSXJVemjwMwW+sExttcfIpTXS8h3085RKpJjQm5fddtrUJftnRqUqjfbEx2YSXCax7Ojg C6B7IxD6adHC1eTRwuuV+psclb/HLnbUUulIEDFeAU8pUIa7Oz2Visq3gykXjOLUyXFewAtc hXX2pb4BWlZ/hPDA2AKDaAJ9GeZv1C1zVXQJffSxxUvZ4TxAvmChJk9Pm9LR1uaDucB22UYm jFu3NC9+Ad+ObQY+26tE+5IhTEz2SWPChMphSKaUnxN03eZOAARyaAHL3IUfwLry+2pxrNjM /Fk2uzG1ekWCz0NqBiAxAQpbomghH9C+7KEhbLcObODSdnRciPVuPCT7IYUugK830km7CUWn XDs0UjMmkzNvMZqfJcn6svC2Y5aHpuxfoWYS5CoHLMSvoSz46pOPQ+XZeq5mOr8oQ6MAPUEF zcDtBgCeUWqZsJ9KNwxsq4IrvjuevFdjUQG2vq4KIwzT0lW5jBZ9mA87kDOCkNQi3W3Kd9v+ jgWPDIt/iZVlF27ooWep+G0eiQSYvO6pO0+8EMfXUcYdBp5WMWzCnydJM7WsliRwjmKb5As3 idHAE0c2DjZyJZso9Ud0LKTQTuJS8EMmeyv4gnAVufKwiIKBCmeNOTRvRWcoIo/wXIgN49YM AwdgfV636s3zA8PxM7PTjmjQmAH/kIt1v0zofv756sMo8mg68VHlILcDZMaklola5pKaS7fi 6rcL9P6MhX42Mcpc4aNCzb7eS/rdrprQsAoZFxG5IV2hp8ZfSjgnnq04bM/zFzBYYywmleSB U0QkzzX4fam1tCn+SXYwoGhnLhMV7GFP6sXJLykeJf7wB/Shv8x9UEzDhXoxWUVhgWjjj7Kz W8KSIELplJFgkiT20zJOO5yOOmNrnHMxzNgDXFBblW0Wc8+1waCH0uV5rG8kp4sh1drHU4R9 3epwbgWe3RMMktRDS28FWbmlqhPOTF4owaGTKuIBCL4m3ytDPC2Oe/pnkuMTQ4CglLdz36gg MXaZ3zIksHtRzT68cSx7GrBGmRd0mx6gUj3secTFCAXIMFikKRQSDtfNJ5Hyzqpdmi5CW317 tDwbEZk1nf8DAP/B9NVEOSzkFeUWCPhZA0uvN6yVhSxhgic8mtFdKvr2vzvG1JZTVndjav+H vDxP0VfaYDjssvUqdyD+52Po67eOu99S8S8S5KblicHBC4ySRp+iWNkYGvf8TSJfE1KnR8cS ZsNqMhNQPWTNzFR9/XYLgInKc/Lduhtz+HnS7KFuxQxlBBuRBfGWa7Wku73AtyDq3mZcGFqe iOO5sK2uZ5XvauEQTTljp9YVCb1NsRPBLsJuPGO0sGU0ZdD7cqrDGmU5hgvN348Ls2dyqUkw tUnRaCIfw4yX0SPPWRh5HIRJG1AmutAsw66p6Y6DolZ5RcEuUzY4dciNcVusinFgr+PW7at2 +/WPoA09jMgZBu2uvxW+QJNAuze06UHNFVmqvRJGtLuwXECcSEkp6q9ia5h/q6rJwizVGPxH gQasedWSJu58MM3Iw2nZe0ZbdDT16JjxhZAjc+aUobywqtmfc2i9DyCIypdzUSY/pKvw8+GQ jHtkmK/h9KvST1o6sv4jRJtiH8Kex1Wk3hBUSgYJCzMJxTFXTgwcCMHkXRyF4bM0xd5X+VG0 2c1uGRc9fkpD9wOng2PmVItsGaWuBSgycu3fLMXwyyMIVOi1Frq+DcAY60kFFKMObQap3ooe heIv3TQPoylkjLAMWWKMHZtwV+wLfNLp1nK4UKzNHgsazvR913MtLcE2aLbJ4eaFhxZS0s6v z2YnBGLC57kD9JIUoL/bapc4NKPmQLV/MACb6HTF/Ipa/0VZGqpICHkVgK+cPjKZU3Ge6fSv SU6VcyKWV0xgyJlVDcVrbQ7XEeaFW/Qn4YXh8wYfF2MSvs6TpA2KMUI9g2xNGxIckk1FyLJ/ 8UUHyYkxJY2nlnopTbTbPAYX/FCaOCU1AkKtnjO41ifZ8+8FIFiw1L1xHe/gatU8PmSOMfWK O094wtqpXBkvd/jNA1bbH7sk6mz7R3doOlx/zBZPJvYpuDWUtsyl3ZtlbijtvnX3l+0xBvnZ jYkcGsbwTfrC8Sed1iS2L/RcXax4M0Vx+Is/oXhyNAbtnR3xUy4ErpztFYuVhT1ey7Y5TPaO JnyNasNbxV41iIF4OyzcGyWZ7Ek6zemSYRBzBhKZKCRBg6jBKweP8r1Pk5L8LDrEL1YLMgoU LeSc5b4zHuCcSdLlxy4bW7EHZGs/A1ldg75xAYnOsWspio2HPPqy2Zepibz3Y1Z2EFE9Zjx4 Ofi9/Wm/lp3bNj8Log9+2DZE8tWowQfURZeKQXEzUfTFOjET8tHo6vhUgO8o/kQS4AoKBqMV DlwVw5JPU8iMDhoZGktB07Ol0JqVvaTUz8Ty8g84pMFGd0COwvi7+nH8+yVPfzJXO+h1i0CC NdyWguo+sg5/mkPOuyiyq+kdHbgTU27wMkOE9a/EhKMXzemzKgdpMiK3s0aMbOXW2xJlZbWr woqDSmuLUIOkbwecE4o6ri+eUV+z0hA+GDh/WceYcu2/4kAOt5XHPJx+Jo8f868xB2OHAtM4 IyM3lrog52Zg9o9vsricTZgG8zyVomhM7fPClHr9xdtia4f9v6uyOTtCNZDdO2UhF+5qS8VT f1AHb+dBsTC8nEY+L4fgaR/teKy//x+7+9BjM+yNbBuVFqrjLWDFiha9KDCW14ilIkB3t+Ww E8/KMRn4Y8y6XsWk5YkzHqrJi1ooHg3bXv+MJdDISXgmBvJa52QFdZ4pyTflbo6WsAE90FSX hUWD0WrQ5KeB9f86qxeyqFFJj6KduSgZkG3afz7vuxRg3CVl8m4eGgbTtwFYz48KFBg8YcQc tOZDG8Sf+tJb8OwzJ+YSe8DOGousuIGnJHaiiu6EhYXNKMXT42wa0iJANFHZlAXZ7c4EiaUE xcsE6/GeZ+NVkpwmMrrZNn0ePfhDBB9gHQ5yFvYNTgRGzQiAym0lLCur1zszken5myF9lvK3 /lcYU38u3ZtXolb+nfWy2inw/hmrB1ha8k1NsU27IOHoBUHyOfahS0i8eecWoLKzyhuBQMcI 2BkeWvNbbu2YZ27FHwtEnmKCaWuWIfXM5NVUfh+fMaTT7Gi5v1kKsL8BPfKIkrbWjtcua/3y 4xf2DpKCNeuQM2x5YPAVF+qC4YmjVr1jQyte45/72T1W/CliPw96ahRB47CU8NbdPCm1t7JC 3fajef5LnpcEAhf5qFKDXZTJVhe3KJjHs3sSeHXlyAkvXr6zzCpG/nrAs8dQHB1N6JLWXiGx keplUOKbRcuyc2Q39wWtyVquqg7H+1ejX7YzOJqDEGheRS4Zt7ABCgoppRPU2SeeOzxTVFVc gbgMXX9Y45zujMMpj9eGTeoBrJkXQZpo8Bm5XWtPycMrkG1Jrz198R0nq7zDBnJDFsByqkoh N9QqS4ngBCN1LXLlbz4KgXkBnxgs+bWL01oZ/PtZRKxeY5mmmtP40G04BDjoG1M/oqo0Ibe8 itcn/5g5oJqQfCijCuBeDGifc88djvAlRvncg8LkxmviULv3dIC3Fp1+ymg3XqbC2XfqpTni 6oP6O+FJ9v4MuDFGOe+6Wtc+S4ja2MsIP9cKWnhTKu0TG9OZ6SMCbYVJh3Q/pB9tNu6SdCIu qBvr9ONSwB8RMieOUCUFJp2PJOXAO0p2b79fnLmQXUsigpN4xyz4Pxprvq6kNbFYIiM4KOJT gPhn404bzHSL0gc2ldGRzZiUA/uwtxoAFBIQSzY1q6jgmcqYKmha8FuCBHQi7t0Y45z73Pyh iK5PMAxqz867uudyH6UK8bwZjU7PS1t/NOGtVrr4lV6AxEQ+n/u4ivxzeBgxxC8+FeyAoLVt lVOx9GR2h+pnmrfx1tV+pqIv5W5Cycltq3PVOIRNr1N0sS+fpNLnxRuuyxSJJUS9wz3aE2/w 3YAf/iH4A1dXsfLlW0xKjxVHJmFT2aCFyEV8T5QnRLapIgcLZqzIJfpp263oBVVTzxluJACZ bOzhfKGZ4lWgNh43LN/7X7aFn9LyJXBSsAbfpJpDG8d/prsa3jSC6D+kHQTxggfhCYoEimp7 HolBawJp/DkEsEA7FyFJZTa81WnsIiNCG1IA7ePalNP4Hcj+9D2VMLHUlusJHxJ5SNzdW2Ym afDde03Ca+bse67rpC0aWBVOFoxHULTGDtxPisDtu0QdQVmyHLssEdJroE+Cb1Tp88Y9zI+m zVw0szXiN4GghhG8QmWx0hwpZqNNuU8JwsM2Y7iKU+o1EcbpzIkVn5CWeAtzKa+5IwdyZwp/ b+Z4pNWMBO4jVqqlJ7THfcNqW/gXMxsirK1GfgO8CzHBWdRQ9YKq2C79LzKEMIAfMGK3mLWD vtgvVXL2chbY6cohKuJykG7JHrt8S05nlQ1Ye7Utpe1MYxoTn3OoOdoCyC0BEY5hsC0YbLdm JMP3hOBqaYtOjzUWozr6WIJldh7hDafz48AtdtFF1B4dADL99BM7H3UU2igpfQZSU7XPtHFO M0ygdgkxq90FJfeorU5DFfApxIlNADUDdJ9sJB3QWrfNWk5ScYJFiLw/hp11CzrmawnkqtQI jAzbBM0/H5C+cZfAEIjZBDHhaqYdGKoMi814xtttLwaDbtl9uiHvFKAmtHiTnUu5xP3p2qgv xyVN4j5F7BPQK6nMhZ8mNQtnHOS+iONrp9BS7Dah1R314iAJpMcGg8ToavrmMXqk+x/y/lYK Z4EhZFiIHNnMvJ2fvIrhXOFCgQudrIwzjl51Ps/h/lnFY6RHJXjE1pSPyuL9sz02WsTh85Wc znDSdY8dGQQ89Sg7hxLUTDrpfCWdcg8fsT2zAMu1IydDcBV8V/Bne0tOafcbmMG796fujSHs ez79xS7J8hnETs5YGYEgBR9S5w4e674plLDGr1yYvoXK5qAxyjMfo+jsNL8UjimDhpCe51By dis2czqsIU37EjVQnEwh8NweKHsCsTF0N2ck7419TCCsxuUGTAYXmlU+/xIp1WorY3Ghl9v6 Vrlwe/4O4wC4iVTWSb7jdTCGAHw/qpP0qxDKp1qp502uhBNYaGwSmPNnzA6U0pNU/6C8HZqV CSaXnlqH+jFCxaay/3GCuIKBxOYzkK/y3Iki3z/du0Gu3nL7lhOgkOrhdf0EXltD4V3iUbja LV4q3L0NNxF1D8fCXmA4tNrhyUAbJdK65kvG9X7oCo7zaaoI7bExnzys7sfnaB+uML6ySCIr UNdPxj5HwlzA4xSehKEDyKlLzs+76WhB2PcAc7Mp6gyB0q9Pbzpm0EicTpEnS7J+k90HsvKU RQPvw3v7WUEB83pDn2mhsrIjnZW6Txpn+1yXmSkXrjNx7QGr+qIv/ulANQZh73MCd0gRYgjZ DfyO+hQKE+h+tTRKhCG+UMuALDgMwjDoRTbfHCeZmixQs9TD0ld+lMwHsBteqJAt+aJyQNOX fex4/coa9qIgws0/WY5B900qi3FLevmKRKWCEHvd3WmP6wMEqACyHuoanSxStojKxG52BbQl 54i23I9ZqP0OzIgrYsQP+grfRAArmUoTVP4leffL5MDZaLt450MV/9cZ4jXhMvHDjsRMCImo gZNt8D1tH1iYUF6BknvgF9gV08OmWGYzWY81asS7PTpBb/3use4MFn9ERltu6Gxp8DCHGlZR CmimM1p3nIjZj5Aepa0PMlMEWAKUoWe0srQUCyT+1spHo+LKYmbCO3XgzRHZLRZUTCvM7f35 TNZWW4l2bCGGvCzmDzpKmN8YGt4o0seXswRGDjNfItFeA1Mao/vbRBgdy47IDv9+fh+FGuYi MZMnTMh9CaecqY+n2+doSO/u6BLz8TbqqAta6T7rydJbXM0XlIahGKpZdKaTbg+xQq4M3mBZ IFmuY7CBFGBXKexvV8cifIZ1BU4Tg7ddciSh8dRgHOtsSCCXL2Foor1ktCi2ye2EVdTNeEEB ckmroc3V9C6Qzt5xCIwAAPSLgveIUnrWKG4EiS/FBgevFlSHocViwciofpx81nMDdR3xti63 rmYRIEapZdDC6P3eBVlRYMYNneV0HAA3swVdSey+PbXjDZ3nYqoNNvjjg9sn9UttL5MUfeq7 PZ9W91e6DxzgY9LBUfCUovnaGbVacGMZ1vu7iV4QNRHg8S+v+em++Qf9pumAUWLFBojZZLc8 ba5yUSm9zJ6ESemmgXNC22Dex5EWk/20thIqsDtWMbai0uvB0yYFuTfLNPR1MmkWsvKpmv/N hfETnm8m0K5u+L7rWz7ntjnrbHMuyq3+rywUnDMcwk/XCFpqBR3iAHGQl3HDNEW+X9mE6PPs 7gMajCI7ssLuvMwXbnJ5Iq8q8cbRZ6htBCsBptGQ4qadK9Rfol5XYlcBcPjkB3Stw7hqlva5 Tx+aQK9/uW1aiuuRtAweiATosnPbr8SldKu1EvgA8Wkw8cG42gF5rccjiVUm8AwYCSOse/RE umwYD/RQZcEocqXU69/3hyGg7DPkZhDmBQAOqZyxxWz9lH0EI/wNbYw2E4U5TvGsBf7/odYm 5mTTOZVJ3JRbuselPBT1DsVUsFA0OSwsFp9zwDavvhZkVVZrQzL7BubLekZm1DsiT+sDfC5H VCi9AYs9G0MSaEB0WhSCpGsrhvEO8zH5QuEKXHicEFramkzH09eoKOrSDM2xl7S413q5FDxn /BWeDVqBCCV+ofGUz8iGKBh/R+KKaZgtmwkrZQ2msoszNLyeOOanEUfOyb9IOYwEPUKh+Lvm XH4WMyYltVlUUTyQpUpLN0BfTWyyA4UIUF38GBGplGscYT17lhG5tJHf1obX6vgEC7P9jiqj /3isNAbNwCFWk+auoIk0mfeNFsnphKvPYs4N9rBgjUKb+7wDOt/qQfjGqimuVW4NRFFJWKoi nHxVvMdTE6NKluSp6DoNDwQJuw6J2J7hpcUq6HmHJggndmpq38EPK8g14cLLxTrTewlAfnA8 9778RL9U7lVWNhZgGeto2n+2D5/mpOlT9RQ1hCOdmOXySKd9DQhenj6owDtXU7qkqhZeGkzK Vnblur2WXNX2RNl9kfQ8RoetngRWIsh4gDJAP4/+3FKUKcoEpECe8cT7aO6DgUdPNpfPRIeh fcpOanO5qYWzTvjnnUBJoSuRSkrWlGr24epIN5iLdPZyUxUMvVONmeZVnplWfaoqKXqvcC/1 WRmW2hLBHVAiUDquSwDJZKmsDJhXFiz5ptdSwjtoVnZiNA7yBh82QifMob+eC3SP9Dm39uO2 htKmVGRiLILNqdH+w0Gq8H/A6AB2L4RnRNa089L7TLspPNLQGffBd4Mpj71TiuJBjhjZzicO b3So+47JfOtbsWvuQKVY1QwY5eFKjWacNf6uCW6IrF+La7E6YL33cmr5OjKIDipu+Gdz2pzZ 5dU2we2l2uyeTe+rWxLvhxuDymvULnNBaGk0r4RUfHBTSDA8YRnUPIODAKGIqawvPCCR3fLq MT443ZaWljaJBycAq8x4FnaOyHv23bdLkWZZjZoMY/6U8MnLwTZORhXAFcTZkBlnVhqdeCo6 Q/1HRoEt2XAl14x96VEzxbYjocAbXRxLjWz6GsSOfBYYYfh1I/lKVaJUFdgbgDMNX8KFR53e LDMsayBOmssG7p9e89iYVzfitHK/XaFnNnRb6dsbh1zoxHCdbSrj6QSF/geOVMSbeQljJptF pKEOdfdbmZ4qZ5DNGy1+Iw4KAe6qe46YE5QR9ujgVtepJIWm0fcFx+yR0Ey5kVj8YVuqxyX9 4vqFj2OIDvdcblSG5r5+dWHJQe2/sTUC+g5bauj/dZxjyZXVbPbKc/wCovxdeE2G4SWMku2A cS6blq6m41ty1jszbmCdrJQgbVotkXQ6QSVhOMhmfFF/i3xfMp1siI/OxE6fL43w8tMtjBWr GGo/N3ygzwIamEm15fWTnjKFFUMcBxRKz7CEO0yVQUKQFLzLZigOsnsRy/Mtt/luTMRUblrw /oWWbUB7qvZCEnp0n8S2GrERRUPaD/+Usg+KJY3g+2ol4SPQ6L2bgNkx+KsmfuxBtypWenzZ jagDoBGCYkfXCV3rBNF8wHuJXQezUnOiODNFNHZ+eejYoFJDyaXsVzLWloDWol6KSISfhViP MaOlqHlMNTQPcDJEELfWqNu22UbTDgWlwkSpaVRZaq3om8L7bgeDaaE68GXZVstk0+WFzJf9 9pgwxF/4cChQFZYPNMosxD/HmnElmAZSEhzODuPFUHWjOsxsNkm3vi0rJwXAo7wjiawpiJW2 DngqlDv28c9w4mZiAyycn4ZYV9HU2bJHlVctrR3tRU4vZLtVY/D5TL0rZzr5xJr7Ifwzf5NP 7vjvJRrGG6DfOhYS+LRiGef2+YBJigB+lZFC2Ba4fGgP1JnpxXzd5D8pV7rVeNX6XW1zF/As TBTjHXLntfT/wfB5in7N1QdugSV2+yPtKPifxNg1lYv3l8PmsH9tSJ3ZTMnCqhzSrXS3RFeF P1ZzwMOEnTDvN3Su+5r42VajTglSMVsKFi+7KsTFUJwEiEEgwsopG01tPGa/w/spRzCtfYWL uV6ZQOXODJlHEOxs8fhtxFBKFwDn5YQewz6N63LD4PNb4b9HR9WueWmFrdiyVIO+YnzX5mTC d+C02RBQqizmMZ68msATKTOwqbfmTpegpuEOEvidMqDcIXtdqTh7mBmQlPrtAymHNzmrAITK /0PqoNAhgptF7iPsqFMuppgH2UiwjvAy674hBW9YCDqAwRIg2xuyuswieq7kUlJOSA9OgAYm OPVdwQETIyTY446uBhLCi21Qqxl3eVJKmg+ptCWT+eTfUnWv2IBYJyoOr9p+/8zkUyomZV6W 720N00FAuKMmSJoNg1Lzx3BoCH6Gn1ZyHTXWOn8VZkDetf29bk+ih5waiw/Ol9K7NYASnzUl l1/0klDYmHnLhnEusBspPlto9Pejg0nq+3F9clJBNdo5zonyuQxac0t7wlj9vVeDeFS+WZAv ffKdygzn0g+J7LKN8Jbxp6h7NpBzX3ER/rIbEDtv+C4rTOPkX1EZ/dkIHaPR72Pogx00omQy Dj5oS7xz0lRlT+icxbD3U8ZknD1F2CGH55TjRQtxwRVUOYjUqBLDMJfwlp+vckCG7ozso6ce vKLEMGTdJQcyPwXCQ+uk84baq014PBFNduiCeJTn8hvE4aquymV08YmjwW687GTtyKA0xHBo zzexIiS1MxE37VaORcd+0oU+DwEnwXLiElP1q1I6NBBPYblpxirP5TtzfF8I5l7zv6xobSwr 7YiluF2tvkK7BYLp64pn+pyBd9E1d1EDhDnLvBevKkE3OLw+OkEZwa1pvP9q1JXDvqSN1sQF bgw/bYjkZlTB74ts5bGmZEBiEq5IOupPvYGrvdp7ebBM1L3yS5KxF7xx+VgS0R3wUgvY4i4t i0CH8g9MQdoiiFhhm3qWYQwF8joENv6JgoVe5I5pvoZBM3qtoFTYD0l/tcSrayeOSh9jNVmq qNDWtR88fXESLu9RpQFStssHOnPHf2NjZksxQZHMRezlMGiILX6qDNVjJm2PHrr5f6IaYj8q ILKDLVnC918WPm/3/CtpnmjnwA7PssfbHgm8Jid51a4rQfBOQQBv23HmcMTQLS2md5cKWi6p 4Uyo13iLEW2LNuBTQLp3W0+XpsMvWbkDRkgqPeRTj6sXk3ysBQYrE2bbIz80XGo42rs4Htuz GqfoiRTYc+8IapnvqLjA17A3y1CZVtNGJpcFpmPt9KrLox2yPvxRqeg4CA4mudHFX1lRkLlG j6pbG/HOPkp9VaTAqyCVg8Q7Tib0oHDh3IyvceyJuPxLHD3CpNIepnS7jJBuQ0TdbbwgBHXi kdVGUrhpvHR84U5Fk0+JJyQU9g4cms6eCIMgnekVF0pge38Zf+yV771qh+NzaidUVgt8Ccet lH73k/lFaOITcE6taZN+a0I9Kx/lmhE0WAMwcR3UY7h8o32H6DGS8mhZAo/jH9iS3n8Q5ATt gtNj9pPLM4xPt+w0PjcHauM4jZYVzSyz5ogSaydW7yAOXiWCCPvg5pB2P422OF/++e5DplfI z0QKVXgOrQ6Gs07onKIhpU+VsAm3qQNEKZWotJCRCC/yVmVRaQoKwWMy1z8HkUBW8B6YHX5d Qlwd/4G6Cyv9KRxx8156BlIjSmoijSMycuxByRLYpcYSAJmcRseu/xblyM7f4Ds0nz3B8D2Q 5cGdlLuzB7UDQC37ghljrOawafiOFfMfKbT3Km4MCGHyBQ5Mb7WAXQI2FbN+YaMlGOovfUNO ckHrILWRxFgAd5MXOgQvP3cFD2ulpiJoBp66pwVLvjGO69ieeoa3IIVkAVZSS9DnyDbOCyqL 0H3m1EBtAlnkiolae10AIkGIQTHul8e03AgzOBHM2GG07t85RrVRULQZkjfRRXt3tWzT2e4K zPRuMptjUaPtUXwOblkhTcw8CmjdYFEjIwdrcj45b4CZfQHjHnF6GHHYOUpRTFrVyeaSh1tz r1LLacTdGquJBLeJLr+PCxUcLIkpd2jkzpKrzp9B9KeVWONOuFCBQaVxG+ZZtfdOeof79rJS JLO1sLROsgYkgKz/ptTHRkmpINziN9ablI4nWhGuNYkN1qK2t48tPkl2uZsUCwrCRfMb6Qlx +8jmFm+xRSls0+mt+fLHcLvj7InkZ8OXLe76VcyEFd+iIB1fSKJv50P/K7gQp6d9mjfUrZdp Ysr5F7EME3Dg7AAQfezkrw8nZvj1Ru6/8KKmvtN22mbWtCHGIYpUM19ckA1+ZbhJiFX/oxCd 3UYQKIlYjdheO6FVwNNVNXY91WcUvN6xzMKm1dTd5b111Tjucw9ooMaIm2Z2L24y0dbOxoGB qsIFRgzUTu76k8GG1YQllEIz1BvRCNUiW+zYbG+lRws0sS0rjN8alIaw4MZXCLRuvcQUR+4Z ibpcquk8wAMKWY/fE5R5zVCI2mYx/Br6IjQB86pGaekneqc5XV1anMmTOVvWAkwnn/Z3QQdB fcGBcMiOlpU++D+NqM8/8PfFK9K71akIEoRSHe7zWelhAVJAnJWf/r++HLpwaIk5hnCfm22N 8EciiTdvXF2QlPBlIrxfAmmDX6ys4fAlnzQ0XpHA4npP6b9AvKetRKgpSi++DTNfjq4OjttM /J7zLvh2S5iiaMok/mtEnTb3Cpl+z/FSsv6sc/66gNVXL7o/ykEClGwsF2f/gcZSALh6NC84 KlMjahvzOxUrlbyjyuypYlbuuoLaBpHKSt9uz5Ur4Q/L6Nb8rnVs64G/LsZz3EEvdsx/+E47 F5Kpa+Z19Yxu4CtVn+cnz5ODRcWUvg3PGyccxTflioOnL/uLQe44n0Hrm3GnDVcxTHxBQuGL 9ZNjY69xlCPloLDBIrp6gHc9q/ZOay96LCGED8PVjT4CpzXruL6cPqv6o7554e+ltfO3/bPt zJA9kodaIcbcCMYYiqZLMmMlmOhY3in+OisZE6RfKTdDYY0PsuqBaV6KSc8HtmFPx9U7afo6 J13lOvYCBFCStBQrbmorQkP8NhtzcXQZLnmhf2U3FfFT8coAi9Mf4ShSCQzHLqOi+ICRpx/i R4a0+k7mgdOf2/VrmGzaLWgGuEti0bMi5Ewr0UmMAi0r/I6l2to8eC4HjKMbCcVk9U+7QYf4 +ipA5+F7QuuCbZbgFrizofZVEkLXhwsS6gct3QzxTtbRhURLjuHDk2/pgiFc65P6UvDv4ZgD nExvAONc466FHmiw0AizQn2xLbUC+uWjfjubpojSaUHc0c3BLiadpSb45VtgBjpzlKW+jcCR ox6Suw5CoCQIdlu1cZQAeStJX8J1yP9F1Ro068OPJEKYBTmm2g+uol6M/TKEFmL3/KpARAN4 vkH3o6dSlabAWQoRK8TptjDbY1zjjXAUeovKqYwmNUhaTnKN0yzirquY2UQHFDHekYDVVVcl qBBZm8d81MZQq3dxb42TyAHaObVzjheV+spD3XGBD9nINhQxewn2TCYhgbzqyLn86mZiXm/U zr2iQ5ZYI0VHe9VTAIIm7qCjBkRN0VDK66ZKeE3HWyBcd9BiRfmcNYOhfcPhS2bgqc3fHdor mlqOOB/A+6JCx+JSMiopVp1yOwthW+U+rfqvQzKE0szbtYgse8KLjBP9UTdDqQTda5YjXgNh K3mBZiVs+dN8p7VevAsPexiAmune5lRu3a9NWq6Ovcl6v5n1YUCuPNuQVNOB1aIU+CoSmOS9 icCRoofTvDcgdmaa8LdSCLe1u7MQVGDhneah45soUOc2tlFhvQg/jP8u0pODgvka6yNBvUJ3 CV4DRmR1XfgrOSsmR8o0bKETiBCOziNdbb9pMGjAOOakfJX+xZ7MPQN680nk63GIu6c3VOFA eeQkGc0xOSbSWhWVGIRBwTr7NCz5ClWCuW35m2WFRyn9kpY5BgbNTHHGCNP1RtPCWFvOxOHs 7j/mg9MIUy/fBDE6PaEL6C0EDbQPB7GTRYpb844YWSdJeMzRjXxK25iEAmvltXTC6+W5Bm+u /y0C77dM94r4oT4ImtP1UL6cm2MQpAhzKxElsG9Eif94oj2r4Suy46hYcdpczSyKYz4lIN2A 0OTKLtsP+H5opzMDrQusyTkcWAFq96IohtCBrRBJI5hsLJ75QIQSXwTIXFGBIFzLaB5X/0LE tGdFMhy41rmkZaX7399lLGSwQOsmDby2c05RDqU3Zikm7UjK0LzPCfL8hJwwkeMzB/BHK5Xl uJErVPVMU/GArRw+tjBoiB2DEKk8a+04O8Aib0IyVpIpdRxoHHnO8kzsxQ3Dg9p3IauBJRpj qbdp9EcGg1jP+tN94c/mMsC/Z5MESGQUmamPJC3Yy3G0SkbNaMHQ/BbSDLvuxy6r2aWq1xwB YxvsrvoLeK10+I7XqGoQ8T3xNPx1aeVoemCIuys92TFNvtMD8dNbkWKIT0rvKOjdIfHpr8ur EVAkVLNi50DsP+nBiEx/LRyeLa1jRG+OfZewGkAwNTC4i+xvivJpWUMmqyxI1m2hhpcohKDW Its5DacFDlhUROL0OkYSCcwtMQEXfPPZzRwmv/HlCDATb1mMwL2MiRvInebZun/FgKhzaB+Z UARNWULdZeTRHc4ee0GHP5K1toIng3Tqf12lVOB/bXJwGctl/2R4vyRdF6At+GAKkzyhpzd5 uiyQRW0jbHZ0vVkliRG98oSerIObSxJ8iVBuWO9T5Q6ebUbxx5LLVbZQr6SgavzcjghAIqvZ sjfSc+pV705pR532EW8TCn6IQi9ak87OpY39DZKy4pITRUh4qm9yYREP+NvTk35zccgu8SX+ SWLTYhwG3k94PeoniD7HvG8+2V23J945FgsXPMsHzJ1xEwjDlC3fkOMhE+ymAd+Ir+DRKDmx rk9nyQa1uy81ZIuA5HxdwP2Y6PU/wMApK0p0DreKlEfDng6NzIEwvunBKt1uE0VhTDIGdpx7 Dj5XCC9jjM7THz1S9u8ho1DYbUVGXlT4BF9PTv8SD5KgrC0mu1bQbTFMUApi9isM+JMkOMx6 mfGUcX7Pg67XlrACgoNyMihmPluupUdVs06zSBXYTTHxMK++iMbCqhzSrXS3RGZRgbIIcNkG gkK1BZvMtlD0NuXRUiAok84nyYIsGucDkanpb2rxoOolATFSbDAI5s2KP2qGmHuRsZvlyWql 2QdtijZtO74S8PtFRlelRq401TFrR9xzWhG3CrFHv/iwctMsVB8Ey4f41ftfkqZmvRKu5LSX lFBL21vmfcH5f87Yox5R4x27havgUNkwfUycq6R+7mOCr3PzHT2VTDXukLvri7Ucr53X38GY fSRDsU+GB9EvsXeEiRVleINII0YsxVNkL18uW4KoBzvVDr8a4/Rlq9iCbyLI6UotsptioBRN eIod/dSn0PWtm745hMwRUi1nMjsyGP285aEW/4OfX+/B8/Zzt/ElqYFEsedk4sri3beCsc9z DWVuZHN0cmVhbQ1lbmRvYmoNNzEgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9B c2NlbnQgNzQ1DS9DYXBIZWlnaHQgNzA0DS9EZXNjZW50IC0yMDMNL0ZsYWdzIDMyODgyDS9G b250QkJveCBbLTE2NyAtMjE0IDEwMDYgOTUxIF0NL0ZvbnROYW1lIC9Hb3VkeS1JdGFsaWMN L0l0YWxpY0FuZ2xlIC03DS9TdGVtViA3Mw0vRm9udEZpbGUgNzggMCBSDS9YSGVpZ2h0IDQz Nw0+Pg1lbmRvYmoNNzggMCBvYmoNPDwNL0xlbmd0aCA0MzA1Mg0vTGVuZ3RoMSA3MDINL0xl bmd0aDIgNDIzNDkNL0xlbmd0aDMgMA0+Pg1zdHJlYW0NCiUhRm9udFR5cGUxLTEuMDogR291 ZHktSXRhbGljIDENMTMgZGljdCBiZWdpbg0vRm9udE5hbWUgL0dvdWR5LUl0YWxpYyBkZWYg DS9Gb250VHlwZSAxIGRlZg0vRm9udEJCb3ggey0xNjcgLTIxNCAxMDA2IDk1MX0gcmVhZG9u bHkgZGVmDS9Gb250TWF0cml4IFswLjAwMSAwIDAgMC4wMDEgMCAwXSByZWFkb25seSBkZWYN L1BhaW50VHlwZSAwIGRlZg0vRm9udEluZm8gMTIgZGljdCBkdXAgYmVnaW4NL3ZlcnNpb24g KDAwMS4wMDEpIHJlYWRvbmx5IGRlZg0vTm90aWNlIChDb3B5cmlnaHQgKGMpIDE5ODEgQWxs aWVkIENvcnBvcmF0aW9uLiBDb3B5cmlnaHQgKGMpIDE5ODUsIDE5ODcgQWRvYmUgU3lzdGVt cyBJbmNvcnBvcmF0ZWQuIEFsbCByaWdodHMgcmVzZXJ2ZWQuKSByZWFkb25seSBkZWYNL0Z1 bGxOYW1lIChHb3VkeSBPbGQgU3R5bGUgSXRhbGljKSByZWFkb25seSBkZWYNL0ZhbWlseU5h bWUgKEdvdWR5KSByZWFkb25seSBkZWYNL0l0YWxpY0FuZ2xlIC03IGRlZg0vaXNGaXhlZFBp dGNoIGZhbHNlIGRlZg0vVW5kZXJsaW5lUG9zaXRpb24gLTExMiBkZWYNL1VuZGVybGluZVRo aWNrbmVzcyA1MSBkZWYNL1dlaWdodCAoTWVkaXVtKSBkZWYNL0Jhc2VGb250TmFtZSAoR291 ZHktSXRhbGljKSBkZWYNZW5kIGRlZg0vRW5jb2RpbmcgU3RhbmRhcmRFbmNvZGluZyBkZWYN Y3VycmVudGRpY3QgZW5kDWN1cnJlbnRmaWxlIGVleGVjDTwtKYOXUVwAN0DSZ4kat2pMhvDj lYYs1rwrtVmMSI4qScUqqYIPON/KUXpjD/tDxoPxBU0lTj3AmO0umgbqqytuhRSvgj9Ww4OG X5OnZQBQWCt67CykvuoLN03rgjqcyPyvNPrIQsTXePJ8uTMGB3MnowRuPus3WOajQ720iW1H JmFAy1EB+9vKl8fJ+V9w+U+9MSSxeGtVwYJwfJVrN2i5StRjw1W1YSTk3hh9+SfWB8StxkDt 6bhm6pv9vxHvur39+C5bKqC1oHIEkvz3igAWPJD96VsjxeQKhlx9ufLLdGjjENQjRwTIwaFn 0hfoGZ1lWNDsMjsKfIfZM/54FWNn4EGG+jU8181xmUbE/V/AJxqAFA6miQgU+GIl+DeSHxmH eGUmVyoaaBez5m8uTB23D0m65NgxcKaLFrhvxNrlPCJLZEa5fpAoDQUdmmKW6MlUj0EAZLvd DKT73M7h4RHwyZOkOWtFkIcEbbmhkbeK3+KSKPGFlhfLaJqjYe028MJsPKmXyyH6iQET+OlA hWKUh4zHUXAuRar4oKrSRzJjXAJs2J+5ANorH/age33Eg307aEX03ic76CTQRPUjCmx9W8Px cARDllegiDTne3NbkDZ3fKJNwM8JlKVXNmCBL2DgitFFanAJK7TEZteKnMzpOaMRlfa7/6pr ibp5gD9XLDUF9BEq9M8H20raK5c7MocDOz6Ghh8PZj9YqTm0ohpYt7WlxCr2qftiX4utpNIw E5vixy2PGxfZzpa18leTnJ+zhMJEDMvO8YaGIThCdQBovmD56lbh/E6Z43wtNg883jXT+8Pp ZdPH+13UL0E0x+U3o0dpwj/amV1ddfJsaigKtZcFLUFDDfKcQBhG/j8UKHY2Q9mbR4IdSuKD 3SZA6MqoE4HQPmxTdO/R6TPWBBSzCFejfWFVQTwaBIBTrLqjcaeRxvDx97EuUiLH8epntac9 FE7apQstDgJT13/4VGN0Nnaak4/KPwIFfupIVgInGoXQLcvz0ZczOGty19OBUi2h2DDZyWmk pEm+xlTC5h0R/YIgvJ0Neg5P18cBcZ2LVr2xMoTH39lyRsiKjXG+bY6WUfyaVM8jja+2X07+ XP//YwnJs+nfJt/xdEykPH8SlKrYOgHQEELMkHELlHRBH5EbzQxIpxRk6zFVaZ3Kw/rQQf7g H51SW86ve5UrmF4hfDTB06BdJ/aKsbeEhN0UrJFZetUAdXcPlHZ0YcwHPmqTa5tMaH5eLu76 yvglD0U3HVTmKufya1H42vo6ptYWH3r5AWgkAwF97r1oISuJ3PYFw0ijsKLKaYbz8rZX3j7n gwHQZ7fp/5MjuvD6iSUWPoW6K7Kc5O4tInkZ3eUJgiOH0xJHthgnwTQwbCKYcPw4JdaUYKrA qS3W046EOMWIGehQ3WhpacFwciA8a4bAg7RSHZEKjgNdQMYp3Oz09+sZqOOV75QU0gDiZO50 qUm5LCoBl30OcxGduIHbvuABK4N70M9/2KCyCAvIW0eKyCe9MnDJcGpj31nKU02mf915wPcX bclQU6+pEi08AEwxfM7cSJVDmjAyOke4K3NFDJ+KXIBnvlnuvXd9NkGdvNQ0mrx479H88lLB k/UKumIWb5neLhigD6jETdYpOvwWlhI+kPWt5TpMRrrpgAVqQozonBF6pU1Dg7m10pzV9IAx tbK0JFNT67J6aD+qr4JwGnVNXlZ9BaDdPnj8WxwDRWsmScdwuEEU/YMQ/RHLm2SEd/3hwq1R X10z9En/Eue5NTHuz9Mz3FbGdAOyKi2glFKTJO+8d0cUUcs9AQzYYIrco+EXj9Oa2zr9GMyM m8rAmyRFL0GjXc9rzUIhlik9N5DCHzj4qlSocikme4mulZ7Nau8v8v3WRwYA9eZeLflSAAIS A9I+evskn2bRv36cRojhCA5jJ0XaKeM0wb2BmgtrqWHIkY4aQPCojK7t4WguG5SNL6vvhMxK 43hOkXw9MfZmm60Qwwa4uGLABz4cMCuZkDci8xXIyPYIWC97vv9Q+7IvJxoCmHgAFIz4x1UV jHoUBLYkWJsStSFCse2Oq8zVUH+EmDd5WwSvjvkrjwX8L8lXiKXZORH8JtC3j2dDFBzVXLgs 7VrHEVlt+k6EyAh2tg1rEByTBh6vjT9BTlzIV4CZUz4N9QYYGXmYZ4qPdEZ+yOKQbCOspNf/ GkKVHVxvdeUUg4Y894zFkZU1sW75i/r8QzN1nwFtolTpwHrKFoksXzKJKZiEQ3SMyBvVO4th q4g/F8nOQUZ29mUQ8z018R2eSckxY2ma54pifw5IjgRhJFfZQ54fPJOctPF86XVm9wTTRSF9 nNIRtzldAITBCYuyXgwgwkoirdYKLNG0ZLEFk9jUUlH6Pj7GxlELa+fiVyG+35wseUO5Vn5T 8wipS3rgmSi7/WbATS5ISHBA0vPxsaQmjFi9qrWWV6XvO262FOsT9sDjQXiefIsENixIJJCt fdPIilMhFbDzzfXACGg2cx1kim4zaVQ1WtxXA4+S+G7YUJfn+dpJGa2rurtkABlu+bU9oBIB jImFblnORo3UwXWKf8pfSRRhorUXqimXL2byLpy3yimFQltgCgRuZ0/W2ubRDCFGXlaR3kNs bo031UCUYiLbqisTLvAg1wCfmr/6anxNY9NjqY8DAXPg1QfY9R+HQNFWM1spyW3iCWupU/// PcZatNbY42420rSUf6z1B69hJ8FLTVW7NTmIxWloeadCJX6C9tSEsfJyKXZMEEjatb0GaHzX e4F3QCSjHcC6g+QD4QR60oX/CGPtaBAf3DikuhUag87PAXMAYkr9UpSXXBBMHnHz3USbOmSC 5TsHcS9qEulJ807Ra3eVrGTnH7cj7xPzYeF1qizvgwzOKcFUt2S2yavRjv7IuGLMuhSCa4Pb wDd+LzWstxSdt7OzKf4TwFK1bHs5CtSwfI/2m7YNkJ3jM6t7td5EShlupAug5a4X8qSvuXlT bNv8wOE+hJ4bvW3fDJ9MYww5yNJC2nBW3cVJgjmn9rR6woe2vLgiGa2FYmc8zP+kua0bPrlr RLEDXNHfe5OzPz/pTlmj2sEUnZyeNadEzZmb2kVEwW9TLQlmpLzjJaVZpN8jolduhQOaZW3c 8uTgVguZXmWqKmfAclgnecUpYyo9mQbEGpTevn3aEIm9piYnb/HnMQzz5yHEVOvCamde7y0K 68iNvk+A/saoEwikhieNEhWlTSdREudXLL6ZNljymRgJ8W9cGUb3CrfiNdB80+COFjLttDwv IDwOTnR/MU+npq0S1IpFfiHHvRZAIrJiLNHifm7NxHlKyOPy5UpAhssDza418xmqHMUb4Nas qWNh1Y2fBikZIfRhE8wZA3LBK61avtTEMoxeRXDJGtDZ4xDXG8dT2wpHx7/DeZ6UWDk2Tvn6 E4MGNpT0kwsdv/ThfqTZMN6t18FhGeno3D5CYyI9puMPh6szQA49K1DN2lmCwBF9rlyuPnKZ jcf2UarEloVwvA5+dbFdbzcgTW1ScendcwdCLHQSI1wvniyIw5kttxYSvYv5xBmq7yQ5PJT2 wvzlw821DM1A3zjYSQCSVWB1GsdZHEa5qkmV3zJG4fSxBKvD6Iq5F9rihkq6iYmsHre2RqrI 5WI8/Sh7c6v5hdyZ3dOyz/TEMQWBaTw2IKxv9qQCeh10f+Ql+wvTQG+0IL8ALD4MiS8ZMfHD tl0V/tx6pD78wuQqDqUgfRI/auR3Ds6Bh7Dn4n0Te3OpZTOenU6USMV4iL2DzjMpS2zqb64B 9779kFlGceNfxWanh37vakwMX+jacudJt3h9mScJVZxQBJp8+7a4ZYPIXRktGxKV6gidKZl2 8vSfcXztWSVw4cclw6dgAbQ5prn5lFOlO0G8nODUhSCrOemZ/6Vog4G0RvztDzjPK4Detmkf 05y9c8D8sLjg8pzEN81QF3+5a+ybpr0YaVQUpoqKaq/jbbIUwZThIkAOMzCeBabG+FbhCTvm 1/loUPv0Gex837F2k/CaRBRPy2Z9vOxoYEjQtQMXZOUfYc9M26waNqYq2t26SvGo0epzfBWF WJvDeCEjKg8nChfdM/M1q+W/0PxgBfwvDH/7qnM7MJIyQ10ZmSLyVXaJCfzZw3KZzPZUEo+k YW0OFr9VEJgSbDHp852uCVvliZxH6a35Uvo4J6+mjB8jRfza20rc02BnQmgdmb9/Qqby3uXb 2yTBE7bhQjDwbyc2pMmyg0I3dhhZo9O6Xui8GEVn9pz9E+J8neUbiyZEnweJdhihZb+kjuVk 6m3gI5x+nzM9029FZPcLIUG70CNvA+U4gtq8cIY+D5UgIY1/HJ5q7PnmQ7FLxeS77dndnDgt GFkoVd/sjhZJlDX+v/3V0QvDNz12j9wax25EJ5EB9O9MRKsKJu9h4i5+fGNDkTg+krn01Pkd hH/eaZircPL3LGy5PKZHdpwyZo17IaitJKafmzhF9KEtlVjiU14WwBS8Cg230vAXh1AnaWQ1 KQmGoubO3BHW2aiTcNOYrda7S9EtlOr+KPSLSbvSM+pD9yNL8o+rEdWNkXvI818ETBPq799b o8BVAT5fBcL1jOdlEjGybcRM3/Z7c1XkuMj+3x4eSCy8KU1J5EdkrnzUz/i3TEjnV+CeXuAO RaRBsN1anW4lpavhq5i+LyIvScNLQpYY6MrFFgyavcOZwxWrauD9NZNwOSCO2ODHKwldMbim g51Jv0uTIGmkqAWNlNlHc04nSNhP4ZBG5N/LIcRjpjpZmx3u75GCesuyRISXfqIVTydSIOz4 cPOjoOeMhbvm/YMSK56i8abcPaC/LfCPqomWPBl0RkxhmVPF3iwCI4Heg8CfQ7RXbsDkZanL rO1ceGa4y7yYRpPIE6HXs1F2PcQb7umzAOmz31AX2CneO1lraNz3ubR8AiJJi3T3qBx2MjaA a0HLpn+Lluu+J1BIJ2FpuGIZebXNJG8RUTvjdhdlc9w/Jp4CPauhBXhF7BXSNBoyGCbEpbE9 P27C0BFaX9nFDOaEeBWCgKkbUYhXcLKYfGqQTCRKqK3pvfWyKlyAAmXIQ0vCMiJOKvhICgNq nxEUfBIKuzmrPCiJ1q33PT6h8SX/n6gssPre5e0sf++0wnQxhtaoECcmDhzvD+b/ap6BHtW4 IOERu2rfGPy7ITz3SKmRfPvs39zZg1oApmYUXwzMi6/6+HzsiarQQzyOAfytdpPjNOR2DUj4 q8zD5377r7n4lHqt8Kg2LWNQDLREyF5FA8V65bgo0GAs9jbhdO5cMhcoQrER2/8IcMUKZoPm EEMJlJ2od4NaERSW9HjgXFKi1DGHTnMF6wEOmj2Gf/krMamWU606T0xo0uw6WFsc+gOOa5Pd QPAQxRrSy2youKx5KcbYJW6EpGWz/DHWEIfeOTTNi0cYIWlWvWmiHoQTkBH+O3wtkEkHv1zh ThxLeTQUkgqF4//7FPR0g4wmm9vc8FAKVZ+A81xd2eJRuO6CWJ7JY1QPjlWGXtDNxlghHHY2 LvuZb2FlbNN6SNuPCFdOescfbG4cUW2v1aFFo1QSugxpuDYbbLAzQdB5KxqB+B8vHP1u0NME qNiX3U6XldV9qkBI8i7ahqKbqqpfkWDtWxzMukbjk07fsBZXSjhelMrM2jvpMFk35IRa1EEZ jyK2jQG3K9/1Gc+e5iuS2GrT/WJeqGO1qH/2wFBpVVTz2+VtauUmTYUhlav+GaXfASud5HRI 0S80dJciW8OhOyxhh2zM8VgL99/BTg8j47Ia/lUaY8CDfNTSSWe9rq07SvAqlQxbOsHs+RWN MHIyqg1mJFJnIYPO21bNWpth0EbETjYMbl2hR74sEltdvv9acoNlRgcIGINE+CXKXwJlA5pu ndzWM6CsMP1teEZC0W/Giv4FNguY7XfBsZ/N6v1xfug0Sq5XAyKMmpEb1/mzNGwDajK9hU9I vUbpq+K2Kz5JEvjVMSv63Ug5ef0c+6D5UGPjd/9y73F7uVTmdpvJIO3xJaV0gwaR6EWxHz6K dgfXLhKLWrpPJylI3CP+FDvk7bFNMip/zO+XAFmNGo3oQ2hzZudaZPQvToqFuhG7DBYsF54q 7bCgzn0W6IdEwEGHxMpAOXjfmRbUedAaqAGyStCwY94BujIEi9+CKnKyEcQIHbBrzLT+v0C1 QpR7v04HvQ0zCqJruGWcDEfyBimk4mXKFi/M8ZorOxd/CzWAZIgX2YMtufBfsVXNqCasQUel 2GaADHKkL1m4JkFKDxhkN3x02HjP+deVV0svdFe3pg7dbDy/CH+FfscIEB1kk6IO2uJyfgHk 5OKr58Fk18gk0lp0zEhYDJi/a46KSGJ7M0VppcZrr+M2f6oTAdsYuneVzom5PD+SvFPjCDV+ aJXxQG1fI91bNIRsfMAMp5qTqVQk7EHyQJN3AoTlKXg8Ut1i2a1Ed6RurncWq2KbuKid77Sa hbwbc8bZLZ7IV63tmz13tP7DocePJLDOmhcPuIMCQkqMIged4+XTrpVUap+o3HvJHefDgY+w s17IQZUBr6WsADVPaOGE+Lli0lxJkQYswp65bo2ZaseQuWWY1ANyVmqYkxnfJ1Azeb0YtA+o 6dYbSj6PCdGGi2RuUNW3MOrWmm7oTLCqVTtS4oWUVeFns39cIkpttDa8rbXWdTDMUfStm745 z2XKaDQnXXgoWsKDAWFrnaCFI4zGIbMMQkFcna6Lz51MNqUufyj7PyERfSndfgq6F1PDcXyU jezP1wpvwh8TdQC7XwkyNGTLX0XMuLtjgfh7yP7FtE4ykzn12lLg37mwqRBZFhp2DSvqQcZt txSAs1Ef357sjpZ/yjgLrkeYTuQtkw5cqgfU5tf3wxzGw/s0SA77hsMjSkwk9DwOKb+et18M mFQYKMu8KKLGPNN/e8WvKLvHN8LDAcD5EmJ/aWS3FbmSJGP2PSEoECpofBzNrGqwOJo6CqRd BohIW8hJzOzvcOVdoh7T25yz4r5xtebKMMhdVAjVmjG0xtIc5PmbviR+6Hm08teNWZ8dm3yu lxsm2WlVmX/GMEL41ItbWVHmc0iLAQZvhpaiGN0341jO7sfmDGlTL/JsEdiuN/vfNDRZ6ZLa x9kDf6epz3c+yJ2mhzEMZwJHqKmcl7pfHLbakoWR4+gxHalaYWBJeA51lN+bHbn5k4s/2cUC X9oj8f3WDyi+fbVngUr5qyh3w5H30eW/ZXrdW0txaNz3cG0TQCkG1Ssm0hnrRR5Q4we1rq8E PEA4/J3ZnuyMLp/naGgDtX2ffuwxQQdCtvhI+nmsfAXg2lAhYQNvfaLj3wgF7iMUHgTqE/Kd qTISfnHrKa6RqByjd6Uk64Zs9/QfuCWDhDmWBH90Iy0fl3sTxwYA4jkab3h8q3BfD21R5VBY N9RyiAaXcSw+Y4YjCUo8+rkMyquWd8fGre4TFjkwBEDE1PDsAHwomrUeD97hvQ+C1h3u7JUx CTDEGypBvq0y5kEj9GAdYIeJFatAASEkU7DlZ3cqRww0uYWimUycFJ8n17DHldyIjJzEf/1F 4pkAsk8S5htFfP/finkxAIzvVrm0SdJUokcdHfBnFqzlGfBokvGzRBTytY8tAXJkooRaTSeu ao3eK//hqeAa++9FR2LYiUHtz8fyTh4m9J6vykrDJf3LGIDQfJp5HJSPAIaKMBCtPTQJSgb1 LuKEady3AYACLQ9DXSKT9sGvwQktv2zY9rCvr3FQWHVGeDPXXkJILp0cEkJ4u11yDN9HTIDo QsGFd5sBPnASne3wAjuQRBbO1JsNAFF3+J2i3JzoJS9SBK/LhQJKLa0KU6nMZ99LTGhcdSUw kpeBiHpfq25bMpzCmdPIYjDNkuVZ91jbqjKzlwJLzJzLlwIU7TajIMQtWCwf06/qUgjDDZCv vFM48k/hUl7fzZIk/+1EVo77j4ooaf8sCcZxsT9Oq9vA8vtiRoUpC9iV1WoN9U4qxceepgrt FVciGfA7s9N+R4jtzg8TntsO6zdqMoprEleftDqnuqW9GnW4yKEnb5GSBNCGhQhIZf5WGjuk oTVzU7c5lKqqnhfJs5lddRupNCCQgnpUjGrbWxg//QqvzRjNpDw+AfLHuE0mewFPL7B3byoc 5Yzfg9WrMydXZ2rlK0P6oWR/twHjzHr2qgsY6q5YRtKCc+LvfWZJ7NpHHeP0rGvjznEauapd VMyCpTfkhFlf27D5W2zRhKe+6DxiOby3KlOs4ZoahNBd3WotNcd++Z6EtaW/IkSe9wR2PVct xJS8DFNEq9UaRPZ3sbnzwWf6+j8bLRkjnoI1oK6pbXB1LlEjg6SbObMb3MDwySmyYOCn6eYE pLT8Z9tllBcSxq7vavsZZwyQrXHbitCkNTv2YqQTle55tiZfo8/Dvdzw6GYXScliX8VW0sfk BVQu2TyLiKYnC74Lh6R/gkwCUSshKlMU9PUVEVXMAYf27ohnVZ4BPHtAmL4CRVoRmZ9+1A1u tn06V6sxALxaVXxuJhSaBqg7uiDakTx1tKjVDvuXjg59eeH+QvZXqt6ZfzmbVVDlN8vJyg6b YFxkThruG809tcCS7K9mxdWKjQZiEeQcg2t6+YYPZuHLr57Srba5OHG5Zykr4KosvS04AaX9 A6c97nvdn3zza75inxPaUchfcA7uN5fLFWST3DCLlm/brepOcynTA9fBxBlK1LCmmyalhhc2 sJsanQIcV/tfUL8dn/w2gnSkDUX7yE+uR8BGcPWZ30Wft+txKMdJmUmPvosXI6Q1Y/1r4XrT 41SoYxBMLNE7Xlj3LQb99JK4cZWN7Q12FH5JWfUExwv9whFJOxFe3DOmblBM9+oId8bpmKfR a8batCoj115sSLKXD9BkBDdUTUj9O0k8UJqg9Z2SdHW4I2qgrUUpL+GlZrv1DE8T/w0KH7gd 8PMzWAaNEwEsa4mk2YUjlv1tO1XBmzdOv/ej9nRpQ5FQzhiamVfpnaNNYWiwb3wJTbVJKG/c hP4PP5fHrOiV12AbtNnoaGJHX72DR8YhJXBt8PaIpy/6pKZqBQBMfuHCF1+wRtsOkzoydJFs f1jvAPx9y5MsyZz8ZstF5vITuz87cbqyZmWeD0i/5aamYkZI97adaP3gy34DUTyq9Qp2LTy3 q4LC305eU+W9NrM348itw/aSgT+6OTLezSeButkuJoptYP8FOEqr+6NGzZcAwwHuiIjabbFG m77OCk4e0zpqlDF35erezt/6Zj3uOJTed3mUQIRvur8qeFAuOGeZEKIPmrPht4iRv/45Xgfr 1Dj90Oq12DpEyTz/0TCsrt0jhyvSgepgiJSfcWw4YFkOQU4ynQ5JWRQtRjFYFGIO2XyErkzx 8DfpR4CKdKSitsiP3V1tVICY3g9vehxf35nJD/q9ormKhFWtNYbiSIR6xCnoZZJb6qGZw+zM oZRfVitLCs4GcOAoNpMBc5s0VYsbkwSHhlJeqNvhtWTdL2bv9j2oJxaSkYggMY1Z3OotImqR TYM/iq+XNUwFvt0xG3mWYEnqu8oQRLoJkl+w76bNBUQpVcEILsSWmXvR8ASrJbrHAdlxsuJf Ho0VQxbR+wdAIXHoFNksKgSRCg4U20N9+TbUVV4092kHANs9s1HdpKwqK/iu6B0OuRSlEOvS Lk0hupXNkLNQIYRozGgL042q/vwVrKqbkB49n4WM71q22uXb+dD1/8PhSTFbOsPPIBgDsnDB gLtXVsC24ch1a5OwktLP4tcUdhwiCsOyiwTm6eOihywMQGpLsG3JEo7YXn66ZeEwYaNKHMho HZZGP1FaNDvbluunw+1pfP7z+aBAmyVILRqVuDgiKfCzMth5nx9hgiTmAVHCFwsNGbAurdlT 3Bv64f+sZyhGP4AxOfDKYd/Cs1EDuLQLj+TIRwhkKSrD2jKnYFq94lYL0g7iWmipTTTbl6iZ AFZrS+wwsOnY53JLAESwYH167xt4wd0fko/HU5eDefsCdqYzNP5ir5A1v44XLENC6RBW3DNq DLdKSneFwJgDXZDVA+L0jTeRZqZ1z9r+UavLirmsdK7O8jM2xAE4KtJJebO4zQqC5BfCZl/V DlXLcPkzdSwYL+3tE1A7gieFkgnqwi2AdVP922yZJjJYIfa+prn7/cBPlKEJZ5IjxxEH37Vz +L0rR4AWXKRBffK5ZpwGzR31A40U0kafdR63mnrxJx7Xb0qHsThYam8YS1TRCPfxSZqQ2w3E Tk23hLC+AVuJnYzPL+6QXjt4Kqq50Sd2ybWw4IVozctLbH2/YbcvwO8O6d9tgDVc1i+j+vDz QGHQhF3jL9JFFQiD2zTtsN7jrNA8vI0pxcBHYAMlsl7YDo6vf2xUNah3db6Z8hzlb5Fswobi GgiQq38/ydwyULP0fM5TCXNrHeVSipigv3jgKpmtxThHBrTvZki2w5bvxkc9yE/pZQB2Xfx8 T+z6wP1qRywPw0PqCNuJ3vCPibRLpeS+HwH4B1j+G0SFADtYhP0+8rzucCEjZbHJr21uqVjD EoJ3OZY8+9A1gBAIMVfqRJSotEk/SbuzeYCH8rC7eQU4NmLuzpo5IFEmy7ZhNCPgPdr1AjdI fNNDZX9muytustKQy2gqs1/jb5b9/W2iNwhTp9nxNjHiw+N97qFWxjvYNke5K7mzsrvDAGgU rrIlJLVsIIRSPTMx501Pj7GIasqlUJw8uaaN+tY4Av1xA0Hc6IuMYymYhTa3req3vxm930D8 xcxw96ps0XwcNTElzDEm2iC0a+AZzZ+gvHrokQlGb7eI0sGkpPoa0AB9vUR7jdt7tJBSSeiZ 1g2vEOUYvnN4KbcZPyxzsEWzTDQ5ImXf+OcLXUeAcnrButYeTKKCDn+WMD0v7tvnrqKGevYZ qySDzgBlJkBM+MPbOEJtqm6Eqc0YEM7akOJ3a/6WSnDqR3Pf21Jv0QPmI/JD9R9QBLKbnaFw jdbI2uQtP574V1FnorZb2xpKBEgfgxyo9noFETEhlIbu0p9/fZfz7AdeoOU+PiAqrjukTCXR D13YY4snu9skx3qESeU+i+Ryxu8A2baCkS1T1JhBptkIUyWV+PQoaooBt5LY3Vv77MOOfjtz QMLirzUwjWgrgISXEwUkM4hYtCaen+ly+/YCH8Z7bi0d2x5yYGiTz0wh/Txugk6GNvLjADfj avN0MDSfVNUxT36HKe/YfQsv1sb+8INoavQwf7CYeEFIWUUmrbWr3tjNL/xUOGrbLE9ZkUXg wOL2O1XCBf2XEaqFmdMegyH7qO4E7taZjNS6NSLsIxejWocdbP6zW2HiOgPSGr5qB77eniFw ccUxHXZvQitXZtgqvAJEsHeftLV3/8OkMDvVjBvxmPMdn+7yKAzssmzdRhNIJXZrzrz3oSC4 P+6gppkUt/0HDJuUwwExg66FPwvjsjK63f4+IbJUt8JjsGfMH6cGU5/DNxYCXg+3dBxnsK9q 3v8e1008uAYLAJ2UrThki2u0Yra1jEC+Zs3/L63b3F7wUSsumDck6635z3GYkdYUj3r7DKm1 XLLTWLB4u10MnepUwhvPJQiiXhlbV6cC0WBkEbG1k4XcPZ9Xhqw1ATtZoPctnp0fLy06g0ek hRyL6tIwrKe9PTUchFH1YKeDFzCVodJRrp0NkGX7pkMELszRYEYUKLByDOQqXLTMVrXUv/P7 YqMveJjXqa016itrYS1a5Yr9JuIhfnEc+00OJvtZgO6pICf3u9uU7JNAgiO0tbNXs/P8REdi n0Iyx007ctoEbkqhIgo3ZNhSTp0CqIb0otMeleUbAGCeBt4EKgFK5jLlNmu4MBlVl9NvCnAJ FZ8QtCqkPNQkkpjXTkOfXY/mcCZ5FCCT9+p/4TvllngQisH5uGJzAX41yHmPk415m4/PYN9r tooXhga4sURKq8n50cDQvQOecODO6VEA/lST8YWXgyM6sqGpJthBuxL8uGdTzKLYsjI+YWau vt6Q1zqFbx+H4AgHZuGWx4JE8p4sPZv/dMbOVQBoZr/TajHJ6FXII2Hc6FBE1aNxN0jIwqQN DpsoLgYrI7zKCmIVuHpCDGzdeB+BTY4C0DFkAn0zSbllusklwzYNuEc5Ma+M7ZBc1idGzFZ9 KTWkeKRT0Ogi6wsbTdtXOtg1Y0R1O67YrVeycVJdi4mij7MpTd0K3JHTvGuykr2V9Np1HdYY YlT7EjjYQpJl4yVZymUoNr3jwBUZE9Lm4MEvwTK4kKKdqrExCRllUj1bz3twohkWCeKbJew6 vVA1zhMGm5nE11K0KwhoxMuS5tUEyDjeMTEJ8Gm1zTnpJm9/K4wnLpIpMDHdtBNTCfJrVSNq Wj2RD8Qj3A09GdnYc4ptS0xAInXc4WU3wYaR+IXm+3bdjTc/Mwcq2yMrvPxlRe+cH7Vbe1FR xD0TDHePQ07l2lwyVTTKHlyoG940KWPZ/d4S8eB3ly9OukyFpK9Z/Za9BfYycsNljVJT5KNu VpE6cup+NYx89Wwe+XwQJHNlKyw6xawkHMS2g3MlKNVDjA6ehM/hZvWMwacHuj5tuNtDKE9Z G/X9o4Cx0qfoWCUcHp0GN2hcKs59WcFbLn8bqESGTJ5nHB39+grNtVg6UD7RMXK5PjT38Vbo rmyMyfCInEVN7pphkC+wgyUNQYw4PAd7ahZuHU8nHuOrz43w2JNots6Po4BZK+Stom0vKKW+ GOoGvJEDPCehAL8VerKy+MlGyRZZgGrWSe/U9cK0SWABS5/pRB32/+Vq8krENseFh4IovIOl p7P0PDCzaIDLOQvhY+FllIDkplKIH7nG/CZDCdAaCceVXL4IUcNkkCu1WYwbkwn8whEytFlY SFq7S8hcK/E/U8zJjdPft3QsOJiQYVh9DzMb8z/gWFB+hzUxkXps1agrWKIXIFUqjagYN0Cq LnGdcWUN++ugEyRpTzN75rIU3qCjqwGItJy/rWZGXagEW6LUXGiKzeWneId6KLk58f1btq73 pF0n+QAl6XaANRs2HHjxgdQHkZwW6hPT0g6lG3wJ2zKDEIM1JjJcXf0rONwn5lJ+dZi3v45P EFELa2PFgPhwPLuzyPQBYAoJAQszn4lGEBvIRtAFiXWOGS5oSHI7FL3aFcToO37ux1UDjCaQ RSa5cD5uNdShl2g+y9JRP6B6Cyfxzbl9Ytk6GkmGi8yEFbjLUjW7GfNhQVWgwX+qpBGtkt/y vtTgQiTd5Tk6Lv9Dx5T3dARe997/SLlje/mIlhJi5yTAYpi1mMe7MV+zRhsVLbYfmLwgO5QA zHMn20GxPfoHLGmcoCAr9j7cwjrlwum38RnHANkeXf9EoHhqnegSQMMTrYunYaz9UfUDzOy8 YDEk3haGbj+BjG1SHlHHnuP7hED2l9PpqMhC0WYJ6ek1QWVIDCs5YRlUAYKMq6iRn7piPznG 2h9cIvcVgMv61LKQkeX1qYZnRtg8GJ8hhx7L0oH8LMNrrs+3GVAOj75GZnkboJ0r4+o7PNVL JmZiOvEKUw72bVHyBZR2lAE99wtSKbSPNZqHGN8YPBVSH7nfxF0id/piGCu2u2z/qagUWJ3G 32FzC2JfTikSZKdyPDxmYRVW8HS/JB9PwajCLW13NU8XELIEe4xvqLGhzSozsPVYo+p0XgpQ DaANgzwq1voyOb8rrysP+54bUqgQFCKYxU7hl8rv0SZA1wZCIhvKoc9kSlZvXFMnNJsdsOoW HxrbrPuW2CjHy4NVT5LWF0U5BqL4m85rx70A7ATCXZqLlo/P50hP+Y3f8I5866A7e1Xlq80H wNnatThfzGVo7ygYetqSGM7hvWCbl+bfmpDtU+0de4vROYVwJTrspAox6dI7/RGMT5QKbzo0 /6YmPP6aEdGht4s1WumVBmnWn4GyEl+X5o7bq8h6851x/8opsqQ172/wBF3TT+Ra+3tNrad0 wJvfMHb0+KFM0z9A2TZaU+H2scYfd+z98gHe7dDIG2TKNMK2ObIPllj2U6JdgUNHgijeCDpd DoBwq2N/hdOpdoIuI0ymkdFtz4XFTjqKjtQnqoCL0e5Jl2hNUsE4+9C3bVb5UwETSCvt5hLK LUZqUc1wYsjF7bdWR7+k4Cf8lCh43hVA3qRXvYacx1AaKfNtbS+lvJZGcLVJi4qPNVsr3CIR NdoLRvnu5IskStaCwIaTIu+vAHVh8MOXvi7xWI7NYwURoS8e0Hh6FCph7YIBRaXBDHOYJzPV P6Rj06p3xeiDUl6ASmj/mg/np631TJhExPAgW1f95hBdmYr1cOOx6nEwf5Zx1OfZRoZcj0Tp paHPLYTTyp0CQBBFD62FJAWi/UjOX3RFapbXdx84SrLDyRRbrSUtOTNn5Hc/klxnqGCKH5Wh 8CDwJnnztvA0RKLU/5e0u9fr4nWsRqE5t9M0oXieEwKWdEn5t1/Do1N8xhK1GNWb6EXk7cSa rFOl/ygOJPlv6sqHeMnXTrXNoipMEC8m+ptkqU2p3oCu234S7Xu8T3NPYLLv5jWJ2aGllJZn 5xeuoIhmadG4Fu2a9j1RhK2jwh0R7faw40Iu5mkKis7gokDdlS0OVqWn8tV+m29H/WYk6QQ3 WJ7i2DC1a0/NGVRFFF4VSeC7pvFlVdmfgHnjHb3PeCV3n+TyPbPnZmUbw0D3iIHVBzLYPOpf erRZlF8l2+S85m+2UZi7bZ4puASY+hsQF80T0o3EYjCDyK9TJGYKAlPj66i5BFLVRsstALgf sWQAQJkby3ElLw16PDjZ0zBCEhLASvjDLi129lQF1HxyMIrX07uXVHGTubHK9t4SGm/n84gK AwJNKEHW9yp1ewGspYxq612wNPBRzm2QoCH9am0Mlrwg4ArAdmUMpV3tQi4NKwxVyU08k2kq vzrsgg7NHlJsArRfhQX8Pnx5ZF7mS075WsaPJnVoI0oM21yILU0HTg0zoerI0UM8RMMfcDIE F91zV9eNATnOoeQJXrFaBLH5WVLVOCf/ShARBhV+SNhpfIa+eC49uDkqAojr0wlVo3WYGncc s7fiqUb6CW3PNbJpz5NQ1Nz4UMNQRM7Q8T8shGBHpGUF3qCY8cNGPspoXbz59EDKQYyynZw9 Gg6jzBoUkjxPQ4W533TB78Lh0/2HrT6CEg9l8J0GrQOxp7yz2r9wI2J5tzOUG88U0SY0b7AZ Vh1UrJV4SS3hbUBzFyqu24fbuqgwP+gDNVfIHwHQY2xi4WE2p9r+m7212RALtRfIALIJ8AMY mLTvoSZP+4j02MtQuUxMzAkdZ8Kca3+vEIeczobcAkFQBFWUr/LbZsQrMdY+SbHMjqUq6zqY cfijucwPu716p17NUZ0N2ZJaebkBIPk89AahMuQcFPQRZY2LtdF3YnrWbdSvJ5NbZUiLQpLh wS3z8NflbrdoJln7xOSyU9z5v0nKTwYDqGO8V9lQHdtmxqMU/fYp1TnGjnePshP8Mry03RPs gZFUYOwWE7xllWSEeaiavID95M4yWpN3QkkZ+1hkEenE9fRLpUK3KoUJP2qajaIKPbjH5Z62 cfHMP+LnCyjEbCrcUXud4fEPxwI46s4xsNK5LeX1yA+ghAwhlXprHQxgGbmEUZqZe/I+kMxn cuXvdb0V++4ARLFasUUevcB+8I8nyP2aEeDkCOpDwmxvOn5xudGVYjCJTJv+pB6/HtEM3t25 UqaaJh5P/c4luqmgrjpD9HxvUFe9zeXMejIA78tl0IyNX2N8psvCj+Y64YPXFvGer/vLJHjA LaeZZwrO21YrOHES57o+HD+FHVCMQ+gdPBU9s17CSAjmnVS8T90DoGMlZVpNzn10+6UeKpQp 1iywMZLwTn6YZ+eopAnpIr9Dk+chpepppN62LzDHVu3kL9fYNa07kXAq6Yk4kuoiAZU3lNM1 cu/1h8nYmfNLgw6Afm9uPVs8NQ/5LCvFJ9Xcb0mjk+YsZ1amCTsFZ7ourIlRdn810v5tVwRz /qhQtQ6xfV9oB/SQiGaCtq8ldQflbnHD7lz7pURMrBv/JLtyWpLr7RYx8smdZKelGPYwmUTP WmUAEShqFpPAoMRNcZ60X6wD4OB65xK/BmNvjqOZiFXqi2ZRzlT3REGc2xz6Im4AcgfDNnNV 9yOILIKfX+bGg02RDPgAjbk6N/d9Yzvh80E0jHBYFtTr16EZS5cn/F9+bP+VTwJ4TJAQdvIb H/EQ83XLFajGguc+jPgpC3v5Jzo7sKKqmnrLa12toloLF2b74vIVBl7bLHR+3cLGSRbO0sna OvQBs3ClR/yv9VBJwWR4ciQ/CRzHrh5VccDEnDDjo7nkfDuzmcJ1sN0+Dq7aMlvSKA5zpQQ5 0jgR8d6HlSDGO1M8/+998f9Y3XormO6xdb8apwQpt/GwfbDe7lFsT+YV+rtnJa7gP5+RjXQZ iDEdjhbFAScsi30N17nErLmDMsXhUGCR+W9jngQ+bkw857wklbPpYIOI4+WePjUKMOmmMfKO w7nJSAs73Il3ldrL4UZepHYMI74UXEsI2mvPy+0divH1/l5ZmwaDqCo3PSjD/rf58PmUg/N3 oT680lj7OP7487fuNtOPx2Nfhic6gWfbmOHFpYpGhn4d4aZBG7nUmOj76RTf5UKkW3OgS1MD Ei2rZYtdT7rnjNp7m2PdhoHNV273kmTHljofiWyvCSjrTKrHmoKYd4QoJfmw0+4UIcWiuMy7 1hj8BKhyigvKgR39zRbXZhOpilcJcrnKGUpcInDoInAlgiZqYOgSLg4KWg24sfJ1l8RsNyKX 4fJnCRkLJcnv07liuiHvssjm58nThkNYPmJOdSddPTh+HwAYRy9hVrDN/MqxRqWK5TSkar4D lDpcIdzAnP/ImX1f9VYkRP08Tb5vu/6ZSdzANHXR7nY1OQGI4QjH9fkuH+M8+2+XGE223H+c E91sDkRFRpoAe3zwAuQo2t31KKjuL4Xpkp9fqKfwMw2NfhcQxOLuyI64e8bgUg0a1s/IjTbm hTXSqGJWZk+Z7++G2rylbzTdh53TW+hLSub2oCoptEVwfkI0ts+eoCJ9TgQI1kFIAn0/FB7f ANwf1JCEfBdXfUz0Yyx3Y9kF6r/6V/xSgl9hAgKJrgg9X4EYeFzYph5WQocFwHA7S9Rm90kB JRmI1GO8ZXDPn26ln6AQ4j9PU4nVYljUUuI/4aiXSnI6OShoWJLUCY3q31jhMlDykuTBm2+7 Y/rZDBcSEZxTGpYxmL3UEgAqPZrfa1+jMTIwSqHv72zV2b4VE+3JlSuUaiqKdn/7/wn/X0Np yQrDqvWNUrUY/JUZD4f6RkZWbFkm4gMu/XO0F1XWZGJLeiIGZJgFU/MOR1Jk0BTY3pS8hrlh ugOjTozYdA705iTcQguA2hcPTzxkGUhR8+yZWPQf2un+EmjgQ/xeg65S2FIaPr3Srb2gdAi/ L28f7GMoshkjHElKQbXh+o631iJTDFILFLPUHyMQIYQOVmobw7sFWx0+RZ66yB14vm833bY5 +NI5PO2n+SXKuS4nZ2y+HfRCBCRdAnVyCECiBgwxoK+J9kIQ5lPjRTeFSTcgJddqnlj2+YPl OIi4MRYYW+UGIMa/ycfg00py08KyXu0TmZ1rhVu03qbRkwhFC2RFiwn6kwBszNCLXe/o4dvn AIXJRLcrz9TmvVHgAASHt2QUj9B8Au8mBmo7QbzF4SAmikUXCL64/sEeJ/GhT2i9NnHThfK1 1B3GZkDF/pDdVCgUQPMcuHNjPhhVRWstdO9yXhzVLu3xE7c9wxgPgCIiSsujvsDkuQoIf/X5 fYei4DIxQor6dsIN4fkNJRWSpJXVC8HLkmz4oesjd6Eyjjhf+I5/f0+yaEvvCt+Uil/9A/2G 9YJzV3N7Z6E7Y0qkdoLNdlGv7X2XRFxxSwm/BLQBYeDcQ8EdWGeC1+eF+oysFG8ajz2kXtt8 XeEm3aFIYacGWPKGK73KYiB9mROm+0JyEtIVYId7+guTpT7WumD3rEmxHeLZ3UqkUQqV5kWY TE+hjHClB6PVv+XFuFPTheWvw81AWkof50jDcEIeRWpYi6WG7qfO92XC5XRW+aYio21xwbhm XR6bCsYIXLRNsZm4SNWydarYay3jmgtaDN/2HEjArqgCo8aslS/BC8nyJhAM3l4f8k1/bv03 GR0IycJ4tGRBr9d+dcO5GRXuAXK+TGiSy4uymcTN94jEwoWTPIJtUrimPniyAt/68hkDf8W5 6FGrpezGjPEkbOiS9QJXw9uVaqzWUVDjjHStfOrkF9IxKaoeSc7rsjVDmqzk3nISi74OEb8o H702FcBMHYlwAnHAL7n9w6VlSVF+DSkhdwNu2df6vghxVEMKRt3YBFXGn6AHXWFJpVehyhGs TfZmOWTLdqexNWuwLjb2Ew/vQL9XsIJjldH4jwY92iboyUjCgljVLBBYyhI8zipv1TVCEdQq GjLbha/2uTK0BsZT2Au5svbnJivvxFKawYSKkoKAmuuTz9rqR1aJShQgRGji/kQyp+LmRA3z 2FRvatFuCv9UMRImkcCfLz/vTxpnMnm/qRI9wtDC/cSA0i0+L+bewXoXD9gi7sDasKYN6Gvq ryQBMt0VfqKaTafVbYcyfK/ONaOQOXyUe2i0vm+/tAfyPd3QX6X3bdp5NufByCWi+pDwyvH3 tZJRFpSy29wRy2+M0lfuSuyHbzhdnFJSQUjVeXz8z6c/Xt5ImxaLHhmYlKYKTKG+KvYHy64L uMk7CKYnjAeQ0mVjWUCvVyVM4uDeJv+4hDwPWoki9Kbq30hYO208G8fWoZ/JVR0lK0iMtf0h ZGtb00F7B0bvP7pmmQsup8TIkEuC1hz9VVkYep/YEEBfrceY0UhgZ+mE5l1NfBXwZeeRBZDM 8kvO1g0ieZ37eFA4G/khZ7Qa/IQz73MjyOe/mRv6U+olDyINFaSUeie9kgCJcQPz46i+CaC5 qUOI7Wk+FCdT59r3J1eVwk0DGFo+F9TZKv7w5uKvtwXICPwwmm0YglFORIT8HWhIvKEU2afp PuWcuo8FQXO92G7KfDyMKwWOctpADUEcFb8PgnbNHK46MqL3IPrGfUISxYh7fBcrjPOqMCyo 3QINeyDmmsJB7txCAxdeD6UNBuJgIk9McfFvgcdiX2GZTcRfUmRrGJCB6WNbRM/VcDkrwGDt ZA2Y3suCBaurmWqa/839ckhAunlmvpMIMhCYaKBICQjsYuPD1S+SvTSnJlUX8u+csckhb9qI 029/fL7Mz065RqtEZIzZLmfEq+83Sf38O1VomuJKpsjr0Q5lZGbuSBLcsrPdhfwFXn2by6k3 T7KuPWcZokZLOWjm+s4WOKnQeveU5QPl4heepKvPKP9x7ezoetgeC8pc+io2BvLiMHo0Rztk feBAXPZsVxI80c+fdsWV7v68cyiunMJD2ZKcgIoL4P3OVsQs0qMPNkcHGH9tk8KzHMb2xuLQ Dc9sTscWC1lWA0rkxtruQWg3VpNYaLpZQDVdoW6nNq82OsEf2BnZodsoILbsXKoqqlTSCwjf eFD+GAsfY7ZNDQssvG5hbud3b6jsVqwKxbp8AHMJhSz4JyvgQ6w+JAbTbJZWUfYNFRIQuw7A Rf1Nb48ieDpcx0akKfxJuNPnIh5ftW7fue9TIHihUDyT1yQOOJrDNWXrg+MIW+mL6Q2WZAMX Z28NKUU2F62O6tx/jF82hjGL8X8dyGLhYLMnempunWzxYHqnCGRCjOJtyfPUHlIHADN94fqr Sv5ml5cOej3pbBKlEQ0ef/YMkZKF1QRikWSFw02UVLcX7LdJueizSBZPcoqf3S17/3pbiBBB 5ptnCj7OuRmiEvgkadFL4NC/mbLJI52WaSeaGas4VI6Du1LqW+d++dRgarY+pSOKPDwn6/6N e686/JV1C0lF6DByMaLjlQQ0YEn0eLO8t0tI97/cgUTyhRC/uJ8i0AWBavrypzEJ/iw/XGRz ixGZNP+t6I+Y0lwboR9ioW1YkYoGMqkXka/cnCtGgbY+CqYxRtEyQhmVrwLf2MJQTDyjgoV7 3pcbqA8Csy/Nv2a3lcfxIj2qqAp//MJ6BONOwhpwzsynFx3wTmObbGSf2NBW2+TIfSGL+8yI kff+aKxqPTnI4coXINnreYQ3V10jl1E/vimqzT3McjV4rTK8U1pWKBN0NBZipiWltYdGsE5K RnSHz/CiUMup8oxfhpXPLb/GGaltXNQiJmqc25gwnbXl5LUxpIxzMI2tbA+QGZgMKPY4hTES 0WfUFqyeMeV0y/r2Y1BIuD8XDqQ1Vh0RFTUvr/dZ94f3piEetzOfHagUj7+dFBB0x6qUrAZ9 6rqltBZe31OMfdkt1AJoN96Zz1abxtIzTyw6/KtY0pP2ueyh64vMLVzco3bMfTUzY5b0js2u hPo23uSi4Zv1drguUrYeFubtepgtQkH14ptX4OmO2QAUNOvm+zJUYQIEwpbnuNW5aCTd5Ie8 upkvv8metSPo3M31wNuVMUNYAEj7kSDh2Axq8M2VSgwTXWFbpBq8u/MU2SK0C1mtxXPQItx3 t1RpP7pIaRM2MLiT79VpGtDcObjjg5BKbBQQdo/Dj2i50C8AKgbcpL5O4uYKIuR5Pk5auP4R hQAFk+3iTcbwhu4ITlfu1RifgZDCu8+eCvyzGUAytu2RdGn5nuFxh5XkT82sliAuP3fkkMCC LUt+d7eWKo0nXL0oVEUi/0p19bHqOCROyUG81ixHRHNk7t/cxmZK4JaWg0SQ5pbKUbz/Qmdp 2SZNT1WjqhjMrCslBbk7L+VxNf1TwDdTTM4t1jETw6TYmVBsUviY09m5YXC8QSROrSXu9Cpb Xb++GVRxW7bokEZtF6rPQ/bdwb5n3Urcn5rSLA6eKb7fAhwpn7o+Sxy5qFlD7xYo3F+gASyf 9CAdKklLTr1squJb5oWa9MhgsqDHoZ7aShjqB2neT3IJ8TdDJGYAVsYWX/NOnwg6V9S5e2zz 8I/DClG9gDrC1JGaDF+Vtg4ew/jpohhrjqhzjJ7lfMPCHW09XalUEYE8aMYvVn4R1qUrAyvK dyNxOq/99hwxCK7zfk4voFW0DV3CxFUrVcyiwy6dOBKxZkaUYwXmW14X9M2fTMBoSPf79BYn 56zl7v0NXG4+mDlhxrYySJ3j4ArRpRs3R5VHG9ovtvnTklaY4Uugj7RQNL3LLdCIM7LQV4AA cdznd+JPPpyaGIKF0kr8UThR2yT+ADIO6A56X2B2PTeF8Hc45sUCsRNvQEP4srRxDfYZUmeZ yN/88ioDtDbbHAdQfFlUC0B9RESYEmP6Dy06BOa27Hgv8qWlEswkq7Jlw7z0bRSsqx0quWoL 2m6W/yPrxzZ5Vsl9epsgtCdg49meFTRjKOLJ2HrRpsOvuuRSMZUm9NrVwmsDulO0LPDdHlri gQWZliH9qkm4qGfiLGLKKSntxI8DcmoacaKOTbVX3DHAGOELMyXj+4c/RBDmBq9BjbM6cuwz Q6M7yF5sO12RSa/ASZdu56mANtsKzuD2JQe93Kq1/wFHoCXMouE4cWoYqLPK+FeI0cp87hSw v95WVydLx8JHTyNZ2bm2Mc1e9jN+f6CF1WJy6Vby6Bpb1ZFNzO0GwNCwCgXGZ+7cwYzhn2im 1BcUQIBz18MNr7tOV3KJpXBH27eCjBbiY3iH8tRgq9KtZFItJsKuEdGSMgKDAw4eNAll3P2t Me9OLJNQYSvcBJo8lnBnn6Nb/jECLUa4g8H8BFj7xKa4JYCpHzRJ6lK17NVDthnWMr1oSOKN cb4HHAHcWMGLgZG9RWzCldbGemaUxmjEr2gH0qI/OGVN/JY/HRRrKTpDwB/rz1iAA9DayZUh w54QHud34lNRp/iHeYgmSNrpl1yKNRa5G+XKIqwDwjgekc6fOrRcNFVvQv/0R20A2/KQIXYo JIU2ve7MIUX1jRfV4CjrGvMiu3BW//ZL/xzM9Oe1MmcpDNiZYeX54M/hIVcrfZOODgQyX95V zZLFeQ8JwPpvp+Uv1yoh/JtyQSC+PP7qrnI0XsA3lf1p1asKxzXyjpTlcFBNl6FUycIr6sCS de/oJlSyQMlplsQIXo1fws6Od2JUONAjDS6uiZS2y+6jG51myEUy0VrhuXPjmYI3cn5rU8n4 +rUfLCZNL3fm3SMr7qF8ojCv20+q9LBCrw+XLPVrpFpK5Jy5S5m2F9RsE8iIDvOJ6Z4KWsD+ C+YNACBetoKOvYSPRq/Yp81yP3V1kZ6UbE5bOXrxt/Pqm/oKXyRnDVQ5t5uVRWLIKCIwXF6B NOYYip4/WGXWlNVaMeJ94pPzhMudYWNooRgfdMc0zQtEWfoedUJZ+54U0iEcL8joE7k3Cziu PKMB9jANaxGO3JTUFYJQCsjQKldFsUpfBsNXXeHaICz2V/4K3Ubv4MESoqbrr5Es6zAY8iG/ phXGi28Vo8rzdmHuLjhWKIqOsbgvGnHSBPnfwPS/ppEnD09juq9x6Eu2jHiN0077bTnZ1mWP 447FVdxWqBh/hpj/JQL0fJxD9+Co2rXvs/HM/jg1uVKsYYXpvPXs7vtFhFnaR0pZp2Syu5MS NBszR28aIx6BGzkxc5HwHf9tDivh6D5wFHuhWz0MALQeVJYRL7dHUClE4EO+SAe+O3teOBwk tTdxcGiiZuN77fU3ANH5gW9UBjFux4gkPBAHhyx8Y4GzIYdjQlQ4Uc8SfyXqFAJRfLsbMMYh UsA8SkD9c5H7ApvRlZJa2hkQ3WtiZWcTrMRWFlwnVaOpIfXEwLwfsxNdsBphXIB4LC2Nhl+u ZMWV1NNfgbWJFl1SCDYw+Wo9fz6RWj5gk7fGrfN/cpZTZSdluC2CnonpUp/U9RlencMahWZh urRaoPy/+KCCImuB4b08XYRRia/cQGycO47BzjIrz85nUb34xlo456rnvzFinmjVzvKFa/9v hevpmeFK7J15qPO/J1hcnHrIKbeqi8flrJFf+rVa7uDSpUvM81nytvu1BiD+83cILSjk1REw TcSs/hH5Z6wDu8kwdE2CxbniBU2mIZepUJtTxHjBuq+O2juyCTWd1KYMKowEpVUmJMGhtm4s E7uT5pwZ6yU6jnaJJzADvAQO7zh2FbAv9O8ivh2G5MGzHrliAVBsuHCoenevTPBJGKNzs1Hz xFoWQ9izayavw4r/6SNhWThpLr50Nvw7otw7cN9RZZzARue59JK/zarC7uxRjOdlqRnt4wx+ dPGJUbVKkEYLFriS1Jl0wwakuY6qyvLTGQYsXGfRv6DHIHPPuhY+sMFRGZqFY4q47BfacnNq tztUUwnPvrzfir7kwi4MNZ6y2ScqVryCieyYaE8Zsjhva99yX0Xpf0x0YjjkMeSRVktpP5xg sK99Y8G+xHRCkJ42bdGfPgjzk9uwA+2Yj89juyURFLHW2VqfG2TNO2Ft+vwYSljVtpE2mZpt 81HNkf0f43PL2CrdQwbDTEZ3GXDLfBkXILyHalHVObEVjOB3e4Xw6g1HEHNULi7MBkezo6V4 fkaUX9GdJgya3wJ0/GNeBfuO4nVtgEYWPR4PkZmjKepKoXfqNL4V3Lxnei2tNGbyf1PSujqk 91jCr2fx48dVc3fHZ5GZEfLysNYnQ4giCsjfm7/WOmOo1wf8sQvG0XvVNPJJV4IoOz9vuwBk o+AH0HPR1LgVmtwFKXo6SIJRSBxuzAVlAXsvBogkq4ixTodEguhqIctSYCnlS9K1mmwuTiNT eSvDl4KEMGREECEcISVTG4Xrvtl9evVyE9mO5OVUiZ5mutIe9+qDQT0kuJzl7wM89K8ku1AT 15SGkXeNaPWS6zHSU5c7dBgNC/zvwT5xYFAXWF4YkE+AJ5vuTqfvSFwJIcU7LWU3jaKSumqb HHUGVxSBIiG2Mq5zAw0wTP07h+b5hSaFN5la26TWw404eNg5B/xh5q+orT8wzNDWHeDRKREH 6h3aTrZcgSXjGlqJA4CPsjNPCeRqnlWJJkYDUPxu9oVxLL2lsHS2klxET4X3vFMiv3Jt8B2g T5LIhEjhh8UxkeI5X2zzElvC5sZ/vZy3CFVm8ZpLibCNk+QmyGUbOkhpM0WfloGUHDw1z6ZZ 143GV+p9bQnloPPI7RPjF4PytRIDcf/WmuOchnfjL5TDxVEdkNJUEBkvJZkMPn0EvlDXGGl1 OMWtfjjigyCz/ZlJeQd0qS54VagQ9QJEzVoQNDuoGiLOFLY69kRP2++jh/oZq2g37UNXDef/ bNa3mtVxCvKIkPdcwsLNVvmTlLNrbf8Fs2d7vG/PGKLjbSx1gkkriijASxj4w1T3ZR4kSDUS E9HT/W7nYTl3nsCiWu7fuQsYoToUMIv5ahTYPfT9Q/3Y/Ftcs12ZdAj1cjwsMs/QIUcibrD9 41u7mH50l69Hnre/QWC1GlMZ5lpEPnpXxZAraoq51uuc2T3vUSAFUpFH0kAqCSdL+vYzcEag FDq+pLmZiclezJcuYIx4dYMdc6jbEtER0eGGR4onIw/M62j0uCsefxyvdNDqnb2XPmW1PYqs cAK1o/eHhtPMOeKG5IkOhSQirdJdixnjVxSo/GBY/ivSuO2Frxpm/GifR+rpBFVcc32AWEIK ofAvyFhXU6bstOr/MK3336b0XLwOjg4/FqAxAbl3TP1BGnG84G1ZnY3gOgS4Y0hokgia0pk4 rxpB03PNhM5k/VMkMO++7Aang49b6q3Mdq3PmJfV3ryTDz9wMyFymtEAStOMc7OuWZNlFTe/ +/jKv6yMy5KAeLVTFn8IcPyoAz1291zl68TmvwofJSMDCdqOMN5q+pbqMvIiIOnPhHIKqQTe 5jZdYPXhFFMS0OQWqx1bBX/x5+ewUtYtV4/NE9JwvM2syRspg/eeFTgjReEIlkUpX8oToP2R TwHT2WI9LeLPDBCnWTb5uky3mI1okYP69uivyA5PeViN7PE15H5But9chGBKJeepPi7hcjlZ /8QecdsCQIQAlkF6D+C+HOiQ7UFNz2p4DLyrx+HBcodDXQfPen8HQB0NOEFNr79/pUKQvX1X GcYrRFVJnZI7c8vUYyB5QcIx1gpTjJ17STJmXLkJSQFqpB5RQ4zbrMqhrF01/MfSvNZaP7fi 9RXxVLWTD+5mh8AalI/Iok3miKpuJSciMtPVVl6PTPOOVa5WpVvDS+kEdQeqVdUxq5Z35ywR +FO7NY5/gMFcQ94aOYuA4aH2JWuE9uWu07eqUSdfO0W6cGKWzZ2sRTWzNi04RfGkOs1mei1y FUCRvnIPwgJvvip0vsFmiaPxH1Wpwv505/etLlRjKlvmpAJaOZ0eICHV7HztO7++MWv+2cqb 4MQAAJeE7xfIgX862bQsSdmJzIVcZsJpNKQNWON7zr+dfR6523TIylNoMZIofvBKHSj8MSGY g0yDNPXZ8zj8KJOl7oCRs0SStXNQRwzLMUPpjrZTuKKjiquzbW9QUIH0nDoZbeknlxSE2Opf KttjVdY2MCblp5QF21SG8yYD+Fj8XniJqZllDs51RU4AKtCzYRgymPe5QCKFFs/JIwcOobuo B991YKqTZhcEDJ5XCtFSKjngEdWNn1ZSfZiInJJG8c7DsZSgzgZVvXuCx5wQMZ1tA4mPpZcy eUJ6epO5r190eRh8nqL5ElONYr4ZaLP65Pk7WH0bDXna/HooshrClGJfnp3ZSzWtdFpPcK82 C+uyLL47OYWj1PQ7pHcpdMGZL7z9Eyo/GysKRsLa1cA8gNEX7YenhTdRWzPyr+FZbqYs+ELB gjlt2yOBsDpKzeNMrxBuSsyBFIgDmXUu4NtSd+kWntYuFsmk+0ZO+DbWvjAJm1HRwebu5qER ql6yOOtfSVTQL4D3jYx94wsnc48CoSVW+1hRFWLboLh6gQMDz6nqq6ETLJBrsgVZocgjrAsj srajYviB0/qadXP3v0i5cqgcsNVjDHiHOhnpfpBTdAUEJhhJgyyA40byW7DGK1+7azkCmSno Xpjp6euOJQ/qx1cN5mg81P6EvnPJKjyHNA1eY0l3w5F21Pkx1B3QfNcTiFY8xjf0q96FjDEd 7Osm14Cdp7S+zZjchXHvOlcYWMEbe2ThQQcVWpfzViKE1idNGaXX0iS7Jsjc3Y677RlbW7xh Icpj4INm25C72D7UcPER89HXY5FE/SRinAI4lVW+g1fQwtQOd1pl93Iwn8q7kOvdm3IFzUTD +tMAdqJrjoOlp4vjOaipS9P0GXzBX5Fj8UZbi6aSzYqqSHlEN2MRmCXQ4vka/9XaIM9ziQyN C/iQher+ROwfvDLIbfVWvc6KJAD3f9BoEgPO/Wz0J2vP91fpaj7KE9CbaCoSmS53pTpx/sQp iWoynSAKqV1NtNE4ZsLLsENodWK5+q4WKvqNqIHzgLylDDuxzr5QDKYopnDKAf/8Q4OMVlBw Dl8jxmEwXpKn12FAgEEYbWbqLjDNUJu6Yw0WcgXA1A0cAG/xWRQTr8curaBE4lhmgM0hMZqt JZqCWTvmlK2x+1y+AEWsC4iMqCPYHZZkot7dzmXPe9J3rx8bM59xNTGNpojKWOooMIQkmOkE DmZzg81VKpjBXPwZnLMGoD9LWUkbSAtxwnT+X5Jb9Sshoyv87Yg7Wb2t2eAQoeB3WSBF5OC0 umItg2JMDTLP6Cb6g8XfkBTRp/mPg9ND7MaU9n9aSzbMlvSiRkmtia7E70hNk7Mw9/iHhPyT DohKFwFM1RUPfYTNoiPsP2kYQt+3H3Fzvhy9Iu/stfRrFBcYOtMwPdYR98/r19ehkhyeLTMy KkmJ+m5PJEQXK4Pd5VOVb1WW+Xps/gvoTB31R+/CVF78tSW92wYkHfcsq69Z7PqWUoLG2aW5 ZQIz1Pw8BO9hP4MgkBXS/adAqJM0bUk4gVlSmiRgP5oh0OsYiPrqUXmrqKOZeP7vVs+kNawm zkxujj2D9o8HvkjrfilkTt8EuXCCGrScgCrZbCYoB99vSn2Ax3d2w+263iUDRPRXQgyzH9mj jc1fmF9TiRHkkdA1X62DuerexdT8SC3MOv/ivtHZf+fq1ZZ4FLZ8R1mN7j0yZG+FN/cmOVCq jhIXf2CxWQNaGmrFIM3GoPWuNm6GgLW5tfjpGrp1bCAegmxjr7Bb8UOmascHMrYRcUPZckZB lCpwdBIXyUkSjOVy4/5rzSYpjOrAPUVMM/gdJYN12+alV6znVGQhdEldyolyQzyKjtfJujou Rehcv/WEcneiNqVf3NWnMxgfU38EPwCfmyxDWWcAd/J5TchbarwsOkDDMFI/mLe6PnPjzI9V 7IEQBuzLQ5SkKRXUerLRRNhBme7VNDx/vYLxhh1uX+fcle0z77qmud7QrVkU+Peg0UXgsiI2 /7mmTtuFuy6Q2gbO5UkronG+BWZaxOvqpN8bqcMOK52+2di+p2BzZLze5xud/zbMb0uaOU0w mtr85zTppbwYaxB/tuVhHHp961hKV/efHJzg9THIpehrleKDF3Ud3W0esIn643Mkk4h2/Kd3 C9qVZtYp9nzKQ3A1JZ9NkoG8m8HJ9ON+AcFTxgg8A0FzO/Tqil3ylXM80YjVguT6yDsAiBHF qM+ElXx3kkP47BXeyCFePycadR6Few6CFXh19vKHxCMortlGLy3KjYu8eK+Ey97GR2GB7TDc Djlio8U2V+rnr+ua/XMqbkJ/Ce67/C7VwgO9PMrCv2kGZoNJ5xueiczl6clBiW40KLaQdmUR YUPSmIh4xJNtG5XaUVnlWzoCx5LDIeFgDR/ab38rJFscujOiRGA6T0xR8UgAR7pFI7MmHRYU ZQqQuAwWAOiF/vz5J68hw1KWoBeFJbIExajWBxxgGFViyX4HRsNYmhPpmsYfN9gcyzhDBArG g8ymrCPXotYvgvzrRgQJc/Ke6i7pETx/ZLTaDz2iDt48VLlY7XSexf9eElLThsVc+YHbguu5 oTg9KdeRv593fiojWx8O2r2uTwdaASaUMT5PD4M1+DhAMwFCJ66wPUc0hnPvsrvfNAmiIlsT lZr++H56HO7QE6LF5u+9ECvBAA8sxBpYO+Drz+PobkvGEt0po9pBg/2hgv2suD4kHMweR8NS SAlcwS0TjwUgOocvQZyrM9PUTOoAJTzKHpLDo2JDwYRgMrsM3JP3XQsORqr5B1mvNTGGUSRa AJ55KRA85T5oD4nmgjR8yAqb9Z2/bp+HapY6MHJxfhln23uGgNhqYeavsL8QMXaUPHpB7sz+ aA7tAuOxGSiwvSAk5caVPWHwc+iSXZhX0L4VCyURmeIcdZbRiKfZBjYQxzUE0e/mjBa6YYqw Xv1oMBHVrMzQaMQq0Q2psf5UOM143d1aEW/aM1zRjo5fI3ofA89m/a6jMjb3R1fKgloHalUI IQ8KAXiBrxAmIcngfBvXSIQJQsiWUGVpqjuAvmyCOzxmCe5Ji0znpKI8tph/QaFxlyX7unvW UBRHembMI58bsCI/0GS61V6YVg2rzSbE3OHR5DViSu5lui51b7tjbTNy0g9QNf+YukwIwxAr qXjlD4+eh3aK9zpn6huurBQE8j+SV8SOV1BAvlOxzL/qKoo5YCFmlbs/bEOmhGplxr7+dqNv fKF2WnGyUdKgvI5DHgSFdUf19P9qMNK6snnp7CpdnxpTvyr+kfHXBFtTVwlBBPNd/26bGXSY iCBzKEz4S+oHs56NA36nhp2SPRlr+ArCNLbCWGubqvlm7Rz1Kt0rMgzNtk4hDlwIDXDvDQS0 ydd7rrVqgcHp1OPVxfnxY8eaoLzluySYRacJJOCyB7im3VjNne7OQbvWarsLBog5OjJZpF/W 4uB6ULi01MZeU5wUrnDw0TkHg4VPSd5xcXQtGucTYIsBhnuvf/3sF2duuZ2NGBgddr+6kvKM OZ+cZ1D4q8fp9DY0F0r6yX0VlCbe2vSyblQYUcllvsnWf8A6u7cz8uggiI/AhUNDYS4+w5EZ 1oFJNY8IfJCHfYbT1/d5TRWsPXtaVdde7SqRwerotuDzP7LGBnvnuANOj2DR85uTwv/eZGJd XiKvzmbuu1jT5gtqPWjdaA0gBojmJiOh+PPBs8DRUbeg8imIgjoyUpY0lai2MfLDPy/Sy0yy YPmbziwsWyzYeXg7mQ1/Gz0Fkla6ReXHGASlj9L6As7h8idPl8SiPXXx48EqygM2GHS6AJDj xhTIrbj3sIe6kSWZxTYlX2fO3hrZcWYRgBugztPUbx/AuRl4BK69KYgtMXanW3qBv/l871Vj Sba2LezO6MMnXzdXAJ0B4AOsWFoJ4tATRvOcQ9DQ6Hv0zD+KVdMuT5XbrHWvvHdY2VmVIYS7 XhYCfwK2x+xnqYjM6cXg3GQL48h+/BlWnokYNbb4HlvBgI4zuuEk5n+JpRkul9yE9iRXnw6+ Fa+JKywD+Zb/PIif3KzHoqhFjgYAqD3czSEffZWWXOEV8Bg+pt9eyUgiWkNRbj+EIU9nPX6K 38ubkK0QHo75FlUfjMauRf7PfG68PWjp+CTQsGvIboSRMjkvEQmYWzKdl35vxf/KOoQQ786g BumEzeY1vmmsw+PXX0x00IkGXSFNn4ZoURfUdR10nzm+xMJXOeihNsvOXbo1aoRzP14auD1M 8eg42d4z7RKxVotLH/tuUzMwlCznOryBulsV4+T4zAuPAbVfzpGvb+Uth4VRIB2H3H0n7goM AG7Yb62eLdAbejLh/OtEHRymnLxqSdw1QdmNyR9z8QjdZf73KzgcDb/mKLnd4qsSGX3PblnE PEG4eyqd5cEySr3cPD25RjYLgI2QQ82ch2sh3f2oVc7LcVaxTg6azR2uLclRBAEFeq9iw6y2 ebkoOYyD/jfawfCCGG8O8fN5RpSUj6NkMlluOpsoAp8VZWEBwFgC+6EB2BqSZC2YpC0ksHOB v5gR0czUm30gO/jQmxS2AaXvLtF2D4DKtikSVx45dayTRuCegBZf8rioLb2eDZVDn7w0XlPD 2bt0bJxgdSA3YcTWTGGKSbNggC8ghpI0o5urLZgrcs86u9QkHrVmKbB6zWZAUvbKByJDsAyH QYCxXNvEGIdZdKZjGWJU/mPgKmNqSHBoW+poGiguL/7qyrVvwrr3BL8L+Xxi4II9dwAN7PGl stLxlxY0QpgEDSBJ53bY0gTLzsYuHH42pxbpvZ/82yV0k8Xx33bl3JnqzZUKCReuli2osn41 5ES6uu/dpBldOSaOT3QBH0aj/Bn9EqOq5j004FGoWk+sqnEFVdur6OFIkkGVb5fgv0DBsCk8 xzCKLa7VyzXwypHKnCb5LWFOp+nVN3gA+Apr8tlwpeZA0gE3uSfAA9fnlSKlT7OpLQiwyWbz 8oI8O73OckXRa2IUEx7Q6KZRFhyIRtMwvUltgcjFR6CJ/zXTHOckK5l+4QI/MXs4QLwL6LUj aY0tElqPTPkVyCxKLtEnUmWM8OnirsWL8MC1gIQABym/KpK9lWuJp5nObR4Ztl3haS6bba5i a0IcSQLMkidHxAyf0IRfbus6f+AF3VYDZpkA8/Fqp0sfu3YW32PzbYv47oUm2JqNkhTkRzl4 GMNrrK372Zv49vxRGlqk/YTCWSWnBJaTM6f6JMf5Je9jVZyEt5kOfJhXEINfu7Kec4VoaIcQ 4v1ftka1rwk5X3uJLG2YrJcFwB3wsa+LKmQ+pQ0GYCbxVFw0UdksmpPvGCj79S7BS2NQ77LZ kZpp4/4fYfBkJmDHedfSgsDcKpCUddnK1S2FPlJnKs0I+s2KnAIsREm2+VQjLBy9qLwYzRd8 U2ysY0OArHk9Homy1O6z+KxbTauAzQOnvPnS444joLAvxkvv84Ro/6rHhjyJPHP+AUIX7O8e ca1GDB8CoyJ39bYTQ1yqx53W2KwI84XjEOMzxBplEsRjqUuQdDt0V3MNvQYeV7OQLkSnojn9 JmwLuDW0W4MeamdvpZqfGYzbowwCkVzK7nhEq39nxnNweJ1Fuup3VBxEnc9eqbMBpmLBcn64 CRPFr1nhyth/BfnLvqUKLE//sGC+Uf4klR+v1aov3gatXkDpF//rI+YsvF4VYo1TxSTqAayb Cq9w6WH6bpCCzhzXApfEiDNPMS19SfCdqQZ+gGKddmC7mJl4dKfguE+rjI0YzEBbUXFbzlPw kJtAy1UfH7HoihTJAnZPJtfl5IaicG6uF0/uhQCvmHv2tYmFBVDODUM5dKbMPFwnAm0ldypY Pj1ZaozTerVYOJOX1WyWPjhE8Yo8kahTdAWFX+sxdvkiWdc4y95HvA2eeFYaq1Z+9qf2rk6R S0PBPPRDeeF9rP+IrkvI6XtasKfGoQz/cpeV7c7KRKfEba0+KDtpgIFpBwsGoPBkTYEF70VV cLJf0HPWtMTDWwbey9Dw6JlySk42dsyPR+bKsi5kSxdyGYAEPO0oqPJJKhv6xW2Q9qXZA62E 39K5Z8eRHDrGkBeokDfxAlSeowZptSRsoxM08vV9arF+6hPsYXOEL/lqT2uE0SvsvGI2FgE0 iJfSSz7GzpF4A0+mtDPwC6ogT7ks4u4KtU9p6NYsledc77aw0/9Dx8sgoRM5vztfbZgi24Q8 dISnqTQ1D/RGNrEDwTxN/DhURvm+HX+3m9KaHAB8dbFBqtnEE/IJV086ez9SSO43jJArVWrt 3m+hft5EwZcIzSgCn7QHQeoGRw6x9x8nCjKA9exoWN2YKsH9MDatP9Z0+Mpv64F1/sPh2Fcb BwqGN0zrNv6XRqpLvHuo6JlqkTd2AtnovNroN6C8pQg+91WG6XjO7m+/3dGiJ6efD/Mvu60A YHXlDS7uvLe2L8vjg8w9QCetlE1qq6M4iAiXVosDbtcP88CLZPWTSUOkwbNrUbioNMBskyer cMcOBKkj+CaQrsn1hH5SxXXimU92B8ml/HokM5R2f1TDz9rYqkTHrVJN5CpOJDficHfX8o+N gqKBvpUJ0YZ0fbMBmxVTbkokNVu7DgBtlwLrqbsMdOWV7iLJJfrBt2TM13f7muEgt6SPeTv0 YRYcARA0UzfvwoSAVdb9bIpj0YxkkKpqQk8crizdDxX2iHe/cStN4Zcccs8MEe7YiGCd7+bW RyrpYXxW2pjsTVyLa2ka7+ZVne5QMOU9XkuN59434tRZ934G1EuCQoGLkyltOU/5Nhn22jbs Qwf/auTzHi+jofKRBJUo+3yo8D27Jek/9+GM6fzOZ2umhsTRzDvuYV6pluuZEcHH1rZHnOtr TKbPK9US/HtZIV1TV2G4LpYvuVIpqg4GQraEEwuAJ1nuDYibA6LrAhBfK9qYDo8Fh5GZCZOO 4DdLlNnxInYZzU78s2qW/dq/k8KFacRbp9rTH48B1KnbZL2zvMRSaNsWQ5bCESnDyyGkSviD gAOgQOf8DeFjZ/b3CieAxUwdSiBTvErikS2zCp5BYLYs3NSwjlfgHkhrhUi98FSoiCo7JxWz sgcV1bnIVhOaxK9WYqm+efhfC0H2ex4NKCGxZujAxB8FfYWDTcjjpWdS+BAfllybGkeMNnWg ro2W+hN36Q6OBIurLISgtuziPCuOYAbGyRKH4xmyX9hxh5xIg5zir+c4UhUS8USIZmcvjyZH yjRsn62J+Z98g4pw4IyXTxwQKHBG3XSn5ZPC3kvK2KLD9Cdfou5jAIOSOnvNxGdwe8bZHFMh OcHEyUggytXBtjk/C3o7RjD4ngHB5QlzJ/fVcxJvv3x8dnNXYZyheNGxKHSPc+uOb7Mo3eOR s/PiZKFstqytlDTIWMosABPUwBaVGdXzy3QsiuJdlciutt/Cw0Y0u8nAqYNOkBh19KHqF4wO YCLwuTOhaJx6RO1nKAq8zoSb0pcqI15ksysk1OkK38eS4yc9MI6vgeNj/G/gw3QNqcLYzUH3 Q1NmhDwGI81hJU2lDD2InVVMcKD7Oew/dYmwvBJ3zovfvZ0O4hjq9nM4mPGGElNkLP24dRc9 T9yQCUyAxUHBVAjej2T2yikOevZAjJUsNUbg/0o1KaHsSRTvhM3o9D6oneKgnxYbKDTQHLFE 4wMrmiAHxMzu80B/uetxGdS6fnDcARIDQuByKs7tRO+68D9/wW8bMM2Sr5hFgn7SVWIMIXSm COvw7XV/0JIYltaJNh004gwOmqt8z/0wSgC0+aVjomO5zj2gV9sFKXavLUXxXb1bpHmDIyA9 4PJKcwPvG/m2NeqNAp7OvrXboLyyWUyqxeUiHPNvLSDnIt2KPkzMUoZ6e7EoyA5jBXjBCk1G fCDbHUPiR6BYU/tlSE4J5DNF+MZLI2jf9R3ZbEFtVGfpm58StCBxq09bkTnXgrFHmOcSp8mL g3807A/Vuso5LNz0POrp9Gx+wrEce+WGFUKVc7nf7Yqmybjl5o3Y/7LpW5kzdDf8AsS2WYfi 7vxYKO894DQQN6EXAubtAeczRGeQ3JBebWxH32H4RKArRjhXkG94TRnSXeCO/9Bx2br3sFBn SzRWcVxH6iIai5y8/EEPbHJSXWsnzbyWzAbsanH4yMVKEL4nXWJiO04KCnaOXM3YBN7QApwE GRnKKljbCHMh6csSPhkj8DORNUQU8aC0wsuspZNlJQ+MwbLESH/kIrUqCaVLJdTxOqCjM9+P QzsCNqYCTea9XFNeYFcNwlknBZ0UL4e4qy1HgnNnfswMZ1xjf4Tu1AD6kFlsrT/1gdUOwail j6JyRSwDzRfRe6sS3KVpcjp/tcrMFiRtluDujuhu2uXxThnKbV32DXBSF8HGp+O6XPt8wT5t gapviv7az7teyGMZY6Kstv/3Qwocf4K+bNdpRdagenK6+1W3wvC1DvNrJ4lCbZbBLisStr45 N0KWoD1S3ur3LrVHKhKTpVfjAwx++ZcGp2wawwaItg6CStaK1/Tu8MuYvifT+LNX9HAiuZea Z46q3j6Gh7x4PpUxk/VojPsFhsRnLkioe1wFXMkLY4hn0Qto3sYqs5YzZFbkjDTS3vGDueoP kIAG2goRFggAz7BfVVACEcwW8xfXXG5XJwqpa/f/cJG5vsqd7izh6TYpxXR+7VHgs/s8vIY+ rjZAkV1ndN3WAkuvD87vID12A4hYHywfCbFtEwvy3u2vmtDRc6xhiEq/g1QNMaNjKPlM1RAP nyU8RkcGq8/0lg7QpEyDxUJknxayrMpgiGWDM3YEDq5LX9kN9ghKYqqa5E1KbkmDSc5NHdYa kyCqSnlixsftyVonZNzkrMrwGTXOzlmFZAxIBCpR8rndEOok7kuIsjAMAvipNx7EIAHA/lWQ cJ20WosKvJqbSYAJnItgW0yCKsWhr0wZrS3jSgFyCebJ4PrR8uD3yKf6FfmPkHl5RrxICgLu RbZ3b/yh8iXemwNyCVVY0MsgKX+UT/6ztGepoYGEhXtWN7EtyW0JP4xbX1sb3xE55qw26OcP ge5oSJCZF0pDDjqRljC0bpeTS8jktim4HhxDlV2Y/l5FEMtkFFJ2Js6snKLVvIirPkpk6HIv krzihJ5zVbUbWvfWLdUjyRoaVa+Y580hmGhfoLMfOsmpJevkrc5elxghlYoJbIx2kEK1sOl5 xf5bR48PPXiN5s4IAUUK7DDzT0Wscd4Z+7X5In1LEqA2fBlyYKeCN2kMJj3hGI9Fi68YIwlv AsYebuGBTzKmHy9qlFNuwA7T6q3QO1D6FAc7wObB/UcvcGcbwh3Kp+/HSfBEQ52NkeBzKn6o gmtkhnWL73QZsMUnc+NFnHAIPr0eZyPg99G4wLeh1aOB+E7wyCBJ/Ty3sPMn3gC0nF1cygtH ss1f2KRUGSC4U4jKbogBW9FNzdv8DB5xhUKQ0jGvOBcuEgEjsBvskXD4sYg9/sahT7Lko7VJ NOZ2Aum5bgsQcyBK6fo/Xx4P4jAyarh+o+D/QSige6nTlHe5IwOl0ggcCLxd1PZyUKucxRo2 IfA5J7u3RYEmalTliy5l0XvYbD8rkgewx6QpbpRo9ggfOi1n9AqX/WcCU9Ig74WFnSzrLu0P FSSrXXKhGhLxhLaNEudgV22Fsr8+5cSLPvVNTqh7N6t/nJfgxhGEfrFS5ys/RkHont5Z6zOe Fu7zgk789wtmNhG8NsYdUoOrVEI/QTtjcC3JsfewZWZrQ2+O5GehHMoy3GI4aM7CoPEJqOOp CT+V8ujfDOSWDw6XNHIsKGIi+FJVSGKjsXWPaCFfy8+CuHXTeNF4fyu3v1PR/QLvHSTNB5lI g+X5GCyM5ML8uw7dk9qhukuCwsUKt1Lb4HW56nqKqBZIJusx9aw2x/1Gi62OUY4eUFU6Lwhz D2j4pm+Es0WEDeCIUjxO2U6tS+QveWvi22uuyIrvWLTZWDPcC7kcHWxpKiwuJ9xJCgMrWWWS in+lu0sshcy3p9C2PVLzulzY9glbHdvJfqaoDit5Eao1Srn4rbwlPpGjcvUv5iVzNx95Mqsd vcIVqSRHiOwIjHwjce+NVCVwLQVCLLCfcssycxHmGXY+phviRmWGvM9cgDY8QezXp6SXR+BK vP2q4CDiMprHwqgVnLRrCP2hsOlJTzBnlytc5JvVX+8fEvPGEIIOJUGgz3axrDLp9ooMY8/y eW+EuoVLdCHxagdEtK5KhApjR8OlsPvno/8H1WuOh7bM5YqBRhF1hTJeHH5/mUiiaotcmhOZ 0T5pAzON0D/SXsSMAFqJqd72Tg63LDUOkwgZHkkZDBT7N/Y07Bo3OZmrVhsUnPEAevRJ9KiM gA1vbTI2WgEvUaUT2kYb7g/11sADf0l4vCzAcKw31NEJoKgZWBeQK2SZv5dTiRuP6+Zhur2m wVznLB7rsFUg0i8wod/uJNviAXQtPOZ3HIJ1s45EQekbMvoYBp1V5hcu6u6burvNmsasHIUE MQa6yutoYuVXjAi3JBEq4B/IYiiQmIblIvZo2sknl/EPEXB1AVsWo+PdL4CqZ5muo2Qps5AY pbr6gof/H7cm3OHKX0M92cV0V6fej2ASvGHymzUjTSLGVyIjlm8qVL2oCcyTpfGKZHdv2o79 mpud1bK5RkRDJElyBw7JB2Ge4Vn/Pn01MrxcUPs+wQclw5k13RRKovaiyYOI7w8Aon3ICn0s 6eWatTGNd2qZZ9W2LhbB6rGVcg5pSoRNtb0liVhMgn1k+S2yCTUxUeWGhiiREtKfipDw0V32 eQrnPCtH8Ys4qEnBI3RkfpCBIDuTwjpLf0uGqNJLdgG5EsG0m7xRcYILQErpPA00rYlx6vyG cXxYTWE6g1a6UuOW4foiWpwiPNWMlTqYAvCOuadPw0OXqBDoFtQxIQxgJOE9EAvGEIDZWE9w ce3igkQz2Cw15/0oS0zbvc6CpyPMlQTsPta2Q+7OiiNlxTunxtGbD9hZzckEQAydcUHfsvZv gt0xoF1CjYexEQf/2ypUJcSIYoA47h9DtYl35lylstNCuHAXrewwPC1MNLKlhYPP/dI7MUNM E7HbxPBOddmRCtVm9xbqzc8+KFbM8+1Vjk1dgDJaWGkcizQdm1l160t1Ru9+vabRDENzEEPP NGH2CW22Qf+/7U4jM1KTbwGkRzsUJfBcR17YoYrVY9z+clHHmtrDYvQj+OU0SSBzNxyFbgAQ i/sIb3FEmt9shCO1q3Cmd515ZEFMKTRLiG5DyBPmF/i3rUWDxz6V8rV79YwmBcA3TOW4aL9x pchXKNtl5M5X5ESRZNuLJdLmw+HZFk0KgaDrTtnpWfsKxxU6YMS4bXWJ1k/5ZQUscRJTitct OkeeTIR6ELwYvtJEg0gsBUdHLjS5+1Oq+iqAb8w2ev+xlofDziqcHIxc/53OuX03zFYMJopP WHzU+rDzKue8cJZEAX+ixAgCfyCqz7gDjg559WijyZLoA6HUMmgN+MaeXddCATSeETcEqiRm 9G6cWZeHg/5odSk/C03+iPfP+DPmUhaZt09u7inRpZ1cTf3VesrI1VO+icAh3azfoqgHUwft gVn3BWtCWFUG3oq+YVWWX10xuXvRAAW6Th+fUnXdKLiKyH9Qn1gS3o7hDoWH3y3uMTqDgWh6 N6SpWuxPD3MqkhgS2sS03EEX90xquaTqQU/PnezpJU3Kenn5L8yelfDE4zlci9R/eUScdWq2 50LZqzcsYsWACJCL04ck4YtzWMxIUVS07sWtvF6XOwh//NWWk/+vIjexatXDngVUtBpJWzKN lfk6Rv5vBC8jHNjFzhRHoaO/oMmhIZKWHhzYPrgUu2qpAkThVOlJdzDj8U7XV3rTsnaUvqU6 sIvcKaQ9Kuu2GcHUtssFq3zwaoPj7gF0xubYx21yB2/E1w8oXS5Mnmyh5UsV12Czrwh1b15F nPcQsOYYbPmWT6xOimYnRBeOEro4a3xa0pbwWc45om3iTsGMFEb4nxe1hSvoSCy/bAkSlYhj /Nph6IL/tXqcD0cWfudp3uUFkVHVbG4ho5GePdg19d/IXD9J/kLvYD13UBHMaZdpj6HmARMj xDsWtD2Z0UYcG9duvpil05FuzzuNS53SkZXNo+Hu+gJFW/ThKa6RHwK6vNOYSFeY0Y3dnhGN rttoV/Lnh5/Sx2vS/wF5buaAhcT0NX1Q41cUlxhGGUxasZ9hsM2abyVBn3lg3pRTJxv6dC+p HrZJSVcggSTZXo7cc3LlEvtc3nkEfNo+TSj6xn2oYVlTAJVq/jcbVtx1m1tch670VP0dsVmU 06gFGsoBdSH8xMM4wbCrnotMp26FOUp7WZj/5/q5Dbn10baGh5hVJvCUTtFHePLB36dGanR9 ZbO3G592x1osXD35pWEGRCOnedBaZZtR8KC5HpEag1e9YibYIqOGT+wABDQugB8lDRQL9V5N RL+/BjD7sBah0fyeJF3RX/vGUhFOxIbnbJZGeD8GFDWENQJgSFUA2TUk6BOX6g5oZib2STid VJY8hAI5lHIM4SVc1y2Uzqc6q6e7BQzH3Ln1GbrCt3dM0Lmqc3RNp+3P5zQn0WiX4g/mADES tuardAx0FEfi2LF0B9Yeh82S1M+SYOazVrIV435+S5i//KfMKHzGHP6CtjOECbX4vFug7bgR Y2W8FCHdEsKXr6mjq8Uahok7J9tiOEviCrFgXW/aqARlUmnP8QYfiXJbiQL5fFLK498nrjX7 diluZw7WaGoEajmRBbwKJtIiHTzelECxpLa7Cz2sm0WnGiwbItbtzgZVn88sNHbTAP8Jkh5Z 36Fuv5iFdGtjYcl03Bepck56qRt+GKETps9IMungcdIEXrL4KF0Exx3UVIutqGoBvOvXEdwc nPSOXxR7cZ5OO7xiEMtx95FOoMy+NNX5XWgOj3LjAI827Ht3GtvI+xUiIKoyAu1E8rdAzj5+ sTFUKgHagweh51XxDPbbcTZTdTqEd6w464iZyqxHaVC9rTJLpHsWRQnfVRacB149F0PnmSdH iQ88Je1jc5iQSXnD9y9Fnicfh/JattSoSMfJ50sCBRYaMMwF0jsQS8L3xZUvF+pRAxG0MzfG nTDY7sRFjZestxkDXs1gvJtk1CI6p0Z2bJGcfdOkKY5JSWDGNFYOW8xA9kbDRsRsl0ps+uAd NhswRYiNjdAhDLzUlLMoavVHAYKmhN8oVjLqs0KFuhbVylMcfK6PtHo7phBOHw6PPUN1KTET 8rMzJmRjxlB8JrUi4KNiidPr27TZ3u5YFdK5QLie42O5a0RoknvFzmSo80Wi2uwFIkVrW+QP lyXbQsGH+yCcJUxMXkjen4fnLMNnk4IBhokApsofXFdI73Rlh4DLPmCTM9aef3ZQkYGcvM4Q 3v4BQK2WXSNrxK8n3eIXbJrsMGEyui45w4oMaC5+BAozIZZK66tebDmcLoR1KfYoDdjz9+uI ecfGgtg89pc784kgNEfb9jJw4rauS7thBsaKSg238mlkVAi0OJofP7Sy7sfWop1jUoUd4qrD zsou+uvq4Tazl7I5Nbh3BxXNXO3CM7WJIac89DXJyAgcP4MfZx/X1pIKAdCPlnPdap1atEBE K0e9otqeRAEVLMuyzR9bUMy0sZ11gBdFHWJhemuF56OnxckPJ1uDtnP/koFEhNQECtFypt9Y MboR18SQa+CDj8/C75OP2ITL/wgaZwNDZ0P8WOQoFnGZcci9foxNL0ZNDCtOqDUQREnFw8RK ZLuFnqHanXZB8jQ+BUXw9JBtYgqwoqawwMQ6Qr8TcCTwxPuO/k235BR7iwDaDz0sHAAVGQaa hk/qo5oQpg0DLALLae6i0KnQ7e/UqZmyrrcgsZ6zs8JCbSFC4kRW8UBTYd4533Sb45qWvLUz cv3NkgVaxQllHrPG00c6AnKNOChSh8gDIJ6Nn2x2eZaK9HUTDah5tzgrZsNCgFpOotsRtdkX eYSBgxulUMQwabhimfk8iij8MQHF+RDcDwm/OPQBV3AMaVYRu596vXUjL/95myonXcY+Wwez RD1CZSQQV/pAMVVEnrLEvTyj0QjZDJAGbjZTIvLyDSsNbmWQPkXiNm22wI+XrRnU+gfvVMju A8UgIczzkTSr4S1GVxiyY4oM/dMP/73hGYhBilRmeCfhaonf7PH/h40ZsyftxUUdCcpJ3Rgw ULJw+1TXhzTiQVu+5VhSctwKVWHKlEu9qlpjsR/su8bKmcLyCzfPyysFJ3+PGyZMqCJ+mUGp AjrwZRRM9Ec6yuFpkdnkzGrGzfZj/oYvV9JC6jUhlSKSTkIYgJUxKD6YAJ79wtRu7vYtmRWj 4TnC3CNBx2Frjv07kgTv2xMgW53db1tcLhAh1UVNAWzC1wBJlmHUFLhI6IV7RbVfPC5b7m9D RQ949aCiFDxwGgL5fa/vT33jN6GG+VUSh8q2duxUqUiTqkpSbKDUQr8KbbQ+pAaZ68NFNj1I LzJt2wG0JZB5F8b18V5h/nOs0JxGvK8rGYxTad2WLvP8QEcaSJ7J7AL8HyQTsVhG5SZipnus 3Y5CSjcG/o1B6h3QuNB4uC039OD0Osr0g4qBqZOInXkDgkLrnn43voIU3ZkyIrVXkf3HbsIQ KGVKZcADXTCpNVZrqigjUGrXePUylg0BefWsz3ReZVw6cRkZK4HvUPGgkrl9nU1jxGfju9x/ +IjOqVP34sG12w4qj83kIk8TT/h62FLuLKdYywJGU41bM937ZD4NI9OXjf+pVjUVT9w4YBEo QFQWgr2hP4xs76HkOJlpsGxNqswoLyHHTUpk9o+bBUQYtbarCcSYro48ERl7WIwTwJjX3ooq f5jmWXbNRGOM9YGRqTD4SbZf6t+28Pp/4IvwAqxK9ChM6HrCREhaL2p66dXJ9WpcW7nygOvI H/1hh5iWoXWq+sdVVoYhyxjj3gYQv0/Iboiw6/nJ8ylcdwCl7UxppxoqshYw7KmkLLrdRwb6 1niRJz7ycT3kZs2wx7wSUFfFkOPeTGIAHGb9briYspfitGiF8HK5CrnSARpg6VBBX28EipNd FMCmZgNW6gavpYOftPCaQkAxu4n9wJZB+Esx5QT/mcBJ1knKD4Se4dgqc99cx7SO1a+cJCaZ z1UA2z+6dxFGucOropOeuxzJK0pEmKr/F4X57PLWeGIZ1AWcwoomsY0Em83cAe4H8dvce7wQ dxG9xeIyNlst1MxlN6WB/xvTR5Hby7ShnRFOf9HjERrDDyyF7rcNMyRsx/XGvRp90ZAHMQUl WfVzyMyqcL4iCf12alUjs1KaFOezdgYFe2HxTNxy5cMOXwT5KoolgvggzT8tQG81yztSFy2A CTOChvSHhxiG2V02OxCDn5khazdg8NLfirQxYifJ5xMXnEXqaWARdbDU838XlXDgghmEOyfG Db6zRYZi00GN0qmr5o1SWvWwm6r3Zgq7cJwHi6xqV4LXcHw8zvsoPP/ZwWiHI5EIVwcuWcnK wIRByr2DSzGl5NCiMUxSlSq75qndvNQK4OHMeIw9c/h6k1XAy7kQ/oGFynQY/wC3Jo5CV0iY wLudgPmzMzKoU8lx4XQMFQphMBC0Lp5lobP9ZHXA0YcD1ZURn0AviG/y36VjfQ+7DkvjbDy0 ArNDJzUgVCH629oWLPGtv+uTizAJgyLTDeEpyXvhTIMvQCkdZdiCI8pPAUUGminsam2wxG7W eu48XlAK+N3pWcafPNT2nwmOcIpiBJIxd/oThxFkumVcRFib+M6MwIX1Ro10nWXz1UEyMCu3 4cUXfKc9MlMzxUEX/uEwpOB89b2QNtYzAWcZ0SKOi2khQijQyWT++TrXqEY0RdTDfstVobTm 8kEMFUqmxWvdL0N31mNJE2TNzpVvMGDAbIhRj7gtCGixL7ig1UDZgmIqgrINmRcS2fpO/lWW BgJc2/7bP84JZDv6zrQaByJnul66hp1YNeRnaenJxSeNEl0aiPa52I1Phq9HnzS7zuJ9BePb gyYfXc/UAvAREJUkH3CfRvRg2pGrPQ72i281hV5Avgun+/i6XMvSnbTVRJOz5MwK/IEmga6k vOrClMPSXeq0b1BhMuE9yS50DE6zZRoA8nlNeZM6NWsPjWJQ/kNDjGSgpaFHlFZRkJcCKgxl +Ux/6nSHF2uUZpAl6dgvS4FugzrASwjvY2ss8zzxUXHoEykIWOCcE2LcxNCFJunGi8ezgHXN mK/BSFBILchPLI6Zy9J8TJCrNCWkojdz5ET4tG48OKvABJ0OnqlrW/FyidIvi7Db4W4rf8iF +2nc/d9S7NC4qDbibF7+s/DKX8E/TIUR8Vam1gqBC0OPptaCvdfzuTbVqVQOz3JMYFubZWh6 RFIamMbJoaL6O/GaEcnv9xam10SFYVnl8PnbwA6vvAZQVvysrOuYsxnyTNNEg/Tf0O65dOG2 OpSb7/McOdvl9/2jYZoX1SUHu1E19gpq7t+gf+cZ/3JwlQKI0ZYz63Q0guRgsxcDaq64Rnyp R/lFAHu5wAxPwSLXyaCaLINlyFBfQL/aPaHtKlOK12OdFwbSjUQ+6LVn/ceVlilQfqWt5ywL ucEyuKbd1acygxhL34O9IEsnFbtkz1Y+icx+4xcmT0iBqDJcBOoP6tAduyrGt0hZijcoOry1 FC+Bi2LSRpqFHfCx/5x5Bd2ztM3otAf/VOWejPUQRDTB14pZJuhtCcD8xAOYEgqz3Wy+9405 vPC7X+Px0xr206HKoRX7A4LQkpK4L4v37cMKIdCPuETHgOU5d2f18zf9XZ3q1WYoetw3tSFY zyP48u++3d0lqmxfAKjgfCi5yNG7Mqh374stcOOg1a3PJCmGZRUHuMTJgNa+o5GSuMXiqzha X1UkNv9y1SufqSUGG3ABOUV/u8V6iwVMhhxcZjMmd/3b5TbsYXzKYVUlM9rWpT7V1depVtaV 4foYKVTO5LozLF4fynPD7/JassVysKEbOtm7ES3S1k68h5h4lHqtP9ByQtkL1LDEMTpMnKT0 +0qVA9dRVY0DjT60IAir5SyqFQi+lDH/VhQ2bJ55+z8zDiBI4/dF7O4TMJf89zBvQbPOjz2m 3LjJIRhXjJ62OyDutBGQ35M5PuXFWykIhBt/J71aE/dlNFPczF1A3EC7cU4JSiqg6YTj5CC9 9KsCk2CHOd6nat79VvRhET+OyBpEiXmSjAD8+xH00iNCQg7wjHPy1d2itvBIFaU8HObf76Ie VI7RwX7RoL/+bY2Lpexu0tZ6y/QJ1LnuQvwlpyoXPc9av/IkKxuqIQ3cH601JZ5xihA0fY5T NbaKP1RLbqTi44kkZNf5y7cf0tKtMl6lsWoz8YG1xLqY8Y+/vCtaRTlPfu85zzCO0+uO/f1N Ol+AO5I5a/U81rNlV4XXOVKws6h2KPTHvmTvMn/yYN4pGYthGsO+Wicq0ZmS//tgizNTaWRq 0q+QWIlufD/D9N9otfmEvISCSXAknrDXeFkYE6gudOCfJ/Xm5+HW3Mvn1cTSfq2RGFlYgCLC wo7G5+p1R6fNvMrQfp3AnWewlzAzdM55Jll2e3wEiFQ1eM1oINSKuTfF5jPjI7I5buWgmSFX CMtJikF/fvAVtI5Ox+R1GQQ7ycY6PgNCnBu/NsHsXLqRWhQGGBPTZKUcUH9JSI+eTpBFwbNR +pddDq71yBQujGHqqb4TNr+QLQEZxILjvco8TsRKL3Y/jLkmSn0L3hDGuLcuBXaxfWIzW5li ydEJGATlIpqPah2o9hfesE4/jjHndaqpi7PsF6dTmCJ4gszNFgKix51lUn36g4zv2iRfRgs3 tFq8lPDE1Itj67KyBVSMkGyxaNlq3lWvad5Ao9mh0gputu5yqeoyr+jQ/Hnv9yKYbyTnqpdK 8+XO3eGrHRTp76Xf5qQIaJzuxx8GuDuThxN7Z8cNDD0cn2DIStHAc4Wamv1F/hmXl0+MWfNC tNjGt/Tnt+4Om8C3RaJxMk6Kn43QC5bKaAqNNFIIVznRh9Pu5IIPslC5C0LMvVhvPp5h0ER4 W1IdnyY2ph2D2h4/gpi3VH9s/RvfpZndq1QuKY1lyK8u6GTByfMd/GbOqUZnluaQo25dOyQT 0/HjlO54mlyDhBJI95dnu4QWiG6IgyDrCEryPWaipab5CB+C4UBXS0B9ut+h9dTceFPuX+rP W0gw8guTGyDjl3a9TPEnJgbOgiaWK/Obc2Wqb5UhDUeESRbgtmoV+k34X/LCo9ekbtAJLgTE KrjjfriLw4aMs+hDf75lX8vWF4pbH8WlQKc5AcxHbH62uywCtQmJexDQASZuRyewkJA+Vjfg pzD8wR4qroIpKBWSUaPI45EValWqNqi9tm4GAfqWxXYC/UKne5Ii28+Qtvzz6de72aShViLh Chmnia2/N9ccIOsWqN7w/cZpO41N1t2e8MB6KihLBVoWyhfaN3jbY2AyB6xKuZ0iyytXo/AF QxgTEVfsmHjdFULKxWyNfyH48jOvwzTgZo/hxT3Dfou7HY6xQUEDoYDPDP2NARKgGUQdL82M TZKFqL/ec53NY+Y9hN3huOthOVAquEoi7qfqqQ2bIdBnsbBBjzAq1m5XAQ/Y7k0qSSohzJtc HY1jM8MDV3RbYGv6AC3YTA5nBs6hfp+K9upK5m7PGs0+XSR+nqXv6RKa3A5/qzkkqMdgSNgb Ev+GSOpOs4jjzOSj/yiODqUWDI59OAZpG/D8lVuMrvRQNBnnzyoNO5Cj3zge151ol7VLTPmf YEWX3LtRPTqWXEju91eqqjO9PF6P+Ldaop8PO1/XkqapqssputJLdU8rk8I2yNqvTHuluQ1Z +19jqZdw3pLgLO42fhDEPE9KFzSzUwMnDRd5zOFrObtS2jJMOsHiPYC2MAf+fYgbcrNbeCnK ZOG/Z/uWX61/CD+IQqeOZZ/OCmqf5EkVe53MxkpzBZe2Ufa/bOXB5Fnr0bxo0EARTB+SkK04 mLevtn+xvQbvLang0dSxHk4LAObrenctcfwdT9H2574wCAKHkoSTcGJiQBA3z9W/bOcWbHQF dsKJ3HDZYyemw5hkOZlgAZj5Zd+8Ifub8p2ibigRnFpkLUhPgaWJ7tKAHgKkAAny61CATuWD cd/ikvFKRCt/sbczSDzptmiHSjHJbYxH/F/25OxV93EvWD+xTEGjCCkdy4So6VltPrT2+tkW +KYTxYQKc175/YBk3rUkWJGTvOzkVHHURdSG2LK6SQu2xkK8qxMYV2vsO0HZGkPiC4rOMhdv exnb7Oke7s/l+KNXNyYDL+jAfHSLKD6XRWoPmEFkz06J8ZI1BU1YUxLVrVtcCCQIpyTlnYiP 33CO5iEk1trKPsULTt7dFynXl5VgV5nzDJqUlxS3slTBccZP7P5EhdrnOb4Cxsm8Xdth+VRt 0DbtXNr6lr1GO1J3rRfTbjyj+OqrYx/gGnsYZp5DyuN6rSC5lEBYj8CyogeHrpj+DouVtKiz aStVRbcCJ56kZzoWSHbWl5gGAQs6IYIMVyeQJAVl/vaNz1MU7nsdmnK5ee2y1h8QxUC94Dp/ 6WkqXwoc9o0jfgaUhqIExCTaQEi6jlmN1Vltakp8n9OQEyiqU9PYTwtpSrl+fIZhppllVc7z z5bkuSGmto4JvecBznEk1Eu+fOFxArh8sg1dBR6vwFbTcMTU4HXQ4F8Co5p623nov0ud3n/V ogpu293+aJ6mvNXYpSlA87R8wRiJDZURUhEktJOEqHE/JQoULaKavcyzx+TEbo0vKnwxfLAt XJBNggS/HnWFgOxQPh3cKzAE/a6B+YoqgejxYxce4+W/whC0Z60CDmkN3300FIswkxP72HtW np78CSHIDhQlmrMnRDh8XmwVSYO9oXCO583BEOreH9PKwN5ev8wqcf7YP78D6PDG62kSbcv4 P5Bre4KDKoiPydZybh9RUpKu2ch5JkE3TuNE+5H3rpSb4QEWGxXJ8PGi0nzhgwwcZadcBw2e HAUcgq6XitOUxzz4qZ2O5XaUNdcSgv2yQJSzFeetHBHuB2P5EWMmemcC0sVgWhzTGMYv5un4 gIyCuNym8GDpqnkMBZFNCqjok01dkXxZ24vdv8hnvMnZTmunlEcpYjS3ir67YN0o9akkoq69 ieeP5zngX8urmrLcsX3LPXPGds4VKR7sjOWh3u5mwADSp+6uEtCAe7Ia8uaXnRmUt8gOj8hS 4sM8XFbJ/jfXlrL+Oq1VaU7Jpdjf5SK5gcVo+0BH6t49VK5fnyTSKusZMrzcuVQDQz8EtvXC Susu4pHL2HqOIPSmVzpqA5nsIU/q/QwZymH6DHXeBrtnNHdGZNSzy9/4S3vdLTxbwWqB54NB 35sqH0X/5ulGlCFJlIzJOljYM7Kae2ri7tcjdWyrP8pQOvRL+XoqPCbE6WBmg4ZNi8s5N2t5 ZIHlnGwjWROGCQ/fW5axQz7mprfg8ToBiyaQf5/YxSXO0PW6EYouEQHpml0AiTbNHXxS43+x 33vUcofsnrqC/GuXm1GbzKiGl3u9VT9mqwjZ2kh8MrxZka7dZ3Vg5L5Cl04ykNzrSaPDTdrs VSicAKn1IVoBbpCLU0sSkh6uJWNKoBYC4lHLQ8fquH0Wuf4U7DhzHAGKUl/c25NawaKJVfCM JQcDkGaXgISUFQYQ7Cmz02UUEbxUehNzxj2UmtX1TwO8Dg+jU6zKyPrCW+Zly1r+e9cCwAlK c9p8MugjPVabJ5AhAQuPt1fXTyex3paAxYyL5tCSC0SUltFYWKC7jXGklxiBFqqHqIi4uMOZ jTdaZNORIZwjwnnDqZmHbJ/YZ33DzAoAr/7PNLqWw3Lx1jjf1RhbdM8zLpZq9/GKejfI0hAg D0SM9QNUAalhF+fcIplMKFdMa6aeFE6uYpZLK+Khoq9hcaP55nUK1/EkzX3ZSM8Ng791j9GN horghyUwu98MPsF8o1VmAa4aCPwPZ8ZgTx/fph0sYJegPBLT+RTNA3jIf+Gyc4u0h0y2BhxO TqGuK3KghFYYbUWNauyuO5u/ggT8T0UxNaypFC7MQGI/EMHCv8aLLJ04zZwVxun+byKrcMgt rIPDVcc0IW+eKdK1eoj6mvdf2GX11cjlfMrqRSDl91en7G5m3SrfOw9k3vzFNEh4L8HbKA6l I3qY7864mjb8h3YbsTHhWiy7vzGDfdIT6ATBCbNqqqocj0/ekUZz0qGDcFVEee6QVksRJJB4 whtHc1yxTWOz8stnGN0+QRHkuVNVl2tWTyUiB+JEOuIr5u4Ybm4aXKcc5YK6wdw/gRRX9UD3 vh2QbyFEr+n6w9xmbqYJ2QwsM9dfjVy6pl3t6bchDXcohpAkEYBu5o1Ug8vRsiuQ6KSHhDBa GvvggEkdO6yfAAg6FXbY5z4/rpjLghUi8td8wfI+Ng17Gt0Fth9FvAQ+RdbQXHOn3M6xCzm/ 8qCV6torkPcKQXS/8mvTkb/rZP0u2zTGAnSaSWLU4dFn9s+UHVFYhHTR7VrTj9gscH/phHOi fV7x26hzdQBPGuWy8nT+NxgmCUMi6lMLjxwodEQsE8nxoYx8Bsuyl1RF1apoOdVFcx2HayXb un07NPb6CtdXoSYXwS26A/dVDHI/hxqJcG/dqBBsl4X42UYdsCp+AX9N9rvXbX7QA2iJIUEo oaqSeF1Ncw01myI69o2CJg+Rma/vX8rBchb2efs3m4zLlSnwq/PRcGWTDV0768Q/vxsbzA61 gsZ502ZAWw+2n36QcRLber3wl65hA/hoHePqw7kjgcv+e/5mB7yo5zZckniZC0vXIsBmUIxf T+wMahNfZdebuNEyMEXV7ytjK0AESP0MCL0CY0E/xiL+0LxQ1Zo+8zHVnP/gdtYt7M997IiA KiOP89YieDUdQgASNA44wN+xNQOCbu7RfFm+USsQSlOIZbpOEfWoyYoXDZxaDfRCXwdFl9B2 58LVo2Xn2PGu+0HQdoeOpLw5Zuu/h+zgcJphYJUXpE8vcaCpvMoQX0qR45MwBeTduCa6BZMt R5GMS8EkOmFITudQ+HTd4TZSctDKVVAUw38RIUISvmrpHBUxjQ+9nZtpS0bBnsKiXdoOeeVE MbkrTC5ffSAkINChA0lJ8Ri8MRry6pN0FoInQUhdYjfA3PSm+XdbCO5mddmXoIMc567Gu0Ba bN4D5Y6llVDTutkz6vU9VKpvwLh1cKxYBdgiwRYF8QIQq2VaDa7vXoJ57jslYEZXp9eIEY2K VSBvXgQwaWzizh6KnPnqUDejcM+CSv1g2nkhNzvJcy4Q6cWPogurLG5plJnx5xUBbKIKpxox DXXJ72wTUz9SMEIF2x1v+n/LCyAuTIWETzj/ksJ1TYoKRz38iV5VW5y8WKMg16pWszCmfQJ2 2ZYVdBfkPcgiHTiKWgCdZDWs88KdTPXkb2rJT0Xv8O2iPdUcYKKoL/FXJWR5uIAIXJwIprra W7qNNzPuPfVqE8hUcZHN5BOywCXajY9lC08UPazx5GVjxaU9eGB3bjmUgNmPHCIP8wktsyH0 sxoQ8E9v898/kR9GbmROwQBOFbLA6AIFsPb6MjyL9GLam1dohUp6yY2kv4YS27uzfDOD33Ba NRdce6ff6QclOQFdu+m5eqFnvjbFlMvpyt8kk2ZmbvwoeKjgET690CaoIohCTu1Ka2iyZYad SFHtXSbZSDAj6O47P1WvIbAZhsxsDoImV/sLmq6xGWL2a4hQMd6+6ZcdU/cACLujFMogXDRL CHLRY+2NVRNPqt089XiUOYfPV82CW21etzEcNenub86l40rMsrqfCryjCDXXhi/Ae2llD5HY g0e2WveOdGQ6U4aFG6stIky1RyUmJue/BP70we2u52wF5EmSavnvKi/TwFd93p510CbR/sxv rMZLaKs0sY8aciWNwK0Cn7FIKjEBcoO2CocuUFH94AKVtnJJAa4S/5mLqFUa8oRgefHlb80W aMVjVDA4gGinIPXrGYK3lE6ccwAD05EnhOnJtidYRXm19Ezw7papIppStPJvuLKpeStukP2x NlwQcd15klowfR/9GUU/gGJ8fT6PSYfoR7Tfz0fjWCzZgLeOrqvT7P8roy7OxH5tadaH5/Hp zEAJcTFJIC+cm2AaLV6lub8Ej1Sdd8pPe2KWCEWu+LSspXslfNEoURqW8NMfTvK4GGtbWwe3 w9hqBW5LpfmnQr4WEGWFyiZ2oYhPX5HbAp7HsEWJxZgQTNohndu3u/z9xBp0fMoFCQL2WUyG V5GBMWC8j9P+HSfNFBw1Jg/UqEONHMJOF7sQcoEIlEEfSc4T8/BBP09vtfifhYJGT/IY7ZB2 fETEd3iqKhVSQlZ6W6YD+raJhANfUHehMKaxIF7189gE32urL305OV2Pjw9y1Iq2nNy3AqQY v261KWTpT9yCcE0C3I3vib3B06s8Ju49uAXq1MvEP7RgTtfaQv9BHkvy2hnxrRfNQkGLGKO7 YPtGFKMXbYCfd9T8QwONrLHLgadjHjFcKpt8nK7xwK+zLEs69t/h1oByZ43Euj9MxICW0ICn uT15Ds1Nhft03Jr+fOIJqz8ylF6wtKs5K/vh0uTCCZj58npiq3WtK69Cq39/IYcjQcJVetL6 N2MLoI1lUKXCLn4BaRyAv5AifVoeuGtRNqmWh8j5JxylmvNTNKPoAc5ng0CQzyDhg5mCoqHH MCM86vwryh+utTmD3Ah4wfR5c5R1/gNe0Iv6QeC9J6UvZNfEK46IQ5/jMaRzDV7zfz26cT1N zJLxPQ5r8RNffxOqgxgTz053frXn/0YtAGORd1zuSz8fUYu4RZZUTFc9BysauhgI4tNFluDE qhYHxgJvCkAeOFcyO5o9Ovw72GvITqG9ixhmx92WkjOme4ATIyAeSrRkQKFGpe3dEuesQ/7x mPIW+jo4KxyFsDGRAYarPXf/Gd2MeIFv/5W3HrZe/aKPakB/KvpFMMGeb7iZLj7AThhfsL9U 9QHZZ73bg58YYZSkLzLP0+J8O9+li9XXMq3hxyTSjcYsi2j5jvFw9yl9nCR6mURzFYGIVEI7 u4kFuazmJEDl1wZHBMrKLOTcMUqtQWjHgyoEIkSIYbcPMbBJ12bawtCZ1ivFjpoZZKpUHbzC QZaSsKdi3amE5DCk3JETI5384gW0BCfGoIlGoihxc5SkU/EiUm9P4on6xA0E59aNxuQyNzC/ PjsQtnlFXEXffl671BfI+mapi3eeJTV7+u3c+rmfxaJkt4ZovydAkUe7PBHHTAsFlIUbOTg/ SZA03Au8tHlw1hUCDRn1OVWnP4A1QvT9pgalkl7qO8huDMbk5Rli2Ap0yXmwBsUJ+btD94km kkUlxjxeEnS8g+nXFIh3+250VDoSCPSSNkBNr916NRe4cNAtxl2AsMN9JmpkQ79h9WIhrty3 xBlbeXYlgdoW51wzrZvptX9FBsUaGpBnOLw+vw9w3v4rnYX9evhtBNPYa2/mi0g5V5qnoKBG y8DuMs07A+AC40FmxPzdVh6TWBII2Q+qIBuRGDkIs6BkI4byc1nlYRmf858nZUJ8E2VaK0Eg VBoB7nr5V0UrH7MNyvfAZ6xK67xREfLgXv8fuJmOPaJ781uiqS5f51oyCwk46MaqXpwSYbDS 9ygOTJ0lC6iFzS07eIB0uymC5MQi6IxFI6DSFCMJOjLBoHPsgvSb5qcIlnGx+S43kDR0Pepg YFINStP2aoFHUP0/XicVCog601mPnJ7gF4wNBz0nGsUGJlgmcDWhvxrT0hr6nAQJ6LA16eRv Kbtj8HT2Lt9BRekSd8y8IQfZsjRo4XD8JFsp2rHv9Egr3RLtgvUE529dbe0f8Lk6wcgS+ljP i+AjIPQUYelXNC/t4Xm4OFk51p8a9hf64/xx0sS7pIjYNHd/o/zRpnd7xfBWvtkbpG1LGfa1 7DAR2Mp4py7XoIOlkjbogjiIpIKsfkJKMdyhtBEwLYX4PZbe5jjVF6+Du0z6o41UlmbvSvb7 JgKXyHf8EMT7kTNe5UWe2ZLv5fhI9ReSBehH/TBhkfG6MGKtIpQ7s8tOSQkle7ZkXGYcM6Tx rSX+jFHFhcppFparUIK4mo8d4cPGVbDjOVGKZlfqfND5d2pqd9gJgjSLVAqsRmAnTkI9cals LSCaFx0eUMlJtSKZN4kY1PVHpdpeppwQCnDiEM7JaMhkheBoibapKgiL806tj60+njQ9hGDs mT2UstGkBM65ezeB2Vm1jhguPAu7TKVeDjzyOfxBL8iQclPr+f4P994yMGeRvfr/rA5KjccD rjoIb3e12thBgUGHpDaYdUvTdrBqysepPcctMiVlJxM2oRi8b0dDgqo3CCOgIgxAe/06hBbb QflbHLQFcfG9+CpYRwsYU0a+f4MTaxt7gdfb1JJDNteaorvE0zjhLHmPwkjUPTyz+5uANDXg NhXWZNI8tuvyEdQxlpaG+8aUFkHIGc+PkO4SKdEeETZZT2Wj+ODjnV0N8IgEYTBZ7FbO3KGL m6a21WJf3Pu94MaK/yvtNIUSj+f7MEsLsYeyv4i34vhdk6kZSkmnA66wx3YBe+Bq5/SiEeiO 6PMXZu+9R+eeUnDcyKNQKRcf1fe2jfm/LN65nbGWhFRB77pCBphfJsB3nEdITEQWq+JvO2C9 ZGAsCQxjbeIhdUnxK4z/i5vr7Q/hitrO8DkwtzCvNwuhAgk0lSzHfpZn/pBzFublMyK5qKyv 98AXMbDlJo4bBD2BRLkM63kEsLLLudPa6lnLvsC77pgljZEIWzd7T52DLAjySMPq+7KMrjCK hZmSlQLhZdh6QlMGwcUOERY9fzB1zld+7rlGakAKd5iwL72Tfo+Pvukx78+wzi4H7UncUJFT pwDvPabIvsjKiJ4AWts61GlVfFxWxUV9WzgxS3oyUFIYHbSkPhtXehGBivEuviTYJcyG/6QL IZrbneydA4bYJdxFxFt19sa4KUOeugjQBjX80FmtXQ4sni1+DWLkzMSU3QoP81eOMl/QUfeO udbOgQOUwoTDydNVyT2rovAcjTvHx1g/qsS5FmauMS3Mzpzgf6gZ2ST0De5+e5SaOGZaLMj1 r9K8pSqiDwHNSLmV8Vp0dWo6PHg/1YtFQ2jc0imKjl3qikNJS/k37iSrTl4z5OS0mm9yvczd VNjP/ZK4YwutkF37BuXlzJCv8bQEWoLomfDB79UTywz2DgvJeYm6cmL4aTTsCuNCpdwbpuEU laIi4UZul9NOhC5aS5ZGO7bdHBbsI48VZZ4UKncmnBQxCw6VFKfOkyfzEdKjNGvsZELc0MuL WsWjE8SA5NfGuktzum2ff4vCjZZoNbTYAJZN7wpNURU7jkaFSUkE4qHwjozN2lSCj0NG4tmH jGpzYPZtO/hem9+InfVEw6s9omu3IA4nEr20CxVjrJ5DFi24IHW1TwZPd+j5gCwygaaQ0ZQt 84LDwZAVF4641/1dPmiDF2qFR9WaV0AqDbbjcia9jSihHQRF9CvfaIWEMa7LCVO9TDNuUcKi BvwOjiRgtlsDHaEk0oIi8EfD0ju63PP5Q5piKEmECEbUGp7YZjnlFVyimQXBAaGwR//uLJNH MqGB9ggRuyZK3nQECXoM0cB30pA/tZGA+1bRgGGKTS6yI61Q7jv2sMzj4NKWvQHvsJvSDOM5 KwnskXvaIbgMNg5IAIImsRA3W7fTN2TTjDUqRR7CtncABURdOLjoINjKyPpW719e8VnYRis5 2Ggk3BM4Jufr1NhAaLSm88JDUlhgD0sG1LN0IvqXpCr9MxxpKbGtHp2L2m8Chh1rQDGrWrDV l39UgVzFYsyYfUPi4JgW4emqBoNMoRsQpM4ObjwxBalHQYKlcLSb+fenBxhrqmFoOupEVX9A b57CZxLWEkXAOguSgNK2w2SbEeTTgQHaa7ubq/fM7QJjzBtvo8GhIh5hDA80ijHNAZ30KrV3 jNecFNemaS4ezGL6jNqFvGyQczNAVwCZkDAaveAhCDhS9SB8pwRjwQ/ikzTlaD49oOUd3FrQ CAYGhh0TPLUZDshr2RGpLaBACyU9mzMa+uiA2XVFhhm/auXAHgaix4z96fwJNeVYtC4IkJJJ t91r9ZbtOiC+b21SrD1XjEzpXHjAdMAto4e6nUkeeRiQKdVKHF3Jz75pMt603l5R11yamOHc 859pSHfEfZiBd2CxfRlP227IDme2heM5K4A9Rr1L22nNLxEEF+yTkfKqVxNxBK0z3JCBD5q/ /ySY6ywsRLKf0HmUSxbEbgoGsszpnhbluC4LUM8+eOes14enwvVuAZIs2wkPu26isgSUFPvj FP+nfUuaZf5k/pw9p9T29jRGI5w1w27zrPEhMUYVTVrU7e+gRvCW0dUs9g8R36LvSG2pqu7u 4l52qgQ+Z/07RkMGkZNHyn94e+4fknPDae3chHP2MdTxEBkePSOiPNH7L3pGZ8gX6fQcGkr0 OrVVpkF64POSxsdbDiNJKoGvsKCzl7SPR5/RTwfFWTP9bwVEL/yfCYGWxBQfGNrFdWE1zDi/ tPKoLZlf5bnMKEmoWnDt9TajTkuA9fodeZd5Lfcy7VlLF5DqZ89wf8ZNFhhm7dyjCo0e1rva rwBl9+FFkap/o9Kfb5Z97RH+Ix0VGu2Xcup+znSXIoxEdVZdRHThRe4OBPf7Kj45EmaQWCUQ xY4d5qQM57sV7f20zcWlOk12pIR3glRvZsvm2CFZ8Bw+MX5piKLcRQWm5VuXOCy7zs8j/Osc E+wYB1TNoGEr5UB5yeOkrGwAxTfkFul+2x4JcWyTulE8mLBZ72Th/ge2MFNzzm4l2g4FsOLV RIdRQpyRTa/h+mwVzRAzjDKO8tJglDQsUV5xjSpsVL3eUvZU69gkqhLhmHqP1k/V9fAbk5NN e2+OTPMCT2rXyGFKEghr2hFOf5knLboX12JOTKtVucGR3Supgo+bkVX8N1bpAFuumUZixPut FSh5VvYl9j6hKt2wFqBKe6QXyaPtd5kQ0VjP7m8dJls6SPVe4oc50O/j7RKUicNFcWh/mRPG 07k5J+90I70/2mEX8CyAEU7NVkYxAuZBV0wSERJa9bAo57xxPA7x4qBB0PqGEP6PklglVeqh ovxi2ONA24W55ztDw13BjFDRuHAVxo4mRLNeHQZV99GeGfk5Y8TiOTOohgAoYdH3j3suZbk5 metg74P6icI7I6cBzWGBdjPaICsU8a8YY46c7+gGEMWWZdAWMSnnmslmH6Rt/aeIFA3rjtCX rCGmU1eBwbaitMs64UIiMIkEQfjde8MsLysNfx2M93OZneel9PiJoC46GGW5+1OAgl/mr6lv bxFTgYYl7VZFix1D9hh4nenL9kMJ56Cu8EwQPo5KhHAHyKawgfym6e3kBArCJQWBM0bM2z7B SjHKM3qbz2Rs8iPmhaFuuCEcnppPa6RtnxhXrvtDV1Sx/VI56GN/C2x+iNJ68f9kY6a6BaXl Aw+wEIAAj7xIGdg+bKLM8dgyK69Wb7reY8LwHOL7lTgFg5IESGOIczZDcojRc6g3El/XI6x1 GpZr42rmYVBif01FSgzBbaUqBzEjTAZVHAYWmK89ssCsP7+78NOnkmFkOlH7cfTYfbBLY8Wu +WlJ1ph5wiYsSyoTiLOkjqMdBf62MasC61FidOtvdu9VzsXTyZSbtu0jgCfko2VxVJwuu4Rk J0894qOdwQW6KOeRn8yJUTpRHTw0QBYjn4LMrzga3UfVjhdfko7BdoEE+r8LgtejI+/U2hvc dSwYSAX9J6WGYbkGi7r0yplNwSVN3jNDTRdq7Nk4sQWUmPvizC+BJR64UEF1L3PHq7hXG7Cl lCHe1ilqTk6cq8mUK7UhXBINKxn4KpJal0UIazMHJmeP+Z4BEtsanv1Q7ufmTBb35IYOR2GR 6F0JNsm3uOiYegMPgwlifM8wd220ppg4/tYoDgZ9Xu/VT2XmXs2HQjourx0xss+dA0hSlbu0 TovUPYLl8wOYBMZc4osuYnv2U5+CYYxL7jxuytgGluNIiYYoY1+EcAdwt4TxAG8dHqCRH+ZV ONIrXQJq7s9+N/9WrinAe3NcwnkY3JftgcGyNBKkrfMHt4fCHPJCPx5s/beH+Gg067h6pjfN AM5Ty4/4Gub69lDjy9dFHDQna5KgtNpTzqBrXv/2v6MWCTpiTlIr8F1zy6vJ00ZfiL8kc9ui vpnHVtAjDwCDj5HgSRcJ8R02uqn5NqwHvbKc6xDVoYmbIQBMlohW+K+rslpSViPdyoDLjUUa UYtMrzAoYOSnZvOPNNv2sewM3sOk0Nl2XpXjcuxQoJTajWwkgW/fF6OVWZOTOwtbJlfEwHDC 7np50b0KaUkPzqRQM1JUesaI0qNl5alZuRabyIH/EiaUr4SBiQryd8MWK/qFMibDfjAkw6JA 6/gBUj5H8Dy7xoaR0wwbFwEGzYGYCWL5X60cqerA/xPDJheLOekcQqhfNIExQAjHFkiwkess nugrqvz9SK0yYxHKzy3BoVZ1PdjiFKfEIDuVDliVGxhfbv0Z1Acbz7881kCs7umje22Ym7R7 OKhwpafFnytn1neq9dqqqQ2AkY15qfnmWX/4T6L0qRzSNb7HN1yQP8EMDy5cF6FylsG9rv+c AGtMj2xAfaV1nAdzLZ2unjCWxYs0CdF5h9v5UvS+qo65zBI+iTlyLP4k1VhZaU8S2gOY4sZl A9scPZXlLBC8YW3Ff5EkiJjvdGAjZV3zX2DH0o66q6xyyQnubK2PCbiC4E5hArQ4fls1C5lu H2HSyb+RYGCXfXgn6JrkEOjjIQJbtIGNfRr465BObvGlIwBuXL/BHoJmqj+BBbuX8oDEPDED EbD/B3gessMaxgA9/9b6IryZwYXLquzaEoSQpS36AfJDF24hufIjfjM6AujCMoJQh6gw6bFk K2YHyEnhpRv4/gl5NHVhb6MO1EDmpE12YSsYGxq+lyLg6oBpdgIBY9zMaloiIqTDqRvDMEWr kFdnwc/h4SPA6B43RNGwZYne2YJgVuADxnun9AXia/MHRspgUZ8ZWp3xwQzTSdbpm+8JuU/N cWMZx0A+JplianlImBqmxQbBP3ppT+XS8MEkBQZCr+48aMoGaYlz9rUSCvDmUPf6wNQyAFX8 HkFLnKv/A7HwV42BBUzU7UsvJKzNP+ZMptg+ieMGzJLpOovVcCkZ+rNmWrKIIHcH6Svgzc8Q paTuOVsIJ0FwIYzpteEBE5kgrMvYQHZ2duLHkCocXra2dmNrg7+5JuTOBGe2TOoRJ/6UbIbF GlBZ3/6DtLv3a5EUL3PZApzgHDJT20Nk2WynhGYCqXW4T2SZgrH2NEAojSBU6fCn1CA42Eue hVDEJuXcNv38YqFS8IsMlteLc+McSx5FB+6rZ0IACVp5yLdIX+JVLcA/kCQDVGFCCpnbwqu/ KwjNyy3fP5/19qnZpfocVvhDJgJx0JUX1zKIAfdSE3lLnnH1OfHwhI5YD3/OmZdH8+qsR3oK W4jpJ8sZtltBXJNNFnOb45prQ+fnzZ2+8UNSEOONmf2tkflZhVlBOPuy/Q3XPOXXWZC9Wc6F YILtahdTnyyuko9BMX0Chypkc0ekeYHmu5Ppws0EQBq9vDutgDudc00ZsKxjP3NF2os6MJ0x gTBQ+2Drw6nMobxmJDJwaHlXqBKef9lgbcOL4PY5h6uPwcrUn8lu+BDksOxAkaxPjVc/S5ye PfqMnh+gryP13NuDpwTzMl2FkfUK1rUrcCycCWRYI8FT0LD7mkqNyOljXwRbC8HQyHIdQ7A3 PQGpgF8g36zlVMY5nFriA831erqY37Wip5cFUsVOsHaonabM07jHhCbhNE7trG/mBoGDzwYf e/0rGKlbnN6iNuR9szJEw3F2xPpVuiEHzkq6axq5+ZE8zd/YnrxLsm8HJZTts9E5PvgNUlx+ +qKxnB5+df0JYgMJr+co6hU3bVPLh6FMd6B74g1b2lichZQ+XtB2AwyyAcoA9iGNJJ3Oh2uL wIOiFF36W+khosOEI5i/f1hCfaYMs9ShTDncN5465MO59CBqDkj3uZ7HHtj4VAgusXl0VFMi wyQsPeuAC0N4PNZv//lv8vFZ/kG0zC0z5ZDY6WWoUi5uC+CXzA1htj7MbocOYp4JsPCTSwz6 psNqLXGmrUSw0uiYcSn5fVCpH6iXOXZ2PZUosacCivqOsHiWxqP3ojX2x161sn/vKOU0d7B5 Ld2Ix41i02usPMOoso6MdAaCLLA0Mlm5XYJ/mBFXIY4Yv28V0SJoFYguUd28/0PC7nR0cQf3 g4PrYLhXzHIeix/Io548EArG45tC7CaEQy4snjmITjcegjs+FODuoX8Osczjhfv53eAulIrQ 9fj4rdccpNs6u7sNKBPblnSiK1V8gL4i+kEyR+hHd1nUP8uQvq6NK/TG4KCzU58qOMUrl9nu 1Ow4fM6h0FaWwjYaugcfsuN6LftBJkRy2ssX9XO1dVnECsZ3M8kEPpinP1sQalwNZW5kc3Ry ZWFtDWVuZG9iag03MiAwIG9iag08PA0vVHlwZSAvRm9udERlc2NyaXB0b3INL0FzY2VudCA3 MjUNL0NhcEhlaWdodCA3MDQNL0Rlc2NlbnQgLTE5NQ0vRmxhZ3MgMjk1MDI2DS9Gb250QkJv eCBbLTE2NyAtMjI5IDEwMTMgOTY4IF0NL0ZvbnROYW1lIC9Hb3VkeS1Cb2xkSXRhbGljDS9J dGFsaWNBbmdsZSAtNw0vU3RlbVYgMTA2DS9Gb250RmlsZSA3OSAwIFINL1hIZWlnaHQgNDI5 DT4+DWVuZG9iag03OSAwIG9iag08PA0vTGVuZ3RoIDQyOTAzDS9MZW5ndGgxIDcwNw0vTGVu Z3RoMiA0MjE5NQ0vTGVuZ3RoMyAwDT4+DXN0cmVhbQ0KJSFGb250VHlwZTEtMS4wOiBHb3Vk eS1Cb2xkSXRhbGljIDENMTMgZGljdCBiZWdpbg0vRm9udE5hbWUgL0dvdWR5LUJvbGRJdGFs aWMgZGVmIA0vRm9udFR5cGUgMSBkZWYNL0ZvbnRCQm94IHstMTY3IC0yMjkgMTAxMyA5Njh9 IHJlYWRvbmx5IGRlZg0vRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0gcmVhZG9u bHkgZGVmDS9QYWludFR5cGUgMCBkZWYNL0ZvbnRJbmZvIDEyIGRpY3QgZHVwIGJlZ2luDS92 ZXJzaW9uICgwMDEuMDAxKSByZWFkb25seSBkZWYNL05vdGljZSAoQ29weXJpZ2h0IChjKSAx OTgxIEFsbGllZCBDb3Jwb3JhdGlvbi4gQ29weXJpZ2h0IChjKSAxOTg1LCAxOTg3IEFkb2Jl IFN5c3RlbXMgSW5jb3Jwb3JhdGVkLiBBbGwgcmlnaHRzIHJlc2VydmVkLikgcmVhZG9ubHkg ZGVmDS9GdWxsTmFtZSAoR291ZHkgQm9sZCBJdGFsaWMpIHJlYWRvbmx5IGRlZg0vRmFtaWx5 TmFtZSAoR291ZHkpIHJlYWRvbmx5IGRlZg0vSXRhbGljQW5nbGUgLTcgZGVmDS9pc0ZpeGVk UGl0Y2ggZmFsc2UgZGVmDS9VbmRlcmxpbmVQb3NpdGlvbiAtMTEyIGRlZg0vVW5kZXJsaW5l VGhpY2tuZXNzIDUxIGRlZg0vV2VpZ2h0IChCb2xkKSBkZWYNL0Jhc2VGb250TmFtZSAoR291 ZHktQm9sZEl0YWxpYykgZGVmDWVuZCBkZWYNL0VuY29kaW5nIFN0YW5kYXJkRW5jb2Rpbmcg ZGVmDWN1cnJlbnRkaWN0IGVuZA1jdXJyZW50ZmlsZSBlZXhlYw3KgquNdHyaiTINpCuOutuZ KZazXe1GCj+9w0WdjpBMJnLjckAqKGCOhh2tWr4KfLFJfZu/r1EPzmzxWb1z4KQpN/jtqc2w UA1Tx7Bth7nrELOCLXs89p3Cn5lyTUQ8XlwlAOnamJRGqrJfqFQU5rWdEJWopXkAxQZdqjxp d64UmizybENFou/ajQS4g3pgI0Emx0/o1LvM1O408iOeONtTVg6IGxI61tJ4e6NOx2oOtyE1 SwrrI5/fhOf1xrOtXccGGBZiLX7lItQ6ZRpeUfJHO6ughMZm2wYicPWQo4a4pUyQZN7c/xn3 Vr4T/QdLQp5tckUmviZjDpTL41GuveMdGyRJmJSG6s05EFqy9OA1pEVWrCJTfOJqNodUfZOz 1iqSF2ZQWDnwRiFNKb5WVm7EpdLpV9HD45qGRm1WY4yMe7sNr6VVVG2QsjBNnr1nnyq9/LZ4 h8N2Sr0r5gDslnu8a4JMIVda93Nq9C+tdwGKktbZjPUfPs8utsNg4nsLBu66oDi4tgwzShXE +tdpA8YTiTG+/jMUE885se0COMdyfMxomd+aRPydufABQi0JWSIwSCOaYGM06ZhNq6J5G5/h KWrkaUvnzbyShAH0wLGCpVECxe5nNuZz0KZ4Voowj+MqJasiL9jSrYxxgEv04gznL3lHxfrk AmmwjFvl4jLGRZs4Q8BhEysDIvMtl3pgd+WpTXzPLhyg0BhUxBACJX6S1/hp6s7rVBiQ0Z51 P/m9RAzUEfXh2r/lf2Xfpi9WLkVKK951xP+fuwQ3uv0Zm9lKN/t11hJm6tUhMvy5iPaWtIE4 ut8uPr7rzapV08L3lAEzVXpGgcCPfP9PWIOaL/Hz8ADv4DrEGg48/1P0aPuqQj8c5NUoN+ru OzpSUToJW2CZ48Ua+SbIbTtBE2+66j13vw8T/BpfDHt3iDda631D9tUkPSy3tjV1wmutixG2 E0vPW7ADNONo+vC83ZRlHmpBdX7AAeBZJvf1jlKXocdBG0+YE8MRtpJBqjA9JImAuRIRWpcV T5s07q307OMdEUWhoT2kBwCcSnROqDHYUfsIoVkNTb0YAgx0LLCJT9ZnnH3RqY1GBQ8Bkd3k E4ZxgdRHL3QrK+Rij9y42hlKwFYWtxYgLsnNCZHrrz1Du/wHbZ7bSZZtFbGT0unsBpRdx6IG pLhIwlk1I9rrX0q7XBHJiMCuDqkeIT4fO7hrqKIHvI+dRwE4OAvid4XkVCv38FH9LjGmOW3Y Qk8uV/KkXpPj0kPTkx9SF03wYZyjQ2FmnbwVipI3/2Rn0SgSAIKT2GniVxihIHgPM1Kwldbt dLKnQM13APGIlHXtfdVrt06m5RX3jy/TaCRxSnSMo1OWPAnmvVUlkuANGAOEGqACJ/AfvIJS iyxOimWWIGmqp8MXp+cvAAkXuhDoSH4jxuEh4K74Y1EwmkBb4b888wDBgSPYuoRWjC1oz5TO Gu1ZW/3z+rDqDRWLu2X1Cr8Na5juU+RXvUvQ3vUtZEiT+GTF6JPFNpLEuVRQEnSoV8vb+3L3 fNDC6tA2W1ihjE2usUIF9HhKkjHY3haqBChrcjgS41ICJDHepUQiNmQi+1eHiEPn6S4lvWB0 VLd8bhSjzbYyvuns1DVysm7POf9BHftHi5JdFXtFuaGKVDqXcbqp++Lzdh5cZSAB+zExRU0/ /p8A3nDRHT3vl5Ex86lFgbLt6zeNSIwVdtjckQDQCpkwRY+q2JpcqwuaXKaFPRPMIUE8BQer HeQ5xglJzf3b9hZe8Vr/FRbbuNKPOtYBtI+n1UgpTig8qbx6K15olF2eIoRRUo3umIInpesR IJcBe/JWLE4zuSKyzOGyJzma15KdaxD1BPv/OsaBNHzniSPdE0iDkzsePNfE13y/79VQgQis 2raO+51UfvKL5Qdx8gKh1CgJiK7+f7grqIeB80VTObVdl+RMvD7dD48xe5atcUxZwu/mB5a9 ssVppz8wq8VACNH3cyIgLeMNRef7zeMGXmc0Tp8xfLWHLhuzeFZG4cA1Rq9XUsQ0cP4xhINC FeVmBeR/yfCCa8fG9CFRRxiFsHBdzYUYuFxbOPOCgTLUptaXt6dO7NpVQQVVk5tyW4cP5g1k Bn/P7vTxZeAdDIDSD1+KfDRyEUV+Xq6jAMoDMxHCyiGzSFgy+YKKh5XK6W3P9XR213BTzy97 JLTc3auleiW4qr9qL9iwTBfHnWvePg603hkDY1pCqZfTLsTLxkT7Juoew0aOSuRnq6+fOaeb iUlO3JKhkWPHQB7uJIhHCGMYnOz8Scs73CZwpLrNCuquMK4zJnDzdoU0UAyDlZQBeVWkMxtW j/YahkhxnwM1hyuBLIMhdnHYoTFBAlyOXv1iMw+8Wjyq7kn3Bv6/YfI9sMMnhtR4Jccfqd+y MhJ7ShtPgH5OwLNYSbGNUGrWRdHhFOoOloL8849hMHZR/V6qbaplElAAEOG7Ib2ki59FtLGY VLCh9zlZdaSBbsDiijpAsF8ytzO9X/X2Dlvrfe5okJHCfl0fwBAsaeh7ElrVXfqDtuGas1BW 2VaPTr0nBqTqxWsJytzNlJNBZUgTjys23MuH88PPNQ+D2Kep1ZYTjrxXhWgI+G5kAjL7D37k +qGaoQBVfEcIT9nPHLcXOp764Dx5j1EB5FODNbGHaewLbK5iLNga7cEqdy1y4WI2p+os6heg xEX8mSfPckNa5dCmTDcygJvd2lFG8WnaYEaCQYMzWfs+QsXGLyHzKKq0hryZ+ZSa5DmCbTeE m+EM7XniP1L8jonEdrbEyHLf2aYdd1al309LZrPPNZW6rq3SEEnq4Zc3CEmzdfeltKI4Rnh2 tEB3WFya8u3IoJJ9awVRfkxjkqqhX0jFcuhoVCrqHEZUGxwt7BHyjf4aGnkCEGyq2uU9if0p U1J5yiZh0Vcy/MrwaxhPODFpvVuu6lpDowiN49XLFNrFADeFZpEN1qXMVQgpkPcHIIV8SesI /blYLueAiFnspLxijNywUr3wfP7sr0EWmJWv3R1V0dRL3TD/VJwQZG2ql0jKVRqJokSXYL2j Xo5dtOc+qZEbgu/0fIbQs78A88b/wS7HK12Zg4ld2mIdEyP8xFaRhX4jRYOHLiUlH9nx2Im3 rHfzmA44kOLsq4zc1uFW6uHAPqsPpt5hPhV7MEnc+uodfbXQKSjJq4tV0H9hBf2tx7dD6yt7 2Sg3q3MxVr9FNWbc9qFiKry0YA22k5FJ+txnL5/YuDIRiEI4lLTFQzWxe0JzwC7pBdzeV4fP Os0gj7DyTkfdjX3EIZArnJjR1QHlPgOuTO+aQxRBndKzQfWAUGRNc0qOTN9RHPHJDntAD/vw gtflL+j6mp0QIGjPYzT4s0Ixw5TK4vQk/D3ZLOOs+eCDSrqM6ZUu4S3ox9dn1K76ud+unaFr paLej3iChITSkjQsdrBPWldpAA09YceFVpRR+/ReiBvHCMVmel6S6UzOfCJDRbl1hiaTasYB WbGqofkmAOz8tKPCoYnvSF6UKLeVYJ0N5dQ3zIMbllgjRzZ70y2gLDR2ZJuKwt30L4QERJz8 pnABO9Tjmnx+epMR7gUaebmCTZcuUX4NmBFXyWSm5cC/y66mnarafk5dlTJVGipSVdSB2/2/ 8+mpk/AbPjjySZPLeRRVT1tmcBgDZ9DeWmMUhvsTijog4mXQz6iTMZ/HhhB7BTdVZNTiF6tp PvN/kIbyYNG8otzmkDW8qup/NjYAZwuupS2hN4A7oqcAcvA70lpxMTTNEpkKI7lOqpKEbR95 K3UE/FZLzyr9VRK7g0Vc2+rYY4CDejLosfF8gNjw8CJe7WvGDfmmB4pG40trMjgJMN6bJAHz Fjj4o0ffr3tXl7MQr+IZ8EMBGuV/DJzhB3a3ZYDhzfWnhPfU4yD2mtsBuB98TBLcwYJn7eCA etedafNrsgJ3/NpYV03Wuo8vg3ysqSxiJjoZFKvjhSUWa6SF3v/WjGLDtbk2CYhcDsvIlEuX iutwERlbeBKnEA/VJ2K+kvEjJMM6yFsa8iJgQhdYNRVUVlMU3qbx4axKUkJJw885tzdors58 IEWXP1HoQOMHGemO5stRdJfn9fUMCEpDpSQJ+JaevVsv/rjdzzLZnUKRTR8cYlfQNpRXVJPB SI3DRbPDCjAWeepNYnOtcKdfRji3XILx2xzSAvVl0FDeG7di0gqnaDuIdSvh/aKTl4zbwPSE 6mdPxmH0aqNkSaRkLrS93To60CFcxVTKDlV0hd8M15Tg9XTA160DySWGrc9Y/tBf+gIULKwq C8226OPMTBNJtMC/L4PHzLmOM29SRNHEpNIqNEJNdnVSTNAZKdjGV8wkpQanqzSuVhiCO/jb YVSJLt/OMBh5+xomrtCQAr+TfL3sGJwHeBJfGOCpDTN8cAx0w3M4XNK3GleRg/p+Ax61UiFg Ol2qQAYOST4gcsdX+cdwUKK/NLIqSvvUWhjMK1OyQv0Fb0qSSKSJ/ITYdRYkuS4PqeDn42o6 ftYeof+5zaTjyOs4EQ3522kzFxrxvhJKfws6h3j09menE438FVS6qGwhjCw/Fpe+vm8iO5pG AQgu9zPWSNCeCWKwNnOliIurpZlYStcKMx5Ed/6HDrWnxJbLbYq7Pt2Vkzh4cyFkPqimpVEa S4V4F8wLOhPc9PO2njOOpXLdXkGZd/SKqO3JAdaPNJPDKmZ9aTZuQ6+FrswJP2UPhOaVo/H7 beL74dmUbzQI/G+SZSULQH9X6Hcc6AmmBkL9RHsaUS+DZ51ItuPwRi3pLvj40/OiD+6tzvyc x3EtUgXFUEq4v2O9MmvRSG+bRblLOgF0UfLUkVV80KHQtwwGC4JM3fawYjX/5TG6k9rYhNeb v1A8BwxjoT1abQwq9LYGfn162yanFXG5fPiqpeiu/jY34xeyZ3PMxIogcZ1l98i/ZJO9Yo0e X4VmRwp5B0axbxq/3zb2F1HVEFTpdQGOtSWJOtsLjvLBizdl9zek9WbGxASIPu4/VnQQw2gw 8cD+xS4na8Pg/uWsfWr2A5t/LYFcHInzakvJ5rlTt7Lqwx+himALsoM6bASHdraKp+kr29XU 2CmFssPHob2+gE2/OoJq7AOwNJc7+ZtSUUGtRwMnbV++ExyXU3cnA5voqAexOqYkySdr5+pO zX507vfG1PfPrpp1hEhHEr2W6TEHup5lvDKoZSiP5fn/s3pExEQQRXJy7p9N/I3Z5ol/4BMk 24dpIMqRxJyKTR7EQndpwGcKXUGEmtFjMUsjRcBnJetvWQO6kC22h1z/tjEtmISFIIook9xd Q7n9l2IeVT5hHZsUeqjBiCHT1TnGl4eATEAgou7pBicQ26DvsnNfF1h264fXlVhlGJZUd1eu e0szq05RpfelcOxlUlU2vQMMX3A6Hej1yKNSgvVSvZTk0W3qroRBikTb0+Qt8T2GMdeRSfR7 WC0cKQ5gNDB012t1DkM+atN73VzLGvfimEsdLSGNcVFtio3p2NRLO0FIILkzjPsdEBuEO6oh c9onh/3mXUDEQUJkwGtr1U/h/ASZlUjoKcv1emtrPsRgcL93WubOlqh0LlAxKOl1rP5ePE4B 4ODLQVVPlegRcp6Oi3POpKU3a8oijUgTbae2oMExwkocAfkNuQI9L5pZtQldVvENZXzlpxz3 ZFc1vcX2J3Duj8Vv5RH1lBUGDnHqxz3x79Y6oxr28SX8LnOKddfHIV7EiNvwX7afnTLsooOp XtiXTacoQtl2iAk1Zj9e2mP0ytMbY8QLGgpLaMfUlYSVm8jL0Hdrbzv9qudh0aZD0fNMcir9 FFLcJQhx7RhKn5rlFjrrkA+RoyWubX/NzjMILcOsDIB0CGaEJgYWq4mNz9lE0qFgGIe0MHzU BoSPbv2Mz+cg/zGgPMgk7VhLS+RrwRKVH288wHfcIC9lNtEPoQ0zVmMM8QUh70EPVqgOO1Xc W+yzc+ABd5a6lhIt2mtmRizOX0c2kBiRSU372QyVcFFemj35ictS5/QlsPoCVoTbQqqhLCnk HznMcuuoSFKBz7FN6/nAovxuUZMm+fHnlTgcdmK0Ii5QKhNKxD2dBoxU2cMDNKzKimH4wT2a s2UV6JL7OfoRsDztO2vWvA7yhx0fi4keISVDqaOTL2Fso69lnwwifXXvY8JMePY3532emC/H uXMpUIonx48g7MnCt6EVSHbhchgD6Nr5huFQd+92DgXV9gUgPmYRmHYwYRwDMVock0joqm9M deaAC55bT5BgqNJ9MJw3HUdPXw4SXwYhjRBoCQPz62RIkQkdrTmRP08YU2MlwBuUxpTUJsvO i91nXNwxTVF3l+x/vR9w8EzmY3cVQ+XHK2xgxZ8X72xacDa6wFa4o6QgQMVw/AwTCHCFxNC0 a6yrbpWVd1ekdpMk1Xk53aBiZ8Aq03ITfplJSqnd7C78uwPhT/9NJDmS8l8ZG66uxEVAwKHH 6Hf7oOzQ7HE+SKcmg1FGTb9DfEadJwHcqyLkX9ObnERNaIyp+LDRuPAYhmCwg84shoUK2weT sKrbA4vsSi9nuzztzldsf1eiYwhDqcrC4pcSHQ/2Zg5U53A2L4brZioWWeOtSBf3EVAlahbQ MLq/iAhcbl3tk4BAL6JP0NhjhYHh/6bTs0tTfLfmcULDaAFJ56Qa2FniHe0XhXLuFCebqNHJ iQpSnZFvdPH1i97v75FHbuPHSKVXFyCWfi4YTg/fNFs4lNJhkrlUNfBaoqZwJmcANJKfWJ/e VT0MPwsj4MVTxojfsG6AT+KqnkiGbmt7huodxcqnBLltT+E8nbqJ0agIfQxmo+i515+YeaRO UbkT0p1mfsC0hFT0/JSio0i1RC+xRA784tdE4LCydZvDZYXlXn7RfiwyljFtJBtKu9ObC39i S0yj8MBRrOPnkv1sNMC2Zt6KUjWIvOeKVjIPcd5umAh52aPS3WE+jGaxVpMVV/6oeyL62Por yMS6AQXhJQp9P1TQhgmaai/rK4IMXsUmFS8NKXX//Ug8rmQxsI3370+U5z/YADcxZSdPx670 5JNlYdubvQ/VMNaTmPvlM5igl6bUL0s50em5hVjWAdOXe+T7eTsb0BxyqelwsKoRnvEAItPV jMf3Ai9i93of/xfBaIVpBBNMeaXn/ivBnUNDBSUV+WtXt/u4V+tBKHwN2tLUcT2CHf6D/B2+ OmdcjggjBBiCeru7NZWj9wBOJhTwxwMO7KbeW1KVRG6DUau7UA5NL/7AWAL6saeTkzXloUWO iBg4r4Lb7P+GP07jWN60yw9sbT7bZaAGzvrJ5iVOM8/+mJWCrVXCfLnpcW5jDdbRkr9yk2/B ocSkHivcdQYMEa8AYaadyja99gUR5R3D64+mwfByA8bIdVkdPHeSw4zIyIGMtQcM040oLzlM Q5dUBsnc2WIJ1TrKARcAuv/a3xUK8cwIvaTFdnKfxLX9gmiMupcadkM6Fh3sGbAaQ4dxgpyb RAXBjLkapkc27JFnD7eEFNhqtca1dIEagN6Dy0iz2wVevbFfj/39pFHZGjlw31sPdApSYVSl bvig8cveb9YmtcfELCj91zpfAn+Y/aq98n+iO6mhTl2GYdQL+r0whU1tCBUOIzLFaLrLnnS0 FXH+//cwcxh9s84g7kPks4Y4pSbkbAnlEtdwag/NH6nhRZCkOGmOsnZo7gYMvUdT+PUnv2lV vp1wtiZgpYh1or0LfF7n+bCvjj8uYB4IyMBv3gFxReUUcZnqKy6ZL80Jv7e+ytmzVPt6uqsT pXnUVNabrQrW7WKAOYrGVAbVLXk1BMjs1q3llbPjA2HGl8L5U4m6M56urc7xI6QRgk4MXEqE yYs9OwcjAyY8JXEq+dTz5o0fUz5dqH4tXOylrMqzvXKXtl63r0YKbxmbjtUerSbJrb+3XELC cBYlGYGC9wo4sScQxvflvqRG7vi049HNOWgWET42JOjskVV30J3lLBeRLgShYwMMhM80FXhH 9YXpePLoj7u7t7L4i2qgtG/q9mzdg+r22M3vRX+Co2jpZLE2j1YvGAG8KjzJ0wQlXv0uhG/X GA/fOsE+4gzLWwFn866HjjeSGMDi0J3+Og8YNFquLIa2v+YjuTOLoxrz8uhv5JBlmcIR4ne/ xXJH82x7TXIjob4Ru5YOes9VBoyWIjU6tE/UGLX6Qh7xd0GMokSpewJQOG85n+PwRmuJItCb cumU/LNePuN+FqqB8e5SSUTqTcn2vJZJfmV9G3WLvgg7eOkJruBp9PhbFw4PtUdEJa1+3yV9 Q5c799hCmpFpJPEkZAe232TfELphCAmNRAChFk5E3jbmvY/MyZKCq10NGXmFKaXQ4xS0gmEf tK96BGEJyD+YsDOWGGcGsgZ9t9RODrNJcSbDcDq0z26hSOMVJ2jLslCvZvXT1iM5fnE5+1tl B/fxNHb5dmFXZ3Nv9n4f54AS1Ago8obmSMqb54H412uCllhUhOlLDII1XZjg2nnhVVja7rdI XU1yuJLNG3B1HOFKUBTXeHPblXz+wB73hnmvTABHVtK8RTAAshikJJwftxYVWb72Jlurvw43 /QIIXOCgGPCQ4hJF+8rSxNJi7/GVE2qkyfIaJvEJRj+Zi6xLuhP/4Oqmqa+rHr/7gVTcr2DZ q1TjTohrNoBWwKdcKBzT+iB9tG2imTF284ksZ2inBhQxiNwiItvaQKzlV4N7thWcW9VTjL+T +FsfuQ4VZRwcNUaUY9yoF9gkGdb3pK/TQb8Wli5Ecb2oSE7mpK8VpaQPa8PWT4CZyKFE97hI KIIiocdIE2riZLCTWmFgwnxKFvjzoDJehMszqCTrAG3XbkY2y2qLR3QPODChWFw06/kfiub6 0MgVmvoSjmFSSUxM2OcR6YgIYl8/PfHok5ezIe+kbrHrlH3DtRRts4CDSUsPMep7+vlZ1ee5 ksAklpHQ/3Npt9lB6wBi+zx7tAqT98UaRrv5kqumaY/z5JMYH+5mYgA//MhvZTPRFWzQ1dCy 804bI4f9Ymi7XyvPIP+Io+vKR2njfvWs8tF9jSDgAnJxWWCSAEOpAsTlGCTVhRWpkfSLf8bn Y1/LHPZSsCXwp1QrjBsFETo5h9p/t/4h326bsSwz8ADyxIHTV4YvHSHJrkO04hbDg02leMeH k4h4Ki6mSmE+g813Sx7KkBEVR6slD9GN4jG4f3hF9cjYWZMP0jw11m6qJ9Zo3eRAjZYnRUBh SQaK5ijDKDybnzQgnRhF69XQ0jbG/oxRBjjZX6PzntD3TqSPUu56UCdu5+w9ymTWK6PRn4WS fjZD7517t+4YiRJTUH+o9pNCsioC8YqSN++dPItqWzkiXYrAtXibg4OMJ0H1yaDuoUWmzLBS CE49ctsVmAYcL45B18bdLqX003a7ZgTJsn8rjHXoEg+FBxFHmIZx7LPEFKJf4iSknS6pHPKY gXbicnH1NkVQcRiDXC5fUwm4KjZqRqO9YksYhlwMQpTWjgv9gRjRajhp9fU+xM4SFJuDf+rp ddzHI57PFI7ejD1ciUWv+ZQCoCU0RIDWZ1KxmK7d+FT97LdUHlrp/vgEqvOtKMQnFMB53nLm KmGvxHNABACClar/wpcPyvwmakQ18juVGa1qHtk0IpOJn8NnVxb5GxsI1XJFL+6jBr4cIfaX Rssxm1gFm/IjiKnq33Tka/dhP9qloO9NWei6mJBy4Fdkw2OKFxQzMJgUmxvhrF5wbl6w1ULD ANwYS96e2cQonNLT7m9F/IN46cVLWRDyYuajDaoKz2S9YAMPWyvhudM4h/MC4wLtF+lJ7Mt+ OHNBbkmDSTysJuM1vwkJYeMrSEgoFXXavW8L54ZbI3W1rTcSx3GJhR65C2Y6eMo7y/bSsDhn Z+1QKQ+iDnzth7KQXzcwP/jN2W+XZQPAHht5oBoPxNNYRIG5y3xyNWGxVlwjisp2nMOrLB+/ HsFT6nbHPceKvKSi/CO/6F632GNyfijnmb1A/VF+EAISAmgAk9TvMqyOWc+MzYW9s9jSB68v c3D9sJdtB6Hua+1VkJdGMk6Cbh6R/A2LGn9K+jToAEYQG8hG0AWNt313fOvdIt5IFA1jybXo szjYdfnvoi3FI0W/prkVpoTPMS9l62SFwg5cWaO8DagulL8QSlDFyw4PDGscO7sYP+9pmrii aWqNVHOmyCBScC5czA3iDPjMi/IUlO1oK9Qlc0kKufKbDc/00yxjNWYiozqxeF3cklbdK/Cy q7xqUsTvy5DsYpqD8/M90bry92EG+plTSVwpVEcDKfA0p0m7JCvLAP+IkNzGT4fnVN1R4G/v 2J2ezr3RgSqBEqsdEhjek3PeMipRrGWj0cR8VrxSCrOCUjnJAbA9os87+JLUGQCmjh6G21R6 Hsh0lI8tuu92cZ261N8VQ3LrbtwOe9+NfmwwN26GdHkXP0qT+wRirElk6XaaCHldeCT/iCrk sgPs9rualjq7xoHY6SKT3CtRB8rcC32fjXoAZRupCtfPOjVlbhUCbrDQnq5PxORzjLE5EH8G Eb/InzgzLgYMgf5ukgsLAXPqe/1uSccdc7klgBeQnBVmtU1k9FiXlv38KTfbv1AYicLQm0g+ ZbSvZWetPnx8aaa07u7YOFvHNCoP3K74PTZdKGMglrPSjup7sv6TOKCevM7/EBEXSJYWpbA+ Jn0gc2RDMUHAJLALxZw7KfB3NCD8ikV3JkkTHV4fovxPO7aK7oKLrccBRkRjzTstnR3agz1v xl0IouvyRPwwvJorssxNxFH5wDxDEGpvVZXzwBC54Qtqc34ivDwv0wEGsCsDQPWvIA5LOF9r Lsr9BJTjcreaCNGXnko/eunKjuQBDz/i6Q03KY+Paxjf0ydutsvtLGJ/QU/Ohe6Meprit+bv 2kpXVMAYIc0BXQl5G55cdnV1jjgIQrktJbfuYTdTp6UleTfuX+n4jSF1BEniFcqYi6YUzxAX KgmFk9mYgNR6/Lb4dP0aL37ZLbsE300Srj0C2qiNPRkKV94Oh/p5RoG2CIzbPDtn8an8f7wr NJvGFyNZqgJdm5YeZK9vhBq402+qLwDlmKfi7YDoBjRUjoqwT+Ov3Qx8hlHC/EYTgQ+iShLn L/zg7Thzf1lVjHmMce36yFUT0HcwGwfylXuueWjLz/DuwSHv3ZYKrInoebPEKqNdSehQqPuK 2xb1avazsK1wfuvdS2ypwsX2rxOL9NzUY+p50RFC8sok68tw3+MDr/1LtLXHMWFsl3DFK/jx BDNXamOoGIyj6Vkkb1xdmwjeDSnu6tda++1EoMJ6j6fsQtvfMXl6T3fFs2IRHq4ATvgN5UZd 8eZxq/MriFj4wh5WR59LsoiwaTRmMKlWN61X9WspzJ85uTWx/UVAk8KjuNv86c7PGXBRG1Xc 4aBKuEHx6XMSvrQBKNwCoL4HWdqDR/UoQbYtzvXQCfstmMxxCkTesdotL5GR1XjJLXJ9lmqK tuqzTASorMAoKCp6RHBmdN2chxvH2tj5pc61fFRgaAyYlofnSd+ekD6Vjgp2fgEyGQY/me8r V2PfunZATtFBkRAetyslFZIXqFOPe9NUhbu7d50I4L6EoCXK+7OYEigj6Ss5Xbmf0ZrDXXIm pzSyzm+q5OMF1uQ1Pec9Lw+yFqRg5OR4MEZbQL6dPBFF9MoUhiDCX2cGrusJKxciv+yyU45h 1MO/85L09HhAlsH2AZ4WPDaaQAHi8LUrKkP4npG/3ocSF1JOjPPlgoJxG1htWMhl3clsyxPN gYpp8rDjGDkt+A1w9pgQIjaQtgBNr3HINdFEbq707+0ahiU3uuzuJ0siXfKJLPfva+95Mndn XlG1GJo+6UCnhw/1pn88gd1HlbfmUuD24xpf07dKlSxu61Dw3uWYRHNJ+o9XQUXgY0Nh8fLa +myhJKgHcfHIM3ruH9J1Ck1Kh+7TuC/BaRapDjj9k55KOF4HE9qarHB4ZLb29TelplSkmaev yk5mNaOHGd6P7Aa5y5EAF4vZJxNmWKqdIUVia78ehoopj+93wYJyO0jJ+nnDt2/0M88baY2L 40cARwTpv5WrIcMCu3z8k5bBUBJ5ZfsTt4QLYkQh+jRrPUSiXCmdKHmkDy9bPsOpkXh8Ap4S 4ZdCLF/HDwJdQcFPp60QhteDe6rTtTwDwqVCB4noA9B0q1eveh09UlAejP6Os0kYPJvuz5Py ZCNX5jiF34GH1zUjF2Qrr7ji5KDTFaNhFeU8IIkUK5bdfswG9p1Q1/eke2dCK4Zph0KAyrcr nFZE/Bb5eUa2xQ3Q8SmMRyjJzv6IfZc+29h/tx5DUdsXNBfhHBk/EDvzDCY7R3pwTPKQK4Ri nFNKj603aVRy4AcEVwSOw8V0d7dt8+lGnERQvjoeJkP/dcnLQ0C+px81dN69PxI/JKuWq5+0 9RvPM0GjMKT3avcyp2sCGNI0mdE++6OScN7ULay13XvuPYia+28PIxJeYT0KK3xFcgsd1rXn 7C380LAOMS3+Ll48XV1Wclx3MGpIP8uTDhcjtfTaPpCwbD9RDdgu14OXlH/vfTeloXqh4kQn mCiVhMPplrzcGKwCOtjkKeO1nO5OPTkdOgO1ibyIP1eNpVs+5atC8Nh3P9CZsrN9pu4eFl0C ZS6hKXP4E+pB2NxQSzhisjhki4jZ4cT4RpVRYe3ypoOT2xgCPW6jATEem4N/6ul13MdURTkT ghk7x826IX/EtTqTuWPoyPXIk3kWEF2RG+suMm+ST24aeMSkDsE5T6KtXLRXgqiR5GY7bmV5 nOCfW2u9e3x4efPfxEZteoojS7LekaXE1gmWDO7cJyhkDPanvLzNlRnE3Cs0b7AZVh1UrJBz feuBTu53RS2O+iygaa4FQaSdxvIi7AQzJQ8NI4Wec4PzaWclXZF8phShviYYJdK9Dyqp4EJn 5BMp48W/0A+ERnpjVKHqL86hNmu07qGpKZAl6419xKfSPpc5A/S7rjO+2OSMtKftyXIwEYxL rNEBFory7GMcSKzrNuWOFF0J+V+5vvZkjL4350g0FLnFRBO/96tB7FZgFvBMzItPJto/OlkX 8L1g/pgEQLKunD7V4nZ1V90DffglpKV5yBDstzd6P4vVP4/A8dMnQMwKl+RucOesKRZxxLh3 7V56anOGdYi1tFTWoZb94cEKLWd/oQOSAwoeN0VLVEtsEzWwIvfpV2Vu0Mei/ZeXR09vmv17 YME/x7v8XhKlmzIYC1erY7QpGqOJdJodaVq7egLUKLO3TkU4ILWppd5RgqeXHuYjo265HfBG i9J/W14TpdZzgKP3eNhF50fJZARGZq2fiYJUj04zt2De51KZ6bJpplU5MutonYv3ACyi33Je PEdIJRBb26jcNbJMUxJ2WqiU9tAJWbYDPy3xfsMw8brh4AZIZGAQWlFAaWs3k+7RQsbLHetJ wWvG51lS+C0j3uAu2T0KPTT5cM1AC149MWb+oqw5qV8s+z/Bn4tGoa8Eu+UBJTcpLxzMxfmj bzstEvkH5ZGuyGETZ9QysQQOiGSQiGRNuS8mgXsyBwe5YLBWXYlXxiwfRpUCLglA1BpWZYj5 U8+VmDng5+PFodLfM/HU69Q0Nb/gBG75KokGeHIjrOgj8CePPLzq1Cyz0uV+w2Db+cOGdkm2 SbERYi+jIHP/xsnCG9SI+i1xh2Y0W3vLac4Uobi7g3ayNbWwcpLbBScKdjJi0TqKHg3xjQFv Q9eicA6GJN61QOvgLDBE7VtK82/aT0biX3jXK3xyQHC2rioHVp/k28ScYF5KVIFxfs1wVc5K lXo2G/R86rBgY6QoLNHYLW++74FAH8V8SnxDkfZso/GKbu+puqyu2ardDHyGUcL8RmSgHu7S qo2BvH/tfn9cviiWio9AjKQacZf0KPn/SwGmI3lF2SzIx4vfZ6eVD6pCMREwNS9R3cgjIeea XAxcT5W0Q6vOepcIgxDw/JB12EpGXatdj8IcC+lpzWSZECmjbKROZ5uaQQPVayZQYApa23F8 wMYs7h17KH2q9g1pMnWS9q0cX8T32uVqD4Q4aZgmQqDYg8fb6DdRnCphPKC/zI9Im+5ejjYb BnM8dUX/NZp9ZFagSi+0xRw7Q+8XRZqdVby7FP/W1OD/sLk0ysc+/s4RHG+uugUmxt6Wniww 3XHTC+sWVT6P0tY00jukfaL4eRi3VMAPJT6l2bcUFm5PWhUuAhdB2LVzwsZeYXPwsswSUhG7 Wp4z/mq4jrbksO1+xd/hGeHBxCGkOytKuSFpUqqT96eZOVT/mUZtPqoVmf06Y79PuXoWihsg C7Y7ec4RmH97v+e+1uWQAEe9uCFNkg6Rjnq80mc/zONx9FQk1obEk9+mLNGVTsji2U/0aN2D beVcwNdia0IxWpn+d/9THG2xZ3cTD0V+RFGsWp6fIkf+euQWjrSqFvnNvFJXBpYxxjQO093h ijArts/puBymg9jH1t38DoeIb86JWyR4E3JFBPuPIpMXme9l5tx0kKopaaNz+B+4LSsVe57M SfLDhcNshcN+A8hgnUFvpbMRYkC/oCQygX4PXKzoDIRISWUWmzHvb2OJW3A27IkvqHl1jcRI Cf6dWkWwxa7v79kAkYISh4meLLlY3ut8BYPBryqdU3jqSh1R6VlJAuam6YV25277DHjHGMQJ xgm4tyG/m2NIsumwXC+sypRSITLwIR8d5QcBVFxPPUDG/a3qgWTrg+FDPMSJkjhC030Uc9X+ yAJwm9j4wFjtO4u09R37G7o3cxZpWMFz0RRY5e4IIk3VqCarbcITNai/oIMQu76nQUugamzC pfh1jB4jpWIyFU7UeiDZc0w7WmsXNnhO9Zzw6qSUtsrmfGtNxZRTLEsFqdBUfOnVALj6/7JT 3oswMDoFfNUWSbitXfPaz3qYLEuIuzdJAiQtWztLr+8M705LfVvT9Irm1Piew6JurEf8cBs6 IpdALdGXnTt2y7w+lEI2O6FZ9zGp0C/bVaWaLNb8mWki2F6Z+zp1qAk86V0TbSOQow/ROLBp 1HUzneS9+4fAa3VbeWiTVHh/8FLNK11ak7N4uCUDorR/rAYINxulLFGS/arCKOL2oT4R/6R0 bh5972Gxbbns4AeZvzCzhOI9A/0s9p7rTulUhGnZi3Pl/TSEuNZXwecYfGEJQ7JMlf5pNEEg h2a466jUbpFULjj1sUt9DkjNYs0dYDyZ8UnXeYXtcScod+Xrgu0c2fXzzKKQmWErk6XQB1oM XddlfVjGP9SN6O5fNJwZRcAcYod2LO5IW/qIEcq8z4eokBETEQGpLS9/wdO7ojpy0oqv29aR Q2Y57bgGpJJG5uZ9s66rPp2VMZxXGZjJiVicVtVOYaCjY/3oM7yjC0b8ekdVh3x2laDQlP8i HWDSFPUVM0HTO7vLrrIkR6DmEyzFXpI+/OmbZNEWYVMYSHUMvy44+XuVcBKCSZjnz6gGDNbF jz8xgxC3L8DvDunfaUbXP0lta0YxzHq/xfJ9fNLhRk1R4qPlv176mcyi42PxFzHy6wGrBfac yzU8n0iA6AKlshrUdQHtBZ+I5BCr9QAX7VFiDC5SP5RPPc5fghpN6IJUxiGs5Hj9SfClnSkn IPg1yqaSyjsekiq+IvH8CgcIc7OiNGGhxsRcdqqhQFeE3Hg2V63MmZ0sB9EtVwV3aiV1BEji K8zmhJbR3aMivs94ipYULAF0RXpw+o9oN0xhW94xU/ulXD3x99uHiORh2Zj6aK6AT6VesKYu +rVPUxNVq/kQv1DEJb8MbS0NUm/5XJ1M+LIZaPqEYrDgcekXMxVM3vrJvOL4zjqDWygYOrvK Lb1YFvzswIvxOQidDoH/aBjxT886ZStaQopTESd5VTzLYwPbYAl6SVWL6dImmOs8lSJqUsc0 x+8wWTtmqYPYpQCRhb6wCw0pTGLZ0KkaNOPY280sneywOXnqivIUxtwXdGVRq2ThbexBNdQd Hm3l9mtAJjmdkYBJbLH71w1wqB2JspwPPmMpUmxkyM2UVVYUFoPaO5UOevEz6v5QKXdKdWGQ 00+ZstY34sabkmlWRdpipB5zoEp1CoaMBckt30oMbbvw2Uzu/dv7IfApJWuLuvC0cVTGPD4C 4mZGZGppDlqXTAY2x9sLze76owFIpoqe+DSeFAAOQHUNEDWCEfHGBotG90EtBpdP87UY0YDU O7hFITVWM7d2x8dqoMb/azTPwg1rs2CEY56eNZ6CVgfZzq+FPEdYp7h1ERNaoutIjklxBNaE S0qvIFN45ob1vl5FM9lIKXwDgisuLCLXONqCQaRB3VO4nP/g3Ln69c91uFxRKLLg6A9ncHR0 i6aXYWufUi3UDNjDSA7v88N95tYSMGspQkZ3gSYjimlkDlk2dMNMpzH2in1/pgGxF79nhtW7 PhinT6KJVdVDaZgz2RwSuZkLeoaHxW/HbAaiOXfxaesBC3gNoSIYANshw+Scmd/VX4FuKQ/S rJ60+KSXDxcRsZdSNYmP2C0k6kQdOHBRTWzxxMy+Fb+Hvmw85De7PnAo16yADXv0JxBxkhMU czsf0IyEfTc7bp11T71WWiafseZCZBcitouVAlTV3MkXh4og96mj3YFPzOdPidCMzwcllIAE bTY8GxGT6xeRdlh49njgzlTB4FKsDs/S4uv3WfbL2K0bJJF8HspKpytMeWmPrOz/OOVC+J+7 +cOVuE5sgEnUqEMN0Dj+Eu1rffxTs2V37bDF+A5tj6ns4TbxH42gU7CCXD6bWacDjiGpsvBV yD1xve2vKcmVFtmB++J6l0YSzJmw0/Lbxcsv3ELg6S01P+kq7vC8n7lyRIQUZ/8Z2MlLYLLT l97GKr5ZYOldGjtKLfQLk4xC5TbKtsBLvNhWkdhxQTc3JbNI26DbFwOnV8XjhgMtK+VXy3Ct OcfLcRU9qv+W/hoSpCDpllykw6rL6QSpd87hjISXMmgAapjC+mV3caNJy7HTsdncit+jAi0G sLj9LyNOHw51KcHurM/NYIeZuOD6NmD2TYdJqEE+qedqA0DcG1bBwzwTX4XOejv9sqJtEddz JnjOv29RWe5tnyO4wjMQSFV2Lb1vZ47pd+sfz3jfIf++cTM247QuV1fB62kJHj0NvxCq22Tu xzZ1mtVaITz0UtktX3W7yo+lQCugy78bk0jL5SUSE7tIZnrNhceIOoWjcbbDvEe+NS9v9Ad+ TArw8TRWlCd2+Y4+FlrsncEwSk3P6D3mzi2SEhu6IMFbQT1EFae2xdFu5UsC/5WUoF7JNA3g LPnOgkBeQJ6bR8PmChSMrpQCkSWJ6j/j9ydRuQr7rhXOD7OTzLQGwKVFFqagnf+S08obhple fLSWTJpmTLl2Q8j9X//zdJ7ylUWkysdW2GlHu9GiYRcIGFiQgOEYpMQDpHm+xdduEz/t+NDp WwmOoJVL2RjKWqfhoNFlmBiPCvVQouCv/WyeRigs4ydCHqti11tbgz8PBBc6AeDqfjzN84T6 S1ss8qbnd5l93Hbd55/1W36WB/8AfMR3WznsaWFsxp4vqkGtqDhWPKB/OySJrp4OgjvN535p tZ6f/5VUeuylneY+lmKrv2oRUejXiLzsvjNNjlku7iCbZRfTz6v62b/7k+8r3kdtO7y57xQB 4Y9NhRG92Wr9BxJG9kSiklZbCiprUWC2pycB8rW8RSuVCX6d0R3OMJTBe88Ir2BJUMbPlkul GfkgjjKu0hrXYg5TzsHp6/528+Y4kRsZAs2kqkAlvtZENe8/x3+5EzoHj2BInDF1Rcxcf6JQ arZZrU+UbekRvdqAhgIWKbuciM8fk1oNzyx0lnes8yHPpXl70deV3W9wa8gF0RCozfIebR3K lwXLIdFcI8CIEl1d9yxf8+1nH5ZcQZHEIUa8fisuyjch+nEch6XU85mMC+192LlKPok8Qsfn znhjQoQkW+lWdCUuQdqKvaFmARv/X2RDftvA6bcKgQz2EO3vaEWXgSyp8nUx2XFDq2Z9wl/H gY79awVMtFFQ/T62BI1nX8I/Y8Pj0VFVvisKRiyJHIDKl9ZZ8Gzme3Xx/6H4V2Mb8pZgecuN S6cW5OnhN4bR0/v+FtFjZM1GqgBzUUyc08PYUHzqQKDg8OaqVk09MMADBDT263wJDt7QsfLq WA/dubrYEVuiYkqFormoOqBtSqrhW+WJ4fk2wDFBsxd/hcN+B+i8AY+9btLphASXF+IBAF91 ZL/M0gyQSXT8b7dRB/xM9xt2HLgwsFr64dIxgBAKqjKMDHNnHxeLJrAixMLUbzDPEKOxyYfZ KiZEmCrtfrjed5o9HGlDdVyIeCsbX21ZC5y7ObAWYUsxIsUf4i/3RH+zwV8vYbPcZ5SM+BIc JG1yjxNawmcwIThZGJABWV2nq8Oz2O/kN0SRWvpSPPPyL5OekXaWFu4f70M9MVgmJknJzHB9 XQTRzb/JE7g4oamSfLWyQG9gPGKr66OmfDbTYBtPZenklWWHZKoHfljaGJVwatTqmHkcDZMC z04I3rgnIR4RV4sBtuCqFGRbKlWeUqeuJcSJ7FNb4gOqQbRZtqsoU/QdrwKhOCTQTY8cTdAn lJ0Qo3KZNWoC4br7E8CtMg/j6LyQcAvkAF3ua2ZjD/iGcu2LAIskyxbE715M4RbpiThrQw17 jGE6S0bJJBKjuJu8HkNC5S4AWaojbW/YLC0LS6iLsZyN/akyTuZruQqfPIRr6RuDr/XZFoB6 MbTa4cnxG5DjB6ZxIYOD3MGJpTJvEh3TIs461LSBJOvmw40Rl+eB54WpUT45w/POhjUwT18s K8e9XYeEIXiqzbUiTAfnIsMZgY9ZcASIPIG1TPj7jnxhUdlOt+lvLS+90HJhD3AXX1AXfVJh f7GTr16PgxbQ+bYMn5b47f+ytISwkFbeDF9XKucsOXVkeW3ZeId1Bog2xFqRSXGtMwIU4X/A 0rLiOf0zcxliq3XCKhX5vw+OGr5i2KOZ5/v+3tOzil6LXJqgFB/zhqXsCEuDdmWIr0dZK66g W5/6MWzMuNejqyaCpXe6MqB8ba1TNTOos/YVJX3xsbFqUOkrUqnsFXltG4bZ6pHP2k0BBgfN ylWSp3xDQtnTxIv/4GKx49WQYu2T8tL2xKIjEyirxqhuuZmR4vgE+RgN06sFbbu1NNaZTuGl NhCRt1PEdo9DjV5Oy4DgTvsJ6x9x37ZY4L9CC20ieZ3Ei3DtLJFD8eVeBdxYIqN+iTYVwF18 JoX5ptSO6MtPmXX35o0gEXLzhtC7O2llpuIyB8fIHVpz5tQfx0Efo48X/UlYhcS1PNPaL+oV WoizNB7fb+QnmruatIk2yOteUWp1hWb2WlYV38rbIWRuJrumzar/XPeGM/xM5cgfQDC7EbGg Cs85i7Okj7S+vNn3HhgaboqNwx8QmFjpZoM7L44Sv/OWj4u09ULpvmVAUCq3Anzn22SZEDyo w7kzJcncAfUL+v+wkbVDgT1Iw1hvPQG/7gmOOMhYQ22oi727nXiKQEP35ZCQABfK2UFy+dC5 T8F311YplXSL8Sg52l4awJctReoHzOmJZLHPlmDxkp4BEcQvrDOXzkawJV+R7pjJEAi32cmC RuJ0XKMzxhdDhJa8mIuoNk004oTm8nWl9wpaFsqNO9mEvPld55RcPWd5Fwkm7UuiZ7qiM4EH /p6zO+hMmwe5oLG+y1u4pcAe4Ygn4quNxwa/SvCC1tOLUX4HmcrkctuIzQ188jP7WlTQ0L8B n4yhILlfv5AahPHUP9JEDMYViCtF0m9VwuYjmrmmS0C7TpuhZ1f4OJS9UCX3On+l1vgCxbyL yidabMT+Q1+Yh8381sL3TUFMkXNkWowxx/tR6Fkt7jYmOft5aP5l6EBGnC8h2vuGnh1MPSbq xOo1wUcIIa+wVkAuuHK1NkjJ3nPQ4M0a7Ohcx3vHy9XEIGuJJq7xSEwYa2rXRaylbEZBJo87 mCPfXg80vaHeWghDpsIOiCSyJI0m9ngtnmEzlM/ikoq4MTHtOoFWo68QnZ3Mh6pIouS6XxZr vTJElJHD01LlA494AFSRVvvNZl8po4JpD68RxaUtsCZtdEv3RBgwuQf368zbcB6P5PtU2Zew ks5nZfeWN5d4sv1mIywHnQoK0BzR7tAyP8KuWYAqnv2Sd4wQ/X7mzndy6zw/8uBm6F7QE17i llc6jBd/Sf2G8gHOxn1PevNcEP6GGtMjDsAc0cdpHmXIRV6rfTWrlDYa/tijqIpRDFni7usG 0LarbUzhv7eD+J82agmcM42KWRbOLwlUbfvlVlcOVBv/T/VJArpjRTM75rPY2QNNwkZOiZNd Py8E7zrDOOOdsztqlz3p6CC4njiBZVDFUleCzFo9tf3gb0QCbqa1zoiCiJ3aYxG0trruEKgT oe4cBpI5tfzNhIqd0Bi4FwgnN+u08XWm2GY1g0PyKh0+cKi8qgxrcSjCBdBMuFH25fY3Efvm 8pzCZLsAOzfI4/T6sV8LlEs7IcdKzTv5wSFSF1ZT6UKd/MpLkxN9k6okaX4PIs+gAEvk/y2f JsD5+HnbRw5Xw7MnYgeP2aZ6RETxwn84EZQyytb9z2PMskjR23LX3dNMqobLMOLdzQMipYYm mFssBWVCoBoKO7xHnG4JIASSsPpCZv3QQxQuNMle03PBIgJve6l7TzuPMdnLrfUg6KKqjA5r 1KOwezsVj9zlTnd2hfekrFlbEmpVKADo5b7X3Uam2uZI+SHMr9nAjIbrY00Xg5gRyITXdQnE kpXimxPvHbfkc5OTX/WsSw/Z8+r8xEzK5lHjau4EVDPUFmMFczdwMVcFXQ/Nj8Abmnii2VYy usDKeKoNSLU/jaduwk+nKCAV4FbgsX9lOewKnItDJ3JtfA3QRDBipxj1lkUpqb/A2EMsNj3n Ud78/OTme2rP7sZhakNRbEnkwZ8nxYhU+Y/BH06XgEr0LDp/YqPgEux8A9FsON+YiaCmREOy +knqPWRH2xnh+uvuTYvkMMe/4vWzyyi+FYvvUlidwpHfoChXoEmhFIA0F75qhpweBmkAL6eY FYxUdJU42iFSlq2imWJ3t+jrAWzTIfqXQp4FDjuXiWxZ3H+xDS6Me4XnDkfAQYAVlcFcdN2t TdltRnzjdzDZGdNiD/9jfruAd0Zg8zL0QlyMlvuGeWMNEcgwGJSOA2qBVpIbM9kYRv5SDd1N a3AdDrOGTYQYpqkwshDsGGvDPvbj/ZY5y9htYRIgA0KnfxaDz5PPOanPPL5RN686RjU38jQL CaljSn5yN0Aq4N3QbaypJ7VZEG0puiHBqGbFJkdcNaVrPr5rGYBazTPRMnJdfH83GKO03alm XPlMbo71an8Q6pf0Jc1FlEeFBFG2ghNEMIWU9MqK8YGp5QdYvfneuYCoOmOs+MCMEEhPa3u+ a6SrM/KlT+88GnIuWawHgokxMTDjIiG6Kxy+uB88eKPcdoAjRiMzyvIEgp5PIyBug1YmM1xw 4Gzpa27bA6wRu5YOes9VBoyannDHRFH0wNpR5bcKuTAQ3uPLuUPlgANVxK4dodlo1mr4sa3k R+DOLFsRc1TLNK9hhZO/PCsLIy3jzAIQoeCDvdueeNQpfHFexUrrEoro0k2Z3A0umsb1zZYw 2W1yI+SUHQnDMMOQN7fVnG1NFoWE6BzWOMhsAaNhPgli2Nbxlr2muJTaqIogtGfrqyw8CG05 vgN2yrfvQH5FNNZlWCWU8hyu3QGdwB3II2Hc6FBE1lQTweHqFIbOhLxxVaOLi6gq9XsMI4BY 7RJm538wIQIwc2V8KHpv4VbL+EJTNRmeFK8jBbRFqRrbZMOpHd00VFKlydGjQ9h+FDnSgpQW KlMjtS8CDmn3iSH3JkzrTCtZzKFP7LyTLo69Cy7uAKaA3cqV2j9T2BNXA2S+TGzo/O1dXHme QD1U7eoTnneEFcLh/VmeGL3tuvjC0iAxvyPayzlrTzA6BHk08N3aT6qZqzB9vAv2bX8Yme8S gIHoOFelCFDErk9aTBN09+aIoWIcEzP1xdutTYi13mo8QyRpjr+pACN4Svl8T4vk+FTWJH16 Gbt87nM+xDGCE8LrXA27Obe0QcQmzgd7MCa0O/gNc0O9a3XddkxapzaByAapauyATFJV3VB9 t6VI/JZEH78gv1QABY+yBNbMkXv9J/6lzDFEb+VbyxDBhH0HXZo32KEIuRfFnybb067yR05n CMzRxewwiApooTV7dfZ9jd5u04deL64Pe7VwLsoGdCu2yb5z9FmfQtVmey2TyQ9ONoHdcDh0 q+G6mOTN1Mk06XIBNzxH25WJwFZEMFfPhstFu09zYSCX0MTBQGyPbJlSZHUl93VOOVwNw+wK kaEEfDnY4bQWogFldvmMMG3JOJDPSwY0/TYwPAORVrslTLWEw+TYARnlSmgMLwrXHxQGINCl 1a+oKA5aVY47fHBbFZsVEVNXovqNM7SmP4HC8eQVJ186N1QF32HxFv7wHu/1izeG/W2v6OUk 0UWpe1EqmVfDNRTJ+dIDNRSKMM1ykppSaXICSQ4KmdMFRcOePhTFnf22bfDLBY1Bgm+x6RlE YLbAm8FD5AhZANikReGHSKdazqf7GxSJAOOcCX/AygG1y4wCxKNZc2LTImYfo7TAEl2KIpFS 7/gzfWonU543ADPyfGQLR+3DpE1b9lreFLDfOo8cIdSvMa7JT9QudVTLYeLn76aLcY5NJeeg +3qK4X5OotN1VNaKekfOQGRaPiof9LXjgkdfL10n91CwVPZZE5iSg1pF/NO6HctA2aJhmhyB FVN3mA1KGS6zFmdSMMJ7ifDiHrTr+qjK+qjp3+yPxfXnJbp893ELfRFd0tVczEIRuO+B34v/ 8M5RforQpT7LO/J1WggnaVU6txTSpDEo89wdXIAIJplvOVYOBhjITHfw27cDgutRDHHOdx0P qo1PmDatWHXYAh8s7rKUdkuKg7Y4gdJNw4whGay0mxYYDXDymjldJ8c9GXfCJFkqAv687Q4V xL0AHPY1ySOiDk/3fie4jDtv9eC/xlvbvMhyOXdPII6SEN+5mieVdAEn5CibILa0Lm1yK1HN f73ShWbh0tddicUu2CaZDOoFO4ntW18HiZWUdMn6db4Fg6NrQx1zb1G9/5wryUxsoRtyuOUP zQWRvSCNxhMfX4dZ4hYw+Z3yksvks8ZouG9PbSODa2QKRt3ZMStcvQnzDTE5A35615nqW/nG LgQPlStxQUxpsn1l3vbr/uPKHLpGukrV7qnPiEkojjAf51HBGj286IeiZMHVu5CbyarRSjJv EBW12Xghli5W/azem8OIXvoiSEEagNM52YxDbGFj5tl/3hCchDK7hTyXmNKwKEbLS4hUDjYy Zw1W/bFfY41ZAHyAj952H6NwJXUKHoTnLks8OID1txawJLSrn/pDv2sFnp/UyAnHAIr+3g6c g9EuPs6t7dwVn16LsYWLT8TXzeZwX/TK0YI1rT4D1cSCT8uhA5gRs3Ac1hFainCJ1d68Qg4e e6rzyPYj4EBKUyJ3OVdrNCTHk1reoNQ3Yyq2izdym3pM57YO5tKgyGTvktMlz12qReThvhl9 1/vVSMqTfxaRSJV9KSP6V6qybBLR7SqCSWq1WFQCjgEmSBZ8yGNQ2WoFoDfdVaUlUA0C6d7g mg0Wt5mH/Nqkb07MQ/l3E6OGQY+4bT5m5brxRXUxYZu3C6QGiq54kyblODXHpMJogl/YNjRt 3txZzvzTGCRgXKGVhip3qBstEDDgixt/8+DHL/kDpVQxDzKuTB9S4UtNNv9V+p2OtAWRJ1F5 RRvrFYz77rxO3qt6lEw6/j8KPOxoTIQOGzRXsm/GmuJIrGJwsqeMUWqIMdRhJ11w12oPakpG ULZWHB69l12NPkIGdYWUSHV/tozQenHx1PmWbsrZ2OUy5Gl2y6wEQLEXVipVNi0pDHkMgag+ 1ZuwviTy4nU6vLUBUHIHAYYTTmjf8AdIzTlub16vH+bL/1LTh+xa7O0+bXWkf2HTS/tpQJmr dk8eL19c0u4k8DnBFynf92DhhBBHWEl0sTHQGjGR6dcMGsVhYFE2z4enVU1Wv/CeHfQ19mrC doHwxhP+j2I063cedyq3hQfBnHUj9gokhbAiTk6c0mIRiGSlinBr4Vl3yyMYuuwLgK8Mf/q2 a2OfqG0mxCzpDv6SR0HuTva2yw2dr/u3ffdKyGLvMggdRMIDR3HMfpf1Bgw7OCsk3Usb2peV ztaLZUtGb4PHVlZNQNF+2A1AyiKQ22s62hc4/HXgDVX6wsyRiIwi6rzB6nRzlVfBavH2hOwg RuAbqHeJi4XeaN+qZqCowfIxoAqk8dLga7h1lJKDU+DkicMPCGrP0eIiUzqPjEw0gc3nYKKD IKwnK8aZW8iFtMlEkcP9mQ/1x+GDDvQpNbOVG1GGkODCOi/uXzQ0kgHYBE3cfPzO9XM+ax0x CCrDufKxgp4svg2w/Gjs58crciBb5Y5wCwl0Fbp6PkGXhXao8vcjfj76Z9aJ8ZhhPB3WINZ7 YDhOch/Io78rRiU4qT0HEYvKF+pziw6Xe3hepuy9IvyHEEmUwJeOvl40FMCa5dePP+hIjD7K OIJL9qF/+BzbBaCZaaT0g9nyfGu0NjTJch92CiZhW+l2OZzmYOlxRss59GocwJu7qI/x2PkX 1QDa+3NSCzrtnq+iyeLgDlsmNWE9MmF37kWYXGhbqjFjHezxP17gL0hpLmrG4nL29sAXEnjA nYemREZG0II/0h4UdhLrXmRTqym7fcZpIIik/joIEbaiSv9BFOqiUmI/vpHoJnJGAs2AzLNP h3gzPM6L/Ses7+cVNqo6OX6JizUiYFVDBWR4ENjlFU/6ya5cESH8iBvc+Ud+Jn1ucJeHkrpG 0asAQd7ff6QdSuFYLaKCYD8bz5ZeTenydfp/ISi8DazW8bgMStVzLEZ4E0oscjO2A+15vyfC RKbLXJYmA/61BeC8NgBT+qZ8m5stUH6wIHHrTw+QZKnkVecaTYamOPjJnI14B6v7bS/AMfh8 xeU89B8QNpCKSOK5xJkGwYyQYtl2tqqvJby//5o7ii6utPlymnP/L2vSJHmg07Jt333YIFTR yjhqfeiqfD/03Ef8e83lYxoU1cHQeQTuNl2BB6CjIgDP7uuCyf3Xd3a4gJBzkZCKRlGCbjBJ eQS6uux4sq826z4kLIUkMrAodRDGfeuBqsPi2jUoJbAe5sO81helQ2qpB8ifLCCJ6jMA5tyi Yj+d9NFU78oBpriH7mHbJ0tFxjWP6iSyA0B9EDLBBVKuGI+pG9YSxZnY0pWT/KoCBBo1H84o vHRir4KVuy9YNV3eD58IBKJ6hIohxlHr3zuF8gBN3zNRFCL9rJXNOePLdFyvHZca/MXDiW47 uoNPxzQqNmNlO8dguc1VpMmwq5/KAvnRDPi8YTywOZMrVXX55UQETtLzJJtV81sMj8RM3rsu fPTi/ToxJW8a+1n3kODuuKJOMQv5n6BRq6ykQb8GQ086Rihk9DNQ5VYYG4GbfNWE57FO+MU6 WKHOWtXCs06N36g2QRjrx5x2M7Cc4jaJM4SJ0BbQ9wCcmo9HXYSS5ByDnQgQfv/5F7J9Lyrl Aht/K1H3m/GsunozEU4SGj4i1BSGdhQoMjdIEgod6B9t4/OltjAabs+o45dZ5SuB/92HptR3 +fnFUopKuEZ3pH3w7ZzqphTl3Yrp4URTc06AfeP/U7sbNYbLxyKJ43F0NBfNBTLM+jwkT6PV CNjz9K5yuxGtiQgyWiR92wSyV6AgeFwSkQT9DK5rtU/AudnFFqeh3ZEppOVOBRTIE4+lwEEU nFdTa90gWz1O+bQsEvyby99D7/aj17bLK5XO1O0l9Oxjm9yA+8SjGqajXoUw0/TUM8HG6F+/ r7cXkP7ITMk77XorjQ7WwoIzMVUwRiMA9FKaJVwTGEbSIruJqLkWudtRZx/0VoECpmFwG67v tcb4CmVQmRvlB1uxznGzcYlHpZeb/PWY0NxKxLSDx2OaoCgT3Mf/tV0RX2OyLPj1ATDENsiq ATLGUEt+PtvIvORJD/2vf+gIoagcLzzxuoGayyPZJuzcgDAtJNKtorpjAmsUm/+LlRc8W4XQ HM3ZI4/Nj4H5qxMwvFlSDcMS7fvLxk9lccgp7Q8qGAKQvesfahA7/Zv1yd5Db2Vsb+TF4vdv uVDe2SXADKc/boBUivQbghzP/224ECzzhewTaM0f/4Ij7a0vpomobtlqbkmznlIoZOUu+98Y RyoBwNXLudGr0HeZV225G/lTqRsHXoUA1H66tHLjMaZ5qiYy0XF7UpYenF3JcR+d9y1pC/Nq 1cHXuxZjL0VGRhKxlRmNJUugYPX9fo5S0DyUDOYBThwLUwK1JD5WWZvOiEYgwIzh/IpxXIxj V3O4tSFnzIGUlFMdGA6urqxmLr1Ct4IDLOXDEht3UJzdemZ1m/IHg2t3lg68AxuWbnp7OWXN ejihGx87AW6LPZEkc7DCPNogsbpfmsFBl89LXOHZR5+2EPZ3hft8DO+TgrBg7AbK5d6E3mdA aM272KcSQFZEBeJ4Gp/UBP08LTvRQwaqYRpclmDqh8z4uLEo3FesWjT/JFKOtkHpg9BYuwha Rk+bPHh4vbCBma6QmQvYA1JZ95DbvWbtAmIZsIehkT0ZR2a6EaVR+hTOZsvOr1tnijlYFNPQ JjB9nCzaW8FL6imE3gxHGiiftzLsb3MMlGtexXuGmrmcakE1uZi7QKRutXZFmLy83Jqzki2U /lxvCX0oxkxDSzxn8d4wDwluLRJ32rYK0qUqOyF9rLx56bh0q8t9LpVlZo3KJkgD5NS2Vv+n e6Ai37IIIn6z7PrRUZjvLvBUB8O2YeSMyL0V0xlWeoYYd47utfpvcEu6/VmpkoT8DJGjtDXP kRpBr+Zk5xKS3KUL7XFiqMBphOmeXCnZ8xkO3c1/cSkw3wpcX7S6OIE0nHHl9Ahlr1i+xRSo 5GACpM7nsPy+CEBkfr8SCcmLZJbzac0+ZAw34ze5pU3xzmSaWA6kfOfHml54qBFnOQC1IJHW IlVN9hV3D536dvHro3aeZZahHEPuHAVyP4hzrTa3Yp/Zk+nFYwv6Xe/PicUYVv5CTsLKnTS3 YL8rTSuf9Bygrbl/F62PtnzBGCGhQW1GTblG/fFI9UUPsfrnQsIZ20l40M6fURmFmcMWd/Ya LXrSgDAbhRTKIhwOl/7Th1BtMWIgHLXDS0HMY3IryUG4VpoiDtDTUxrqRT043SIDdzsY55iE OsZwu/43tlwlyuMT38D927mNgcKZKHdjoDOFupq4zkyzjqa3JDH/dalbOUt9h/XIoIwPAS8B Je4YRkCInKgnxOggBIzuZtHq5jJZozb4NVI3Z92wvW51E7KiZrsAV9n+TW3XQXV96JMq+ZYE hfbfBzJKWIMCdnZRGGE7hdEr9tYtSDT6udL7LxHEqEteU2sNMWqq5pGnjc7H6MYTQVRqrxzG YMBeGHBbaGLKOkIy7WQg655j/2v0lGOl5nlIMbIbhU13TFu4I9jP5fyNawhHJ/SMNoT7AV1S 05f6uSSvnDVmzCRIAfYt+jTgkXMlhDHHCFLlmb9ibgu9r/idzEG1GomNA8psSX0NgB52PwiZ 4J7gRrYtEoh6bUr+6fZhQ6IukUmO2Rxpr4qVzgwx2DCC6+qQNlRMWVe6H/QS8n/6fiMVNaE5 kSm1HCNdUEiMRcxgE85vZWYceICjiuqznCU7fP8vIKM7m48RLjGKhbb64h5X4EU6WISv6psH xHosKIIlmV7a+FWhCl+M0UWQVjymMF5F1RK9xF2r4PJC1MuGPbap3yEU/rZbU0jNjsIC8ksS o2ab0v4RYo59EdW0Veg/Ms7y+CyBk9w00l0cOARAj9Zl1piJ4ZL6G85Rwk3BvycGfYN96979 ybAKhcEyIfzocTwLPdQYzAlElLfHfsshTkWxJYuu8btk0oFY87hYQp54Akv1IzldhRsVFt66 /PdAovRnDNWfDUHyEYxWLVo7Nm4SQEqWA8BKEMc4qoz+Oz56s/C0UCgz3s1x4vORAHeGscqz fNF+G4/BQpVY0EHhe3GUl3abmcoOdSzGDjjq9BC8sJ+ET5cfSWilabzAvvcV1+lf8SglMoxE OTUyUl8FOwO25D6fWtsjJgglkkxTHV7mKjI/WS8NmrSZ3DwMHlsvDaSdMCzm86U5ocAbfWEg EJZ02u23Djj1D1fL12MwLKbD1cYYB4EvfQhV4ZVwpbr95yRgVcEvzKnJOlwdLlki6fp39TS7 jVC27BXxgKeb9SB/vWsP3679NFdBvNjO/O2MorNGoX1QRsBwjb3YiqrdW09nDDmU2f0zNnTO VgIcQWrM+w5jOynuByoa7F8FnWrE2Jz02LAqQuItOpOtjFur+Uf+QmhwJSfchj+I2vJEz3jG 9dXjsleTNus3u6c0gKeZS8HDTYQ2952E51cHjiyK0n4Z3TbNzye+nEm9CZgFZhBLxcY0iKSL p+CEZ19F8rS+rbxh7T80lqeeMxYrHpiM9ug8SGQfa2SvilgX0P8IByk/I15BZE6O37objXAv Zp7ZdOqEsufeXgj0fmtm5Ei1gEZuN+NDPRHr6J7chTB+MVXAB5FxxuuvjIwtY3tQa+Wn95Jm VPzARaCJv6Q3zvnqOLcQGiRBibfG7/jalBhjhjYzocygxgFrXsC1752TlT0rvKsNJqPbjGpZ Fts2vmS1WGRQYe8aHUjKqDpiRdsd9GIGDXqqD7/4QbYPUZe+QDeqpsyvcCGg10Vhpf6AW/9u PHTkLcFbVQgEiB/BqegjMNcnmFX5B2u5+e+B6bNyCDGURw92gjR9imsIlqAN+P9folOlTNKx l99VwpFnv0jkxeYJ39GjHlcUsuDW/YvXLWSnPOWxtwHlJd/xcKB51Xg9OSrkKaWbjnY3h3P2 3Bc4UCSglcSqWKxVnIvUdDwlEYP0OHDWjUYuy1RIeRlUtUcZeqmqXYUfV4itrU9cnd142Eso xkQCS24P3PjDRl0E6fryKHGqG8WbCYrTxbLZx4awJIChwjUfDYizp7fbaQUdwPVdFnOqWUu3 7hKfU4IWM7rn5J1JR4Qplj+5qlZSBtmhHQopz5qaFp3b96OYveBOVX6Gyrd18ePEg1aVqX7l 9dPaNb5IoVfQMASjsH7JbhxMJuiFOpPUWHDxLNQ3+jsLpunrbkTzk3kLT+FvgEvtlzLx/YVm /SsSPOy6IM3m8ca3Zc+PZ/VGCLNsB4Xly0tptepiSXiYAa/ntLU2tg5O4JkGdGNHlCmOa940 bjcupMibrJORK9Q3X8ICjMC+glwilnwn1qjGtR6YK8pT8QNisy4D5cVmtfnD5isYtjMSKcxz FTxCMTKOAeGJpQvTpBQ68yXAyrGHJDbjTLJl9jayvwrvwHfUEvZFFz3/mVZyKD/vZJq4xtum c14tlOjlYqZW+f5QYEsjPdevjNHpAjEX34W2MDCwr7gBV7l1Vqjwoh6vA+4jxXTnpN7UBrBP WlZ5/hYo5rWXLIbvgm6XYG0+cJlRx+qDnGaqdXAVi8UvPkxtorpq+YxHVs227V24RquxIS1A wDql80HEdM2ixgiq2ldje9uH8k8qyVQL+R3OJWLPnnKYNQ2DNGTrljALi1baVXUZ9HJsoC/u ITFUCDbgYUag69dQsihPzpUcO55qzk2Bntrri4wp0L0yoiYU0E4M3sRQzTk6duN4tXTML7pR qTZhHyuHkQAk+okyVPyHW9WNrr4ULoP8ZxkjksbvWr4lm6U4RqF1erOqZo2z4p7B3Mw3PqYN 3i7ebHOs+XSW1dPT7Bo0BgWhuGLhrz3SDi35YYjFjmZWx03qqrWUAtwKSauM7OlRQM2YJDlD /ONqWRu4kTGb+vx3kw33YBqJnmtMDkJTunR2kPLxvR4FKx2RE3AggEok+WvwkhxeYo7ZGM1Z g1TS00knZZYKLUnCKiLhbw83tN95F5Rrrt0qhfj6PaLxRHF6Uyg76tTV9DmTVKe02OiqX5qE 2qjULwPQUXlgiWqEM1TlJxwqNKT/0E0sfIgz8sK74uPQ9kkWIqUPoK1ZtkiwCX3JoMwQw15C nWr887rfocETF4y+ZxuaxaZREVfg3sKVYq1qE2KjqJo/MK9uRbR9iYNClulJU89QocJbTEBd vJPTKqThJNYi4HcBmtilLa8yVA8sinQ2z2sddxEdPK9nTf17tjZJVSyoSaT3ZEDVzbfyRpGC u3eIfxalY+5TzM06Zd+4Mfi8lodKicTFm0DM6TG1QEUS01D0Pba0js1UuzIj4pexXBoy12Xw Lw6aWDlHQhieapkYIo6vZn49sR4Icyi9FMeZE5MOqw1JC33HbVf9dzSAsoZ6s9ujzt/WaVh1 fDkpWHgK5IYERj8xTFugaBzJhPA7bhamb8+m4LVxo/RW8xTzyDS25E+AcesygLT1fTUxnUwb Jdd67H8zNOMrs5BDlfGDxhQEEBc3Mm0R7HwweEEoyGTYd7sR8MwHgVoGPywXlF1IRNxR8Qv4 F1NJ+xwyhl6O04LoXV2sEy7GJ2ewZsPAhZLCrbgRPWhM8N17oRZLCndt8/aACxU+Oq0xpuwA ewR0y5Om/7LZZuUHmEcpSwAASvyeUx46tZNOJ+g6TIJuNDrpLHNdHRWgyBh59Rk80HBpivl0 nbTZXPzVVT029ij9TQ2nHXEMNtB6XNJzpP/h9BYBpi5KKZJw5bC2qYYG10nqxGvP1+jPr+T8 MvtONu8LgcypWNW0354ArpoHy1BWElHN0bVLUf8Z2VYRcMsGKOCYOQyQqeSdXTHMnuZridd0 KXLdJjHhJv1e+cXUat5SERqnQhC1LrRnO5owjS1m9sduRqsUW52SP5atdO94r4uWHngiaOXm Hvd4qOSxMONvjRpb27Vd8J7cd9lVu/QNZf3DRPaLaMqfQ7qVddElWaz+wPU6nyGKUEYP4U/9 MY9IgFbixTiB+dExjwlttSXTDKYbrSoS1G2wrSxZSkp8g3obKdwHTy2lZZgyBJyxyUw4mPvH BFWPpzk0dzvFxHL/dxL339g8RfrxMMIpFBwkOc9eNngUpBmO2sIdFQnipGDFsWUUQqo+xriV sLHFgu0yvUdDkpPHuinXXWSmfTg+HVYuDdUhueRdtwQGbsICy8SA9amdoQ7hYjWxLnJ6yCxO MrqYEmJl/H1rBM3d3QKIPCZGJ7Ksdv8gj/biP63j9+hW4fCygsG9RD4AkapZkVlhG67KjX9Z 1zK5/tkcO6/qrOl0+8rVJRL9a/qRhhb3kh8G41Rif7eIkZQIJIGeauhxI5852z/efwUol/H4 mbh3iTRS7Sg/r1/p/jMQtS9Z4VI7bAwv5KsA0at3wtsih0QGMvA62tNLy5UG+PAJTs4RW6NN BNM7KocJwrQoZYtO6APSrNr2k89fDiz8x0i18dtKngobXQk6TE6e+5vYw4ALIc5Fom3EDKcr 4cyjb73Ngq1/HVSui8/Yk3918eZM8TGSk7X8VMUyMuyVh2CXxg/G9LXzZK1JlM0NLIplyuIE x3qpN0kkgDc7CIko4D0Unhk/FdtBNU60WHlBsTcN7EqgnyL2sgiYF826nwG96TcTmp2Io3WJ ku50VD3otBKL5RIBy3jmb1ThGJYuN1b7yElndUdI1eETF3c3yDkhpvF2/OsnZBucVWWUUrwW X+mu0iJ74gFTt9JFu/hBRJo+X4uJy4xqWqSrrkrtqAwNVa0sbO0BcOR6yftu5lxVocPLG5aj /DknwLjbxoooE2iO3eqIMwXfmGfjSxwZpNPqGWrCQWeDYBxum54Gw4cGLEjgVz7lyE06RCOw 6yBNwEgX+9dKkgDUyEsStW4OXUeROMoHLqRnv9SWyrsA43kTja2f/5y5/XAWaHAQyCHU8A3N ieZSzcGEBq7yAv0c8IpbAtmLyiOT9gl6uGhsWfbmO9XFyaZFEbf507+N+CzcSxh4Z7nJHQh6 QDAIhgzze8N8pKJhRP/2/EYAzCVQIDtmqTzj2Sc2zrIwGO3r3byndwh5hF3hud8uHpPSBmcR BguCA/feBdFRynCjIDUw01ZatPlk5CCGyonMJX3mOASm6SmwNT5ORffRmYMkhkuyNEL9/MAT GHNMboL9j+xSBrGG5b6Za61rIdO0aQfBLYkyERRW0mNdFBwBhfMQpqHKrCkl4HxCQRFrRaVJ 1xSdroClrtJO3ieiLEFm8SoSpUgP8Vx5cBosqKUrMjZ8bn6JgsBugSgK1PcJe84YPxUuUI++ mzALkLL0fy8mXVcy+vbnYCzhM/v2VKvmU3cUk5BBVs3AiWLx5qQurjuxFqmphVzK4xP2MM+Z Xnorn2Z8NR2gLxHihZju9Mvb4tuaPYTpR/BoipbCKVUeZT2DgT0HwdUAz5DQzif+XCVUwKA+ QjLDw2zXlixO1bVn2UK4XeGUjeXzZ39+N1kASpdvFizkEX9usrDI1a9bacIN345/rc9hXM2r FsfCI8P790a43M6GsCc+I0n1PZclCfGBd03LA+oQYYGPjN7dEvKFWychqleQDBDTrfK90Ik0 tA+jgul3S9yqR/ska24Xdf3CY/X/gXFi05pWjFYOaJZgLSaYtrONaRJEF+KCdCiZoZ3+k2I/ 8cUdMbD48NzGg1wur59dgcEQ/5Bxtux4zaj84lB7KKGIBDY4Hvyj0LbxldL4EVgDeDilHnKl YRystW0T9TeXKjuyuvnSwYLROs0VmAVg3oZh5XNjZGZsQ1boKx57tXGs+8FR6+Bt3D0p3L4k 2OT4clYYUW3eHUI3/3EOtDVoW40gHdgG20g4NGaTCX3LD1m2amQKVewVe5Cngkit6Ik+eKBp ycDQggKq825vCU0RiNBzTf1ySALx7JJ1npteurLeDZf18owjVOQT6YlZmoVdV29ri4f9GCxt ylnmWLvzxRlLXF6OP904ggYauITrPmxtWw0Slv4uwFXA1djDUrKzngEmFrsmzLD9iCSg0QOr XnxpvUskcoidVYx34kyzaKZEBGRGxAF07eAomSCDlcNhXV6gtPTYwHbLdPpYjZP8CevkQrw8 obwkfWB/3L4xr6rfjnk07MhqfM77BVLiyf1dRhh7x4mtQVRaWYXJJE1fcZDqHygqjAa0vbw4 EOY2pd5aITtvgl+fkOrhq+BA0o/aAAFpW2sJ3KCZS7Z9IdhIg8Z19rUWav4xN8BIlHFnkmyi lWPnrb5kj4xb1284sVGCLj59S1zV0o0TWTVGEdjE6Duj2UHDclSkNanyKg7OPloNXxZ6ostE tgdMsHVXNoK7vxILS3RLceTXGoIqp0Lbphp/+f1w1tGT3eEfjujter8vlMsmBR2S6j2Grw25 Spnh5jEDJZPse1sRky95b9Ss21iotuMTTliTGSlgr1GpfyvZf9VZyAzp9sCU1qQvjXKg4an/ B5Xmy6R6BRmL0rKPSWLTeXSl+MHt3KI/FyZH/IB8CjZ/pASHmjaeXVyG4x0y15kjWTo4WXxo s8aBBlDFY+MbsFoPh7jwgfAMf0otDc+uyA57GBfbDQNI0UcEdWB495b3SUBr2VU3CI0eJuRj m4NwW7XEEP4ewKpPWKysY78aXMdGv8me5a1io6yJHefK4GHdNkZ9v26xLrhhUJfx2K7/OLJi lXbrQRt9ZO07hoSbweoDyoJSbqePZ7MWqP8mYp3y+LsKNN7Ru0u4hx4fsKyxBita3MjBnBk8 WJSdSkCfw99Z8ZQTG8MJOp8EuwZKvsMYg004ICDu3qRvFQ9yqwv5xZwZAi//pA9FQ/SKqNT0 lQlxhFMXrNLzWj6eaAKNLK7EE1mV/6i/fcUNYerSnWmSCi7vZl9xdA3v2zG4b1GwH0AQrbED SWF9yvqkhvUo2ndk69AYb/XVMqv6LMLpu8cwzFKLOBPYE4ETggg8YGC0+7w5rWgxpL0vHreT QwecE4SJZ8OU5SUDtLVy5myeDhzdyFsFKMoqmYqWtKFzfYE4g0zAzUKDnaY2ZB8dTg+eh9xf lIv2heHDRckhIT+HJoywNCHOjHEPj+meFTqV88yn9bsoZahZcespGM9QARpX53uc+QB9Hpn0 pw0INNIEiI9UG6kTIx2f8iEl1WMZuTQrwGvHxQBDLh+NPUHFcUe2mi0T460dVQF0GQSlXbfB ZHxK/GZ/1/Q6Y5u3JagEH9ZMZqy1NcojWSaUDLVe6G6//3T5nse/U0ujQSThSXdmSHBaAn4/ jqAG+zhALZX24qTNZzk+h4SrR+5KqlFxscsT29JgdFn7UHoTh4HZGPaf1uK1qS2AC96SYxjx omGPlhWbHjKUrirmKAjeOZGl+nK2oblPY46OGJIJ2/2WmNCj/Kp9A/BO7IeuduYx6fhWh2wX haXxtXi4e26MrEfwKiZ2oWFhEoQHmuuyN8EIUCkf1IgNygX6KdZ1EUl/eQL7q09c0vNpd6aS EhwDF5PtSkOnUH01HrCeuAwPecjPlupYVbmGSxbnwMBZSOztVe4DqAJIjAKOflPk+B4pBcZe 8d+26B4fzvvtx7wuoy1AubvAADl93i+mZn9NZNTxazkCgaAL6LPtbxWM89KshVLDauLi1lhF l71BJIkZypGQlVTLXoYltNZG+AtYvet7/xRS1t2G1yx2YVzlypvEb1VbgPpAvc70ue1fDN+R 9pAVn/S/F87uh+qAVlmcTarQvPYxZyDqH5/QGQUc3zNAVPlAJ0NDWquYmCUDGobwRmhpOLP0 b3jIGmpZdHdA6pShaG6eCYmS0NGMyB6eARoDh7L1XqdK1GOzffeI3Qs/y6w08ht9RFj8Cou6 OeVdr1+g6YkAeTvTYhcoKAYXtNtacPXAZmx8PenWnRI3P8CbzgjpSUVswgBqMM6USpaKbCF/ GUfxjFyhruxRkqCfVnbR/hgW8Fg5TLtKMasCkUe8A1+2oD3x+jhT6bxzBrY+7QcyFZ31rCbM kavhCtOko4T/lPLkQ8yOZR4poJfsnJS5Q58++oR6neCJCPod6kVRjiG2oq6Wsiy/MrNgHSSV 1kWXw/SVULV8OH65eBIupjAlGYUFTW4wwgqqPE/cZCSzezb2quX/8AAn2UzZq+8hV3b9AuaR QtBianBjTkn9DKwif8MMEARfZ5xcUeusVoG+QQjbphPSFlwkjHpTM9rLKfDHQ5cBVEDrTK7x FOmEp59V8JYrISF+UgxgTL65o+bqtFe7h+pS4y4/xtc3ZOmH5MA2ao5uc9L8Axv/CgVkwnFi rM6N9PXIyQPs4MPBvJekBqC7ltWYtdv8LNl3o7cLdGAC+1dirY4WBoGgOvucWpsXfpXXpw/i 9CTsYTAQGifX137YQG+tJnynpGKjdVB9HBy2zhiOmpRpf0G9YGfN8KQSc0qvaUtkqAsmTm4P i3NPrez4aU7eVg8jjAlxcYNjNcu27hkIlXkrbwQ6oZoxUTCr+unvS/NKW/8K97jSQv+CSp+S 9yI56+DU4tGvLNvMsO0F7391Sl58dvBIUWkyC50T0NVcWS9k9u0GvkowDEDMKlvCE93nVH/t 5ZkwzIWbILCquSSP7AkzxJGpg/nlJ/GhHtodOyDDJc2RtCb6r6i8GDIqxcvfAEoMULRI4ajX 0RTRPDn1HVLLtefF5AphWw11rGL96aAzWZFrTm/3dRQPahf//0eAXBIQLyKTHyX0LP699wCm ZAee9ZiuV0Rq0CGTOKPBvjBbR/vqxMt21/Y7kSMU1V9QTr5dc4f9RwhZGSQe0PcCFiJlNyXF LSStrcXyRdD+VRtQcAahB0lzkKJzuL7u8izjCr5g+M1vkXs1B0v5dMqC7TLmxGiW1BOMzLY9 xAq6LtbjLiiGzg+t+c48Ej29FstTyEig/VJM2UcSUa65hWwHCUFuglOduPe31togLXI1J6hZ xKw6fOIe86HbtM34mdybXobAanBEQHb8zDsYTb5+h0w0+otpbdH+ttQEylOyhES2JTN3x6lC p+4bsb8GyB+Wb7uDD6SAZI7GbXz18oI4o81K0p7ddkZFw2u28f7KwwhxckbO/0Pf26MGvopY u/Bt7GKUc7zFIxFNaDxdi5uCA14qy56c+CQgKdmKb+yyfInN6mhdLgnRapRD/M2W9EyfHiME R2vuwoU6L86Bfw3NzEArdHtNYu3DhhUeaOQ9DfgWfEeq5MJp4ZoggC5FnZg+YHORoAcSsax+ SmqtWs8TIkuPk4eitsFj/FqAciKNq7STSuvpOfyZQmyJ72U5l4mSgOvmICY/2i2lF8FhA5Z6 BfZAeKrzUK+CMrhbJdJmkXpFi15pwPS/8OR6mF3dakpTVXGE4GwzI0yc4/eKi2KCrUJQzon2 ifHoQm2GtDj7NhJDC/ipg2MEnsLNYt4copuB/94/L/FimZOmw0fw4w4A1BadBY0iATp5vLbq 9hXpxYLqc7/muzhr/2mqUOWYpRpLfaaOAbqB6nCWduTKTP0BP2IK2oES5zIUFm/yGvRNwN1+ bwWZSnkrPL4mxvzlCrxKMX38LYuX4xeFw1hcHWIpjz1TUBV9JxcFlBIbR+0FkxPq0eiKN7dd YzofDvhuvQv/h8H3QJYXKKVtFzDXAo+xHEiJ6zwoRmxdhgQlghCnj2KMpdsf1hrXNv7usyTv HytJHtlZX9M8lGUN8Sfnhs/iVrdb+QGS50Yush6zrSOk8uD8b2zeEeQZ19bPyJbeg6HY/tB6 UryNjYyt/KH9Yb8CG0pEg1fcQPauzcYPokjhTlzdp2nW/zKd7s9PWo3n8lR2kpzdibESHkMS 0wCipkJOuhBdsw/dYzepi8ea9JT20eMN6gnONaw4aW5S1vqb8iUaFQKGDs+UcXRFYyhqAtOJ QXwDt6x2UPTkuLi66/4alKFDWvZqC+yE1uUBQqJNQanbQQTbrGnXMjNc9Em66+ARdYqRpen6 C3D+B1wUZRBD96IgoRNu2z0mNVomOzUE6SFC+vZ4j2uVmu/WiqaWaNXuF4lIIFyK6mToIMU2 Ug0xNWlZVpGIF2CWY7EbUiyCYvwL2tMl70i73XczrqjIU9uBP9oQ1UD0VFJpA6S5C/wl7rFj qp67iFvjZ2lrVfTMRmUmPHD8JYrLQyDWu6So2FCNPsrqoGaS5L+JIYTXZ4HeObYKpXGZ9v9U H2Kkw/pj85LhXqIJV7H5dkw/3EJUH78iiJouF89Y2A4Xi9zY8HCLHlIQS9ZoFiQs6ZmkwwkM 5b734Z/PDkf0X1/xxoVvapI6HR/5kV7lqjWDfi/NQ+UWVDsQKhLCp3zPVJ/oQDNxgnM+4SSB fUW+C6QBmu7XsMm6PkILC0k0FJqeLpZSL+TE9HzAD+ZZ6ytaV0jWw//BiaOJN20ayunZfIeR lDQ4VEuSdvo2ugzsFXyn/mQyV/QM2dA7/2IVPNQHr/UUeGXhEH7fFMXLCpud3tKZPebuketq BD2gKYN0VwNcmujefAYVLWc/KMR4IqeKCq80pJTHWStZqhphpf9xfw3HAnL4KhU7Xqml4WNF 4j1paAdJ0EsMIMUyDbNng7rUgPMAw6PaNuO5jkOuUPND2zE13buSOOnAQzbIO9pwKgLRLOHl t7ZtRIqTN4FNUwwjPaIXn7WaRF6ypMnIwttpVNQdW3JfVzTftFTCaBOQL/9T2oJMOLH9NM7T 6SyGR3WemVZ7UAFqqtMYe2PoZzpM1pNmCevdqHk7hgJzX4soUzj27wsgT76WCUsMYPnIqxtI bwiMTfRJNpnyLEydHrpFOHLWRdUPOxMQ6MMFtqyXQf2kvyLicdXNH8I1kA9HREVPnbV1aAOw CSeHiaP15HYuxgkIBXPfTQBAv6aDTFSbq5XeZWSQhQxIFouvlK0Ud+NVr2+JJTu2d076VAX/ P3YDznJ11ASb8yAByW2Wu4qYUBEoIura1fRs7nBJ6zw0doO2ig+4wQjMWaFukbF1sJPAbv66 Ysc0uBHygT5t30TKykkZRimOE5iCRqNcNT9qrcvjOpBdVjGAIEVJtJbIwhkJZbUr1WT8Fzht yWP4wm8I9AYubRoaa9y6ZhnQfn5xAS4jsVGgHYZ5o5E+qgruEe9f5AThxv1ibCdo6xoSijtP othlfFLCHQGEScRp6BV6GADF6NYFUNri4uOABJFxHrTMDv8tp6nVauNn9V8FBrcCqogUs5/H 4xpmB/iREj/Ixpi9yq4SoPARkIouQ4JwwkfylvLLxRLtWJf+Ddz1qFG+gV/JbL4UrkXMiyeL f9yovnbfOFx0xWIvjZoXU+OsBzLohxcIZhpnOk/9t1TeH9g63MnIwwTml8R2y4GBSTZVQ8Zp YRgGgGYz3VcgDaywbWdDGZqtS0VHFDPTgJBOlDGHRY1/O9e3AZ4cTtjRn6Wdmj4I/EXt42Fc 3kgBvL0AClOFCrXLRr2Aoi2aS8toG0+Sr2IVpnR5jJAIeL4p0pDutUYyQb6rhl8n/PuNmEuj 8YQbrHhhp68pXzn21IyT33JvH1yRpRaZNP7zjsiE+nSLUrmc44tufl6/BRE/8yCQ5eUGOA99 dWVuqI1tcCB361lJyHSlpAiG9bxEq0NrBcRe1DsO8PrZoMMivAlcB2i9NbesiVrbj6mluZVy pcqmd/D90CrRee46s+E053yy9e6SeGi42LRLOu7DGfB/hK5taWbz9GKu/Vjcv5W9JPYZzugf LJofVIfqWtaTE/EABMRv08hfweCsvy+7OVNS0ta3iI4MFvwTCo5jsPVg/ZZPFakTEnxpDKh9 TFpvkZnYztE3Wy41dcXJCwdR1SlA6a2g1/S+4Y8xSaiZ3bYiBP++eS2c23ZJDtM24Vi8+sOC om9k/1IynEMe3pkRAAx2FuRQNx3kBN8S9KpicDY/BpyFM6s94pUtyXV2NB5FUJ6VXcY72Da1 TVfPIk9PyNF3lVoXJ/qoFZgC1fjrrPpd9aHJOmLpYCR0D58Nb3z3GcSiUAdFxDaNs9SrKTKg w6zOz99gQ6b+qqAZ3PNFq/O5aB5Gr2r9rT3h6jlD/TOII1e2i7FBJxPffTVzOa5shEfaNQG+ mvp8EtqzSVft2/sxPH79Zmz4hm92fxO8S2Ln35RhBnR6XkjKcYS6l9OqndbxRxoO+iRAFuyj c38sJScrpLHOU9Pv3+4mmMciS/g0rqp4v+wKM2DY4oml3JfUbaAlPoF9H3XlVmqmdioGs3rd UOzJDhfY9gwbrAfG/7x97Ty4eC4apcE7v8VyXvv+o21ho4xNWXM3G0TuAlMLJcG4eTn6YMzj I3jeCZsqiqzQmANthk52+sEyU3vqz+h0WrhGUW8tqbyvPYpWjhZtTcewWDK0K6uXMhpCWAhn 9v1Oco4j2ADAjwdQFkygIuP+YZGK46NxUHb/G9CxDmqK0d90X7dXt4Z3G2gzeXzbK1loK0ku u52gp+m0V2djFkycQNCpR5Mj53qUwk2RoU7LQudIfS0QP8+JLnw7XAsNFBKnNU6ZCAQy2AxJ xlukbsUqGKJet2W1laZIQ35T7MzjQwqrOFmx8hEBhrCEFKxLEKr81ojQVvpz/2aic7RreXoD YpWSg0i3ezS5inLnfFHz2FNcL/P6ICf99m+Oog9YbsR5vbIwz4PNfX61BYyCHsbtMTp0BGAE aUz63AwjqPEQnZc+1WSbVBUCzyYAdh6NHTT2Z092Roeaq/vlxcNXADegA7Ou9d8mDUM3YSpZ zMn55V+IEl+Q301Ou4f8mBpQ9/HcL6HwzKAZQhBmVS7LByuCAknyOqV2OHzHjTv1FIHGTK93 F5Dc0UFbAQaos6ySW/UMuhkbBZcTKwXg1hfSm/qSyx4QGJxLI9IDH0Kw4CLZpt6zHnQkBXPL 0NkmRl/ErXr6XkkinGMKHOVfsLAjz++rq1/ZmrLZ/YYKsZIO1yx4r+1r7bEZEMOk2EOaOHe8 RxCTvWa5S5P8lY2cR4lrikbYrEKXcZ798/ds/7mQ1d5ztAELVActMIZR3wNzMl4DxP3uWZAG cbp6n418liNyYUuS4+gaf4KX77sNgNQ/YCF+4tEayIMxbPCSoTWAwyr/kh1pbYr6xSJI16lb a0zm4fXhIfjyxxRMA4GSpBGJxd7VpGsHFtLZ7LM329fZxm77apXYzxrCTWxiQI5lXvSviAY1 VmRX4OQNqEIejN0MpES4ePxD1Dl7JPTWSuIayTYO8Hf91HdsiNlJMdRYBiuAhEmTjx/2YZ5M +T+NCC2HVdzzWDJXLcNroHUGztqlmJn9Z6B1XlTaIukrqm4MXbXYhRMwEzkH1z0C2MayqvIT q0cD7fiuKJfzg8P5VZ8oiwNUUDvITUrwTCdfb6GsKR6uATrfHia/qGo9B4vpvI/d6GKHLYZm FbjI+ujQxjJCcjNqxQd/Yej1D5XlcLUQX038BEy+oSezWHoy7IW9fbcnqsrvei6WbdttM9qE iW8pUeXm/UzEMlZNKpN3uT/Fwbuumdv+/f6owFXMSAHKBS8m2IkYnE+GLzrMkpvBQronRIDe n9pYDd2K5G8Dtv7nj/3gWxf9KF1/VBYeRFlku9WXZtsoy4d+kiYMEO+xqK8OVf7dXvNcfHnX +FSTHlKWOJO1ZrsnSyWhkLRqix1gatcCzM5Eksln3Xj5u3kd6q2PIXqGfzqQiCJsPAjx21An YciZfw3yb7O9+7LoPhZb25E2oL48FpsofVoJ8cwFzaQZ/MaYeW6oZG/m6+kHXtNPeAddAuPF WrBUpYGRoqGF3UfPTbnE6bCVkfDSC0w+UVgq5zDKPZMIeUPb7mvJLMcLro+8sliZUuSi6ona 9o86U7wl9W3+LfIDdQjWq9TN35KANIAr1Jo/8CgadZU8XyP5c6KxsbK7sMniPE6Qn+Lwd+IZ ad3YogdA3sWCLni69S7QxzZybbzrlX4TA12FibA/qlII4mXgczOVw6PY4IOu5y9PX3Idgqp6 Ovhtx1+SGcwYtnUtgK4QGEcZEGTczr9AdovLLpoxre3Mh3FiU0HvRt9Gg7Vqyq+3pk4/f3Ha T6AP4EVRbrZzwpUC94lespKCAJwzIr94ws3u11Z/JoxYVUk9lireTtlosVDi4eIvIpuMACno 9slh9nBCnr0chrv+ro5prI9+faizgTSaq/zTY9KBQTu7uijnUmSzedABIUplK01+TJI+8iCT K+25gGyJgw8LLh/sHdFJg6UDo9N7O0Ws6RfzhrgOrpHzDAnnRqGboKLbNtGAX8ofgC81CgAI 4MmEPO/iWRLlS6P6h/G2xbpPlis9BmW1oIUo8RDr3cAOhiW1HV/mGRQCWuoN22/sDGRkgb1f nWgxqQnlKL4aUKQRFYbZ8TmQJKovQVzDA70ogv05bPmp8nNMFrAEpY3TfwOIhOi6BNRlHXU/ 5FMyt87+gw4kjBFo8AisEULHkuUzWzByUJ3Ru62+spQwuDUSU7tAVfEoinqc80+jUwUtpAZY 6VJdiPcY44zBtSFUiFkOC99xXlds2Fd4v5pu4LxLxV++y0qA+71DoQzeD2G5kHKyskE7GoYd zyg1UMuHnDBDfMnj1zPBfS4MOAlPRvUPvHLRztMPGT4uGyNvOOlVVjnvtPs89qzrq5gUXP3b j5I9rXZAfUrQxbjCFrqOj2oEfvAE3Gk04cGCocAJ8YmmOhfK9MsEECIsnotxuW3KQMdLyoR8 4mtIKZ069AKlYrV5o2s0y4tcZSWZti72XonN4Xkfmq3U5hq4OPL+HDPrwUnkRPZwYKKdP1PW KOWWMWrzLxXGIUD8EWCBSxSqS3InK628rPdD4jFHxNua3jxzEustMsf9atMzYmy+thYhXBZE 5j7QQL/+2wGFyIaPqqw8wMitalzTMAoui3wfeL+zlYDog4ZH6UyPSqgsXJKln3CTBE5zylFp jHW8pRO0UMQlHo2VfopkWLPf4/kssg7+OEzlKdYLe/yWa5ywov4DmzITZWsSzgfiiSQQvkzm jH26O471hf4Rrq419k9ZE00fmN1hj8Cxi0RfXFQao6POkf+ZPtO9OZggZ2WuxeXZTfz0asNw mrVRL5Ev0HIMDVpUMq0dE2G/Oyy3Nw8sxOIjMoY7Ma0MKTvLQ4f3rnx7H9ZQ0hLUqr5oS3PJ OfxUhz33vWMD1iQldhOwgOLd23mBhOgy5/4jQ2q8WZS6jylx2rtiErptYr0hDr7jAORcvzPP DXnco+oxpbNn4GCovr3LjeyAc87EemyLVOFPIeUV9kWTyG9PVNfNmBz9qdvBtliw8cLEn+Kl BuSBlDZnElRxP0US20WtPmFA2F04MU3mC57g4xqdFH1kTzPt6YPOGVnatZl2ifI32122C8lR FQdmqQ2wc7ZEqGBmd5NjSGQ+gh6NG32UCWNwxqmN/ZCvGqSxl6i9zQNqoJD6zTzODq2FJtj0 c0igu68DTT/7bmE5a8/CyDLvnN/B2ChoJX75Vk0p0KjusLZnPYiDRL1veL+ZHs1OXCDMgSzB A+vg9eY36m7JY+pNEeuE081E9De/tE56lSDYCfMWggkwMBKBKplxrV1hS+cRmg4fRScZSfuz aWbIqGOLJvEhEKkYPXM8WpFfY3UbWJlEnYSdnUldv1kCuWoDxoB3DTE32KunspKhJlAuIoWs oW3j5iyPxYzG7mTDdqJchFzyiJowP+e2teLeP9Q4YHL9JOlPJM1O4umja3ii5CkDL8R6OLPL M4/ccZJwd+C29cSXxLf7vKdRpySiIYPCoOOTtm2sjRdmUbsQHzH6ge5PdZR5wNpJxn+97Twi 6rSGuSbO59dM656twRorEc5jVyRUmUTqsGzdtn+E7n9qzRr0kFMayThOMz//YC/vPo6k9zWB +Ef+59AyguqxKCOHffRVcDfMFoGn38cIP3RxO8ePKJPLHEmgptEtahsWT+Foe/nlpxZeuwem nHjgywTUK7I6HAJt+HUdUsSc8PGkudxe3YAxdqte0ZW6zR6rtDa+ptteks6Zf5E5MB5smxRJ 4KWjM29KqFritXwmMVyF79W3YGzYC9sXEfyxZF/acCMWAZvymACaDspKVQsuRNJLmYF//+AL e7GX9Ayovj6Ft63GjKtQAiUeBH5xKle3SbICC/slzTPu8oLSJEwT3nDsZL7FHgqmzP8DUgoz aFEcBEKHRz0zOCjZHlgkhz0NVrCnQhrEhnmTyN61wUg8zFHloHudvtX44WXEW7dif/nAU2kH MxVPoXztoEyXSHeEAQHbR8DA+yx5bxY+/tWFV29wILbmJey3MUreqY3dKBRFPzQxEcJM0x/+ fNiDseGUfNaGDP1hlIhZ+Q21sj1b9fE+fk39EtLWG7q+ijn2W8zHhazM1sxcWPqyfyS4PG2B 1Exi44V5G9xQR3+dB9WboeFSbg2/qUvqnvJoRTr1JTRV5HlzNUSZuSGrggQZ8tncipQ3nPf3 SRgHaF/ltt6s6s0v0RBQ6Ihn9Xx/5ZMw9NES3SwJQqOUd5kiCjDtmKmuVdgD4iUyv3MYP0+2 hl5S1eAsS7YCBLT7f+bBXVsKBS9ABxa21TcFriSOL2eJQicfih4UpNTBgJuJBNgyaa5lP0Va qeNWotp1cT8s34fFpJmpxegpLuJj8Cz0LyOAt52RTT4Tt0pRK7xPxl+SJ+2rAKVWugpoU/DT 7UcNLaFH2kZmihZ4Wsyc/19dUIyRozywxqq4kNHzP63TlgKNYdQlGsdWS0FdQBb9Cv8SoWO1 F9pylqQS77t5a/Nipgsbd6PcZnorHPHnGQcKZSn92SH7xkXTDfKCMEtNpOQ04DISFrzJPVAx fB63aXuQZH4FGLJzsTPxGKbleEUFkkpaqsi6F+KV2eA8Rwpksxx35Ki3exbJd598G1gNi/fB 0fIJImnU14dI7ui+vKkNqHip1kY/xGdfWeDhcPedi8jxo8h8je5iRBteGP1hT1XM5rAio2mq A/0RP/7yghb0FfkzV9UwNBGZfqHbVilBAl2Ips3l4MGjN9RwImEK+VsVcGzg1uhFQEmt97x+ nb0Fc9k9vf7vhCm6cS5eDizjStFvXIdNKpsykL8h2Wx+dpybjAfQ+n51iltNDrlWKAprryHJ Kwkdx7czYdcyADlbdVTbcNhDc4JrgSCgtkCGZMRFG+nkBuCtH9H4QCJC+gCyJjzjPRvMzuzk 7kQ9I6A9sRAr+m1g3UuoEvijkPt9o1RCH2RR/4LKTZgm6u8CF6TLVguaaxWItMNDLONSI9W+ Ber6AUn6UD1A42OVVm61JoQAHXhqfWy4ejMeKxGz/vSz9+AS0VpkmwD0q0R+nEznYONzBrPu tgYnZso1qPR3j6v7KPBw0p1G0iSf9ElKUCHNLWRTyeTzlReLs9gS/1B2hQlaqM/Pjv9CKbnc 566b4atqgXfUcRWoDEmdbwz/Inx7z6RmQTmP8/wpBuMuH00TpcOYt7SzJdtLwK0HahNIrSGd xTWxnpYwx1Sj6EaHeMmI2vALBijIj99ycAaq4Ox6KEoVz7Bv3O1GQuhe2DgPV9N2M+LSSKxT 3eG9m3+VMbLJSd7+lPnDaUeCDexvVxUBY9yV99uEIn3A5R0q/Fdzt3RooueoiGY6Wm8J7HX9 S7nNA7w75Z2qjr4A//7sOs4p/aCuH5aI8IBsXr1S9veKVUU1mvaTPJb3UltOE/s5kwpVEM3v +0l2BS/bRTeTqWw+4i/ezJvVpJpcIPxqnpyr4AnijMj+ckWa6uSMzG2AeUEpzGN+jPCTYlIX 9ozDdSNr60Jfa0yafEhK/y4FHjDWIAN7I7JqJYgm6f8xAAssKBsmtSvMB/eZR2vT2ugBFPt0 7SiOMynl/xCKEgzzD0zzOcLeATqtnsldD8ObxOhzMuC4NroVth7+QnZ/qyQbno9Ucj/T+WKk tQmtH06dcfLsj+UnQzG+8Qx0WKHRqTrYPdnuq8X/NI07QwmWuXZukxT9awbOPM8clpGMO7aW yo7zTXOUYmX3bUuQjrcODNMC5gGWkOQ+weZktIBvg7mAZlNsAmei7z9aZNrJWtmzqK0iOKDW fzpWX+uIaSLVy22j+UThGCqMCbcrQ3Fe2R1QjTlCs7YfwiMs3zI9OjY2Jmg6aZHr/yk7ra+A BXZLRvdsus0LB5aRrLXPyi8Cd/rZbvVnRtwLC/JnrSPAwRaNRu8EMnuirhkZo4N/mERMYMq6 3fenCC7UAKDTXRieRYuDMEf9aA19JY/Iq6Ltw5DVDNHK2yyQI1OWHI10iymAFAGl/BC3J7Wi mYV6w7GAcgEhxBoUhHZdZ7V+CHh7O20q+2pxV9Njcm3wgLaYWTp+m20zuMLhi+kYoLBHL0jG /MH5nA8jBGnpqsMAeeH1eZbaKFu7lCvQHWTGHSHkorRS38eFSCy/qgJ6hIpyVuAUPm5IyTJN 5eh3OWI7ZSsk19kvy77cM1Gy7qyE3pbWlM3yY8t9Uo1imSo4nkf+znjcVGhynmt+U+CPUnfp C9p/t8oRtpa2pkdCFJm0+zXeLGyLp7LfQ9g19VCisOp++0nB8pfQylTgErIkzCblBBalPokZ X3K690CtGIN3poM4JZ5uTysleacO61na2rri+Hc0XUPLJlGjHDUx9suRA25HVYi8/HjjLOtG CtUphACNwSNwVu6swkQqVytYuQFF9rK0j5IdOUdxSJFui8jhiATKrqy3hIFygcuIFSkKWlaS fIBjYySC0NZQzA9eimctX15KMlbk1Nkx0Yvba3x44c8/YwQTswAU2U170b2VLnT70oZtlGXL fFa+SE2HkjPdxsJ5Z74DS0vROhcknTTIMCjnpq1NL4NmZm5kxoMKyKvHg/x3XXocDc3gLvmM vxXSno3XMupX8h2QIsn7OMWvA/w+6UKfYOG1jdjFTXXQcoudCDb0+z8g7mAfmdAkk4FwJF8F 7v00gtHdcoiJ4fwWRS+yfCcoPUtCnN0rNb8kH2TDI/2Z4YSEXS5lS0ZRv31blI1e5fMzIBsy 0NYi2XgqnkQP8cl2XaO0wDaC1yKs96FusnVpsrNDtwIHpt6Ivinscd8Y59z5Hnhf/5X0lnRO WttUvItEdUP2Z60nEEqdf9CrXiD42ChXCGBSPqhyOPpPA0p2aLfnGspEb4Q4aFr6HCiSYTmB Rnk1SRPlZtygKKhLPIBXytV7xKGSogDqPM77InLCOEUhij55B1B4PWTQqZKVIQelsL24RfYQ QJjprDKWK6hKySZyy41DO39uH6v9cthkHEwUP6ddTv45MtwuI64X1/jUjVNg9LESkfOcy+y+ +l+65PHrsw0Dzzk+raAtVvtwSpBA/zFGY+r8iyw12E49cs/e5E7x3QVCi/5irgZhC7cENMPX 4SAc+Y1hr/zwNT22k3qGeXg1t6tOYVhsrKkQprcHJG3o+KV3lpoIBYEdJXjws0ixixz52YcL kU8ta8p4cBVbYoLPD90TvAKTSHGHE0cgw6TwT/RqHqUr5oYyldAx963zcEXyVGyN7B3nnw+Y Ak42otdO4KMiOhIaYDWR0sIJD3qe71xE1j2sJTrUXJMtbuRNuE7eYi5piNaZ2sxF4gS/2M/g sbnkvbD71bnv3rc04voYGqsJ6Xs05EyRaqQL5t/xiM4yGzRZimTvXsKeQTwcty2OOS+lUy/1 sLzSNY/8XGXf59pVj/HFWOwPcGXZk2ksgT06WdcMO1BAReALvV1X7KIk/vSJ3A9wOFRrbvnV fh1A5ftEwJEsH6qB96D7EuNovFmdZp1mMmo1YpwBGVif4sGbYqqEd4KU2CfVrVmS2lOxgnX1 pUypGKpLPxmd1zF+IyoOyXs6n1VpPPQPGojyvYbN8CwzGxVCBBXTFhLoK3vQulu2Aod8pEib JQK0aLpFWmk1hL153XOnKBVX/noCTL640qiHaVpyugUWNsLibYjMWEmD8KrNWv4N+7i8axdo L33pS5ShWz56tu4zpVGIxkM1s8gbsQ5wGryvtbjcurHJcVfYmzfzIWEvlnadpBsPGBRaHQrq cwvpN/v8kBCjKBjMvHz0VBvSzsk4Fj/OM7NBgFm3lwKu90CbbQ2bXUUxD5irg9Z+8J1hgobz 2SmCQ3ev3QHCt9mlgZYXZN2V/2HUhV9e1HLIv0sCzYk+W/Nq4/IpUr5DR1lh51NbN8r1O6ek l0NIgN+f/LMiHIiaAc/3wDiI+MfUG7CE9ZWoJDUD0fChty0atq5+BYAXqc2vXo31EK73JHnk 8lHx7OF/Up0CwUIrtRPY2CxOLazeZwgGOcqiNKgwM2ASnehMsLBAoZt1NCfQNG0nbo2Zr6NV MkcdNtvPTimxd17Y5DHxiuDqvLOebtyxzuxpmI2sBI7uXO/kcjgqCLJJ9mN+3507wyX/uI0/ n1q7FOPxxoEpcenJiBuUEKskEmlePd6otR7oivtNOzJfLdw6irmLTdOz5qISzx5sYcIFXyMx +2P6Y2104LtgIF9Ao3lqpArZX5hDU7mhNzllNMGDrqCKfBqL7+eP7AxMdhdguncKsHa7glYW KG0KiJDIoHa5YeWgR8Rz48WowBit+QfVR3u1/6m5TfcU904F3utUouErFSNIS6UmrjVBxkhk f+33WCw7z/pZzXRTfKYS6uN4K+2b8x7fAHyM+Jl3if55j3R8ej35ZpgdVDnD2M5jC+vjFZGI Wve9k0RWLvIk5K/OQx2KBFHE0BwiBOpMJ03rlUAJ1/EpjzHCCVzpIwBu4iB055XyZ9S+0aoF WMTRBJib6JKPcvVnqZWnkCkp9qH+d8wY55FglpvHBWxnh8Q/5m1E+bnJpIF8XjzqLq6Mi/qK nOLSIAQy0xFRlPddEQ/dxDfPox64paqHG9B/yog+CAUIyxP8I0jRozLlAYhWuJRArADMhVQu qQxdQp47D5TNpwwvjhIppHhQYLdPZfEuELue+4ymSe/KzdNXNE244U5VkTvrOOEH8q+Jt1+O JKzXPi/nvoyinZjgONuN9A4D5HD/sIcDgP0uAZbtI7uB6zohniHtzeM9Yk76EHnh35K1Mz3x kh7Msnx3oW+x0DObn3xx7pLJXezj1KU1OwvPPuH3vxWFye8q0/n69i+mKqK19770xrMEwz2n BiMFnfq63grEx4m+GDVnY0c9zriFzGhnAj1H/tJ90ewn+YuRXyfOB5Pm9vREdFwwe3gj4neA i2nGgIWTfhL/iGKcPB3Uq/0qYCHE9xksF5WZMAHJU3Ig6QAuFScZfAFbW4Vg4bXepIuBi3aj eqBApXNTK+h9xAB506NDQF+DPzlEONqJei+xXt48+MQYjUU74JIuLvgeYTfO2K9fruK9A0XC QXnke8IrBXCohzcuAvJG6cjPOASxRvuNqv447U33OEKkZH1wIBjINB3FNog+k/J3sIP36yzZ 15jYC82/27qViHzvH3xIjGaCO3ATGoEjzJybVJpKc0nwHVsSW6kT04z9uBeFM9y0SNF8mpwJ MLhEKHN38KMW210KhP2Dq2cbVLd+YDAWv9CpoG/lxfoiXaqZNMWdg2EcOg7EfRYH1yG25z+n S4HNcqwT9r4VZU+Q1BPNmZH4SNqR9VEqyhTZ618O4EHEoNwpGLdVInG9qkmkWxJfjeR6YVCa fkkRVYAqUfVQNS/WBrPrX9CR4IG5AkERTEN1k7HD0Li49a/0ZCUwoHejcLrEikAUMX6p6Bt6 ykNoptf7sWJSEjy4Dt12FFeU/xSNaBJoXHFarqrhUirDOjWqDyjcLOJuNITXjfTUrPepJ/U5 M3B8fusnflPK1kEW1nU1xIzuFRQ7yUydaj0W4V3kbXJuUZlVv/9HO5KWNMw2iHK8q6+Ftcbn SizfSulw5PH72pQhGtRZ7pQx4FMbBxBCOaB6D5HJL+aYWSEqpfVAN/jmeOuC7WZiNFlEMI1Z JOhXAaBCt9CgSkacQSQ89YIDgV3tS02IPjVSgwKsnLDy3waLyVJ+z5iIeoYUKWbK7W+Pvoqs JFBmiNPWCeqMhWe2xNbEwQWAfNUXu/KNNQ3WcOZGsDM8nhWNHOS97/xdCWzZOs7/LdoA1ild q0kmRIi9NdLUFDloF3dLo4pJ1XedskEiAG0TLTbZJak1Pr1iMuD43WcfI2CC5PEwOaUP8HwN yeU0cXec6mikxGMd1si2yUVPq/dlm9HGxwnVHHzeEwvuDxxMFW1Fl8AbyV2xIm8WfO1qYiSx lezgxXmWd1yDQNCx37f3S5m3Vhh1zIRl1LCXTXpNYxAP/FT5VOK93u4luFtGmGgpf/RvrWbR KDMizjjpLz8VlenGIt9zJEST9WD3AjlGRh+9cp1nZblh4lct5CFedyzLLwLE0jcgcIXGhyEX 0eG/KfPt0zrZ41bYHftsoEAFqbLhXHjpVwYGkwjqBJCPreQwHs8wjMYTPjOTyLxtIOKqQp7U 3FwD4XmWJr3EiYk4cPicOECP+iBUjgDdUErU2cXPl9Gl6PtRpBlID9920N++GYDMoagFW0Yr al3Ux6ZUDEyvCPmfW0a81K5VCWL7lCtru/455G9DKKUsnkqnK1zITh+2EEFJl2GXaL21cmNL sq3UmJ8rHUMjZKGAwEP2/al8xdfmFSM/B/HYqRwpOp8i/M33/P7Dbfj/GyiU/JDF39xin7U5 h/9jrSdCwb4Uvg2G/vNQwRHFLraaK5JMKKBN76tqiQHz9wBUuNWBSLrF7oTlsk/x6DUl0fAs +aBwY6zQFykAxvgu8+BWRpLhe/R1i0FK/gzYCBtJzuAE2BakHA7ztLGzxua7/0ZUpKZDKLUs ej8ObodCcv8YhyFrtvb6Fsphjh26RpPYKVjNBb6X2M/nHzZ394Yxf8pGxy/1p8BwGHwvKfT3 S+PADgsc2RNbZMqS/OYkFnUpMScFv0GrvdntUwDTCEM2LBJTZt1YNqbhLVgYJaRzyMYHKANM wquXx0Y4FD5JFh7JoBkTmrvHhGHC33M13ia17I27WzQXnwAK/Gow4KD4wdyCpbZUO3j4pEfm 8pDmy4rsJUFqm1WQ+K9irGMwOdiql5OpfGdt2j8ekAln+yrW0+MqvJoV50lhkqUFB9UNGPSQ 97G5UAA4eDxG/F6jCClsJ/lDA4tSAaeaRPDRTgkWlFwMr6WwZpoqtAhMfrQNKnx2jSe6uw3o B6A6Hy69C0PNTEvMB1CeBV3lsbc7ontDnIt8W6ZyQPuNEA/gBPHdl39MjWjJoVx+eLl4PMgS 1aBn8ZvbJA8TxFZgZZi7kqjxzaJe9uNLLUJKNKV0fOGYUIm0R9aOKHkv868mzkxufBQZu+h6 mzM470e6fX9V09NM0C5C0Ap7/+jCjOWE8bb4CMGFsJFozKtQl/moDV0wrwNhrAv9YF7vvquZ XBjaf1pC6Bu9xFzPTHawX0raDOlb4FvorMalRRHI+NeOg7Ru7tJBbdm/OHH20sp/pCBo1Jj+ t3Drv9f4DlJWiLssCGqObv3vha+TAyeMeYM7DByMCsYGuLGhK6qzRY5L6KFZtKcKq58BhE0H DzETySU+2FURAYVSfaqF5yi8VlJp4Zba9XedtQMW6rjZ4PZ+utv/sJ9cDrZ8sCHkH4qHYWvz 4I/PHeC7WoVZ9pJWrwJnI2x02U56UM1Kzfi5+2vmtRuXrkJkMt8R6KpF3c75Tz28u1h0wzUP xGcSr49J1NQFn8qnv2Mv12slaJyQ4mqTLs7lPLYVSridQ+vATjzkDsoRqdIDH6qvIUxDSXyO KIsIkgNsjr+N1epUx04gHuRMKxz0BS/1cavE4a2ZR17LE9eZ8UdZebHieUGcw/q0A/yurG3A nEUEpkbCQ5O+qqvOV7pf5izdKL4BArZXo6eU4Enq3++LjmUVDNqUOCi1FfMa4Jg6FlqWEB9z lnQpJ8AL/l9aoOuBHR8GRdfZv+ps7PfnfTdIZCS1g4CBLrE8sltghkEQbKu38LtHNM6HGTg0 tEVfTUN2Vlvm7s75a1Md+7w21j78MZjEi8dce3yh5egWJeVv3YVbyuax6cps+N/jy74ipUyI fwQES28FzHqJ3ehZRo556x2DxdnJieuT5A40iC8Zq78299jarVOun7yO2UB5f4x3LJaROQHe ONwO64h6nSjuRirHjmnjXO1ylk1B3+cFw1+FwWgbGmCzNc18Q9C0RUjqRdljhRHQkk5BhsMy TsVQ5jqw38Oouma3u+WNBuhsuzfLV0PK+dcTqYHfy6NyI/wpAxlWC0eG12dn+nsPzyKejsVo AgglMMJyhJZjAVNxe+x+oCL2E0f8OjfsFQB/e6AuTmqj11u0mq9OrExWNyUpEB2kBerAZwUm hEBJWyovxmgUTeGvUTWO08m3AfgKHE/fxOxhfzX+Z7t3b+QzslojISmJKy0RFi2ZQO8T60DM lEudk7jNqOW1f7IK8FLsv6/b6WsXSnUk2/RRT2zuZCCxaYxyTbq0J7xLhPenc9Rm7HR9S1i7 Xhwze9VVKEIDQx1sEiqF9/E32SAZPU9fBT5XwQnhL106xl7eFy6RIN6xfy9DCXJ34WJlxBR8 QtJUcyM7JezkuvPvjhOLVx3KZ3qhyltRV49detZhzapCd7l37aJDqgYRezfM3g5Hf7Hdvc8f Z4YUMQ31DXwy8WfJJzEbrIFqV2sSJHynFlILty+9jS15vMh2SYCzxOmg9FnlNZMemUIRR+FD 9t4Endj3cEgp0FwFMSA5clDltvcCh08jiBfEHK51QHikTW4oiNWc70lg1xsU/es4IDf3riWv 3iJWfyiEIlT4P4Hr1JhdlEAN82Vo+QP+wpgs/S+f9aAc4MrX+MuRA29Ly3b7HRKUXsI3IZk4 SV0UrxxjdvUJyXEDrWG59O8aIc1kKW00azsittYDcW4TWiEaMiYQyCskCKQVQAoChEGH/ni1 9lA48kZmkd5lbWtB7tRlssq0ory+vOUzVTxCo8y66esuhEBZHg8fN1bUAf+cAd9gl7VMpAzi HjRW3ZggBxp1FqgC1Gx2hADTgjn0HUKJblbGiyH7R7qaf9dojsAFV7cpRdEZxKkT4m07jKp9 AmlqW+5sfxlIFn0hGq4m4y2EPlTl+TX4DOjbaScX2w/lyLC+cmLJSVVFLGW5/WXk/jby8RnQ cIRWe5y44hsiCmPoepdZxU51wjBN/4xBACU2BctCjlbH9aNz7U8xYo/X5HktFNDU3i/Kk5rd xPf2/hzIDirOazw+T57kTA8g+XyUDi633KTft4XUOfBzF0sNVdeETvWo7CsOt7KDvS6MxMJx e+rk+RiOV8uwq9pSUQjgpI2moA9InHcFH1U3LVnhipFaM13c0FBUgQD87j5uW2YCkypmKkRm dB4QnGRmOvkqyeKOjywdXUrRCxHwxMM4bROVLWuLy/nfp9dmXqmG7MIdbvoMox7eMqR6f/c6 GaWIgS6y2b+Evb/P+6t130xAGS7YeHOZs8PJrP7WD/JfVrZKCEtns75npUsUY6qwWJajY+aB MBied3jENwxYWJGE64wrzW7cVGuhGrg39tFa53r3Vuvy0j2PwiRE+7w2B1fCWxUD7ZUyE4Rq xF+8CJoTaRGcbMsjlaHgZD24ks/KIz4g8ssRIR7o7UPtknuHvILYyj926We7qSwtqzultSFE cZIDxUHym9+kIlzkPonqu7WupSLaDivdk7TKh+pq8pDq0a2gfObV5xdptBDBextk2zxC+rTp b0DY/aFRQ9Hr5Y+r6qHPQpW0udQhsDefbF1uDo5SAAUEEH02ThmUYg8si6J0VfqmLpxBFTRE FgjqKBZyIXdwEvBzvR1s2k4SNLNvrweM9hFdUnReauLz1n6neh1Nro3egckK3dAO1avsGT2e szOJxeFZ5WUtl+a9i23qVDOevR43nU69Somssh36/RvLZ3PYdkBUJ/RGywz+OlpADCxFKoQP BaYxs83T1v+XHBBxXa95+iifPnjaWzQ6owrwz3Hl3taoksWEdwVcu6rOzgqlk3eJKfkkFFNn NM8ddwd8xx7gWDU1TUIOF4QI69P3KxygSMSBctsKP9EJ73tQ7RryNER5Mw1flP6sCHsa7TSt nQq6vI21QSQYAEirLxO3cEa+PZShUTvq2R84DF6phxDllfWiYJlOz3m9yUCllMeY06EqjotQ 3RQvq0I4GAIfUVdkJLS2RViKMSuD8H0i+hrGx0Jx7BIq4JAGL5tfEXqscM+2HkPv70V3vQPS kp3TiYqH4yl0INwQldnrRKmXrtGHEIFP5WR0hBdMuBfIc84ajVufDgKBdN4qCS6/PcPhRhXA l4tTheen8xtVjdcAW6eUDF5+kPoXJCIL8JYUjzUR1aAq2P3JfFyjycJqOD/BB/H0h77mwW82 Fp5UeZgba9EAk0AOa90Od2z4QXv46t8b10zDoGAGkjKm3nVMlMDmMFvXHndAnnBOKcP3EswW 5hW3zFE5pD4OfJN8HU8reQ1kYuD/civU/+wsNRRbi6tSCr2t7r6hepsN4eBad2l+x+hjOf8L eMDJFPyiwuPBnJGgg2TUZNBJ8cNdNr6h8FRIK6kzX6cxrsIAJqTnSjgN6KKRpt+8ikvVrhcP puTktojiFol/kXDM6ohvcc891UfHWDE7tW+aa+zh5L6sCMMr8T39+PSL+DFSE2AVU7eNKyY6 eCPiDfIqOAuIH5pPdUzgVbKEibZkfWft1dm8QAtSmoS4oCcMmesYDXSUNdPBTxwSmu3HDBVM kxXXVTP8VSts6mIktTmu8ZGu8rhVVIRdAl/pGSvdco+2yKyt/46xZ1s73Zt0Z7ndZtvCWwox H+l33xs51sYPDc94Zrc2neXml7Y5PvS/KIY7FXDWWGwUgqgamn8muKSF2IWq8wFx+bLa5O+W WMsLnVgkintNfxEFq4Ygo3eHfHKRwpAyfBCxijQvZohOlU/WRlXpcRiU0/NHvR3+BZsdaR+9 87nIfl/TqgvM97CMCl+7BBPa6QbomJzcCuOo2cHrgG52Dd0tB4/frzKzK9JJIDgi1worbs9M hBnmDmTeqiIvPwbncE1SdBIe/lPRk48zfOGi/D6NwWDPXnvU/WI3GSLq56SbqdarFizo7fU5 dpdPu+c2gIo3P1O1fBmDNvVsZIri6Rzf+KXKAoLfZSYHR1LBpPSsSdRm5WXDqRh+TpyI/X1m vxFe+hZ/OgPBRVsV7H8XikLksTLlSb79gFpZmwRV0gnTbFTdrp62ng5ivcW5hRJ0mHsS1KVT K+Dy969Y4KiIDeXaw3UK6qIgqsv7Asb8Pd4OvG8vbPIQORBWIvIechw4fYp4wkjeyvEkRnGH 7UKtOUxBl8hjKwpda1S02SLOhuXFCnpFdUvnLuZohqmQ57maf1mh0qCJ7sn3BMkcgG5VaVs/ i9vY3g8VQTxkKEBCPs9JMrwL5CIzPRqiheYyuSKLSrd9pTLwafg/JhVHHj+rUcSporegqUfa 9U5eDKINFX0BdaCcHh0B8+5i2eV8VFS2Ux8XVeEI7H73JLNKXGRY0ls8zZXvl1jpYANR0IW/ zx4szz/AT4BZJSNP5OHyTv0LNoPIKWlQK3D/NPLXw9BEDpe01tvU1LlE2JrARf/dmq4yMRSG 9roBSXSGI7KKd6AgYS9odaOfV3MNA+ATQzRu6vxEGlx+LxJ0rpkTXZ0o6nDcplRV/fdnpNex ThahoBKDy3UJf1mwOyMDgYMRwWa2OxHQgrxA6AFTxrntIQeZeHqDBGCfXe3u8ajJQ2bUsFoP eURceDXU9ufno95Es0YhPrXR10WJutwNZew0dbAK5m91kQUwpX5VnG3DoZ7pqu1Rq38R5JCz kqoK6qaZ3smj6u/g1nM1fysJalIKwPlYVooyAxrVWig+cim7NuYeSwuJCUv1ueLueQgJ6CQ5 Xatfate2JHSM1dAhQ4hztNmISjPdkUztZJbRmU9PsLyjx0AiGIgKARJVy42G0IeDH5NDWhBl AgO7k3wxBrVZwZb77yF5JzENtM/n4ws4b4nsdt3u7jh+RHYBwJoigUHwjT+5t63eELt95DRP YNvYxcgyuLasNsLJUwSffFEYxxOmz9ynzWT1f5UE5gP5Tb5oFvCqRm/suE7uOShAI3zYkG1P y44R1twMKviz3wfcaGhD3KuUpkcOAWrgrvSMGfuPSr99thFFnAz5nExDrapxZUf6Y3P2JgEy WwfzYNzZ/AJEtrvOxnEg5n/42CYId3/MqcSfb6iROth955K1P98Y/dvAwADtIOjOnNoFans/ gJmoHpIwEThwJN4OCfEhq1qxqekJK/2kJ7zms+qfnmDsCmimqEmQVz0tEODzLPAxz4/jC6Bs BpjaWjhTj5G7boD71kyzqeX+Yie3g/1hDDqJgC91msQZox0HlnqAlThfI7UT01/RzEt1XDUq M+sAAyZBtaJmdUrHodyDovRRst4ZsxrnRvSkAw4vx6jwDO+LgY+In5II9almHfYWNlPlZ8Bg i7mIFNX1XXxXvb8qOyaaxFhSeser/esrGhg2+NC5VOhTGwj9DsMhFK6w69oXzYeQOh6MbJYX R/qqBpwtX6j6oOU58dS/taRBWFviB0zUpWg6rHZmEQOTiKRXb3ymqFx/b/x1172cETyXOo+S yChC0Dw9lnQ/3TRr13k2mdVEkBz7Iu2iovyFwcBIQ6L5zRC7vAql8pwkBSnGeoRhvwGUj8Og gL4mUN2yl4qLEXtX+14+JOY1wb9Ua+FK1fvC07NUQcdnk6dcvAJRL5KDwByWhxRMKiUwMHRY 987eL5Zp1zdkxpfpUoq/tq0cEbuyfSAtY8ywpCoq6VVwHxDrlsg6FtSOkv39U/4E1nxxzwIv UqZSjwOIc2quEoos1twZ1btd7Mut/K1vCNJCCENGYAYzrGlvQCNYuxBrJotLy/DZ10gOMNH2 rSbAgK4u6PBvRO8MKv14hpFsZBvYSSL7W7W6oHy63DeMv8FS2/J2IneC7NjQeFhAk/B1r0QM lULawhRF0cKUjAl2tc12G8xporqeg7GvGix9jsugNdbGCriCniMtoK1xSJzKgLwfwcZoH2Ih y780XdKdF/GUSY3bnEU/8TLlHHvO+fzUE9hb34Pr3RIqKi3GuX/fJt7NXAr9Pp6cv5QxyPS0 pHb+msOV260I+DtNj7uOfeLL5imihXImM2i5AHPZlVlvNkFvWrCTblfzKBrEIKwbr66w+zqh tm7SKCEkLm2nMbWxs2jdNT4Ffrh7I3GuNh44hPNjAAqpE6nCWo4w+vmA/6REQ7Df8qoel76p j2ZD6NQqyUP5L8XTN0EGIcgrjbJbx49iTEunyM9VCROPTpsqRtfPvyR4B2Bzo0lhGXKv35kk HRqCx3jyT3renIw+oexQMCWXxgP0UYG8aI+sO2Y8+uKC9u1vWKAc29JStCbt4o+GHfaJJilB KbAzGao6oAVPoZP2OeZzPFkBjPsgYg6zRJPssP2UTqqvZ0ZziUlnwnyo+NA7Ygv5MyX0Nyub rLAeOCl9exC/lHFFzs9kfD/uBsmEE+wc6Qv5CWTgebBOc5Zcxp0eN1Q+Xtn40zZyQA8kq8U2 Ez0yXWoenFWq1GWeHU4xUi66GcJSYulIvmUuTzeoexJ8lQDpONp1ibexiyYsayj7scINejAx ST7oyqlzFPbtoy1cvbK5ATu8gfmqpRdtndy9Yeq7h0TU2L5c3HFhDUCd7iUH6xqNqDBL+6yK fk43RVqFVJ99nCi6yqPfYX81L3TvprHCViyT+86Bmv2OXHtE08feVGXsL7m/065fqYw5Vd8X JoHKxc8NZW5kc3RyZWFtDWVuZG9iag03MyAwIG9iag08PA0vVHlwZSAvRm9udERlc2NyaXB0 b3INL0FzY2VudCA3NDUNL0NhcEhlaWdodCA3MDQNL0Rlc2NlbnQgLTIwNw0vRmxhZ3MgMzI4 MTgNL0ZvbnRCQm94IFstMTY4IC0yMTMgMTAwMSA5NjcgXQ0vRm9udE5hbWUgL0dvdWR5DS9J dGFsaWNBbmdsZSAwDS9TdGVtViA3Mw0vRm9udEZpbGUgODAgMCBSDS9YSGVpZ2h0IDQxOA0+ Pg1lbmRvYmoNODAgMCBvYmoNPDwNL0xlbmd0aCA0MTIzOA0vTGVuZ3RoMSA2NzINL0xlbmd0 aDIgNDA1NjUNL0xlbmd0aDMgMA0+Pg1zdHJlYW0NCiUhRm9udFR5cGUxLTEuMDogR291ZHkg MQ0xMyBkaWN0IGJlZ2luDS9Gb250TmFtZSAvR291ZHkgZGVmIA0vRm9udFR5cGUgMSBkZWYN L0ZvbnRCQm94IHstMTY4IC0yMTMgMTAwMSA5Njd9IHJlYWRvbmx5IGRlZg0vRm9udE1hdHJp eCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0gcmVhZG9ubHkgZGVmDS9QYWludFR5cGUgMCBkZWYN L0ZvbnRJbmZvIDEyIGRpY3QgZHVwIGJlZ2luDS92ZXJzaW9uICgwMDEuMDAxKSByZWFkb25s eSBkZWYNL05vdGljZSAoQ29weXJpZ2h0IChjKSAxOTgxIEFsbGllZCBDb3Jwb3JhdGlvbi4g Q29weXJpZ2h0IChjKSAxOTg1LCAxOTg3IEFkb2JlIFN5c3RlbXMgSW5jb3Jwb3JhdGVkLiBB bGwgcmlnaHRzIHJlc2VydmVkLikgcmVhZG9ubHkgZGVmDS9GdWxsTmFtZSAoR291ZHkgT2xk IFN0eWxlKSByZWFkb25seSBkZWYNL0ZhbWlseU5hbWUgKFJvbWFuKSByZWFkb25seSBkZWYN L0l0YWxpY0FuZ2xlIDAgZGVmDS9pc0ZpeGVkUGl0Y2ggZmFsc2UgZGVmDS9VbmRlcmxpbmVQ b3NpdGlvbiAtMTEyIGRlZg0vVW5kZXJsaW5lVGhpY2tuZXNzIDUxIGRlZg0vV2VpZ2h0IChS b21hbikgZGVmDS9CYXNlRm9udE5hbWUgKEdvdWR5KSBkZWYNZW5kIGRlZg0vRW5jb2Rpbmcg U3RhbmRhcmRFbmNvZGluZyBkZWYNY3VycmVudGRpY3QgZW5kDWN1cnJlbnRmaWxlIGVleGVj DZmbdzTuDuo6o8d1jORu4HpobBNaoxgY1zqIHZXWv8Xl0CkoAAglfLyRjGlbrqs8tzTSHngO rQwYZeRN/ye+yXafmCIM1SyrdkUtMZXvOxH+gn22rdg4yqpTrmtPNqUm85jSlGdYJ1B0bKyN pTvbRx7WYwhWyN9vqiHhILZolHhYmGr4cFJH78Dua5x+DP3+U0g7TiTGD/8X7qF0DOfdOQRE bgA1npidDnDk6+7qncfBW073ex8cCS4M/YEKrsC8hXb3XiVSRGX3+cFWTdTsRog+3ca0z/Dj u33dfs8aXfec/TSKmzDb96HmKLVVYXi6HEqXRGBVN+I/yBlWIOkq8AOfvfwvS8B9gvgIt1cs B0mXrnwcIw3eKRY71phrWZsGRV1JrDhMTkWfDrJiTxEcR8StWikBm0ufzRI7pY80iCVVP50Y 9uTd7TgXKLchy+QX9L7WPppL2NsrlR6HCCS+zIqrMs6cJ87q3andT6hGjWnBzlaNXRUeQAXc 8GRSdXMH9LhCm1WtGeHPR7p48mKAQgL+rSygR6hZIYRSzqUjDm344iC4m6iTzhkBADZyzJz4 IlxcDuhVosLPF/HeMieq4N1513I0tsioKptKNHLwkwok7qutuLJz0IOp4/sui/EeznqA/d7u GjU9eN9Z6BwoaQ5/8hTk+eeaf8DT6STsKUtwehpYLCZ000Ailkg2cGViuBV2vHa1mKikHydW Lvf+o1kqHe9tBu98n+9fSUUyoToeCXRlIYPBXbvME0NAne/ieMECWbgo7qJNmGOfTd7+Aylh sUT/VPSgvcJwgYMIvL5L4pyz0QQwm9q5a5XIqMkGof6EFVlU+ofgFrdGb3i3ZAE/eNCaW173 vCu1s1OPAV7bNq7bFLA3G/gnd+aIhMvphxCYv2RgT4nLyQUvFYcMEgHMxxy5aPzJZflBfvXh fFdmheDrbXkP7t8ws2U/v0k4S5JWcqyyvzjMfxOOv2Xk+u/IoR27YZdaBa5UEAeOUAgpxjZZ dvBm+mH9aCg07efPyjvb3o+2q+12EaejFrNrM9re3E3IQs3Wb1cl3nSn3qrdNGSc6/KidxJb emapuBRgldP72ukuuVOSfN+BTC1xW1gf6Jztvvqx7DdH2bubbxOZAo6D4B1Z8x1OZMA1vc30 LlO5fPhM0QQBoGwWri5nMbRpYw34cHfxnjqbnKROIy20kXyoQKv3iniUugy1sDHzKU2+Te75 F77zRDW2qftqTTVXrPAKDyOZ5PvPgLSrmS1SOtjA9jug394Mz7+Qs2EhMaKyUWL2l3r5QbB3 W/NO4SDW2Tx3O9iZQeSl+QH0uIaztTL7kLm9UukFGVl1w5tJGX+Mp4DbeGsj8ygNzK5JooEY aKjgaDcNsf2YewZiWlaCFzLKy5yZzA1cdAgf6NxLSbQgNmWzwcC08vptuKscMK+rg/fGWfFj CCcxL8rqy4EfGce8Op0/XDUlcPcU+kS6qsJ56g/b5T8s4bGoflwguucRduiEm6s4GkJQKoM4 oPRJkfh78QZ0wAikY8zIcOEF0RDfjzLQP6liS8VHhNAf4OwoS/pCVC1A9jcxvvrix4dCaRnG OBpiEJ4Ov/dmaBby0PdGXdKvX3Kb5kwO+hCR02fx4OZSIsZ0qvBMmcGXZ0No+xzMKjxYgRic VxSAtmlNIA5BXz441m7Gf1jXh+zjKK1ZxkZg1J3vjbTIYFn7XzANBWxJlpSv8gPj5EfiTtN9 JFBdqBZqrUHbF1PzAvNhpEqyZ5iRP2cIJdoAE8FzwUhQPC8qBcXJJQ9y0gigwxGIT+x3PKX7 /sj64dnXCblgW9y7OHyuAmH3qPE0h0P3CAI7QLNWBt/ijBlJ+4xFzauQ2zm72bo27Sbm3NUs xniExoAZHmxGRJNgHPMHTOVlrxTN1SVNNjnpL3sr1p3gMjsdJK4teiCVrthwg8Ru99OxiT5B G8bpnI6ASiPa2ljJ1ivqgwKEYaH8NhQGZdLZG37D2YiKaNm21MC6tOdANFYHr4g2xWycjgai yyk4OIOXUKRu454Fr3CMob7+Wc2xmqfC4NKdrlQgDYaA/61aGwHvu7/YOcNBNoayCmu4HvBe Jen1datbT5F9+9MdoYBD3+vSRjmDSdALF9bQ9Nkp2WRCEI/O38roOpN7lqRrn7NKZVLt6mxv ZOR13m0h7zx0NI3XDrdh8VeYh5QmXkkBdRUvexMxkXkX95cPlApnhnSIXSwHwRzbQl9RS5xY WvKB3OgX7CLkVHbNAFBsMUg4JiniFIWG141C6JQHAAj0SvUWWT5Jzk09bwUQJeIU82fwssQ1 b+aeUmyCWfUk9cHVyE0cNvQcdIrSIDdLOBRCcqtrz5kOLKXygPnzAlOTtmogmKAlNPiHGDvD DZNGllDS3mvyTgexXEWpFr12nmcOPOgguHfCqGe8fvieI08HCF5QnsZYkN4QYWU3nAHFV8ps 7df1rvfxDB5oZhOZoLC3KdYkedkj7R9l5FavCVJNWayD1eXgzeuk6OZLR3/BnUTsp7y+Sfeu /51FtMhzufCal/SLb/hj+h+NMJ8NliPjLTFdBnA1NVWNgDouVPNvPcibsTPy1bwraN/pVmUR bx/9bLzUPLMZt9W3kzeTPZI7NZ6P7UoOR3LIDqPBZn8nhbZzXYEfl8qIxDYRHY0qMar4IIE7 x4zDkj64cFZmItVsuSs+fiCKWKPbTfgeJvyPYTElm8aLc7GSgglM0GRX4Ti9+ypxnl/QEbJx CMMBDm7mMuePDu1kVKhrO+z8AGZZHk+fVPyoUpPiOU6FLOsdeCE5+dP9VREw8gJTK51MvxFw xOfJWB67tv5l9Nx4M6F85hK0D0k+VcbApX3ZyUWHL/KwaXlD4y+gPz1MHybU3AlihPv24mKi 3vVK4mZb0VRSCUclwyy5kJ9z3IaWOZ1oKthaiuTrnlxZt8a/eMugRwViHCqDY9AZoNv0kKuQ wa7otw7BFpqanQK5Uc26lI36Zid4AWa+57TprVzOVhK+So7Q3cnDn5Nitw7qtZi+7V/4Wmad 87WKg2f07T6Uo7bJ+BQmpxxCfgkXrYnf6TY9KVg1jYS/B2vdHSkDZvW6Popn5A3muWaEiSnX fW1hWQOvahXq5jeuoBrmVLcz22dQQiMHRJm49JzWC8VKp8oyMa3Zgoag+aLmViRNveUUc+kw V7ZeMuMflQniaLj1qWBpv3/kPj3xWu7yb/8VCC2xEX2jmGqOQbtSepxqZJtWdkgWiTxBbW4D MWmAuui/245bOFJlm+JtxIOxgcsQBJWGh9itqY77Y8bzFlH8f4mKlLMn0LmsWAgznGYcozPR fSiBMhAnWkVi9Kc3RRO7so+z3GVhWW1ldIk4xOt4iwHIi6Se3uQWgIbTpl7rjpEkC8wjEbLW boXSyiLpj1F10AFpBzydhxkHFfuxXyNEi9P1GCa9a/cmVOoW6Rsbwbtdq14vseYcE8wS3Hp1 2eKPfo0KVZ1yRxB30pNhuOpx5J9+O2zgjautua8U3b0g7+qBGhW2fGszNBmcmFBvMvcT7biu W8KFqkkuSC3jB3bRZu1SFU2Mus4Mb74JfO5vJlXSrOrPGwyIV++Vi0Nw2N8FtHyrFTZr2WDw SWZjrhEvKcTvK+MxrPD5omXp48zgcTAGBorQhWLn2PBKBMuMLS84vOL5I2TJh7bmtsh+pDCb UV+35WRtgPSXrDRxBVzSiLteDW7le6xvybYpdPsvrBpR4zSqvx3CQi7nwBf+slhMkdGFK0gy P5h+pdUnXb9Srb8AWevRqf83dpdodnSZSjXOOtDTM6OMlelsvg74WCBTZkjZLAbMzmtLJMMq +4M9wkHHI90vAQzgY9rc1vlWtB0IVMBBZToL1A9VfqZWoEfNODOdzdHbg0k88mHg9iwThiCs uI1jy4wuDrclAQZElQL5aOcdi+35LODgyHhibw5gW0RjcmQb9d4ERW3s4bO6q/txbCBgwwVK VVqwI5uQeN/Uw8Ygt6DUhEc/+x/a3HjK8W+EzZyO1m/L4z6ppW4BJM1P65Iv8ujLTk05ebIC YO58xVvC3bOXDFxXtS83m/Bx894xwBTKAYmo8KdZMTovo5sIeHDoo3lOjnlv7I/+r2CoXaKp sxYMNHjEx+hzmfOh2ZLMsfW16HhFb4c+uaPwgt4wcn1JLy3DtGD04Iji9Bs/hSxxsJ8wOrAp NulY+qFUsMvHVWvMWEs8IjSJSdXK7KIRdDGT6slGN1fr+sDsXG9Jo7HeI2a8Dv3MguJw53+H CymffdwB0RUKuuslqOi8trC82NVBVjuiF2HCFCw5MH5CwtXfJc+nAUuNBJlfZn64UcAo1k5D 38VCMBVwZCZ4r5oq7Fd885SqnCEHX2gmeH/Pwd0fHKMyhUvHCsjJLfYEYSltGp9gynCV5H+6 g5Z2brLsRvP5s9rLtSqvqAhGSUl9jYku3KoOm8P4EM5eYQC0B1aPYs5kjL9EfWVuMdn4Ypiy pDsE/XE3cj52tc37yS3qsz7DcZb8Hys3d3RmQDdbccN89O2LkOdmSYqv+IR7iEKrQTAHf7vT hOR+QmZ3TFHmJAvFRYtmW0V+/9mJi5tibv+0GQrQuE+XRzDS36d5kILffMg36EPlTBpxYg9z i/aNtPe2vHwOU1tKDHbqGmGfGfe5kesH8Go/aRcRYoX53P3G1W0UU4XytiQPaBL/agFSQ+lG yn3kQcpURsZshaAvT5yvaXAeFvpFHUypfJls/1Jf98SAOH4NgpoxYVjUnT4weiRKgpGXxQXB Al1NJRuItLGkS6US4/zYx/anoCKEDt8r08bjOotP5QYfseE+P8bYRs8G3n3dFmzzFlLZIhmO f+LlU0kqhIMRRZ2N1Q4W1zb70ePEVwlwXMA9hvrAIoGfyOVGqd9/51OCQdOWOAErav4c/jaM CPcqAAtEOvI3zhqwmkAL8CvH2WlMOr4+eRp7pId8W1Tiefy7nUZ3BjU6zR0BUB80fyJ2Sg2S Y5OYIABpI1oDQy9+n4/D4PROluXE0VYfD9yEUdy7pxL8gGxN9c2C9s7YZARTLSqTax2RBoz0 T0oRKdFfh1x8oQVoTffbSk72qJA7Q/OeeNOPr6Afw+YaVtMI0QR2zj8RrlxH3M7sDt0uydcW Q/ujRpukzbIDcEvWWuBT+lTo5fOOFxLK9bLSaf/hNrwxcL6EV/CtzdZvL3T6+E+rRmD5SFtw YdxP4wvml51rf0FdSJeTEzoO0rONW6RTPrRgYv5o08+osQsaoN+rwCxNLNTQQ8z7XwKNhIFe oouh4rKNzi0lXaxkKOvichaD+CcTLe85P/sEwFLJCR6XvGCNRbgVfetIRRyoM2/W61VQKC89 uQHcm5xIY9OL18v7ni/2RKvTFyo2bLZQSgwX9O6+OyUVMyC/YNUjAKsQUWF3V6U3Mpkw3DNc LrC1DENyi116VkOFnIy5dQjDi14HQXzMRyfh/0YuSEyzwV6qYimUPUzWFq+H5D5DrCrnOQgn 5euTTgnPctafGo0Z43+wiVXicaOV6OJfNgRuezQobAKhnQUT239JDyYHsDdupgYHeNKEuVv0 WE+lPoQTl9V3tdHaBujL3DrmO5RMi3qDjItIi65lv2WyuCp/LngS9Gzc00wWGS9dO4eVT1HK kFwy2m9oNttj+cUtXGF1+cE7hsVAi69PjnnaYMyIZLYYjJRSSlEp1MSvKQkVSTxaT9wrH4QF RHSNiX0vB7WSBom5v26WR+8jwACNMaPJKBVWabZFLKtN/5LWXRksZMYubfO/Kpj6OX1XdCFM 2bdVo2w6g46FOjjPgC9PLka5gzIW76ti183ELFpACx+abkCGREJ6toU8N7/LtCg1KG3JbaMN icni1IcdsoELE3rU2mZJilDA2REpDsWOGAz+00bWgPwFkxKDEZXLBu/bzc7uZ0AK3gHqMYo7 +nppy90jtR0K4kWo9D8WnvOOb/GTHxvM/J1gORUKH8BTlqc1BcH3unGnDf1MPieKRMT7YOWO yjYNfRwZrP4OLBfZDYws/8sxYqReaE2l5mRmoqYTytWx2D8bD49Y9GvL9+6gjrLyGDGmp+th m2v09JATvLbKO1gszkMjgrRLYl/WBaKck+fSobhOuHaG9lentzTN8i9fTiREY4VcLGu8sGz9 X6LpCp0gH1cjpmhao/bATcYmGzAKtMrcMypXajdg+wHlc/o04LBwWIHqP9it4l/DeaQfUwNu j/acPSQvf6dDX4DnsTOJK1J+8Cw42FSi29qUTu9d6nUC+n+Kg1fajwh31upnsX5EwsNWtnhd 6dS/71/ohuU37Mz5DuckX9C05sAzqzF8yKM0G7z/tR6mX3IRXxXUAKY3HF8HJVKw0uw+vm6/ Fr7y28Oh4SzEuWHa3WRUQeCm4o8oBBKXP+akH77lYqvSNnLUacFmKvdie1WFl196Gfu80kix PjtwsvAqzSAi4fj59Bk6uJXH9mvUUVkNTC6qxGkil6RHp7eefbhgM9gLfQBSbHDOYNAMsMtC r25zGK5N13NUoRmzciZTtvsk6UkFKajKbxzmH7EwvZ61GVT4k+aOVmOHLWK2kZpasqWvcWbX lN4zcfSCzL0qEGKYwmrhpSxK2AX739MS9P0bYKwAN0IImho9x2+8CfO0qleVnU78NEE620Yp LtmcyOxENtLxFAnfQCeDMy2o2YX5GdmnmOPTa/oa5s4Wbh58RzAu4irhbXNwe4sWR99zJmSb +Rm9dTPHMgvYsZRBByoWvo/nyAfBwT1uS3GHbYuxigfFioeJTSAJMnvqSCWfj1y5qIF08sBd VJbXLTDIRvKxq97ocsavKiV9mIV9Hd6Gs1VE3jt9UY7e06h1OculnKje0AFVYlL1g5f7MFdQ /yDXuVXbzBt/im4J0UYMjpIWVL5JeNP2MDzTcdm/xDvI1LsYbcw7hoPthLWJ3N4E/8q/CLDI phq3uC6h3CqSTnMsXTnQXmNK8GBnjJ6Gf2gybd8V0+CcQF322MmlM+vpbmWa8QBWn2FiPnol OlH/peLMCGsMpU8Cw264Au5192egjR5Nebc01GxYdorl6G7JV+siuFZQylMCxi9HgMQIG4PB FXVItDtp2Wi7NzRFVJzkCS+wEBPEC0fGTSyXsa5rK+QfEj6u5tL5C1PPK8Yp/z0UdM0dJ/hf 107ESL2UWMXGE1N8n7LTlZrzvCTVejZiucaZSTMQdleHts0VE/rY3aqUnKISmumywBu2uYGD aauJSMFRRqSFvT0QcGT+0AAP29IWpUyMEhuL+0DC3mJfgAUW78lc7K22naA4eFidi5RXV94e QM+zaVBx8m1mSEuNkBwvAbaexJ/AFQavF4QDqYEljm5MfUMPCCUBs6aHRmBGJ+BOKGqfz+zn qmIsKcLvtkPc7bf4N5lN08RqhzK/pNn/u0oYpE3ejOJOGMJ8uubhtpRPiskOJ/81xskGnK3C tTfY2E5fXH1Ktx7EQRnRcohFnkUbQHEPIQPO6dprHRahYwzvjJ6yq11sLynJMXD0870pMQNt xyfYXVyssBgHzqv6xsUVUoCYXXh+JtcWiYgK/yFg5317OvSxB9N4Eg9tKdLDKqc4qZsW+kQ/ VnpvZhTXUd0+TVyK2qGY8wfokZyS1m4Rv0jpFUY/t9XXaBHLLRyDdsdv+sNdvOT7xexsQRlx N2J0AfRLefWN0bRRnX0UwWfjuU778gyVMNMRnfe6slTJyfn09syI960dXIQ01i3aXnGozAB3 kHSOFhuh1qqdCsyjr/teuhuMNwmFgjO9ce0sr+hrQ9SuD/3md4e5gLmo4eEl2A7aHCyVgFst 8hiQcXF7VAGoAlPns4wVvDvmLnV/yPV4v//9TEUgPuEVg4j/cFbt2MNGhCK6upROBtTjtcoE uGsBRCBzdBJ18nmpX+h0n/aTPFKsMrLYnH2/G3fNlpfi64YZFuQUInZwBLQN/DLfznFtQ/og KKWn6ya+yQiohOho5jmcb/7ZVZNYLNexQpVeLaq+dMzUnNkiFs9hU9l8UhaxtY6zu0/5G/zu 1y02rsKSmFCFUsLOcyQn09kx8gjobpOxnKpKM+tJnJx5nObkA7jPrzFhh/fcJWTddOfi9aIH nSgqdXDKwiym8NPuDbNRmfituFtmd/RDP/AkIx9AiIVW88ikw9Kz6XWaxtRo4+ecn+cj37T8 KgjClK4owZgyoQhrhUOJNgZkuzbjAS4ViZE7UBHuruc8ll+6UvoIx07ycuZb+67XxFijXvV4 LwrG+9RMAREP2cE3zek9wbic0JqnyvPU5iXSUvyctbxhKEckNneRzxnZJueUzvxCwTvNFoRj tUO/zBUlnsXvm8udL0KuY9NivSBGp3oqIpDJA2+p3HSp00Vty2QwWks8cS/Zko24owgx3QcA lKficU9jv0QKvwxbZeZARIa/wbNazcg7eDXlkUxvTDEOE1yCRJa29gOru14uFI1hlRNM9C+U 4fMRBxHvQt0znJZ21PBPmHaYnoxfAWL3s3CKXzFSjZJaNUCrc43PCUYgnuyMXSyL4Eqc9QSj ogOdOcyOI0UgX6ymKMtbzpThhzVBZWDY3ERvQytdhIWqZjcUaeOOmrktF69xet+8P0APpnca RtK6jmFt4afbo/79pZ+eXMkYM7DnNbtv+lB3Cwi3yH479/cCC2D4AiWxEH2ZYlIDruldsv4g TzIJ75WkfOvJNFesS+BPmyhCmB1Rq8tkgPHQYL9ZuhQOq8fHiQynOEhrZz0Eu1HfcwjL9cwS sPSkOgK/wtw25xtC4TU72VdzlBYx7OBPo8yuLSXXaW/p78magzzeS+vOmmBvDgN8/A2Li5WU 4LSmAAGOeeei8mtXESqu3H6szGVTRgPUGS8gSUD7bwCjuvnrMXRseCFJbdh1RWw3cTFAq69r d2dDu+GmAxnCi+fwc59Ox53T3tn/gt7jhVXink8K+pZ02Pwp9n2kiOhAGE+5/FUlevqWf0kW PS7Z54eIyM2XtAChioFf1nmkDWi6FfX/C87pBxa/96Cie43cqYo6ymzWJqL6VZcbgw07XW7W LxOG46YeI+n+aK1+wIYdUWu4Kz0aJ6y1AafNY2ciDgbwpKyDxgCzsmGd3xVCQsDmhXb89yV0 mSnqa5ZmKKeA9ifdYC64rApZ/RLDq9NfF7m9qG0Y2lFsnS2WAwyH4EcsWgbqRjC8ck7Q5+Wj COxf7eww6J/AkVu3zbGGa3aOlQcprbRNvjFo1Pb3M5659t/sx00ap8X8uPEMPEi3KI1g6UGs kpzckR8id3hOtMJe5wfQDZNefwtDgRHJUrWqNYlcvzzZGhv2NMTFVFb/Ue2FdCyG92o0AgmN Vf3ZNcaoR/3CTp8TBNfo4chrnhYcO6R8HN2x34ikssRxg2JpqxLvYTmwNLmr8ZQeQpORsuN7 8ZMZKOwo1Qqi35nHJ1zBdxArpSCnUswIyMsqxv5iOpc3v7af11ghZ5KrvYVoRdZTgVSU9X/4 lBu/mevf6ZKVz0PH9LGV2IxzFU91aQGVbIzaPxA/QjxTsC2uMof2eDpHMuwt0wudn04oaL+q iXWYIk9AaFPG0vQt1FdahrE12Yczn0esm0u6wKhW8f+PXF/rO6PfP2Rn3xJTe38J0cxtazTC ZkXmb48gkcMkAaZnfkLkw0WccDKEiPGTGSjsKNUKqPU1NH+Py3sdKHgRYI7ygihnbQ0RmG/v 3q2xV9Qxf8jQHWsggeJNRkILXZQm3k5Hg/06ESMyYUqlkqi6rS6UMQDclrl5CfHLIz4p39zC qd/al8cDsoPI1tTNUI6fivYbgM8Y5brr6Ps4PBPSwehNR1CDVF3QfrmDID76OQYagu+Lq5nc E7pobOU5AwXAQKe4wt2IxCPGtNUzglfpoUIwZvxudZsKVvA7PLw8iTKSq0+oHmGDgvWymVdn /luUTj52Zi9qC128ZLjvmL8Xjy0ww37k2Jn9vaUFGKyJKhoHSUoctSxofgF5BQpHDyWJU1Un Uv6sRxqY1liE1nJFYLGpsp0fCWLqyZb1Iw++Y1AZ1FDwy232/0qkY03Iu+kjuGCz4KS7YzJp 86UkXjcTj2EatHoFmahiLYXT+oZavD6kkRjOz0rGcanFX2TIglN7aLcjAbBkP7Yn2WJ25ahH igOcw3I3lhQHGSo65Tzn9LuxA7+Zi4NmULr+8XGrTBIpZRPX6uK/fN/5jGdMauO4ARdMOo0R eA93eBsYA1FXPTWa7E3nZoEhTBECF0j8ybU/k//rV4CDmUB39OBbN2prtSRGZEb1I0Yu6aKO /TjnA7sJLMgBXTl4YLI1nmJLF24g6Mg8UueiHGfpuQs6nPwVCb8alQ5mfdP21cgMpPZIveWl YMigqwvETedBekM/e5N1Q//ca/F5F3MlobuU8BwO/778pqMOe89g0cd+KULVcBR3UVfsSOHW qGLoAVu6y3y9yQnVM5qdYMHQKIcMqm9NjcmeIuOpWU4GU87lBGCQ1Bt4tW9vjdMjUo+Jgsde 7WmlYRC8W6CDA2I3LwWDkuzOKlLS6eXnh5kZWw3IBdj8ofrUEgdzw0MWXjEat4x7/Pq3YiPL ZXE/qfi1V6ViADcFryAgX9f0wiXV5ZCjUMMZHnotEEa4yv1GVu90WVCyQafUJX6QVBsTeTHX MwgGVn0CrikeEvZJffN5kXvnPp8GRArS1zRIHTa6bNtNnxxIQYJcr6Ksv5HY39Oc92MR9wK0 3HMAgoy+vSNQMDN6RJGPeO14eHhnuFHODFzKfhDRAbqjB7xoHOoAjrUfa/JQqyBQNfWYtr9B uUxNnikYiHzcW28mJqt6FEFhHNqvZ5Pa3zy9uBql97TEY1cEOOz2JVUp8oh9OKqiMgBV+O7I Gba2RQ3j8XXA5lJGxjyJJC5uURXtxuacVMu2ZhRHykjGngeJAQC8flkK2PM6g9Ua9fjNlt2/ hD1j5qSUbo16r9BC5mzd6rHRY0RgR63eU2fNZVJt1dZGnWNvdDAxHAQx1pcGC/w0fEqK4BF2 ej0dKGYSoPoMnj7sqV3Yvb5ZKhg6ekiHgOeczUmIuyrOa1lnaV4UEpXcMC3FbwqhuyOzT3ok Q9Qb1x+OjCPH+HmJsEybe/s11cMY54TzsEPI5m34MFmjbAy/sIZrH8Il/7+sjpfFaust1VE+ /NesOTZCYt0ffUI/qpaV0mwnFrJGUOjPprv8aQhOqCmjSsOOsqvhlQI6B1bDHn4M+TPPexTY 6pufNmh928kQKS/AOU8e7ALClIsfcOsdMl2kxl+7prsUaUg+g/LoFEGaEiJ1yu+hsdumovxX on/9KvKQKMgAZKLHF9cdCUjsvUH094LXDcQzJ9rdItyUyg8Zu4ApqX+vvjQsRswApj479HjT vR/N4rxdxXXuytLT0ydGCUAZw5o4d0Xqwglte7q2DBE83pWjNyr2hT5XHUcHYUJcTPKWsDHj naI7zk4bb4yDntXZt78D6uNmENpyXDr5DYBiUIN5DCSab2vWXm5JrSvBYqBHIxCETdRwrr4j IPEyclYUU6lS39kHO7hkXAVJ461KMnIa5t5bEnyWwKaOrNfJKIK/+o+3LxKdixErZr5B6VQw g25JrXW1O31a7HSDKEFynE4suLYTdSEgJ0RL1KrGoYMOhg5JwX/y9PpdYpDcH7zR4+NyujAc CJoJhW9ApTLr3Bp6LI8yj1T343XRdpZrNUmJMDJDC0WMR66HA5Sf18E/94oW6wU6nuOOKbVq za7JtqSi2FhA6J0sEtRd3KMpeLIwtWJkn9yMdtnVYCOIGQ2weFj1i186SdyGwue7G+uOPdTM +qQsFuTwYVmPH7IurOvBPSe+icZQUg9RRvbkpxU4XVEIdxfQetqsdukOGfkUaEInlpUxk4qa HpRgIrW9b5C46arnLWjEGtvWC4VAQ8xV9EAhZHhpPgbYsXIpUc+MQyxmrlwGFiJsR9xjwwUc L9tTvN+CBf3xomdP3q+1FweNae99W+ab1YHVFClE0zVZlU73Hrw1yK5QmSN2Ho3EGsKl0kYN d5TP4n2Ri3GQ3JXjEUL09OcyJU3XlZ6Z6mgq35EEIISrMctM3l+2iij5/Aw2hj/FTcwljz7L 4UqV7k9rOyQTi5jmxrw/XT68srWw4CyASfdcYYZ9q2KyW3EOcdt++qPiNhL2rj7Ki8uDaLPr WWvEtqYlppWi+ZOgI8HehcR4QsSS3uf/jDZENX7UOR/R2cHsYCrIUHtdjjXeeWLpL6pgjpfy gTg/Ax0vTCbBGVRzBWItPV/Agbws9Zw+T6mH7nCed5MZ8Mo7VqFmvDWEYB6eON9D46wNcJK9 fuSua/b3c3euFKl0xyBJlej/L1P7b+Db6JHPqygJ0L6FqkmHf5q8rG1GuIcQoXn48ULWwfze bk3REOALc8jrZ7D03NFVw5XitXtAJL+N4g9E1gFK3jkDr6gpj70IdOeinnR5WV2OXpsJ/hXm tMuwytCckHkQPDbfLBzsY6jxqy4aXDb8R3YMFjj/DDJ1yWJMUkA3S07N21/rObVn/3ag1iTw 3oygr6Is4dGONsuWlkDLCAb4ocgIdUg2mnCgu5LuhBzJUMAb2ngZZ4yikTj/rkAG5gBX2rbb UYlu4CjnsmEPXxugd1jzMhHaPCEHfPl9kq683/zDwNRa5O+gCPM7IkCtQQIltNSF1mjZL4FY eV927Lucn67CKF6PlhPnfMhpl2hOscivnRc1xFH22rU8qooc67wMS/Kz3K49nZe0RbX8Vylc Ys3ovQb+Vxu7gnXqcFOUFsI+C5KAC5grxTHIkCfSr7Le4RHMrwi1OMivZAv+hNP6e9PGUVjI VSGAKs30kfChfF16YYWz4OGP+lP4s8fDqcUH6+BhQzcdC62PVg6/s4nTxo0VmQ8/HewBQFRX uLAz/n92t9WYVI3R/JfzOzuiAOso5TOSl4GI37uJwc8H1ivdup3nwgoFQwMA8LtPdKZI/843 IJepC7VQPgxTgzEuyhsDX5UBFn8jWzT/CvdgRsP5yR2gE3/T5SneMGJB7ensLA3GUTpWjXR/ yWFLz3AIH7qZNhkQxz5aLIt4Lpfsb4l4YChtC0LERYkAkahCLcHsD929u4ORcKl27frIVRPQ d2chdhLRpS4qcCeTf4BDAzA6xcb44BbLbvKjgapMH8KtDRnZCPyMhnOkcDxuVhdWbxnh8Jku 63IdcYcf18zUYQz68T4CJasAEj+XhqDvsPO9NW9Ll5ZX2tAOz2m9S21U7JoNmS/UXVorWwT3 SlRvzhJQkU8E0TNh7fXVkIu8jivrxIOtLZLoc6B0NSiq1VKsWt3biRs/2MLJCEnsRllGGTiK bp0Q2gposqTA3NXfusHG8mESGoLxMVcTSwFzSIxHRNEqA5fJlkkBDwr7xrJ+E5zm2Ncl7k82 4RDH/7nf0mb0xfgomj6QViswoCi90vtlPLvkfmw7wWwmjh1q1FSqRFE5CSKPNgwsU8FLQ0ic /0uY5Q9ZmQ2w2cJOUgztWPuYTtlDs1Lf72RO1lowDqpywaxTUX36mMGTO7/+RQgeKwuSH/W7 0yd/ge0SKogmHGWiXn9gS1w06ZNvvmEDMES9SdPyZubQ13KRrwx7lgw+zMEq17XBj+is/4k6 u+zytbgbF4rfHBy2manNBX83ps0b19XPShdgpznwscktTRGnj9XMpc50AG7etzvOKJKVGzJq FN5SFdBQOzdc912ZEFjdeEiY6naQ2yr51Sl+AsOoK7rnYKXU4LkxnHR70pFr6flC/DPln1pj rvuUHKm8w/yvfkDupVI7UN3f6rlWxwmX83fwoBcE7QGQcH7msRkMZgemakToLdvu/2CGpgvM 9AhuNxcYDUu2l4OKOtnBDTqUjvRk1fAhcB/V9eo9e6nTbuNrwSvkbjVo7avnVxqhvUKT+6gR DIdHTWkTmDAPkQTqH/3KQjQT0qBeFQdyVLgDIuqx4XHlJYjhFCEWxrmbDWpoY3fmg78ol8ql Lw/sMU6S7DGZp98zIrZD3tJvD431q0H/oMk4/xM0QDVCYmKUobF4aH+tM4t/ozKcrftmbu5s +ASZv3BvrRN2HYtExuvnDAnvc+BTK9EHUEcRhZmGoJ4oSJeGWvQYg/mNXQSRN3ySixlqEmyt ANFsO26CA/9LGKg4Jap0pYMuUcD2KsD2L9Zu4TFJqbCE+nctjEcv5MoNE1QYEP9BecW2+66c TtQccQFhFWOKPZuyXOutmdFWW4z148aEdgo67yrG4p0nItYGpfxi6tqxkBVHB61oqdR+5iyM ZlRVrJGAfD9OUyQH1G7hStSkqvr92VON02e6R2ZGcJsF/eaYhpRsb4UoblR8fxQid+ACssbl zk7uSxQTuIIh1/nZF01SGpgM3KYUPRqzm+P9PUapAs7lDJTUICc+PjEj9jTM4RH4Eedp4tV1 G+AyFsCwGO1cspJyd2+GmdV+cRvD+ZVFW9ynEKZ2w2oceu70SfG75xc7rGt3rV5FTAOur9zF ifpOLmMH5amW0h+C+nyKE7LrPr0F8JGdpY7KtPSSOkPvkiQ7R/wThAAWVZAlEtaAug/rH3vT iPFOqtjblP5q7mdBvbu1I2mQBmvjdCWowi/dLPPkRgm67jeCKXvAj4iANALD56d0W57AKI7w TpFXzP0NbPc9VrRIfcP4+N2EdEXGqTFJZfmjJD+JK6SJGRJJ8FdH9J1z0mpPVuVcARUGKbw+ AKVH1i/x4MYKzI142IYY8K6AOWSDLOMp5coX2jMBnzUscrkvrY28iSiNJGo3j6vStJ2n0yMe WdxvL3cdPPd2Qo7j3qDcr5E9+QgfzOaO5vjertvjbE5l4N+dyr8UDoI1ersYA8ItpPzIcJJC 2ZJn6t4ctWioDblw30uqPlnA0JY0YSJg6ngZenYRs8JJVHOMXe75tSyDVucO4AgKvqhKVv7+ pUDEyK3k2LsYHenYNJ2X1MNJ0/xeqAECXVjqeodCbmicR4boxIPL/QQ+QwhufhiF+cgu7LAR nf5Fa9X3H8Jjcl6sKSkCsdjB26oCaY7AMvaCXEvGm99HrhS0pU5cucoKNNah65ez8huG4ZsE ZINIUCZTSFS0LXoDNMcEPh1UP5qBV8KPohQ37Rm+IMmvONontr81y+W9NCy15bllFuBHly9C WufR8d2erw1Xk+oK/Q8ZzXa2SSWIfcJrq6gSYVxzX+b7BnSxJtFT4MAHWzQ34xmmVsBaf97b oHeXfHvL1Ya+ApjxdwIPavCNH7NFvYws5kFWtaSdRMLSEEaGCcW7lOhhSWbQqlgQSrWsdhlj cGZaT9tRmv/0Vm3ZLE7OzdW1yUDwvMNqbphyFX1r9plZ9+N8KyHuiKAfsExB/UZBzvNncIyE g/V37qSVxHr48LpO+2v6wRIa3Ipd2Jm68/f6UbJXttEh6ELoX4aMVtw2b3b4Gp/WV0IRpsO1 ecC2D8AQKaK9wHlUv1ljnn/2SCLcO2UJZgIebCnyXBzIHXVGJYSh/zmm7h/0kFmyhFh7QfIe sgX6/R63TiiLIKT1w5DZaRzD5jr86Nal+f5K3bldVL6oFsrHB+FFKbEDVYQqS2ne4VIVUz6o NNKqjEjlFsXHqvXtP7aKoAdm5TxXE/LgQooj0IkMm20+tlR/McRas1as7XOz0JOwPEHVXL9u S31O6NAiPAX7Xzk/tD5fhiNJTUblRJkaBStUquif6MiEongDqYDAHshA0RKpM9JwbN/g29KY 83gugVTVRUL2FracyWiyx5dLTp89/IheitsOmKnQWcjEJcF7oJ8w4SrsYPl4Q63vUedRBN/d b0sz4LnM/IM5ize5t1MFUZWFX213dgg9TGu6ozEOm02rF2aBkXFbpW7DTQlroMlLTxARTMpv fyxNFtjwB+EI/E5Es8NivNDQICUWCPdvE8jahxpEVTNF6vwDoOaeb3X+TrqhUmgS5+WOSeN1 YYPnUW+6CZcBgutCvTyW66cSRgGgVwAoz16bw3iMfAy/q9IpTQet/IHefiwiC6RV/PrYauj9 WMKzEnc44pPfzlf6bjYMx0m6TGu0bB+ZMALE/qWeLc6LglsnUPwpLSTRTuilzg1XLqhagmmN hSF02csZBUAa2M9fMwQhLmcNzopcWrgrQGUoMse3EpxJ0P2XXojhtl84T2ep74MeY1l4TDli ArlzWtWXJNo+PgAn+GikgcdlSEoxIZvUyEYZm9J1RBZ/e64aKfmkfHP/MK8zqKnPiXf76ZKf Qo65E+eLzjfv6wnFZAK2ud9+I0ACSp7Xi+8sgA0vWYOeS2zI4uJE2XY3oS+yp3kGJ3+/TDxj VscIHA0Zl0Y2fCtMy204hZ6wCUfLb5KJgepn9arVtPUmqM3+wJUyFXepPGJSB8vy03Y1791j tg3CQlJz5KLEmouxGhw60GKjO8D35yr8GznwxJbXoedlGaJqqeg8tFNQrkQyZJ7dqta8LTZa MacQy5JUVhBB9eHH59wJ8C50U1VWOjCabQHIh9larI+PlfKLhwzJ+CfllYOqLsmnHZX7ZuDA LV5C2I6RwpTO67p+fnD5EU2rKdZN/OQG8hW6jMTFZju5pLjaS4Am0UMtiG9LtGV681I2ETId Sku8i14efciQxWUh9v2dqjgDb8GsWjgN2HXEp503/q7WS9LkzvmtN76rEmBKZMBqUzEuRhCC 0cUd0aKc4H9Y89IUhCy8Q6U8Gg6WmY0+3PEzBCutoixhyDKsYrBmUqGsKFRGKJpUyYbZ3nxm gWWFPCyiV7zGaVSPZuCsNYaOBrYSJ0M+T6GhPwWjXFP0mNyvy4HsCjUjrsMxi1xrs15kchhK OBSeW4Ya5y2gO+cYbrTuirDnCQWgyeoBVcY4sToR5hafAKf5GbSRfx5jpqVSoYbGN0mkrB7w NbySevEDRo5qERuJxz6iesmg/R0QdjJhJaw2aIvf6mbCB3OWGY+ZJY02/xiyT5VXcMjffZi8 k+0UyuF1gvKPO/X5U/dwa8wC4P3NkZU2MrhWDJ6P5bO8oy9G9mEUj3W+2CX09Cx8fZ+4N8DW bxog9g3EI8cWdS6ripwXGCwE8H8J8XK/O8Ce2ZIuVf6uKIbEZwUGb3Lu1qKwurclAKoihIQJ e+Px+rtt7LaWLxV4XIuTo8LzTLqIcLL1hjuGsZ4oXHVH/LDIXY8MpsqLi8foX9AWGsw5w5Fj Mv9hxoLf4x4CPsPlLXjUZFgm3sxvyRygO3sEL4G1jVQCxFObnjd3pFx3nAePxpRIRFebgESS AeiH7xSTOyqNzerR+IDTXY+/QIslh9BcZVmDIVu23Ye4chJVB6ZJsTgoxl3dpvm5V0hj7lZ5 JvRBzePsIr7CB3VIlPHh/WZOiuJeGFaNU9/eAI/hyYUhAn620cfSMP54aVASyX6jepcpynl4 aPcQ2XPmQcAeIeHBO56VhKw9xf1RraPbF5rlni+v06SSFLn4YwjgM7BmRHD7+bUUwxc7mHlP C9yA+uxIBCrdcnIWMpWinyZoyftGjb9oiNX/0C2nPU1Sx7pD1plToZH5byPjOfdNQwAxmSwt 9LaCcfwkMMvlU2SETXubehekiEvYTvI+rcSjHK4OvOKWC6ki0JbYgihHx9Olq9mBtkSdx4iW jXEV43zljuL0g8W0gngPP1mMf0wOq654WGUZk8J4THTpeNQtB8yTm40MPmPSyiULvg9uJyoe SEbswLBAADbIk2B9+OXbaJL6ORkOpt3y2SiCcwKergALXPJuzQW5LN/P9SFhJzB0zG1t1zMP ac+M6nEoVMUzrzsj7rHVfkKyvUeZAVpP7V+GSVh0T5nTnjPkQL+zynMrnh+BjM3IlwVRHxYD 7MDjAgkrXZhS5J+tnwrs7xnPblCUQu/xHhX0zSPGnP5eueFuKuKVvre6Km5yTGeIQdrrF74x qQh/HqJYxsFQktwmrwQD3LTc59ralKvcRZrUm9Rkr2E/zqsCQ8iMfYerpDkhYo34ydrFFxRs ZzHBjII3+u3qMCBu5jg1dIbqmj+HiVTNVOPKYbbH1Y3ac1jY0qgoTkr89nVhq2KxQSFTWKXj dcHAn27QalMa8jIgLb4yEYFJuapdQYM/NcVmqVCnUtyaNNTemdhBQkZDpcy3ry8157T2O7bs S4ip49E4Azkeuw5ExU4Mv08mqNyjQZxjRhzWU4HVs/WRq47DhlJcVMX5DPMq1T4TQl1WICNG Ums+vDKUsDWT7v1S/O2P54rI4ZChmS7mOXxbrqCxPn1Dio59iIJtBL34cmvJUJeLphCVIny5 8pECPJXM9edatmB9rMBMWzPNzyzWCokGu1WSdDXns51a7jZ//jXcRXBHvNqKQe5OXJdmlgsR f3f64SyAHqDlBqNFSjczS/hrRJMw7ukDhzhzLUs1nnHuBxU1vfs0LZPMNknoyZxWojIuN+Se iclvpaLAOPr3hYT6dQwuGzbep5L5mkxyIJilAFj2bTNPwabFZt+Npl+LjJXUOQolr60zWyYQ vNsy2x+JD606R7szb7WOiVy957G5BMtGV974N/MhjXctvPQCU2U3ABU/xdkSo4iH7VMyerPE q+AS7HxUfEnkpDeLisUtme1pPEjMtH57qKvcQHPsXLdYXuCvJQ0OVh1+1vbZh0sIaQlzj9gz H/dm1NiNLDGgyjUYCkIs+8JHdDMmZhI7hTA3SGLwQSnVrRJ0daiVmh/B9rDe75UTT1MkcwmT KPgcutdSPr0HfbO/jMoX11o4GC9AlfhacFakPOaVpxiJPUx8GHISrAWns4nkD4Pb2eKGJAQB I0sxSuNpbwo0BWeHe/H3Ws8eXZIgXi4qpLnRoJohfZNCudlOzAusYxMPFkPcKe50W62N42vL aqqF09fB7uBqpMrBPIZeF8DxX3mhTkmnvWdOKQisocF+9p7s6VBlv7I4h1ugIr2zwf+4l6f3 tQx9TZ8Y/gX5yC/UrvVLd2AJiVqq9qqcwZ9VBkx2t8rdGFIXMRwsNCRVxRJ5FscwkhRJ6wQ8 HUHccoQrWqJA4PD78rWQXRUYpB0J5QSqdQDN/9GVtckrrIhloIv3aTCCdPNEZsBCK5WbaX6p EGkOWyXSb10yDon9pkc3DTRxx/e28yculR+uuv5Kxwr/l/1sIM4Hu65rTps2P+qgLkE5bm00 DAdro/q5VsxpEKX1HiL3VuoPEv1k9qd3FRCPUUI7GuvtLxqM00KRHLW2dLAPHWwSrAV8P6qT EkP6C7zDj749M6ll7Ja52W4M7C67MW0dhHRZ4X9R2gfo9Q9aqpR9q9PRYsuWfJXyHmsvn1Fc aobA2Cy/vm9r7s0U7J4X6En2aGxYCoEVCrU7r6tHnbNKEUPE4QyglFvKb+QTnpZapUhDlrfS bRUMf54pZZyjfOHnlKLYsn0AWp97X/Sard0hJQlx90TgCrKG4avBBUInwqJVy/akMVSmZiuI DmwMlrwNupUKwcZzhLjojbp0UHX7drqyY8apP7w/OOAOZ7+FYMArL9Yu2MrgXWL7g06PVp7k JVcuhk2LUsX+s4BFlNRlfmQvY7N6jkAS1j7hk8Q9RczVVGY3Nv9TRRkprI1VKwvfVmHNOMDo 1ypYGhnZypM2LBP6hg+XjvXoqpohg0oJ4ZH+1fZbQF4YAFa6ORRSHJwpcCwGFteYCgBXOR+t grsH+Kb40oSC6PYUSgqzuOuU7hPrw9ZPDxknLFPTQrJ48kx33wOI0VUeJ53ztPHzaQ76GljN 7UHEujfV00NpIOGvFWX2f1mnDlg1PnWOLZalHc2r9Yi4FnI88YXBh++HCr9GNOOOfvyuMDuM zoiAVmX16fykxp+zFKTgtnWeSYRpxFfDEdecjn5JkKGRy5rux8K2VGB13WTQiK5MV2eRKP6e 6QtmT0KyaEJplxIwxV55T1aMmjH9jyCGeiMBRElQ+9qXhfh3VCtqMzacUmtR+lyYIRNrryG6 jd+zTMyR64Ym7jtlZQA+FALfI1uN6Kwvmj5Hzekdp9vCIcQxe9onHwoUwKLKB8XKVCE6qmjs 6koay/Nl92VvbeJ7yBFotEvWPunmzfK3PMfv5Imx5MO5ESLoD6DiXsK+W1wD1jx5JqqAA1jj LNsWdsDf51aZp5DQNrReuVqLG249kkxNkrcMC0YLI7Hxk9xFaL1cXyGS6+AgvGzcSq+jLFRc kW6F6WNsbYsOwolpH9eCO1E+Njrr2OxtcmkjR3h+Wlus9pXMBfyEctvtjHM1oGel1h1ybhcI WV9btMiq0UP67sQqrk92znaeHlK9dMZLEOnhiMU4LsfvNDioyUTz2Aeu803UxyJ8hnUn8P0Y mdz+I3kmORhU5tCQ2XJL6Sj0MPYzlE/XikYBozG+19zn5Zjo+OzoznFQZTz3po2kH77Ik2jA RVRgA6IvU2DPx1jebqifSx9jXbk+k1i3OOnDnShEOFSNTTxdHNrd5+22M5FtJjBbfz78BUpb zeYuLJ5YdD6z2kFT1RMyjmNqOaNMMcAJpe6uMknAUg84yCPwgjCG6x+O+R2h56bVVKFkTp3J z8N1L2DxuWCZz0xcIaDg+E6iImIy3uiXfogoTa4SIaoxXtgNj256O3yJ9ITfJOxS3bc5uVb0 6U+IEA3Tu6lBVSEi+2Jo/QHiyjODTp+QhsP+PoBN8RZqJ0ek8DfPE1tZb3Q+dUl0bUVwfaE6 HU3DQ7ZkXYJmdNJ+uotEpx22eLgWWve9QBGZRp+x6a7vJ1uU729WhN6eK2Z3+S8AkGGooXXI di0JV+yKEUTJb/ydtWhpAIfO0atB9cr9Vb7TbSWQ8/OdNSHhdNjLe+glMu8iRlv1nEVl7NSl NmKJ0TD5PNYIazbHh6HI3NKbThrSTxUQhfAK6TWAEtDGaVqi2lg6q/N3MfXHfZVtDSdz+Akj Hz2kcAPo5At0GSKNgK0Ol2eHanJv29+8eUz9e5uyK9HfomGsSOqm+F34jInCXptL2STOHm9E PZOUHciSbZMYvbxoWo6OoLzuCic5isxs35vYlwEohcEGc/IchMRecJHFc+ZDkSzXLngstomf cYXz4GjsnHpFR4qLAR8tAQ70mYoZsBx5R1sLlemKPaGImjcDe7OIKDrB66gs9Kn5AK2u9pav mxE5szjOwqznxpvuNhkN9+UUz3RsMqN/z3mCPRBcXH2p7hHQtl8LlhKplUd/6I0s+YWL9eIG imY+NBqZ/ZPRG0JxYN1Khfq9aQVDj/rXwf9Ks9JcF0fsASqpOwdpwbxXsMOKcEnX9rQW411s raw88bcqu7Co3Cd05tTLAnzAEVS/nx9YekVIXRmzNkBVseKDKvv7p+8bLBd7SzAT3sSZ/qzS vZ9DEZCCUcjviPfYGuaHJCGwhqzFlK1SkZ9io479Uv4cw1tVzHxdxfhaHhOBPD4BXA5rjwxi lW8r3Y0jVdhjdvhYyCl31jM/KmZWAraTrKAAzZT1pSrDlBBnrMMWrBv9m+6n7MHfwDo5gkTL 3P++vbGXETELG4/Cbg44JTBzwbS08qVENg4gInASwMTLO0VyTrgpxUsm2L1N66YGlCp8DDIS denC7MLxwYpxzyRyTcedkcpKHrbo80twmbl3zebAiWw2O1TTBRDwKYCE+c6G5sZuhNgG3MwG PbJstJMpG6bj7k4zzcuC3CJ8M/x7js/2q3yHHZP4IN0B6oSvka6kumzK6MK5of9o9mhNIhoH jPtNx/n5m1NAwOw7YG8CLDJTDxUqTew76ylVntHtsZYkZJNohdlTZFpCWRHQEaP6MhGOtQzt yN4pwo18WyIBWRHDD5HyX4NZjTwhZb9jmODZhzROwzyq+JuRgloIRbT/SuZ8Zzw4VgU+ZGqV X+IgvcL78bHQ1Tm9CpfWLWL2/hb3TvYx3iBPRaq4l/vulhC35iDA3N/eihvtrR+eLpnOHfQz Rm41+nY1giiX517HXrvSAqb3FTZvCz5N75F3ClJgyDLFYelO7OzDF+sxrMQkesbrga/qpIam FfjB8u3cxiUJ4jqmcANfAhHKRE850KC4E6jmCJ1zWyVFmywY7f3wLNH423DKsnH73Oo7sQ3T N0z0EV5TLQclTJulEBiIQEprOd0MyXj0RwQqP1DtdAz0fI2m6iV79nyHR9FhC60aCgu5to04 aunDe6SkWiJ7NEC0S2QQJ4TS3s3DiRXw2Dv/oBCU63KUjGyJD4EeLUBTZgXOW7fj6yfOWYcJ ck+lbNwCZmWSdq2fOwMXVQDZFPDBdKRPJQyaQIyHMYd1PgvFMD3/ybs9nTqrFj6dMQ1ZEcjM YdPwHaqo10zH34noD9IWyjRc05FJ73xCxo2bPh5bGmt6H1cMb8ofni+Vu5aC0dtZYTltIBhK tfe2fSgHr0j6JawniiUPq2UmN61hKYLZOcVd2/kO/kimAgGVwJYtvOzpgRA2SRApGmD7+YDK BWvbE4ilqGafKySRnB7TrOEghMQP39tQOInehICtJVUZoePs4GlzLkQAzRBetHJFQM4o3eiy aBR9NMR51DyM1n4fTs+QHumBWPeLfTPginOA3udZj0ADAX0brY/HteAfFNSQ0KoyuDAcuga3 lw51vb5vzDSVcEaa0aAiQ2zJ00kgWCFDuyLA7kYzHrOk47aoP7tyA7bC7N6O8MXp9pXK0M37 xTmdbt45om7GJEBP+6DAHUSxRAL8mbqgNr+Y3UA7IjaVxJ1NP7DTuU1HaQVH3Ym60eZ3UaeQ UmsRDlrubdCVAnSixUuGnL9O6LddvrsMwGnEZoPZYczrUSFDucROCdCI8N76WbgVPiZ8pppv Lx5xNUGuzdbwIAJgD1ZGp66qiI0oCDCpmkMPEdgqyEp3Rrpprclb9KDQqRf+Fbl3CGeb9z7l GUKAz9EQSRqzoS7GanwZWLIREhbZaA4d1yeqLEYGcWuK+Sl2GcplHsr1UOyx2OnfkNCDorxH AnY4EC0GLDuu03VVhFAAV9XH5n8B1ipbgNKhXKcHdK4HM7mKAxKQaXFV7396po4+JYVFoUxm wIBtSvE2N63zHe+61N45zoTVsNBUxBNduvOc5Vyp71ijFuCgtmH4u7dj92V3SxsfOWCkDqiW 1D7mN1X+Psy28b6Mxh6sDnp5/hxW6xRciHpETEmefW+OnAdtSGgxztXoF2ZOjRV2zPTi4Kaz A6shENu2SQT5v5w9v0oKGTmb+sjuP2SxM+ZsSquTdXQ/9eiokNlBQH0Euw9Gi51+vbrp1lzA g89bazoRlwJ7tNFtS5SyW33M5B8FTfsFsi6DEjC+ModPfy2kO9T/UYZCxWHUDdEelbs04Pxx 8kkQiGxC0RQo+gX0ZVeF+hh1sJB/FoMuBPRegSYiFrv54rqtu4ftk8nl6tlTP+hVApyijXY8 o45UF8i22/BkN9oeLD/wo0QaHOCzQCCQQdnSYqhIL1S3MvREiiK2TF92MbnpHosnxxnrcMVp kB7WWXpzKmhaw6k/92osHYPHoKarF1OdCr+TvZDb65LQiH1DmMN0ZJaYcrheeBDnIkwjACVt P2hffBkzK9+kDa05xml0cyFN00nE2xY7zUcl0TcKWt/zDCjTGiNa4Gh6TPjSbuMUhH1B7PIE QvupKlBXZ5ieUZIHTaZw826I6i0unyXccjUCS794B9GUkgOjp2efsTpMC1ijPO1URsfGKoyn UbVv95N5eBFdQjxMiPH0tDeNsje5bWdXXZJDowHoICuNgET251NDbCx4k3iecAyp+DR3fsbO SXCI3hKXY6ee3a24KFYf9MBbQFzKWwKFBRKnM3YEcU1pOPk2p6g+qdlETvvaHNojuVslz/ia qVrzBghgx/lxzW7Bvkqmbohq8vXit/skLdz5nacOaHdThtJ/vJFl2DEzf8KI7Qx4AE82Y0MQ zUI/LwTvbT+znvCvAZJwonfJeKfaYJW+VK3IvlezMFwafpIrLdI04io4PhWuZveWiKy2vsnB DLA5qNX+PO6sun0isbZYMo0REKyvmgQiUqbuIDjkNGrnt68xvlVIL6zYXAEsLw8yfy0ioPcZ sH16n39KjX/ylmiDQRNqbda4wYAc3zqrkWUdZcD0LrDltMaxLv3S6TUutGUb/MQxMeqABv0x q81QPP6noFcwSZ9P/wIruIyKBHEnRJ3Ud+fPq6LXtBJEZjkbkGup38b882RDMi8m0JlsM1fJ bsvcmXd3prj/u+zQJLGXlx0Z1LNBOdh9j4y3IbXrOOAP79TMICnsq52RTm5PkTthOYcbvF6z JVkqsg328m74oCfdGRwXup7UZ5StdVCHNvHl5BGkhNtDGQnIQ/S1SEMlxd+h6kxK9H/Fu7Rq MoRcUqEP6s7TLE4RnJKLUQB4CkKS2k6rAWVT1kTrxmejt9JORWBtGMpLl9xOTySqBNcd0zn2 JwD3T/fB0lbZJ5aimKCJQqVkk2yYfdzmGZ2C7fwjOzS01/0avDktq+lwNW4QPrkGCRlnb3U7 4p6Wu08me887VrO9x2z8xlzs093JJU3UpAx6BDAstOIsbBqPhuv4vH1lvLRvNiRiGyo6IU02 3Ql8rZzZdkHGyEmqBvDuX2NnJmRyW+CH+NuZvwXkKzYa2Au/LG1xAEM0tFh9BmoeP9R8MeW4 W3uWQ9L3sV0d9p6BfnEbkkBUwiRzi69FcuK0yBds3/r33ZK9e0fpBw4zbdttC05MbwnUO1ZD JVaUHLOwtbxDnVxXr29zfVKTrwekx3tEmoip6DcCSRYkW3xLqAR+NyaRAWEPyrGTv3l714ym Xqi/RPFpTzL8pfRd37Xsy6nwdImeZaDMazLDPhQl08M0om0j81GGhLNL8brF5w6Q+P53URIF WRWHBJ2PnwZIgsb/enKPhP3qIYXdhA4zKSNAQqXHUwwuJ9Kb0VcDP3PWGB9sHXwxoKa9WSCD L5uHx/7rOE1a8/RJuJGxdcItrpwELw7J4O4auleMNMeo6Y98szA0jPV1mA1bJcdzzJRr/wLj MuWDMsZ4j7//fOjbqCIcf6H1tAr4y/KdEcix6YJG7JYKd8XGFvUiUE36SJyfs/h5ZmSR/aOd HRkQafgiCt5lpWccM6BDjfArJ9Q/Bq7O0yfYPPv40IJNfzonCPhXI6c0RGEtb3+ONA+qd5t4 kt1y2gJpSoyJa1i0wn62ra2n54o3oKjYtvWcKtWwHXRml+ys9k6wsPocUkVm8dSEkLOUaJAP 66xHTHkR8N132/aNznBj2t1kAFW74SdeMDNiP9oTybCcZ35e39VUTgycWpy/dEUSMkJs/Q7K aPmi+aq0I9KdPuKV8XgdRcoZrjBsKza6npW8XIK/3WgNx3wNTsgjMcKdzn/MW9+tgYiMaaRC UHVigCwnyQMwbpcqQwSaqc02g3UAIuf82+a1hACbhyhDCvC4VV13v20M/qoD3MIvog1IjrJE juitlTUuQWeIlkPx7LI0Pifg4adwnYi5yvWJK2YNViPwwSeqDDwiJwG7KZ3tO8h2lcpZhWQM 7W/YeWnEVtKeAJ/+GSPOYcjTu/JSL6i70Cl/m642d3w7QdMiEvcFGviS9pfUdVhTU14Dp56p 6hT86ZSjAPs9f7n6UTDS5yi1dguysOSqPnHLMlA15AIFWJPeQK/kNpsVXSdDNPhsHhpG/4lJ AMYFEbZfRjIyIG+Nw89h3IpUc2WTUCTJW3+wk5wfjQxCMcszq0krSqXoaZcJrONts6YQlc6v 5TAQlYHaVG0Re+sOqMPwIChhqMdAx/AgpdfEJzgpILP/chXgLJZDqoeH/iNPYq/4KZMHtsgt KuHNsx9K4EJ1honm/uzo88VSkhOt697VmGJjfcz5+rLf0TrXu27prEhyXMH4yt/qa1XqeU7s DSoHBkl5AqhcjwC2er1Zsd3Ki5dhwQYe0H8sXv43ajqgzAT71j9OilnVm0Eg8x7QOkPNmwAs MZuOgELpC6k9oFb3MKrHxa6iN+qd1g5EfOTz04kmaakxnLpOOW71RBxbhGJ7I1TsjBdagRBz KwkqtIYMm05hn0JEBD5qKfcqT+wn32WEnPkzThklCdWV4L/T5hXcTg4yQ3vjU1aC1U+7sKUC AR/MtQk8jhG3Eq6M9hjlHnwWdrBMp+ufm73wy7ii8Ki+OV+Sul1UaVxLrSOAtZL2G1PTGc4j O7pjDy17j0lILvoy44DHiTYgY+50qiTN1+vSgjz6hxefTVVyA337bz9Kvm9xcNdY+eA7h0PI z1r0KEoFo5cJE0O7/3qfXqOiU23ZRpAu4hVZ6nLpBOf+6ozd5+BesXA62zkSGxN0/OeoxdPq TKrp/17hoiCKnYS5Bj8uj4/oTuGKCFnOcY3hCCKMNMs5m8sLmGRUOj6VYaLYPIhW2S3w1Ib8 2ITbo0upGv+i63jiC5WNDvBnJJV/501q0rDNwSZqwlyBf5pN9y1MnwPvSDykGtYWqtGFDuS3 Pr4qklqMn78r3fEaSF09LdfxdXnEPZvaUqzQNEiFStF16+j8naGtX9NmT6eKzKN5JHLTKo/y RhD019PgdrIDyOnTiyB86UNeDRai1TKEfJFCztP3KV1symBg3cW+WaHCXQ4AlffNafTIXAfw 2rFyxB13nyWFxgF/0vQasLDyHcGDtIRqhEnHgzN/sNLamFE573Aw5F7CBZBdUQ3UcQvloEVu A0rq9WzA1ZRHpK/43PxIQ1w+b09wApCWZ+cXrgXzn3gQ1r9jgOmW/HL0nVjJgrFt4h2QgPif bMmZ4OBj4VvfA/tkxMEpA0KAuRHTJcuiXTa9We32RnBacI7Xkj+KWC98CXC4FJGCmSnyYBmx hDWw8h4WIpm/9Ccz6EDJmmKbJYpzfKKC/HlWSBup1pQAEctVWHP/xwyJL1j/mzCufDsYr5Sq jEu3AghC2Hgv74opYVJnSr9ONAvzVUFbBR18Nk6watGxDRcJrLkiRGa0T/ZjvUyM0gNVzw93 pCQy5ZaP+8/nbqcxYjyqoYLcTPqMxYKA8zhHw//E9O+b2Pb/qBpDj91hiX2BDfRfltBVJAZ5 htWCQ5lRLpAyX55Ndmdyjr+0HbAAnk94vrLo2YF/mSjEhcv0u4lE8bJpyTPpjyOxNc5fOfOR 9PI+3OVX9J4vvTxpvH4sNDyFiHCER+J6Y5ltXEKJtP2WEJfqXTR8AoTyTpNVKGToDpUHS/9d tIyCvg48baMkoPnsppaEetqdh5a9UCxfbtZLOsnV63rw+DG3nSBTpNv6Eqn4QNG6lfpCqIOU Aq2Wc8gC7xUl81OEQ24JvAOVnJ8nUknyXi3fz3jbeda44ucwykv+JYzF5bTjotZVWNutH/UO fHa3Q7YNG+kPDyJP3/a7Z1qejxvHlckvghiNyHAsK7dg6c3dkZuH6pOT0cKrycqAyrnPeLhT 30DYvgqW4eZCG1g8tGPBE8QX/m8YZAJuwYD1FfZraV2TKI5ry/iMfaW7YuYS8Qb6dg6mYJSH VC1sHPOUG6JnWOSgK8cq63YAscWdhjlioZgbMhVIZ3j3/ZfcLj07TXf33AVydetpP/dxQHz5 V0+UoCGady99ZVNGsc2w3B8hcR3tBOujI2L6tHvzh1bD07l8VbqrYK0mfjdRYLsl0o09guir XArOrIx52TVuvbEwTCWQqQchMj4lRKr3Uhrp8xyJaZEhtlKFWrSNd3IUHbR1xi8EfDTRQpHt MNhvveprOmJHQcd7imQrm7eRhmWqT+WXBTZnH08TzxcccPY6WJMgCu6hC6GrwxhwlIdOytHa jdULt21xExtUY+xe8IHXOozC60owub+u91I6/0S+LDzEeO11eSc7Ehtp849sAB7Rt+7Gp0gy agcnRimvH1H4fa6usNTcLaOYU73ZKMVU2QyQqZZkGZMwVNaAQox5VbDPsxivA4rxT7STguCZ eckBPK0lCQ/68LCACspUnbo6qd6jyzRtrl4975W8aKgtirkww/bCz0N1EF9fJ403a0lt1KxK cFph+3k09MQY7wPdyLcgfFrtXiO9MftttaZcBDW+GoywbVan5mvzriBrS8Tmzdc+LaVB7PyO 29HZUsEghMU9HtQavADo6mJcQ7A+QOU2adpirljnyTlXUh7v8LrBKMubhp8oPME8TK1nkJF/ d3SsIW5uH7TCZGH63PzCH71k4/oaIE5Z9AZkrkKnzaiJ8lVtrj9/fPMEeaFG+NeKacC2WFxj ZB9ULcZ7dbV4q44xdtXsuhvAptWXjgNaU53QmKIkT4bsIk3oaT71/47Pcw9sTRleNce+q6cI IsoELOx2WFpvQbEoAVm0F63kG7hY6Qq9dg02r6GLlwNsJXxHeI/PwzH+1IghSPmIhiZbJUAB XrbS/GDzsgd5UT8ng66B43hchGqP+GOJiR5YvYQCZY9P2bmxEUtbXGMVGoCGdQWwqB9WS+o+ ZZhTZlCGBzXwVgHUrvI8AkYzDNCpvAaddQ1rqaPYeTjB9CKU5b/OsXqTCTnrpIh3CfMjTNFz oCTITu64A6CtDWZrB/c580Y3VPLIPJ9stNKJ/JTKFCN7LNvdMBWjTT6JTw4NAaJIFdESd7W5 E0Gk9IYiNbYpMft6T3U4zbj0m0hN1fK+b2XFU1fAfYVbWeHb5e5i12z3krH2QnBL4eUinBKA 98wSc6ZuIWyf4vrNDr4LGsunsAySGGIySUyZh6h5MCejtkdwiFLsJBMxd8Bi5Qsbd9XPRUMU Y4px2sNzp1fEr9VhcxExGRuhGKHLkEIezpnluD+SO56pqwCFiDGcJ1b8wWX34nyYLNp2wUIF +Xu4tRctIimGd7wTHF7h1MKjKpvyI+y9ccAbXfj/lL0k00jibvusMACbSXK2ePq0wPHT+T8+ jgJQRpclvOc/v/mYuKzwGtN6OsVy5eahTZlDVL4n29rtkLDdYAQBj4+dzzDtGmNGjAIQW5av UktgN9E8kBRfE9EkHTVtYHg2JPYg8pgoLq3Dmi2u2zMPPO37kUMKeMHzdrQHTdjBhS95tPIk BGKhT7fFL3UzcdZmESgCtIo5DcgO1Y4rFx7mfm9TaAFFyYBXO6fDf7tgRTZdw9hXT9Uozx2T 4a2ayphS9ES1Crr0pNM6Ta0zQ3ZZdKM1W9VJ5qX8sHr6wdvNtagaHro2jw8AXZriZDo4szL4 mlbaAirplDrpf7obT3a0ZxnU2WE5vckXeKuVjVf0i8sb3CSsclRUS0nPqHhIm+kVuO918ri2 Gu3VdI7zldhkS8pRE5M2R+UfVlJi0L9Ye3G1EaenfHZR/S5Sy7jHnBDQy48tP5QYABnR7Zbc h7l/fA6+d5Pjrz/O5PD1fGphAfctDSF+sly0S93Xlo/1Emmm5fNSNbzbxXg5nKq1xbh2VaTu G9JAnolfbEU9ipDZgG3agqDKK1dLEOvLD1Fol7mRtrVtwGEE2myPfd1ezLOHUgLFhlPNPfn+ 06WrOmgWMDEHAl4Ony7W3iQ5dEPRdWgnO0WFnhkCf9cgsEwDN4M7JM90XrL/y7+kPtamzrBc 2r0IgaTwDbGzxVVGeAXfdnxjYw4Pu6XPcRQp3Z/R3bzEzp8UtXyeg7bZHVlZurmKp6mzNSXo DK2VitYIqtQlpVZRsRlybdZSEAQ1uKYAg+zux8M4BXqPbyqgJFDyilYkTvyLj8PeV2Zqi2jx LvlMtKlZzdI8u9o4FzeA9YV39cMoksnHwfwzwoAoJsc34X1TKV64mKzG4ylqr/xDtuRGfEKL h1JyvLjCfMYrPyKkxkJV/otifq61l0iwed1aI7sR5/07NWKIeOC8B2K8TxUHx+gsB5aqgz0t bIX+gQ+HdL4HhbvvjAj0kmpS0crN7kwNa2CuweJ0ulqv4mwFrJGp5x7/g1W2pHL5Vu6ErZvu KHa8KEQ2Kkz0fKBn6/S4ZVNhmoi63+dTb66jG6mznoUbkY5gTMhz/caZh0SMbawP6w8GCVjz 2RCJelv8ztdLdlWJbyPGh5r3xn57LlFjRCiQtl1gqx6Okb93qxbBw0t8H9xkgblnpngnukiM zZabTYttt3ZsvAWYEuxRLqjbtDwJ87jjy+BDOLFeZ1K9dNutYg+6ThY/zOVCp9RlvN83bt10 npySuY0YGEAfBx8OWq9o7K5nlZi4Ni9nuJcwiuzriEUDd9EZzH9KhPf9otOOn4iG9SnbeMND fI8HBwFrJNN5GkDLbbeZ6VlP21NoFuYpCQ8KKWLUjwL/3rpZRhBuB9d9Jbt7g+5QG1qmjEXG MyRQOHbyD5gDcAatPGQ0PPP2bqaL/N7gVL9Q3OK+JWI/rk5AN3pd6FyDjRhW+okECPckRHDx D8wJz06BSr/LyinFM6iOxYZg2QBigzPoFQBlhZ/1O/d0Gm8DSO+R7K5J7XA6BHY2vTDj2BWW uqTgDEAOp7S4rCRNV4MWDUKxIHpWc3DBN3yKHSoOczN5gv8fojqZc/cLHWbnFphd5sVnm8C2 e3vMiw7Hq0T+AsDzW58iWA0cqmBbeM60zZMs2n3utcFafewBaJx+d7Q247r0ZlUhrvwxf54U ATFimBfOEtTnj/kRC3rTamg0/kdlq20J/Uc9lem+Bee7EaUqCUSbtapNeFkUiCoL4AdudLzF aLCoY6Pc38ZcnXvcu2OMRQ7V1PvpsePHQlJuPJFtMWTjOWfh3M26N8KBn7AW2FnyK+CbQLj6 9FwZp6v18v7/wQK1efpQklWBMxQg2EilvH79RUAOM+GO4z7OWPuc5e2QXCc6wyelodGn3zku LCr0XpmRtLeg5Lt9uLgyub1zvc1iwdc00P8JNc5hb9fweES8YygF2vxnMYGYlspTNXRFwzAl wG75w9PuRq1ky+lorszxc9N27YjSYXFjSJWEVdFALm8qy3lA/fj2KpSCBfyMrDR1O25Gj6/I 3iX4gUnSs3ppbmMDJaNORdccoHNjcMzRQ/EkR+e81zlN7Ygx9GZRsAJDlEdpy1wDAA8GzQ3R Scedy1lFGeWt3v7fvbubPg/xvIlu8RmjFYhgVp58fhpQWjKf7Pb40gI1zpOmRkvFRyomJMuH TXL0CMBWXcY5bOlmxw4SaPSACsfUaZ9wc+TRcKe36Zyw+Q4sMm5tSimWJCioxva2Va/UNU8b yMcjKe9lsYCgaONjm7AG+Ta+tcQsVGW4b3+dMtaAXCvPLDonGUon0be55kTYHhJReLK9FSvr 8YiRIW1uElKIUguCFyXlh9aLXBRb4iL6ZwEf/GCk/ky6dxU60J3nSwx+5ftzNmzYz/vS+TTk DjdAVv+gcj17BEdre4Z2gsnCTWAjuec7oj6l7wBYc0o0Jk0L8A5FF3DTF7x2ZTQMfCV74rmT K3bHXoPjzhO207Xf1fYgkXYS9pmlDuC6S+uVWUuMblXikuBojysf49F0uHaaI6eEA4NUVpLK to6ptRwcdPfw4ROWbax04D5tNdCs+2cWNjwEJ5rF/kRnKKzPo+ObWhKMKzFBLh0AAUe2pZpf wenIqipi8r3XHNIdKwiqWBQCYhS0vlqzZ1mO6f8FkBoKH3En7+2ATRVikhaYMJJWkMfwlmL/ Srgwy2/nygf1whjsujecIkmGGhogCEysIbMy+nZiY0nle9Y4bGQM6C/OivgbcKEf7ImMYS5s b+EKAAB3VFq6yiVlFYOgZ3x1NAnkaMXuJFmp5GM5csVee4T+Q97Z+b/pivMd1Bnb4/1Kr07r LKunVRIymyhhht9IsxCNK8sr08387Xkn7wouRSV/i9+g5z6+/qcR0rLpP8ptAw8CRj/4rcbP 3o46c19/5UfJAt22EiI2scw1qh0hqLWBJoATyda+1scPQhLZE5WSCRev27q1a3JKIThsgbui m9748biDkLmlfr5y8DKB82t6CCDEkw0tAE2VraVfLQIQKaJ526oxT1EkFwkKA2UL6kprRSpN 4iXjETcfH9C7Y+fJp5jXqFZdWVcYxG0iwIEkA6fLaVtQGXgZZn7+HUk6aWufJV5U+KssXeE9 ktPXpVZ1y8/DS/ivYRo2x7pbY2ncUwkSfW7t2ezTTV6ZlQoJ+RA/MnFJ3wFK7E5XmmC/F7Az ofMN5BbKyX4YRc9GhuNQysPbYPOLKePI6/TAnaFo54GDIMM9sixBsH+9e3JAcLb5cfxpbKeH JY/OliJdY6dpMJWj2/pGnwfPk5AtPMpf2GQWgN9TUbfdfjsoJkEQ1Uavfni/+w3XS1TnyNie BwVRD8m/5YsnJja/FSomquqeS9TNB7Jmfb4RTk3rdpb5QZXNzocE/3LqT9V/bMHfyXsiMBcX L/RuDaeto+CM2fDOq8exc6pXybl3PRpqQi44HimjW1gmc1LNt6/eixtoBn9HUICU/A/KJAjj lntVFzdSMOuhFKlhV4ztxTCjU6xn40P2/Ze3lV5cVPhhBD/YvGgxwYkUgoLsODVu6OshBW0V srg6mXfiIIFEwBvfncEsKEbpeMB3+tuOWZwLzC6Q334octld3ddIZonMCoO+FKh1v9g2kl5a HQsbtwAdHFCbg5KO+2f6Te3fK5ZiJUzsFf2D9BFr8JCFJvUDURsDB80V0TlpAY+Ua1xKH4iB siC8K0JGLayWWt9KIBGBUh2XHTtI4Alq6iJ3R1NjPWN+rTaqJmI+NSqOmDsnnD+S7b75D3Do DC1Dm2irtFDpfgVYFP1Mb3mwQWLxxMZOGUrTwHd1tL2fsIlsadgs86yNwlAqkezIFzYzhRb5 OrtoBlGpQMcBMWcEBUrzSdphtu8l2qOHjVu5brPyYGk+LjJhVG9/NCNeIucHqoahCppwZ9Nh It02eEkrJEuj9aSPSS4Pn2bbazEhpcOtYkrBE18cJZJjX9xqpF497Oyu/r3k3ougMU1YGkEn 3lXNtBS9gph6jNegqszNXVXJJ2qrHAL3r7JzRdei/k2+jgv09mdm8LroyotLbWHbXgQ6vwFt RIQoBiWFxSJMEaQscAq2gXgmpBIrejtf8r2t+W11pqQ3llkyLuZIrznn7jtt0jqeQ7VGOHTQ MIobv0VWZRvQEN4vXrHL4+dMsmIab00hj8Z+c11OVafO1jpFlDSXs8mW/PHN9UlRJ/yleBwe VRKkBDf1zAt67rHr3MkUArPMqrmLa95OX7fm+J6Nz3gTngMOo+wHtQXLeHy5160NLX4y8CQO 5ZZh2CpiQXRBwIVq4Jtwbta2zbIep+8C6kMXiBooMirWiOqYprIBLsbAo6wu7Lj0euIqaFqF oi9ZMSUTZ8tDgfriXxmUsE8Y/ZWilqI3rnnhz1n14AoA5cEwEzjX9P5ZCrCvyZfXKyyao/Yk 0EQ7x1EBdjDw0vPj1Sx4sgk4nv6pr3NHD5c/kGJfglMYLwezHhycACT0hZRJsPdN2CFSMAui fK8FYvzwySU1XzUqnLqv2xM2PbENs15rfg+n9SHwDC12tQkJewHYlha0G+ytYrE4x8uNxKz/ /taNxiUw1+QiZ+9/6Ds642YPrUMb5Hakor+0prF9DgUXSloqO4w16eM9GuFqedwaRNXQ39P0 gHx5gpsedLDplEBYLTcuCdH/E/RnWaLH72tL8trZ5UNhpUbfb2YbcSbjkl2Z5IEEir2Mi+lz bH1o4Sly1n8llEVQzaxp6qWDzAieiqJR/eOOKoTBx+l9S3H5re6Y2OdOw5IGq9g2hGwZEVi4 aMFlijQXw4/fUlISSlIWKfG7iDsCDTAgRNn5AjW2zv2/YT7yESjNsd9WG6CJQlXDgA1S0xWh MRmMoyqOo9QaV5CZIcTfdvM86M/FFq0Rw9Ae9zV7YKYHZpqjv+CrTaWjc1b/xZXUwsXZlTcx GrQB8YBWfetWcdjjyupCvSGQPM0tTxGrG4P6hGKV4ioBp0Y90Xdaiuu0FwCZb0WPLLoVjykc TOIDOf9UZZpNprnhRZtp/u3BrvHVOaa3KQfMAQvExLbQATAkURo07BzwHWeFwS5OoW89+ATY clgWmda0czNl8/EzVmAnGMgjRNYwygQybZOVVs6bLTyRUXIPQMxcD5J4NgdE8r9qlNm3FApN Pb+OOcUUdZ7oYKkbXByp6d0WmgRl+TyVm3iZ0CXA4sesBrZvBZTjiICnlL4IqMScyS8C//xj Eu4mkz3514xEIcAKRBRrORJ5hwmynQbN3cdkt3D+JQjvkAikkMYuoe15r3pCwjFDN0qViV3J lCVAEYo9fzf5Y58cMgJSWOM3sN2bXFEOgcULhff5IM2OGMYnchy+haGIlIoqr+Z17ILxFZS1 hBwUtDP1cCWx86gLUWv1axrKOkddSkNH4vfCpgdUw7Kfj4CcY156ao0PB6UfgEaHoa0bxZ4D k5PNfFoCh0l4GRVtDHvo+TamVBDektSVyE4Cpz2e9K6rGWK8J+4NbinmV8nSCjy55t0FQIIo bqvcoS/g8ZoW57GnNDIhTkDYcOJLBOzZTHpkxp6bfkkgXG9BvB5YmmT+C+XdgLxhsPWB5pa5 fQRLiRoYtR+4kdbrgnIQ8RGX8xj6Z5jn9IfIeuOzMdGYST4OLTRLAfng3HM4OE5FY+aKeHpT y/Fs7cP/K54Ff8uoOhvIUzVDkYdQCgtwxeVLQ8EEV06jYk8ft4aMZlEN2uHCJ+Pzm2VRi5sn AeMD0S1gzEqUnVAucAQraLmQ5QSvV2+mE0E0/ievt4BH1MT4LqiKYt+teBNJYeZYBwd5BlfN RjCwIwvMsm6LuH6hFcTdSuaQmHFCyfgOWveAMhExUHqhhrex8ohmuAgDY8zF16HnlrO0mjTo VaVX4Nu62Lay9fbzehBosaGc6ovV1wWWL85YwPyou5ClPdQBg8Jioo6dKh01qNjPUuxvUp4P RYottSIBi9EEmUYJBnR9bOSZVHZRGt9eWsr+0g3ILL2ulfqolgKEU7SomDpLYIqmtyfGS475 F1gJq0DNS9dBOKb6lsL0tZ0yckWJ2IE8Cc9TAfaSkQYqfxB6N9OAGORMKOUUxaRwApPMmYjW FllMIcFyzj7UDRIo5G7ScxL3b2MZkp3uSco4IdVK0CtqxqBe0ysT23X1LPU0WfNoAJlqt76Z fcc2+VH7n1jtvRztUAxy7pEp04ZCFtyxQzSG1stEv1TuVUFPxiW7rqFUaNnYcCc+IUTxPgY2 9KQo1vssZJcuNcYEeO8RMWF0Y/1OoVY0xETOr57ntYgZCFaociZSbbxj7tBgDgBNEMjXajgb BwX2R84U9raPKL0b+nSs4h2Q6Im4BMsj0IyJCMYtrU5AiDdqzj5Fh538eSkiXEy5LeM6WZLE e0XX4ru+Ryk6WQCP8MsyRoqD/PuIQm80RbL+nhD6YA2QqpP2loQLwqmXz0JGIgKMWXknBsi/ JT7KoP8PgnvsfmIVEEh+kZiA/OM2L7ukkeB9sYxME2xVemQ2/haHVrCHDNjT9wIkws4x9Ex8 Im/nj3IMreYm7YUb+HvQDFwD1e1zCJ3uPlA6HFJzv7kLCPJWmjIswcQRw8NQzBfEU7uHFuf2 DgWUFcQgMXWIj9FI5O2vzB1uE+DQsWooYZapYcvQFl+UzCGT1ElIO4zqz0aSasr7BsmTs+L3 r8GdOt7GUifXmszB/zyZzdiuJJwsOTQYWh455IZa3zZryBYfIK9Vz+0GbUKjAOZRXO3bMe0i W+BIusaiFm0JiKiMmwMfcdaTpBLfcnWHGg69SZyltC/vY9RyQ2ppMFFV5Rj4gh5kl3KiEznd cv+iwH6ba/BIcZ0l57MJZCWUJtekEuofzis0nK99KPS0bGW7j8aBmcrj30bMvEZrbQ/Euzva AWZPENkUsM2MIqTLMbYdLrN1B2jZW6+s+khSTgCWS/XwfYgJuqWmUKPS61NAwhI1CzcXniNv yB3Mgv0jA1eAJIGoZbn7OMGfP18KacabJb5kKUwd8zjk+DO7M14hnIPjlFLkN49E6gfDcKZI d9GNYYzuJWE6ayWLEI0eNES1cOoW+uHptHS92RjYiTHDXbSo4/N1Q0tus7a8U8XUNPQrs0km qJ3WE7p5OJmgaqrmC2+UXvhfbtk9Xrd7aJto2fouPnooEGZ97a/8EHg+zWGQL0oVVyFIoAxY 9881No5JmQIFPZYo/5IQZvtuE02vudpJ264B4ZwMnTYvIY/dw/K/GK6aJrrukpqTtrGDNn3z FkAEphMR42jFZWYDeTf6AL4Gjkq/qA6DO/aIJmojpLGgXPKSnpq0ltQMFj5sQOZz/i7oK8R9 5FNdguC/krgTya07b0Igc+H2Vf5Qi/rqnQ0/OKPSMqwnwdv4/JGXRIllWjPUUqPTTzzbpewf r3Z8xtAyDJBM5GZoykd9yOC81Rs3vM5Z9IwknkS7SVyBGX/4c/RygbYnM4Jsx7zl+7Ms/A/B S6+4EYHQXewx/oeSggB6PFDNU7o27iqjxjLPV9RnfJjSZYfHQeALSO1lWwj/B5OJXErsWID7 kXgWTpR3tIVP4ARMS1Vc8KAlGFH9ZlCa3man1taUfnI6tJ3dFxJzGKONnPJFRr8iDlUtHQBt BUd4obEoEt0QzTJB9DDrgL9yIAEn7SkYv5pv5MolOQH3gycgANNL7A4MpsRrtr0RO3yfaHQ3 e9Xld+YnKnzaoPOL/1KNVqxUX+AmCLkgd7ke7tvZ2jsA+4uX2MXok69CXbctg10307xGPHBS H1utW2Gkv5xvZT8QvjLWxQsviMZj/o4xCkk85OlC/DCYngCAluYkS7Ai/uWqcxsbZYgcT7ye lIYYBXbv+oHjUUaY/hgxnS0DOR1bwVhV9oS7uoZ1ygYPXnRrpN1lAT3wcuvsVBvNBEj94hgW Kx3/ucd2Nj0AExeuJNGKscqTSX8Q5vwRXB+z/LDKi4IaVVgqDfy9S7f4vfQttWB2n3OoQg1v QgteXLTY9LVrMP8RWjJ5IJ6tGeLLXEq8v12YbpYuX8D+C+aocy/B+LpnVPmWmqNvGioH+OCU /OC/CaTZtVAlb0H8gW1GqT04Xpoi/F3iTn5MDDfSMtWfUBvP2ZOPwzauiVFUDytElrLHp3yS 8gvcDCBeEpHccIDelDakSkrCS5zk7CXR/DHL1putBehuHneszyMzbd94oS9WFIXA6N34sW/5 awg/sSDZMTkvHNyHLrzjF9MnmJGhGOXeYpgemEjN2KFgMgqkjJadTklGVoPQUZBmsE51xt20 YT/flQ7ulrwv1fr2ZoUew+lMdZ9htbe17rUPd2i+mU0Tca/ROYdHiohEMRK/pEFyV/XbwYN5 OXqIIVbPxt3Jg76OpZIkjL6p/nxqaaQ/b/OSBy7ghuewiAbFx2GjptJ2qSSqjSN6THOhULg7 41BCYeWTaTVhljwyfLuYAJ0E4vMimRDAQST69IfdIVR1MjVsB00C5UBbjlR6tjVQSrvETUUM pSIRduv0nhZ1Iy/KDIHicN+Jvx9sIm+4KbeBi8jLhWM793TPkv55jDNqLSmQxd3ZDyZDFE/H xtkSOtDo1vxxf78J9lr2U6yBS4RWl6I1ce3T3xk+uJSvdlySoJKaFv3v/DGPnm/8cKwwWYBY WtBHqOHaEeh18Jazi0L1162of5GLr/P4kZMqnK+rivWkNn9JbBIg71wxs2vTBOQAMCbyTg8D ixKsYgbGKzM6gogSdDfg1tuBgN4t1opbPASkW/xuI2xNd3teuNYpD1hnECfC5dN5UXZCAbJK eW2t73TZSi0+3z0H/atKrn+um/Pg4VVOWm6rJnHIQ/DYVkH/5Qr0tM8pj2UDwOXRSGFehXIa h87Z9KvhrTaNKOXyRnC7Hlgy0W76Wrxgqr7J794nKDgT0sL2I0JKsBI+F66jz8ddayNXf8Wb uoV4pgi1Pa8rnZoX+vMaHEtibtDgmrjeMvSM0ocYDtps8wE7Pg2VLITozDD2Opdjuk8iKcmR DKhiOSTabTqIHcFXuM1c4btPVt5R2T0griTVErw2v+RZovxHytExgUKb9S+/HZDPYywxV+D5 vTFMj14CTbnTWXZXvpsCHQ2cmis1menFDzjLepb2U8SKvfhBdVM8ogjxH1oYH+3TNG6XBejp US/+G+OGE0yoIlPixsgHANx96072NC2Mu4RD4vmB300JKR9pUI6kvqz2N3RbhqxLpLyk8CQG vmFvjKRcmUjpD8gb/wg3OJXS9ERgkxRNTGYiioJlzUY7g017PwgfphKi17KsVCVLz7hQmTo3 c71wlYPE1dldqXSAOZlJPFWFDWaoBIpnaOxjpE0dLj+9QqpoME0v5w89tULGhJQOCNyt32xH 30BlY0ophAlYrQljFDUc0an4f95HR5pkGk8TbpIw9sswODtwkEL6AHBcCpGVKJD5B9CrmYtD PzZ3VttKz8puHbkE9KXH4st62WN5qOM5PMlGkPtxqPhXl/tlVtyMoDtEr6YpTqAPn7X6CF1b h3xqIj9YiBHoe/umNusQErt8eLB/pD7fHpdenrG/YDZgODa/vJGtjDO7F+UxMvV8PIRsKwAr y9tnPk1/ksaTpaanUr2pqcIPrcWifOJ2XUSwm76DchhjvA7EHZNoYqzGGC6HqAahThqDvs0g P3t4UafLvVgiRTHILnRL/m3Z6lbANVzF7iX6i55bEGmlVUVO8fvFI4R3k8jNNLiGL+XnK2D9 YlWwvXX+DejNH/PJcCDS+rx+7jr8V8fI729+GpBw5son5Qf/k09sBF1tMJviwzGZitQzovGq hzGjElchziNRTZAbxmKCThuI3FswA9xX0wiZMRY6jz0nixtzIGID30nHC2cWXae53Op9t2J5 57cyc99YY0y1kE0ETtRsGyy17vWR7S6FSc9S5z0r2NhwcnFFxokRIZkUgnvE9X7jjaq33q0V klTXxOvYBzYy7v+v7vfya28g89dnqOkvR64RFa2nxNm4le2w2cD5d2bNdxElveg845TCLdjM ZcnSVzSQ1sTCV/ewr5reNmBd/wuV80KfK3uFVfHnWyCjWIvn47b+ydUhEk8yQTexw+oxC8V/ pKMQ8qjYslcvkB6x9emOJCqOyxTIoAiFqiBtAEqBrBWyfuW6gbsk8Prs6tHadN3RP/yyxxs3 5AbEYuVKrnBBgbDGWzMCKcpcXVDfU16tN0nkVO878y2ydJmNnToNlqOrgOuZgAiOGupftZLZ K3k2hsnEtb/EzxP7VfgCiuwGPQHSxc4yzGxOfFydedFX3wCmdYmUpYDuulTYGqClwwOG/jZj LKT7cen7IO1e2K8Yqz8y8fTG9mqD5c+fso1ae7wqPkr0lMZaIyf2Wxm/4qQ0Omjq8skCeczs RYkIMCkanvvkqf00Jc5aPtYViPRsG7HpZKBaGa8fL6oJ12EJ+o+bOpkZPSAB+iPLAZVonqmO qiV2vNLE6mZleu4mcuNJa781mV037yjS1xwGvQXI2GkJMN1Ansbz1VE6ZOx1TRxXscZjRWh/ vRz5ZwAzESRs9Xjh5pLpClkoxbiL6QPe2fe/cZdFMvuZqKFpvrNxfxGlqpLYaIfE/UPrPTIK JtMvkDkAj16QQXtqKdEcoAH7QNEDB6ZhJS0A9JDITCrYAx7ur0SRyzA1E03CqzXZHgruIAmg M3GdqwXIEyX++FjDcU8jnh9swHAqClXf/dN5Twm7ReEkKahl6aexc+Dphq3vfiuJsMznZGRc 4BGEa/+Ikg8FZQMY2cEL/fVblH9WZFkDXK5nomJgZGyHSKYnpm7ncAl3Mem8Ox2b/7TDlPh+ Haxkklq75vV+B/dliA2NKA2qJDoHZ27lsk5g1eD/X+N06An7lw0BGtYYK+SD3JhdfbeLdtbK saShIhmPuSeYYfSgcZoANf5FgtABkg/lm4HCN5+u3NO11Jpjcc5Dew6p31a+iGwJ0cD/N0M0 5Dzv66TAhGZC3yYcX4sOtWwHaXHK8qrPEfkCnwCGY+IJ8CikKgzWPcg18C5JLQIT9S+qwlfh YPdeb97y9tjKjnjwOfemEh4dE3Hrw+1KNqfYGQMDCNOWpYY8VjR/m/TqC07H6WYuM2wMGnhL Lb5SEQgcLVbOU2SKGXsgs7rAvx4XNNvtHugz6WEDxTACObKyGd3Qu2i5H5cojrWQQWSoxE9i e4F5L2tl/dncY+/dk+k0sR9i1qydJSWR5R+XLAIq8bncry1ZWK9g1OZMP1hrj0sctlOI+gx0 ih73EO4U0a0HFyXTbtd8suB3Gi2BGW7kRAXCgSAU7fRLdUI9MM5gMJ4ku8GX1vTSxDLATkcX dkxlTZd/5UYe1COspxKgvLh1/Ih83WH17jry4X8WR/5GkCniZNIlGZb2hC80RyFv33R/h37U vUl3Ma5P62QQRqVLf5gt5fA8iPEA2AulEhZaoTy8I+GmD81ZqHzoXgRAajpQBOtxN2Gl53Ci rr0aytc2LhurX0rrOb1IRSmAZ0kqt1Xa3sgCIvcAa0FRy+TdWnx6deGXYrTvslQqinjzqai+ xg8hvRS4HDXE/fBaiiamDZrZyp2EiUylk7HDNQxDj6LQnwRn7HZPj30lQnTM2qeYCUp1jCww 8Um68r+hZIMWMKp98rWIMET9cJGsIMf5zrMMCyNDFdUMRL1bnw2l2Jc8iN0pzCkP8mKN/7bj yikRgOfOcP7xyqhxiZVChGYNtIAv1CL7+8DWNEmnNm8QIVAPG1/9GXOOmTxla7o/pvBw7OtJ JYAXuv3WXyrk6QArB09tQyh4H1ZCrjPpqYtX3W6w29NlTCqUEMpClNHZVgntWIdQkJsyBBI5 ximr9A/5WGkKM8t3lyZBGcxLUPR17opyI2S/ObObhHXITvl2ak+JalLZBE9nZCMlMc0z3wQ7 U3PfC0Yo+ELaBNDxmvv8k8uM+BNHuxW7api/ml99XQdU9gDCfZynt7F+ZhZ/pWma/H0+2p7Z Sco+Uqfwvi0SVv4bC46LLaoCA33UxTNU/YNktVlANOlvt6gF40M+DHFd4Ky1kk/E+EtZcRjk BrNdRVkDYYyxykXdDkC8UStgZMx8ITDdVAu63YvGgxOVtMj04cCzHqASUxYf+7wrmUfl3Kdk Bld/WVpCn4iYoZcOyqmTkEw8Srki4FApEby9X36ecOJUpEWnrZ9ezjcefYZryAM2mtduOlaP Be2SvkwFWa6boGkayVwuHKeeDnEFqilroPverknZ6S9o6et/1RKkhaahia5CFj1JewJ4a1FU pD7lIdfQC8vNonUaxrz1ecTRn9VTA6/cbe+mvRIJ0JGxOgWPR5SEFbU8aPDtAfQLCq+ybCjl kqo4iId2TmV0yPVqZSL1pC8UUcIh/ia3dAXMZhNQ4+HuWsmQIkFHsqBpLQEiRL83GqB71fRz FZoIpsBurZtOEEWZcZZ8vrPC5WQCJNzQ4NEQ01QQTTdF2tPApFbXn9z4tSL4mw1VPekcVOGL BW377M9YdSlilQHfc2+1Od/adOixEYUqMRa2vz29a9saBL3zs4TSgCxpTNKgWMSsLtHvd24f l45jGhf3kEyxF7xLiJShaY+RL4tKTly5rIh2Op7EEKAMN0yIvj0fj8vabrTRnHuXYwSg3yyx K6V/o0RG6mmiQhG4YKbEKoqdiSplIIKqnBxdXKhmsUXJnEtIPeBXh8cLVNfErqn2q2K3jRTQ F/T9rkA0s5xE14yH04AN19/G0Gt79EantChmT/x5Lmo33ydhpXERV4rI8sknxz5fwzq9N/HS TGg2PpgK+99DG4NzRDQVRoxpnOaWj54jZVebi0kQy6zdQM9/8t0/DpsGjhXjEAvB1qU26giN ypFB8PhRVmlUpid9z4tS1iyhGwEkkbOOWBS9XlZXfV7iOXro4TsBnLIWBDIkL34Ouzru8oab /fCnovUtKvp+DVVEw8RVRvkz6hI4zCzu7ZlczzEsqQXWc1JX6zNQ7cTiWXqYXEXGfZOPhFe3 Z/cnsU2E9/BaprDq1rx6plzGX1owtrP6JrE4hnQpf+jZdbt8QPyEJF96fgDB9/DmxdWBrVZ7 Qu0iscaz8ULm2ib2xp7z0uuz0aGlwDhbfaeEx4ifJQ+iKLi3mjE/yLBPVldvIK6pDeeNNNa8 mXViPT/kNaH+gta2Jh/d2SE24I0VRJRnu2jYKD2u4L4BODGvEwcUC1O9lnc7qo0ONeQwLoE2 7zGNw3hihak9ra4XPCbxXA/xsPg2G/popqBrYf9aIOunHIDL5VySxB6T6CIsLmAiq5Q01PRC rBy+3IzAjX+jkfu9gK6g3PUA0sOiB9X9VQZy+kqZcqZkIyOD8Je1VefJvcPeGDp/A2Wao8ed y+N+UxpEu9W/TyD4nxArnfM5trkL1XBHuARFk1u6e0pWM4OyTPIaJb8JT/by3tVPtEzvDIQI DA/gsE3Xa8mkcy+rdw9fqearrPBdBvqhwpbKW2QcIiWpz0B5+6nDgDp3jf2oQOlOZzYwE6Qn dGM1ntw/z7FAlUjIKk/sdt49OE3mIsmixm2yEIamT0mOOkdddhZMWxR+PPMSzqGLK05s7puC PYYxY7niYW93//CtzytBjdK8sBIbOxLKSWks0Tf1uc1wfEWnkaTo3mQnFx7w/20zOh7x5XDT mBEJAyTrJ+QRrxdk3w6douggs5S6LSx/APnrxDRfjBH+mRMStDIdlt46Q2K6BuRZFblVkkgl 9F9UQdTrMCmyyVYGApr8ik4R69Puo7SvvCFAH98i3baFe2dyPO+ryjP35/3RT/qEcrLx/hNK 5ZMixdBrs7r5ARKdy9vpqK+JVkdZHsrv8uxmWsH/5uwtT1bMOzzU/697qi0/tyEZLdUDsI5h jNzm93tn8/yIGjfh8QkGoeZ/XnlsRHZUmo8sVgBJZvaZmCR8qhk9Ht7es0wPzIZG5JLf+Yaz 0EwsUqtdhkg3kRr9bbe4HVOgM+J++iflMiNTLNLKW+nUBdyxfDHEB3r4Am3Qz51nd51PN+18 1yvNy150xjZPQg0EI7MIsTQTvzKLbhcVGJX1HwOQYqe+Rc7tVWUKoQP18FAjbJbBln0/ZeUQ vqx5cidOvQQ66vfhF0sT30ImCtqMJOuiBJBk9r/njJbrPjkfe27tyOwjoeTcPj9XaTpWRcCT dGmF8LGKTNqGBtyU3rulU3utE3zjpvH48qFUQzmKAqrJkQ8jWVHO1wj3Ywu7LL6Br7ziKsmm KF3IbQl2R6fJBnUlFflAZ09MkhXtwa5aABSsUcWN9mxuEOjuV12p92oy7yjdLUX3zjXRORYg an6QI/7P+yMvzioyRd1qXSrYsmqYoj9TFXN2/mlWGG7xO9fOdGSWGsZ5YxyH7aJnAPseWpTM LKGYV9MagXoVl4C+2NgPECFyQJ5tczBu/WLaOkwvytWOBEQrveCfXo2zTUsL3g1hKIMRnIKU 1wIDIqzi1mjanYDqO3XuGRl6bRkskQiuZ1St2qVSnPe7CqTkIqpFlmpE5yThh1Mt7Z5rL32N 6y1vIvXHSn/yFY3WIKZYno1GtNa2K7eps/HxjLrtcGdo5wnQQmIDCoGydvdWAehoz4AYbMUf iV7gLDvnfThNLWyXCc+MWXAeBy86kVlrGKvtnTAhcll0h+Akjh+yZ7PyUohuL+HafnKs+yWt qanzEd+pdm9osHariY/ymCGHETSmYOSj+JUcepkiQLf9c1eMTKK3OYdhmD1bzuUuJoSHzanJ VyBZiykNQ5xYK8UknhUpb/klvPFoGblwVTcD5Y7/+3ENO+hXyvyZcYZvbRBtIVm2cFCcsSSZ RnvOs1BBcPLNsuaKQU0jBWTsfOsdVN0Cx1Zk6DGgSLANNIpOyDYogBJL4HtBJXC+vgxJml5K oPsbLAXLl9RtAZjVQp5LQb5D0S63sMakT2y9aRcWpKtEQzFucYHTV4k0CbtOfLJ6yUTXKMiI NbaggAem6rKdhU2eHgJqdc9+AyQdrZFVqlNKky2ZtSXvG1OBX5FMl0nSC7ylCpAZHOpzWIlk H4BxnnBcEOtfcmliv6kx+DacjNAgZJBbHeAZAiPyeEuRiu3umDL0ecq7tyRTEYXO6GungRmX IjY2dreVWulXPBAeM7muwvZMjL6cOO8pMcqQ15DbPWJD1ZdKK2gAaJHjJegwbRmknlnMLEQ+ VOXV4k+zrsEVdBE2c0FhdG1ErAqaIoKCzFm7qLpf+YClTQmTzJvCkbK1bxFWwiMjjaJ9dcK/ RZQ5c0+/ZDwFMYz0U3k7AsXZfpbf5ACQJDQ133aRwHlmDyR6suRrIPPEOQGOuSnmBTDcGDON ldyvPmuaoK4x7qYFG+j0sR3b2ikaGkkEXR+plciHxEM4aEWHA7h6dSCxxCS9JY+jaaVMRhXp Yz4d4/LTeEwG22r2a6xmEpzlbNBqKvAaMa0PMGz7K1lrNAZMZZutIiwa+aoBRSjIMj7FkwvQ dFUmzTFI6a48hJl4QYQ3Duyk2j2l0FoHjNYhfcDoqJw44VuOZ1EvgVTLtTNXG2CUkEzOM7u/ FMASK6kjkUU7UOX1cusGL20TbU3CXh0V+ohwvZ8EDJxk5zTnFi6vaC3DEmC0hvB8TBHMgFLv 40NoARoN7yla+lwpXTbwHDbyQiWOvnMiGeD+0+aSWMUnHOGIK61N9CdfxPAHmxbak+lI4aEk gZYX9JTaGvfEol71YhRD0MZ602sJMtHr7utb1w5owQ4HjDYF6Uu6KmRbJYnMiI2rvYq8KbJK ulFsOw+f9foYI6iE1IzxDiQmFVxWoean0f98es74KL+ubpeTscaQoDGumfYmZqPfVzk9LTON 89+KqEgLKnYrcbr75HWMTKWvF2VxxvJTp95fcYtNZ5CgIYBKWsu6edXJhCBQDhxf1b4UFsSm w5ut7Tb210FT5cuyy5AVwl1K8lDMiZU9pK3I0zjjuMD2omQPfKMOWYeHsuRMFCjf7c/ZfhLT LHp7yjmESKiDPsmZwo2H6mcnJKv8dDwB/gE7h9hJ8cm5h1g8OufMz9HuPSl0qLoZub0bpu8V HqFeo01qBTU36rpfl3Ck/Kw2UBb2We5bfEsA1JpnZvIhtOc331lbVxg5FN1UeteuR0BSra4S ikzADA7M8aN2Jxi4dnlN6pUaV2chP8uSUpuKodAADytiHjwa0sU/8rkrjGPoC1GPfL6AwpZS fO5r/veJh6gQ7Q+dMzNd3QJw8taxJ4NZJHLh9qrKEo3Q7Rh2iB7VkG71EsjBH8lgN9U1MeTz GkrKPdGxtLBB1DB8zboN5wMfaO2DDseusxHQFrzWk8nbuMsbEtOhO3oKuEyzhVtFXlLq4dcD NNm5mqnc54xqP4bA1ff85TvP5cyBzd639S9R0SNhF84wc879w69HQLs2ytOUQeZyPPFJ1rk7 PigY6hAER7xTkvx2pjGBQ9/qGTFeVTBcMymES5gpp7RUzaLziHG9WfTBLJK9LvbBxahPACoK pAXGKLFh9EJdrE2ZKl8uFsl7plb9gGrHAioxhoyPNvw9w+iwoCvtAsxUyhDWJukGImBL5sGs KEj8oDtqLMDYO4v1RZ5Fy89EFDczlPmtXBQVflIN3iWUc0rX+rE2ORUi32+AijK5XE88Wv2n mZgL0MDOB2e0JElaNyaQdg93RbJOKyh9gE/Wg3sYRYt3I/p9rqwZP8tfTaNcYCY/YRWbdru9 cRS8ok2uyneyDLG57q5fYlidZJDNnDCqlo0i5NDJ4tS1+7EiW/Pn5AzaruJDLUopgoV26g0n dhj3LDJJB9BzLGbZnuszYdBMVLpjRgkn2tejF3KeRdpu2o+MhKbBAdZvqMHGIe5sLGmZLzUZ 7ETebKwJ8mmcRZTDiEx1hvG+F0nJNakB7ws7ywbJOZ9MNMBNlhPpcZT+Iv8WVocuXmXXioqA EhiUo7pei2c0MWZaL4g/QxDMwvrT5CdV7lWoqyCPwYlKKNSdxBuY13ZmABIc/6BpdLVVX50d 4X+9va/ZlZV/ibjhTubgTOrYZLchGwJ9m70SLsG0OUZJHBqz/R1nePw23vD7vjzZZk+EYCZm cZqXdzTOFbVRbpAYsmEEFvNZrLNxH5XRti9TnDUc6n2/9ZPbXmt5Zq7U8fsJ6Xoh//6i/7kZ fILhPxbHq8kp77VHOs48D34KJ7as0nK0RkezfWwF888dadaD9AZvJHIiUvpqXz2/NLPcTkZG 2MEtwj0JRCTlEZniZSy6FPr14k4Fwntx9uouTirUespom4eOfXpHGKY3w9xqlUE12t8cMlVW JnEdg6dk6kQUw5LY7wdPjcnxmrVFG3ClQ9LekpiSpTwkn3A+YHs9YmCkY+jb6kEiH7fMJzK8 fjlk4sn4Lk7BvBNC419Ev7LoGfXoweeLBrdUmOO/lKTc1rGIbiOJFc1AEivWGBe+cWhQE8I0 pO9sbzT632Ci3Idx5CJw6MGnOThXDZkVgotACXqP5yBvQjJWks86lJblCQ0I7aeOjKU4B5Ko zDqx8F6cbf703Xshs0gHZ8vMjaCQPGIeiDSdrvhZtYaB7tAsrapp3MOiVXDSydHBUHFw731k VcyGBTLKFSUtYz/DlijnJBfgk1TPxG7EUMZPPWzjz2L03aZOm9n971rTBP2uda/0vPwE9LAP ZKuEjqybsYFimjCkb9FJWiQ87GS+X9D96auCd13yL+o47IzX42MNKeuLUwFoHKniSInd9CH0 ngXsNbxsoiGO59KZ94L4WCPKWRWsCgOaaZ9aNeIst6IkG2U4B+vrUUa0pmHLpJh10qGzSs9I EOoKMWf5OaR/iVamy8s2CMmw4lfIfaALJs56ZZ5CpvrflsevJpSRFsuWlU7FFf64GM23FaKl 5OkGlwYxxksPBRVBbGW0VvzFDjFQ81yRY3A8EFlXMTlsTtj+xt2K33rlP+DURd0CHwaLlSCf BS5U1qkeGrmMgz2zBYegId13rMbdrS+c9QgenB8sFFkHU6I13nF/8IzHWFqPhChOVu2MCSZk pH6Vzk+J3HULCzWLIA7BlyA+Tm9dE3TaEyeDH5U6+aCTtMNGGNR7BhHh3QBFe2aiwGQrVixm c2onUvzRqK4LC3ztiTWLpqlVHjM9+fFXnlAxS+EuaH8pQbGYDvDdqJ8EaA2sW21f69VNCu9R aLlM0AEwWpAKCg+6Ffev2eS4IJsoBAox+rsqnDp2TzXJSg/6IslgYuMf02hEXVYdrMoJU4lv kxATBIU/Tt9LgCbRQy2Ib0vgg6O2QLvQRttQ0QwXShtNUpIo1vya+71tvep4XgjEkDReQ4Io OUrx+438H5Y7+e7Z1TtNXBxDnSlZo2ArW0QUpW3qY7cF6r+fPbSRUaZACRBIzyzE3+6lXHjm M7FD8mqoLWsjCCEZh/9EUQIRzzn7w1DUy6+APdKYVRkwukZuJHGByoCNM3VazuS34M3rysVe a2BuKFdmcTO6JqlZBSydy13YPOrQt2Pns7+aC4ZhpGLKSUJqnW/uML8s37eKMdMoAVeQVnYf Xzuyo0UBlAMAvkNx1kWyHwxgGbkhcjfnpJ3/P1hCwyLZuYT2k0mMkYwkRk8Wslj/Pw7okWPB SkLsWPWbEvCsb/+/QpvDvVuvAWLL1qm+iDC/E7N/XtN4i0rK+HARIEY7Zi2xxBf22OiBT9v4 Z+j9RJJDINZMKggCHT/EHYi9DFqtAwJZTWKE4D/9fcgHUGBkKHAspTFSBVYonT0joy/KHXtM anKMwXYN8K+NI59uSuGLaUOg7+XEKhlEeUilpxP/2UM0190QpD2NF0n5j7jaJdkpmK3iOd4B 3ePgQSzDmEPmQbTsIZavFSE4N2vfnCsRHDaUtP7HYBquqo4w6RdsFJamD00PBsZCkb1ISheo eJ4l1b9BOFD7CgLvAkNwmKZeSqcu5BsQQbOzdTOKGodF0OyRR4RH4+/VTbP9RxxOh2FtGn7c 7PMRkSF+SLcgKWUCDBN/bsvhHQHs8UTbW70eE6AAiNocwx/k72CroKROcf52LbBBGwRtMOuE ttxeK2Qk3WGLsZhpf6I/aeJ0CbGea0SvxpwhW7ixduARZr/xQpt61XgwblirqzQRXfdAzUVW 9iy2r9L1kWOmo/UnjEbAzL70IDdudA0h3f4vYluFuC0AdriAHtM3Kd5eiuQFV1T+GN9lDFRz IuV8QGpuMHccggHXLKAExILDFgtC7Q2iV0ctFNvnlLk4jX4FFBqLyIyeFHt54S9pWFqA9jOJ 4LuUgz4O4yQuYDA489sKUHRGW2+81jHmCrwfp46GqooOcat7HddaM2GRThQsFWRby83eahS5 Zi/MFFgrPnhvwYHALGYNTAbVI+d5yi2FEd4b0V4++8KKGkRvf9wHdTZhmeS4nrve2wDODAC2 NENXQ7pPej6O8lfxSfMHRqksN7bN7RFUnwyuBlxo/vqT9aNEKOoeX619Pw7Z8OkjBSj7ET5c d99HQB49GDyN/XfuqiuWje7JrlEeBkg/AF+U4qA2q9FqEmr/nt6T46YOQ7GENRJUGJIWBKor dqyJGtYsJ1mPl/RgbicTEk/MUNkwpKC8+b7Bmr/r6WxkD6lXPr/Tx00vkwQNPsJF3WqbB+xf GuAgTCjzxWf8s3k0Nuwby10qOhea4fzbzRl5jmmkd0wzU4zaONtP89tWgKPKqncAHTEH1Xmn sOcLrRN1eDe1d2AWQiizQ4QL59ODnfpXFlUK2RsQq4xbelAWf3b2g+7B3/hldiT1Bw5bfRaA OIR5nXH+0u3xcBv8WSLUtd7c8k3CjruE69R58BiQDv4fiMtWp6NhxebV2l2Bqhm8bxvD3+lB Ao7mFh5aosZq6UZlcnu8ZCmmHn8PW/RtFgoP2zKr47J4LRsOBBry1SOSldKoGDho2A78/9us ypkz8FF3ORMRwIcv+5gN+/quld0OgD0NYqlPsd3LZysBZppfTSeOJoEOX5Q/w6ssoAotwpze gxY7iz1ICyKMeqL/As3AKnRZde1pFMfHiSPooB0Tr6cQoGLiEpJLI8G0tZ0O1/1pHF3//j5Q 8JwTyd90OoBAFRO3/CVlTLNiARB4JKUhQznusfvu3hhU5RQAEPintVCt4NjL1B4fLMux0pGA JGLyxyjQ7jyr94XoVUK0LWXeYdhaZVZu11Dq/CbXEJTf8Nx6iWUnlv5l1nY2lkswKExR65pz h4ElRa833FIzSolYaSQsVwvmkb/IPPokI/lBY1W9JBhvfkfLQ2XyAznUCanPwsX5qF2SNzcQ l2mmK6Hc47/Dta2zFVmIXDo8nE7+/Dafbz6dJ5Vk0ngJ8nThkPN0IenszHOZWp6rjcsoFh9b n2PunmfNGNfNT0Vgq6bPyEHje3ahJuEDDJuztsI4WUE6zvn01Wxmf3dVzi8ql7kDlZsbzwZK rh2qtHt0SHqzoPcGuqmsI5W1A+Axg1k/xiRqBPaNh9Y4G64a/LVM8ZtdH4mUxe/N8dFtWHYR dPqgv+mJtIrYROvUQniU+TKThe+ZVjfnXw7gtjxHVciJ0R/ZKkVs8kP+Kxo0CI4SXCPTwANc IGTHGxjN0F1XtDTzjJQ0vsDflaAaRVfKaRZ29bclJQ5/Jlb0eEH6M2pd7UCUdEIf9uu5BgE6 SPMbiPihju+NzDx9nMMo4+UXAoDpqiRCzb9B4elUf9vwBuDzXItQPOGuAJw2+5m8EpVoKjGP 64mkiSG4iyjgqM5UrX2JuwUVNh57c0nn4m32OW2mPqRedTzOm5I65aOr83uqORYMjhtF/pUe MH9OziVl1meeyuES/3MnicbviJCO/Yv5RbBVVlt/IIpEyCshcnu1r/4KWAhyoIVPZ76e1d1+ iE9fYt3bzo97HTlTD++GfSWPb+qj4f1bovcrhH2xEsB7y8sqMUJzE3CSq4TWktc5DGFBdTh8 yFTIhdZcIkdzf9V8z6fxjnTRtfI2MuznJlqJfQ8jiti8Zcc5rssn447z98RsobobTDwnZ8wX 27aciiGfQOUiNrLAXtKq1p+5F8TAdVux34B7ZTeiV0mM8LNS+sC19HFoAq5J6S/oBnPme/2S RlAHp1+kRnbsS68cAktvDzTx5cXxfR3xo/N0sB2j3rzr897py8v27q6b/G2C4Nih/an/CJcL gyYHbaVdyYVazJ2yPCfnJkXNGbZ9R+6v2cGjeMU+s4KL/a0N0pe5w8TtjswKMPLR1B/c+Hzr j++lijN8jRLjYb6VIvNee8LvZfRlTgMZWwP36ZryvJshBZ8aFE9UtqHTGxSISmjmdWg67ijJ YQ7DEMbz3KA5QFmv6x8ADS0jBEzqA3VrfIs2UtxCAa2htwM5fXXX0jHk8nfjsgU7bONgWsg3 9hP9OuzSUjZB5P9DnCWA0Q5bAwbc65yUjfQHIQ4h6dRmeKAFUSW5ggHY08NymwCXNKOIxjNp C+vd4xApwiB7eWnF9/gYMDk3wCSrFzTqr1CVeKmaMldU4WattzJSr14ZFrimse/0uRH9orn0 q9jzxEoADzpE2VePtn9CqU5T2vTlY4iTsyU5spF2M219wat6JlHaiLUwzUc67T/uh+0QuPh9 PSxEo9kUchYv/iSHsyY99u0Z3kugFb7H6HeD6RqRgFZiZI8FjuzV7n1sV4a2+K/dELYdR3FW Wj4sZihXE0GrwhBD6XSCz9TqOPKXoB5YjnyibUDJvHWrOwOqn/yp2dMPtPZprWBiStXDiAmM t41zMyCkZSWjDznI86IyLh53hOs08FOFuZUuMhB3b03nz8v+gOeyRc67cEUCNAZaVZk3p2Wp dH/GmHCJFQPqc6UI6NmBGpU7P1w6wJGE5pU4t+4U+nFSRoe1fno0APw1jjZ1rE410KAXGQvJ 3UDrrlZO4tMAAC1XEMV+J1KiAm59+j+HVZxSnabZ7Bwp7LA2OJW8caPsdg19m3CxIfAyuhee 6MX8Tg6I9GQHShpnFA2FuGJTZ+EXWONw+tBijsfhd6WEzYmuB2xj2zs76VVt4gqobl5rReum EqZpte5l5T3QtCLAupHJrl0JRy6Wucm1he2n/maSjIWN54+VFzQ+osMlkjAJMzIWUnz5jj6k QN5Ut513v0KtcSZy8IOkIbG4VvI/O2/Ent93Ja32Lp4inM9sol9CpZ43bktRd0nuth7a+rOs FUFREMoLF8BOS0yvY0OuEbRptnRkB1smIA8WXhgwC1z0quGDTalhpp1DJ89e/S5PbR1e4moH uTU4D/wt5FU9UOWVxzGS59F3Fyt5l0fvggix3/3ZiFqsBgNLdVepUyJqT/lZsVziEQ9E1tlZ copJl95HstICgyo2Vw0Eg4TR7gwN13Y1yQ/APuxlCanOBi94htZkHSjPddE8d2Zj0V3tzje1 2Fbm39MUGltTaLeLIpBue9wSuzvc39rKmOEClN5s8Fqbc8YtSJfS/c78h2H/fS7FeHUsDZte UGe65PgX7iv5H7jPMwzzKurUE1Z+LADIv6cYaKIRz6Z6miEb9DcMSWycvJjr6Oj4eHxj4U9t pBQWU8AyIqroPcOOkhHYTCfwN1mcOvze8oaWayH1Xc5MFrpOss7m8y4aKek1M6okmsyXKPND QxHPO3RsZ4cVcv/FPI8Ye1IlU/C52haC8R5FKqkltN7N0C+Wpk2QusarXmd9OAlaO1PIMKU1 9iIftgHU98ciyinaZNUDG3PKPQMQhGJE3fDIaBIt2b+KtMsHJiSY7ln9orTzCd16fHvRKHSW YcMb/4NH92R3zbOms6TVK48nazoIDn9t2BepPzmroSUSwcI8fyNVlsdaaumZxJFBcaSz2BG1 tTH8q4mpdGKyCgt5MuKxwr+Af+tPkpdgzBYBd8R3mHCr/vpKVwmIlivzccer0OZ12GXuLhP1 3X+l+tPPozn6Zh59qtNaW0ZDHri0Yjb4rXlSsceOQjuAm0yws21dhROxCX/NVywtnCTQWieN J48Su63JQBd3SG7HclbJPrzmLFjPR7qUnMmwWFUIc82RE28F3NQFIr2OzA5QABAq04Vrs4Sg M7jgj3kEqP828ybGsbo8TNtL/SkzoWAjz+fqAabMhTcvRFLKagIIPC81v6+mCRj2Xy8J3nv1 Ix0lbfUQFJGO9otxX1YshLKeNzwwsGP0mZO4ckq/Rri6JxLRQPExNy/HO7DpqkTtRitVl76f fJiF6EONJe6yqM8yqZwu5oKTmv72rhXyxFArEzJ+UsqLsD0LyxLC43hQ0T6Vg5oM1pATES9K 4AlC3TcqFZQsJP6tvzKAN+6e2rkF4vyuxi+08ShNLYw/JwYgw/LDcTdmQyVox5VQEKAatCU/ JJIX3UenGFwSiHgYfMw2WnGTtldw3O2icGU2unB/EXY++9XP3F9T7GZlUDnf6sm3uf+6Jx1E 7SZA+QZbAtvRNeZMAv8Fmye1CQm2I00vMaK3q8m5n+fRsxN0CdEdvXwgq2WUw7mdGu/IS/+h dtPwlqTvoeRy2pmcxpBYcbge8GCSOtyMAARm9BGQMkUVYMD+9R/ec12v6ieeX15lD1uw6S33 yWkGk/CYXdUh5xagwW7tsQvXI1t24RhMj8Dj1U2hzrPXuKJoYVI4lqzjREuTHMIFOMRSGKya hUJgx39mQZGYUpNUdKelencyV8VBTR7EGkPKDLlKZ4juep0hOvRXxTBwdx5ugBsd2ATJRWfP xLo1NJHBHFZSl9udBGJB8JUr7RevFQ3QYbKecRmq+FkvvWf0DblTdXjgmKxb+f+6UUi030C8 06W186anFsHB6lD5wWIU2RgHOIMTYI3ifc6v+Tk6Dkn7eZH0a+4TvCk0pCcjDa/qLhB61xBY bVjIMuBXR/I9Qzh3bLMh4552f5NCemGXVZVx8nVZ50n3hvPC5ThBI0Fbx6Ppa4+c9xxuWLvU E/DZ3AIqhN8+BaD1WBND6cR2g++MRl3yw47Gn5z24BBVZufENz5I3WsA05VnZMtmTIFEXQEe APCchH6RT4rNkDNlMxclAK90LjUXtrMXR+eJNSK+XYE3zjv9hpK0c3wQsQrmjNEq6HTIPYvd 3sMDpzeFBYJLfI/7oJwegmdrmSlEdk2Zl50KlpYBPLg5k2zVZeB1bWtAHOTwkf6W9jOMhw4O GMpmOJmY+OPKBWBxe34mHAd0XEp7WIkh1rQPDJnSvoYHZS6D0rM7MzqBxi4HrVuWEPvMHfsq kBnBsZ53FOnxhcJZF+svktuOIFhnhTtj88dtelTgXRxInpOvKRIKRYeXoI/bsEFKYjjPV5Z5 p0jGSAQxTVnk6+typNCZhOX7KIEUBMhibawcmA6YMqI260S9EARUdkHRhjNzm56AIjv3LhE9 uGborH9Xta0NIwc3giTW8iIQFOYrCGksvLrYog5sYnh6HL9u3UopNyXZAeX+Zf7vXIJPtLLE 1JrO5kNH/QWT2+EvGmBIqamRecucatXKBbr+XN2bYyuwQLhuJP11Yvabakd2Wd9VUSbf8Lz2 /AU6aU0TGpbKdk3PJAUXuxvPJptTzepsjEFI0HNZIAs/+t2mJGzZ7nK9uS8wXwz1U9aOsku0 H3gZxyLXKYQwUN4oZw4Mg8rIGVSy/Evt9T0O7e1+BR2dJdrVuGB7+jFzWVqR2tYFxm1yF6rU OxNlusVNiQaoFSvC/fJ46WH/ygN8Nnfs+MfvGm6WgmXZqPBkCjykOkLd6HF9jb+pk9nVEn+o vrz2InjxjtzLhd4PXN2vnAX6I/AIeM5TmNHs19gKkfaO1UuD70Ikqs9JqO/cDRbI6mjWU7sQ O6sLEWG1n12bnGE16FTM1lwE0Guu/CU0Mw2HQHK7Rf1VhpRzMSKrrlKPtQLYgAzej8+F9Pr4 +VPs+hHJdJwA5AQPPb1abOGWQHNnRr79QB/5yht01lZWLX6BU95coe7mi7Ef0nTZRf1i1qUa EHrWbvHPEjFb8l8iNAwtqQVZAw9e3Hrc4rxWyL+E4wRJAIf9pW+PWoVIvfOJFIrbrXZL22E3 kK0NNQXSefC1s78FRzLeWnb0neIALBYHkDew2OYMIgXRMzGuAXDsQNqUfwiFMmc78D4+X/ra LDvJ0AQLV+l0m3ETzvPd4dWZA70M4XUo5BJ+Pd3VX+g7gOF12YxUKxMGZnv86nAACQBFvbmg TaaRToE804OJQKnztRu2u6xWXsgWO4U4fXqAbRb61h6qLEgWtr7WlSecVRpxf3qBxYyRgxyr Hj49EThZRYtAc9bw2o6obcunydmuJbLoMiK5I52yKX2xc3MZgG9n+Wf97jRNq/yGGXvweD83 EnNbpVtLs7OXSkALJoLlScMZljitoXHJppgWoH+EBpteJ6JD64YpYljGHUPADM/vaGUhrzSG PrMPZAzUTp+2O/OM1+0JQtAg4B8yMkBX4fXoyA4cRJX4qLiqn1sDqy/rR35/vmabDftay8LA MsNgH0IWqb9S0DWY8fcu1NoRNaRTVtSYO90GmyVGF5ZreioVnVbWqjmpzI4l5R57Oz7Qrm5t DGfr9KXjj79IyDp3+aIz/5L6Ev5WrWn3MG5b2apk5J//VGq029V+txEhgFg69TbqnW1UcGlk MESfonoyg370D2z5fYO2AIwT67e+1WG01redwquGKFFD6ZNxlrgtuwm3q21jzappFzFysU5W ua1TPVxxcdfpvlsKswsBi+TBja8ay1v/IAQdOYHdJQYEC9uTnpgRQ1CcR1AWn/IUiKMjBEtW 3Xut7Z03I+DWWw9DDWVuZHN0cmVhbQ1lbmRvYmoNNzQgMCBvYmoNPDwNL1R5cGUgL0ZvbnRE ZXNjcmlwdG9yDS9Bc2NlbnQgODMwDS9DYXBIZWlnaHQgNzU0DS9EZXNjZW50IC0yNjQNL0Zs YWdzIDMyODE2DS9Gb250QkJveCBbLTE2MSAtMjkzIDExNzggMTA1NiBdDS9Gb250TmFtZSAv QUpITElBK0Z1dHVyYS1Cb29rDS9JdGFsaWNBbmdsZSAwDS9TdGVtViA4MA0vRm9udEZpbGUg ODEgMCBSDS9DaGFyU2V0ICgvaS9uL3gvYy9EL2gvci9vbmUvay90d28vcC9FL2UvdC9TL2Ev bCkNL1hIZWlnaHQgNDcwDT4+DWVuZG9iag04MSAwIG9iag08PA0vTGVuZ3RoIDU5NjgNL0xl bmd0aDEgNzMyDS9MZW5ndGgyIDUyMzUNL0xlbmd0aDMgMA0+Pg1zdHJlYW0NCiUhRm9udFR5 cGUxLTEuMDogQUpITElBK0Z1dHVyYS1Cb29rIDENMTMgZGljdCBiZWdpbg0vRm9udE5hbWUg L0FKSExJQStGdXR1cmEtQm9vayBkZWYgDS9Gb250VHlwZSAxIGRlZg0vRm9udEJCb3ggey0x NjEgLTI5MyAxMTc4IDEwNTZ9IHJlYWRvbmx5IGRlZg0vRm9udE1hdHJpeCBbMC4wMDEgMCAw IDAuMDAxIDAgMF0gcmVhZG9ubHkgZGVmDS9QYWludFR5cGUgMCBkZWYNL0ZvbnRJbmZvIDEy IGRpY3QgZHVwIGJlZ2luDS92ZXJzaW9uICgwMDEuMDAwKSByZWFkb25seSBkZWYNL05vdGlj ZSAoQ29weXJpZ2h0IChjKSAxOTg3IEFkb2JlIFN5c3RlbXMgSW5jb3Jwb3JhdGVkLiBBbGwg cmlnaHRzIHJlc2VydmVkLg1GdXR1cmEgaXMgYSByZWdpc3RlcmVkIHRyYWRlbWFyayBvZiBG dW5kaWNpb24gVGlwb2dyYWZpY2EgTmV1ZnZpbGxlIFMuIEEuKSByZWFkb25seSBkZWYNL0Z1 bGxOYW1lIChGdXR1cmEgQm9vaykgcmVhZG9ubHkgZGVmDS9GYW1pbHlOYW1lIChGdXR1cmEp IHJlYWRvbmx5IGRlZg0vSXRhbGljQW5nbGUgMCBkZWYNL2lzRml4ZWRQaXRjaCBmYWxzZSBk ZWYNL1VuZGVybGluZVBvc2l0aW9uIC0xNTAgZGVmDS9VbmRlcmxpbmVUaGlja25lc3MgNzUg ZGVmDS9XZWlnaHQgKE1lZGl1bSkgZGVmDS9CYXNlRm9udE5hbWUgKEZ1dHVyYS1Cb29rKSBk ZWYNZW5kIGRlZg0vRW5jb2RpbmcgU3RhbmRhcmRFbmNvZGluZyBkZWYNY3VycmVudGRpY3Qg ZW5kDWN1cnJlbnRmaWxlIGVleGVjDWPNMhlQd6+RxkQ7bQIA1NpYLRhumHD8OCXVVgt+0SD9 NsZ2ATDqVHvuK7VSNqlqrVIOtZH1BXNqlh5tzb6fgffBsi5SY+SldhRvhI0keZIl7hTQ2Md4 EUiW+fWyLfH1R/cN2smT3apY9u9srbCqunMNNXYcQ0w4MwO1+ph6YOCsDK+hhooGMfVaLED9 SYsVFexDev8QGGfFjZWIAMYZwh8Mbe56a26km+L+3a3xinAza3JYwtrHPS3vs01f56XcXaAH 2Ekn+Le4Rt+U1uT2b7Vu91REnl2N498i6KHdS3BPvNMs4bGe8FpboN8Og7UMyXEgD3zstLQA flViAXe0zHdz7XmJsju8pcUWtiTevxYHcxZoiad7i+5L2MFuw5eiYFkg2w9ETzg1yC6FcaD8 uYvCdBpdTfEiqi5uPkcq5nFTdl8OK1/76emULDo7glgGCwpJorne8MUBoiMq4xZeQ5IsyK0+ OpfFyU1kzk4IdSb3oItvt51zbULC3aJMcNm2R0y26wn9OobrL0LcCvkm99U9JhzM0W7QNWea 1JvUOG4zQ1cUpAlGEg9/gHDbxImTPJGHtc8I9mbcbguJIZqNMgZ5Q9spmLf87g6NjTGoFCj4 X9vC03gywNDtDg+t+VgnLie+ZZm5xibkZeQ8sy3+0lYTnEufcrSZMy4z0O1eT5g/S3G3IdbV VaBJhdhVc8e4gKHa+/LHra1anIuQCEGOTGfRBT3d1KpDbaAyn/WibfhDcm4ezKPuHiE+Wq5C T/4bFXD4E18a3yubApHDNQluw6mCcos3NROervRWMFV9qQZhuGINCEl9jE71gxDICGbRSR37 JlsmDWEgfw7xF17LWMLaXQuw+abDEOnLARsIVUJmFRzq4NziutdIX5bm+GGHMJg5hQQb+7wH oQ/gQV1g1RNb4kCUKbrcMTMe/h34uQhUS4w2260tA7SkUAzeRiSijJY58jFWkFc7zXG9TUMB 5Dst+15o8DDhAlCpnEyk5nhbD6kG++VkBQRAqkxylbLQXZI6mi/sSBbf1Ma34IAGC6DUNADf SOb2wP6qjzDBdj1dUMEWrqDD3i2zR7t6sC/QsFcFdEOxWwYGfb7bLY1Ml1dyG5hO2o6gQ9bV aZw6Qy/MzE2qOMBrdMAzYgzK8ZgkA9kxNbYoxb9FFLe8H6yDtMejiA+Bcz0wl4oVXsRbEihq wpTwxYGaFtaIG/6JgWRi5NW/6U0ti+LNBtayl5zJc/YX84qE3rLn6ZkDqzribrpU4Wb4DtMn 9SvaPxND3mgymFKLSN02vQhXEwcZOlgos8ZB9gIlpz3c/82/3B86XHteVJPL0iTDUfhxIp3M 71yd9r+WO75JDl98+do6Zt0rd/DNQwyzRgC6MW53XyvTzOgjgZoiqc41kzsSiCVXClBAEH89 uawGDeqchBlclqVgBY84ZDfkE9FpJM/EMCjxHYWLLIi/Tln2Y+t5yt1sV/CHL1vaqZg6gxzY pnl+oiwcZ8IJaLUTZgHTThR2pnntzno1xbxdxMp6I36DFv+Y/GtwmNCdUAj7A8A9Cd5AkXbY gCSt/rqTHSVX/+qYITpWJWzd3+tlHeFfhplgeTyrlmFPkF7fu76/MPQdZphuA7bmc2kmEwH/ GHMF4evmrl5kx+8ILTTvYYK4enzxqSLPgJqn4zFsYDsI80ovCLefdDsMt42WNmh9TKxDlHoC dk7XkFnCy83SE+YAipSqBGidvXREVH/EYQ0RYpa4girdckxeHSMT9Tmivs4iDYXJOKgCAk3m gK3VtisiVxiJPJqMp1Fq5xHRJy3YCWatY/gXsrC129GkgnkJdubQpXPeld19dt2Pv+CD1pWN NuF2N3EM8fvrB9U+MRPOar5b9YACS4hLVkjOuArQiFIa2hqS+ol4aZULJrNeYA9jZyt3aeFr BzYRZ2DbY9Erpaoe04tN3H91evaLuHqSHVbNzdQK3NIfXTabJNIk2Ak/I3fyeUs8k9yMW7OA 5fUjVA/DV63exuuwLDNFmh6ttAaE4gC63mLSL2Prq8PeR4mpSyj/F/yrGA29iR8E86DTWBbl hLH0us7Czi71th0UTKio+zz9ZTCIYvV/S3uVPoax6/NbfpUVgXig95j2GtBWYAFrtMPc36zR J9z4twcSl4TdH4O66RVsopnod4JrhYKByCN0j/MB2+fcIkLFz0f6/QMO/rcIu+KpA+LwZpwz DSKYhvRz613L5MQHyPcqakI3HokBIwx5iCrDsV3WkPskf2UoDN39rnbNIfo2k/LL2QCG/aoT 7hmCAZvYhBmH+lQZQJNsng7RATJziv87iap4DMjNIPezwGWau+hCFCje7MWDH+5tRY4KLxP+ 2f1FJZN4u1qXcKT86TXtBUFe8efyosDzsh9WgjzndfwYRPP8Ftq9f0OEKyt4ityPgoIGYMxM pmTaq928vW1Cx1q2VSTrH+u6+79KOdxpMBbYagjhYSPF1EkspaWGxhpePEfnqWGhCTHDA0lH ODxsTOCJzZo+FAIrw5mFPiFD6y1j5ffZYL9aVxS1b/FlKu8RIG0qQ0r4pkKClKHu3pC4aark jvuT6VQMkQk6x5iPJLswA8+7UXg+hShYiHWEKYwKd+f8ABNgN65bhYpIKZTALwB5q09wIR+V E+CHoIFnGRTYtSe6f3y+swu+Fz39mXIcaFPoASfBz1q/59hO07awqfSeSf6SUcMBo24XvkdT CWodyXd4M0Yj8nm+ME1MI6e5NWHaTEp7rF2iUbwvcZkyoZBFWpsvRMVTdrO5stVkQPz89khR MFMEvlIeAzdM5snvpslBX/jSXtLchxMLBIgx899u12T+wxvYxbxw3l2qKAA4hTtEgk+EIVIQ +DpJJgV2IsPGv1OeIdYWtsq+9ScnmP8PC92sPdISE6OJU8zfqXmI516CWXK/aRc/LLFVtaXy kqu09aSTp9nxNjHiw+N+vZ354dMNqWytKlmtfdDXNh+P0AsjKOHM82J+bfqN//YIKXUhN7zt bRmZIUgbBoK71Uwvxst664ofZI4x5pspoGPhd4DTxF937GjTZnkQZFNWFgMm+f1ElzGlGDs0 zbExGqorOE7pfLNCY6l6VRKxp0HdfJ783GwQfgrbWyPQgqlp7gdg0SmrB7D2AvnbyfX4oHD8 VDXB47Ntba0XgLF6SVGSbIzaP1WjPww6ALCYl2F7RiY/gW/rZk0bWeVjn/eZkdn8DYMbV1qN mqCkLPDgYxz7GZL0RZF7lEZoDY8Tizya9VtOJtWqTN4YZJs9UBx5CHHrbBUWIcbpZZZwZYuw HuJo7X5sSS0Up+l6vF2GbbDqr/ZSfda4gR7EsFSFYAijiPibfFeXUo4CnQ16UZaGcCpoLPOX 5BVGiksH/OjRbPXydhBRIqf5Osl3bOPM8xGyxg+XRTmhe2qWZce25rI7Yj16rvUmD+25flsv KQ10jvqCOd4q9QiWDNxkXdz0bSYD9VMFJAmURfQlsYp9qsDUlLHvpNNBIQNWpyk4A+SyZKmy cgCPnmaZTxAPlYN9YAyCfAkAhZHeIZOUefkZZ68WIUKG6aRgUaGSe8UR+reOJbQ81ECxyV8m /VqA0a08RR7GbkzS5BIJgSfh1RYCYN1u1FVby/OfN5owPOvXA5s+4fl4BPgY3Mpi9AgrLbIJ R5UXoSvOXH32eZU9261P6LsZAPpqiEROOkUPJZyJ54q5p/FLoMLK+iyg4XyZPkh0mlcaP9qM i/VFsyKixNQHunyIh9LfwzMAWln2QdY8gqds5Xz19Ok/9HCrBcZGGAi7YLxdSXzbEWpH30mN BcAq2JEQEiirdEaGk7H60t+v1gL9cftamDYq0J2/fQS3giSFAMXkz8qLgRXK6EiPc2c4st2c 0mu9adn2njx/z6Ft5WJp2J+YTr4xSHmPUissL0dy01HaegMfUsb88SqUrS52QZ3XUNeZuIkY /WpHMwxtrj9TuPokCr+E7oM0i2s4aBEc5KYZnmjUqrtyEfztsbKTsPm+M/uTA6+kwuFLnxxI QceCUzWYWefwFk3UsCv4F7/zePVMg9IsSHeTBpPXrt349WtjzMsvVd7idC/+FoXmjWm9s1Vb JlV1O37QCoZ62IDRrQKqDsWuoegO+9+LbOyBGZMVlGtmNP7xo1URO1ZHew8h27csitTiZ5Vm ndd09Llaf98RXhTrmeGWybIWfAzkuMRa1Zz0pX3eXUYBDlA7GTYeXmA8ToplxExFHTOHntxS ctK/6oJs/Lmea8CXfnakiF3jQa1a8wMuZFyEJGdcCeJHCdzE07HnNdg3bUdCTiV4o64Gt4Y9 Mh9UcGKFqhCiXYiT3ZML4yT6P7F3R66vqEFNkPh5jCFulspG3hJKGKDyRhM/s8Fam0a+JMKI XwtTU6Qbwwa2yQj0CV4eAh3Z6hTJ2FOjZ5Iqt+qYzXCQXiEUhNwuY3O2AY9NxX41u+Zo/oVo eDL28ziBgl6uG2VbwbDOybCwMAgU25scbJqk0aKiE2KurBooOa07l7nGVyxVJPfGSkWFAc2A Wo7MBsKvuirHvmCdDQx2x63svAOcYI2B3Ulqkih202ljnRpK7Z69uYpAS27hyaSY2HO233CG MVzWwimSW5pauRLxei/panc3BnNKJWfHpqNBOLwMooBIaH726z5zgTWmET0Vp18wbtL0l31e 0Y6chdB3Ta+/wJcf8EkdgWtyejBwKBbodjUGZr2zg3bUj+HpzOL04uF3a4MuulsvHZ35Kf8W gyVxgn8qbM/smdMHxzCn8eonhAtPmzb3s8FmEd1rnVgB1pp7rR3bIwHYZSqsbA7Xd4tE7te9 KmZNhpVFdrUi/uGnrpFTq8ras2UhTMC8QpvNxwuFurMxxMyh5hsKqQX6PVV65uoq7ZQsAGxD A5U3VbkTpUCGykFegb64nFEVwG17a4v9GqwzaSJgu98bCuiXYemcCUbWUUnrLIbEVWaAa2Xt 6dsv14C3HbiwAzRRLtDS+PGLjjxWodgjmNagQZByvjebMrKsb/e/sP5Z3mwPAUdF4PsVUeQK i0tSZ0RwaPdtPT4oM0fbp+8tQs8EIzhKDaKLxJUDyuzMCVjeF83hd+WTz6g7/uSt1hOcvjQN VsTi4Bk4Hl4V8dJHpNWjV9fGOcc9ey6ghuWgGRSK2u0+aXQJ8xRXJEwPx5jIbtLrITVzP7Hl DaP7mSl6O1aLFXHPoyvrh31tr+rnFnltLNFgw1YFg1IJ3qKKlWZ6K8YF6fzaYRnOHEsAk/Pt uVs/dkJJGftYhCeasuGBPPLM/gTixFWc83UMbNfyUfkMk2/oTyiPsGkbDVwtlJ/LaVve5ixC Maf03PArb/LFQ7GkBoQXSFSH+Qt2TrsW2O1De3r58c7I5Ldh8oPo6McdsOVycpvl/H7kDlMu WAqoc3OlSpG7FmuXqhYCsYLWBhufuvK9DW3Eji0NSai82sHG6VVmj9tLRb/Pa0bkqBcxfTmP JNnw5aa9fQP1F6O9Mon7SQRz72ufj0xUfmwgfjmQELJrkmslhaL3VrYHSwphFQQO6tmkphNV bDJ877j2rIhI0n2MxPSSVJglJxDKeSIUd+VNQn2mel28NTzYfRm/eLUbenhcTngHuVx6N+D1 lJIISxhRv8IIVJ8MvBLBC1IKCi9w4jPms7fk8EIslhDgxnxCvsIkxBE9JvjMQ42mzR9/M1y7 559LdCf6015ex2QVZBM8eB2cId+9LtMIWIBsdVkNNltF11zDkHvfZyZr3ZbTomx7+DduQ1OY eF557MnFNdQqywoxk5HiCLRkb2va5jAAuQlGUifAvPXeoWR7iW2U2blJp+ABzVKuwFIDiOfo GyttjWqKHY++22GOJwQuTD9ksQNUdj3HTkERLtn8OIzvQVKvXbwf0t3XLXARQunTEZd32Kuq QgCHXyAmCJxRa2kraJyubRXMqN66Ky3vPXwI2hZmPU4rJGg3SaBOPi4W5KEj/YPLUkHy0KnP rQoHpfbQ6lwIYxEJgKdpg9B4pJYeP2RO5nK1GJKRwR/aHA3BXEXtKJEi0h1j20Qdz3mUjtAe c1CTqxizDrekLV1mIssM70Y7tncM/tej25t9k8G00XeiEY/e/9CxYQkT8H67NYhfPe2IylEs RYv1P0TcbMGkknbb22YpPOnkiGvkZLYEvIU84+8iwJ2T0V7xLfj0q7hhUlHrnCrO8+Zoi0f4 jVvw1dFJpnLCZIWLHo0p3LvtS1iPjr+XKcz5dRfgQhaSkLFzsLGsU/wMYDPqnBy1pP/wQuyZ 2iuQGVj2gNEGOaajy6/e75h8Qt3nftD+ReqLR3+4d3RZ2e1+72r2yFpNoa8E6yYWLTaIQt9P TthJ0mjCCAwkXyBJGryKLotVL1bfL6SwyiHg6vtk6ksgwOL3MephJ7IiAmanuHif/Grj8XpA fY2ieF6kUu1TQdjHrfDD1vKDlW58ypZnlihUaQC8ifzBYwNrDvL9wiSggxPCJJXlDkhkOR/r JLGrhK02jc9ACH2m9UJgO++HbLZhH5j5u3AP+k3P3rRPqTLZhDqKWc2NKjsJlNnU+VE/SmPF OZGWrQfq1dyeXpR3IwTxBclcB6b/uICr9Y68SOSXSUGIBwsjEPhoG/mJH3ew8YIyhSdGXHkv iGhfAPInE5DgrLkHFedD8WQHc/IbzU/R5u6ldt2wRjlkWDWHFhI9B1ehu9rGDbznoBFTBYJC RSZCcMsFi+B76tiiT3oP13ZiTxInu/z+ULkQ1seM7h0tDQ/fqJ3M6WJbZGMTb2iMsK+1dSb9 uAzlsssCMIHNNcmKYgkB8nvtuR692MP5pxtU7UHy/8gdPd9uu++cM7IG1aLijJ4FMz+OyIlW VLGOTIvQM03OOmGTykz7+/xXaGL7PKxIjE7rFVXxEi9q7SIFhfGtM/gSEtRrRFvg9k7pL8BO L9++kANoXOLo/qqNUvjHAkMEzSd30QEDRe/BFiGiOVFR+Y6Wvo9y3B+LCqa0CpPxitz0M/hd gAxFxLVS2m3jbmf4wjSSVR2b3g1lbmRzdHJlYW0NZW5kb2JqDTc1IDAgb2JqDTw8DS9UeXBl IC9Gb250RGVzY3JpcHRvcg0vQXNjZW50IDcyMA0vQ2FwSGVpZ2h0IDcyMA0vRGVzY2VudCAt MjA0DS9GbGFncyAzMjgxNg0vRm9udEJCb3ggWy0xNjQgLTIxMiAxMDAwIDk3OSBdDS9Gb250 TmFtZSAvSGVsdmV0aWNhLUxpZ2h0DS9JdGFsaWNBbmdsZSAwDS9TdGVtViA2MA0vRm9udEZp bGUgODIgMCBSDS9YSGVpZ2h0IDUxOA0+Pg1lbmRvYmoNODIgMCBvYmoNPDwNL0xlbmd0aCAy NDE2Mw0vTGVuZ3RoMSA2NDANL0xlbmd0aDIgMjM1MjINL0xlbmd0aDMgMA0+Pg1zdHJlYW0N CiUhRm9udFR5cGUxLTEuMDogSGVsdmV0aWNhLUxpZ2h0IDENMTMgZGljdCBiZWdpbg0vRm9u dE5hbWUgL0hlbHZldGljYS1MaWdodCBkZWYgDS9Gb250VHlwZSAxIGRlZg0vRm9udEJCb3gg ey0xNjQgLTIxMiAxMDAwIDk3OX0gcmVhZG9ubHkgZGVmDS9Gb250TWF0cml4IFswLjAwMSAw IDAgMC4wMDEgMCAwXSByZWFkb25seSBkZWYNL1BhaW50VHlwZSAwIGRlZg0vRm9udEluZm8g MTIgZGljdCBkdXAgYmVnaW4NL3ZlcnNpb24gKDAwMS4wMDEpIHJlYWRvbmx5IGRlZg0vTm90 aWNlIChIZWx2ZXRpY2EgaXMgYSB0cmFkZW1hcmsgb2YgQWxsaWVkIENvcnBvcmF0aW9uLikg cmVhZG9ubHkgZGVmDS9GdWxsTmFtZSAoSGVsdmV0aWNhIExpZ2h0KSByZWFkb25seSBkZWYN L0ZhbWlseU5hbWUgKEhlbHZldGljYSkgcmVhZG9ubHkgZGVmDS9JdGFsaWNBbmdsZSAwIGRl Zg0vaXNGaXhlZFBpdGNoIGZhbHNlIGRlZg0vVW5kZXJsaW5lUG9zaXRpb24gLTkwIGRlZg0v VW5kZXJsaW5lVGhpY2tuZXNzIDU4IGRlZg0vV2VpZ2h0IChMaWdodCkgZGVmDS9CYXNlRm9u dE5hbWUgKEhlbHZldGljYS1MaWdodCkgZGVmDWVuZCBkZWYNL0VuY29kaW5nIFN0YW5kYXJk RW5jb2RpbmcgZGVmDWN1cnJlbnRkaWN0IGVuZA1jdXJyZW50ZmlsZSBlZXhlYw3XQRSvFEnQ 8/HaPria5J5pOjjyqrtbMgqqEZy3fc3vTqmn9u6K3G4MzLjqLhnqagEsz+r7ZGf4oDgJN79Z AZ7+yPaqxCkui3qMYHuUEpO3tqUl2/OukHjjjfd5kt1EbKb/fk6CQk1hntRsOFVux3N9syqV tPrcl2D9nTMUqOve6+KkF5eaQBCiC7oeU7CHRwMVPyZa5+X7aBlxygBVOr9felfqoSE1+mui S22OsEoUycJGpNAz2ny6ZhXVWXjlMWiTJdzxJuorQ0oA/6oLmqBpOgqnGJNcme9jNqIi09Yt ceBjVpRNYbDKphMVnTb8PdeFCWSRIzMAT9AkiEY06qtVYdEHVwFRkdbFmFAv0ImilO25Rid6 qtr1BTHZ+WGDloYRnZ/acnkV5xzjjQxBsJ0cI87415dBTVaMsUjtonYA36HfKbxOPRffuHmA B1LwogcEaz9Ww7/lvqEF7wb8ElEMzDc1njrnmz/o0etNmjX/MUKXssK7BJ6nkT3t/z8g/Kii 0mWwqSo7TDUuPNsrDVX7W8d7TrEPOXwHG7/CWwope+HeV/JnPJmmE/nFtHByMD5YvW99SZDU 217ChGvTE/uIAf2D/IIajFbboihgmxD1i/5FA7EgHnQp9SSnVfy1iqjZX5a5f6hIufMavhI6 rW6vRkhssQBvufW3nv+QbpLjvXtbTHGuN+o6uS3cuXdyEdbDC0UNe1GNAO0Yn39fWVp9G+tX ayedHFliKTcp7cDpWocBdBsVH7QEqvCDt6sDc/fQwooP4OsDJuEdGY+NiB4Q/pMBVM8FTdwb NnztdQ5m24b0jdDGEjvPN4JgTQW1832oGuLXKdM6Ieh1PZiKR/k03RC3u45DVT2d7bNqlR/W DefoS3/buFLgADI7WcuHznR+EiEYrCkesQAjWHCyKMDxGlpc6xf+icjs5vNymz5d2ftxAYTt UIsCW/KbopKdPKdbrqmfmfrmHAyLgaTNAGsNwNzEd5CoHBNNVEZW65HV/JI8u234KlcOtIL9 z9poLPYE/NwesGggoJdlQdKpgNHUywAgWAHHXxFDxmWIR74Vk/Blx/fyR2ejeEVVg2T/ZX29 ZbfW2xuL0NebQ/D2Tp/qCMpRVT8ln5CFNTCgS0IQ1QdoZUE071mkmPr/xbTRPluqQn8vWDnS /QyajD3P7U52ZVxG3i9Ji5ijc8xay2Et9JXRkmDJ31/nXNZmzh62/fbYHWM/0Jw5to1gAC6P Z3M4O0JsuPhTXFd2YZuWivPfN9nDZOUFWpB3IiXxf3wPIt8IgH6SOVJb1oLdnxIf1s72+Tb3 ccKMbRidpEMCIIZinQyc6Kz/h123hYmzlCYEp1QEdOA3J5u772HSIzC+/o929Qz5YZQ2UgrG u7bJrs5wMXFUrVdKQNRCGeA0TxTXtL5Kx64Qq9fpENlnkN5y+kHarHrWJWZrApuUkaDtDnya YIj/V01mai1NcJarVQdOwibSdFRyxELtVohBtzKNxLDNzkX479Zyx9Qz+ZwPUXwbsFtdVd7Z EXvAnUT+hKPLIudi7NhYIpf321tTD8aqkHRMwcF/o1l3Yh07pOJb3XmKMr6km8UGlc/Cbf3+ 8A1K9BalX0Sbuqa862xyh7MnODFVB7xWTP29cORpCGi0MKaLazhoERzkphw5lBW7kEpJDTe5 nd0DR1rm/Z6opOCOTjLZtnxgxkuyR2akWGM4sO11clVfJtdyFanJG/cQKYu6DUuybQaTFMlV k5vQnHQ0Ehl18DYdYGvzTxWZ19j1yzC7KFE1h+IwQdk0UofiF60u/xE4DXaQdEWpWm9hUu9/ CHzD/PIku2XHgafOz+qFepnHkNI4HP9UoSnX8QWAP+H9tJkTuLwPSYuwFkTycmoim587r8t5 7CdE951oXoCarqPOvuNDLqHB8QdjXhqilyXAPxzASM0AJT/kxZRgRe1hwoT/yZReZB/wDCBH +L5mbbiaNSeoDXpUtELlpbAWPfF+q8glXfNkke6GVz9H7q8JWMYHPIotHYE4efmDHWm7fNy/ JwZr8JLlQQx4KTRJ67BSEHJu6MGid50eHvTBfgepHaKHfWbc2DyBPqHip5oz8dKEtSdPVlpq NsaZE3HRkHRlNlx19PPO0t0MDgrQ1Pf9Cuk+oSIXWnwWwaF54sMwIz6YonP+VucZ9v4JyGX0 obL8Y0upjtesBavi7B+XcTNeUjvL/rEmyc4mRN4e7yzVXBcJbkfH/frD4lSwUE1bMkzVt3Ta W++73/hM5PucoNlYWtu6yliUHBMDSgYuH0QoBWK45H2gTwAqCr0nhLexIwO8MHZYMLWK94jr IGSM8Tu815R7do5MYuyKDA3vZp7DC5/aqLGjRbE4CTPF3E324uBvNgsxpYnQcJDt2NuJMT1q U72LQ5pZVB92q4zDYb58i1bQQRTPX3XGbIGzt+2ndUYdQkVfbWdbin63CXr4UqwaY2gTvHMi irR+UvwwvQCqsst3avVGxqZDOlU8PxJVGDmUA/j2tmY7TIRBOIkc2EeHXpxh5SreuQUJzOqw 3f6KvYjIwgy9qKoAIXIDQWVEwi2TRPy0C+lJI5SHb0ZhsKgNJo24+Ur7p0qF/Zm7NPec11Hy 0epPMd4azEU7eshgoEZs2n557YDoBjRUjoEGzY50u1+IwQulRn3C1PdZoRYOhr2je70e7BtJ 5zX0JI1iZFrsbv+i5TSk47Q9E/NzjqWpGVsD8qIVdNgrdCG3Oxe2ZulPd5EUw+Gp2/tVjJ4F s+PnvK8JRQXoTDz6wRgzyTTpLvbqGfwb1LWq4o9e77uEglsoHlejzj9jUmEF4otI80jsLlvF K7vqfZnjccyvHxZfQQhmhv7j2tUw+HAhUiTArwBox4AcU+9KHLAf2zNeT8I9Sup+XlLCa1MB bJxHARsaf56Kix7GC6BWstdchKLBOSc0RiUqAt826P7jYwEErDHVK9MieSNBxsBa0rWRg5Mc tRt71vGoLXzaAhp9x+afrHZq1sQ50Tz2C1SBBPiFHv7cu6P+crutj0jRvQ+zPLy8Xom8IVCT UvqPK7fkOLVtyMQWk3mgv6Vy8F3n9gVaBECVeEbgsa7M/OmyScZzn86ZX0Wrtl4P3gWxLWsF I8xeHy+GNjEBjn5dh2GseH5N3W6c1j93c2wCdFnpJy2VaV4taev73jQni1vF3KHBAyHd3AkS HdQEVRBNovU/73j4rFJhH2G1HERZsC4BAoxhvvIYHj7h0EjXSM1YsMomavCnm2vCiuedilY/ NA7yIbM6ekiLdCunDLEJlpTbiDD91LDJBzFdekexN2gcpKl3+AcMJuVTtC6Pg6y5Zne+4S29 CgRL8WnodMdXXsTzm3bCYqNW8MC34Ke1hJRAWXBG/cswLeQSkghcTqCNTjHSeLjEdAPpO7QT GiaVw85IDyGEQ3Dn2jEQ+9y0Iiyhad72yk+awyIdhzKWKULZzy60tswcGsh7ed6Xvk0O6fiW U7dkqN7NCIUWheCLXtZShB3NmRa0QF/by9R8X/TVsGL/unpcbB7nA611L/JBx5bSoTOu2jON U7zMZ5Krvd/gqwX561A2kuB38alcncGtXtHdAFn0rUKAGshHUZJFJvl0N00P+OtmTBUXWu5Z 05imnNVf4Vc0aa0A0PZ9+91LTqA6Va4Y1+EM7IQaG2al2Qp5O81ZRXmIMIGL8OWCyh7SCaA3 bEics2BO99PgiRgsieJZNeQUItpW8eadIuIoRg3QLIvzAk/7wtoVw6EjuxsKOY+fMcdBJliI nfTiDNXEATgJPvK91PXb0uQAKubQ7nT5ElfVRAiljctdPMF9Fs7kIsoHSA3GextLzTQI5FBM 6gL98aaCEsFykAIjQEzlZj3osj1aCA6Hf6N/Qcdk5NfREqcWW+FwVdqbAWiB5yg5qVB0cYKD 6A/Nnjs+QuJCC0QDs8KRvomlO3xUx703mrHckv472xQnqNNHHMIeOUXu/yx1XwI3+0lthEow ddtkcwGXcEVtyzHSByjHeGz9Pb73/RYYRbmyBekAe0xy2uQa1TwsH2T4JgSDMyKWrL5+T4v/ KW+KKXLec8d3zC2MGaopY3zp/DNJiPiHlrbE2zdw5lCAUelcMiOzf1JFVhGFldn+dmcFpdlG S4a+t6PR7xVOk86dDz++tyvvkDlRIHm0QhTn1A5CC83McxxdHYxTgLH0vh5NCGjg01U51FOy +aKHhbeE4TP5a6W2qXOO3vE0MAgaqu/v0kX9H5Pk17Fd+3TrlMpVh3aQd1UvzMr5c4a10Iq9 ++DUEV9hWeJ/8Rdf/KUjgau5WigLt5CBFHGEZh8dnfVHMI1FFvOgtGVuYr5R1te61Uvy9sg2 J00tqlSfzRcgFd/95HaYBfAzyEVsN3yQIwnK6xoOEv2xuvRgzy7jTyuaCHcnpsLS+HpU78c5 11AsRAiV4xcG5cQeE4EbjNC6BsnQnlV5bdDiJSGoBhcnThpF4AAOqgky/Cu049Mj+HnSW3Hn tf5UaM0eykG/oOcbcMwpR+y9FnlUzKGAwMJriH/eRubiTF6WuiIA8G0iTfcevDXRm74vStW+ cDL8UFez+Zy773FTYYN8xmWFB2W5TlAOaoOFUqEGEvWxAAPbNvAeuCx0itVRtgG3gnvhWs3K ToUe6a+Pj/BpnrxwL+UEMeBxlLzV3y/eX1bLS/Ilct3Dk4GRwYkY29vO9O6Nu+2/TKfAMWbZ l2JtsDlAHpSkKOPfaJvw7lZnB1Hrt9ZsDs7oEYsP0cwcO3yrXGK3TL4k1Zy2btXhDNcRal8+ r/fKGebrlFHa1LuHzVIGPeEbot57RllESE89Ha7ANnVnNwtGJCM3jntHNuIKCIpsMck/yiC6 VridhcjLAVWYAdPNMkR+YKk5ciyzEXtH/W5hrbtKNUkDeg1f6poLrwhBVGFeeHxBkIJ02kdj 8g29jFnvRZRQPCRB3G7bT9DfBemInKPfxCx5OvawzONcLrbRUvQCzyLavezzzgWNl/T32HSV 8mlY0Q2KxhrI7xXXpHRuCGOW6D3/AQoVIBECESYdpN4NmenxPzQcnD/gBvvm2mPypIu60PZY YQ9bYtZA1Gkp3Mr2FVQ/q3Rt13J2Kfu7dzNr2v/gLzyq54q2BS+M0fmHxKTP2pGpeKYrkOAw udoRC5/pax2AR93/lI6IjT+N+ptyZxQqDeXD41z+QzjBWVePGqEPdHk/VKW69jpqcilGmVaZ HgyxgwZcY+XeRQydV2cIvFNKy96J4GHWIVzzySA4ZczStVIMqPWZReAk+IolTiEwnBhUORkU U5PSCY43YqURYzdwXghhKwQCRZmtKsIzp6dUYfUIjPgvpeGf1jPPBavf0moR8dmCRGUkUKPP hF8ydmOViv/ZT3uvFpagX3qzdxHrpEdUDESWn2o/05tw7YxkiRXD4ZoWxKSniL7WLxIq0Szx tk+5lMquMKvktYmALx/OAz9L7Qlovo79Lt/diCjYdRo0e7u71G4IRONr09ifDuMsg0DRaoCi NGg2gRbg3e/pjMiy+QKnYhvSTAHtf9VecdxEOTpqd4aK404N0644qh6+dQCdfERH5+LmhuWQ mbIA1Tn/Sf6l5KHWxde4iwyLNrhGX7I8uZPJDYB8FS8/bFMJSVNJifVk4y/LOi/xua13Rama kGbOky873ZQbYvxt5l90az9CsuEnwNrDIXO47Gpw84vXhg4tAaNYESlbVgdYu4egCubGTzwP 17vPSDCa5ntBhZ62raQNB4yMFP5SYi0H5TLmGPAiexSWuqsT55BsfJzQIucBJ4/4fW0FujXS Fc8O8F5U4fnLkm5E5vqj/TdecJUX7uGEVLbQZ5sKWkOxSWcef9xrmDDq8WQcQGCDpvvfeSCR ZRXOD7Rl5V0qjCskqmRlvY7E8Rv01HQQsl+qK7W2wlo77H8GWuIaGcQwi718tG8oxTHrh4p2 eXNmVBrUSkjk6ax+B5SLUiKztiXnwk0uRdIGkovkPsIjK8aIJNLihATkrX3MdXlnUKTlHFRJ g8ItWzGtuAcVGAU3nJWU2GQYePuatdQhug3gobT1jEFqz+9kUYsDL1wTzsvQicyykxDsqnns JIOlmRt8kD++XiqoNRL3gTVapA+W2M/ekeWJnUZFic9jMLr8iPMtGXCZbpkCyEJ9yZFCzR8S WsQ0HIfudV1NkZAHVlliV75seStoUiL2Z2wL4hbWSs87uUjIoOIoAiSJ9hx5D5jaS4KCsYWp eLcxPLO7Axrh1v9+NKAwy/J2R6gM0NhyNZapmu8RBZdlnct5XJeUqnF8y0lyoGpO5TIB08IR GSM5zJomFXBCJyyf8V4ijzlTfvwnEcQY73+AkIVh2OO2pdW345iKSJ3HlUxLMnrjmoLgpAIG sbSWikZYwZmSdxCeslC8HuoeFKaXAkmFAEryDYsMwdWLJtnWmO8XmoU9CzaRzVjm7CjYq6xR oa0MoIVouI+IrHsr3Da0qQvaIa5hzcbkUc0n7FtqdEgi0HC2gOu5pTXR+yHi1gb0WBoXXgl6 LB4RSS0tGdh/qv4azkNatTL6qJtDHG1aigO5L4OyxNUVygJIqdZhe3JtZG5tqo/UFCAU5m5e k8ttPPFKpcl5i/FHda9LBvMA8iZIv+fdiMeb+1GMTdozJMHb2p4VHSUhl5AjVFSwoLE+2HO9 1QFdNWNb4l960HX3N5PZDLizZ+Wi7fKr/QoLXyZxkMnWI974kH1g37pj81UdHZVq4B7EFyzA MCKW5D0TCBMJ7BP2Q/1PoNp2tUj0VNpKZWbJAUh3YGyXJw4w6Vha4LyvZnz+7ACoRLrFQzJO uAoScOp43ydDyEOyloaJ9oxqkMdQ32qLPx1JSbQnzfVc4GwntoOjpIZ/XFlU7W40Wuc3Et6E SY4piLIkbBhLNjdaQaNGcLipBZywKgqHFQE0BU/Y470pr/o0R28a6VmXybam30rI4PcP0Mgz xloMm6MaVem07NAle1/2HCQVjACleIkQy+UUTusM9MXJTCD2OcY+l6h9YRN3ohBZvu2vz9pE DXkZ+uOs40sx8SPpy0ltGcSXtMI8KUxT1sKuZFoHlByCiVReYWgdrZRhkaQvgRZIX5P5ncOg XvP2OW4hPFTWwK7sLo0cQMk2QRjvDf5fIQtXazoY315nXahCCvLptWOU2fjhzPV1meeU+9DW 0IYHLLsue3ZWqdwE3y2BQw0Or4jENJxkViLvkPREfFuXvTl9WoFStyUOQ72gg/VCgywEh+qZ hBsWD5OygahVdTRo3smY3BAN/I0nKvqtnUurlhDZmrKajGKaJJbiBjtbegxxDIy4bV4beFTK OaS923l0WYItA/XpJrzcaI/tHzl/aWUziH+eHCQnnUX1zOVA5GTxeOTOo1rpg6fVPY/GmMUl CKclZ4T7Ko8QV5JvhoP2xaqGrR7BwezqAouJOuS8RCSRbxV+2gDwQv9aKoIjIMDSmQ5dp7YK gNv8jqsgOfeC0u2NnLz5sNehS7aELGzbgV3yTirJ2ZFGSABZVP1+5lu9dvqJSI14Jvyvo3G+ PFirjgOOLe7RwednrRoxZ0U+FdACEyIbAxPrajiv0gamNZVr6xkKS4r6Y/oMqIyroYN7D6z2 eYwloW2XqbZ52Manoz1EW8hl1BLMtou4wAIhHKM0mOm8L2YYe70pC78ICTdacKRmXFjyW35g fqxLJNly2ED6rYQbgwHXbxRPjaQ2MmDAglg3oN643PrC8+YPDHcHo8SabdcqvKGi9jBkYp6s I2LrF8nFsTZUFwzF6gLMATs8u7Y1kDeynVtRf43iFkopaUHxohmlms/N8ixabBoIEdROsPy3 zMsz2peg0fN53/S7jxsxN7f3dziAwSqt0Wb2TMvpcEUjEMt5E9irYRoc/1TWKDfUdSPXkJMn +2ZmIks8HNJdiMea1Qcl4guC/Dxpkqdcf5QBzzzqioREnGY1b1Y8m8uFNNfRI6Le5lCJV7q6 aay4i0TMwbqxTYll9pkOQ9qGIFBxcwbwm9Ui1yzp+As4ftKKxxdlBcqXaHK5hu+3J/+FvWNi xgY6d8ZaRwVVWgkf1Fj/8AM3fUNfc+3jpcL4E+Vo/HDbCX4Wm0Uqc2p6/Z9yvlJkju+FLan3 QHADCpnoRTJqydyyuzvAqLOAk6sKPd8mFR9PIyGqzFU9jMMnQA3Ozm2kpPgxrHM7AB7WIIay a9foYTNCLZn1p6MPZ8idNZmxvz1AgTsFY/HizxIgg8zdytXatWhCeyIS+kg3X6h502/E1OLH V1eKRv5dHrYl6dgrVrEjQigMmzswMemgqehEyu8Yrlqqu2DBC62g1jHisI27sIX8z7qZPcu9 5NDb52v1VKi87/L9a7uq+4xD3q5dtqTYMVrmdC8dx/0JpeIBKDv3kzedgJx9+0hQbd3cV3X8 3ciKXI48LDwLPTac+P1mytlouqkG/NkO6kb3HWYpMpmtwz8AcmCvh0kgbbZh1HpDT2bTBD/q kPQLcjnXZNgxRkK63wGYJ5ZPJREko69sDQjY/Ep3oJBHWz7mdUYJWmwgHDIdyPzYtRI72KGq kBlTs6Mu+10IW1qTtYr2M45Xr1NAewPEUbJm2b1FjPXauYwm+54g//n0r5jxldPwMcU68fzj yxmHdISEAOE0fJaFgjBQWwCOcR/ntmlW00tsEIXVFZ3LNR2W5oYuhDsHXMLffZBrEnllVic3 RhVrRTxpSrB/6eVZ3+bEoIs5wbK7Z5AeNfqp9gKzaya+7xlOhAnbjYiQYtP/HGjd4w1Aeglb uhOU9zbG8QtN0oGuruT6g/Xe8+tRvQU6wyxn2mRPTlSFTlOUfNllM3nNyjMJK8GzBx8vjkiD 9Ci3HWT8DtdLnBJI5mdz5h/pwi7Dl1cDcrk1ADpO2e/47N+IUrJglJb/oybBttoKtYfXHwUd 93z4iIt96fFWsJhp0DCF1RZpGoLCuGwWBeZ8wPnGZn2/kxfbybYT2phE+kkl/y5RD/kV3iRo dCtkqDXdHA1T9qu2+154FtWXROP6amc02xqJoSLXmM3eHL3tmFWehZfo4Z0detJyIsuQxwH5 G3DDPO2U2vsKO9fwkgvCoMrGx1dFYAbsP5dl+oJEXhqH+H0mQVSy46TdbDzQTWc+WuBpJpD9 BHMeWZVqVKRKz4CJU5E4KHDmYSBJbTD/cHK1VFlRk2+hwBSoqXdkRfTIySZm1wcR8AHBVaiO KY7VPCwCbATYrSsXuSvMxXYFzMmIDFFZatukq32d4RLOGAxXoiJkRqx+sRCtjmBcO5sD/6Q4 HoUB7bzyNERtIdOYpMQYfLio/nrXKRtNAZKuT2NQYqmc6hKnFgANtgzfVukV2kiNE2Q/Mh+r IeDuMV7g8jBrlE60w/mXFHPsdBG3cBbUNJ//EpvZUtF3H6WJXFcLlLcN6UlkOCFp/icow43q t8EGdrFpNQADaCqfCrt352c7E+cuzNM/1Ot8xUrg8Thf2xnV3GT2JnK3md5nHtf8qQ3QWBFV fn6z0nGBZ8ZSiWdqowMI2NbYY69bx739fS0aua+hh+OXem3dPLIdOXEnHDXX6sa8wjL7VsVy 75VXbguGim+0z7bx0fgFKgS0AENG+6AZckb15KSEYTaxaluR60xrMsdt7Zy2rb/X2y9boXm0 uYDVK+zyOQZiTWRwPIAXRD7jXYqZMrc95MxCSWMy4IYCIjB5JmdcGMf5+xdiazXLbCBUtA4q wQWlPbDB94X2mcB3vnokXxvifN/0bG+6vFOavTO0HL4k6y/KQfl0Wgovb5cNFNfe9k89Unv9 vbeQaAkrKSETikVwSBv3plK3Kihpf9WH4bl3jdUDEo9HbuI+1y3/IRe7qY8Zsdi/iqyhy3qd dFN94vLW2CpclaS79FbaE4au3L7uQpOnOVkcnFiMDUxPqBx7Ygl3RlqXKyS+qTPA5CN/KelW tv2qvGO+mCoXl/oSeUCSgHX5hqTF77no6FckBuDtdaGtTtg2clMKEDUyvJOBrV2bEbIv9/Lu WIP3eRWIZzTnUGOVJtT9o5eElI4YCORtMbj64NO/etnnOR/oxkLcn+vjcW++TGVpqGsZ4LgK wyPN4HxfbURWaoKC2alpbH2YnM7Mnu0MDhMol2/fccGwYpdLKR/YAFcsEcI6XFZn2GQ6ZjsY QM0kyxXBmgJRjE8pCC3JJHRF7O7W9wGvUO29kZejObE7g8Jq1g8o9ewgTwE+3q/ZIBlkcnLk 6K19N3uf/6w+/2mfDZiO84rJAelQmtDr3Sb0IGWGsM49+qVI9/GEcPrbV4To39WOXqxOWgdg 9hcP+qjcS+ra1OGy2ZOPP8Jsxq6nMGo+h34sEik/jyyiCmBOrSiV4jPFVtnGedjrqSWbqc5p dw2Skr9yYwtputh/uklyY9293WfaQRYSiJyMV7T7zZFzNwlUhQc2OEu3JKvJg4V6dbZlwdi8 pqjNE0s2nxZIfiCxIzLwY9ThBdxnPFSIshLD5Ri3hdJZ0s4i4I+HqkYZVK73CiPjla5kQGlb 2we+72YBIQMH9yCBqzmawHWNaNuLblxLJnT2XWe8ladmUfFvUJ1Xm+EcO2SMReFoe40FVAwO e7qeSMS0vWs+FqY2wnBh1XdaYE33Nsbj9uPSRRb2z9w4ZzZD3rCTfLkis4J1So0rdkh+aX90 YzLHWqQBa4kprzoVif+P1g8erEQQqNVnXbKU5LJk71YfF0oBrO8vE4XQ4us+lk/XVBC1Py1m xn7X8YVX4+3gaQ1ZyCa+Fy2XaeVDmdc1/WvzEujhMLQ1ONlBfVYuArSU56OPOl50eyb3OPNx d0UVwZPfc3Adxe/exjxGlcQQBAlEoGkM9NYLGiOLuCjwELgZPh5y9ZdXiIyTD2ElY0oxL9Go ozKt91LNfmjHhQfX5A1gC7BRHhIB0ChKkOs++H2y9JPlFXpfiJImS8ZX/UHml+54gvKwVXfC PUvKbvV2LcLDzRfpSg9wy73UIkEOa854YpfY3HW9tvCpk0MsVtrJ3fTFhf5qdMlQ3sMAgsRw AeHsFs9jQKT/9d+wkPoF0NITP5BztHEzT0DxMzysIlOwQLwtEhuqgyN2eCc0U/9elNWonuxn BP5MlVlKI4XNsCKjkWXYs33mY2F71qoVcUn+4/LboWWP72sX1UiYZiEWyeV+BlTHgaAkTEgq 3qWWXylSw7hxKQADcbG7PwBicBhFAJ1t4EXWGIg35uDjXg6Qp+g/Ul7FbbUfyLe0k0CLOqQH vl8moxhapwHbOb/SjfK/6oM/1+dJtzRBP6x9VbABlm8+duGEhuUx+WAVtTNdE1FgzI0NU7t4 DTFkieQ3OyXjBo6J9bMhBugKavpvuhcrSe39TkC0XJT/JkzP2EMBSHDBIYuukXYL/AJk69ma 9DaGK9xEXKQ//u77mZcIRrZ4QUCOcDiLFQNxDu1USA/Kso3eZs23nNJHgH7MJ6T2uMxL+gj3 iCxQC9m69JvPPyknKWt3OO+H/nOc7v9D6/g0gGVcjAi8vDLlYgu5alHBf9rBejWkvtTbe9d/ 8zZv9EIhY/b8YRVRnt7G+mLQvdt70VUbXHZCtWIb3uX4fYy1YEhGv9TOT+2FR6ln7N/KWB5x l+ybzZVjvzZbrZo1cyZvX2Jgibj7wq87vEGJ0ypeKnNEzRCgIaV0N+WJi3aZj2IfOKYVvFsA FGP44HqfkaYZ7xUlRSxI07ftUPsFPq5qfFo6uk9bl4ockWVPlmb1rGGlTSSKtGEHLzWFfTro Kwcdu99DCWg8nu1K9ewkE8PH+lyjuED1alIidnV+lfzUNBNz0QRNM4BdTs0KT8WTQJPj1WTj nJyw9ghV0zwxV0wkQSyvw+48wR5YexsHDlU/vQg+PBsXye3zfx368vJSKVn5jXO8NV6mdJHo Ftpq03aH27Wun9AdVl2JfrTEUyftdlBSlspsMAg3wyEv+PoxbXNbnGIRyXhKvWI9uMuvX9rg S824bQBH6WntMvmdyDXyqHUSNzEQk16JJMOC4VM1nsN0V6LMnsLd8W2pivRWe4UL9sXfjevo jhoXTt60ysuWKwkP0iSBRTadA0V9ZrmfAluM+ZTubztiHHLyrbmwzz+gzXqFKQP74Xd44Rq8 1fHF6t7Sr8viowydL/JmQelbVk6bHeZKrKps6MAUzKgDwuDuE53rS5nsMLrcE8qYfU9Pw+Oh 25EHJ1QS22sdcBObRjDdWjlJ7MW+eaFxBZrgc+1EAe600OSTR+24aIluZKeJRXQIe6mM6vCC 7KR2cAe/jFO0DCIGkGZKH292B5YhCdj0KYyBlk2D0wlZnRu51upNJ/V9F0Mu1N/RjqOITmeY mvzLHolViwQA6ZhCJ7ipMvkdx5OJcT5hN14Tz1FEA/JoPTnC0AFl4d4dtaEMRnC7WIRf3Ygs fYuFZO25dgM0v6Grr0Kg2Od8nRBVihYybeBCGouEz+U0kbatY3HRLFnb1VewKus0vDquTXHj 48vWG+1GxDgzcdoEmLt2RbwsTksMFSGm7yKU/2nSze8A2on8R7xVlMioqgY3nErLhtMXHLGX 40wjC//W1zfdNG5wkrFiTzUy+BSxVhBEFbPNZP5wz0dI+yVXMfhG5M1ulEeS+bPrQNcKdfJz P68BbTyc6EKZv0FHj5Eh0p2lHStXm7NarrzFMoovx2dYio3uaWg2fTPNvIIlIX1ZaITOhdrK DiIz+n3+lQ+e+amDapbFiVcP1jkJ2EDpRLRarFSe7bHr8wR7aD5b2V+xc0AcOq9Op3mhlG1c Zb2aoYEuXc8DMPfS+Q3YVi1sgMglwp9AXcmPm0lOCHlTjX9Ev9J/5R1UOwUHCBZlW//rimOS nlvI9yFmxWPgoUtmyt2661RiNjiTcpCSbGmP+0F7DzcGGTPaNrvud6vS3EZPCUtzKqInOeFL v0bjh8kdU44aP4wUFLz8iDHoQRCkjPobQCcM+hSt466usJdgLdvB2G0s4WvjTJAEdomLuKRh NNPROCR3xDKAb7wEzfNu4Oij174vyRgxeWeBVDkzv57688stSXoRSKZ44vpQYr4xTcknGI+t 1SPWzwwKn9YQ4qdzccmlUQnPWS0vpqXaPbfDh7ozJ3GjJzol0g72FxlqzDkSShRdZaO8UHg5 UzriLzqjK/uGGL4LJatJ73QR15kMRFFSkGbEa2ofW8nyU6xXiAQUgJpBsrreqg/3VEArXfm4 QIhBTTGy2qFgY2/JvkJbpyaUAJvyHraaSLKorZOkiUE17UxsiIiTqCfDVnQOFLm2rZMY1XTP 9Yr68PZmWpvIJU9dCJwOZHf9QvtT6u7aj3a3eWt6ZUPt1Sba1vefh1A+ZfYmBPwacbyguonE n9kN+uMad4s/KY7JPh0eahnguaYwsCsubTEByo6Sh/JEPu1Qz4ym48Mh/ak5QGThYOoYhQfj d34Tgp08oPFmRaZqfhvvCfUMFcEKflit4bELn5QcI5as7ftVWq0SNUGz2HDYTVOcDTmS6H5H T8Wl4WQr38QXiY5qKAxPM4j+xpNI6rtUGnjD+pI11YZ4sfMKUmRddkDOHAJBdo9hUOXsIMtc FR+lcDN4DFqCo92+O8JHIe/qO5CcBsh0KDBuDxRSrgakfV3+K0709NHBubl95EeNwrYJZvPf jkevYzazQJcIUmS51gSgBpH7uU8RS2Ht7wVIL2hBLzPFfCIMiogTGG5h9Qe/IIpTVrZlI1ek txOl+Uc92vAlr4KNkL1aMzCgmI2ZHut93ql//i5nrGcwglFHm8yoITj1XuwL4T7AALpDWNE/ U7LDkPqR9E/NCWtUfzKmZ7vMONs+LojhxyN/es6zNYhjSV48fp+DdFstbXCH1dJWcsHQa4ck rsA+KLszv9k6/PgaaAK3MJU08OtAesjr6nC9d5+Fksc4wijyY43Uw6InoMyzOIUj5KZR2TJc nLa13J/Yxn+IoRHK0coJyO6pm8gq4ud1dGvVeXkhY3VyI/pJ/64UZec5++7Sb+LJllWfojGR +lZBLcHoxn4RidCqEyB7Kxq252MKB36sO4RGikLhqLayGNOWDVJOyQgkXTUghUlbvzT2LrYj Z14Cq5bhRbjATmdrpX8A96xwUpMf0VOJqbxwXdED8jj2aYbS38bPpJLDiiffHNquti74gsv4 IkAbwb1fWKejHaM1pwE8vutpeV3Cf+ZM1ke6oqmNsAw/abNqUMLwkG20Fq5cEMTt8ggFCcRl 3BUY/9zJ8RXC+cHsfTrIKCOetIrRxKgJu3G4KoP6Wd9SRn8uxnC6Zd6/vZqtVtsKJATIbQkv F0H+8tYhrUnIphybRiPUuNtY7o+Af1P6LPTZnBO0jSolV9+iieZvjPSXSPj3WL4jOQQ0V8wv tCy61kfQ7o2u4wAajnucBnr2w73hESA9TzGuEX5tl4/AQlrK59Nauvn2+LYrZdl1kzl6a/p/ 8PlXhxcZ66Lzskz3pNohtC2FjCNLLqnKBAT+xScLfumoxRXzqArQo3rEWnfYHEOx3S9oDPCv 47BgkqsIrTWO8OVjDdbBnrcwnj9yf3NnRqc652by7T5fzb/B1AauWAgzcaZZp1mC74RZdIR9 FQBBHfCdv78anXmX+Ur5DrfgLGqKPBc/1CYDBJ+G2AnLg4McTmRL9pUUCa6eOGaBI3BVNs+V T2hJBuMabLUCXePTPR1ukE6cezaY1XEmi06DQ6rm/UW7LDtR9gXsjjh7VaKIYpe68dkjg9EU 6Uh9GUX3KCZhiOwOaGBzBUq5GeTXfOPlYPbZ/BOlgsbLWrFxxRwIiLL9T44o3ftdtghMa7or PR14Yj2ovnVHikeOAzHtlRc984wHi8n2/yp8apWmPObA0pyVz6ZOqm4TiDgEuK9opDjXoXm2 lW2VBH96P2A4MsCI/WEQprOawrM9AkmYcuzcd092QtZAGPXCv9kK4vfbeocqb0C19Fgmd4oq yc96BGPJc97SoO2yVHks0LsOlsmolBF/0AUO7v57lnItoLt8l3zO3XE+4fyqxDpeoh9dpJAV 0WiETCMpWqV4EP5JmA8OAhTr1n7IfZwrBg/g9xMnHlZ/bBR6SiNeKvvZWzWFhMrIgZnu9Qor lwrWs8s3+6AupjY/tyT14T5CNXIfYlntJVhWUkta2aXs6I69CZ/h2PObHq2DPPmskTxG85bt evTCwJahc02lG+MOkOaW8vEeuuc5v0YW4psN1f25mi2WG1UXyvovjsFclO1TEGQJQkUvm9gR djsIvkgOPz2+4/zhywqmN0wFR2v4kji4FPcOIYz918HfcroUsbMWixpZFANRZ91/AEU6pRl2 +QftnAKIyixyIMfUz4XoG7HYHxckZYM7meLRKWaQzBfNU/lz0kRyYePxti0bIbdcPiIi4t0s 4XQVV8NZC3q4utB7yPCSfOljcJYfOIFrCg5jFVOc8ekACuGBDcTQMHwPUkEEDlkmB78pRow5 FFSoLWwqptRETsT5XlYOlRzEyq5orvxQjOOvQjxaeuaEztjsSHrNzz7MNL+Na820La+YBLOt EUt5iGTwUuHdEhv3VJmyF2iS+kjsWflg6by6hAvyIoHcfCoZlvDbhyjWvJKZQx6UqnKKVLGq YglIabp+mh8n1xZg7RRMuqwqe/elS+pJhtN1vULgWdYlc29vXSsVFpG7fwnuQgofYcoFg3bZ RMbbjDyywx5UH0XObF/WMTk4RxfHPDd/8o5V43g7qao8weVjog/DB/M00QNtwd4dUtJRd1Lr fINgrFoyk0bfv9uGSHrvxhtvx16ZtQf6qdws0vfU3admr8Dc70Wpgjhw565tJTinuvqCjpGl 97JrvY0Ar6CV2udJgfpcDTD+B3qgmt6fatfvQ0nHyRRX/BIaHdXjqESL6VKAjDuEgwSAnHTH 4/+osHEpUDCmPX0/b2KIG1EE4ypkhacT6uqQrbz/AkZFcQ5NebTWkmKpEQI3S9QxNtu3DwmC Ql/MUciCMG5v277AS6LEewCt8NdM1EGRF+oAk/19KpAlBEpLNy7XvbMKwtw3YHpm/59tCXhF V0lR8aaX7l+D5UQj76y2aUsPhZhjEM7DUP8yRY4Msqwl7mrmJo1M/wBUb8FaXvzfOnnSpxn4 9inr8c+iD6JC8nueNnFiAeaZOthbbGANVMObaZBfc7su6CeyjWNoVldRscdkXEpXtDLNqDe0 cJRKJRCezabui6YhZvb4KHa4CmHszH6XW8Nmi3CElxPfYorFwRZYN9k0yi6CC2KBdgByGcRc Bb4l3dFkMZKhoit1SrVXWVtyVT7nKKu35febFJoHw4814YpvEtM9hz5O6Nz+bf5XHKu4e2By p4xKNdVCR3wLnNIizQgMzQTJKWEELKTRVbf38j8f1xx3ANCxWRAdDNfEAbc5JqqTMkJLBaf1 +rpu7hGmxG3ZtEM1e2J29QU702muX3jdipsZ/OaJqHpaeQ0laWs5cCG5Yql2Nap8xYJZpqUr 7ISQtI258MgAI5RGK/aZUFik/H/xDKgUFo75EqdI4U5ck9pZxPO8xONZFkeFA6ckNWlCoS3N wnUOiSvC5IvMog152aPdHbmHQotmGo05qcX2DNholD48t4znH9HijJizxDPV7w43UCO7lECz Iv1fvVWjex2oWwu223I6aATp8H+2cN0jM3GiMUI1aZNjrIUGWJVQ88AQKK18Yzzrk155XQdx JDdD6/KC+aYp3ruIfxiNLNvqIm0N2l+1AYTFx3HFniCPvolJc+prxxgy8TGFuTOtevZg1I9g hnpP5Z15lqmSTn+/pdcTAv33NLiiMPWxYo7HP2q+5jlWfdwkQH6ugz3Fu7gyX33myEE8T8vE LrjnfRhbO96YXYZAL9mdQlBouAg6dnfFEkZSZdzPQAe+5KJtCptEKeM6t87sBdMooE51Vd81 q3AAem3VDJutEJPHhrB2Dnu963FtGc9YlR8T8OAB5d6r0+z/K6CJIk9qN1I74llpY4gJNp8s By5C2HN1dU701BL+tocwRn3Pn80DikZdMn9KXf1iWcrNaP33ccBinLGzKFIk3zBESxhZiQ2C fUeBzwICQaYLnSbjf+ziwoI2xxBqdMmIrUdqg2zxFwg+V7/ORXKYkTykoBm4ixfr1offkSHr yOgiMLJO85+CAWdxsez65OGmVlbgTXeFwV15VSCi1dKuqUBmHXVM96vJRiwXv5CYvBUsuq35 peRrF5M+0xeJKvdnTqnYZpQrjiIiCQ0XgsXtqic5LQyKtcnRHkdJblTU7VJBli/IIaKWpEg6 l49SMdZaF1Aem9CDCRgnfj9xJyrgRoOHtVkkqB67HL93Pg6sP9QPuh8FBTIv2Po7c2EpmoyE yS/Do6dX6lfGBJ5qFvF7b0N/6R1AQVUWG371tRki5v3mrH92A7vsnqNmqEK8TMChDe+RxdTE D3xk5qtEpwLqDsAnkpdhAyMttd6ftbHZ11VJ1nl6JvUxGmCrd8MA0sXgcu2T7qnuL/s3aE7w SbBzMH6h775VU6xJkP5xBvEEiO6WCkgZMT6Xl1GBQeYVRLeL8XJA8vb2G2CaG96y1sxwtpLa dLscfYmd9wp2UeNnpeUf9cob3uasofAYa4lt6JYCcFMJowFtLw1xulCJFVuPqZNiDqc+fKZV jW3UD9RA1Bq0hMAccakrPoO3eeDxAY+avesX+XxxvZSfeGsUvqmj735RzGfBw3MBZUzhf1Dv ye3PxnZspQvsAp5a/g8aDtv+b2hHdFPpZXvWDMS4qBY7Es37crdWknLrfcdld1XWQLE9jRIZ 0+5n2tGZ4ewaSUzXl2JTkJ5BSbZagVE3A9wDwjOKpv8XB9mKJG1X4pU6Pr75fz9ZyxZcO89F Bbz//8RwVqmfdlS3oCVqT3U00/4yJQOQy17dMLBlyPyZxU5p8DooD8xettBQED1vwen+fodc UvYtGuD8zd9v+MbkaX9/PNdHG7DEDk9GE5WjzJRp2jUmSF2w5G1ZiONQonJvHAcLd7QCq5uQ t6M/dJR6B0icYar+lhJeOFdJKl/NIVm22f6bhPq7XpEWlMZPKfVm6AQh5SrGO59JMCMSoCye Eu4v1Nbzre6m/6+XhVHgxha4h2BTNEARw+5PBsZAeM24tRDWZwwOGpgv3uWHIkJGSCvhYZBw Sexj+/4Pvde2/bb2Z7jW/iDuMiaG6ade0JKdAuR9X9n3nUBIIzh+Atx0pZPR5s743UEv2+7z Hbyy2/v0lTN2jfKkAa6FLpNDAYgJ0/5Zl7UlCSwsHUbpVEjw29On9tsKpCF5ffZ2j01D1LAg gjLiDkUMRssdKJoT+d5IEuL/BnTYcE6SQRdciGDT3r4/PKjJw/PPLqw3X+bjpOvyTRZXRNxI NMq7hdlp9lBeaNYKUdrPBKjsMR4KORolxSCcqRxdJotYe6r+Mt0wJVGeh75mdim0lR/x8n3Y KETdRhr8/vqsidqosPJFVYNJNkYkfxtLAkmF4TSeC8wblmZwLRmuhT9SllmHSgcAYVyt55Nf YGl/VY5OhD9oMBFBFKkYeEYBuL+lelQDOppjdqFnXpFTT5eP3Rpv0VuAMgcUhtkkZGtP8izT auFTfOk6W18NekMWtKlqvx48YVH7gOkA4beitVpNAvPbnuYyi5J9+P4k3w0AaP5mEjtyh4Fo 8bQ7nfjYiuU1B/AdzVhHMnN8RZdr+xS2rA/dqoDXRNefTS4tgQOgdB/dX11byIDwy49izS6A t9HF2LffTHmGdXxymjzIH3/r8mh9mHXiEir8S7S86eG2i02v1FocPduV94GeEAFypchi8AIE g3hROgY97HjjjDsjStqNH9LjCUAu5Pyg0k3RB/WFqkeqF7Eo2E2XqaX7buTKrJxKbQ7PGfJ9 T9gGLkzHlOG101M8bSB6akmSCXC0XJYW6mc1NWMCrlRCzlF2Qd78JJUSG5QPGEVTkOv/oviW r6XfTSUTyzN0+Si+Pv5yQ5dL6axGW3XK6Mz7+VN7Kn3ZOUjbrOBrysz9QbiBaHmJ7g9IXay8 eLIu6CoUBALQ4m4qIpMSLDxDZAxwzhcKZf+fyDLruaQhSDtDgJWUNgasHAyjnZQianA+GaU/ pGJMZweQ34T198/ma8tfG0WtrAyX0jsV4mS3K+O01bezYrHBBju9BVjXejHYz+wb2il+Pq8q gb9ETyf0WHBunwktIY7xhJNhAsbqQovxDralP4YPlkLTNNB9iRezS7myX+3xjygQFJtwpQpa EE2Rue8SIt68bj/jfr6lrBCtkM6XPflcx4UvKEOlf6DnXfYpns10mT4la4Mhvi/jOetok7LD 43+LNoyM03Ou6qqwwlA+1scbXv8sY05Lrx258Iwu4j7o2UfKEPvCLuFe8KN7ZhqymbI4HvYl QW7FpicOy8hKXBymcv8HLD9HQP+QK40iCeeN9AU+mbiKa6ZzJCM7JFOfnx36wxzelf70m+2p ry6BQErYgog15xt24lOOcUlzSL+3y436DhujsnuNnEcIff2Yab/8CMGacJ4VExH94m1dolVI cWWX/z/zvMUmyfJtYz+cTuvRNzs60wjlvjo/a8mWM/wqs/MkiE6ieOwJPaYoC1Of/iBW+GWk pD250B8rviO/GqKQqgVl4mjvixyL8nqO+1svFex2oCVsS9WNQDjvF1YnAzjJGr1sK7GU7alP Dp+qZ5qZILGnLrrIWjqdsymDstU2gfMFVtit7E9D6zg9Xn8M8QnzneuJNBt/d/rhNbmxeurc zz1C0gomo198i3ITNKx4zm71coIjqdzo2Csilbmp2r3cxoMJ3kn0HNZAxOgi4tdhq/oxRVH1 xhrNL/HWJHyRuaiXmcDhw6uReRTVJyo/MxjTw4laZO9XE+C18edOTOmfwxZ0Ut+c/P44Q6Sa 73qC82hJVn8FiPYCC+CZHtu5bcX/ijFHkDPpd0mD7232YopH8lX5l2SyQkdJ982t4jUUoJNR +p0JhKae0TysDOyPm8y6GM0+ewoMud0B4tF1ZV3yKwHyIgkW9pXVgexg65al8K15uRKdc3T9 DX+uyPnrbOGlbf9nTGGsbbu/M9XYw4DfeSG/SuXJDyi4szeBrKUHBr6dTI6CUJ6bCRm1JFen XLN85KXbLd+XaSPXXpS+1AqYAW9QFtXmdXPeuwaRfc5OQ+Qvy7+XcXY65Yg+HcKdn4XJ0JsB 9PFyrMe2VoxsYR9JJFTAzHRAiJ5RdK2fBNv5FTH8MsXBLbNwSHAOqYiUBqKxi/GtJeWCTInB g3EF+mk13Zn/Nc2vPD7sHjI6gLOcDvoQbbOMBd/5LDkJxvbISDnPRD5DC90SORAgAxgUggas fKImxyLuBOvgwwBWjE0bgctOUkZO8MVSMVxUN9fIAXLSVfsRdkTeKaAdK7LJJkYyyMsJj8jp fNbTtPP0AFiScfDUyiBpfej9tGG222F6TaBj4r1QS7RspB7/wQIhajHr4tA1YYXZZ5O1etBE HP31ev8zAshBQcKdbkuTsHgdzNwXcdyD7GXEDYxURGuyW6IJsxdtHkdnguQIJPKIKPn1flQb SnfbeIwE31YU7hx0Q1OZBLqg8xRyw4S/G4MPqzH+Gd5NDS94BPN+I0P/lXj4jbddqhl/LeLM BHemlA260p48eUSjBgfRO3+1TOn8GBCLNj33nhxs40mq0SmqX+ZV/bgNqgHg/Dfv7jgr9++s V64CGbV3I8aPDtb9TLYWRLys12srvHNQjQouxrXXAzPddA5d3Z7KM+ZGveFZoY+2YJCwE63H 4RZNTzfo847fRAhjfRG2zPKOVh9de/bO7doAxiHXog2njfYzSlyaSxL1WK7IMjNNAxHz/v3N gx6rzntkkksfJUZwAWTuR3BVwe0JLM7kbh+wstRXRmigR6jKwTx2tgFAY+nme9/Yiw+Yy+XR KwllBzpcey9iZkf7IIUIHeZMXoK1VIXXiRneSCAoh7SwSCmleklozzsR0ggL5WETqS8jgQWr HR5p6qkBZ/h3dZDFdWX06147jO6RvxE/91Bd1hVqpCYb4YTlu6Skxf8ZhaOpB9E4ij1hNESg HHfzqsM05bXUh4LFzWxqRtNI7vHj44hSCTGAsG3yWZAKJqy1/mw6xOWYMr2aSkHmhv51mTsZ wVRyJ4cjZZEqrzcpDwDiX/DsLE4dyHvwyCd5el6MX2jSWe2BjAH3/PSHpoJY3KaeRflr6z1y FV4vQKz5O5YwuASmSxJLqh50Sv7UeWvZw8BrHAHnzMowsEkxZSjSk/IH0yEdjuRgVTgk7Dju IAtt6Rw44HiQZKL9PjhirK6URSo4Tdw6OHJbWYBPyUrCYT4fQ2CSBmg4rtn0c7K3NnY73UoZ +kfVpiZFHwGGeCcG63oxTCUaTN4eVBf7JW+oIH0ejwrLljBTbllnQhmOTyO3xn1g3BeM2lBo XOQXB4hjcpgyUC+ZUw9JZWwmFBkZk9vJV88jLzmpV6tBtMinQOMX8sThMm6k9GRZtQYNV08E Ts/esYPZprrGaRTSex9rxtncpHDWrcoYZI2qSCsetmX+ghakoe0DydEgiKZerkzagidU98dC ixwC2VpOeTxF+91pBt+IaP+uvcB/b3CKRSk0VfIVIffidsYBAyeKoNEuk8FTUHB3qaWiwDt5 ohFgnFLb7gqDLkw1thTVStFltrJVXrbZCbtqEyJei1Bz9rp4ErweQ+G/iz4gTjbhPs74dor0 jPtOxGXUkJ6pPXnjnizfNe0ge57LKdpk1RrsFptorSmWWIo9eKtvoKh1Gf0cRCyzgezeKZNT qqGcyyOyZaVoFizehy/KNu6TtcQt0C2X1qg10yGI9WTUUI8McchkmYCkG2s5LDjE3DNwA82Y oo4Fz/JU07TvHGhu6s3BAhtBsucDdkZNxUq/jqtASlYccS69JIdnmnOJqQHqCblIX8+jy5jw ZLQLl6NqrRskO8eFkAfiRMRQQYH8IHPEsxN+CrlBbzWPq+zhtTcBioLcsRlouz2OL37otrRA FCScwWpisJx+r3RlLrfP5hfWswDDm/fnhhoJdZ4uGmYsSHD60YYADwldAizVrRJ0bA39AbUN DCSab8S3lSFjwq8EPS7qMX2SRIiOqHkZivSg0mLoCtJlTg7ouUOjAMtKVBVhMnYEXbUbIaxC /dmGPoF9TkwNmN6TSiLIt8eTyik8wDrsxkmbLXXYYUXvAfVXcEQ1EJkufG/dg64iGsShg/5I +DlKbKsTmYcwWhopm4VKfl3Pqi/zy63IF9+kNWnmYDHSfZe5Ysdk9xrXnjGXfr2HfL+dl7z5 V3NYvwyDUEnQVAQXFHkGkwhGVv06roqywjGcriZrFaMSuwIukTxuM7bGmOSGrjvzfjwsWdiX eE6SRZZPW+jZFbJ5pWMxG6qWSRAcW/Ilz/6/eyobFwELWMaSRHYmik8LWeTZIH5p6GKe4XFQ kMwGhI4iGGmKwmNPFK3qKElVQeyoNnKEVb4pjmSxwonn+mN5KjmvOBmlMu4waCC3ebb4cuM7 gwYiFykDKE/NxVMu1kaEgtx9eHjLJZQo4/AfVoZYd/874EzzYEGNQkFBBkhpYyiz3aYG4CWD qSB4FEVJEml4MI/jcGnYH0IRpihTNMthTve1uXmSLB436WBjQlrMjrBRfUT4adj/TLSaidQE ZZxitNRP+3EHV+jimcqSuuuDqhXrWXyGhS1oYQKK8tPQ0n3P5uOAO9cLiXPf5WdAxFjdU+5p od3ybPaUkLDkhGGBjceRsyIjSMf6YqgYcE+QruvKRUyFlFW0uzV6V3ImOonNZ2rdwPfzviKt 2fZseq3RFJTPsklEGPz+lJdkuxd6Sb2pRcd1s+MGQ/lIRA3eXYkfQwoIug1Ky+x9iGE8tslR umFT2EoNK320eoTB4kcEUL/lkZUHXuLAm7dNzLMaLQhLI6Yj2tqAWlpgUP1DDR0ZFhOfXPi/ S2WvCtOzXAaWEcaktKO10BpkYtgBZ0Wqpkclya2cQdAGN8K3LrCd3Gs5QdVfpy5TKS5iguCI yt5JWZrZnK2gsL1E6Io+/70p07/BpTyZg7w5QmGuEEQwuX5qTbqsoI/9aMU9FW+Qcuqxk350 LhG4EYaLiZMy6b2UZKMv4dy0Jnsph0zsUDghjjd/+nJPBg/Dp2MAfxN6W97MXEPgOLlmqQW/ qzv0b5khtgMtO3pO3fPx54IE5s598xIA2dW5zN5GP7gBt7KEFsjNzhtIaSzzox6T7wrPahx6 7u3JMHHKoD05AGwiVeDIzK50EBj1FAlZNekqA+03n4PluIbCuO/w4UbYPDDm7D4+3B46DElG e/bIRotuAAUpSdIGVhWYwh02LU0j4o111afz2VA9gNClBecPcXicjqvHl5YoJypiNmVNm8AT s6bSNzYKXILO361PimU1EeTrkcLlmkmc/fRGOgwxtUvhPS2p5+4JkfVs6SmLl2Z/1lpbCTUv gAkBAGlcNF7jjsKS8JODIbboGIsAfyz9RFojU7Q9ENuIcopzhWZx7vu8ZE98NHIv/WfcHiIP mxLYqewSmYn6Iz1COseJSAS1PnBV/X+Q+BRGz38K8ma+nArZGgOGu5mU1k7JAhB1vgaPsuis OUMeqFfLBU0cg8Xq1EzzNgxiWHw8fmwAHUcqzFQ1nIQgJ7ZEUYEaBTHviPos0qjNS6+bBPOo h2hzKWuKaW0pDgI1h9CwFpTMXUtOVqwg+DWWnJbyWIBPPzXvFrS4/lDwCUEyQVfiTcnhBCMP yd3s639XioKbI+B79Y6USNSdvDJ8XISQnOHVQXrTt/FSufvOs2vE9pQ9qB7goCnpX/E+w0mt 6aDnrJOkuAliYcC8VqSluJN9xfYsLQr4/I2hoALQd+FaCb98PQWuU4TW+9jzvQBzLiOR43+j Lv7Y8mIj7RGk+Lhn3kDL9oInWfoNPKAFuM7sAFuBeHYa7y1iZFvqRMJ6DtZgp8SiCGQPCtKb S6wMvUW8mfmapaB8pXiAduWnVFJfFutxPUMFuApztnTh2HbJZ3cYBNKZuJRDpRQ5IabMnMrs +9Atej8eA6lirkpFNe6b2iWy/JFjPyM0PEHCO2xxA7akVrSu9aeTZ53ZDZ9qFWsUCG6eW5tr BiTt7Dw/aVeizEj3JgWI5Soq/27M/Tuf7rszYvVpPioBT2eYFDkGV5BorH25PBAhUMj649+5 8olsKdvFwekgatYByYc71htLR4xX2k/8ksp20gMIlIpJPT+sCb8xhYe9o13CKV+B7vc9dubL ekF0sHNkYoBcSTuxf4OdqGaKsqRW7jDnR1aGbxrBLm/+DJvnLQ/v9yi6gRJF6JGhvwsQpJtu 25OH8MlHw3wKQnJJKG8mUQRIRQ2tB2kmICRn8jzdGFEdkMguxR2rNzDnUhe8UZsHjQJUoswv FsZxZdixKJ7+vCo0WzDJGzfPr2N5fhKGov8HsiHqiqNz3hZObi2yfF3qpj533XgUVk/xEYg1 44NVwPMqNCm6u0erlNxuze4falu+CoacBehBoShHdu8qhbBvpiuRSkopSAvKoYACXo3iPTnB TXcmZ4K7e8HkvKtHqnVYrOPmuCG1MntmNJg/wBiEwQFJL1+IHCCLBKvkPfrTbp0We8X5oaxz hZ9UxXD7Whtk5KU75WM+ZZ12UIZ+C5kIlyarVamzkLFHeUkAlc+kIvQ0myApjy6SHe6w8Hik wbTk7uiQp4H4ZgI0KFXHtbOuHDusucIPEkcBl+mTmjwMy6Mcqc0CfMYMmSvqpQp1ysj0WU4e BUZT1ps6iZxOV3fkzWbZw8PAsSRjTDFVJpNKMoN4g/Vn11MgQPJld+2xgfAVFNa/TYQLL3NE QTHM3fuPyCy0Yr6XLIGapUw/6hJDbqWrxWdDDF29u3YZIQXGMBT6kHpY7uastALmkOTngMhY nuTKpUpVZiYAQeWkuIcrkePR+DXkZwZShQAHvJGVerO7SuO+ikOlR6rFT/uImGe3rNB0j4Rc xU8pyHs/A4TTHMiXu4+Rg6ctMlqs8XW2giyjUQ4NncIv5tmnIgOcOhZk4eBIqlGfjR+Bg0N8 YQ9NuKHYEW3vnyewPPZQhI2m1L44jN3wpT96UaHXUvoguWTJrzZ6AFq6ZA6VYa/vGWVe4Xp/ I6p1yCx+/6AOs2jQkIJG0OusfzZG+BlUmqLvGVfZZblwnjbAGQZMcAvQ1gaAqcq7u8TVkTtR Ut5QlJT+ce5Itjr7H1iG/UMf3dq5Xr8Z4xY1fhfCAvzkbHodK9YdRW5f+ppbyynt2hX4EkGs aAWa4HIFXhDk2/xw/XhJ0RVe3YhRLV0oAJeaOSVjZeODD6fDLI3so270SMcyxkr4WWj2kf/+ X/dleFUg7KyOdpc0r7dJxz22/PPpuV9wEjCf/72z1CW2UCpbgFl3/7iKQaeisxq4hY9/IO2L oa5BTQOzH6N4x8XuaZRvICjueR2K5pCljN+4WQnt05nGn6E9W5MjPCbidmcSfNreXeaqmixB uddfCTtzVOcfRyxqbIjvfqPa4hClmVoOjhMGfOFPW4naodzUTAl0nuqKLBUTtjzOKhVeQ4mc 0QLPGlp0vS9qLIM1bgl3OEgUySn64eSLvGywv4vyIWd/lRjdo84k9OYJ5iSHYcZh+sZ629r6 20OPMiv+Wo7ZK6Zs6OpNI1VVK7xhTzLWFYIoozQLfZJdiaU1i6ZTKOFd3KmkmAgRzAbnXla+ uprDecKUmLQ0nkmRph0YsboqkDLMvzBOpcx9x25c8HjOWdwmOeRJr2YKEeVMPgGbDCjF31J2 sT4e3DI8pJ2ZYLHLKKaxpmhQFXcWNJMxyOFEO8d/G6rR6DYrmHcq6+iDyagZejbMys1UDYeW DQ4bvG84dhD09WSjF0x4h0bzvvFFlfU1jL1KiNrv1Ki5FpCPXert6AMIFCT13ZAal6ALVnMa GWW8Y7850m/FLrZp7dZk+o2U4nd9OlYYIS4MyFCNk+JhTew+VvzPqwvEjKL5ykE12t8cFXEU re+g7TX1LY30PX7jV5XyF8W52sJOfYDzOTt+9aVfyS+qL1PzoW3glfB9mCA+tBnOvgY3Mzmy Km1uxVMNse6a5uiK5wtP8CQ+cFC5LDhR23OGye6m0yNOQXRwLkoFo5cQzGW3EqzU22g8WfaH uGLN0aQebzVV0U5atoran3Ah6JdtI0ABZhhBNuCdVcA85aP4shHwYWP8OnFkbZJK0o/tD3Dg TXQKxDZ+B7BPP1ywtpd9JISqYISAfx86GXgKdhAnU/f4k29q7vBmknLeuS5MxQVUv5B2g8SY xTysxmqetZlK5eVJ+hBcX47BXLNm1yy71Gux2p8coPtpBAvirQ8PWRYuglbKn9kuVTeliwK7 cgVZLI+Vri4PcDSyybAkEWciO5L4TRpWBfT2TIGd2HJynY1Sie89jGfzSqjWAEtuujdns7QK s4U7edB6NXJvMbGT2KfAQcm6kldBbyYP/gh6rvLLpXNvrx9IGVuaMtfWwPG7lggkm/9yhnLZ s3iMnm7M4G92dgv1VsqKWPiC2q7e/zwr0vnkj0xpW5+ttj0Nk/nGKPMy3H4Yyfo+aYx06L13 +ZhKNGq2i6iq5UuIaXCumRja79IHFzEWo/Ti+LDlOb8RKIXtjeOubaA8IR4gKa/9wrTJxggA GXUAkd5HbkpLU1GqUR4NCIvhbL3TNOJuj/rL3MpZ3dOA+WS0LfSQ+qr3qZUv3xUKPJf6K4Uy 4vV0a5xYlNYslj8kcAzoucptnszoiFrIz/AR6hHDki5J2AiHW52kXmzSis6E4B4XYRpIK/tM S0V8LrIlfTXgnJzEbjKKLoh9mfHpniEQJ+uOqjLVKAktU8eyruZ/Nb4OH9+QQp1yd7/qcJfs Ytg4Tdeza49AeJ9+86J55P/5SwW2BEvQBuqb+u+u8iibbweXnpIyFKZVcu5VVevVDlXKdaHj qQMBTSqaMO7bFeNzDfxJj2LwWwzJ7m+FmM8QSSZC2t5Z93CQBVgbLRmz0ETdniROuuWfFcw7 X1gAN51mnIMbT/89glSLyr7Uc2O/CNau8cPjSplUGbuPllNvhu5z6zSKsj433DHjMg6aOv1S V1Id/4xLH5t0cZqThdX2xyh84stN1nsf444F9B/SaVZuRCfhfNk+4A2lNuP55BIHrUnQhuwC sYGwVSn66fgQbC8vvAHBME49/Wvj6HJMeq7SlnuyNHO6gHpkY6cZIxVsOk/of1L9h71S3cTt cRteP3V3pH2my1bJKv82qHVWI6FPUvHaiHW/YGLE7J9lzcpcESeHWAoapx6mETTX52tL8FfQ O+hFc1IYALLC46orlo3u0D7rsVR9X0NwrqigL7VI/X724UDetzpTZlx/9ZcCwjOmd0lNdJUn oRU1zS0A/M8MPBdz6wL45qjMT4ifA1AkwVTPcZ6uPRtEERC41epprPxgTI/iKJSlYRqG5eg0 UJf5Y4onuF1xfsIK4ryoAdznxJtud7rSLhbJvzp0q938/pvRz6hU3FrEWJRVoYdRsmDiP3q9 OjhSFvAWXeDHcpHPCQi6KBq1YavSggvf6Rjm4UTeo8YkmE0O4mKFuAVC8B/PTLxcRiZscUmU svxQwjDHlEnQOmQgShsOrdcAX1E2fy8gaNxinkFhJNU8ixmqxKMBu1z3vETaBtb/7NPQ2ZMK zSiiltT6cVj4m6e5zwAdo0DpzGYwN6wye1E+seew9zoPSQOy6NUeR6ohElUWDheOlGnnkRxK VawX1XenrOgWqeHdob0HS2ridwvrMP58bOAUiwlAlhMT4wOgLzmFK4siARHFbpW8nDrJlS6W SXFd4TRmVNu2mLkRnEOkQAvk9KFq/D/MuYT/THRFdpl7y3mhW9WdDk4ZAEHP4tFCmM8v7YPF T3n649zqZiyRNMwYuqvD4fFjjP8eItjVzAg3sv+MaD2VpYBEAoKllaY0HrO4HbkacQK9IEnb qtBp+tMk89C7zOGGhXB84R6WRumKGxNTy7eY+zpF6M2S2Szre5GXZ04zAGqyhdZGcUqDlRy1 tVajNWOt2m31cIUzkNW+dIvLvQxlxOQB5U7w1/Skczi/bfzaZnnvs8ZHxoid82EzBXFoCuSX pL8K94axNaeGVMfcdCGerfobVWOXiPh3fNEi+roOlhddwe4cI+x5xjkjz1wuzGSZXBz1JujG Ug1ticu3DVGTgD4UoCrFJt557HgH9c6NROecVfJ5/upYXVvIo9XWXhLugVNLjhmbUjDMBEZQ ySoZg5dxTzzZYMH67ReoeGPX0xwHxi4GXF9EmxLGyH2VlO1q4Ncs+w4/7gXvLCsaqlJ+Hrgm g1sty7FMM5hYqnKfqY7NGTb4v7KVFmYGuXgwl+jXgoQ7cHIjcJqVgFYlBOWQ633ZCMC6CA5S 4xZwU4B7laIHjj200NPL68wqXZGV7/hl13iVhJQjx+Gn3eax7vt1v+klHFHcS0X1Xpg65oZk +aFMOvpibbNcosK8LSp2QAjpNi0WwrbaA7K53Yi1gZO5qK4e0K6wPfDEq7ow1Zm8x5qv6MBK 4thGok6r1qz2eArLb6DKs8JViSXCoElOurK69tKic1lHh496Xujwd5yWiS+CJDgUmM2+iTt1 whnC+W4bVyWvhstM0Vo1eVxaPal4wRxAeGG3vxe6Y9kZ/2NJXoPtZB4PFxwDSDlmmeijeI5B qoozc7Z4OmER9C5zI2R8G0z3j1/8/XzFRbZzKpBZyvlEDafk6ruv16Rw82OrSlQmeuBfZPnY UKdGInunHFhG3/rHo9TXy8OXSe1vgJMcXexXmcJV51jVfeKR7B2jmt3z4Q0fATV1HRFmMkZR cSMvFZZQi/3pfz0tj4yJeXBCT92ASi9JQGLXnDoCKoFC+WNWc9H8jiNmd5uF0epACK1cRtti mBtUro/BQbt2GDqjLXzxb/TFZQwZu133jPkO7NLsnADoxoahm9lsK8yKDmqyxM1GvaddY1BN vxQCAZFxgNf2PTqOAqIOcUL6suQAdOjUC6lc/EB0PtfhGmkBLZ+vyf6VRhRsXDHGYf1bFXU6 q/Mx6i2LoXTQ/YFk0bvwJGzkS5kaheu46dR19FQDnbVRHmxO6UwzR792NH4TpP1/IuiAy3T4 OqC1vMwVJswaDhB+wW7G3uBqdoi/1+SXWTepdlVGKwe32aUzEu085jEy1EdiSgroLRZ/+E1Y SasKGvsy0MTMcXJkb+IWdFSKq2tsjKLvntxC73ez3bURCbEueGKZzSE0y9ugbUp5y69z1Chi r1Zy6Gl6kDK7g6fqs27EExo3Gtvla1+r915rJxdiBkbmprnNZCxUo9FO8k1XhDGiJmyHh/kp ZQ35NeemRBZOzhzElPaBNjr5+SJ40ibIDw0IBmYVticdHvbBRdjyz3KQkeycP0pnVkFRv4Nt L5QXpS0rNfRVFz8nma2j6NX95EEbb47lqkqeXJRDKqWWIqqZF721xv5GSdRcnzUf6RjD70nb WKTzV9b7JC3VL2wg8+YcgJG9Ni1MpuTush7FgaYLxfCOPXpZAXeJgkTytv1F1XZxe537CXSD M9T9Pu5YlJHpjmxNHn7nPXofZNdqX3vtdXmzOALEOxT2oXwIJgSY9J2CxDQD7sg7ACZjECzz 4uNJ8WWGpoOhFr6I76dTXIIQ2n2Pdz2TorBsoi4xCLv/XZUo1Lble8oTjyka0mdVebofTgUN 79TQm/KDSZuQgaOod4ahXUmqTvYW8sbXsDFC5iPLZxgQlJZwonAdKouocEUQ809OIUgcezib 2WastqBvr9gXgW3AnVQrY79LDxvTQUxU85lVo6MnvSG7ul4UNcjvoWV/GTZ4+iOR3bsxe4cZ +vd88/U5WhcuS0u3X3/en/WX3JNYv4LDIT8nAxcIeXOZ7SJZ6TC3Hz70DLamSWBb195TzHUZ bHFNUdhKUp0N1gaNF+bx/b8kKJep27YujtkrnR3/Mr/78mN2lCHZ61be50nsX7/mWcXEQ5un UJqshb4lVhHR+DOkAhzK3+0Wmm/KNJeVeZwkulJVlOgyNC27wHycWQL6jFffG+VEwoMsYvlm nmqF4tXOP527yDQINjuAhZ/yF2seCDU/QmorXDF10XXEuxOojC4vTB1aJ8zQW05Yad9ns+fy WEV3TcsD6it1fZjeyN6HhIUpoJnV6YVXbZRVpVHIxJdBeWPEHUgNGn8qUYe4P9fj0MA8XUqp hncEgDvYzU67qKaQ8yA3YFnWFRKM/orq5/OSpfXjm8LqEL8ZQmsUV7uGh2bbcyuYtsPG+Cif 5XDFcQJ7ligQk26Dz6UXCZtBx1IlvAc6XsGKpldRcnxwK3MrRipyP9u6HoKhcrJn/AuIcqYH JtqimTw4qkUGmv09MkMJS0mSfou2JDLEBFBUaKdKc2aPkP/SIiCFPtTXMzOxDm5aK75UTwDi kPjpoPzssm9/8sr4jt3X7jLbn81UOTUWr8UWmb2vejRlnFVK+5sTHPtsnLd4CXQZfx2HOKK/ 4F4BHt/lvD442vDA7QPCuSs4bDDEZUuOJ6wm+iBcR4re1CKlI0bw8KlMYvOkgdhKjlWdV4c3 1I5WclaNWfullestbRvEFrVWQt3hND6gR6kRkkRIZWDtHjpKy0L6w4AjhAxplPRibk0wt0+a hXpSwD4WUa5MfHLkGHMAscGUtmnCoHpQzQlFck+luHHEdpIsf9A23fWwxFCnfQU9y9KZBYHV Irb0wOkas5m/FZX8XF81wVTP1hfPThy98jjeON70+PdxDGTHOguo6jBho0qgdE+cook2m0Yu ksdqBnEs2ixb1AdXT7/+I95VClk8HEz1AySSFH0b4ku6yeHI8OVqWDd4NDyKbiR4S80rE1Nf 2NQHrIl4bh6M5WudDfy8ch/PyO0tHPl+0A25HqJpgyIGHgV8lJHx7nDcpAaNHaDRChfLfZvm rBkq6klPTcGeH1TxT1x+DotDcMVRTNDvdIwIDUPJjY8vg/HELTVZthttFN+ADnCkD2wlPGPS SYG/G0NhmskNPM4/Q2RltRiDiHQb5T3V9Vc+971TQt/4yiXwqEsEe+n8oQiAkFJ+grMXK1ly wx6NYabnzA5VtJQk7Ueq0PSEyF/PGc1VSpWJIAH7ZdNmSchTMPekvycA9BG9fRCxf3cx/N+b 3ogojIYB4bSLM6xRyNjLMq3OGs7UT9hv/lAnSuxq4OOl94bp3eQLTmwanaSDrfst9IHlESu7 pLYgnNbwujvfVRfBzSjbgOcVUcww20R8LuDbUYZrRLo4t4qvjUrfOITk7gHhtPo1zTQ0i6oI PUCQN4XkmEHOy4w02wleBBwd12R3dX99guBBrIrPOSDIuaT0V4BTiaa4EcxdIIkaSpYrOft/ 2PGnX+n/eGWWtyjalHblFvyXmjFpcrk1ysplrHo69yWm/Zd7up9N4PbErVj15i/YZmWaTrRo MkXK0QcJGFi8o7iqe3fpv2fjGaax5u6I+1SAyDn3tocdfF4v04zI3sb4xkljoMrxndbe5IvU caR+Q5xFoVTJXK57+Z+SNyzOz4ardh3duuM6pBnX8uNQ2dCJDFYER92/y31WAaZKsStKzRV5 z0cyKiXMaG8GZNpm74fqYLzRiAcBWEw4jQ1lbmRzdHJlYW0NZW5kb2JqDTMgMCBvYmoNPDwN L1R5cGUgL1BhZ2UNL1BhcmVudCAxMiAwIFINL1Jlc291cmNlcyA1IDAgUg0vQ29udGVudHMg NCAwIFINPj4NZW5kb2JqDTEzIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMTIgMCBS DS9SZXNvdXJjZXMgMTUgMCBSDS9Db250ZW50cyAxNCAwIFINPj4NZW5kb2JqDTE2IDAgb2Jq DTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMTIgMCBSDS9SZXNvdXJjZXMgMTggMCBSDS9Db250 ZW50cyAxNyAwIFINPj4NZW5kb2JqDTE5IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQg MTIgMCBSDS9SZXNvdXJjZXMgMjEgMCBSDS9Db250ZW50cyAyMCAwIFINPj4NZW5kb2JqDTI0 IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMTIgMCBSDS9SZXNvdXJjZXMgMjYgMCBS DS9Db250ZW50cyAyNSAwIFINPj4NZW5kb2JqDTI3IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9Q YXJlbnQgMTIgMCBSDS9SZXNvdXJjZXMgMjkgMCBSDS9Db250ZW50cyAyOCAwIFINPj4NZW5k b2JqDTMwIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMzQgMCBSDS9SZXNvdXJjZXMg MzIgMCBSDS9Db250ZW50cyAzMSAwIFINPj4NZW5kb2JqDTM1IDAgb2JqDTw8DS9UeXBlIC9Q YWdlDS9QYXJlbnQgMzQgMCBSDS9SZXNvdXJjZXMgMzcgMCBSDS9Db250ZW50cyAzNiAwIFIN Pj4NZW5kb2JqDTM4IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMzQgMCBSDS9SZXNv dXJjZXMgNDAgMCBSDS9Db250ZW50cyAzOSAwIFINPj4NZW5kb2JqDTQyIDAgb2JqDTw8DS9U eXBlIC9QYWdlDS9QYXJlbnQgMzQgMCBSDS9SZXNvdXJjZXMgNDQgMCBSDS9Db250ZW50cyA0 MyAwIFINPj4NZW5kb2JqDTQ1IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMzQgMCBS DS9SZXNvdXJjZXMgNDcgMCBSDS9Db250ZW50cyA0NiAwIFINPj4NZW5kb2JqDTQ4IDAgb2Jq DTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgMzQgMCBSDS9SZXNvdXJjZXMgNTAgMCBSDS9Db250 ZW50cyA0OSAwIFINPj4NZW5kb2JqDTUxIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQg NTQgMCBSDS9SZXNvdXJjZXMgNTMgMCBSDS9Db250ZW50cyA1MiAwIFINPj4NZW5kb2JqDTU1 IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNTQgMCBSDS9SZXNvdXJjZXMgNTcgMCBS DS9Db250ZW50cyA1NiAwIFINPj4NZW5kb2JqDTU4IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9Q YXJlbnQgNTQgMCBSDS9SZXNvdXJjZXMgNjAgMCBSDS9Db250ZW50cyA1OSAwIFINPj4NZW5k b2JqDTYxIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNTQgMCBSDS9SZXNvdXJjZXMg NjMgMCBSDS9Db250ZW50cyA2MiAwIFINPj4NZW5kb2JqDTEyIDAgb2JqDTw8DS9UeXBlIC9Q YWdlcw0vS2lkcyBbMyAwIFIgMTMgMCBSIDE2IDAgUiAxOSAwIFIgMjQgMCBSIDI3IDAgUiBd DS9Db3VudCA2DS9QYXJlbnQgMzMgMCBSDT4+DWVuZG9iag0zNCAwIG9iag08PA0vVHlwZSAv UGFnZXMNL0tpZHMgWzMwIDAgUiAzNSAwIFIgMzggMCBSIDQyIDAgUiA0NSAwIFIgNDggMCBS IF0NL0NvdW50IDYNL1BhcmVudCAzMyAwIFINPj4NZW5kb2JqDTU0IDAgb2JqDTw8DS9UeXBl IC9QYWdlcw0vS2lkcyBbNTEgMCBSIDU1IDAgUiA1OCAwIFIgNjEgMCBSIF0NL0NvdW50IDQN L1BhcmVudCAzMyAwIFINPj4NZW5kb2JqDTMzIDAgb2JqDTw8DS9UeXBlIC9QYWdlcw0vS2lk cyBbMTIgMCBSIDM0IDAgUiA1NCAwIFIgXQ0vQ291bnQgMTYNL01lZGlhQm94IFswIDAgNjEy IDc5MiBdDT4+DWVuZG9iag04MyAwIG9iag08PA0vVHlwZSAvQ2F0YWxvZw0vUGFnZXMgMzMg MCBSDT4+DWVuZG9iag14cmVmDTAgODQNMDAwMDAwMDAwMCA2NTUzNSBmIA0wMDAwMDAwMDE2 IDAwMDAwIG4gDTAwMDAwMDAxNzIgMDAwMDAgbiANMDAwMDM1MzIwMyAwMDAwMCBuIA0wMDAw MDAwMzczIDAwMDAwIG4gDTAwMDAwMTMzMjkgMDAwMDAgbiANMDAwMDExNjA1OSAwMDAwMCBu IA0wMDAwMTE3MTA0IDAwMDAwIG4gDTAwMDAxMTgyMjkgMDAwMDAgbiANMDAwMDExODMzMiAw MDAwMCBuIA0wMDAwMTE5Mzc3IDAwMDAwIG4gDTAwMDAxMjA0MjggMDAwMDAgbiANMDAwMDM1 NDU0NCAwMDAwMCBuIA0wMDAwMzUzMjg0IDAwMDAwIG4gDTAwMDAwMTM0ODQgMDAwMDAgbiAN MDAwMDAxODUyMCAwMDAwMCBuIA0wMDAwMzUzMzY4IDAwMDAwIG4gDTAwMDAwMTg2NDMgMDAw MDAgbiANMDAwMDAyNTE5NiAwMDAwMCBuIA0wMDAwMzUzNDUyIDAwMDAwIG4gDTAwMDAwMjUz MTkgMDAwMDAgbiANMDAwMDAzMzM1MiAwMDAwMCBuIA0wMDAwMTE4MTUxIDAwMDAwIG4gDTAw MDAxMjE0NzAgMDAwMDAgbiANMDAwMDM1MzUzNiAwMDAwMCBuIA0wMDAwMDMzNTA4IDAwMDAw IG4gDTAwMDAwMzk0OTEgMDAwMDAgbiANMDAwMDM1MzYyMCAwMDAwMCBuIA0wMDAwMDM5NjQ3 IDAwMDAwIG4gDTAwMDAwNDY2NDIgMDAwMDAgbiANMDAwMDM1MzcwNCAwMDAwMCBuIA0wMDAw MDQ2NzY1IDAwMDAwIG4gDTAwMDAwNTI3MDUgMDAwMDAgbiANMDAwMDM1NDg1OSAwMDAwMCBu IA0wMDAwMzU0NjUzIDAwMDAwIG4gDTAwMDAzNTM3ODggMDAwMDAgbiANMDAwMDA1Mjg0MCAw MDAwMCBuIA0wMDAwMDU5MjU5IDAwMDAwIG4gDTAwMDAzNTM4NzIgMDAwMDAgbiANMDAwMDA1 OTQwMyAwMDAwMCBuIA0wMDAwMDY3NTA1IDAwMDAwIG4gDTAwMDAxMjE1NjcgMDAwMDAgbiAN MDAwMDM1Mzk1NiAwMDAwMCBuIA0wMDAwMDY3NjYxIDAwMDAwIG4gDTAwMDAwNzUxMjEgMDAw MDAgbiANMDAwMDM1NDA0MCAwMDAwMCBuIA0wMDAwMDc1Mjc3IDAwMDAwIG4gDTAwMDAwODE5 NzMgMDAwMDAgbiANMDAwMDM1NDEyNCAwMDAwMCBuIA0wMDAwMDgyMTA3IDAwMDAwIG4gDTAw MDAwODc2ODMgMDAwMDAgbiANMDAwMDM1NDIwOCAwMDAwMCBuIA0wMDAwMDg3ODA2IDAwMDAw IG4gDTAwMDAwOTMwMDYgMDAwMDAgbiANMDAwMDM1NDc2MyAwMDAwMCBuIA0wMDAwMzU0Mjky IDAwMDAwIG4gDTAwMDAwOTMxMzkgMDAwMDAgbiANMDAwMDA5ODUyNiAwMDAwMCBuIA0wMDAw MzU0Mzc2IDAwMDAwIG4gDTAwMDAwOTg2NjEgMDAwMDAgbiANMDAwMDEwNDg4MCAwMDAwMCBu IA0wMDAwMzU0NDYwIDAwMDAwIG4gDTAwMDAxMDUwMTUgMDAwMDAgbiANMDAwMDExNTgwMyAw MDAwMCBuIA0wMDAwMTE1OTYxIDAwMDAwIG4gDTAwMDAxMjI2NjUgMDAwMDAgbiANMDAwMDEy MzcxNiAwMDAwMCBuIA0wMDAwMTIzODIwIDAwMDAwIG4gDTAwMDAxMjYzNTUgMDAwMDAgbiAN MDAwMDE2Nzk4MiAwMDAwMCBuIA0wMDAwMTI1MDI0IDAwMDAwIG4gDTAwMDAxOTQzMTAgMDAw MDAgbiANMDAwMDIzNzY2NSAwMDAwMCBuIA0wMDAwMjgwODc3IDAwMDAwIG4gDTAwMDAzMjI0 MTAgMDAwMDAgbiANMDAwMDMyODczNSAwMDAwMCBuIA0wMDAwMTI2NTY0IDAwMDAwIG4gDTAw MDAxNjgxOTMgMDAwMDAgbiANMDAwMDE5NDUyMCAwMDAwMCBuIA0wMDAwMjM3ODgxIDAwMDAw IG4gDTAwMDAyODEwNzkgMDAwMDAgbiANMDAwMDMyMjY3NiAwMDAwMCBuIA0wMDAwMzI4OTQ3 IDAwMDAwIG4gDTAwMDAzNTQ5NTkgMDAwMDAgbiANdHJhaWxlcg08PA0vU2l6ZSA4NA0vUm9v dCA4MyAwIFINL0luZm8gMiAwIFINL0lEIFs8M2YzODVjZTdjZGE0ZjhiMDc4YjEwNTdiMjJl MzVlYzY+PDNmMzg1Y2U3Y2RhNGY4YjA3OGIxMDU3YjIyZTM1ZWM2Pl0NPj4Nc3RhcnR4cmVm DTM1NTAxMA0lJUVPRg0= --------------C8515E6EAC751FF5702124B6-- Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24292 for ; Thu, 22 Jun 2000 11:13:13 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5MI59g18905 for ; Thu, 22 Jun 2000 11:05:10 -0700 (PDT) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FWKILJ00.CG3; Thu, 22 Jun 2000 11:12:55 -0700 Message-ID: <39525726.5D23F3CC@netscape.com> Date: Thu, 22 Jun 2000 11:12:54 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Halliden CC: "'Paul Koning'" , seidel@timeproof.de, FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <61922E6DA745D311A42000508B2CFD14B96779@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul, Addressing the first point in your message (a client submitting a "cooked" MD5 hash for timestamping), there are two points to make: 1. Finding collisions in MD5 is still hard, and finding meaningful ones much harder. 2. It is not the concern of the TSA whether the client has chosen a form of message imprint that will hold up under a challenge. The TSA's function is to associate a timestamp with the message imprint, no more. Whether that message imprint can be used later to convince a third party that a particular document was reference is more important to the client. The client should choose an imprint algorithm that will meet their requirements. Addressing the second point (getting the TSA to generate a colliding time stamp token): 1. Again, it is difficult to find meaningful collisions. 2. The TSA is concern in this case, since a collision could result it a token that indicates a different timestamp (probably an earlier one). 3. The TSA should choose a strong signature algorithm that will provide the appropriate level of assurance for the required time period. I suspect that many TSAs will choose a signature based on SHA for this reason. They will also choose key lengths depending on the desired security level. 4. Since a large part of the timestamp token is fixed or guessable, t is probably worth including a "nonce" value in the generated signature to make it difficult to force the TSA into generating a colliding signature. This value can easily be incorporated into the CMS SignedData object as a signed attribute. Terry Hayes Netscape Communications Corp. Paul Halliden wrote: > There were two potential issues with MD5. The first one was an indication > that, at the time MD4 was "broken", MD5 was expected to fall to a similar > attack "in the near future". That has not happened so far. We do not know > if that is because the task was too hard or if it was simply that no-one has > got round to trying. But it was the reason that many stopped using MD5 at > that time. > > The second potential issue concerns the size of an MD5 hash, which is > shorter than an SHA-1 hash. If an end entity is able to create two messages > that have the same value of hash, he can submit the hash to the TSA and then > subsequently claim that either of the messages existed. When challenged, the > end entity presents whichever version of the message best suits his argument > - an adjudicator would not be able to tell which was the genuine one. Whilst > this task is far from trivial for a 128-bit hash such as MD5, I believe it > is the same order of magnitude as finding a 64-bit symmetric key by > exhaustive search. (IANAC - so any cryptographer / mathematician please feel > free to correct me). > > This potential attack is, IMHO, more significant for a TSA where one entity > chooses the message and generates the hash and a second entity signs it (as > part of the timestamp). > > Regards > Paul Halliden > > >-----Original Message----- > >From: Paul Koning [mailto:pkoning@xedia.com] > >Sent: 19 June 2000 16:00 > >To: seidel@timeproof.de > >Cc: FRousseau@chrysalis-its.com; Denis.Pinkas@bull.net; > >ietf-pkix@imc.org > >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt > > > > > >>>>>> "Joerg" == Joerg Seidel writes: > > > > Joerg> Comments inline. > > >> TSA implementations MUST support SHA-1. TSA implementations > > >> SHOULD support MD5. > > > > Joerg> I think there are good reasons not to use MD5 in time > > Joerg> stamps. They should use a strong hash function in order to > > Joerg> achive long validity periods. MD5 is likely to be unsafe (=not > > Joerg> collision free) soon and is already discuraged by german > > Joerg> authorities. > > > > Joerg> IF we add a section about algorithms, it should maybe read: > > Joerg> "TSA implementations MUST support SHA-1. TSA implementations > > Joerg> SHOULD NOT support MD5.". But I think such a section is not > > Joerg> very necessary. > > > >IANAC, but from what I understand the currently known attacks on MD5 > >are nowhere near strong enough to justify that. > > > >I don't have a problem with the current text (SHA-1 required, MD5 > >recommended). I do have a problem with text that implies that MD5 is > >bad, because I don't know of data that supports such an assertion. > > > >Also, it doesn't seem like a good idea for the timestamp spec to give > >very different signals from the other security specs. If there really > >is good reason to say these kinds of things about MD5, let's have them > >identified. (German authorities are not a good reason. Cryptanalysis > >that shows weaknesses of interesting size would be.) If the issues > >are real, changes to MD5 text should be applied across the board. > > > > paul > > Received: from windoze.tenebras.com (windoze.tenebras.com [216.15.43.196]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23525 for ; Thu, 22 Jun 2000 10:44:31 -0700 (PDT) Received: from dnai.com (localhost [127.0.0.1]) by windoze.tenebras.com (8.9.3/8.9.3) with ESMTP id KAA24292; Thu, 22 Jun 2000 10:43:19 -0700 (PDT) (envelope-from kudzu@dnai.com) Sender: kudzu@windoze.tenebras.com Message-ID: <39525036.A930020E@dnai.com> Date: Thu, 22 Jun 2000 10:43:18 -0700 From: Michael Sierchio X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: fr, en MIME-Version: 1.0 To: Paul Halliden CC: "'Paul Koning'" , seidel@timeproof.de, FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <61922E6DA745D311A42000508B2CFD14B96779@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul Halliden wrote: > > There were two potential issues with MD5. A potential issue is not an issue... > ...If an end entity is able to create two messages > that have the same value of hash, he can submit the hash to the TSA and then > subsequently claim that either of the messages existed. > ...(IANAC - so any cryptographer / mathematician please feel > free to correct me). The difficulty of finding any two messages that have the same MD5 hash is enormous. But consider that if both such messages are to be meaningful it is quite another order of difficulty (greater, if it isn't obvious). There is still no mechanism for creating a message which has a given MD5 hash value... Received: from stonewall.baltimore.com (mailhost.baltimore.com [195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA22941 for ; Thu, 22 Jun 2000 10:15:49 -0700 (PDT) Message-ID: <61922E6DA745D311A42000508B2CFD14B96779@baltimore.com> From: Paul Halliden To: "'Paul Koning'" , seidel@timeproof.de Cc: FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt Date: Thu, 22 Jun 2000 18:16:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" There were two potential issues with MD5. The first one was an indication that, at the time MD4 was "broken", MD5 was expected to fall to a similar attack "in the near future". That has not happened so far. We do not know if that is because the task was too hard or if it was simply that no-one has got round to trying. But it was the reason that many stopped using MD5 at that time. The second potential issue concerns the size of an MD5 hash, which is shorter than an SHA-1 hash. If an end entity is able to create two messages that have the same value of hash, he can submit the hash to the TSA and then subsequently claim that either of the messages existed. When challenged, the end entity presents whichever version of the message best suits his argument - an adjudicator would not be able to tell which was the genuine one. Whilst this task is far from trivial for a 128-bit hash such as MD5, I believe it is the same order of magnitude as finding a 64-bit symmetric key by exhaustive search. (IANAC - so any cryptographer / mathematician please feel free to correct me). This potential attack is, IMHO, more significant for a TSA where one entity chooses the message and generates the hash and a second entity signs it (as part of the timestamp). Regards Paul Halliden >-----Original Message----- >From: Paul Koning [mailto:pkoning@xedia.com] >Sent: 19 June 2000 16:00 >To: seidel@timeproof.de >Cc: FRousseau@chrysalis-its.com; Denis.Pinkas@bull.net; >ietf-pkix@imc.org >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt > > >>>>>> "Joerg" == Joerg Seidel writes: > > Joerg> Comments inline. > >> TSA implementations MUST support SHA-1. TSA implementations > >> SHOULD support MD5. > > Joerg> I think there are good reasons not to use MD5 in time > Joerg> stamps. They should use a strong hash function in order to > Joerg> achive long validity periods. MD5 is likely to be unsafe (=not > Joerg> collision free) soon and is already discuraged by german > Joerg> authorities. > > Joerg> IF we add a section about algorithms, it should maybe read: > Joerg> "TSA implementations MUST support SHA-1. TSA implementations > Joerg> SHOULD NOT support MD5.". But I think such a section is not > Joerg> very necessary. > >IANAC, but from what I understand the currently known attacks on MD5 >are nowhere near strong enough to justify that. > >I don't have a problem with the current text (SHA-1 required, MD5 >recommended). I do have a problem with text that implies that MD5 is >bad, because I don't know of data that supports such an assertion. > >Also, it doesn't seem like a good idea for the timestamp spec to give >very different signals from the other security specs. If there really >is good reason to say these kinds of things about MD5, let's have them >identified. (German authorities are not a good reason. Cryptanalysis >that shows weaknesses of interesting size would be.) If the issues >are real, changes to MD5 text should be applied across the board. > > paul > Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22760 for ; Thu, 22 Jun 2000 10:13:19 -0700 (PDT) Received: from [207.215.85.136] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWK00CM5FLZ9R@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 22 Jun 2000 10:08:23 -0700 (PDT) Date: Thu, 22 Jun 2000 10:09:12 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <395234B0.D4546882@caveosystems.com> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Rich Salz wrote: >> I'm not sure I understand your statement of having "*less* to trust". > > Sorry, poorly worded. > > If I trust the CA that certifies a TSA, then aren't I (by default, and > certainly by philosophy) trusting EVERY certificate that CA issues? > Why should I have to? You shouldn't have to, although this is the model that most public CAs seem to push and/or encourage. As I mentioned, a possible solution is the the use of "anchor certificates". Regards, Aram Perez Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22410 for ; Thu, 22 Jun 2000 10:05:35 -0700 (PDT) Received: from [207.215.85.136] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWK00F0CFFAAC@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 22 Jun 2000 10:04:23 -0700 (PDT) Date: Thu, 22 Jun 2000 10:05:12 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Stephen Kent wrote: > Folks, > > I support Denis's original restriction on the uses of a TSA private > key. It is desirable to constrain the use of a private key to avoid > possible errors in its use. It seems that we have gone down a thread > that focuses on certificates for a TSA, more than on the original key > usage restriction. > > I've always asserted that self-signed certs are just a syntactic > convenience, not a generally useful way of ensuring security for > transmitted public keys. If we agree on that point, then I don't see > a lot of reason to push for self-signed TSA certs. A TSA is not a > CA. Even if the same organization happens to operate both a CA > function and a TSA function, it seems appropriate to separate these > functions. That's part of why we have the proposed constraint for > using the TSA private key only for signing TSA responses. It was > suggested that this is not consistent with the use of POP. True, but > only in so far as the POP in question is the one defined in our > automated registration protocols. Thus is not the only game in town, > and for a TSA it is reasonable to anticipate other mechanisms that > provide POP, but not via those protocols. So, I don't think that the > POP argument is a good basis for rejecting the key usage restriction. > > The "less to trust" argument that Michael makes does have some merit, > but as Aram points out, a self-signed cert required some > integrity/authenticity secure, OOB means for its delivery, which is > why we try to minimize the use of such certs. It seems hard enough > to do this for CAs, without adding TSAs to the list. Let's assume > that TSAs are certified like other entities, by CAs, and work from > there. Well put Steve, I fully support this position. Regards, Aram Perez Received: from mail-fwd.verio-web.com ([161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA17486 for ; Thu, 22 Jun 2000 08:58:16 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 08300882; Thu, 22 Jun 2000 11:58:17 -0400 (EDT) Sender: rsalz Message-ID: <395234B0.D4546882@caveosystems.com> Date: Thu, 22 Jun 2000 11:45:52 -0400 From: Rich Salz Organization: Caveo Systems, LLC X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Aram Perez CC: PKIX Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 > I'm not sure I understand your statement of having "*less* to trust". Sorry, poorly worded. If I trust the CA that certifies a TSA, then aren't I (by default, and certainly by philosophy) trusting EVERY certificate that CA issues? Why should I have to? /r$ Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14304 for ; Thu, 22 Jun 2000 07:46:15 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA29576; Thu, 22 Jun 2000 10:46:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3952194B.84989CDE@caveosystems.com> References: <3952194B.84989CDE@caveosystems.com> Date: Thu, 22 Jun 2000 10:39:16 -0400 To: Rich Salz From: Stephen Kent Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, I support Denis's original restriction on the uses of a TSA private key. It is desirable to constrain the use of a private key to avoid possible errors in its use. It seems that we have gone down a thread that focuses on certificates for a TSA, more than on the original key usage restriction. I've always asserted that self-signed certs are just a syntactic convenience, not a generally useful way of ensuring security for transmitted public keys. If we agree on that point, then I don't see a lot of reason to push for self-signed TSA certs. A TSA is not a CA. Even if the same organization happens to operate both a CA function and a TSA function, it seems appropriate to separate these functions. That's part of why we have the proposed constraint for using the TSA private key only for signing TSA responses. It was suggested that this is not consistent with the use of POP. True, but only in so far as the POP in question is the one defined in our automated registration protocols. Thus is not the only game in town, and for a TSA it is reasonable to anticipate other mechanisms that provide POP, but not via those protocols. So, I don't think that the POP argument is a good basis for rejecting the key usage restriction. The "less to trust" argument that Michael makes does have some merit, but as Aram points out, a self-signed cert required some integrity/authenticity secure, OOB means for its delivery, which is why we try to minimize the use of such certs. It seems hard enough to do this for CAs, without adding TSAs to the list. Let's assume that TSAs are certified like other entities, by CAs, and work from there. Steve Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13679 for ; Thu, 22 Jun 2000 07:20:17 -0700 (PDT) Received: from [207.215.85.136] by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWK00FHP7TIQQ@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 22 Jun 2000 07:20:07 -0700 (PDT) Date: Thu, 22 Jun 2000 07:20:44 -0700 From: Aram Perez Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] In-reply-to: <3952194B.84989CDE@caveosystems.com> To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Rich Salz wrote: >> So what does the self-signed >> TSA cert buy me besides the need to go through the trust decisions again? > > You actually have *less* to trust if you have a self-signed TSA. Trusting > the CA means you trust all it signs. Trusting the TSA means just and only > that. I'm not sure I understand your statement of having "*less* to trust". To trust a self-signed certificate (no matter if it is from a CA or TSA), you have to have an out-of-band mechanism to verify that the self-signed certificate is valid. One of the nice features of a hierarchical PKI is that I can limit the number of times I need the out-of-band mechanisms to verify self-signed certificates. If I don't want to trust the self-signed certificate of a CA that signs a TSA, then I can use the out-of-band mechanism to verify the TSA's certificate (that was signed by a CA) and treat it as an "anchor certificate". My definition of an anchor certificate is a certificate I implicitly trust because I have used an out-of-band mechanism to verify it. When I'm validating the certificate chain, I stop whenever I reach an anchor certificate (whether or not it is self-signed). Regards, Aram Perez Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13219 for ; Thu, 22 Jun 2000 07:03:24 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 10:04:25 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C045@panda.chrysalis-its.com> To: ietf-pkix@imc.org Subject: RE: certification for pki Date: Thu, 22 Jun 2000 10:04:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDC52.C59A3F34" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDC52.C59A3F34 Content-Type: text/plain; charset="iso-8859-1" Russ, Thanks for the link. I had a quick look at them and I have noted that contrary to the NIST CIMC PP, which as indicated in my previous Email created new security functional requirements even for key management, the SPYRUS CIMS PPs contain no security functional requirements whatsoever about cryptographic functionality. Each SPYRUS's PP contains the same statement, "I haven't got a clue" when addressing Common Criteria requirement statements about cryptographic support. Does SPYRUS plan to add some security functional requirements from the Class FCS on cryptographic support in a future version of its PPs? Reagards, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: Russ Housley [mailto:housley@spyrus.com] Sent: Wednesday, June 21, 2000 10:48 PM To: FRousseau@chrysalis-its.com Cc: ghilborn@csc.com; jean.med@arabtrust.com; ietf-pkix@imc.org Subject: RE: certification for pki Please take a look at the protection profiles being proposed by SPYRUS. You can find them at http://www.spyrus.com/documents/cims. We have released the Level 3 profile to ANSI X9 as a strawman for a financial industry protection profile. Russ [snip] ------_=_NextPart_001_01BFDC52.C59A3F34 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: certification for pki

Russ,

Thanks for the link. I had a quick look at them and I = have noted that contrary to the NIST CIMC PP, which as indicated in my = previous Email created new security functional requirements even for = key management, the SPYRUS CIMS PPs contain no security functional = requirements whatsoever about cryptographic functionality. Each = SPYRUS's PP contains the same statement, "I haven't got a = clue" when addressing Common Criteria requirement statements about = cryptographic support. Does SPYRUS plan to add some security functional = requirements from the Class FCS on cryptographic support in a future = version of its PPs?

Reagards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078


-----Original Message-----
From: Russ Housley [mailto:housley@spyrus.com]=
Sent: Wednesday, June 21, 2000 10:48 PM
To: FRousseau@chrysalis-its.com
Cc: ghilborn@csc.com; jean.med@arabtrust.com; = ietf-pkix@imc.org
Subject: RE: certification for pki


Please take a look at the protection profiles being = proposed by SPYRUS.  You can find them at http://www.spyrus.com/documents/cims.  We = have released the Level 3 profile to ANSI X9 as a strawman for a = financial industry protection profile.

Russ

[snip]

------_=_NextPart_001_01BFDC52.C59A3F34-- Received: from mail-fwd.verio-web.com ([161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA12841 for ; Thu, 22 Jun 2000 06:50:38 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 08234539; Thu, 22 Jun 2000 09:50:16 -0400 (EDT) Sender: rsalz Message-ID: <3952194B.84989CDE@caveosystems.com> Date: Thu, 22 Jun 2000 09:48:59 -0400 From: Rich Salz Organization: Caveo Systems, LLC X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Peter Lipp CC: ietf-pkix@imc.org Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 > So what does the self-signed > TSA cert buy me besides the need to go through the trust decisions again? You actually have *less* to trust if you have a self-signed TSA. Trusting the CA means you trust all it signs. Trusting the TSA means just and only that. /r$ Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10258 for ; Thu, 22 Jun 2000 05:25:58 -0700 (PDT) Received: from ctex01.us.cybertrust.com (ctex01.us.cybertrust.com [192.233.30.4]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id IAA27900; Thu, 22 Jun 2000 08:25:47 -0400 (EDT) Received: by ctex01.us.cybertrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Jun 2000 08:24:55 -0400 Message-ID: From: "Meggison, Tim" To: "'Simon McMahon'" , Michael Zolotarev , Jean-Marc Desperrier , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 08:24:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I believe the key word in Simon's email is policy. What is good policy for one situation is overkill for another. I suggest the spec should be limited to technical and interop requirements, and leave policy decisions to actual implementations. > -----Original Message----- > From: Simon McMahon [mailto:simon@onthenet.com.au] > Sent: Wednesday, June 21, 2000 10:51 PM > To: Michael Zolotarev; Jean-Marc Desperrier; ietf-pkix@imc.org > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > > > Michael wrote: > > > > If we forget for a moment about what the draft says > (please): what is > wrong > > with using a TSA key for signing 'something that is not a > time-stamp'? I > do > > not see anything criminal about that. Especially if the case is > well-defined > > and justified. > > > The draft obviously said it for a reason but to answer "what is wrong > with using a TSA key for signing 'something that is not a > time-stamp'?" > > 1. Its good security policy to restrict usage of > particularly sensitive > keys. > > The ultimate restriction is one exclusive use which is the > state of the > draft now. > You should show a very good reason to weaken that or show that the new > usage has negligable impact. If you do this then an attack on > certificate > signing keys will be useful as an attack on time-stamp > signing keys since > time-stamp signing keys can also sign certificates. > > 2. It couples the primary TSA service (making timestamps) with a CA > service (making certificates). > > I'm not sure that the intention is for TSAs to always be CAs > or vice versa. > If CAs and TSAs will be operated, managed and owned seperately then it > is good that their services are not too coupled or intertwined. > > Also, if TSAs will be subject to formal evaluation "torture" > then the less > services and complications they include the less the torture > will be. Both > uses of the private key, time-stamp signing and certificate > signing, will > need to be evaluated. > > > Regards, > > Simon. > > Received: from stonewall.baltimore.com (mailhost.baltimore.com [195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA09034 for ; Thu, 22 Jun 2000 04:45:09 -0700 (PDT) Message-ID: <001301bfdc3e$b4d31a40$123c70c2@baltimore.com> Reply-To: "Farrukh Ahmad" From: "Farrukh Ahmad" To: , References: <96160607224858@baltimore.com> Subject: Re: certification for pki Date: Thu, 22 Jun 2000 12:34:54 +0100 Organization: Baltimore Technology (UK) Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 FYI, under the CEN/ETSI standards work currently being carried out for use with the European Directive on Digital Signatures, trustworthy system standards are being written which include in their annex CC PPs for CAs and RAs. These may be used by a Certification Service Provider (CSP) issuing Qualified Certificates for compliance assessment. A public draft will be available sometime in September and a complete standard by the end of the year. Regards Farrukh Ahmad ----- Original Message ----- From: To: Sent: Thursday, June 22, 2000 5:47 AM Subject: Re: certification for pki > ghilborn@csc.com writes: > > >It is not a choice of CC vs. FIPS. The FIPS 140-1 testing pertains > narrowly > >to crypto modules. The CC evaluation/"torture" process is about the > >system/components for certificate issuance and management meeting its > security > >specification (security target and claimed PP(s)). > > Oh, so the interest is in certifying the PKI process rather than > machinery > which makes it possible? In that case there's a whole host of standards > to > choose from, from ISO there's ISO 15782-1, Banking - Certificate > Management, > from ANSI theres X9.57 Certificate Management and ANSI X9.79, PKI > Practices and > Framework, and from vendors there's both VISA and MC's SET PKI > requirements > (which, while in some cases SET-specific), are well thought out. Would > any of > those be usable as a PP? > > Peter. > Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA02256 for ; Thu, 22 Jun 2000 02:23:10 -0700 (PDT) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AB0A28A0052; Thu, 22 Jun 2000 11:23:22 +0200 From: "Peter Lipp" To: Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 11:24:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3951CA50.CA0992FE@certplus.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal > I'm not convinced it's bad to issue self-signed TSA certificate. > I'm just saying it might not be a great idea. Agree. I don't see the big advantage. For one, if I want to trust a CA I need to go through whatever steps are appropriate. If the CA offers/recommends/uses a TSA, it can give me a certificate for the TSA and - having already decided to trust the CA - it is simple to verify the certificate and decide to trust the TSA too. So what does the self-signed TSA cert buy me besides the need to go through the trust decisions again? Now consider revocation - do you really suggest to set up a separate revocation-scheme for the TSA? I simply don't see any advantage here... Peter Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA01152 for ; Thu, 22 Jun 2000 01:53:22 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id SAA03131; Thu, 22 Jun 2000 18:59:22 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Jun 2000 18:52:48 +1000 Message-ID: From: Michael Zolotarev To: Simon McMahon , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 18:52:47 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" > For an evaluated TSA I would push the self-signed > cert-request (or cert) > into the Key generation operation. That way signing the > cert-request could > not be classed as a form of run-time usage of the key and should not > conflict with the intended exclusive usage (signing > timestamps) of the key. > If thats what you've been saying all along then I apolagise. > You would not > be able to re-generate another self-signed cert later on > though. Does that > matter ? Well, that would probably matter when a current certificate expires and you need to issue another certificate. Do you mean that logical(!) definition of Key Generation operation can not embrace re-issuing a certificate with the same value of the key? Why not? I think we'd be able to defend it for the evaluation. It is not part of the run-time usage (a tick box here), the key was not compromised (a tick box here), a new certificate is issued following the same (already evaluated) procedure as the very first one (a tick box here). Do not think it would be a problem, in general. > > BTW The steps now become : > > a. Key generation - output self-signed cert-request (or > cert) and private > key pair. > b. Secure private key storage. > c. Cert-request (or cert) distribution. > d. Private key usage - input validation & signing. > > Regards, > > Simon. > > Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA28380 for ; Thu, 22 Jun 2000 01:20:20 -0700 (PDT) Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id SAA88914; Thu, 22 Jun 2000 18:20:07 +1000 (EST) Message-ID: <01c901bfdc23$de0ad080$8802a8c0@eracom.com.au> From: "Simon McMahon" To: "Michael Zolotarev" , "Jean-Marc Desperrier" , References: Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 18:28:08 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 > > Ok, lets go for it: > 1. Self-signed TSA cert. You have to evaluate your secure signing > environment. Which is the same for generating timestamps and for generation > a self-signed cert. > 2. Not self-signed TSA cert. You have to evaluate your secure timestamp > signing environment AND whatever mechanism you (or whoever else) employed to > issue TSA a certificate. > In both cases you will have to evaluate. a. Key generation - Output public key and private key pair. b. Secure private key storage. c. Public key distribution. d. Private key usage - input validation & signing. a & b are the same for TSA types 1 & 2. c1 - Public key goes into a cert encoding and is signed by the private key (uses d1). d1 - Sign timestamps, and sign encoded cert (from c1). c2 - Public key goes to evaluated CA for cert encoding and distribution. d2 - Sign timestamps. I would suspect that type 1 TSAs will also have to support having their public key certified by a CA which means that c2 applies to them also. A type 2 TSA would not need c1. just received : > And yet another argument (as shyly suggested by Stephen Farrell) - in order > to get a TSA certificate from a CA, you may have to (as an obedient PKIX > follower) sign the request (P-O-P stuff). Which means that the key, which is > otherwise 100% pure timestamping, will be still used for non-timestamping > purpose. We are not going to prohibit the mechanism of POP, are we? You are right. That means c2 includes generating a cert request and d2 includes self-signing the encoded cert request. The only difference now is that type 2 TSAs includes self-signed certificate request encodings and type 1 includes them and self-signed certificate encodings also. For an evaluated TSA I would push the self-signed cert-request (or cert) into the Key generation operation. That way signing the cert-request could not be classed as a form of run-time usage of the key and should not conflict with the intended exclusive usage (signing timestamps) of the key. If thats what you've been saying all along then I apolagise. You would not be able to re-generate another self-signed cert later on though. Does that matter ? BTW The steps now become : a. Key generation - output self-signed cert-request (or cert) and private key pair. b. Secure private key storage. c. Cert-request (or cert) distribution. d. Private key usage - input validation & signing. Regards, Simon. Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA27675 for ; Thu, 22 Jun 2000 01:10:52 -0700 (PDT) Received: from certplus.com (nt4_jmd.certplus.com [192.168.1.17]) by certplus.com (8.8.7/8.8.7) with ESMTP id IAA04967 for ; Thu, 22 Jun 2000 08:41:50 +0200 Message-ID: <3951CA50.CA0992FE@certplus.com> Date: Thu, 22 Jun 2000 10:12:00 +0200 From: Jean-Marc Desperrier Organization: Certplus X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Zolotarev wrote: > > That there has been at least one point of time where your TSA hardware > > crypto module has been able to sign something that is not a > > time-stamp. > > If we forget for a moment about what the draft says (please): what is wrong > with using a TSA key for signing 'something that is not a time-stamp'? I do > not see anything criminal about that. Especially if the case is well-defined > and justified. Maybe I did not express myself clearly enough. I'm not convinced it's bad to issue self-signed TSA certificate. I'm just saying it might not be a great idea. I sure did not analyse the implication of that in every detail, and especially the inconvenience not being able to issue self-signed certificate. >From what you say, it looks like it should be allowed, and then up to every TSA operator to design his own policy with regard to using this possibility or not. Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA25409 for ; Thu, 22 Jun 2000 00:04:35 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id RAA02379; Thu, 22 Jun 2000 17:10:22 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Jun 2000 17:03:47 +1000 Message-ID: From: Michael Zolotarev To: Simon McMahon , Jean-Marc Desperrier , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 17:03:46 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" And yet another argument (as shyly suggested by Stephen Farrell) - in order to get a TSA certificate from a CA, you may have to (as an obedient PKIX follower) sign the request (P-O-P stuff). Which means that the key, which is otherwise 100% pure timestamping, will be still used for non-timestamping purpose. We are not going to prohibit the mechanism of POP, are we? M > -----Original Message----- > From: Simon McMahon [mailto:simon@onthenet.com.au] > Sent: Thursday, June 22, 2000 12:51 PM > To: Michael Zolotarev; Jean-Marc Desperrier; ietf-pkix@imc.org > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] > > > Michael wrote: > > > > If we forget for a moment about what the draft says > (please): what is > wrong > > with using a TSA key for signing 'something that is not a > time-stamp'? I > do > > not see anything criminal about that. Especially if the case is > well-defined > > and justified. > > > The draft obviously said it for a reason but to answer "what is wrong > with using a TSA key for signing 'something that is not a > time-stamp'?" > > 1. Its good security policy to restrict usage of > particularly sensitive > keys. > > The ultimate restriction is one exclusive use which is the > state of the > draft now. > You should show a very good reason to weaken that or show that the new > usage has negligable impact. If you do this then an attack on > certificate > signing keys will be useful as an attack on time-stamp > signing keys since > time-stamp signing keys can also sign certificates. > > 2. It couples the primary TSA service (making timestamps) with a CA > service (making certificates). > > I'm not sure that the intention is for TSAs to always be CAs > or vice versa. > If CAs and TSAs will be operated, managed and owned seperately then it > is good that their services are not too coupled or intertwined. > > Also, if TSAs will be subject to formal evaluation "torture" > then the less > services and complications they include the less the torture > will be. Both > uses of the private key, time-stamp signing and certificate > signing, will > need to be evaluated. > > > Regards, > > Simon. > > Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA19200 for ; Wed, 21 Jun 2000 21:07:16 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA00889; Thu, 22 Jun 2000 14:13:04 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Jun 2000 14:06:29 +1000 Message-ID: From: Michael Zolotarev To: Simon McMahon , Jean-Marc Desperrier , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 14:06:28 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" > > Michael wrote: > > > > If we forget for a moment about what the draft says > (please): what is > wrong > > with using a TSA key for signing 'something that is not a > time-stamp'? I > do > > not see anything criminal about that. Especially if the case is > well-defined > > and justified. > > > The draft obviously said it for a reason but to answer "what is wrong > with using a TSA key for signing 'something that is not a > time-stamp'?" > > 1. Its good security policy to restrict usage of > particularly sensitive > keys. > Use a TSA key for signing timestamps and for signing a TSA's own certificate is still within well-defined and restricted scope of use. The use of the key IS STILL WELL RESTRICTED. > The ultimate restriction is one exclusive use which is the > state of the > draft now. > You should show a very good reason to weaken that Self-signed TSA cert is a very good reason to me. > or show that the new usage has negligable impact. If you do this then an attack on > certificate signing keys will be useful as an attack on time-stamp > signing keys since time-stamp signing keys can also sign certificates. Do you mean that using a particular key to produce N signatures (timestamps) as compared to producing N+1 signatures (timestamps and a self-signed TSA cert) makes an attack any easier? I doubt it. > > 2. It couples the primary TSA service (making timestamps) with a CA > service (making certificates). > Do not agree here. Issuing a self-signed cert by no means makes an entity a CA. TSA does not become a CA, and it does not need to become one, simply for the fact that it has a self-signed cert. No no no :). > I'm not sure that the intention is for TSAs to always be CAs > or vice versa. > If CAs and TSAs will be operated, managed and owned seperately then it > is good that their services are not too coupled or intertwined. > > Also, if TSAs will be subject to formal evaluation "torture" > then the less > services and complications they include the less the torture > will be. Both > uses of the private key, time-stamp signing and certificate > signing, will > need to be evaluated. Ok, lets go for it: 1. Self-signed TSA cert. You have to evaluate your secure signing environment. Which is the same for generating timestamps and for generation a self-signed cert. 2. Not self-signed TSA cert. You have to evaluate your secure timestamp signing environment AND whatever mechanism you (or whoever else) employed to issue TSA a certificate. What is easier? (1) is sure looks simpler to me. Regards Michael > > > Regards, > > Simon. > > Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA15297 for ; Wed, 21 Jun 2000 20:04:03 -0700 (PDT) Received: from rhousley_laptop.spyrus.com (dial02.spyrus.com [207.212.34.122]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id UAA24174; Wed, 21 Jun 2000 20:03:31 -0700 (PDT) Message-Id: <4.2.0.58.20000621224526.00a71100@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 21 Jun 2000 22:48:08 -0400 To: FRousseau@chrysalis-its.com From: Russ Housley Subject: RE: certification for pki Cc: ghilborn@csc.com, jean.med@arabtrust.com, ietf-pkix@imc.org In-Reply-To: <918C70B01822D411A87400B0D0204DFF04C039@panda.chrysalis-its .com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Please take a look at the protection profiles being proposed by SPYRUS.  You can find them at http://www.spyrus.com/documents/cims.  We have released the Level 3 profile to ANSI X9 as a strawman for a financial industry protection profile.

Russ

At 12:09 PM 06/21/2000 -0400, FRousseau@chrysalis-its.com wrote:

Gene,

However, the major drawback with the Certificate Issuing and Management Component (CIMC) Protection Profile (PP) sponsored/created by the (US) National Institute of Science and Technology (NIST) is that the current version still specifies about 25 new security functional requirements (SFRs) that are NOT included in the Common Criteria (CC)/ISO 15408 instead of using the refinement and/or the iteration operations on existing CC security functional requirements.

In addition, all these additional security functional requirements from the NIST CIMC PP would probably not be recognised through the mutual recognition arrangement (MRA).

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

-----Original Message-----
From: ghilborn@csc.com [mailto:ghilborn@csc.com]
Sent: Wednesday, June 21, 2000 10:23 AM
To: ietf-pkix@imc.org
Cc: jean.med@arabtrust.com
Subject: Re: certification for pki

One internationally recognized avenue is an evaluation under the Common
Criteria/ISO 15408.  Such an evaluation up to EAL4 is automatically recognized
by the (currently) nine mutual recognition arrangement countries.  Two current
problems are (1) that the CC itself does not contain a crypto module evaluation
standard such as FIPS 140-1/2, and (2) there is not yet a consensus and
evaluated Protection Profile for PKI components.   Some product vendors have
undertanen evaluations without PPs.  FIPS 140-1 is officially US/Canada, but
also widely recognized.

There is a maturing draft PP sponsored/created by the (US) National Institute of
Science and Technology,  which offers a selection of four levels of assurance
for certificate issuing and management components (CIMC).  See
http://csrc.nist.gov/pki/documents/.  For specific crypto module validation, it
references FIPS 140-1, but also includes all the other system security funcional
and assurance requirements appropriate to CIMC.

-Gene Hilborn

jean.med@arabtrust.com on 06/21/2000 06:00:06 AM

To:   ietf-pkix@imc.org
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  certification for pki

Hi,

Is there any internationally accredited certification for PKI

Jean
Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13774 for ; Wed, 21 Jun 2000 19:43:13 -0700 (PDT) Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id MAA30030; Thu, 22 Jun 2000 12:43:05 +1000 (EST) Message-ID: <018a01bfdbf4$c92e2150$8802a8c0@eracom.com.au> From: "Simon McMahon" To: "Michael Zolotarev" , "Jean-Marc Desperrier" , References: Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 12:51:06 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Michael wrote: > > If we forget for a moment about what the draft says (please): what is wrong > with using a TSA key for signing 'something that is not a time-stamp'? I do > not see anything criminal about that. Especially if the case is well-defined > and justified. > The draft obviously said it for a reason but to answer "what is wrong with using a TSA key for signing 'something that is not a time-stamp'?" 1. Its good security policy to restrict usage of particularly sensitive keys. The ultimate restriction is one exclusive use which is the state of the draft now. You should show a very good reason to weaken that or show that the new usage has negligable impact. If you do this then an attack on certificate signing keys will be useful as an attack on time-stamp signing keys since time-stamp signing keys can also sign certificates. 2. It couples the primary TSA service (making timestamps) with a CA service (making certificates). I'm not sure that the intention is for TSAs to always be CAs or vice versa. If CAs and TSAs will be operated, managed and owned seperately then it is good that their services are not too coupled or intertwined. Also, if TSAs will be subject to formal evaluation "torture" then the less services and complications they include the less the torture will be. Both uses of the private key, time-stamp signing and certificate signing, will need to be evaluated. Regards, Simon. Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA03778 for ; Wed, 21 Jun 2000 17:19:45 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA21258; Thu, 22 Jun 2000 10:24:50 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Jun 2000 10:18:31 +1000 Message-ID: From: Michael Zolotarev To: Jeff Davis , ietf-pkix@imc.org Subject: RE: Private Key Cloning Date: Thu, 22 Jun 2000 10:18:30 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Jeff wrote: > The whole idea of having a private key is just that, it is > private to a > single entity and not shared across many other "clones" of > that entity. > > IMHO, and it is very "H" in this case, cloning a private key, of any > nature, is opening yourselves up to all sorts of repudiation > claims. If > you clone once what stops you cloning "n" times without > anyone knowing > ( regardless of what procedures you have in place ). Part of > the basis > of "trust" is that a private key only exists in one place under the > strict control of the owner of that key. The cloning procedure becomes a critical part, I agree. So the authority would have to certify both the security/procedures of its operational environment, and the security/procedures of key cloning. The same scale of precautions that currently applies to keeping the [only and single] key secure would apply to the cloning process. If you suspect that the cloning may allow a criminal-minded high-privileged insider to perpetrate a fraud, then for the same reason your should similarly suspect any other security aspects of the authority operations. We must always consider every particular case of key cloning, instead of dismissing the whole concept. If a particular cloning procedure, executed by a particular authority, using given hardware, in a particular secure environment etc etc can be formally certified as being sufficiently secure, at least not less(!) secure than the rest of the solution - what is wrong with it? If you can prove that your solution is secure - that would be just fine. Why reject the approach on the basis that it MAY present a security hole. Following that logic, whole PKI would be extinct by now. > > I support the views put forward that maybe the TSA root should sign > certificates for level 1 TSA Agents, of which there could be > as many as > required, but all of whom have a different DN ( very closely > associated > with the parent TSA ). The trust of the Time Stamp would then be > through a normal certificate chain and that only being 1 level. Maybe > the TSA root could then go offline leaving the "work horses" > to perform > the stamping. Re-issuing of new TSA signing keys would then be quite > easy for each Agent, with only 1 out of "n" Agents being > offline at any > one time, update the hardware signing module and get back online > a.s.a.p. > > I may be well off the mark here, if so, just tell me to shut > up and get > back in the cupboard. However, as I am trying to learn this stuff, a > little help with my waywardness would go a long way. > I'm also new to the house. But I've learned that there are two words missing in the group's dictionary - "beautiful" and "shut up". Three words, actually :) M Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03253 for ; Wed, 21 Jun 2000 16:46:04 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA20926; Thu, 22 Jun 2000 09:51:46 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Jun 2000 09:45:27 +1000 Message-ID: From: Michael Zolotarev To: Jean-Marc Desperrier , ietf-pkix@imc.org Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 09:45:26 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" > > But from a practical point of view what does self-signed TSA > cert means? > That there has been at least one point of time where your TSA hardware > crypto module has been able to sign something that is not a > time-stamp. If we forget for a moment about what the draft says (please): what is wrong with using a TSA key for signing 'something that is not a time-stamp'? I do not see anything criminal about that. Especially if the case is well-defined and justified. Please do not mistake this with signing a timestamp with a 'wrong' key. That would be just too bad. > I think that if a TSA is under a formal evaluation process, > it will have to prove it's "impossible" to get it to sign something that is not a > valid time stamp. Considering what I said above, we won't have to prove it at all. > > Of course, the signing of this certificate would be done in an initial > step, before the hardware crypto module is inserted inside the actual > TSA operation process, but it does not sound that great. > Also couldn't there be circonstances, where we would have to > generate a > new certificate, if the policy changes, etc... ? > Under those circumstances a new key would need to be generated, most likely. Michael Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02706 for ; Wed, 21 Jun 2000 16:22:16 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id JAA20661; Thu, 22 Jun 2000 09:27:33 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Jun 2000 09:21:14 +1000 Message-ID: From: Michael Zolotarev To: Peter Lipp , Jean-Marc Desperrier , ietf-pkix@imc.org Subject: RE: self-signed TSA [Was Re: Private Key Cloning] Date: Thu, 22 Jun 2000 09:21:13 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" I see. But do you think that the requirement should be loosen up a bit, in order to accommodate self-signed certificates? > -----Original Message----- > From: Peter Lipp [mailto:Peter.Lipp@iaik.at] > Sent: Wednesday, June 21, 2000 10:24 PM > To: Michael Zolotarev; Jean-Marc Desperrier; ietf-pkix@imc.org > Subject: AW: self-signed TSA [Was Re: Private Key Cloning] > > > > However, it does NOT necessarily say that the same > > 'timestamping' key can not be used for signing whatever else, for > > example a certificate. > > Looking at the current draft it sais: > > A TSA is REQUIRED ... > 10. to sign each time stamp token using a key generated > exclusively for this purpose and have this property of the > key indicated on the corresponding certificate. > > I read "exclusively for this purpose" as "not allowed for signing > certificates". > > Peter > > > Received: from ponyexpress4.csc.com (ponyexpress4.csc.com [208.219.64.203]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28147 for ; Wed, 21 Jun 2000 11:43:17 -0700 (PDT) From: ghilborn@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress4.csc.com with smtp (Exim 2.12 #1) id 134pSh-0001WU-00 for ietf-pkix@imc.org; Wed, 21 Jun 2000 14:42:55 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256905.0066D553 ; Wed, 21 Jun 2000 14:43:12 -0400 X-Lotus-FromDomain: CSC To: FRousseau@chrysalis-its.com cc: ietf-pkix@imc.org Message-ID: <85256905.0066D323.00@csc.com> Date: Wed, 21 Jun 2000 14:42:12 -0400 Subject: RE: certification for pki Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0QwgtU9BSQQ4HjJODHxsbZkidPG5u58Ri4RqOKNcIJuWTfFQzZOpHbfs" Content-Disposition: inline --0__=0QwgtU9BSQQ4HjJODHxsbZkidPG5u58Ri4RqOKNcIJuWTfFQzZOpHbfs Content-type: text/plain; charset=us-ascii Content-Disposition: inline I apologize to the pkix list if the following is getting to be too off-topic, and would be happy to take it off list if anyone wishes. Francois, I agree generally with your critique of NIST's draft CIMC PP, in the sense that its authors probably made over-liberal use of creating new security functional requirements that are not in the CC, rather than using the SFRs available. They probably could have done a much better job of using the existing SFRs with creative use of legitimate operations (selection, assignment, iteration, and refinement). However, I disagree with the statement that "all these additional requirements would probably not be recognized through the mutual recognition." The MRA http://niap.nist.gov/cc-scheme/DownloadCCMRA.html does not recognize "requirements;" it does recognize CC evaluation certificates for PPs and IT products evaluated under the member national schemes. A proper use of custom or "explicit" SFRs and/or security assurance requirements (SARs) is most definitely provided for in the CC. For example, in CC part 1 paragraph 5.2 we have: "The CC recognizes the possibility that functional and assurance requirements not included in the provided catalogues may be required in order to represent the complete set of IT security requirements. The following shall apply to the inclusion of these extended functional or assurance requirements: ..." The exact CC requirements for SFR/SAR extension in a PP are further elaborated in the Annex B Specification of Protection Profiles. If done properly and justified in the PP/ST rationale, the use of explicit/extended SFRs in no way invalidates a PP or product evaluation. The PP/ST author does have the burden of justifying the use of any explicit (extended) requirements (which IMO the CIMC PP authors have failed to do in the current draft). Once a PP (even with explicit SFRs) has been successfully evaluated under one of the national schemes it's evaluation will be mutually recognized. Once a product with an ST claiming compliance to such a PP has been successfully evaluated under one of the national schemes it's evaluation will be mutually recognized. -GH FRousseau@chrysalis-its.com on 06/21/2000 12:09:18 PM To: Gene Hilborn/DEF/CSC@CSC cc: jean.med@arabtrust.com, ietf-pkix@imc.org Subject: RE: certification for pki Gene, However, the major drawback with the Certificate Issuing and Management Component (CIMC) Protection Profile (PP) sponsored/created by the (US) National Institute of Science and Technology (NIST) is that the current version still specifies about 25 new security functional requirements (SFRs) that are NOT included in the Common Criteria (CC)/ISO 15408 instead of using the refinement and/or the iteration operations on existing CC security functional requirements. In addition, all these additional security functional requirements from the NIST CIMC PP would probably not be recognised through the mutual recognition arrangement (MRA). Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: ghilborn@csc.com [mailto:ghilborn@csc.com] Sent: Wednesday, June 21, 2000 10:23 AM To: ietf-pkix@imc.org Cc: jean.med@arabtrust.com Subject: Re: certification for pki One internationally recognized avenue is an evaluation under the Common Criteria/ISO 15408. Such an evaluation up to EAL4 is automatically recognized by the (currently) nine mutual recognition arrangement countries. Two current problems are (1) that the CC itself does not contain a crypto module evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus and evaluated Protection Profile for PKI components. Some product vendors have undertanen evaluations without PPs. FIPS 140-1 is officially US/Canada, but also widely recognized. There is a maturing draft PP sponsored/created by the (US) National Institute of Science and Technology, which offers a selection of four levels of assurance for certificate issuing and management components (CIMC). See http://csrc.nist.gov/pki/documents/. For specific crypto module validation, it references FIPS 140-1, but also includes all the other system security funcional and assurance requirements appropriate to CIMC. -Gene Hilborn jean.med@arabtrust.com on 06/21/2000 06:00:06 AM To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: certification for pki Hi, Is there any internationally accredited certification for PKI Jean --0__=0QwgtU9BSQQ4HjJODHxsbZkidPG5u58Ri4RqOKNcIJuWTfFQzZOpHbfs Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-transfer-encoding: base64 Content-Description: Internet HTML PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1MC4xMiI+DQo8VElUTEU+UkU6IGNl cnRpZmljYXRpb24gZm9yIHBraTwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQg U0laRT0yPkdlbmUsPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SG93ZXZlciwgdGhl IG1ham9yIGRyYXdiYWNrIHdpdGggdGhlIENlcnRpZmljYXRlIElzc3VpbmcgYW5kIE1hbmFnZW1l bnQgQ29tcG9uZW50IChDSU1DKSBQcm90ZWN0aW9uIFByb2ZpbGUgKFBQKSBzcG9uc29yZWQvY3Jl YXRlZCBieSB0aGUgKFVTKSBOYXRpb25hbCBJbnN0aXR1dGUgb2YgU2NpZW5jZSBhbmQgVGVjaG5v bG9neSAoTklTVCkgaXMgdGhhdCB0aGUgY3VycmVudCB2ZXJzaW9uIHN0aWxsIHNwZWNpZmllcyBh Ym91dCAyNSBuZXcgc2VjdXJpdHkgZnVuY3Rpb25hbCByZXF1aXJlbWVudHMgKFNGUnMpIHRoYXQg YXJlIE5PVCBpbmNsdWRlZCBpbiB0aGUgQ29tbW9uIENyaXRlcmlhIChDQykvSVNPIDE1NDA4IGlu c3RlYWQgb2YgdXNpbmcgdGhlIHJlZmluZW1lbnQgYW5kL29yIHRoZSBpdGVyYXRpb24gb3BlcmF0 aW9ucyBvbiBleGlzdGluZyBDQyBzZWN1cml0eSBmdW5jdGlvbmFsIHJlcXVpcmVtZW50cy48L0ZP TlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+SW4gYWRkaXRpb24sIGFsbCB0aGVzZSBhZGRpdGlv bmFsIHNlY3VyaXR5IGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGZyb20gdGhlIE5JU1QgQ0lNQyBQ UCB3b3VsZCBwcm9iYWJseSBub3QgYmUgcmVjb2duaXNlZCB0aHJvdWdoIHRoZSBtdXR1YWwgcmVj b2duaXRpb24gYXJyYW5nZW1lbnQgKE1SQSkuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y PkZyYW5jb2lzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+RnJhbmNvaXMgUm91c3NlYXU8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkRpcmVjdG9yIG9mIFN0YW5kYXJkcyBhbmQgQ29uZm9y bWFuY2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkNocnlzYWxpcy1JVFM8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPjE2ODggV29vZHdhcmQgRHJpdmU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y Pk90dGF3YSwgT250YXJpbywgQ0FOQURBLCBLMkMgM1I3PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj5mcm91c3NlYXVAY2hyeXNhbGlzLWl0cy5jb20mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVGVsLiAoNjEzKSA3MjMtNTA3NiBleHQuIDQxOTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ PEEgSFJFRj0iaHR0cDovL3d3dy5jaHJ5c2FsaXMtaXRzLmNvbSIgVEFSR0VUPSJfYmxhbmsiPmh0 dHA6Ly93d3cuY2hyeXNhbGlzLWl0cy5jb208L0E+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZh eC4gKDYxMykgNzIzLTUwNzg8L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+RnJvbTog Z2hpbGJvcm5AY3NjLmNvbSBbPEEgSFJFRj0ibWFpbHRvOmdoaWxib3JuQGNzYy5jb20iPm1haWx0 bzpnaGlsYm9ybkBjc2MuY29tPC9BPl08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlNlbnQ6IFdl ZG5lc2RheSwgSnVuZSAyMSwgMjAwMCAxMDoyMyBBTTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ VG86IGlldGYtcGtpeEBpbWMub3JnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5DYzogamVhbi5t ZWRAYXJhYnRydXN0LmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+U3ViamVjdDogUmU6IGNl cnRpZmljYXRpb24gZm9yIHBraTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPk9uZSBp bnRlcm5hdGlvbmFsbHkgcmVjb2duaXplZCBhdmVudWUgaXMgYW4gZXZhbHVhdGlvbiB1bmRlciB0 aGUgQ29tbW9uPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Dcml0ZXJpYS9JU08gMTU0MDguJm5i c3A7IFN1Y2ggYW4gZXZhbHVhdGlvbiB1cCB0byBFQUw0IGlzIGF1dG9tYXRpY2FsbHkgcmVjb2du aXplZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+YnkgdGhlIChjdXJyZW50bHkpIG5pbmUgbXV0 dWFsIHJlY29nbml0aW9uIGFycmFuZ2VtZW50IGNvdW50cmllcy4mbmJzcDsgVHdvIGN1cnJlbnQ8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnByb2JsZW1zIGFyZSAoMSkgdGhhdCB0aGUgQ0MgaXRz ZWxmIGRvZXMgbm90IGNvbnRhaW4gYSBjcnlwdG8gbW9kdWxlIGV2YWx1YXRpb248L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPnN0YW5kYXJkIHN1Y2ggYXMgRklQUyAxNDAtMS8yLCBhbmQgKDIpIHRo ZXJlIGlzIG5vdCB5ZXQgYSBjb25zZW5zdXMgYW5kPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5l dmFsdWF0ZWQgUHJvdGVjdGlvbiBQcm9maWxlIGZvciBQS0kgY29tcG9uZW50cy4mbmJzcDsmbmJz cDsgU29tZSBwcm9kdWN0IHZlbmRvcnMgaGF2ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dW5k ZXJ0YW5lbiBldmFsdWF0aW9ucyB3aXRob3V0IFBQcy4mbmJzcDsgRklQUyAxNDAtMSBpcyBvZmZp Y2lhbGx5IFVTL0NhbmFkYSwgYnV0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5hbHNvIHdpZGVs eSByZWNvZ25pemVkLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlRoZXJlIGlzIGEg bWF0dXJpbmcgZHJhZnQgUFAgc3BvbnNvcmVkL2NyZWF0ZWQgYnkgdGhlIChVUykgTmF0aW9uYWwg SW5zdGl0dXRlIG9mPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5TY2llbmNlIGFuZCBUZWNobm9s b2d5LCZuYnNwOyB3aGljaCBvZmZlcnMgYSBzZWxlY3Rpb24gb2YgZm91ciBsZXZlbHMgb2YgYXNz dXJhbmNlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5mb3IgY2VydGlmaWNhdGUgaXNzdWluZyBh bmQgbWFuYWdlbWVudCBjb21wb25lbnRzIChDSU1DKS4mbmJzcDsgU2VlPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj48QSBIUkVGPSJodHRwOi8vY3NyYy5uaXN0Lmdvdi9wa2kvZG9jdW1lbnRzLyIg VEFSR0VUPSJfYmxhbmsiPmh0dHA6Ly9jc3JjLm5pc3QuZ292L3BraS9kb2N1bWVudHMvPC9BPi4m bmJzcDsgRm9yIHNwZWNpZmljIGNyeXB0byBtb2R1bGUgdmFsaWRhdGlvbiwgaXQ8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPnJlZmVyZW5jZXMgRklQUyAxNDAtMSwgYnV0IGFsc28gaW5jbHVkZXMg YWxsIHRoZSBvdGhlciBzeXN0ZW0gc2VjdXJpdHkgZnVuY2lvbmFsPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj5hbmQgYXNzdXJhbmNlIHJlcXVpcmVtZW50cyBhcHByb3ByaWF0ZSB0byBDSU1DLjwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi1HZW5lIEhpbGJvcm48L0ZPTlQ+DQo8L1A+ DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj5qZWFuLm1lZEBhcmFidHJ1c3QuY29tIG9uIDA2LzIx LzIwMDAgMDY6MDA6MDYgQU08L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5UbzombmJz cDsmbmJzcDsgaWV0Zi1wa2l4QGltYy5vcmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmNjOiZu YnNwOyZuYnNwOyZuYnNwOyAoYmNjOiBHZW5lIEhpbGJvcm4vREVGL0NTQyk8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPlN1YmplY3Q6Jm5ic3A7IGNlcnRpZmljYXRpb24gZm9yIHBraTwvRk9OVD4N CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkhpLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0la RT0yPklzIHRoZXJlIGFueSBpbnRlcm5hdGlvbmFsbHkgYWNjcmVkaXRlZCBjZXJ0aWZpY2F0aW9u IGZvciBQS0k8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5KZWFuPC9GT05UPg0KPC9Q Pg0KDQo8L0JPRFk+DQo8L0hUTUw+DQo= --0__=0QwgtU9BSQQ4HjJODHxsbZkidPG5u58Ri4RqOKNcIJuWTfFQzZOpHbfs-- Received: from ponyexpress6.csc.com (ponyexpress6.csc.com [208.219.64.207]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27630 for ; Wed, 21 Jun 2000 11:28:13 -0700 (PDT) From: ghilborn@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress6.csc.com with smtp (Exim 2.12 #1) id 134pDy-0007fb-00; Wed, 21 Jun 2000 14:27:42 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256905.006572C7 ; Wed, 21 Jun 2000 14:28:05 -0400 X-Lotus-FromDomain: CSC To: pgut001@cs.auckland.ac.nz cc: ietf-pkix@imc.org Message-ID: <85256905.0065702D.00@csc.com> Date: Wed, 21 Jun 2000 14:27:10 -0400 Subject: Re: certification for pki Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Peter, I said nothing about "certifying the PKI process." Rather I spoke of the process of certifying the products (CC and FIPS). -Gene pgut001@cs.auckland.ac.nz on 06/22/2000 12:47:52 AM Please respond to pgut001@cs.auckland.ac.nz To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: Re: certification for pki ghilborn@csc.com writes: >It is not a choice of CC vs. FIPS. The FIPS 140-1 testing pertains narrowly >to crypto modules. The CC evaluation/"torture" process is about the >system/components for certificate issuance and management meeting its security >specification (security target and claimed PP(s)). Oh, so the interest is in certifying the PKI process rather than machinery which makes it possible? In that case there's a whole host of standards to choose from, from ISO there's ISO 15782-1, Banking - Certificate Management, from ANSI theres X9.57 Certificate Management and ANSI X9.79, PKI Practices and Framework, and from vendors there's both VISA and MC's SET PKI requirements (which, while in some cases SET-specific), are well thought out. Would any of those be usable as a PP? Peter. Received: from cnbskpt2.cnbs.navy.mil (cnbskpt2.cnbs.navy.mil [164.221.184.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26248 for ; Wed, 21 Jun 2000 10:07:57 -0700 (PDT) Received: by cnbskpt2.cnbs.navy.mil with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Jun 2000 10:04:15 -0700 Message-ID: <07278C38CF83D21181B200105AA34A858B82D6@cnbskpt2.cnbs.navy.mil> From: "Morrill, Dan" To: "'pgut001@cs.auckland.ac.nz'" , ietf-pkix@imc.org Subject: RE: certification for pki Date: Wed, 21 Jun 2000 10:04:13 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) I don't suppose that out there on the net or in committee, there is one unifying document to take care of both the PKI process and the machinery that it is stored on as a mutually agreed upon set of standards? If not, maybe it would be good for this panel to make one? Just a thought. r/ Dan Morrill CSC -----Original Message----- From: pgut001@cs.auckland.ac.nz [mailto:pgut001@cs.auckland.ac.nz] Sent: Wednesday, June 21, 2000 09:48 PM To: ietf-pkix@imc.org Subject: Re: certification for pki ghilborn@csc.com writes: >It is not a choice of CC vs. FIPS. The FIPS 140-1 testing pertains narrowly >to crypto modules. The CC evaluation/"torture" process is about the >system/components for certificate issuance and management meeting its security >specification (security target and claimed PP(s)). Oh, so the interest is in certifying the PKI process rather than machinery which makes it possible? In that case there's a whole host of standards to choose from, from ISO there's ISO 15782-1, Banking - Certificate Management, from ANSI theres X9.57 Certificate Management and ANSI X9.79, PKI Practices and Framework, and from vendors there's both VISA and MC's SET PKI requirements (which, while in some cases SET-specific), are well thought out. Would any of those be usable as a PP? Peter. Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25455 for ; Wed, 21 Jun 2000 09:47:43 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id EAA07854 for ; Thu, 22 Jun 2000 04:47:52 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96160607224858>; Thu, 22 Jun 2000 04:47:52 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: Re: certification for pki Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Thu, 22 Jun 2000 04:47:52 (NZST) Message-ID: <96160607224858@kahu.cs.auckland.ac.nz> ghilborn@csc.com writes: >It is not a choice of CC vs. FIPS. The FIPS 140-1 testing pertains narrowly >to crypto modules. The CC evaluation/"torture" process is about the >system/components for certificate issuance and management meeting its security >specification (security target and claimed PP(s)). Oh, so the interest is in certifying the PKI process rather than machinery which makes it possible? In that case there's a whole host of standards to choose from, from ISO there's ISO 15782-1, Banking - Certificate Management, from ANSI theres X9.57 Certificate Management and ANSI X9.79, PKI Practices and Framework, and from vendors there's both VISA and MC's SET PKI requirements (which, while in some cases SET-specific), are well thought out. Would any of those be usable as a PP? Peter. Received: from laemail.bankofamerica.com (laemail.bankofamerica.com [171.161.96.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22529 for ; Wed, 21 Jun 2000 09:31:22 -0700 (PDT) Received: from laimail.bankofamerica.com (laimail.bankofamerica.com [171.182.104.13]) by laemail.bankofamerica.com (8.9.1/8.9.1) with ESMTP id JAA18275; Wed, 21 Jun 2000 09:31:02 -0700 (PDT) Received: from smtpsw03 (smtpsw03.bankofamerica.com [165.48.14.143]) by laimail.bankofamerica.com (8.9.1/8.9.1) with ESMTP id JAA25205; Wed, 21 Jun 2000 09:31:02 -0700 (PDT) Date: Wed, 21 Jun 2000 09:31:04 -0700 From: Mack Hicks Subject: Re: certification for pki To: ghilborn@csc.com Cc: ietf-pkix@imc.org Message-id: <3950EDC8.C397650C@bankofamerica.com> MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <85256905.0056D63D.00@csc.com> GH, As a "consumer", a banking business, of these products and services -- and as one who is also deploying into the marketplace, I do demand some testing and review. I also ask how much all this security is costing, and what risks are being minimized or eliminated. What I do NOT demand is the use of a "military threat" model in a commercial context. I define "military threat" as "a fault in security could ultimately lead to nuclear war - so no faults are allowed". What I mean is that most of the evaluations and criteria I have seen, like the AICPA draft and the ANSI X9.79 draft, are regarding risks as if they cannot be commercially controlled. To this end, Bank of America has voted "NO" on the first round of balloting for ANSI X9.79, and I encourage all other ANSI members to do the same. I mention this in the context of the mailing list discussion on private key cloning for commercial servers. Given budget constraints and the cost of the cryptographic hardware - not to mention the operational costs and customer (client) impact - there is no choice but to have some cloning and/or key backup of server signing keys. These keys are just too important to business flow to leave to a single location or piece of hardware. Admittedly, when one is acting in a position of trust for other organizations, care must be exercised - but it must be compatible and commensurate with the risk involved - not just to the risk to the keys but much more importantly - to the on-going operation of our customer's business. Further, when key management hardware is deployed to commercial servers that are not under bank security guidelines (like we do with credit card merchants today), there is an even greater need for resilience and key backup. The cost of hardware replication or the cost of business interruption (for rekeying and certification) is too high for the associated risk and perceived security benefit. ghilborn@csc.com wrote: > ... It may be > "torture" for the manufacturer, but when the market (or laws, regulations, etc.) > demand it, manufacturers do it. > -GH ------------------------------------------------- Mack Hicks, SVP mack.hicks@bankofamerica.com Bank of America +1-415-436-5809 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18729 for ; Wed, 21 Jun 2000 09:08:37 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 12:09:33 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C039@panda.chrysalis-its.com> To: ghilborn@csc.com Cc: jean.med@arabtrust.com, ietf-pkix@imc.org Subject: RE: certification for pki Date: Wed, 21 Jun 2000 12:09:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDB9B.166638B8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDB9B.166638B8 Content-Type: text/plain; charset="iso-8859-1" Gene, However, the major drawback with the Certificate Issuing and Management Component (CIMC) Protection Profile (PP) sponsored/created by the (US) National Institute of Science and Technology (NIST) is that the current version still specifies about 25 new security functional requirements (SFRs) that are NOT included in the Common Criteria (CC)/ISO 15408 instead of using the refinement and/or the iteration operations on existing CC security functional requirements. In addition, all these additional security functional requirements from the NIST CIMC PP would probably not be recognised through the mutual recognition arrangement (MRA). Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: ghilborn@csc.com [mailto:ghilborn@csc.com] Sent: Wednesday, June 21, 2000 10:23 AM To: ietf-pkix@imc.org Cc: jean.med@arabtrust.com Subject: Re: certification for pki One internationally recognized avenue is an evaluation under the Common Criteria/ISO 15408. Such an evaluation up to EAL4 is automatically recognized by the (currently) nine mutual recognition arrangement countries. Two current problems are (1) that the CC itself does not contain a crypto module evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus and evaluated Protection Profile for PKI components. Some product vendors have undertanen evaluations without PPs. FIPS 140-1 is officially US/Canada, but also widely recognized. There is a maturing draft PP sponsored/created by the (US) National Institute of Science and Technology, which offers a selection of four levels of assurance for certificate issuing and management components (CIMC). See http://csrc.nist.gov/pki/documents/. For specific crypto module validation, it references FIPS 140-1, but also includes all the other system security funcional and assurance requirements appropriate to CIMC. -Gene Hilborn jean.med@arabtrust.com on 06/21/2000 06:00:06 AM To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: certification for pki Hi, Is there any internationally accredited certification for PKI Jean ------_=_NextPart_001_01BFDB9B.166638B8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: certification for pki

Gene,

However, the major drawback with the Certificate = Issuing and Management Component (CIMC) Protection Profile (PP) = sponsored/created by the (US) National Institute of Science and = Technology (NIST) is that the current version still specifies about 25 = new security functional requirements (SFRs) that are NOT included in = the Common Criteria (CC)/ISO 15408 instead of using the refinement = and/or the iteration operations on existing CC security functional = requirements.

In addition, all these additional security functional = requirements from the NIST CIMC PP would probably not be recognised = through the mutual recognition arrangement (MRA).

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078


-----Original Message-----
From: ghilborn@csc.com [mailto:ghilborn@csc.com]
Sent: Wednesday, June 21, 2000 10:23 AM
To: ietf-pkix@imc.org
Cc: jean.med@arabtrust.com
Subject: Re: certification for pki

One internationally recognized avenue is an = evaluation under the Common
Criteria/ISO 15408.  Such an evaluation up to = EAL4 is automatically recognized
by the (currently) nine mutual recognition = arrangement countries.  Two current
problems are (1) that the CC itself does not contain = a crypto module evaluation
standard such as FIPS 140-1/2, and (2) there is not = yet a consensus and
evaluated Protection Profile for PKI = components.   Some product vendors have
undertanen evaluations without PPs.  FIPS 140-1 = is officially US/Canada, but
also widely recognized.

There is a maturing draft PP sponsored/created by the = (US) National Institute of
Science and Technology,  which offers a = selection of four levels of assurance
for certificate issuing and management components = (CIMC).  See
http://csrc.nist.gov/pki/documents/.  For = specific crypto module validation, it
references FIPS 140-1, but also includes all the = other system security funcional
and assurance requirements appropriate to = CIMC.

-Gene Hilborn


jean.med@arabtrust.com on 06/21/2000 06:00:06 = AM

To:   ietf-pkix@imc.org
cc:    (bcc: Gene = Hilborn/DEF/CSC)
Subject:  certification for pki

Hi,

Is there any internationally accredited certification = for PKI

Jean

------_=_NextPart_001_01BFDB9B.166638B8-- Received: from ponyexpress2.csc.com (ponyexpress2.csc.com [208.219.64.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16356 for ; Wed, 21 Jun 2000 08:48:55 -0700 (PDT) From: ghilborn@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress2.csc.com with smtp (Exim 2.12 #1) id 134mjx-00036P-01; Wed, 21 Jun 2000 11:48:33 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256905.0056D888 ; Wed, 21 Jun 2000 11:48:35 -0400 X-Lotus-FromDomain: CSC To: pgut001@cs.auckland.ac.nz cc: ietf-pkix@imc.org Message-ID: <85256905.0056D63D.00@csc.com> Date: Wed, 21 Jun 2000 11:47:39 -0400 Subject: Re: certification for pki Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline It is not a choice of CC vs. FIPS. The FIPS 140-1 testing pertains narrowly to crypto modules. The CC evaluation/"torture" process is about the system/components for certificate issuance and management meeting its security specification (security target and claimed PP(s)). A crypto module is just an embedded "engine" in the larger vehicle. To continue with the automotive metaphor, it is not a choice between auto emission testing vs. crash testing vs. fuel economy vs. performance testing, etc. All of these tests may be required for the consumer to understand and compare what they are buying. It may be "torture" for the manufacturer, but when the market (or laws, regulations, etc.) demand it, manufacturers do it. -GH pgut001@cs.auckland.ac.nz on 06/21/2000 11:11:43 PM Please respond to pgut001@cs.auckland.ac.nz To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: Re: certification for pki ghilborn@csc.com writes: >One internationally recognized avenue is an evaluation under the Common >Criteria/ISO 15408. Such an evaluation up to EAL4 is automatically recognized >by the (currently) nine mutual recognition arrangement countries. Two current >problems are (1) that the CC itself does not contain a crypto module >evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus >and evaluated Protection Profile for PKI components. Some product vendors >have undertanen evaluations without PPs. FIPS 140-1 is officially US/Canada, >but also widely recognized. A third problem with the CC, for those who haven't experienced it before, is that it acts as a form of torture for companies to determine how badly they need government (or whatever) contracts - the more pain you can stand, the better you've demonstrated that you need the contract. I'm not just saying this for $generic_CC_bashing, from talking to people who have gone through it it really sounds like an incredibly unpleasant experience (when I used the term "torture" to describe it above this doesn't originate with me but with the people I talked to). In terms of achieving more or less the same effect (the certification that is, not the torture :-) it looks like FIPS 140 is the easier path, and it does constitute a de facto PP which the CC doesn't have yet. I'd go with FIPS 140. Peter. Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12099 for ; Wed, 21 Jun 2000 08:11:38 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id DAA04418 for ; Thu, 22 Jun 2000 03:11:43 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96160030324826>; Thu, 22 Jun 2000 03:11:43 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: Re: certification for pki Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Thu, 22 Jun 2000 03:11:43 (NZST) Message-ID: <96160030324826@kahu.cs.auckland.ac.nz> ghilborn@csc.com writes: >One internationally recognized avenue is an evaluation under the Common >Criteria/ISO 15408. Such an evaluation up to EAL4 is automatically recognized >by the (currently) nine mutual recognition arrangement countries. Two current >problems are (1) that the CC itself does not contain a crypto module >evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus >and evaluated Protection Profile for PKI components. Some product vendors >have undertanen evaluations without PPs. FIPS 140-1 is officially US/Canada, >but also widely recognized. A third problem with the CC, for those who haven't experienced it before, is that it acts as a form of torture for companies to determine how badly they need government (or whatever) contracts - the more pain you can stand, the better you've demonstrated that you need the contract. I'm not just saying this for $generic_CC_bashing, from talking to people who have gone through it it really sounds like an incredibly unpleasant experience (when I used the term "torture" to describe it above this doesn't originate with me but with the people I talked to). In terms of achieving more or less the same effect (the certification that is, not the torture :-) it looks like FIPS 140 is the easier path, and it does constitute a de facto PP which the CC doesn't have yet. I'd go with FIPS 140. Peter. Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10833 for ; Wed, 21 Jun 2000 07:36:33 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 10:37:28 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C037@panda.chrysalis-its.com> To: ietf-pkix@imc.org Cc: jean-marc.desperrier@certplus.com Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Wed, 21 Jun 2000 10:37:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDB8E.391CBF4C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDB8E.391CBF4C Content-Type: text/plain; charset="iso-8859-1" Jean-Marc Desperrier wrote: [snip] > > Also couldn't there be circonstances, where we would have to > generate a new certificate, if the policy changes, etc... ? In addition, a TSA private key would eventually expire. When a TSA using a self-signed certificate has to update its key pair, would it also have to generate three (3) certificates (i.e. the OldWithNew, NewWithOld and NewWithNew TSA certificates) as per Section 2.4 of RFC 2510? Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFDB8E.391CBF4C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: AW: self-signed TSA [Was Re: Private Key Cloning]

Jean-Marc Desperrier wrote:

[snip]
>
> Also couldn't there be circonstances, where we = would have to
> generate a new certificate, if the policy = changes, etc... ?

In addition, a TSA private key would eventually = expire.

When a TSA using a self-signed certificate has to = update its key pair, would it also have to generate three (3) = certificates (i.e. the OldWithNew, NewWithOld and NewWithNew TSA = certificates) as per Section 2.4 of RFC 2510?

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01BFDB8E.391CBF4C-- Received: from irwell.zetnet.co.uk (root@irwell.zetnet.co.uk [194.247.47.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10458 for ; Wed, 21 Jun 2000 07:26:33 -0700 (PDT) Received: from jeffdavis (man-a190.dialup.zetnet.co.uk [194.247.44.190]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA05673 for ; Wed, 21 Jun 2000 15:26:42 +0100 X-Authentication-Warning: irwell.zetnet.co.uk: Host man-a190.dialup.zetnet.co.uk [194.247.44.190] claimed to be jeffdavis Message-ID: <008601bfdb8c$8defca70$7c2cf7c2@zetnet.co.uk> From: "Jeff Davis" To: Subject: Re: Private Key Cloning Date: Wed, 21 Jun 2000 15:25:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Hi, Being new to this group I would just like to add my 0.00001c ( or pennies in my case ) worth to this discussion. The whole idea of having a private key is just that, it is private to a single entity and not shared across many other "clones" of that entity. IMHO, and it is very "H" in this case, cloning a private key, of any nature, is opening yourselves up to all sorts of repudiation claims. If you clone once what stops you cloning "n" times without anyone knowing ( regardless of what procedures you have in place ). Part of the basis of "trust" is that a private key only exists in one place under the strict control of the owner of that key. I support the views put forward that maybe the TSA root should sign certificates for level 1 TSA Agents, of which there could be as many as required, but all of whom have a different DN ( very closely associated with the parent TSA ). The trust of the Time Stamp would then be through a normal certificate chain and that only being 1 level. Maybe the TSA root could then go offline leaving the "work horses" to perform the stamping. Re-issuing of new TSA signing keys would then be quite easy for each Agent, with only 1 out of "n" Agents being offline at any one time, update the hardware signing module and get back online a.s.a.p. I may be well off the mark here, if so, just tell me to shut up and get back in the cupboard. However, as I am trying to learn this stuff, a little help with my waywardness would go a long way. Jeff Received: from ponyexpress2.csc.com (ponyexpress2.csc.com [208.219.64.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10222 for ; Wed, 21 Jun 2000 07:24:11 -0700 (PDT) From: ghilborn@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress2.csc.com with smtp (Exim 2.12 #1) id 134lPy-0001Ha-00 for ietf-pkix@imc.org; Wed, 21 Jun 2000 10:23:50 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256905.004F1C63 ; Wed, 21 Jun 2000 10:24:06 -0400 X-Lotus-FromDomain: CSC To: ietf-pkix@imc.org cc: jean.med@arabtrust.com Message-ID: <85256905.004F19F5.00@csc.com> Date: Wed, 21 Jun 2000 10:23:09 -0400 Subject: Re: certification for pki Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline One internationally recognized avenue is an evaluation under the Common Criteria/ISO 15408. Such an evaluation up to EAL4 is automatically recognized by the (currently) nine mutual recognition arrangement countries. Two current problems are (1) that the CC itself does not contain a crypto module evaluation standard such as FIPS 140-1/2, and (2) there is not yet a consensus and evaluated Protection Profile for PKI components. Some product vendors have undertanen evaluations without PPs. FIPS 140-1 is officially US/Canada, but also widely recognized. There is a maturing draft PP sponsored/created by the (US) National Institute of Science and Technology, which offers a selection of four levels of assurance for certificate issuing and management components (CIMC). See http://csrc.nist.gov/pki/documents/. For specific crypto module validation, it references FIPS 140-1, but also includes all the other system security funcional and assurance requirements appropriate to CIMC. -Gene Hilborn jean.med@arabtrust.com on 06/21/2000 06:00:06 AM To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: certification for pki Hi, Is there any internationally accredited certification for PKI Jean Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09935 for ; Wed, 21 Jun 2000 07:15:49 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FWI00L01CYN31@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 21 Jun 2000 07:15:59 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FWI00K8ACYNP9@ext-mail.valicert.com>; Wed, 21 Jun 2000 07:15:59 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Jun 2000 07:09:28 -0700 Content-return: allowed Date: Wed, 21 Jun 2000 07:09:26 -0700 From: Frank Balluffi Subject: RE: Using certificates as trust anchors To: "'Yassir Elley'" , ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE2E08B76@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Yassir asked: > If the trust anchor information is trusted because it > was delivered "out-of-band", can we use non-self-signed > certificates to provide the trust anchor information? draft-ietf-pkix-new-part1-01.txt, section 6, paragraph 4 states: The "most-trusted CA" is a matter of policy: it could be a root CA in a hierarchical PKI; the CA that issued the verifier's own certificate(s); or any other CA in a network PKI. The path valida- tion procedure is the same regardless of the choice of "most-trusted CA." My interpretation of the above paragraph is yes, the trust anchor need not be a self-signed root certificate, which leads me to ... I have a difficult time comprehending section 6 of RFC 2459 and draft-ietf-pkix-new-part1-01.txt. I believe the reason is that many terms are used without first being clearly defined. For example, the term root CA, in the above paragraph, appears once without being defined. The term root certificate does not appear in draft-ietf-pkix-new-part1-01.txt. As an aside, I would love to know how many times the terms root CA or root certificate appear in PKIX-related implementations, either in comments or variable names. Is there interest in formally defining the terms used in section 6? If yes, I would be more than willing to take a stab at defining the terms I deem relevant, including: certificate [Is currently defined in section 3.1.] certificate hierarchy root certificate superior (or parent) certificate subordinate (or child) certificate self-signed certificate trusted certificate certificate (or certification) path [Is currently defined in section 3.2.] Perhaps this would make it easier to for developers (such as myself) to convert the narrative into code. Frank > -----Original Message----- > From: Yassir Elley [mailto:yassir.elley@sun.com] > Sent: Tuesday, June 20, 2000 2:45 PM > To: ietf-pkix@imc.org > Subject: Using certificates as trust anchors > > > In looking over draft-ietf-pkix-new-part1-01.txt, a question > arises as to how to process trust anchors provided in the > form of a self-signed certificate. Since many applications > use such certificates > as trust anchors, I think it is important for PKIX to > explicitly spell out how > to process these certificates. > > Section 6.1.1 describes the five pieces of trust anchor > information and > mentions that the trust anchor information may be provided in the form > of a self-signed certificate. > > "(d) trust anchor information, describing a CA that serves as a > trust anchor for the certification path. The trust > anchor infor- > mation includes: > (1) the trusted issuer name, > (2) optionally, the trusted issuer unique identifier, > (3) the trusted public key algorithm, > (4) the trusted public key, and > (5) optionally, the trusted public key parameters associated > with the public key. > > The trust anchor information may be provided to the > path process- > ing procedure in the form of a self-signed certificate. The > trusted anchor information is trusted because it was > delivered to > the path processing procedure by some trustworthy "out-of-band" > procedure. If the trusted public key algorithm requires parame- > ters, then the parameters are provided along with the > trusted pub- > lic key." > > However, in other parts of Section 6, we find that the algorithm > also requires the validity period of the public key, as well > as other constraints (presumably this refers to initial > name constraints, policy constraints, basic > constraints[pathLenConstraint]?). > > For example: > "In section 6.1, the text describes basic path validation. This text > assumes that all valid paths begin with certificates > issued by a sin- > gle "most-trusted CA". The algorithm requires the public key of the > CA, the CA's name, the validity period of the public key, and any > constraints upon the set of paths which may be validated using this > key." > > Section 6.2 also refers to making use of the certificate's extensions > to limit the path. > "Limitations in the trust paths for any particular key may > be incorporated into the self-signed certificate's extensions. In > this way, the self-signed certificates permit the path validation > module to automatically incorporate local security policy and > requirements." > > If the trust anchor information is provided in the form of a > self-signed > certificate, we can certainly extract the five pieces of trust anchor > information mentioned in Section 6.1.1. > > Should we also be extracting other information from the certificate, > such as policy constraints, policy mappings, name constraints, and > basic constraints, and using these to initialize the relevant state > variables? What about the validity period of the public key? > Do we need to verify that the self-signed certificates's > validity period > includes time T? > > Do we need to validate the self-signed certificate itself? > (i.e. do we have to verify the self-signed certificate's signature, > revocation status, name chaining, uid chaining, that any > certificate policies and policy mappings are processed, > that it is a CA cert, that it has a keyCertSign key usage asserted, > that all critical extensions are processed?) > > If the trust anchor information is trusted because it > was delivered "out-of-band", can we use non-self-signed > certificates to provide the trust anchor information? > Perhaps I have a certificate that is not self-signed that I > trust for some "out-of-band" reason. I would think > that I should be able to use this certificate as a trust anchor > since I have designated it as trusted. If this is allowed, > it should be noted that we will not be able to > validate the signature, revocation status, name chaining, > and uid chaining checks because these checks rely > on a "previous" certificate's values which we don't have. > > One approach would be to not validate any part of > the trust anchor certificate and simply accept it > (whether or not it is self-signed) > because the user has designated it as "trusted", but > to extract any relevant information. In other words, > we wouldn't perform any of the steps in > 6.1.3 (Basic Certificate Processing) but we would > perform all the steps in 6.1.4 (Preparation for > Certificate i+1). > > All of these questions need to be answered explicitly > so that we can all process trust anchor certificates in > a standard way. > > -Yassir. > > > > Received: from certplus.com (facteur.certplus.com [195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09413 for ; Wed, 21 Jun 2000 06:48:04 -0700 (PDT) Received: from certplus.com (nt4_jmd.certplus.com [192.168.1.17]) by certplus.com (8.8.7/8.8.7) with ESMTP id OAA30170 for ; Wed, 21 Jun 2000 14:18:56 +0200 Message-ID: <3950C7CF.7F57A0EB@certplus.com> Date: Wed, 21 Jun 2000 15:49:03 +0200 From: Jean-Marc Desperrier Organization: Certplus X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter Lipp wrote: > > However, it does NOT necessarily say that the same > > 'timestamping' key can not be used for signing whatever else, for > > example a certificate. > > Looking at the current draft it says: > > A TSA is REQUIRED ... > 10. to sign each time stamp token using a key generated > exclusively for this purpose and have this property of the > key indicated on the corresponding certificate. > > I read "exclusively for this purpose" as "not allowed for signing > certificates". I wrote another answer before, but it seems I have sent it to Michael Zolotarev instead of to the list. It seems that the beginning of 2.3 and point 10 of 2.2 are a rewording of each other. After rereading, paragraph 2.3 does not explicitely forbid keyCertSign to be asserted, as this is a key usage bit, and not an extended keyusage. This said, if we take into account point 10, it sounds like this key usage bit should not be asserted. It would more explicit to have a list in the draft of the key usage bits that must/musn't be asserted. The message about the use of "certificates as trust anchor" suggests that it should not be necessary that the key usage bitfield of a self-signed certificate has the keyCertSign set for it to be accepted as a trust anchor. This seems to me to make sense. But from a practical point of view what does self-signed TSA cert means ? That there has been at least one point of time where your TSA hardware crypto module has been able to sign something that is not a time-stamp. I think that if a TSA is under a formal evaluation process, it will have to prove it's "impossible" to get it to sign something that is not a valid time stamp. Of course, the signing of this certificate would be done in an initial step, before the hardware crypto module is inserted inside the actual TSA operation process, but it does not sound that great. Also couldn't there be circonstances, where we would have to generate a new certificate, if the policy changes, etc... ? Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07210 for ; Wed, 21 Jun 2000 05:23:34 -0700 (PDT) Received: from PLIPP2 [129.27.152.34] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A3B2989012A; Wed, 21 Jun 2000 14:23:14 +0200 Received: from 127.0.0.1 [127.0.0.1] by PLIPP2 (IAIK S/MIME Mapper 2.0beta3 22/March/2000); Mi, 21 Jun 2000 14:24:12 +0100 From: "Peter Lipp" To: "Michael Zolotarev" , "Jean-Marc Desperrier" , Subject: AW: self-signed TSA [Was Re: Private Key Cloning] Date: Wed, 21 Jun 2000 14:24:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.776CFB97--"; protocol="application/x-pkcs7-signature" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.776CFB97-- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > However, it does NOT necessarily say that the same > 'timestamping' key can not be used for signing whatever else, for > example a certificate. Looking at the current draft it sais: A TSA is REQUIRED ... 10. to sign each time stamp token using a key generated exclusively for this purpose and have this property of the key indicated on the corresponding certificate. I read "exclusively for this purpose" as "not allowed for signing certificates". Peter ----IAIK.SMIME.MAPPER.776CFB97-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVIDCCBE0wggM5oAMCAQICAwGGrTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTEyODIwMjIzOVoXDTAwMTEy ODIwMjIzOVowgZMxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxEzARBgNV BAMTClBldGVyIExpcHAwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBAM5s1aJQ xXxczmMNSJtL4cv9nhMA+dtbUN4+DA5qfZBqcwR2zWw2VulPyrAeZDA1HFP8zlpk PlC5C4hNnX+p7QdG8u0LMk45FwaatOm2r2gEmTYGH/znwQSrKTsZXi0d0VHZV0TX yU/I3SlYxSXfjFafAVE09KKa2m8jcUOhF97dAgEDo4G0MIGxMDgGA1UdHwQxMC8w LaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlLQ1JMMTAR BglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2VydGlmaWNh dGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAdBgNVHREEFjAUgRJQZXRlci5MaXBw QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEBAA4r/qDOLW8ChbuC 2pGzcf74Uv190Q45aHj99lMgNhPQRIVaLLNXJH+NYJxEvIwmVOWIXjdA03TqkOOq FJ/tK31wV+RbrvaPaVUwRjPhC2f8rr+K6pp9mzUC1SolUEbRWVHgOZGsbnEJkTEr oJOelFdKr0coT+Xeje/fI5d50P3CwsJLR2PFkiswnOoWBINi2nq6MGZ7fwmzW8F9 ZVstrNMQYCeEj4V2SR/YIUrDxsdqMQyorBe/su3eab3fOpPlonb86KKWH6jLdgpi KGRoHGWeGgAWlMB0HdxaupX7Lm8LhVYZOdh9SpvO8AdhMyOXNHOKF6sMXCZvSEHy 2XUvbmAwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZMQswCQYDVQQGEwJB VDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg YW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElOVFJBTkVUIENBMB4X DTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQswCQYDVQQGEwJBVDEP MA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYDVQQJExBJbmZmZWxk Z2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9H WTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFO RVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAgBgNVBAwTGUlBSUsg ZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEBAQUAA4IBDQAwggEI AoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwVHu1+XFLJeJ85AICk SQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/hEb1T7XgO12ptG80q SOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4HkrNw5uH/vsJ72wRcRT FzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5FfCknoMMCitSD38cUL CCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64SurLoUUShPv108ELE 6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgBhvhCAQEEBAMCAAIw DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4DAh0FAAOCAQEAc26n vl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUcePEmXkKsFP4NuCFx 2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZUkx99K70ncVxkwq7 rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOKPbrBjZxjmXwBbZ7t sfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQF50+Pt8ioAgZ/SAu dxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTDkRLD/h8LKC1OpKV8 lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZIhvcNAQEEBQAwgZkx CzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5P TE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24g UHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5U UkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1OTMwWjCBmTELMAkG A1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQSUFJSyBJTlRSQU5F VCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMLr+IHe6qeAtYLk fvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnzh2MuAq84JS58zX5x LqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/BWlXuZU33lgGky/R X84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVDQaQw+HRCvr7T4mAV Yi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0unIYWwUn1YzQI2RNB AjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWoi+btPX8oWDl5+7DE tCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3 DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/oGofngJzbQLa7X2s hWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVeqScURuwuihFURPhI 7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347dXhKJOYJ0tsA583af EKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgDZ4NcCpiRSv9mWw6s PYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRGRztKQWeUiBLkqFCQ xsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIETTCCAzmgAwIBAgIDAw1NMAkG BSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYD VQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1H UkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUg Zm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNh dGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZBgNVBAMTEklBSUsg VFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRlbnRpYWxpdHkgQ0Ew HhcNOTkxMTI4MjAyMzM4WhcNMDAxMTI4MjAyMzM4WjCBkzELMAkGA1UEBhMCQVQx JjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQL Ez5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFu ZCBDb21tdW5pY2F0aW9uczETMBEGA1UEAxMKUGV0ZXIgTGlwcDCBnTANBgkqhkiG 9w0BAQEFAAOBiwAwgYcCgYEAvQe3ZdxrE2Nv5z2ZLink1P2MFeQb5gYrS55w4jsX ZGD5v9Ajnv3w30Ajcn7jI+blIvYYpmNQV476+aUHNZFUML/KN5WGVXfdBOxb2n+6 Porez8KMnUlq3cCvAdhVdquFjwaRHO5k7gY80hNAfVker52A1aXbrT0TaWGlCl25 sq0CAQWjgbQwgbEwOAYDVR0fBDEwLzAtoCugKaQnMCUxEDAOBgNVBAoTB2lhaWsu YXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG+EIBAQQEAwIAoDAoBglghkgB hvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAMBgNVHRMEBTADAQEA MB0GA1UdEQQWMBSBElBldGVyLkxpcHBAaWFpay5hdDALBgNVHQ8EBAMCA3gwCQYF Kw4DAh0FAAOCAQEAhvbZ0/1a47YqiCYjsnsqxWhFufL9oPQzzK9sBDjZZwbpPnhD ZN8PmBqWUXAo74a6oz7Q0W1QieAPCIGenFcVe5ui9m+9TDwtrQN1ECE5k3VuGlh9 l+1Sw5GjFEynARTDmaSRIc75EV/nx4a1LuHLkRYGC5Mg6LskWpIw7ShdPD54U/3Q 19iboaASh0ynfySjBsy1549hQcmi9UfMMX7u1QCCia2kd15u+YaVxtWoMHFB59q6 ELx+9XseEpEI/zBlvSwdyDTXWtnlxnzZjsyk0a/W+FpdeuZ7k2Dbf/Owx0nXS70M HrH/AErvvbhxJ1BaAPC6TAN6da4xPpwy5XSRfjCCBFQwggNAoAMCAQICAnUwMAkG BSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1 OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8wDQYDVQQIEwZTdHlyaWExDTALBgNVBAcT BEdyYXoxGTAXBgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVog VU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3Ig QXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9u czEZMBcGA1UECxMQSUFJSyBJTlRSQU5FVCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1H UkFaIENSWVBUMSAwHgYDVQQMExdJQUlLIGNvbmZpZGVudGlhbGl0eSBDQTCCASAw DQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBAMEnzjatic90xi5VRmr0i2O16Z1a SElQFZitoNvAzGw+KehOTuKeUr5ALHib9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKy qvZ+KphGy6ag6VcCVySJmeY1AqTM0W78XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNg o4UMVdxjGHJweibT1AGvlFe2BqulwtuwOLovMIuIyHHh+o6F2HXYKUB54GJpia1B 2IfmqcpBBFdYtDlHyrxugB5QhuhLo0BjD8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl1 2cZKkqaqPpOgP/znsdh62QBSabrRluvCp9OQW9M8u+mJlrxIIVwtThfzIW0CAQWj MzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQE AwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4JIzqbBydvFOaP/dA5D/GLWEWjPTF8tKcP hxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0C uxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64 vGX+ayZn2P7naGHPfYjCBWUKzW0zS8chVf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSL CMmFEDc99iNzcCU7ILn+RgWPNYPVhCUqoDQ6buX00ohfNVS/OHgqkWpa1HLvLRXq E9NmYUJvfhE2zCY6w6bTME3IfDCXRat2Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEw ggEcMIIBEzELMAkGA1UEBhMCQVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxME R1JBWjEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z MRkwFwYDVQQLExBJQUlLIElOVFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdS QVogU0lHMSIwIAYDVQQMExlJQUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlAgMBhq0w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wMDA2MjExMjI0MTJaMCMGCSqGSIb3DQEJBDEWBBRrrjN33h5Y+qa7 g3/Voc3rKycbqjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzAN BgkqhkiG9w0BAQEFAASBgB7/jeAJfY+Z+SuuGXi0yFY9DAngS/ijX8eNgLicIpAG O4aAyiyhLqYWfAbozXOWWgnNUJK/fMvo7RjsnSgr899XzBDHrleeYzBcO+G15UNK 9zJ+OaeSp2c6wtMaKIUXweDbU3eIsg0YnYcnIGaDfkVluZremHWGegiY3HREu+QS AAAAAAAA ----IAIK.SMIME.MAPPER.776CFB97---- Received: from FW-BEL.utimaco.be ([193.121.107.230]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03197 for ; Wed, 21 Jun 2000 03:31:23 -0700 (PDT) Received: (from uucp@localhost) by FW-BEL.utimaco.be (8.9.3/8.9.3) id MAA03479 for ; Wed, 21 Jun 2000 12:33:56 +0200 (CEST) (envelope-from frederik.loeckx@utimaco.be) Received: from (belgien1.utimaco.be [10.7.0.25]) by FW-BEL.utimaco.be via smap (V2.1) id xma003477; Wed, 21 Jun 00 12:33:35 +0200 Received: by belgien1.utimaco.be(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id C1256905.00393467 ; Wed, 21 Jun 2000 12:24:49 +0200 X-Lotus-FromDomain: UTIMACO From: "Frederik Loeckx" To: ietf-pkix@imc.org Message-ID: Date: Wed, 21 Jun 2000 12:24:45 +0200 Subject: PKIStatusInfo inside draft-ietf-pkix-time-stamp-08.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello, A somewhat less philosophical question as cloning keys: Inside RFC2510bis, PKIStatusInfo is defined as PKIStatusInfo ::= SEQUENCE { status PKIStatus, statusString PKIFreeText OPTIONAL, failInfo PKIFailureInfo OPTIONAL } In draft-ietf-pkix-time-stamp-08.txt, the second field, statusString, disappeared resulting in PKIStatusInfo ::= SEQUENCE { status PKIStatus, failInfo PKIFailureInfo OPTIONAL } So I think this is a little mistake inside the time stamping draft, especially because the statusString field is explicitly mentioned inside the corresponding text of the draft. Kind regards, Frederik Loeckx Received: from mail3.registeredsite.com (IDENT:root@mail3.registeredsite.com [209.35.159.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29988 for ; Wed, 21 Jun 2000 03:00:11 -0700 (PDT) Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by mail3.registeredsite.com (8.9.3/8.9.3) with ESMTP id EAA05892 for ; Wed, 21 Jun 2000 04:56:38 -0400 Received: from arabtrust [213.189.81.49] by mail.arabtrust.com (SMTPD32-6.00) id A2DD18F00EE; Wed, 21 Jun 2000 06:03:09 -0400 From: "Jean Abraham" To: Subject: certification for pki Date: Wed, 21 Jun 2000 13:00:06 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Hi, Is there any internationally accredited certification for PKI Jean Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA27164 for ; Wed, 21 Jun 2000 02:04:37 -0700 (PDT) Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id TAA07862; Wed, 21 Jun 2000 19:04:10 +1000 (EST) Message-ID: <013d01bfdb60$dbe0a820$8802a8c0@eracom.com.au> From: "Simon McMahon" To: "Michael Zolotarev" , , "Paul Koning" , "Juergen Brauckmann" Cc: "David P. Kemp" , , References: <3.0.5.32.20000621092012.0379c8b0@callisto> Subject: Re: Private Key Cloning (TSA keys) Date: Wed, 21 Jun 2000 19:12:10 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Juergen wrote : > As all servers that want to operate according to the German Digital > Signature Law must issue signatures that comply with this law, it is > relevant. > > We hope that a revision of the law will contain a notion of "server > keys/certificates", so that all the things that are not appliable for > CAs/TSAs will disappear... . > So perhaps SigG/SigV compliant TSAs should not attempt load balancing until the revision to the law is released. If the revision is really likely then wont this problem just go away ? > ... With some tricks (mostly not technical) we can get > around entering a PIN for every timestamp issued, but the "no copying a > private key" issue still applies. > Surely this is a better approach, to use tricks to get around the deficiencies in the law, rather than trying to accomidate it in the standard when it gets too messy. Especially if the law is likely to be changed to accomidate CA/TSA servers anyway. I guess the analogy with an accelerater with controlled private key copies within the secure perimeter was not tricky enough to convince you :-). I know of an ITSEC evaluation with SigG/SigV compiance which argued that copies of private keys was OK because they were made in order to move the private key from one module to another within the secure perimieter. It wasn't a TSA, of course, and the existance of two copies was only for an instant before the previous copy was destroyed. We are talking about long term persistance of multiple copies of the private key and doing signatures with them, but as long as they stay within the target of evaluation's secure perimeter ... Regards, Simon. Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA24217 for ; Wed, 21 Jun 2000 00:21:44 -0700 (PDT) Received: by mystic1.trustcenter.de; id JAA18309; Wed, 21 Jun 2000 09:18:44 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma018303; Wed, 21 Jun 00 09:18:44 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id JAA13508; Wed, 21 Jun 2000 09:20:12 +0200 (MET DST) Message-Id: <3.0.5.32.20000621092012.0379c8b0@callisto> X-Sender: jbr@callisto X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Jun 2000 09:20:12 +0200 To: "Simon McMahon" , "Michael Zolotarev" , , "Paul Koning" From: Juergen Brauckmann Subject: Re: Private Key Cloning (TSA keys) Cc: "David P. Kemp" , , In-Reply-To: <010501bfdb47$3caa06c0$8802a8c0@eracom.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA24219 At 16:08 21.06.00 +1000, Simon McMahon wrote: >> ... But the argument has started as a result of the fact >> that some legislations, namely German Digital Signature Law, prohibit key >> cloning. So we've been discussing just one of the possible solutions to >get >> around the restrictions of the law. >> >Is that the SigG / SigV German signature law ? >I thought that was more for personal private keys where authentication data >(e.g. the PIN) is provided for EVERY signature generated by the private key >as well as "no copying the private key". Surely that is not relevant to TSA >servers where no one is there to enter a PIN. Funnily it is relevant. CAs that want to operate according to SigG/SigV have to offer a timestamping service. This is a requirement of the law. They have to sign the timestamps with signatures that comply with that law. The current SigG does not recognize the necessity to have server keys/certificate, and so all restrictions to personal private keys apply to CA/TSA operating keys. With some tricks (mostly not technical) we can get around entering a PIN for every timestamp issued, but the "no copying a private key" issue still applies. >Yes, its a question of whether it is within the law, and within which >relevant law. The german signature law that I have indirectly worked with >was very specific but in my opinion not relevant to private keys used by >unattended servers. As all servers that want to operate according to the German Digital Signature Law must issue signatures that comply with this law, it is relevant. We hope that a revision of the law will contain a notion of "server keys/certificates", so that all the things that are not appliable for CAs/TSAs will disappear... . Regards, Juergen -- Juergen Brauckmann Tel.: 040 / 8080 26 311 TC TrustCenter GmbH Fax.: 040 / 8080 26 126 Sonninstraße 24-28 mailto:brauckmann@trustcenter.de 20097 Hamburg http://www.trustcenter.de Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA20749 for ; Tue, 20 Jun 2000 23:01:12 -0700 (PDT) Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id QAA78943; Wed, 21 Jun 2000 16:00:45 +1000 (EST) Message-ID: <010501bfdb47$3caa06c0$8802a8c0@eracom.com.au> From: "Simon McMahon" To: "Michael Zolotarev" , , "Paul Koning" Cc: "David P. Kemp" , , References: Subject: Re: Private Key Cloning (TSA keys) Date: Wed, 21 Jun 2000 16:08:45 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 > ... But the argument has started as a result of the fact > that some legislations, namely German Digital Signature Law, prohibit key > cloning. So we've been discussing just one of the possible solutions to get > around the restrictions of the law. > Is that the SigG / SigV German signature law ? I thought that was more for personal private keys where authentication data (e.g. the PIN) is provided for EVERY signature generated by the private key as well as "no copying the private key". Surely that is not relevant to TSA servers where no one is there to enter a PIN. > I'm still not convinced, though, that the interpretation of the law is > correct. Taking your example with accelerator - would it be regarded as a > breach of the law? If not, and the accelerator is all right, what makes it > dramatically different from cloning the key in the environment which can be > formally certified as a security-equivalent to the accelerator's? > Yes, its a question of whether it is within the law, and within which relevant law. The german signature law that I have indirectly worked with was very specific but in my opinion not relevant to private keys used by unattended servers. > The law is written for general use, and each particular scenario requires > specific peruse. I'm wondering if we are trying to scare ourselves away even > before the law has a chance to "speak out". Would really like to hear from > anybody who has legal expertise and can provide an interpretation of the > German Law for that specific case. > That would be good but I'll be surprised if you get any. What good is legal advice that is not based on actual case law anyway ? There are no TSA's yet (are there ?) let alone cases regarding them ? Using a time-stamping key to self sign TSA certificates looks a bit like a kludge to me to fix a problem that TSA's may not even have. Surely well defined key usage, particularly single key usage, is a good security goal to achieve that this approach undermines. Simon McMahon ERACOM Pty. Ltd. Received: from localhost.localdomain (root@mail4.registeredsite.com [209.35.159.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA20145 for ; Tue, 20 Jun 2000 22:56:23 -0700 (PDT) Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id AAA26042 for ; Wed, 21 Jun 2000 00:53:49 -0400 Received: from arabtrust [195.226.253.30] by mail.arabtrust.com (SMTPD32-6.00) id A9C027A00BA; Wed, 21 Jun 2000 01:59:28 -0400 From: "Jean Abraham" To: Subject: Date: Wed, 21 Jun 2000 08:56:27 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Hi, What are the applications that does or does not support more than 4 hierachies in a digital certificate. Jean Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA17414 for ; Tue, 20 Jun 2000 22:24:42 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id PAA16409; Wed, 21 Jun 2000 15:30:12 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Jun 2000 15:23:50 +1000 Message-ID: From: Michael Zolotarev To: Jean-Marc Desperrier , ietf-pkix@imc.org Subject: RE: self-signed TSA [Was Re: Private Key Cloning] Date: Wed, 21 Jun 2000 15:23:49 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Jean, My interpretation of the current text is: The text mandates that a timestamp token can be only signed with a specific 'timestamping' key, as indicated by the ExtKeyUsage. A timestamp token signed by a key which does not contain that ExtKeyUsage field must be considered invalid. However, it does NOT necessarily say that the same 'timestamping' key can not be used for signing whatever else, for example a certificate. So, I can not see anything in the current text that would prohibit issuing a self-signed TSA certificate. However, I'd suggest that the draft makes it clearer, by adding a comment (in a security section?) about possibility of generating and using self-signed TSA certificates. Regards M > -----Original Message----- > From: Jean-Marc Desperrier [mailto:jean-marc.desperrier@certplus.com] > Sent: Tuesday, June 20, 2000 8:37 PM > To: ietf-pkix@imc.org > Subject: self-signed TSA [Was Re: Private Key Cloning] > > > Michael Zolotarev wrote: > > > I can see a problem with it with self-signed TSA > certificates. Normally, a > > client would be configured to directly trust THAT > [self-signed] TSA cert. > > Having a set of self-signed TSA certificates would be a > configuration > > nightmare for the clients. And then you add another crypto > box to your load > > balancing array on TSS, and then another one... > > It is my understanding of the current draft that a TSA > certificate can not be > self-signed : > > 2.3 : > The TSA MUST sign all time stamp messages with one or more keys > reserved specifically for that purpose. The corresponding certificate > MUST contain only one instance of the extended key usage field > extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID > having value id-kp-timeStamping. This extension MUST be critical. > > If the TSA is self-signed then the private key has been used > for something else > than signing time stamp, and something it does not have the > correct key usage > field for. > > So if self-signed TSA certificate should be enabled, I think > the wording of the > draft should be changed to specify this. > Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA16388 for ; Tue, 20 Jun 2000 21:54:11 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA16225; Wed, 21 Jun 2000 14:59:37 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Jun 2000 14:53:14 +1000 Message-ID: From: Michael Zolotarev To: Simon McMahon , Michael Zolotarev , thayes@netscape.com, Paul Koning Cc: "David P. Kemp" , ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: RE: Private Key Cloning (TSA keys) Date: Wed, 21 Jun 2000 14:53:14 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Simon, (I'm taking luxury of being in the same time zone with you, so I can answer the first :) What you are saying is absolutely right, and technically I believe we all know that it is more practical to clone the keys, than to come up with the solution around it. But the argument has started as a result of the fact that some legislations, namely German Digital Signature Law, prohibit key cloning. So we've been discussing just one of the possible solutions to get around the restrictions of the law. I'm still not convinced, though, that the interpretation of the law is correct. Taking your example with accelerator - would it be regarded as a breach of the law? If not, and the accelerator is all right, what makes it dramatically different from cloning the key in the environment which can be formally certified as a security-equivalent to the accelerator's? The law is written for general use, and each particular scenario requires specific peruse. I'm wondering if we are trying to scare ourselves away even before the law has a chance to "speak out". Would really like to hear from anybody who has legal expertise and can provide an interpretation of the German Law for that specific case. Regards Michael > -----Original Message----- > From: Simon McMahon [mailto:simon@onthenet.com.au] > Sent: Wednesday, June 21, 2000 2:39 PM > To: Michael Zolotarev; thayes@netscape.com; Paul Koning > Cc: David P. Kemp; ietf-pkix@imc.org; Denis.Pinkas@bull.net > Subject: Re: Private Key Cloning (TSA keys) > > > Hi All, > > I've been considering load balancing and Private Key cloning > for another > project (not TSA) but a lot of the issues are the same. I > think the problems > of messing with the client software to fix what looks to me > like a server > problem is a bad idea. Anyway, here is my 2c worth. > > Performance / availablilty is a problem that the TSA server > has and load > balancing is one solution to address that problem. In my > opinion any load > balancing scheme that impacts on the clients will not be very > scalable or > interoperable and should be avoided. In other words cloning > the private key > is necessary to do load balancing transparently to the client base. > > The problem is legislation which boils down to "dont copy > that private key". > > However, if the cloned private keys were controlled in such a > way that they > could not be seperated and used independantly outside a well defined > boundary, e.g. the TSA, couldn't they still be considered as > one instance of > the private key since externally (to the TSA) there would be no way of > knowing that more than one copy exists within the TSA. The > TSA would also > have to show that any loss or theft of any copy of the > private key, for any > amount of time, is detectable and would result in revocation > of that key. > > As an extreme example - consider a hardware accelerator with > two modular > exponentiation processors on board. The TSA application loads > up one private > key but the accelerator splits it into two copies one loaded > into each of > the processors. The TSA application then pumps signature > requests at the > accelerator and has no control over which processor inside > the device does > the operation. The accelerator offers no other services which > would allow > either copy of the private key to be messed around with. If > the accelerator > was evaluated to Fips 140, ITSEC, CC or whatever, then surely > there would be > no problem with the legislation here. > > Scaling that example up to physically seperate devices within > a TSA might > require a security evaluation of the TSA, or at least that > physical part tha > t includes the devices and management processes for them but > wont TSAs need > to be evaluated anyway ? > > Simon McMahon > ERACOM Pty. Ltd. > > ----- Original Message ----- > From: Michael Zolotarev > To: ; Paul Koning > Cc: Michael Zolotarev ; David P. Kemp > ; ; > > Sent: Wednesday, 21 June 2000 13:21 > Subject: RE: Private Key Cloning (TSA keys) > > > > Guys, > > > > Let's talk about one issue at a time. > > > > 1. Using self-signed TSA certs. > > The specifics of timestamping framework, in my opinion, > make it perfectly > > normal and acceptable that a client would trust a TSA > directly. A TSA can > be > > generally considered a TTP, with no pressing need to have a TSA cert > issued > > by other TTP (a CA). Consequently, there should be nothing wrong in > having > > a self-signed TSA certificate. If the current draft > precludes from doing > it, > > or makes the possibility of it confusing, I believe it > should be fixed. > > (This is why I cc-ed Denis on this). > > > > 2. Assuming that using self-signed TSA certs is Ok, then we > do have an > issue > > of handling an array of crypto boxes. The solutions for simplifying > client's > > side trust configuration proposed in the recent traffic > were all about the > > same: making the TSA to allocate a dedicated "signing key", > and to sign > the > > 'real operational' TSA certs with that key. > > I agree that this 'redirection' would simplify the client's > side. The rule > > of trust for the client would be something like "Trust any TSA > certificate, > > signed by THAT key-signing cert". > > > > Note that this makes a TSA operating more like a mini-CA, > signing the > certs > > for the keys it generates itself with yet another key it has [just] > > generated. This creates extra inconvenience for the TSA > management - they > > would have to maintain a separate [and potentially secure] > > procedure/facility. Probably even having to allocate a > different DN for > each > > of the 'operational' certificate as well? But this is not a > huge issue - > who > > cares about poor system administrators :)? > > > > As a conclusion, I personally do not see any problems with > that approach, > > and tend to agree that the problem of key cloning for TSA > can be solved > with > > the 'redirection'. > > > > Regards > > Michael > > > > > > > > > > > -----Original Message----- > > > From: thayes@netscape.com [mailto:thayes@netscape.com] > > > Sent: Wednesday, June 21, 2000 3:07 AM > > > To: Paul Koning > > > Cc: mzolotarev@baltimore.com; David P. Kemp; ietf-pkix@imc.org > > > Subject: Re: Private Key Cloning > > > > > > > > > Paul Koning wrote: > > > > > > > > > > > Michael> I can see a problem with it with self-signed TSA > > > > Michael> certificates. Normally, a client would be > configured to > > > > Michael> directly trust THAT [self-signed] TSA cert. > > > Having a set of > > > > Michael> self-signed TSA certificates would be a configuration > > > > Michael> nightmare for the clients. And then you add > another crypto > > > > Michael> box to your load balancing array on TSS, and > then another > > > > Michael> one... > > > > > > > > So have one of the copies self-sign its own key and in > addition sign > > > > each of the other keys. Is there a problem with that? > > > > > > > > > > I suspect that this would not be acceptable. The draft > > > indicates that TSA > > > keys should only be used for signing timestamps. Your > proposal allows > > > signing other keys (creating certificates) as well. > > > > > > The best solution is to create a separate key that is trusted > > > to create TSA > > > certificates and is used only for that purpose, or to get > > > another (trusted) > > > CA to sign each of the TSA keys. > > > > > > Terry > > > > > > > > > Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA15487 for ; Tue, 20 Jun 2000 21:33:21 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FWH00J01LZTPQ@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 20 Jun 2000 21:33:29 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FWH00JH3LZT6F@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 20 Jun 2000 21:33:29 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 21:27:00 -0700 Content-return: allowed Date: Tue, 20 Jun 2000 21:26:55 -0700 From: Ambarish Malpani Subject: Generalizing the concept of id-pkix-ocsp-nocheck To: ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE2B4149C@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 I was recently having a conversation with a collegue and he asked a question. Here goes: In OCSP, we have support the concept of a CA issuing a special certificate to an OCSP responder, allowing it to respond on its [the CA's] behalf with a special extended key usage flag. We also allow the CA to indicate that the responder's cert does not need to be validated by having it include the id-pkix-ocsp-nocheck extension in the responder's certificate. Why can't the concept of including an id-pkix-ocsp-nocheck extension in a certificate be extended to any arbitrary certificate to indicate that it doesn't need to be validated? If this makes sense, should this capability be specified in son-of-rfc2459? Comments? Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 Received: from diablo.OntheNet.com.au (diablo.OntheNet.com.au [203.10.89.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA15227 for ; Tue, 20 Jun 2000 21:31:18 -0700 (PDT) Received: from msimon (pc3.eracom.com.au [203.144.16.147]) by diablo.OntheNet.com.au (8.9.3/8.9.3) with SMTP id OAA62759; Wed, 21 Jun 2000 14:30:33 +1000 (EST) Message-ID: <00cd01bfdb3a$a2f90c80$8802a8c0@eracom.com.au> From: "Simon McMahon" To: "Michael Zolotarev" , , "Paul Koning" Cc: "David P. Kemp" , , References: Subject: Re: Private Key Cloning (TSA keys) Date: Wed, 21 Jun 2000 14:38:34 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Hi All, I've been considering load balancing and Private Key cloning for another project (not TSA) but a lot of the issues are the same. I think the problems of messing with the client software to fix what looks to me like a server problem is a bad idea. Anyway, here is my 2c worth. Performance / availablilty is a problem that the TSA server has and load balancing is one solution to address that problem. In my opinion any load balancing scheme that impacts on the clients will not be very scalable or interoperable and should be avoided. In other words cloning the private key is necessary to do load balancing transparently to the client base. The problem is legislation which boils down to "dont copy that private key". However, if the cloned private keys were controlled in such a way that they could not be seperated and used independantly outside a well defined boundary, e.g. the TSA, couldn't they still be considered as one instance of the private key since externally (to the TSA) there would be no way of knowing that more than one copy exists within the TSA. The TSA would also have to show that any loss or theft of any copy of the private key, for any amount of time, is detectable and would result in revocation of that key. As an extreme example - consider a hardware accelerator with two modular exponentiation processors on board. The TSA application loads up one private key but the accelerator splits it into two copies one loaded into each of the processors. The TSA application then pumps signature requests at the accelerator and has no control over which processor inside the device does the operation. The accelerator offers no other services which would allow either copy of the private key to be messed around with. If the accelerator was evaluated to Fips 140, ITSEC, CC or whatever, then surely there would be no problem with the legislation here. Scaling that example up to physically seperate devices within a TSA might require a security evaluation of the TSA, or at least that physical part tha t includes the devices and management processes for them but wont TSAs need to be evaluated anyway ? Simon McMahon ERACOM Pty. Ltd. ----- Original Message ----- From: Michael Zolotarev To: ; Paul Koning Cc: Michael Zolotarev ; David P. Kemp ; ; Sent: Wednesday, 21 June 2000 13:21 Subject: RE: Private Key Cloning (TSA keys) > Guys, > > Let's talk about one issue at a time. > > 1. Using self-signed TSA certs. > The specifics of timestamping framework, in my opinion, make it perfectly > normal and acceptable that a client would trust a TSA directly. A TSA can be > generally considered a TTP, with no pressing need to have a TSA cert issued > by other TTP (a CA). Consequently, there should be nothing wrong in having > a self-signed TSA certificate. If the current draft precludes from doing it, > or makes the possibility of it confusing, I believe it should be fixed. > (This is why I cc-ed Denis on this). > > 2. Assuming that using self-signed TSA certs is Ok, then we do have an issue > of handling an array of crypto boxes. The solutions for simplifying client's > side trust configuration proposed in the recent traffic were all about the > same: making the TSA to allocate a dedicated "signing key", and to sign the > 'real operational' TSA certs with that key. > I agree that this 'redirection' would simplify the client's side. The rule > of trust for the client would be something like "Trust any TSA certificate, > signed by THAT key-signing cert". > > Note that this makes a TSA operating more like a mini-CA, signing the certs > for the keys it generates itself with yet another key it has [just] > generated. This creates extra inconvenience for the TSA management - they > would have to maintain a separate [and potentially secure] > procedure/facility. Probably even having to allocate a different DN for each > of the 'operational' certificate as well? But this is not a huge issue - who > cares about poor system administrators :)? > > As a conclusion, I personally do not see any problems with that approach, > and tend to agree that the problem of key cloning for TSA can be solved with > the 'redirection'. > > Regards > Michael > > > > > > -----Original Message----- > > From: thayes@netscape.com [mailto:thayes@netscape.com] > > Sent: Wednesday, June 21, 2000 3:07 AM > > To: Paul Koning > > Cc: mzolotarev@baltimore.com; David P. Kemp; ietf-pkix@imc.org > > Subject: Re: Private Key Cloning > > > > > > Paul Koning wrote: > > > > > > > > Michael> I can see a problem with it with self-signed TSA > > > Michael> certificates. Normally, a client would be configured to > > > Michael> directly trust THAT [self-signed] TSA cert. > > Having a set of > > > Michael> self-signed TSA certificates would be a configuration > > > Michael> nightmare for the clients. And then you add another crypto > > > Michael> box to your load balancing array on TSS, and then another > > > Michael> one... > > > > > > So have one of the copies self-sign its own key and in addition sign > > > each of the other keys. Is there a problem with that? > > > > > > > I suspect that this would not be acceptable. The draft > > indicates that TSA > > keys should only be used for signing timestamps. Your proposal allows > > signing other keys (creating certificates) as well. > > > > The best solution is to create a separate key that is trusted > > to create TSA > > certificates and is used only for that purpose, or to get > > another (trusted) > > CA to sign each of the TSA keys. > > > > Terry > > > > > Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA11018 for ; Tue, 20 Jun 2000 20:22:31 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id NAA15577; Wed, 21 Jun 2000 13:27:45 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Jun 2000 13:21:22 +1000 Message-ID: From: Michael Zolotarev To: thayes@netscape.com, Paul Koning Cc: Michael Zolotarev , "David P. Kemp" , ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: RE: Private Key Cloning (TSA keys) Date: Wed, 21 Jun 2000 13:21:21 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Guys, Let's talk about one issue at a time. 1. Using self-signed TSA certs. The specifics of timestamping framework, in my opinion, make it perfectly normal and acceptable that a client would trust a TSA directly. A TSA can be generally considered a TTP, with no pressing need to have a TSA cert issued by other TTP (a CA). Consequently, there should be nothing wrong in having a self-signed TSA certificate. If the current draft precludes from doing it, or makes the possibility of it confusing, I believe it should be fixed. (This is why I cc-ed Denis on this). 2. Assuming that using self-signed TSA certs is Ok, then we do have an issue of handling an array of crypto boxes. The solutions for simplifying client's side trust configuration proposed in the recent traffic were all about the same: making the TSA to allocate a dedicated "signing key", and to sign the 'real operational' TSA certs with that key. I agree that this 'redirection' would simplify the client's side. The rule of trust for the client would be something like "Trust any TSA certificate, signed by THAT key-signing cert". Note that this makes a TSA operating more like a mini-CA, signing the certs for the keys it generates itself with yet another key it has [just] generated. This creates extra inconvenience for the TSA management - they would have to maintain a separate [and potentially secure] procedure/facility. Probably even having to allocate a different DN for each of the 'operational' certificate as well? But this is not a huge issue - who cares about poor system administrators :)? As a conclusion, I personally do not see any problems with that approach, and tend to agree that the problem of key cloning for TSA can be solved with the 'redirection'. Regards Michael > -----Original Message----- > From: thayes@netscape.com [mailto:thayes@netscape.com] > Sent: Wednesday, June 21, 2000 3:07 AM > To: Paul Koning > Cc: mzolotarev@baltimore.com; David P. Kemp; ietf-pkix@imc.org > Subject: Re: Private Key Cloning > > > Paul Koning wrote: > > > > > Michael> I can see a problem with it with self-signed TSA > > Michael> certificates. Normally, a client would be configured to > > Michael> directly trust THAT [self-signed] TSA cert. > Having a set of > > Michael> self-signed TSA certificates would be a configuration > > Michael> nightmare for the clients. And then you add another crypto > > Michael> box to your load balancing array on TSS, and then another > > Michael> one... > > > > So have one of the copies self-sign its own key and in addition sign > > each of the other keys. Is there a problem with that? > > > > I suspect that this would not be acceptable. The draft > indicates that TSA > keys should only be used for signing timestamps. Your proposal allows > signing other keys (creating certificates) as well. > > The best solution is to create a separate key that is trusted > to create TSA > certificates and is used only for that purpose, or to get > another (trusted) > CA to sign each of the TSA keys. > > Terry > > Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA00560 for ; Tue, 20 Jun 2000 18:18:53 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5L1EDX17452 for ; Tue, 20 Jun 2000 18:14:13 -0700 (PDT) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FWHCYT01.3I3; Tue, 20 Jun 2000 18:18:29 -0700 Message-ID: <395017E5.59EF334D@netscape.com> Date: Tue, 20 Jun 2000 18:18:29 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Zolotarev CC: Paul Koning , ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I agree as well. There is no need for the TSA to check anything about the imprint. This requirement should be removed from the draft. Terry Hayes thayes@netscape.com Michael Zolotarev wrote: > > If I were to generate my imprint with hash algorithm FRED that has a > > 37 byte digest, does it matter to the TSA? No, it does not. So why > > are we saying that the TSA needs to know the OID for FRED, and the > > associated digest length? > > > > The spec says that it's done to consistency-check the length of the > > imprint. Sure, but to what end? If I send a digest generated by FRED > > but truncate it to 31 bytes, what purpose is served by the TSA saying > > "naughty boy you threw away 6 bytes"? I may in fact have a legitimate > > reason for doing this -- just as IPsec has a legitimate reason for > > throwing away some of the hash bytes in the HMAC construct. If it > > actually mattered to the TSA algorithms, that would be one thing. But > > since the only purpose of the check is to do the check, let's get rid > > of it, simplify the spec, make the TSA implementations more reliable, > > and eliminate the need to ECO the spec every time a new hash appears. > > > > paul > > I agree (expecting a public outcry here :). I always felt pretty > uncomfortable with the TSA having to recognise the hash OID and checking the > length. And on top of if, this would now allow a client tp send a NO-HASH > imprint, a clear text, if they want to. > > Michael > > Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27341 for ; Tue, 20 Jun 2000 17:50:09 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA14072; Wed, 21 Jun 2000 10:55:26 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Jun 2000 10:49:00 +1000 Message-ID: From: Michael Zolotarev To: Paul Koning Cc: ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH Date: Wed, 21 Jun 2000 10:48:58 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" > If I were to generate my imprint with hash algorithm FRED that has a > 37 byte digest, does it matter to the TSA? No, it does not. So why > are we saying that the TSA needs to know the OID for FRED, and the > associated digest length? > > The spec says that it's done to consistency-check the length of the > imprint. Sure, but to what end? If I send a digest generated by FRED > but truncate it to 31 bytes, what purpose is served by the TSA saying > "naughty boy you threw away 6 bytes"? I may in fact have a legitimate > reason for doing this -- just as IPsec has a legitimate reason for > throwing away some of the hash bytes in the HMAC construct. If it > actually mattered to the TSA algorithms, that would be one thing. But > since the only purpose of the check is to do the check, let's get rid > of it, simplify the spec, make the TSA implementations more reliable, > and eliminate the need to ECO the spec every time a new hash appears. > > paul I agree (expecting a public outcry here :). I always felt pretty uncomfortable with the TSA having to recognise the hash OID and checking the length. And on top of if, this would now allow a client tp send a NO-HASH imprint, a clear text, if they want to. Michael > Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22012 for ; Tue, 20 Jun 2000 11:56:28 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22783 for ; Tue, 20 Jun 2000 12:56:11 -0600 (MDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA21278 for ; Tue, 20 Jun 2000 14:56:01 -0400 (EDT) Received: from sun.com (edgemont [129.148.75.133]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id OAA12122 for ; Tue, 20 Jun 2000 14:56:01 -0400 (EDT) Message-ID: <394FBBAA.5CF09058@sun.com> Date: Tue, 20 Jun 2000 14:44:58 -0400 From: Yassir Elley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Using certificates as trust anchors Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In looking over draft-ietf-pkix-new-part1-01.txt, a question arises as to how to process trust anchors provided in the form of a self-signed certificate. Since many applications use such certificates as trust anchors, I think it is important for PKIX to explicitly spell out how to process these certificates. Section 6.1.1 describes the five pieces of trust anchor information and mentions that the trust anchor information may be provided in the form of a self-signed certificate. "(d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor infor- mation includes: (1) the trusted issuer name, (2) optionally, the trusted issuer unique identifier, (3) the trusted public key algorithm, (4) the trusted public key, and (5) optionally, the trusted public key parameters associated with the public key. The trust anchor information may be provided to the path process- ing procedure in the form of a self-signed certificate. The trusted anchor information is trusted because it was delivered to the path processing procedure by some trustworthy "out-of-band" procedure. If the trusted public key algorithm requires parame- ters, then the parameters are provided along with the trusted pub- lic key." However, in other parts of Section 6, we find that the algorithm also requires the validity period of the public key, as well as other constraints (presumably this refers to initial name constraints, policy constraints, basic constraints[pathLenConstraint]?). For example: "In section 6.1, the text describes basic path validation. This text assumes that all valid paths begin with certificates issued by a sin- gle "most-trusted CA". The algorithm requires the public key of the CA, the CA's name, the validity period of the public key, and any constraints upon the set of paths which may be validated using this key." Section 6.2 also refers to making use of the certificate's extensions to limit the path. "Limitations in the trust paths for any particular key may be incorporated into the self-signed certificate's extensions. In this way, the self-signed certificates permit the path validation module to automatically incorporate local security policy and requirements." If the trust anchor information is provided in the form of a self-signed certificate, we can certainly extract the five pieces of trust anchor information mentioned in Section 6.1.1. Should we also be extracting other information from the certificate, such as policy constraints, policy mappings, name constraints, and basic constraints, and using these to initialize the relevant state variables? What about the validity period of the public key? Do we need to verify that the self-signed certificates's validity period includes time T? Do we need to validate the self-signed certificate itself? (i.e. do we have to verify the self-signed certificate's signature, revocation status, name chaining, uid chaining, that any certificate policies and policy mappings are processed, that it is a CA cert, that it has a keyCertSign key usage asserted, that all critical extensions are processed?) If the trust anchor information is trusted because it was delivered "out-of-band", can we use non-self-signed certificates to provide the trust anchor information? Perhaps I have a certificate that is not self-signed that I trust for some "out-of-band" reason. I would think that I should be able to use this certificate as a trust anchor since I have designated it as trusted. If this is allowed, it should be noted that we will not be able to validate the signature, revocation status, name chaining, and uid chaining checks because these checks rely on a "previous" certificate's values which we don't have. One approach would be to not validate any part of the trust anchor certificate and simply accept it (whether or not it is self-signed) because the user has designated it as "trusted", but to extract any relevant information. In other words, we wouldn't perform any of the steps in 6.1.3 (Basic Certificate Processing) but we would perform all the steps in 6.1.4 (Preparation for Certificate i+1). All of these questions need to be answered explicitly so that we can all process trust anchor certificates in a standard way. -Yassir. Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19462 for ; Tue, 20 Jun 2000 10:16:57 -0700 (PDT) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id KAA27393; Tue, 20 Jun 2000 10:16:23 -0700 (PDT) Message-Id: <4.2.2.20000620102117.00a85cb0@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 20 Jun 2000 10:22:19 -0700 To: "David P. Kemp" , ietf-pkix@imc.org From: Tony Bartoletti Subject: RE: Private Key Cloning In-Reply-To: <200006201627.MAA07733@roadblock.missi.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:33 PM 6/20/00 -0400, David P. Kemp wrote: >But I remember an old quote (can't remember the source) -- > > "I never met a problem that couldn't be solved with another layer > of indirection." That would have to be Bill Gates ... :) ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19118 for ; Tue, 20 Jun 2000 10:07:35 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5KH2aX22862 for ; Tue, 20 Jun 2000 10:02:37 -0700 (PDT) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FWGQ7G02.R6W; Tue, 20 Jun 2000 10:06:52 -0700 Message-ID: <394FA4AB.B10D2290@netscape.com> Date: Tue, 20 Jun 2000 10:06:51 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: mzolotarev@baltimore.com, "David P. Kemp" , ietf-pkix@imc.org Subject: Re: Private Key Cloning References: <14671.34005.182423.45349@xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul Koning wrote: > > Michael> I can see a problem with it with self-signed TSA > Michael> certificates. Normally, a client would be configured to > Michael> directly trust THAT [self-signed] TSA cert. Having a set of > Michael> self-signed TSA certificates would be a configuration > Michael> nightmare for the clients. And then you add another crypto > Michael> box to your load balancing array on TSS, and then another > Michael> one... > > So have one of the copies self-sign its own key and in addition sign > each of the other keys. Is there a problem with that? > I suspect that this would not be acceptable. The draft indicates that TSA keys should only be used for signing timestamps. Your proposal allows signing other keys (creating certificates) as well. The best solution is to create a separate key that is trusted to create TSA certificates and is used only for that purpose, or to get another (trusted) CA to sign each of the TSA keys. Terry Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18329 for ; Tue, 20 Jun 2000 09:36:23 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA07737 for ; Tue, 20 Jun 2000 12:27:49 -0400 (EDT) Message-Id: <200006201627.MAA07733@roadblock.missi.ncsc.mil> Date: Tue, 20 Jun 2000 12:33:41 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Private Key Cloning To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Zy2YnAfwx0TZodRsz2lfzg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Agree that it is a problem with the architecture you and Gene describe. But I remember an old quote (can't remember the source) -- "I never met a problem that couldn't be solved with another layer of indirection." You could add that layer (a self-signed TSA trust point that signs the server keys), or you could use static load balancing - assign the first 100,000 clients to one server, then stand up another server and assign the next 100,000 clients to it, etc. Not pretty, but not a "nightmare" either. Or you could use server accelerators which allow you to import and export private signature keys. I'm sure there is a market for both tokens which prevent signature key cloning and tokens which allow it, allowing system architects to trade off technical controls with procedural controls. Personally, I prefer technical -- never offer a human the opportunity to be the man-in-the-middle (or the man-at-one-end, since spoofing a token-to-token protocol doesn't require two tokens). > From: Michael Zolotarev > To: "David P. Kemp" , ietf-pkix@imc.org > Subject: RE: Private Key Cloning > Date: Tue, 20 Jun 2000 10:38:35 +1000 > > > > > And it doesn't seem to present insurmountable obstacles to load > > balancing ... why shouldn't each server have its own signature key? > > Is there a reason not to use N certificates with identical > > distinguished names and different public keys? > > > > I can see a problem with it with self-signed TSA certificates. Normally, a > client would be configured to directly trust THAT [self-signed] TSA cert. > Having a set of self-signed TSA certificates would be a configuration > nightmare for the clients. And then you add another crypto box to your load > balancing array on TSS, and then another one... > > M > > > ***************************************************************************** > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ****************************************************************************** Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14297 for ; Tue, 20 Jun 2000 08:55:23 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA25682; Tue, 20 Jun 2000 17:55:20 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 20 Jun 2000 17:55:20 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA16590; Tue, 20 Jun 2000 17:55:19 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA13727; Tue, 20 Jun 2000 17:55:18 +0200 (MET DST) Date: Tue, 20 Jun 2000 17:55:18 +0200 (MET DST) Message-Id: <200006201555.RAA13727@emeriau.edelweb.fr> To: kent@bbn.com Subject: Re: Can we form certificates with just name and e-mail address Cc: ietf-pkix@imc.org Why not using an alternature subject with an email and the x.509 extension for the name parts. Subject directory attributes extension This field conveyes and desired Directory attribute values for the subject of the certificate. This field is defined as follows: subjectDirectoryAttributes EXTENSION ::= { SYNTAX AttributesSyntax IDENTIFIED BY id-ce-subjectDirectoryAttributes } AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute id-ce-subjectDirectoryAttributes :: OBJECT IDENTIFIER ::= {id-ce 9} Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11233 for ; Tue, 20 Jun 2000 08:20:56 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA29467; Tue, 20 Jun 2000 11:20:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20000620004422.00c11850@mail.accurata.se> References: <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> <4.3.2.7.2.20000620004422.00c11850@mail.accurata.se> Date: Tue, 20 Jun 2000 11:13:52 -0400 To: Stefan Santesson From: Stephen Kent Subject: Re: Can we form certificates with just name and e-mail address Cc: "PKIX Mailing List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Stefan, >Steve, > >Thank's for useful input. Just to round this up, can you confirm the >conclusion that issuing certificates where subjects are represented >by just e-mail address + givenName + surname (and maybe also >country) is simply not possible. > >The name must simply be combined with a serialNumber attribute or >some other information that makes the name (with e-mail address >excluded) a reasonable DN. > >Right? Well, its possible to issue certs with any sort of DN. The question is what makes sense given the semantics of a DN, not just viewing it as a string of AVAs irrespective of context. The question I would ask is what would the directory tree look like given a proposed DN. How would the tree be distributed and managed? Think about the schema with those considerations in mind. For example, if one uses a geopolitical and organizational structure, which is the common model for DNs, we see lots of reasonable options for dividing the tree and determining who is responsible for maintainign what portions of it. On the other hand, if a DN consists of an e-mail address plus givenname and surname, this seems rather odd. The e-mail address, as a single attribute, results in a very broad fan out under the root. (in contrast, if one used DC attributes, as mentioned recently, one could mimic the structure of the DNS, which is well suited for separation and distributed maintenance, as the DNS has shown.) Since e-mail addresses are already globally unique, what does the given name and surname do for you, from a tree structure standpoint? Steve Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10049 for ; Tue, 20 Jun 2000 08:05:04 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiuki21067; Tue, 20 Jun 2000 15:04:43 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA09372; Tue, 20 Jun 00 11:01:03 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA14482; Tue, 20 Jun 2000 11:04:42 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14671.34826.394447.525886@xedia.com> Date: Tue, 20 Jun 2000 11:04:42 -0400 (EDT) To: mzolotarev@baltimore.com Cc: ietf-pkix@imc.org, Denis.Pinkas@bull.net Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid >>>>> "Michael" == Michael Zolotarev writes: Michael> Folks, Haven't we already had a discussion about hash Michael> algorithm for messageImprint? Michael> I believe that the consensus was (and it is 100% reflected Michael> in the current draft) to allow a user to use whatever digest Michael> he/she wants. It is NOT a TSA concern if a user used 'weak' Michael> hash. The TSA does not inspect, modify, store or analyse the Michael> content of messageImprint - it only checks that the length Michael> of the hash corresponds to the hash algorithm. If so, then Michael> why should the draft imply any limitations on type of digest Michael> algorithms, except saying that they must be known? Michael> The position of the draft is, if I interpret it correctly: Michael> 1) The TSA does not care about hash algorithm used in Michael> messageImprint. But the algorithm must be known, to allow Michael> TSA to sanity-check the length of digested data. 2) The Michael> user is ADVICED to use strong hash, such as SHA-1 or MD5. Michael> This position of the draft with regards to hash is general, Michael> and provides enough space to grow, instead of being Michael> unnecessary restrictive. Can we leave it in peace :)? Can we remove this unnecessary restrictions instead? A rule of thumb of protocol design is that requirements are put in because they are necessary for interoperability. In the case we have here, that rule of thumb doesn't apply. If I were to generate my imprint with hash algorithm FRED that has a 37 byte digest, does it matter to the TSA? No, it does not. So why are we saying that the TSA needs to know the OID for FRED, and the associated digest length? The spec says that it's done to consistency-check the length of the imprint. Sure, but to what end? If I send a digest generated by FRED but truncate it to 31 bytes, what purpose is served by the TSA saying "naughty boy you threw away 6 bytes"? I may in fact have a legitimate reason for doing this -- just as IPsec has a legitimate reason for throwing away some of the hash bytes in the HMAC construct. If it actually mattered to the TSA algorithms, that would be one thing. But since the only purpose of the check is to do the check, let's get rid of it, simplify the spec, make the TSA implementations more reliable, and eliminate the need to ECO the spec every time a new hash appears. paul Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09026 for ; Tue, 20 Jun 2000 07:51:04 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiukh27143; Tue, 20 Jun 2000 14:51:02 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA09146; Tue, 20 Jun 00 10:47:22 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA14474; Tue, 20 Jun 2000 10:51:01 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14671.34005.182423.45349@xedia.com> Date: Tue, 20 Jun 2000 10:51:01 -0400 (EDT) To: mzolotarev@baltimore.com Cc: "David P. Kemp" , ietf-pkix@imc.org Subject: RE: Private Key Cloning References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid >>>>> "Michael" == Michael Zolotarev writes: >> And it doesn't seem to present insurmountable obstacles to load >> balancing ... why shouldn't each server have its own signature >> key? Is there a reason not to use N certificates with identical >> distinguished names and different public keys? >> Michael> I can see a problem with it with self-signed TSA Michael> certificates. Normally, a client would be configured to Michael> directly trust THAT [self-signed] TSA cert. Having a set of Michael> self-signed TSA certificates would be a configuration Michael> nightmare for the clients. And then you add another crypto Michael> box to your load balancing array on TSS, and then another Michael> one... So have one of the copies self-sign its own key and in addition sign each of the other keys. Is there a problem with that? paul Received: from smtp0.atl.equifax.com (smtp0.atl.equifax.com [216.46.96.116]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08199 for ; Tue, 20 Jun 2000 07:22:46 -0700 (PDT) From: Mcken.Mak@equifax.com Received: from postoffice-2.equifax.com (postoffice-2.equifax.com [192.168.4.11]) by smtp0.atl.equifax.com (Postfix) with ESMTP id E22ED5F; Tue, 20 Jun 2000 10:23:29 -0400 (EDT) Received: from noteswetc15.fin.equifax.com (noteswetc15.fin.equifax.com [172.18.113.65]) by postoffice-2.equifax.com (Postfix) with SMTP id 9B0776A2AA; Tue, 20 Jun 2000 10:22:20 -0400 (EDT) Received: by noteswetc15.fin.equifax.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256904.004F40A2 ; Tue, 20 Jun 2000 10:25:38 -0400 X-Lotus-FromDomain: EQUIFAX To: ietf-pkix@imc.org Cc: ghilborn@csc.com Message-ID: <85256904.004F3324.00@noteswetc15.fin.equifax.com> Date: Tue, 20 Jun 2000 10:24:54 -0400 Subject: Re: Private Key Cloning Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline I agree on what you said. We had done it different for the load balance, the design is to us sub-CAs for the load balance, this may be more complex. The result should be cleaner and for better management for long term, since the serial number and the DN will need special care after service for a while. And as the sub-CA method do no need to clone the CA key at all. Mcken Mak ghilborn@csc.com on 06/19/2000 03:24:05 PM To: ietf-pkix@imc.org cc: (bcc: Mcken Mak/Technology/Equifax) Subject: Re: Private Key Cloning The issue is relevant only for for a very basic PKI. The wish is to have a single trust anchor of one public key, no sub-CAs, yet assure availability and load balance the CA service by cloned copies of the CA server (and its key). This scenario pre-empts by definition each server having its own key. However, it also conflicts with the no-copy rule. -Gene Hilborn dpkemp@roadblock.missi.ncsc.mil on 06/19/2000 02:21:34 PM Please respond to dpkemp@roadblock.missi.ncsc.mil To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: Re: Private Key Cloning > From: Paul Koning > Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT) > To: FRousseau@chrysalis-its.com > Cc: brauckmann@trustcenter.de, ietf-pkix@imc.org > Subject: Re: Private Key Cloning > > >>>>> "FRousseau" == FRousseau writes: > > FRousseau> Juergen, If a private key generated within a hardware > FRousseau> cryptographic module is securely wrapped within that same > FRousseau> module, is then exported to another similar hardware > FRousseau> cryptographic module through an authenticated key exchange > FRousseau> where it is unwrapped and both of these private keys are > FRousseau> then used to perform electronic signatures in a load > FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean > FRousseau> this would not be legal in Germany? > > How would you guarantee that there's no man in the middle? The only > way would be to have a prior out of band secure setup of > authenticating data, such as a shared secret or public keys used for > this key exchange process. While the user of such a device can ensure > that this is done right, the manufacturer of the devices cannot. > > It doesn't surprise me at all to see devices that don't allow this. > It makes good security sense to omit such a capability. > > paul And it doesn't seem to present insurmountable obstacles to load balancing ... why shouldn't each server have its own signature key? Is there a reason not to use N certificates with identical distinguished names and different public keys? Received: from certplus.com ([195.101.88.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22528 for ; Tue, 20 Jun 2000 03:36:25 -0700 (PDT) Received: from certplus.com (nt4_jmd.certplus.com [192.168.1.17]) by certplus.com (8.8.7/8.8.7) with ESMTP id LAA17685 for ; Tue, 20 Jun 2000 11:06:40 +0200 Message-ID: <394F493A.E5CAECCC@certplus.com> Date: Tue, 20 Jun 2000 12:36:42 +0200 From: Jean-Marc Desperrier Organization: Certplus X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: self-signed TSA [Was Re: Private Key Cloning] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Zolotarev wrote: > I can see a problem with it with self-signed TSA certificates. Normally, a > client would be configured to directly trust THAT [self-signed] TSA cert. > Having a set of self-signed TSA certificates would be a configuration > nightmare for the clients. And then you add another crypto box to your load > balancing array on TSS, and then another one... It is my understanding of the current draft that a TSA certificate can not be self-signed : 2.3 : The TSA MUST sign all time stamp messages with one or more keys reserved specifically for that purpose. The corresponding certificate MUST contain only one instance of the extended key usage field extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID having value id-kp-timeStamping. This extension MUST be critical. If the TSA is self-signed then the private key has been used for something else than signing time stamp, and something it does not have the correct key usage field for. So if self-signed TSA certificate should be enabled, I think the wording of the draft should be changed to specify this. Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA18158 for ; Tue, 20 Jun 2000 03:07:17 -0700 (PDT) Received: from secude.com ([141.12.207.27]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id MAA16099; Tue, 20 Jun 2000 12:06:37 +0200 (MET DST) Message-ID: <394F4227.FFBC1AF6@secude.com> Date: Tue, 20 Jun 2000 12:06:31 +0200 From: Hans Schupp Organization: SECUDE GmbH X-Mailer: Mozilla 4.7 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: Aram Perez CC: PKIX Mailing List Subject: Re: Can we form certificates with just name and e-mail address References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0E2F3B897E84257584775E83" Dies ist eine kryptographisch unterzeichnete Nachricht im MIME-Format. --------------ms0E2F3B897E84257584775E83 Content-Type: multipart/mixed; boundary="------------9E538EACC218188EF5083E6D" Dies ist eine mehrteilige Nachricht im MIME-Format. --------------9E538EACC218188EF5083E6D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Aram Perez schrieb: > I haven't seen any provide this answer so here I go: Someone can > correct my ASN.1, but a reason you shouldn't use "e=name@isp.com" > in a/or as a DN is that it does not meet the ASN.1 rules for a DN > (the '@' symbol is not in one of the valid character sets for DNs). > There are a number of "public CAs" that do put the '@' in a DN, but > technically they are incorrect. There is no single valid character set for "DName", only one for each defined "AttributeValueAssertion" (i.e. every pair XX=YY). The email-Attribute (OID 1.2.840.113549.1.9.1) has IA5String as defined character set, which contains the '@' character. So there is no problem. best regards, Hans Schupp --------------9E538EACC218188EF5083E6D Content-Type: text/x-vcard; charset=us-ascii; name="schupp.vcf" Content-Transfer-Encoding: 7bit Content-Description: Visitenkarte für Hans Schupp Content-Disposition: attachment; filename="schupp.vcf" begin:vcard n:Schupp;Hans tel;cell:(+49) 177 / 2452088 (private) tel;fax:(+49) 6151 / 82897 - 26 tel;work:(+49) 6151 / 82897 - 37 x-mozilla-html:FALSE url:http://www.secude.com org:

SECUDE Sicherheitstechnologie
Informationssysteme GmbH
e-security for e-business version:2.1 email;internet:schupp@secude.com adr;quoted-printable:;;NEW ADDRESS:=0D=0ADolivostr. 11=0D=0A;Darmstadt;;D-64293;Germany fn:Hans Schupp end:vcard --------------9E538EACC218188EF5083E6D-- --------------ms0E2F3B897E84257584775E83 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Kryptographische Unterschrift mit S/MIME MIIFGAYJKoZIhvcNAQcCoIIFCTCCBQUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC AzEwggMtMIICFaADAgECAgFOMA0GCSqGSIb3DQEBBQUAMFAxCzAJBgNVBAYTAkRFMRQwEgYD VQQKEwtTRUNVREUgR21iSDErMCkGA1UECxMiU0VDVURFIFRydXN0RmFjdG9yeSBJbmRpdmlk dWFscyBDQTAeFw05OTEwMjgxNTI2MzNaFw0wMTEwMjgxNTI2MzNaMDkxCzAJBgNVBAYTAkRF MRQwEgYDVQQKEwtTRUNVREUgR21iSDEUMBIGA1UEAxMLSGFucyBTY2h1cHAwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAP4CQoNsxm0rCW/ncYHxEGE9H4IStq2k0sAUJrKzBXvA1gkn c1jrMoQDEORcPjdIVoppbgt4xcmGz59GbGzrHQLDYX4wWtbpeuRQ5p//Dpw+ilA+dfH2WvOi v/OT4q04anv4tI1bHmfHjX0K/T9JoWJNduV1mhhBOvi+G/XG6VgjAgMBAAGjgawwgakwDgYD VR0PAQH/BAQDAgTwMBwGA1UdEQQVMBOBEXNjaHVwcEBzZWN1ZGUuY29tMFgGA1UdEgRRME+B F3RydXN0ZmFjdG9yeUBzZWN1ZGUuY29thjRodHRwOi8vd3d3LnNlY3VkZS5jb20vdHJ1c3Rm YWN0b3J5L2luZGl2aWR1YWxzY2EuY3J0MAwGA1UdEwEB/wQCMAAwEQYJYIZIAYb4QgEBBAQD AgCgMA0GCSqGSIb3DQEBBQUAA4IBAQDB4naym+cwkZ9vjIIAJzoiNzsuywA1QiSElOnfnADa dD7NH3DyfRGjI5sjZBKpFuj2GDHXQBQnZikMxWI1H/J14IyZhv8CORIli8OboSfjavpMlQiJ oQOzO8FDk0j2dJBhOsBxkhGoO/GxTMy+xOdFHsBWsHHyQAFWlgdaCSPrgpq9fSDZ8+Kt5XIj pkyiWjkwnGr7espfevPB1weHlrO5tmD+KFKyVZ+cuDjf0ABAQDXP29HFWxve246Ga2SBnv0Y DTdDfIpVkeHbPd9n8LPGte7MNxM4s2GSJ7lY+p/z33TW0na+ZNmhdhaz8jmXSI/BP0Qvjy/b xKYfAKwvBFvLMYIBrzCCAasCAQEwVTBQMQswCQYDVQQGEwJERTEUMBIGA1UEChMLU0VDVURF IEdtYkgxKzApBgNVBAsTIlNFQ1VERSBUcnVzdEZhY3RvcnkgSW5kaXZpZHVhbHMgQ0ECAU4w CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wMDA2MjAxMDA2MzRaMCMGCSqGSIb3DQEJBDEWBBQidGWphAb+tsgvnq5dxaX542Iw3zBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgPOvIk1Svkzm ubyOxfbHFx9/MGtPlsm0/k3DgpHqy3uInSh8bXNdyeMmZDrv3dQQFPqs5SRKufW5pzYCjYXD t4uBDgliygAIJFa9tQSCbtOnYpcLvYlzwgKd76abL2WQOdXUVqvNiHenKi4Fz7b6QXt0/cHs L/4OJyAuAe+0+Iwm --------------ms0E2F3B897E84257584775E83-- Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA10077 for ; Tue, 20 Jun 2000 00:40:35 -0700 (PDT) Received: from Alberti (pc04.secorvo.de [194.45.12.202]) by rom.antech.de (8.9.3/8.9.3) with SMTP id JAA15051; Tue, 20 Jun 2000 09:22:42 +0200 From: "Joerg Voelker" To: "Jean Abraham" , Subject: AW: Date: Tue, 20 Jun 2000 09:42:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Jean, TSA : Time Stamping Authority OCSP: Online Certificate Status Protocol For further information see: http://www.ietf.org/ID.html regards, Joerg >-----Ursprüngliche Nachricht----- >Von: Jean Abraham [mailto:jean.med@arabtrust.com] >Gesendet: Dienstag, 20. Juni 2000 09:27 >An: ietf-pkix@imc.org >Betreff: > > >hi, > >What is TSA, OSCP? > >Jean > Received: from mail5.registeredsite.com (root@mail5.registeredsite.com [209.35.159.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA08966 for ; Tue, 20 Jun 2000 00:26:50 -0700 (PDT) Received: from mail.arabtrust.com (mail.arabtrust.com [216.247.149.19]) by mail5.registeredsite.com (8.9.3/8.9.3) with ESMTP id OAA09479 for ; Mon, 19 Jun 2000 14:24:29 -0400 Received: from arabtrust [206.161.197.58] by mail.arabtrust.com (SMTPD32-6.00) id AD6F1E90102; Tue, 20 Jun 2000 03:29:51 -0400 From: "Jean Abraham" To: Subject: Date: Tue, 20 Jun 2000 10:26:51 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 hi, What is TSA, OSCP? Jean Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA20426 for ; Mon, 19 Jun 2000 20:21:54 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id NAA05471; Tue, 20 Jun 2000 13:27:41 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Tue, 20 Jun 2000 13:21:13 +1000 Message-ID: From: Michael Zolotarev To: ietf-pkix@imc.org Cc: Denis.Pinkas@bull.net Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH Date: Tue, 20 Jun 2000 13:21:12 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Folks, Haven't we already had a discussion about hash algorithm for messageImprint? I believe that the consensus was (and it is 100% reflected in the current draft) to allow a user to use whatever digest he/she wants. It is NOT a TSA concern if a user used 'weak' hash. The TSA does not inspect, modify, store or analyse the content of messageImprint - it only checks that the length of the hash corresponds to the hash algorithm. If so, then why should the draft imply any limitations on type of digest algorithms, except saying that they must be known? The position of the draft is, if I interpret it correctly: 1) The TSA does not care about hash algorithm used in messageImprint. But the algorithm must be known, to allow TSA to sanity-check the length of digested data. 2) The user is ADVICED to use strong hash, such as SHA-1 or MD5. This position of the draft with regards to hash is general, and provides enough space to grow, instead of being unnecessary restrictive. Can we leave it in peace :)? Michael > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: Tuesday, June 20, 2000 1:00 AM > To: seidel@timeproof.de > Cc: FRousseau@chrysalis-its.com; Denis.Pinkas@bull.net; > ietf-pkix@imc.org > Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt > > > >>>>> "Joerg" == Joerg Seidel writes: > > Joerg> Comments inline. > >> TSA implementations MUST support SHA-1. TSA implementations > >> SHOULD support MD5. > > Joerg> I think there are good reasons not to use MD5 in time > Joerg> stamps. They should use a strong hash function in order to > Joerg> achive long validity periods. MD5 is likely to be unsafe (=not > Joerg> collision free) soon and is already discuraged by german > Joerg> authorities. > > Joerg> IF we add a section about algorithms, it should maybe read: > Joerg> "TSA implementations MUST support SHA-1. TSA implementations > Joerg> SHOULD NOT support MD5.". But I think such a section is not > Joerg> very necessary. > > IANAC, but from what I understand the currently known attacks on MD5 > are nowhere near strong enough to justify that. > > I don't have a problem with the current text (SHA-1 required, MD5 > recommended). I do have a problem with text that implies that MD5 is > bad, because I don't know of data that supports such an assertion. > > Also, it doesn't seem like a good idea for the timestamp spec to give > very different signals from the other security specs. If there really > is good reason to say these kinds of things about MD5, let's have them > identified. (German authorities are not a good reason. Cryptanalysis > that shows weaknesses of interesting size would be.) If the issues > are real, changes to MD5 text should be applied across the board. > > paul > Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12258 for ; Mon, 19 Jun 2000 19:04:21 -0700 (PDT) Received: from [207.215.85.217] by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FWF00E34JXDDA@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Mon, 19 Jun 2000 18:53:38 -0700 (PDT) Date: Mon, 19 Jun 2000 18:54:22 -0700 From: Aram Perez Subject: Re: Can we form certificates with just name and e-mail address In-reply-to: <394E5572.67272FC0@netscape.com> To: PKIX Mailing List Message-id: MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Hi Terry, > From: thayes@netscape.com (Terry Hayes) > Date: Mon, 19 Jun 2000 10:16:34 -0700 > To: Stefan Santesson > Cc: Stephen Kent , PKIX Mailing List > Subject: Re: Can we form certificates with just name and e-mail address > > Stefan Santesson wrote: > >> .... >> >> Why can't an e-mail address be part of a reasonable DN? (I guess that's >> what the current text implies) >> > > There is no reason that it can't be. In fact, I believe that e=name@isp.com > is a > perfectly good DN. It's probably not a good DN in the X.509 world, since it > isn't > very helpful in locating the portion of the "global" directory that actually > contains the entry. It is a unique name and probably will work in many LDAP > or > other directory environments. I haven't seen any provide this answer so here I go: Someone can correct my ASN.1, but a reason you shouldn't use "e=name@isp.com" in a/or as a DN is that it does not meet the ASN.1 rules for a DN (the '@' symbol is not in one of the valid character sets for DNs). There are a number of "public CAs" that do put the '@' in a DN, but technically they are incorrect. Regards, Aram Perez [snip] Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA02500 for ; Mon, 19 Jun 2000 17:39:25 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA04073; Tue, 20 Jun 2000 10:45:04 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Tue, 20 Jun 2000 10:38:36 +1000 Message-ID: From: Michael Zolotarev To: "David P. Kemp" , ietf-pkix@imc.org Subject: RE: Private Key Cloning Date: Tue, 20 Jun 2000 10:38:35 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" > > And it doesn't seem to present insurmountable obstacles to load > balancing ... why shouldn't each server have its own signature key? > Is there a reason not to use N certificates with identical > distinguished names and different public keys? > I can see a problem with it with self-signed TSA certificates. Normally, a client would be configured to directly trust THAT [self-signed] TSA cert. Having a set of self-signed TSA certificates would be a configuration nightmare for the clients. And then you add another crypto box to your load balancing array on TSS, and then another one... M Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA29434 for ; Mon, 19 Jun 2000 15:49:51 -0700 (PDT) Received: from santesson.accurata.se (lon-qbu-gyt-vty28.as.wcom.net [195.232.106.28]) by popmail.inbox.se (8.9.3/8.9.3) with ESMTP id AAA24276; Tue, 20 Jun 2000 00:49:25 +0200 Message-Id: <4.3.2.7.2.20000620004422.00c11850@mail.accurata.se> X-Sender: mb517@mail.accurata.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Jun 2000 00:50:22 +0200 To: Stephen Kent From: Stefan Santesson Subject: Re: Can we form certificates with just name and e-mail address Cc: "PKIX Mailing List" In-Reply-To: References: <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Steve, Thank's for useful input. Just to round this up, can you confirm the conclusion that issuing certificates where subjects are represented by just e-mail address + givenName + surname (and maybe also country) is simply not possible. The name must simply be combined with a serialNumber attribute or some other information that makes the name (with e-mail address excluded) a reasonable DN. Right? /Stefan At 15:12 2000-06-19 -0400, Stephen Kent wrote: >Stefan, > >>Steve, >> >> >>At 14:13 2000-06-16 -0400, you wrote: >>>Christopher, >>> >>>>You put your common name (or given name + surname) in the SubjectName field >>>>and your e-mail address in the rfc822Name field in a SubjectAlternativeName >>>>field extension. I don't think that it is too important if the SubjectName >>>>is not unique; the combination of SubjectName and SerialNo has to be >>>>unique. >>> >>>We have had this discussion in this list. The decision was that if >>>you're going to use a DN field (subject name or a directory name as an >>>alt name) then the contents should be "reasonable" in a directory >>>context. That's why, when Denis Pinkas proposed a name form built from >>>DN attributes but not consistent with real directory use, he agreed to >>>define a new data type for it. The bottom line is that just because a >>>name is constructed from directory attributes, that does not make it a >>>reasonable DN. >>Rest deleted .... >> >>So I guess you confirm my conclusion that givenName + surname in the >>subject field, or as a directory name in alt name, does NOT by itself >>form a reasonable DN. Especially since there will be duplicate names. > >Right. > >> >>So the only thing left seams to be putting the names in >>SubjectDirectoryAttributes but I have problems/thoughts with that: >> >>1) What will the current installed base of products say about that? > >I don't know. Many would probably ignore attributes in that extension. > >>2) The latest X.509 version implies that attributes stored in the >>SubjectDirectoryAttributes are primary for authorization and not part of >>the subjects name. > >Right again. > >>It seams that we have no where to go. >> >>Why can't an e-mail address be part of a reasonable DN? (I guess that's >>what the current text implies) > >The argument is that a DN is the name of an entry in the DIT. One would >not create a schema where a e-mail address was tacked onto the end of an >otherwise good DN. It would create an additional layer of the tree that >served no purpose, as it dangles under the real user entry. An e-mail >address is an alternative way of identifying an entity. Thus it is a >perfectly fine attribute for a directory entry, but it makes no sense as >an added attribute in a DN. > >Steve Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28428 for ; Mon, 19 Jun 2000 15:07:11 -0700 (PDT) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id PAA04137 for ; Mon, 19 Jun 2000 15:07:13 -0700 (PDT) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 19 Jun 2000 22:07:12 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 19 Jun 2000 15:07:10 -0700 Message-ID: <8DCFE693DDFFD111AC4100A0C9B8DB940156608F@hdsmsx33.hd.intel.com> From: "Eissa, Mohamed" To: "'ietf-pkix@imc.org'" Subject: Certificate Retrieval from LDAP/CA Date: Mon, 19 Jun 2000 13:12:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Hi, In general, after a user submits a certificate request, is it better to retrieve issued certificates from LDAP server? or from CA server? and why? Also, is PKIX capable of retrieving certificates from LDAP and CA servers or CAs only? Thanks, Mohamed Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26529 for ; Mon, 19 Jun 2000 13:15:27 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA02204; Mon, 19 Jun 2000 16:15:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <000801bfd836$e04a1bd0$0201a8c0@mega.vincent.se> References: <000801bfd836$e04a1bd0$0201a8c0@mega.vincent.se> Date: Mon, 19 Jun 2000 16:11:24 -0400 To: "Anders Rundgren" From: Stephen Kent Subject: Re: A Heretic's view of Certificates Cc: "PKIX-List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Anders, Part of this material, like the Schneier and Ellison article, makes the mistake of equating X.509 with the trusted third party model of VeriSign, CyberTrust, etc. The figure in Section 4 illustrates this bias. The author acts as thought the 10 point list from that article is some sort of holy grail, rather than what is really was, i.e., a list of points of a length inspired by David Letterman. The discussion of revocation is a bit naive. It seems to assume a push model, whereas traditional X.509 is pull, as is OCSP. The argument about the implied net traffic associated with maintaining CRLs for a very large population is just hand waving, with no good analysis. The author places way too much emphasis on the browser model of a PKI, which is not a very good one, especially for the B2B transactions that are the focus of the article. Again, a strawman. The author's most significant criticisms of current PKI models are contained in Section 5, and there are several seriously flawed arguments. For example, he claims that some of the conditions that he sets as requirements cannot be met because existing (already issued) certs do not meet these requirements. This is an interesting criticism, since the suggestion is that one can develop and deploy a new, different system (of the author's design) but cannot reissue certs to meet his declared requirements! He misunderstands options for retention of certs and CRLs in support of NR, and argues that anything that LDAP does not do now will not change. (Anyone who has followed the progress of LDAP would know better!) More errors arise in this discussion, but one ought not be surprised since the goal of this section is as a strawman to motivate the author's proposal. Most, if not all, of what the author proposes, in Section 7, can be effected with X.509 certificates, based on PKI models that are organizational and/or geopolitical in scope, rather than TTP-based PKIs. Some details of his proposals require changes (or usage restrictions) to current e-mail and web protocols. (For example, the function assigned to a secure e-mail proxy could be effected using the S/MIME triple-wrapping feature. The author alludes to signing an "SMTP envelope," which causes me to question the depth of his protocol knowledge.) If these functions were deemed important, they could be supported just as well with X.509 as with his newly minted "credentials." Other aspects of this model merely reflect implementation choices for such PKI elements as certification policy statements. Some aspects of model also appears to be consistent with the ongoing PKIX work on delegated cert path validation, for those who desire to adopt this approach. The model is thus a mix of new data types, implementation options, and a few assurance mandates. Finally, when one gets to the end of this text, it appears to be promotional (marketing) material for some products/services that the author is hoping to sell. So, Anders, what exactly was your point? Steve Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25768 for ; Mon, 19 Jun 2000 12:36:26 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id VAA16668; Mon, 19 Jun 2000 21:36:17 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 19 Jun 2000 21:36:17 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id VAA12480; Mon, 19 Jun 2000 21:36:16 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id VAA13173; Mon, 19 Jun 2000 21:36:16 +0200 (MET DST) Date: Mon, 19 Jun 2000 21:36:16 +0200 (MET DST) Message-Id: <200006191936.VAA13173@emeriau.edelweb.fr> To: Peter.Sylvester@EdelWeb.fr, FRousseau@chrysalis-its.com Subject: RE: TSP Draft 08 Cc: ietf-pkix@imc.org > > Peter, > > I disagree that the addition of the ordering flag is creating any > incompatibility issue since the TSA document is still only an Internet Draft > that should not have been used to develop any commercial product until it > becomes an RFC. In addition, I think it is much more meaningful to require > the flag to be present to indicate that ordering is supported as currently > mandated by the latest TSA document. I did not say that the changings had created any incompatibility in commercial products. I have said the spec is incompatible with the previous texts Some parts of the text had been 'stable' since two years or so, and get suddenly changed. Well, the token format is so small, that modifications of the actual syntax do not really influence product designers to prepare all the other stuff. An implementation that used draft 7 spec and did not set accuracy and by used a serialnumber that contains some encoded value can easily retransform the serialnumber into genTime with the need of using ordering for comparisions. Thje only problem is that when you receive such a time stamp, it doesn't tell that there is ordering. Since the very beginning the ordering was defined solely by the order of the serialnumber. There was no even mention about the order of the genTime values. Thus you could have all kinds of equal genTime values and even genTimes in different order than the serialnumber. In version 8 the serialnumber of the timestamp has no real purpose anymore inside this protocol; it is not used at all in any other protocol elements like in crls or esscertid etc. To resume (somewhat flame) : I disagree with Ed Gerck; the model is not broken, there is simply no service model. > > I agree however that there must be a way for a TSA to publish which of the > ordering services it supports. As a minimum this should be done through the > TSA's policy and it could possibly be done through the Subject Information > Access (SIA) extension from the son of RFC 2459 if it contained a similar > ordering flag. By using the reqPolicy field a requester could then request > the appropriate service if a TSA offers different ordering services. I would like to repeat a question that I had already asked several times on that list: An equivalent of SIA was in drafts of X.509 and 2459. When did this disappear and why? There were two extensions, the other one was telling something about a CA subject. > > I also agree that the document should indicate if a TSA has to set the > ordering in a identical way in ALL of its time stamps. I would think that if > a TSA explicitly indicate that it will not support ordering (e.g. through > the TSA's policy or the SIA extension), Time Stamp tokens issued from this > TSA MUST NEVER have the ordering field set to true. However, if a TSA > explicitly indicate that it will support ordering, all Time Stamp tokens > issued from this TSA SHOULD have the ordering field set to true unless the > TSA can not longer do this because of some technical problems. This would > then be a good reason to use the value of one (1) in the structure > "PKIStatus" (i.e. grantedWithMods). You suggest that a TSA that provides an ordered set may want to switch to a reduced service. Why not just giving an error? An application that really need an order would have to loop and reask until a orderable stamp is returned. If the order is not necessary then I would use the other type of service. Or, if grantedWithMods is done, one can simply add a failurebit indicating that 'order not guaranteed contrary of what is indicated in the TSA's cert.' /P Received: from ponyexpress8.csc.com (ponyexpress8.csc.com [208.219.64.209]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA25477 for ; Mon, 19 Jun 2000 12:27:22 -0700 (PDT) From: ghilborn@csc.com Received: from va-fch31.csc.com ([20.1.107.9] helo=csc.com) by ponyexpress8.csc.com with smtp (Exim 2.12 #1) id 1347C0-00000P-02 for ietf-pkix@imc.org; Mon, 19 Jun 2000 15:26:44 -0400 Received: by csc.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256903.006AD9F5 ; Mon, 19 Jun 2000 15:27:06 -0400 X-Lotus-FromDomain: CSC To: ietf-pkix@imc.org Message-ID: <85256903.006AA56B.00@csc.com> Date: Mon, 19 Jun 2000 15:24:05 -0400 Subject: Re: Private Key Cloning Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline The issue is relevant only for for a very basic PKI. The wish is to have a single trust anchor of one public key, no sub-CAs, yet assure availability and load balance the CA service by cloned copies of the CA server (and its key). This scenario pre-empts by definition each server having its own key. However, it also conflicts with the no-copy rule. -Gene Hilborn dpkemp@roadblock.missi.ncsc.mil on 06/19/2000 02:21:34 PM Please respond to dpkemp@roadblock.missi.ncsc.mil To: ietf-pkix@imc.org cc: (bcc: Gene Hilborn/DEF/CSC) Subject: Re: Private Key Cloning > From: Paul Koning > Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT) > To: FRousseau@chrysalis-its.com > Cc: brauckmann@trustcenter.de, ietf-pkix@imc.org > Subject: Re: Private Key Cloning > > >>>>> "FRousseau" == FRousseau writes: > > FRousseau> Juergen, If a private key generated within a hardware > FRousseau> cryptographic module is securely wrapped within that same > FRousseau> module, is then exported to another similar hardware > FRousseau> cryptographic module through an authenticated key exchange > FRousseau> where it is unwrapped and both of these private keys are > FRousseau> then used to perform electronic signatures in a load > FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean > FRousseau> this would not be legal in Germany? > > How would you guarantee that there's no man in the middle? The only > way would be to have a prior out of band secure setup of > authenticating data, such as a shared secret or public keys used for > this key exchange process. While the user of such a device can ensure > that this is done right, the manufacturer of the devices cannot. > > It doesn't surprise me at all to see devices that don't allow this. > It makes good security sense to omit such a capability. > > paul And it doesn't seem to present insurmountable obstacles to load balancing ... why shouldn't each server have its own signature key? Is there a reason not to use N certificates with identical distinguished names and different public keys? Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24986 for ; Mon, 19 Jun 2000 12:16:09 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA20757; Mon, 19 Jun 2000 15:15:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 19 Jun 2000 15:15:47 -0400 To: Michael Zolotarev From: Stephen Kent Subject: RE: Can we form certificates with just name and e-mail address Cc: Stefan Santesson , PKIX Mailing List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Zolotarev, >Sorry, but I'm not quite getting what is so problematic with what >Christopher and Oscar proposed: > >What really stops me from leaving Subject field empty, and including BOTH my >e-mail address (as RFC822name) and my name/surname as a proper(!) >DirectoryName into SubjectAltName field? > >I believe that the root of the problem is in [mis]interpretation of the >"uniqueness of the name" requirement. The document says in (4.1.2.6 >Subject): >------------- > Where it is non-empty, the subject field MUST contain an X.500 dis- > tinguished name (DN). The DN MUST be unique for each subject entity > certified by the one CA as defined by the issuer name field. A CA may > issue more than one certificate with the same DN to the same subject > entity. >-------------- >This is what Stefan was referring to, right? > >However, there is NO such uniqueness requirement for the DN included into >the SubjectAltName. Or I've missed one. So I do not see a problem with >having a SubjectAltName containing non_unique DN, as long as the rest of the >information in the extension makes it unique. We're in the process of revising the alt subject name text, and one of the proposed changes is to treat it as stringently as the subject name. I believe text citing the uniqueness check, as well as CA verification, has been circulated. Irrespective of this, other traffic I've just sent discusses the question of whether/how an email address fits into a DN. Steve Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24926 for ; Mon, 19 Jun 2000 12:15:55 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA20722; Mon, 19 Jun 2000 15:15:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> References: <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> Date: Mon, 19 Jun 2000 15:12:51 -0400 To: Stefan Santesson From: Stephen Kent Subject: Re: Can we form certificates with just name and e-mail address Cc: "PKIX Mailing List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Stefan, >Steve, > > >At 14:13 2000-06-16 -0400, you wrote: >>Christopher, >> >>>You put your common name (or given name + surname) in the SubjectName field >>>and your e-mail address in the rfc822Name field in a SubjectAlternativeName >>>field extension. I don't think that it is too important if the SubjectName >>>is not unique; the combination of SubjectName and SerialNo has to be unique. >> >>We have had this discussion in this list. The decision was that if >>you're going to use a DN field (subject name or a directory name as >>an alt name) then the contents should be "reasonable" in a >>directory context. That's why, when Denis Pinkas proposed a name >>form built from DN attributes but not consistent with real >>directory use, he agreed to define a new data type for it. The >>bottom line is that just because a name is constructed from >>directory attributes, that does not make it a reasonable DN. >Rest deleted .... > >So I guess you confirm my conclusion that givenName + surname in the >subject field, or as a directory name in alt name, does NOT by >itself form a reasonable DN. Especially since there will be >duplicate names. Right. > >So the only thing left seams to be putting the names in >SubjectDirectoryAttributes but I have problems/thoughts with that: > >1) What will the current installed base of products say about that? I don't know. Many would probably ignore attributes in that extension. >2) The latest X.509 version implies that attributes stored in the >SubjectDirectoryAttributes are primary for authorization and not >part of the subjects name. Right again. >It seams that we have no where to go. > >Why can't an e-mail address be part of a reasonable DN? (I guess >that's what the current text implies) The argument is that a DN is the name of an entry in the DIT. One would not create a schema where a e-mail address was tacked onto the end of an otherwise good DN. It would create an additional layer of the tree that served no purpose, as it dangles under the real user entry. An e-mail address is an alternative way of identifying an entity. Thus it is a perfectly fine attribute for a directory entry, but it makes no sense as an added attribute in a DN. Steve Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24129 for ; Mon, 19 Jun 2000 11:55:51 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA16929; Mon, 19 Jun 2000 14:55:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <394E5572.67272FC0@netscape.com> References: <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> <394E5572.67272FC0@netscape.com> Date: Mon, 19 Jun 2000 14:52:56 -0400 To: thayes@netscape.com (Terry Hayes) From: Stephen Kent Subject: Re: Can we form certificates with just name and e-mail address Cc: Stefan Santesson , PKIX Mailing List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Terry, >Stefan Santesson wrote: > > > .... > > > > Why can't an e-mail address be part of a reasonable DN? (I guess that's > > what the current text implies) > > > >There is no reason that it can't be. In fact, I believe that >e=name@isp.com is a >perfectly good DN. It's probably not a good DN in the X.509 world, >since it isn't >very helpful in locating the portion of the "global" directory that actually >contains the entry. It is a unique name and probably will work in >many LDAP or >other directory environments. I think you mean in the "X.500 world" not "the X.509 world." X.509 deals with certs and CRLs, whereas X.500 is the broader directory environment. DNs are X.500 constructs, not X.509 constructs, so it is in the directory context that one ought to evaluate the appropriateness of a candidate DN. In that context, the example you provide is not a good one, e.g., for the searching reasons you cite, as well as others. David Kemp's suggestion is an example of what one could reasonably do to map a DNS name into the DIT. However, I disagree with David in that a real DN, if it does not begin with a country code attribute, should begin with an international organization attribute (e.g., for the OCRC, NATO, UN, etc.). The DNS, for legacy reasons, has a handful of TLDs that are not country names, which has been the source of numerous name battles, scaling problems, etc. >The RFC deprecates using an email component of the DN as the RFC822 name for >delivering email. This means that you need to put the email address in the >Subject Alternate Name extension as well, to allow S/MIME (and >other) applications >to find it there. It does not mean that it is disallowed as a >component in the >DN. I don't think I would characterize the 2459 discussion of e-mail addresses in names in quite this way. What section 4.1.2.6 says is that newly generated certs should not contain an EmailAddress attribute in the Subject name field. Instead, the preferred approach is to place the e-mail address in a subject alt name of the type rfc822name. If a non-null subject name is present, it may include an EmailAddress attribute, but such inclusion is permitted for backwards compatibility, and it is deprecated. The overall message from this text is that EmailAddress is a directory attribute that has no place in a DN, but we allow it, with prejudice, to avoid breaking existing (S/MIME) systems. Going forward, the right approach is to put an e-mail address into the subject alt name using the name type designed to carry it. Steve Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA23682 for ; Mon, 19 Jun 2000 11:46:15 -0700 (PDT) Received: from Vigenere.secorvo.de (p3E9E7CB1.dip0.t-ipconnect.de [62.158.124.177]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id UAA11461; Mon, 19 Jun 2000 20:28:08 +0200 Message-Id: <4.2.0.58.20000619173932.0097a940@mail.antech.de> X-Sender: hammer.secorvo@mail.antech.de X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 19 Jun 2000 17:44:17 +0200 To: FRousseau@chrysalis-its.com, brauckmann@trustcenter.de From: Volker Hammer Subject: Re: Private Key Cloning Cc: ietf-pkix@imc.org In-Reply-To: <918C70B01822D411A87400B0D0204DFF04C030@panda.chrysalis-its .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi, >Juergen, > >If a private key generated within a hardware cryptographic module is securely wrapped within that same module, is then exported to another similar hardware cryptographic module through an authenticated key exchange where it is unwrapped and both of these private keys are then used to perform electronic signatures in a load balancing situation (e.g. OCSP or TSA server), do you mean this would not be legal in Germany? why you don't want to use two (or more) different key-pairs for different / fallback servers? For every key a similar certificate can be issued. This should not be a problem except for root certificates. For TSA or OCSP servers key cloning seems not to be necessary from my point of view. Regards Volker Hammer. -------------------------------------------------------- Dr.-Ing. Volker Hammer Security Consultant Secorvo Security Consulting GmbH Albert-Nestler-Strasse 9, D-76131 Karlsruhe Tel. +49 721 6105-458, Fax +49 721 6105-455 E-Mail hammer@secorvo.de, http://www.secorvo.de -------------------------------------------------------- PGP-Fingerprint 3C9C AD64 AC6B 64CC FA6B AE8D 2A5D 462D Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22602 for ; Mon, 19 Jun 2000 11:24:19 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id OAA03461 for ; Mon, 19 Jun 2000 14:15:47 -0400 (EDT) Message-Id: <200006191815.OAA03454@roadblock.missi.ncsc.mil> Date: Mon, 19 Jun 2000 14:21:34 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Private Key Cloning To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NG2ebhAazn8tGK/TbEmeFA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc > From: Paul Koning > Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT) > To: FRousseau@chrysalis-its.com > Cc: brauckmann@trustcenter.de, ietf-pkix@imc.org > Subject: Re: Private Key Cloning > > >>>>> "FRousseau" == FRousseau writes: > > FRousseau> Juergen, If a private key generated within a hardware > FRousseau> cryptographic module is securely wrapped within that same > FRousseau> module, is then exported to another similar hardware > FRousseau> cryptographic module through an authenticated key exchange > FRousseau> where it is unwrapped and both of these private keys are > FRousseau> then used to perform electronic signatures in a load > FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean > FRousseau> this would not be legal in Germany? > > How would you guarantee that there's no man in the middle? The only > way would be to have a prior out of band secure setup of > authenticating data, such as a shared secret or public keys used for > this key exchange process. While the user of such a device can ensure > that this is done right, the manufacturer of the devices cannot. > > It doesn't surprise me at all to see devices that don't allow this. > It makes good security sense to omit such a capability. > > paul And it doesn't seem to present insurmountable obstacles to load balancing ... why shouldn't each server have its own signature key? Is there a reason not to use N certificates with identical distinguished names and different public keys? Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21050 for ; Mon, 19 Jun 2000 10:45:08 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA22416 for ; Mon, 19 Jun 2000 13:37:05 -0400 (EDT) Message-Id: <200006191737.NAA22404@roadblock.missi.ncsc.mil> Date: Mon, 19 Jun 2000 13:42:52 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Can we form certificates with just name and e-mail address To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4WQznHPMAzrZebsnHHg4Cw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc > From: Stefan Santesson > > ... > > Why can't an e-mail address be part of a reasonable DN? (I guess that's > what the current text implies) > > /Stefan DNS is a (the only?) universal-coverage name registration system, and although one would never know it by examining current X.509 certificates, "reasonable" does not have to mean "beginning with a Country= RDN". So one reasonable DN might be: "DC=se, DC=accurata, SN=stefan + CN=Stefan Santesson" This is semantically identical to a null DN and an rfc822Name in the subjectAltName extension, and if there were an RFC spelling out some equivalence rules, applications might someday be able to translate between the rfc822Name format and the RDNSequence format as required. Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19607 for ; Mon, 19 Jun 2000 10:17:07 -0700 (PDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e5JHCLX19816 for ; Mon, 19 Jun 2000 10:12:21 -0700 (PDT) Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id FWEVZO01.2S4; Mon, 19 Jun 2000 10:16:36 -0700 Message-ID: <394E5572.67272FC0@netscape.com> Date: Mon, 19 Jun 2000 10:16:34 -0700 From: thayes@netscape.com (Terry Hayes) X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Santesson CC: Stephen Kent , PKIX Mailing List Subject: Re: Can we form certificates with just name and e-mail address References: <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stefan Santesson wrote: > .... > > Why can't an e-mail address be part of a reasonable DN? (I guess that's > what the current text implies) > There is no reason that it can't be. In fact, I believe that e=name@isp.com is a perfectly good DN. It's probably not a good DN in the X.509 world, since it isn't very helpful in locating the portion of the "global" directory that actually contains the entry. It is a unique name and probably will work in many LDAP or other directory environments. The RFC deprecates using an email component of the DN as the RFC822 name for delivering email. This means that you need to put the email address in the Subject Alternate Name extension as well, to allow S/MIME (and other) applications to find it there. It does not mean that it is disallowed as a component in the DN. Terry Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19401 for ; Mon, 19 Jun 2000 10:14:37 -0700 (PDT) Received: from shorter.eng.sun.com ([129.144.250.35]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28635; Mon, 19 Jun 2000 10:14:32 -0700 (PDT) Received: from rosendale (rosendale [129.144.250.155]) by shorter.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id KAA11089; Mon, 19 Jun 2000 10:09:52 -0700 (PDT) Message-Id: <200006191709.KAA11089@shorter.eng.sun.com> Date: Mon, 19 Jun 2000 10:09:53 -0700 (PDT) From: Sharon Liu Reply-To: Sharon Liu Subject: Re: Why is Java still crypto-crippled? To: anders.rundgren@jaybis.com Cc: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UN12bPu1ZTtFMm8JP9ZvOw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4 SunOS 5.7 sun4u sparc Anders, There are on-going works to make strong crypto into JDK. Sun's JCE (Java Cryptography Extension) 1.2.1 is exportable. It is currently in Beta, and its global distribution has restrictions on available crypto strength. Sun has filed a new JCE export application to remove the crypto restrictions in JCE global distribution. Once that application gets approved by the U.S. government, we'll have a single JCE distribution for both domestic and global users. Then we plan to move JCE into JDK (note: JCE was initially introduced as a Java 2 extension due to the U.S export regulations). This is depend on the Java Community Process. Hope this helps a bit. Thanks, Sharon ------------- Begin Forwarded Message ------------- From: "Anders Rundgren" To: "PKIX-List" Subject: Why is Java still crypto-crippled? Date: Sat, 17 Jun 2000 14:44:25 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA13351 List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe I have since quite a while been using W2K (Bill, it IS great!) using strong crypto although I live in Europe. But why can't I get that for JDK? Without special permissions. This is a *serious* threat to Java to be dependent on third-party tools when the "other guy" has it all built-in! Anders Not religious about Java but likes it anyway. ------------- End Forwarded Message ------------- Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09324 for ; Mon, 19 Jun 2000 08:00:07 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiugp23126; Mon, 19 Jun 2000 14:59:55 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA27396; Mon, 19 Jun 00 10:56:15 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA25234; Mon, 19 Jun 2000 10:59:54 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14670.13673.725862.625427@xedia.com> Date: Mon, 19 Jun 2000 10:59:53 -0400 (EDT) To: seidel@timeproof.de Cc: FRousseau@chrysalis-its.com, Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <918C70B01822D411A87400B0D0204DFF04C01F@panda.chrysalis-its.com> <39492EF4.CE266284@timeproof.de> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid >>>>> "Joerg" == Joerg Seidel writes: Joerg> Comments inline. >> TSA implementations MUST support SHA-1. TSA implementations >> SHOULD support MD5. Joerg> I think there are good reasons not to use MD5 in time Joerg> stamps. They should use a strong hash function in order to Joerg> achive long validity periods. MD5 is likely to be unsafe (=not Joerg> collision free) soon and is already discuraged by german Joerg> authorities. Joerg> IF we add a section about algorithms, it should maybe read: Joerg> "TSA implementations MUST support SHA-1. TSA implementations Joerg> SHOULD NOT support MD5.". But I think such a section is not Joerg> very necessary. IANAC, but from what I understand the currently known attacks on MD5 are nowhere near strong enough to justify that. I don't have a problem with the current text (SHA-1 required, MD5 recommended). I do have a problem with text that implies that MD5 is bad, because I don't know of data that supports such an assertion. Also, it doesn't seem like a good idea for the timestamp spec to give very different signals from the other security specs. If there really is good reason to say these kinds of things about MD5, let's have them identified. (German authorities are not a good reason. Cryptanalysis that shows weaknesses of interesting size would be.) If the issues are real, changes to MD5 text should be applied across the board. paul Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08528 for ; Mon, 19 Jun 2000 07:48:20 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiugp02778; Mon, 19 Jun 2000 14:48:19 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA27210; Mon, 19 Jun 00 10:44:39 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA23823; Mon, 19 Jun 2000 10:48:17 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14670.12977.681919.987123@xedia.com> Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT) To: FRousseau@chrysalis-its.com Cc: brauckmann@trustcenter.de, ietf-pkix@imc.org Subject: Re: Private Key Cloning References: <918C70B01822D411A87400B0D0204DFF04C030@panda.chrysalis-its.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid >>>>> "FRousseau" == FRousseau writes: FRousseau> Juergen, If a private key generated within a hardware FRousseau> cryptographic module is securely wrapped within that same FRousseau> module, is then exported to another similar hardware FRousseau> cryptographic module through an authenticated key exchange FRousseau> where it is unwrapped and both of these private keys are FRousseau> then used to perform electronic signatures in a load FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean FRousseau> this would not be legal in Germany? How would you guarantee that there's no man in the middle? The only way would be to have a prior out of band secure setup of authenticating data, such as a shared secret or public keys used for this key exchange process. While the user of such a device can ensure that this is done right, the manufacturer of the devices cannot. It doesn't surprise me at all to see devices that don't allow this. It makes good security sense to omit such a capability. paul Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA07852 for ; Mon, 19 Jun 2000 07:39:06 -0700 (PDT) Received: by mystic1.trustcenter.de; id QAA05317; Mon, 19 Jun 2000 16:37:06 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma005312; Mon, 19 Jun 00 16:36:10 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id QAA29190; Mon, 19 Jun 2000 16:37:39 +0200 (MET DST) Message-Id: <3.0.5.32.20000619163739.00c31670@callisto> X-Sender: jbr@callisto X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 19 Jun 2000 16:37:39 +0200 To: FRousseau@chrysalis-its.com From: Juergen Brauckmann Subject: Re: Private Key Cloning Cc: ietf-pkix@imc.org In-Reply-To: <918C70B01822D411A87400B0D0204DFF04C030@panda.chrysalis-its .com> Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 10:11 19.06.00 -0400, you wrote:=20 >If a private key generated within a hardware cryptographic module is securely wrapped within that=20 >same module, is then exported to another similar hardware cryptographic module through an=20 >authenticated key exchange where it is unwrapped and both of these private keys are then used to=20 >perform electronic signatures in a load balancing situation (e.g. OCSP or TSA server), do you mean=20 >this would not be legal in Germany? It is of course legal if you don't want to conform to the German Digital Signature Act. It is not legal if you operate according to that Act. In fact it's a requirement to the equipment that it's not possible to duplicate the key. It makes some sense to forbid a single user to duplicate it's key if that key is to be used for "valuable" signatures (this minimizes the risk that the key may be stolen or lost unnoticed). The problem is that the current German Signature Act does not take into account that the scenario you described above is necessary for servers. Regards, Juergen --=20 Juergen Brauckmann Tel.: 040 / 8080 26 311 TC TrustCenter GmbH Fax.: 040 / 8080 26 126 Sonninstra=DFe 24-28 mailto:brauckmann@trustcenter.de 20097 Hamburg http://www.trustcenter.de=09 Received: from firewall1.glaxowellcome.com (firewall-user@firewall1.glaxowellcome.com [192.58.204.204]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06257 for ; Mon, 19 Jun 2000 07:23:32 -0700 (PDT) Received: by firewall1.glaxowellcome.com; id KAA28646; Mon, 19 Jun 2000 10:23:45 -0400 (EDT) Received: from ussun2m.glaxo.com(152.51.20.99) by firewall1.glaxowellcome.com via smap (V5.5) id xma028134; Mon, 19 Jun 00 10:22:25 -0400 Received: by ussun2m.glaxo.com id KAA09589; Mon, 19 Jun 2000 10:21:55 -0400 (EDT) Received: from 152.51.60.17 by securemail1.glaxo.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Mon, 19 Jun 2000 10:11:20 -0400 X-Server-Uuid: c7fabf50-5a2e-11d2-968c-00805fc1f894 Received: from 152.51.4.175 by securemail1.glaxo.com with SMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Mon, 19 Jun 2000 05:27:59 -0400 X-Server-Uuid: c7fabf50-5a2e-11d2-968c-00805fc1f894 Received: by ussun1d.glaxo.com id FAA19500; Mon, 19 Jun 2000 05:27:58 -0400 (EDT) Received: by firewall3.glaxowellcome.com; id FAA19426; Mon, 19 Jun 2000 05:20:08 -0400 (EDT) Received: from ns.secondary.com(208.184.76.39) by firewall3.glaxowellcome.com via smap (V5.5) id xma019398; Mon, 19 Jun 00 05:19:44 -0400 Received: from localhost by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA28131; Mon, 19 Jun 2000 02:27:21 -0700 (PDT) Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jun 2000 02:25:55 -0700 Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA28021 for ; Mon, 19 Jun 2000 02:25:54 -0700 (PDT) Received: by mystic1.trustcenter.de; id LAA03029; Mon, 19 Jun 2000 11: 23:54 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma003026; Mon, 19 Jun 00 11:23:09 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id LAA15097 for ; Mon, 19 Jun 2000 11:24:37 +0200 (MET DST) Message-ID: <3.0.5.32.20000619112437.0394c100@callisto> X-Sender: jbr@callisto X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 19 Jun 2000 11:24:37 +0200 To: ietf-pkix@imc.org From: "Juergen Brauckmann" Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt In-Reply-To: <394DE6C6.9CD268D8@timeproof.de> References: <918C70B01822D411A87400B0D0204DFF04C025@panda.chrysalis-its.com> MIME-Version: 1.0 X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA28022 Precedence: bulk List-Archive: http://www.imc.org/ietf-pkix/mail-archive/ List-ID: List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id CAA28131 X-WSS-ID: 1550F58213824-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA06260 At 11:24 19.06.00 +0200, Joerg Seidel wrote: >> If a TSA has more than one key for performance purposes, I would assume they >> are just copies of the same private key cloned in different cryptographic >> modules for performance and load balancing reasons. > >Since it is not possible with some cryptograpic modules to make copies of the >private key... And sometimes not legal... . Regards, Juergen -- Juergen Brauckmann Tel.: 040 / 8080 26 311 TC TrustCenter GmbH Fax.: 040 / 8080 26 126 Sonninstraße 24-28 mailto:brauckmann@trustcenter.de 20097 Hamburg http://www.trustcenter.de Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05840 for ; Mon, 19 Jun 2000 07:10:41 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Jun 2000 10:11:26 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C030@panda.chrysalis-its.com> To: brauckmann@trustcenter.de Cc: ietf-pkix@imc.org Subject: Private Key Cloning Date: Mon, 19 Jun 2000 10:11:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD9F8.4134A830" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD9F8.4134A830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Juergen, If a private key generated within a hardware cryptographic module is securely wrapped within that same module, is then exported to another similar hardware cryptographic module through an authenticated key = exchange where it is unwrapped and both of these private keys are then used to perform electronic signatures in a load balancing situation (e.g. OCSP = or TSA server), do you mean this would not be legal in Germany? Regards, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: Juergen Brauckmann [mailto:brauckmann@trustcenter.de] Sent: Monday, June 19, 2000 5:25 AM To: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt At 11:24 19.06.00 +0200, Joerg Seidel wrote: >> If a TSA has more than one key for performance purposes, I would = assume they >> are just copies of the same private key cloned in different = cryptographic >> modules for performance and load balancing reasons. > >Since it is not possible with some cryptograpic modules to make copies = of the >private key... And sometimes not legal... . Regards, Juergen --=20 Juergen Brauckmann Tel.: 040 / 8080 26 311 TC TrustCenter GmbH Fax.: 040 / 8080 26 126 Sonninstra=DFe 24-28 mailto:brauckmann@trustcenter.de 20097 Hamburg http://www.trustcenter.de=09 ------_=_NextPart_001_01BFD9F8.4134A830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Private Key Cloning

Juergen,

If a private key generated within a hardware = cryptographic module is securely wrapped within that same module, is = then exported to another similar hardware cryptographic module through = an authenticated key exchange where it is unwrapped and both of these = private keys are then used to perform electronic signatures in a load = balancing situation (e.g. OCSP or TSA server), do you mean this would = not be legal in Germany?

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

-----Original Message-----
From: Juergen Brauckmann [mailto:brauckmann@trustcenter.= de]
Sent: Monday, June 19, 2000 5:25 AM
To: ietf-pkix@imc.org
Subject: Re: I-D = ACTION:draft-ietf-pkix-time-stamp-08.txt


At 11:24 19.06.00 +0200, Joerg Seidel wrote:
>> If a TSA has more than one key for = performance purposes, I would assume
they
>> are just copies of the same private key = cloned in different cryptographic
>> modules for performance and load balancing = reasons.
>
>Since it is not possible with some cryptograpic = modules to make copies of the
>private key...

And sometimes not legal... .

Regards,
   Juergen

--
Juergen = Brauckmann          &n= bsp;  Tel.:  040 / 8080 26 311
TC TrustCenter = GmbH            = Fax.:  040 / 8080 26 126
Sonninstra=DFe 24-28      =     mailto:brauckmann@trustcenter.= de
20097 Hamburg   =             http://www.trustcenter.de  

------_=_NextPart_001_01BFD9F8.4134A830-- Received: from mystic1.trustcenter.de (mystic1.trustcenter.de [193.194.157.34]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA28021 for ; Mon, 19 Jun 2000 02:25:54 -0700 (PDT) Received: by mystic1.trustcenter.de; id LAA03029; Mon, 19 Jun 2000 11:23:54 +0200 Received: from nodnsquery(192.168.200.3) by mystic1.trustcenter.de via smap (V5.0) id xma003026; Mon, 19 Jun 00 11:23:09 +0200 Received: from ew-jbr (titan.trustcenter.de [192.168.200.244]) by callisto.trustcenter.de (8.9.3/8.9.3) with SMTP id LAA15097 for ; Mon, 19 Jun 2000 11:24:37 +0200 (MET DST) Message-Id: <3.0.5.32.20000619112437.0394c100@callisto> X-Sender: jbr@callisto X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 19 Jun 2000 11:24:37 +0200 To: ietf-pkix@imc.org From: Juergen Brauckmann Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt In-Reply-To: <394DE6C6.9CD268D8@timeproof.de> References: <918C70B01822D411A87400B0D0204DFF04C025@panda.chrysalis-its.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA28022 At 11:24 19.06.00 +0200, Joerg Seidel wrote: >> If a TSA has more than one key for performance purposes, I would assume they >> are just copies of the same private key cloned in different cryptographic >> modules for performance and load balancing reasons. > >Since it is not possible with some cryptograpic modules to make copies of the >private key... And sometimes not legal... . Regards, Juergen -- Juergen Brauckmann Tel.: 040 / 8080 26 311 TC TrustCenter GmbH Fax.: 040 / 8080 26 126 Sonninstraße 24-28 mailto:brauckmann@trustcenter.de 20097 Hamburg http://www.trustcenter.de Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA27477 for ; Mon, 19 Jun 2000 02:13:17 -0700 (PDT) Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id (multiple receipients); Mon, 19 Jun 2000 11:13:14 +0200 (MET DST) Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id LAA11292; Mon, 19 Jun 2000 11:12:44 +0200 (MEST) Message-ID: <394DE6C6.9CD268D8@timeproof.de> Date: Mon, 19 Jun 2000 11:24:22 +0200 From: Joerg Seidel Organization: timeproof X-Mailer: Mozilla 4.5 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: FRousseau@chrysalis-its.com CC: ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <918C70B01822D411A87400B0D0204DFF04C025@panda.chrysalis-its.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Francois, comments inline. > If a TSA has more than one key for performance purposes, I would assume they > are just copies of the same private key cloned in different cryptographic > modules for performance and load balancing reasons. Since it is not possible with some cryptograpic modules to make copies of the private key... > "The TSA MUST sign all time stamp messages with one or more keys reserved > specifically for that purpose. A TSA MAY have distinct private keys to > accommodate different policies, different algorithms and/or different key > sizes." ... I suggest: "The TSA MUST sign all time stamp messages with one or more keys reserved specifically for that purpose. A TSA MAY have distinct private keys to accommodate different policies, different algorithms, different key sizes and/or to increase the performance." > I agree that TSAs should not use MD5 in their time stamps and MUST only use > strong hash functions (e.g. SHA-1, RIPEMD-160). However, there is nothing > wrong > for a requester to submit a message imprint containing a MD5 hash, which > means > that TSAs should be able accept request with MD5. You are right. If a requester insists on using MD5 it is not up to the TSA to explain him he shouldn't. Joerg -- __________________________________________________________________ Jörg Seidel phone +49-40-76629-1911 Director Technology fax +49-40-76629-551 timeproof GmbH Harburger Schloßstraße 6-12 mailto:seidel@timeproof.de DE 21079 Hamburg http://www.timeproof.de __________________________________________________________________ Received: from keb.roamingfactory.com (aktse.appius.lejonet.telia.com [193.45.212.169] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA24926 for ; Mon, 19 Jun 2000 00:43:48 -0700 (PDT) Received: from roamingfactory.com (localhost [127.0.0.1]) by keb.roamingfactory.com (Postfix) with ESMTP id 513C5136CD; Mon, 19 Jun 2000 09:43:19 +0200 (CEST) X-Mailer: exmh version 2.1.1 10/15/1999 From: Mats.Gustafsson@roamingfactory.com To: "Christopher Williams" Cc: "PKIX Mailing List" Subject: Re: Do people have something against RSA? In-Reply-To: Message from "Christopher Williams" of "Fri, 16 Jun 2000 18:35:18 BST." <003701bfd7b9$5e4e3ad0$d8c4fc3e@darxstar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Mon, 19 Jun 2000 09:43:19 +0200 Sender: magn@roamingfactory.com Message-Id: <20000619074319.513C5136CD@keb.roamingfactory.com> ccwilliams@ntlworld.com said: > However, let's say that I implemented a standard, say TLS, and only > included the mandatory cipher suite, DSA with ephemeral > Diffie-Hellman, SHA-1 and 3-DES encryption. You know what? It > wouldn't work with anything! Everybody else's implementation uses RSA > so mine has to as well, whether I like it or not. Is seems to me that your reasonoing is flawed in that you assume that "everone else" will *not* include the *mandatory* cipher suite. The whole idea of having mandatory cipher suites in the first place is to assure at least one common fall back algorithm. Best regards, //Mats Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20245 for ; Sun, 18 Jun 2000 21:45:40 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id OAA06771; Mon, 19 Jun 2000 14:50:32 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Mon, 19 Jun 2000 14:44:17 +1000 Message-ID: From: Michael Zolotarev To: Stefan Santesson , Stephen Kent Cc: PKIX Mailing List Subject: RE: Can we form certificates with just name and e-mail address Date: Mon, 19 Jun 2000 14:44:12 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sorry, but I'm not quite getting what is so problematic with what Christopher and Oscar proposed: What really stops me from leaving Subject field empty, and including BOTH my e-mail address (as RFC822name) and my name/surname as a proper(!) DirectoryName into SubjectAltName field? I believe that the root of the problem is in [mis]interpretation of the "uniqueness of the name" requirement. The document says in (4.1.2.6 Subject): ------------- Where it is non-empty, the subject field MUST contain an X.500 dis- tinguished name (DN). The DN MUST be unique for each subject entity certified by the one CA as defined by the issuer name field. A CA may issue more than one certificate with the same DN to the same subject entity. -------------- This is what Stefan was referring to, right? However, there is NO such uniqueness requirement for the DN included into the SubjectAltName. Or I've missed one. So I do not see a problem with having a SubjectAltName containing non_unique DN, as long as the rest of the information in the extension makes it unique. Regards Michael > -----Original Message----- > From: Stefan Santesson [mailto:stefan@accurata.se] > Sent: Monday, June 19, 2000 8:44 AM > To: Stephen Kent > Cc: PKIX Mailing List > Subject: Re: Can we form certificates with just name and > e-mail address > > > Steve, > > > At 14:13 2000-06-16 -0400, you wrote: > >Christopher, > > > >>You put your common name (or given name + surname) in the > SubjectName field > >>and your e-mail address in the rfc822Name field in a > SubjectAlternativeName > >>field extension. I don't think that it is too important if > the SubjectName > >>is not unique; the combination of SubjectName and SerialNo > has to be unique. > > > >We have had this discussion in this list. The decision was > that if you're > >going to use a DN field (subject name or a directory name as > an alt name) > >then the contents should be "reasonable" in a directory > context. That's > >why, when Denis Pinkas proposed a name form built from DN > attributes but > >not consistent with real directory use, he agreed to define > a new data > >type for it. The bottom line is that just because a name is > constructed > >from directory attributes, that does not make it a reasonable DN. > Rest deleted .... > > So I guess you confirm my conclusion that givenName + surname in the > subject field, or as a directory name in alt name, does NOT > by itself form > a reasonable DN. Especially since there will be duplicate names. > > So the only thing left seams to be putting the names in > SubjectDirectoryAttributes but I have problems/thoughts with that: > > 1) What will the current installed base of products say about that? > 2) The latest X.509 version implies that attributes stored in the > SubjectDirectoryAttributes are primary for authorization and > not part of > the subjects name. > > It seams that we have no where to go. > > Why can't an e-mail address be part of a reasonable DN? (I > guess that's > what the current text implies) > > /Stefan > Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15015 for ; Sun, 18 Jun 2000 15:43:27 -0700 (PDT) Received: from santesson.accurata.se (t4o68p69.telia.com [62.20.139.189]) by popmail.inbox.se (8.9.3/8.9.3) with ESMTP id AAA25754; Mon, 19 Jun 2000 00:43:18 +0200 Message-Id: <4.3.2.7.2.20000619002817.00c09f00@mail.accurata.se> X-Sender: mb517@mail.accurata.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Jun 2000 00:43:48 +0200 To: Stephen Kent From: Stefan Santesson Subject: Re: Can we form certificates with just name and e-mail address Cc: "PKIX Mailing List" In-Reply-To: References: <003501bfd7b9$58be2080$d8c4fc3e@darxstar> <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Steve, At 14:13 2000-06-16 -0400, you wrote: >Christopher, > >>You put your common name (or given name + surname) in the SubjectName field >>and your e-mail address in the rfc822Name field in a SubjectAlternativeName >>field extension. I don't think that it is too important if the SubjectName >>is not unique; the combination of SubjectName and SerialNo has to be unique. > >We have had this discussion in this list. The decision was that if you're >going to use a DN field (subject name or a directory name as an alt name) >then the contents should be "reasonable" in a directory context. That's >why, when Denis Pinkas proposed a name form built from DN attributes but >not consistent with real directory use, he agreed to define a new data >type for it. The bottom line is that just because a name is constructed >from directory attributes, that does not make it a reasonable DN. Rest deleted .... So I guess you confirm my conclusion that givenName + surname in the subject field, or as a directory name in alt name, does NOT by itself form a reasonable DN. Especially since there will be duplicate names. So the only thing left seams to be putting the names in SubjectDirectoryAttributes but I have problems/thoughts with that: 1) What will the current installed base of products say about that? 2) The latest X.509 version implies that attributes stored in the SubjectDirectoryAttributes are primary for authorization and not part of the subjects name. It seams that we have no where to go. Why can't an e-mail address be part of a reasonable DN? (I guess that's what the current text implies) /Stefan Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14601 for ; Sat, 17 Jun 2000 06:41:14 -0700 (PDT) Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id PAA18267; Sat, 17 Jun 2000 15:27:57 +0200 Reply-To: From: "denis bider" To: "'Anders Rundgren'" , Subject: Off-topic: crypto crippling Date: Sat, 17 Jun 2000 15:40:58 +0200 Message-ID: <000001bfd861$abccb450$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Low In-Reply-To: <000301bfd859$c5f43c70$0201a8c0@mega.vincent.se> [I would have posted this to the sci.crypt newsgroup, but I dislike doing that for several reasons - among them, slow message propagation, spam and last but not the least, I do not have Usenet configured and it takes a while to find a server that carries sci.crypt. Does anyone know of a regular mailing list equivalent to the sci.crypt newsgroup?] Actually, I have heard a rumour that the '128-bit encryption' that Microsoft is shipping with Windows 2000 has actually been tweaked in such a way that it is only 128-bit when observed by a non-clued-in person, but is rather 40-bit for the people who know how it has been designed. In effect, rumour therefore has it that 88 bits out of the 128 are set in such a way that it is extremely easy to find them for someone who knows how. The French are supposed to have found this out, and they are supposed to have been a little bit upset because of this fact. I am not sure how much of this is actually the truth. The person I received this information from might have confused this with the silent "3DES -> DES" fallback in Windows that has been demonstrated lately. Can anyone confirm or deny the above rumour? Anyway. The bottom line is - I think people today are a little bit crazy to use, and even buy, security software as executables without any kind of access to the source code. It is plain stupid, and it gives the country which supplied you with the binaries a perfect weapon for the information wars that are due to ensue sooner or later. The world is not all roses all the time. Remember the several-billion-dollar deal which was lost by the European airplane manufacturer to Boeing because the USA was eavesdropping on their conversations with the purchaser? Iraq, Vatican and several others have learned this lesson when they bought black-box crypto machines from Crypto AG, only to find out that the machine transmits the encryption key almost in plaintext along with the encrypted message. Which, hence, was easily recoverable by folks from the NSA and from the German intelligence agency. denis -----Original Message----- From: Anders Rundgren [mailto:anders.rundgren@jaybis.com] Sent: 17. junij 2000 14:44 To: PKIX-List Subject: Why is Java still crypto-crippled? I have since quite a while been using W2K (Bill, it IS great!) using strong crypto although I live in Europe. But why can't I get that for JDK? Without special permissions. This is a *serious* threat to Java to be dependent on third-party tools when the "other guy" has it all built-in! Anders Not religious about Java but likes it anyway. Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13350 for ; Sat, 17 Jun 2000 04:45:24 -0700 (PDT) Received: from mega (t6o69p39.telia.com [213.64.110.159]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id NAA08097 for ; Sat, 17 Jun 2000 13:46:38 +0200 Message-ID: <000301bfd859$c5f43c70$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: "PKIX-List" Subject: Why is Java still crypto-crippled? Date: Sat, 17 Jun 2000 14:44:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA13351 I have since quite a while been using W2K (Bill, it IS great!) using strong crypto although I live in Europe. But why can't I get that for JDK? Without special permissions. This is a *serious* threat to Java to be dependent on third-party tools when the "other guy" has it all built-in! Anders Not religious about Java but likes it anyway. Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04468 for ; Sat, 17 Jun 2000 00:35:39 -0700 (PDT) Received: from mega (t4o69p117.telia.com [62.20.145.237]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id JAA04574; Sat, 17 Jun 2000 09:36:50 +0200 Message-ID: <000801bfd836$e04a1bd0$0201a8c0@mega.vincent.se> From: "Anders Rundgren" To: , "PKIX-List" Subject: A Heretic's view of Certificates Date: Sat, 17 Jun 2000 10:34:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA04471 Interesting reading. Particularly for PKI "fundamentalists".... -----Original Message----- From: Lynn.Wheeler@firstdata.com To: ansi-epay@lists.commerce.net Date: Friday, June 16, 2000 22:14 Subject: another view of certificates > > >for another view of certificates > >http://www.DGA.co.uk/customer/publicdo.nsf/public/WP-HERESY > > Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22821 for ; Fri, 16 Jun 2000 12:41:48 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id HAA14916; Sat, 17 Jun 2000 07:41:25 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96118448411860>; Sat, 17 Jun 2000 07:41:24 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ccwilliams@ntlworld.com, ietf-pkix@imc.org Subject: Re: Do people have something against RSA? Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Sat, 17 Jun 2000 07:41:24 (NZST) Message-ID: <96118448411860@kahu.cs.auckland.ac.nz> "Christopher Williams" >Can we please start mandating RSA in future? It will make implementing >standards much easier and remove the FUD because I haven't incorporated >support for Diffie-Hellman! Calm down, calm down, it's not that bad. The way it works is that everyone pretends to do DSA+DH until September, then stops pretending on the 20th. The "shall DSA, may RSA" wording of the standards is a bit confusing at first, but it all works out in the long run. (You're new to this, right? :-). Peter. Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21345 for ; Fri, 16 Jun 2000 11:14:14 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA24313; Fri, 16 Jun 2000 14:13:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <003501bfd7b9$58be2080$d8c4fc3e@darxstar> References: <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> <003501bfd7b9$58be2080$d8c4fc3e@darxstar> Date: Fri, 16 Jun 2000 14:13:47 -0400 To: "Christopher Williams" From: Stephen Kent Subject: Re: Can we form certificates with just name and e-mail address Cc: "PKIX Mailing List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Christopher, >You put your common name (or given name + surname) in the SubjectName field >and your e-mail address in the rfc822Name field in a SubjectAlternativeName >field extension. I don't think that it is too important if the SubjectName >is not unique; the combination of SubjectName and SerialNo has to be unique. We have had this discussion in this list. The decision was that if you're going to use a DN field (subject name or a directory name as an alt name) then the contents should be "reasonable" in a directory context. That's why, when Denis Pinkas proposed a name form built from DN attributes but not consistent with real directory use, he agreed to define a new data type for it. The bottom line is that just because a name is constructed from directory attributes, that does not make it a reasonable DN. >Alternatively, you can leave the SubjectName field blank (unusual but the >standard permits it) and put your common name in a directoryName field in >your alternative name and your e-mail address in an rfc822Name. While >you're at it, why not include the URL of your homepage in a uRI field! >Remember that a SubjectAlternativeName is type GeneralNames, which means it >can have any number of elements. But, it is still of type DirectoryName and thus should be a name suitable for use in a directory, as noted above. >On the subject of alternative names, what exactly is an ediPartyName, >anybody? I know that EDI stands for "Electronic Data Interchange" but I >don't know anything more. I always assumed the EDI folks have really exclusive parties and never invite the rest of us. > >Also, I have to say that I think it's crazy that your e-mail address has to >go into an extension, or can only be placed in the name field by means of a >(deprecated) kludge. In a world context, your e-mail address is as >important (at least) as your X-500 characteristics. If I get a personal >certificate, I don't have an "organization" or an "organizational unit" - >it's just me. I agree that having a cert with an alt subject name that is JUST an RFC822 name would be fine. Your comments re O and OU are correct, but perhaps you are missing some context here. The directory distinguishes between organizational persons and residential persons. The latter don't contain an O or OU attribute. Steve Received: from mta02-svc.server.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20214 for ; Fri, 16 Jun 2000 10:35:51 -0700 (PDT) Received: from darxstar ([62.252.196.216]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000616183508.CBTQ10065.mta02-svc.server.ntlworld.com@darxstar> for ; Fri, 16 Jun 2000 18:35:08 +0000 Message-ID: <003701bfd7b9$5e4e3ad0$d8c4fc3e@darxstar> From: "Christopher Williams" To: "PKIX Mailing List" References: <899128A30EEDD1118FC900A0C9C74A34844CA8@bigbird.gradient.com> Subject: Re: Do people have something against RSA? Date: Fri, 16 Jun 2000 18:35:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 OK, maybe RSADSI are litigious and awkward to deal with. I don't know, I've never dealt with them. However, let's say that I implemented a standard, say TLS, and only included the mandatory cipher suite, DSA with ephemeral Diffie-Hellman, SHA-1 and 3-DES encryption. You know what? It wouldn't work with anything! Everybody else's implementation uses RSA so mine has to as well, whether I like it or not. The reality is that RSA is mandatory and DSA the nice optional extra which adds spice and competitive advantage. As to whether the future belongs to RSA or maybe some recent innovation like ECC or some as-yet uninvented scheme, as Microsoft shows, it's not being the best that makes you the winner, it's being the most widespread. So, given that: - RSA's patent is due to expire (news to me, but welcome news) - DSA has patent issues in Europe - Everybody uses RSA anyway; very few use DSA Can we please start mandating RSA in future? It will make implementing standards much easier and remove the FUD because I haven't incorporated support for Diffie-Hellman! Christopher Williams Software engineer, NetLexis Ltd. http://www.netlexis.com "Intelligent Trust" Received: from mta02-svc.server.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA20189 for ; Fri, 16 Jun 2000 10:35:41 -0700 (PDT) Received: from darxstar ([62.252.196.216]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000616183459.CBSI10065.mta02-svc.server.ntlworld.com@darxstar>; Fri, 16 Jun 2000 18:34:59 +0000 Message-ID: <003501bfd7b9$58be2080$d8c4fc3e@darxstar> From: "Christopher Williams" To: "Stefan Santesson" Cc: "PKIX Mailing List" References: <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> Subject: Re: Can we form certificates with just name and e-mail address Date: Fri, 16 Jun 2000 18:07:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 You put your common name (or given name + surname) in the SubjectName field and your e-mail address in the rfc822Name field in a SubjectAlternativeName field extension. I don't think that it is too important if the SubjectName is not unique; the combination of SubjectName and SerialNo has to be unique. Alternatively, you can leave the SubjectName field blank (unusual but the standard permits it) and put your common name in a directoryName field in your alternative name and your e-mail address in an rfc822Name. While you're at it, why not include the URL of your homepage in a uRI field! Remember that a SubjectAlternativeName is type GeneralNames, which means it can have any number of elements. On the subject of alternative names, what exactly is an ediPartyName, anybody? I know that EDI stands for "Electronic Data Interchange" but I don't know anything more. Also, I have to say that I think it's crazy that your e-mail address has to go into an extension, or can only be placed in the name field by means of a (deprecated) kludge. In a world context, your e-mail address is as important (at least) as your X-500 characteristics. If I get a personal certificate, I don't have an "organization" or an "organizational unit" - it's just me. Christopher Williams Software engineer, NetLexis Ltd. http://www.netlexis.com "Intelligent Trust" Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA17893 for ; Fri, 16 Jun 2000 09:33:56 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Jun 2000 16:28:51 UT Received: from exrsa01.rsa.com ([10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA25404 for ; Fri, 16 Jun 2000 12:33:20 -0400 (EDT) Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2448.0) id <293KY97D>; Fri, 16 Jun 2000 09:32:09 -0700 Message-ID: From: "Jacoby, Jeffrey" To: "'ietf-pkix@imc.org'" Subject: CRMF (RFC 2511) and password-based MAC question Date: Fri, 16 Jun 2000 09:31:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Hi, In section 4.4.1 of RFC 2511, on generating a password-based MAC value, there is no recommended minimum (or maximum) length for the salt value. Does anyone have a recommendation for salt length? What's typically used in practice or existing applications? Thanks, Jeff Jacoby phone: (650) 295-7569 email: jjacoby@rsasecurity.com RSA Security, SMDC 2755 Campus Drive San Mateo, CA 94403 Received: from indy.gradient.com (indy.gradient.com [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17197 for ; Fri, 16 Jun 2000 09:21:30 -0700 (PDT) Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id MAA06645; Fri, 16 Jun 2000 12:20:10 -0400 (EDT) Received: by bigbird.gradient.com with Internet Mail Service (5.5.2448.0) id ; Fri, 16 Jun 2000 12:15:23 -0400 Message-ID: <899128A30EEDD1118FC900A0C9C74A34844CA8@bigbird.gradient.com> From: Hal Lockhart To: "'Stephen Kent'" , Denis Pinkas Cc: "'PKIX Mailing List'" Subject: RE: Do people have something against RSA? Date: Fri, 16 Jun 2000 12:14:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" > The TSP draft is well along and I don't envision holding it up, > waiting for the RSA patent to expire. The document adopted an > algorithm approach consistent with IESG policy, and with other > crypto-based RFCs. Let's just stick with that. I agree and predict that algorithm support will be a frequent type of modification. For example, all the specs that deal with symmetric algorithms will upgrade to AES, most likely as the required choice, once that selection occurs. Hal ======================================================= Harold W. Lockhart Entegrity Solutions 2 Mount Royal Avenue Marlborough, MA 01752 USA V: 1-508-624-9600 x 260 hal.lockhart@entegrity.com F: 1-508-229-0338 www.entegrity.com ======================================================= Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16402 for ; Fri, 16 Jun 2000 09:08:13 -0700 (PDT) Received: by ns.celocom.se; id SAA24781; Fri, 16 Jun 2000 18:07:57 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma024771; Fri, 16 Jun 00 18:07:36 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id SAA28077; Fri, 16 Jun 2000 18:10:54 +0200 Message-ID: <394A50C7.1F54699B@celocom.com> Date: Fri, 16 Jun 2000 18:07:35 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Santesson CC: ietf-pkix@imc.org Subject: Re: Can we form certificates with just name and e-mail address References: <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5659E2AFB7538B3B3AFF4A69" This is a cryptographically signed message in MIME format. --------------ms5659E2AFB7538B3B3AFF4A69 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stefan Santesson wrote: > How do you form a certificate according to PKIX where the subjects name > only consists of a name (commonName or GivenName + surname) and an e-mail > address ?? It seams to be virtually impossible to do this. > > [...] > > What has historic debates concluded in? I don't actually know the history here, but I would wager a suggestion: Could you not leave the subject name empty and include both a rfc822Name and a directoryName (which would then contain your given name and surname attributes) in the subject alternate name extension? //oscar --------------ms5659E2AFB7538B3B3AFF4A69 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjE2MTYwNzM2 WjAjBgkqhkiG9w0BCQQxFgQU7I78gJT2zg+dy9DC78tFftRF35MwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBeG1SKy2n0uKsPp4O6dTcPASQVd5G8 6dGyHdH5dZRtdKuihHA6e548WJJFCSR5z5tSh/ikIKKzo/wndoej2F+mhmEwKX0MwHLdh62V i55ZTLBI8Vhjt4odWdCfx+kT5qdT3RPl3/1pOh63Zs+ZTv5CL9BfRYCBHj7zKreQWaOccg== --------------ms5659E2AFB7538B3B3AFF4A69-- Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16121 for ; Fri, 16 Jun 2000 09:04:38 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA05764; Fri, 16 Jun 2000 12:04:17 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <394A3ED2.E70B5912@bull.net> References: <000a01bfd78d$c3846ea0$0201010a@intergalactic> <394A3ED2.E70B5912@bull.net> Date: Fri, 16 Jun 2000 11:55:55 -0400 To: Denis Pinkas From: Stephen Kent Subject: Re: Do people have something against RSA? Cc: "'PKIX Mailing List'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Denis, The TSP draft is well along and I don't envision holding it up, waiting for the RSA patent to expire. The document adopted an algorithm approach consistent with IESG policy, and with other crypto-based RFCs. Let's just stick with that. Steve Received: from windoze.tenebras.com (windoze.tenebras.com [216.15.43.196]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15145 for ; Fri, 16 Jun 2000 08:21:37 -0700 (PDT) Received: from dnai.com (localhost [127.0.0.1]) by windoze.tenebras.com (8.9.3/8.9.3) with ESMTP id IAA37417; Fri, 16 Jun 2000 08:20:48 -0700 (PDT) (envelope-from kudzu@dnai.com) Sender: kudzu@windoze.tenebras.com Message-ID: <394A45D0.B58E698@dnai.com> Date: Fri, 16 Jun 2000 08:20:48 -0700 From: Michael Sierchio X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: fr, en MIME-Version: 1.0 To: Christopher Williams CC: PKIX Mailing List Subject: Re: Do people have something against RSA? References: <009701bfd785$529a9d70$c4cbfc3e@darxstar> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christopher Williams wrote: > > Do people in the PKI world have something RSA Data Corporation? It's just > that every document mandates DSA as a signature algorithm and indicates that > RSA "MAY" also be supported. Another example is that PKIX does not support > PKCS#8 for securing private keys, even though PKCS#8 is a well-established > standard (eight years old now?). Then I read as a suggested amendment to > the TSP document: > > "TSA implementations MUST support DSA. TSA implementations MAY include RSA." I'm afraid that I don't see why a mandate for private key storage is relevant to this discussion -- other than the obvious requirement that private keys be kept private, whether by embedding in tamper-resistant hardware, password based encryption, etc., and that there be a revocation mechanism in the event of compromise. And the answer to your query -- as a former employee of RSADSI (now RSA Security) -- is: yes. There is antipathy for RSA, perhaps because they have always spent more on lawyers than on R&D. I have the greatest respect for the folks at RSA Labs, but slight regard for the rest of the company that was RSADSI and SDTI. > Get real! The whole world uses RSA. The future worldwide PKI will run on > RSA. One might easily surmise that the future of PKI is ECC, or something yet to be invented. However, choosing technology that is unecumbered by patents is an IETF requirement. > I have never seen a certificate signed with an algorithm other than > RSA and containing anything other than an RSA public key. That is a self-referential statement -- the plural of anecdote is not data, IIRC. > Insisting upon DSA and Diffie-Hellman is like railing against the > universality of Microsoft: pointless and missing the point. There are distinct advantages to the use of long-term DH values tied to identity, esp. when it comes to stateless protocols, IPSec, and other uses for key agreement. Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14040 for ; Fri, 16 Jun 2000 07:51:50 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA33904 for ; Fri, 16 Jun 2000 16:54:40 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA20436 for ; Fri, 16 Jun 2000 16:50:56 +0200 Message-ID: <394A3ED2.E70B5912@bull.net> Date: Fri, 16 Jun 2000 16:50:58 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: "'PKIX Mailing List'" Subject: Re: Do people have something against RSA? References: <000a01bfd78d$c3846ea0$0201010a@intergalactic> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit denis, I will use your E-mail to comment. > > > Get real! The whole world uses RSA. [...] > > > Insisting upon DSA and Diffie-Hellman is like railing against the > > > universality of Microsoft: pointless and missing the point. > > IETF standards are required to use non-proprietary technologies wherever > > possible. > > Yes, but - the RSA patent is going to expire in September this year, is it > not? > > There are not going to be any serious commercial employments of, say, a TSA, > before September, are they? I do not buy the arguments from Christopher, but I thank him for being the first one daring to raise the issue. The question raised by denis makes sense: we only have a little bit more than 3 months left before the expiration of the RSA patent. There are two related questions: 1) Should we mandate the use of the RSA algorithm for signing TS token ? This seems reasonable in this new context. 2) Should the chairs wait until September 21 rst, 2000 to send the TSP draft to the IESG (and mandate the use of the RSA algorithm for signing) or should they do it now (i.e. as soon as they consider that we have reached a WG consensus) taking into account that the next step is Proposed Standard, i.e. not Standard, which means that in any case, the Standard will be published three months AFTER the expiration of the RSA patent. The later seems reasonable ... but would mean to publish a version 9 of the TSP draft before sending it to the IESG. Anyway the question is much broader than the TSP draft and applies to all other drafts, in particular Attibute Certificates. Denis > So why not put in RSA, since the patent is going to expire soon enough > anyway? As far as I know, the validity of the patent cannot be extended, > thus RSA becomes public domain. > > Regards, > > denis Received: from mail.addtrust.com ([212.28.208.199]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12892 for ; Fri, 16 Jun 2000 07:30:15 -0700 (PDT) Received: from santesson.addtrust.com (unknown [212.28.208.198]) by mail.addtrust.com (Postfix) with ESMTP id D50E53E203 for ; Fri, 16 Jun 2000 16:28:46 +0200 (CEST) Message-Id: <4.3.2.7.2.20000616160054.00c03200@mail.addtrust.com> X-Sender: sts@mail.addtrust.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Jun 2000 16:29:17 +0200 To: ietf-pkix@imc.org From: Stefan Santesson Subject: Can we form certificates with just name and e-mail address Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Just a seemingly easy question! How do you form a certificate according to PKIX where the subjects name only consists of a name (commonName or GivenName + surname) and an e-mail address ?? It seams to be virtually impossible to do this. I'm almost certain that this must have been up before, so I would appreciate some hints here. The problem is that son of RFC 2459 in "4.1.2.6 Subject" says Conforming implementations generating new certificates with elec- tronic mail addresses MUST use the rfc822Name in the subject alterna- tive name field (see sec. 4.2.1.7) to describe such identities. Simultaneous inclusion of the EmailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted. My problem with this is that the name (given name + surname) is not unique. I.e. it can't be stored in the subject field nor as a name form in the subjectAltName ext, unless combined with some disambiguating data (such as an e-mail address), which is deprecated according to the current text. This means that inclusion of a name in the subject field must be combined with some disambiguating data other than an e-mail address (if the name is not unique enough). This seams like a pragmatic view that hardly meets the requirements of a practical world. What has historic debates concluded in? /Stefan Received: from dns1.provide.net (root@dns1.provide.net [216.86.64.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12703 for ; Fri, 16 Jun 2000 07:29:45 -0700 (PDT) Received: from cyclonecommerce.com (usr08-113.provide.net [216.86.68.241]) by dns1.provide.net (8.9.0/8.9.3) with ESMTP id KAA06916; Fri, 16 Jun 2000 10:28:54 -0400 (EDT) Message-ID: <394A374F.D475E249@cyclonecommerce.com> Date: Fri, 16 Jun 2000 10:18:55 -0400 From: Timothy Fisher X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Laurie CC: Christopher Williams , PKIX Mailing List Subject: Re: Do people have something against RSA? References: <009701bfd785$529a9d70$c4cbfc3e@darxstar> <394A14B2.8A8E5312@algroup.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris, I also think that the simple fact is that YES, quite a few people do have something against RSA Security Inc. Have you ever tryed negotiating with them? I have... Its not a fun process.... Many people share this opinion of RSA. Tim Ben Laurie wrote: > Christopher Williams wrote: > > > > Do people in the PKI world have something RSA Data Corporation? It's just > > that every document mandates DSA as a signature algorithm and indicates that > > RSA "MAY" also be supported. Another example is that PKIX does not support > > PKCS#8 for securing private keys, even though PKCS#8 is a well-established > > standard (eight years old now?). Then I read as a suggested amendment to > > the TSP document: > > > > "TSA implementations MUST support DSA. TSA implementations MAY include RSA. > > " > > > > Get real! The whole world uses RSA. The future worldwide PKI will run on > > RSA. I have never seen a certificate signed with an algorithm other than > > RSA and containing anything other than an RSA public key. Sure, RSA is > > patented, so factor licensing it as part of your software development costs > > and pay them their fee - they deserve it. > > > > Insisting upon DSA and Diffie-Hellman is like railing against the > > universality of Microsoft: pointless and missing the point. > > IETF standards are required to use non-proprietary technologies wherever > possible. > > Cheers, > > Ben. > > -- > http://www.apache-ssl.org/ben.html > > Coming to ApacheCon Europe 2000? http://apachecon.com/ Received: from dns1.provide.net (root@dns1.provide.net [216.86.64.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12422 for ; Fri, 16 Jun 2000 07:27:49 -0700 (PDT) Received: from cyclonecommerce.com (usr08-113.provide.net [216.86.68.241]) by dns1.provide.net (8.9.0/8.9.3) with ESMTP id KAA06816; Fri, 16 Jun 2000 10:27:20 -0400 (EDT) Message-ID: <394A36E1.615C66F3@cyclonecommerce.com> Date: Fri, 16 Jun 2000 10:17:05 -0400 From: Timothy Fisher X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Williams CC: PKIX Mailing List Subject: Re: Do people have something against RSA? References: <009701bfd785$529a9d70$c4cbfc3e@darxstar> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Fortunately, the patent will expire at the end of September of this year. After that, you will no longer have to pay RSA data corp. any fees to use RSA. The reason that DSA is mandated in most standards is simply because it is free to use. A standard should never mandate an algorithm which must be licensed from a specific provider. This would be a mistake. Timothy Fisher Christopher Williams wrote: > Do people in the PKI world have something RSA Data Corporation? It's just > that every document mandates DSA as a signature algorithm and indicates that > RSA "MAY" also be supported. Another example is that PKIX does not support > PKCS#8 for securing private keys, even though PKCS#8 is a well-established > standard (eight years old now?). Then I read as a suggested amendment to > the TSP document: > > "TSA implementations MUST support DSA. TSA implementations MAY include RSA. > " > > Get real! The whole world uses RSA. The future worldwide PKI will run on > RSA. I have never seen a certificate signed with an algorithm other than > RSA and containing anything other than an RSA public key. Sure, RSA is > patented, so factor licensing it as part of your software development costs > and pay them their fee - they deserve it. > > Insisting upon DSA and Diffie-Hellman is like railing against the > universality of Microsoft: pointless and missing the point. > > Christopher Williams > > Software engineer, NetLexis Ltd. > http://www.netlexis.com "Intelligent Trust" Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA11837 for ; Fri, 16 Jun 2000 07:21:20 -0700 (PDT) Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id PAA25280; Fri, 16 Jun 2000 15:21:04 +0100 Message-ID: <394A37BD.511FCADF@algroup.co.uk> Date: Fri, 16 Jun 2000 15:20:45 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: denis.bider@siol.net CC: "'Christopher Williams'" , "'PKIX Mailing List'" Subject: Re: Do people have something against RSA? References: <000a01bfd78d$c3846ea0$0201010a@intergalactic> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit denis.bider@siol.net wrote: > > > > Get real! The whole world uses RSA. [...] > > > Insisting upon DSA and Diffie-Hellman is like railing against the > > > universality of Microsoft: pointless and missing the point. > > IETF standards are required to use non-proprietary technologies wherever > > possible. > > Yes, but - the RSA patent is going to expire in September this year, is it > not? > > There are not going to be any serious commercial employments of, say, a TSA, > before September, are they? Rules are rules! In September, you'll be right. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA11775 for ; Fri, 16 Jun 2000 07:20:59 -0700 (PDT) Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id PAA25276; Fri, 16 Jun 2000 15:20:30 +0100 Message-ID: <394A379B.D57E3142@algroup.co.uk> Date: Fri, 16 Jun 2000 15:20:11 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: Xenitellis S CC: "'PKIX Mailing List'" Subject: Re: Do people have something against RSA? References: <837B0A2C05ADD111A31200E029054E30A91271@exch4.rhbnc.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Xenitellis S wrote: > > I am not an expert on this, however I have heard two reasons that > may make RSA still difficult to use. > > 1. The RSA patent expires this September, but there are several related > to RSA patents that do not expire yet. It depends on the course that > these additional patents will be fought for. > > 2. In other countries (like in the UK), I think that RSA is patented. What > is > the case in those countries? When do patents expire? RSA is not patented in the UK (or the rest of Europe). Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ Received: from stonewall.baltimore.com (mailhost.baltimore.com [195.152.140.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA10126 for ; Fri, 16 Jun 2000 06:32:13 -0700 (PDT) Message-ID: <61922E6DA745D311A42000508B2CFD14B96766@baltimore.com> From: Paul Halliden To: "'Xenitellis S'" , "'PKIX Mailing List'" Subject: RE: Do people have something against RSA? Date: Fri, 16 Jun 2000 14:32:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" >2. In other countries (like in the UK), I think that RSA is >patented. What is the case in those countries? RSA is not patented in the UK or, to the best of my knowledge, in any other European country. However, I understand that there is a claim that DSA may covered by a European patent. In the US, I believe that the Federal authorities provide indemnity to vendors using DSA in products supplied to the government - but I have not heard of that happening elsewhere. Regards Paul Halliden Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08691 for ; Fri, 16 Jun 2000 05:53:37 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 08:54:08 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C025@panda.chrysalis-its.com> To: seidel@timeproof.de Cc: ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt Date: Fri, 16 Jun 2000 08:53:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD791.F4FB4180" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD791.F4FB4180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable J=F6rg, See comments inline. Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 >-----Original Message----- >From: Joerg Seidel [mailto:seidel@timeproof.de] >Sent: Thursday, June 15, 2000 3:31 PM >To: FRousseau@chrysalis-its.com >Cc: Denis.Pinkas@bull.net; ietf-pkix@imc.org >Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt > >Comments inline. > >> FRousseau@chrysalis-its.com schrieb: >>=20 >> a. Under Section 2.3, the first sentence indicates that "The TSA = MUST sign >> all time stamp messages with one or more keys reserved specifically = for that >> purpose". As suggested before, I would recommend that you add the following >> sentence after the first sentence to explain the reason(s) why a TSA could >> have more than one key reserved specifically for that purpose: "A = TSA MAY >> have more than one key to accommodate different policies, different >> algorithms and/or different private key sizes". > >Or just for performance purposes. If a TSA has more than one key for performance purposes, I would assume = they are just copies of the same private key cloned in different = cryptographic modules for performance and load balancing reasons. I think that the document meant "distinct" private keys, but I would agree with you that = it is not obvious. Instead it could read this way: "The TSA MUST sign all time stamp messages with one or more keys = reserved specifically for that purpose. A TSA MAY have distinct private keys to accommodate different policies, different algorithms and/or different = key sizes." >> I would then suggest that a new Section be >> added between the current Sections 3 and 4, which would define the minimum >> set of algorithm that MUST and SHOULD be supported by requesters and TSAs. >> Based on Section 12 of RFC 2630 [CMS], it could read as follows: >>=20 >> 4 Supported Algorithms >>=20 >> This section lists the algorithms that must be supported. >> Additional algorithms that should be supported are also included. >>=20 >> 4.1 Hash Algorithms >>=20 >> TSA implementations MUST support SHA-1. TSA implementations = SHOULD >> support MD5. > >I think there are good reasons not to use MD5 in time stamps. They = should use >a strong hash function in order to achive long validity periods. MD5 = is likely >to be unsafe (=3Dnot collision free) soon and is already discuraged by = german >authorities. I agree that TSAs should not use MD5 in their time stamps and MUST only = use strong hash functions (e.g. SHA-1, RIPEMD-160). However, there is = nothing wrong for a requester to submit a message imprint containing a MD5 hash, = which means that TSAs should be able accept request with MD5. >IF we add a section about algorithms, it should maybe read: "TSA >implementations MUST support SHA-1. TSA implementations SHOULD NOT = support >MD5.". But I think such a section is not very necessary. See comment above, however I agree that the text will have to be = modified to distinguish between the hash supported by TSAs in requests versus the = hash used by TSAs in time stamp tokens. >> 4.2 Signature Algorithms >>=20 >> TSA implementations MUST support DSA. TSA implementations MAY >> include RSA. > >Again I would do it the other way round: "TSA MUST support RSA. MAY = support >DSA". This came directly from RFC 2630 [CMS], however this document could = mandate different algorithms for TSA if this is what everyone agree. >J=F6rg >--=20 >__________________________________________________________________ > >J=F6rg Seidel phone +49-40-76629-1911 >Director Technology fax +49-40-76629-551 >timeproof GmbH =20 >Harburger Schlo=DFstra=DFe 6-12 mailto:seidel@timeproof.de >DE 21079 Hamburg http://www.timeproof.de >__________________________________________________________________ > ------_=_NextPart_001_01BFD791.F4FB4180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

J=F6rg,

See comments inline.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078


>-----Original Message-----
>From: Joerg Seidel [mailto:seidel@timeproof.de]
>Sent: Thursday, June 15, 2000 3:31 PM
>To: FRousseau@chrysalis-its.com
>Cc: Denis.Pinkas@bull.net; = ietf-pkix@imc.org
>Subject: Re: I-D = ACTION:draft-ietf-pkix-time-stamp-08.txt
>
>Comments inline.
>
>> FRousseau@chrysalis-its.com schrieb:
>>
>> a.  Under Section 2.3, the first = sentence indicates that "The TSA MUST sign
>> all time stamp messages with one or more = keys reserved specifically for that
>> purpose". As suggested before, I would = recommend that you add the following
>> sentence after the first sentence to = explain the reason(s) why a TSA could
>> have more than one key reserved = specifically for that purpose: "A TSA MAY
>> have more than one key to accommodate = different policies, different
>> algorithms and/or different private key = sizes".
>
>Or just for performance purposes.

If a TSA has more than one key for performance = purposes, I would assume they are just copies of the same private key = cloned in different cryptographic modules for performance and load = balancing reasons. I think that the document meant "distinct" = private keys, but I would agree with you that it is not obvious. = Instead it could read this way:

"The TSA MUST sign all time stamp messages with = one or more keys reserved specifically for that purpose. A TSA MAY have = distinct private keys to accommodate different policies, different = algorithms and/or different key sizes."

>> I would then suggest that a new Section = be
>> added between the current Sections 3 and 4, = which would define the minimum
>> set of algorithm that MUST and SHOULD be = supported by requesters and TSAs.
>> Based on Section 12 of RFC 2630 [CMS], it = could read as follows:
>>
>> 4  Supported Algorithms
>>
>>    This section lists the = algorithms that must be supported.
>>    Additional algorithms = that should be supported are also included.
>>
>> 4.1  Hash Algorithms
>>
>>    TSA implementations MUST = support SHA-1.  TSA implementations SHOULD
>>    support MD5.
>
>I think there are good reasons not to use MD5 in = time stamps. They should use
>a strong hash function in order to achive long = validity periods. MD5 is likely
>to be unsafe (=3Dnot collision free) soon and is = already discuraged by german
>authorities.

I agree that TSAs should not use MD5 in their time = stamps and MUST only use
strong hash functions (e.g. SHA-1, RIPEMD-160). = However, there is nothing wrong
for a requester to submit a message imprint = containing a MD5 hash, which means
that TSAs should be able accept request with = MD5.

>IF we add a section about algorithms, it should = maybe read: "TSA
>implementations MUST support SHA-1.  TSA = implementations SHOULD NOT support
>MD5.". But I think such a section is not = very necessary.

See comment above, however I agree that the text will = have to be modified to distinguish between the hash supported by TSAs = in requests versus the hash used by TSAs in time stamp = tokens.

>> 4.2  Signature Algorithms
>>
>>    TSA implementations MUST = support DSA.  TSA implementations MAY
>>    include RSA.
>
>Again I would do it the other way round: = "TSA MUST support RSA. MAY support
>DSA".

This came directly from RFC 2630 [CMS], however this = document could mandate different algorithms for TSA if this is what = everyone agree.

>J=F6rg
>--
>___________________________________________________________= _______
>
>J=F6rg = Seidel           =             =       phone  +49-40-76629-1911
>Director = Technology          &n= bsp;          = fax    +49-40-76629-551
>timeproof = GmbH           &n= bsp;           &n= bsp; 
>Harburger Schlo=DFstra=DFe = 6-12           &n= bsp; mailto:seidel@timeproof.de
>DE 21079 = Hamburg           = ;            = ; http://www.timeproof.de
>___________________________________________________________= _______
>

------_=_NextPart_001_01BFD791.F4FB4180-- Received: from exch1.rhbnc.ac.uk (exch1.rhbnc.ac.uk [134.219.200.122]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08066 for ; Fri, 16 Jun 2000 05:41:46 -0700 (PDT) Received: by exch1.rhbnc.ac.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Jun 2000 13:46:17 +0100 Message-ID: <837B0A2C05ADD111A31200E029054E30A91271@exch4.rhbnc.ac.uk> From: Xenitellis S To: "'PKIX Mailing List'" Subject: RE: Do people have something against RSA? Date: Fri, 16 Jun 2000 13:41:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain I am not an expert on this, however I have heard two reasons that may make RSA still difficult to use. 1. The RSA patent expires this September, but there are several related to RSA patents that do not expire yet. It depends on the course that these additional patents will be fought for. 2. In other countries (like in the UK), I think that RSA is patented. What is the case in those countries? When do patents expire? My 2 drx, Simos Xenitellis > ---------- > From: denis.bider[SMTP:denis.bider@siol.net] > Sent: 16 June 2000 13:24 > To: 'Ben Laurie'; 'Christopher Williams' > Cc: 'PKIX Mailing List' > Subject: RE: Do people have something against RSA? > > > > Get real! The whole world uses RSA. [...] > > > Insisting upon DSA and Diffie-Hellman is like railing against the > > > universality of Microsoft: pointless and missing the point. > > IETF standards are required to use non-proprietary technologies wherever > > possible. > > Yes, but - the RSA patent is going to expire in September this year, is it > not? > > There are not going to be any serious commercial employments of, say, a > TSA, > before September, are they? > > So why not put in RSA, since the patent is going to expire soon enough > anyway? As far as I know, the validity of the patent cannot be extended, > thus RSA becomes public domain. > > Regards, > > denis > Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06697 for ; Fri, 16 Jun 2000 05:25:19 -0700 (PDT) Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id OAA15060; Fri, 16 Jun 2000 14:11:06 +0200 From: Sender: "denis bider" To: "'Ben Laurie'" , "'Christopher Williams'" Cc: "'PKIX Mailing List'" Subject: RE: Do people have something against RSA? Date: Fri, 16 Jun 2000 14:24:04 +0200 Message-ID: <000a01bfd78d$c3846ea0$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <394A14B2.8A8E5312@algroup.co.uk> Importance: Normal > > Get real! The whole world uses RSA. [...] > > Insisting upon DSA and Diffie-Hellman is like railing against the > > universality of Microsoft: pointless and missing the point. > IETF standards are required to use non-proprietary technologies wherever > possible. Yes, but - the RSA patent is going to expire in September this year, is it not? There are not going to be any serious commercial employments of, say, a TSA, before September, are they? So why not put in RSA, since the patent is going to expire soon enough anyway? As far as I know, the validity of the patent cannot be extended, thus RSA becomes public domain. Regards, denis Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA05041 for ; Fri, 16 Jun 2000 04:52:01 -0700 (PDT) Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id MAA24209; Fri, 16 Jun 2000 12:51:29 +0100 Message-ID: <394A14B2.8A8E5312@algroup.co.uk> Date: Fri, 16 Jun 2000 12:51:14 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: Christopher Williams CC: PKIX Mailing List Subject: Re: Do people have something against RSA? References: <009701bfd785$529a9d70$c4cbfc3e@darxstar> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christopher Williams wrote: > > Do people in the PKI world have something RSA Data Corporation? It's just > that every document mandates DSA as a signature algorithm and indicates that > RSA "MAY" also be supported. Another example is that PKIX does not support > PKCS#8 for securing private keys, even though PKCS#8 is a well-established > standard (eight years old now?). Then I read as a suggested amendment to > the TSP document: > > "TSA implementations MUST support DSA. TSA implementations MAY include RSA. > " > > Get real! The whole world uses RSA. The future worldwide PKI will run on > RSA. I have never seen a certificate signed with an algorithm other than > RSA and containing anything other than an RSA public key. Sure, RSA is > patented, so factor licensing it as part of your software development costs > and pay them their fee - they deserve it. > > Insisting upon DSA and Diffie-Hellman is like railing against the > universality of Microsoft: pointless and missing the point. IETF standards are required to use non-proprietary technologies wherever possible. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA04366 for ; Fri, 16 Jun 2000 04:39:55 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id VAA00600; Fri, 16 Jun 2000 21:45:20 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 16 Jun 2000 21:38:52 +1000 Message-ID: From: Michael Zolotarev To: Christopher Williams , PKIX Mailing List Subject: RE: Do people have something against RSA? Date: Fri, 16 Jun 2000 21:38:51 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFD787.718D6774" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFD787.718D6774 Content-Type: text/plain; charset="iso-8859-1" > Get real! The whole world uses RSA. The future worldwide > PKI will run on > RSA. I have never seen a certificate signed with an > algorithm other than > RSA and containing anything other than an RSA public key. Here is one for you, Christopher. It contains a DSA key. If you insist, I can generate a *real* certificate for you. And I can sign it with a DSA key. Having fun? Michael :) ------_=_NextPart_000_01BFD787.718D6774 Content-Type: application/octet-stream; name="DEMO_DSA.crt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="DEMO_DSA.crt" MIIDwDCCAymgAwIBAgIEOHq2UTANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMCQVUxHzAdBgNV BAoTFkJhbHRpbW9yZSBUZWNobm9sb2dpZXMxGzAZBgNVBAsTEldlYlJBTyBEZXZlbG9wbWVudDEP MA0GA1UEAxMGRGVtb0NBMSQwIgYKCZImiZPyLGQBAxQURGVtb0NBQGJhbHRpbW9yZS5jb20wHhcN MDAwMTExMDQ0OTIxWhcNMDEwMTEwMTQ0OTIxWjCBgzELMAkGA1UEBhMCQVUxHzAdBgNVBAoTFkJh bHRpbW9yZSBUZWNobm9sb2dpZXMxIzAhBgNVBAsTGlRpbWVTdGFtcGluZyBEZW1vIFNlcnZpY2Vz MS4wLAYDVQQDEyVCYWx0aW1vcmUgVGltZVN0YW1waW5nIERlbW8gYXV0aG9yaXR5MIIBtzCCASwG ByqGSM44BAEwggEfAoGBAN5q7pg48zsWbRqU5ynTin7qK8lM1ppO4duhWA/owgn+tjdifKexFhee XZ0lL8jcEMAOVvzVlFB/aPVqBqP0sP39X7ecSbzYOl5LWeXpEWYdm/8jWh24OnjTnXHtpmNbw81M udsqVf3INkbA5gqE94gfnKbKAewzXaLnrHHjMqtjAhUAqmRGAyKQmBrQ0NxbsALlaTXkjE8CgYEA wjmOWeQea1+6Rlkdp9vJAhWPuvlgvLpn2KL0OFcbDvpN9fkpRUA4sbAlp8e7HRoO8jkLhypg03yV LgkqSiI3QCcZWCPSa9X9JVGXweYUM+sOQMX2SjdNmwwAypw/anaBDPnwzffuPVCckjYqvJGuATHX a+roLbpnYDasC/rz4vEDgYQAAoGAVhOJmRFPjUZgl/gKbZLZ2xaa9Bzjw6hJaS46o7JBZX7n16Lf ivzz7ICwmkbxIjmw8SltKgtkVWO8QXEII8bZJUlYsVs94vJ0s9GLIqv8sFwnd3P0JtVnDAYCA1to szQ+LtTBtQMe5I7bNSAxe/c/cKuVyZ2jDuLaHIsGTFdT7vGjJzAlMA4GA1UdDwEB/wQEAwIHgDAT BgNVHSUEDDAKBggrBgEFBQcDCDANBgkqhkiG9w0BAQUFAAOBgQBu0HCRDur34mAMEZMSwpnP3oVa Be6Twp24nF00UgO74i0uKhUNcSFxFIi6LqT70BMrxGSZIlzZot/8DKWIFgl5oDbhXIMpX05ogCIm xNtyUjZUIVt1ltD/7EOAnJ7asbGjB+uw4HG0JZYx5sIUFN5kucb/NFPD7OcO1em//nrVsw== ------_=_NextPart_000_01BFD787.718D6774-- Received: from mta02-svc.server.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03799 for ; Fri, 16 Jun 2000 04:23:20 -0700 (PDT) Received: from darxstar ([62.252.200.29]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000616122236.ZOIV10065.mta02-svc.server.ntlworld.com@darxstar> for ; Fri, 16 Jun 2000 12:22:36 +0000 Message-ID: <009701bfd785$529a9d70$c4cbfc3e@darxstar> From: "Christopher Williams" To: "PKIX Mailing List" Subject: Do people have something against RSA? Date: Fri, 16 Jun 2000 12:22:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Do people in the PKI world have something RSA Data Corporation? It's just that every document mandates DSA as a signature algorithm and indicates that RSA "MAY" also be supported. Another example is that PKIX does not support PKCS#8 for securing private keys, even though PKCS#8 is a well-established standard (eight years old now?). Then I read as a suggested amendment to the TSP document: "TSA implementations MUST support DSA. TSA implementations MAY include RSA. " Get real! The whole world uses RSA. The future worldwide PKI will run on RSA. I have never seen a certificate signed with an algorithm other than RSA and containing anything other than an RSA public key. Sure, RSA is patented, so factor licensing it as part of your software development costs and pay them their fee - they deserve it. Insisting upon DSA and Diffie-Hellman is like railing against the universality of Microsoft: pointless and missing the point. Christopher Williams Software engineer, NetLexis Ltd. http://www.netlexis.com "Intelligent Trust" Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06702 for ; Thu, 15 Jun 2000 16:56:52 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 19:57:19 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C024@panda.chrysalis-its.com> To: Peter.Sylvester@EdelWeb.fr Cc: ietf-pkix@imc.org Subject: RE: TSP Draft 08 Date: Thu, 15 Jun 2000 19:57:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD725.6F087410" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD725.6F087410 Content-Type: text/plain; charset="iso-8859-1" Peter, I disagree that the addition of the ordering flag is creating any incompatibility issue since the TSA document is still only an Internet Draft that should not have been used to develop any commercial product until it becomes an RFC. In addition, I think it is much more meaningful to require the flag to be present to indicate that ordering is supported as currently mandated by the latest TSA document. I agree however that there must be a way for a TSA to publish which of the ordering services it supports. As a minimum this should be done through the TSA's policy and it could possibly be done through the Subject Information Access (SIA) extension from the son of RFC 2459 if it contained a similar ordering flag. By using the reqPolicy field a requester could then request the appropriate service if a TSA offers different ordering services. I also agree that the document should indicate if a TSA has to set the ordering in a identical way in ALL of its time stamps. I would think that if a TSA explicitly indicate that it will not support ordering (e.g. through the TSA's policy or the SIA extension), Time Stamp tokens issued from this TSA MUST NEVER have the ordering field set to true. However, if a TSA explicitly indicate that it will support ordering, all Time Stamp tokens issued from this TSA SHOULD have the ordering field set to true unless the TSA can not longer do this because of some technical problems. This would then be a good reason to use the value of one (1) in the structure "PKIStatus" (i.e. grantedWithMods). Regards, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: Peter Sylvester [mailto:Peter.Sylvester@EdelWeb.fr] Sent: Thursday, June 15, 2000 2:45 PM To: ietf-pkix@imc.org Subject: Re: TSP Draft 08 I find it somewhat unelegant to change the functionality of ordering is such an incompatible way. I think it would have been wiser to at least inverse the meaning or BOOLEAN ordering. It is not said anywhere whether a TSA has to set the ordering in a identical way in ALL of its time stamps. The ordering bit defines two different services; there is no way fore a TSA to publish which of the services it supports, there is also no way for the client to indicate whether ordering or not is desired when requesting a time stamp? The text says: 'Using a nonce always allows to detect replays' This should be 'using a nonce reduces the possibility of replay attacks.'. P ------_=_NextPart_001_01BFD725.6F087410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: TSP Draft 08

Peter,

I disagree that the addition of the ordering flag is = creating any incompatibility issue since the TSA document is still only = an Internet Draft that should not have been used to develop any = commercial product until it becomes an RFC. In addition, I think it is = much more meaningful to require the flag to be present to indicate that = ordering is supported as currently mandated by the latest TSA = document.

I agree however that there must be a way for a TSA to = publish which of the ordering services it supports. As a minimum this = should be done through the TSA's policy and it could possibly be done = through the Subject Information Access (SIA) extension from the son of = RFC 2459 if it contained a similar ordering flag. By using the = reqPolicy field a requester could then request the appropriate service = if a TSA offers different ordering services.

I also agree that the document should indicate if a = TSA has to set the ordering in a identical way in ALL of its time = stamps. I would think that if a TSA explicitly indicate that it will = not support ordering (e.g. through the TSA's policy or the SIA = extension), Time Stamp tokens issued from this TSA MUST NEVER have the = ordering field set to true. However, if a TSA explicitly indicate that = it will support ordering, all Time Stamp tokens issued from this TSA = SHOULD have the ordering field set to true unless the TSA can not = longer do this because of some technical problems. This would then be a = good reason to use the value of one (1) in the structure = "PKIStatus" (i.e. grantedWithMods).

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078


-----Original Message-----
From: Peter Sylvester [mailto:Peter.Sylvester@EdelWe= b.fr]
Sent: Thursday, June 15, 2000 2:45 PM
To: ietf-pkix@imc.org
Subject: Re: TSP Draft 08

I find it somewhat unelegant to change the = functionality of
ordering is such an incompatible way. I think = it
would have been wiser to at least inverse the = meaning
or BOOLEAN ordering.

It is not said anywhere whether a TSA has to set the = ordering
in a identical way in ALL of its time stamps.

The ordering bit defines two different services; = there is
no way fore a TSA to publish which of the services = it supports,
there is also no way for the client to indicate = whether
ordering or not is desired when requesting a time = stamp?

The text says: 'Using a nonce always allows to detect = replays'
This should be 'using a nonce reduces the = possibility of replay attacks.'.

P

------_=_NextPart_001_01BFD725.6F087410-- Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00351 for ; Thu, 15 Jun 2000 12:20:28 -0700 (PDT) Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id (multiple receipients); Thu, 15 Jun 2000 21:20:03 +0200 (MET DST) Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id VAA26748; Thu, 15 Jun 2000 21:19:33 +0200 (MEST) Message-ID: <39492EF4.CE266284@timeproof.de> Date: Thu, 15 Jun 2000 21:31:00 +0200 From: Joerg Seidel Organization: timeproof X-Mailer: Mozilla 4.5 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: FRousseau@chrysalis-its.com CC: Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt References: <918C70B01822D411A87400B0D0204DFF04C01F@panda.chrysalis-its.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Comments inline. > FRousseau@chrysalis-its.com schrieb: > > a. Under Section 2.3, the first sentence indicates that "The TSA MUST sign > all time stamp messages with one or more keys reserved specifically for that > purpose". As suggested before, I would recommend that you add the following > sentence after the first sentence to explain the reason(s) why a TSA could > have more than one key reserved specifically for that purpose: "A TSA MAY > have more than one key to accommodate different policies, different > algorithms and/or different private key sizes". Or just for performance purposes. > I would then suggest that a new Section be > added between the current Sections 3 and 4, which would define the minimum > set of algorithm that MUST and SHOULD be supported by requesters and TSAs. > Based on Section 12 of RFC 2630 [CMS], it could read as follows: > > 4 Supported Algorithms > > This section lists the algorithms that must be supported. > Additional algorithms that should be supported are also included. > > 4.1 Hash Algorithms > > TSA implementations MUST support SHA-1. TSA implementations SHOULD > support MD5. I think there are good reasons not to use MD5 in time stamps. They should use a strong hash function in order to achive long validity periods. MD5 is likely to be unsafe (=not collision free) soon and is already discuraged by german authorities. IF we add a section about algorithms, it should maybe read: "TSA implementations MUST support SHA-1. TSA implementations SHOULD NOT support MD5.". But I think such a section is not very necessary. > 4.2 Signature Algorithms > > TSA implementations MUST support DSA. TSA implementations MAY > include RSA. Again I would do it the other way round: "TSA MUST support RSA. MAY support DSA". Jörg -- __________________________________________________________________ Jörg Seidel phone +49-40-76629-1911 Director Technology fax +49-40-76629-551 timeproof GmbH Harburger Schloßstraße 6-12 mailto:seidel@timeproof.de DE 21079 Hamburg http://www.timeproof.de __________________________________________________________________ Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29516 for ; Thu, 15 Jun 2000 11:44:54 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA12870 for ; Thu, 15 Jun 2000 20:44:34 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 15 Jun 2000 20:44:34 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA00260 for ; Thu, 15 Jun 2000 20:44:33 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA11525 for ietf-pkix@imc.org; Thu, 15 Jun 2000 20:44:33 +0200 (MET DST) Date: Thu, 15 Jun 2000 20:44:33 +0200 (MET DST) Message-Id: <200006151844.UAA11525@emeriau.edelweb.fr> To: ietf-pkix@imc.org Subject: Re: TSP Draft 08 I find it somewhat unelegant to change the functionality of ordering is such an incompatible way. I think it would have been wiser to at least inverse the meaning or BOOLEAN ordering. It is not said anywhere whether a TSA has to set the ordering in a identical way in ALL of its time stamps. The ordering bit defines two different services; there is no way fore a TSA to publish which of the services it supports, there is also no way for the client to indicate whether ordering or not is desired when requesting a time stamp? The text says: 'Using a nonce always allows to detect replays' This should be 'using a nonce reduces the possibility of replay attacks.'. P Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27584 for ; Thu, 15 Jun 2000 10:08:09 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 13:08:25 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04C01F@panda.chrysalis-its.com> To: Denis.Pinkas@bull.net Cc: ietf-pkix@imc.org Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt Date: Thu, 15 Jun 2000 13:08:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD6EC.50BA7A8C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFD6EC.50BA7A8C Content-Type: text/plain; charset="iso-8859-1" Salut Denis, Here are few comments on version 8, some a which are a repeat of previous comments: a. Under Section 2.3, the first sentence indicates that "The TSA MUST sign all time stamp messages with one or more keys reserved specifically for that purpose". As suggested before, I would recommend that you add the following sentence after the first sentence to explain the reason(s) why a TSA could have more than one key reserved specifically for that purpose: "A TSA MAY have more than one key to accommodate different policies, different algorithms and/or different private key sizes". b. In Section 2.4.2, the structure "PKIStatusInfo" is missing the OPTIONAL "statusString" field, which is defined in RFC 2510 as PKIFreeText. Because later in Section 2.4.2 it is mentioned that "The statusString field of PKIStatusInfo MAY be used to include reason text such as 'messageImprint field is not correctly formatted'", it would be preferable if the structure "PKIStatusInfo" in this document was made consistent with the one in RFC 2510. c. Under Section 2.4.2, the structure "PKIStatus" can take the value of one (1) (i.e. grantedWithMods), which is defined in RFC 2510 as: grantedWithMods (1), -- you got something like what you asked for; the -- requester is responsible for ascertaining the differences However, base on this definition from RFC 2510, it is not clear in the context of a TSA if this means that a Time Stamp Token can be present, but its format was modified from what the requester demanded. If so, some text will need to be modified to also indicate that when the PKIStatus contains the value one (1) and not just zero (0), a Time Stamp Token can also be present. Otherwise, it should be clear what values for are allowed in the structure "PKIStatus" of a response by a TSA. In this case, I would suggest that you then indicate that the value of one (1) MUST not be used in a time stamping response. d. Under Section 2.4.2, in the definition for the TSTInfo "policy" field, it would be more meaningful to the requester if the document mandated that the error "unacceptedPolicy (15)" be returned instead of the error "badRequest (5)" when the TSA can not produce a response with a the same policy as requested by the requester in the TimeStampReq. e. Since there is no "automated" way for a TSA announce to the world what algorithms it supports to sign Time Stamp Tokens and also what algorithms it supports in messageImprints although I had previously suggested using the S/MIME capabilities attribute for this, I would then suggest that a new Section be added between the current Sections 3 and 4, which would define the minimum set of algorithm that MUST and SHOULD be supported by requesters and TSAs. Based on Section 12 of RFC 2630 [CMS], it could read as follows: 4 Supported Algorithms This section lists the algorithms that must be supported. Additional algorithms that should be supported are also included. 4.1 Hash Algorithms TSA implementations MUST support SHA-1. TSA implementations SHOULD support MD5. Hash algorithm identifiers are located in the MessageImprint hashAlgorithm field, the [CMS] SignedData digestAlgorithms field and the [CMS] SignerInfo digestAlgorithm field. Hash values are located in the MessageImprint and the [CMS] Message Digest authenticated attribute. In addition, hash values are input to signature algorithms. 4.1.1 SHA-1 The SHA-1 hash algorithm is defined in FIPS Pub 180-1 [SHA1]. The algorithm identifier for SHA-1 is: sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } The AlgorithmIdentifier parameters field is optional. If present, the parameters field must contain an ASN.1 NULL. Implementations should accept SHA-1 AlgorithmIdentifiers with absent parameters as well as NULL parameters. Implementations should generate SHA-1 AlgorithmIdentifiers with NULL parameters. 4.1.2 MD5 The MD5 hash algorithm is defined in RFC 1321 [MD5]. The algorithm identifier for MD5 is: md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5 } The AlgorithmIdentifier parameters field must be present, and the parameters field must contain NULL. Implementations may accept the MD5 AlgorithmIdentifiers with absent parameters as well as NULL parameters. 4.2 Signature Algorithms TSA implementations MUST support DSA. TSA implementations MAY include RSA. Signature algorithm identifiers are located in the [CMS] SignerInfo signatureAlgorithm field. Signature values are located in the [CMS] SignerInfo signature field. 4.2.1 DSA The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is always used with the SHA-1 message digest algorithm. The algorithm identifier for DSA is: id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 } The AlgorithmIdentifier parameters field must not be present. 4.2.2 RSA The RSA signature algorithm is defined in RFC 2347 [NEWPKCS#1]. RFC 2347 specifies the use of the RSA signature algorithm with the SHA-1 and MD5 message digest algorithms. The algorithm identifier for RSA is: rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } f. Under Section 6, you will have to add the [son of RFC 2459], which you are now referring under Section 2.3 for the Subject Information Access (SIA). You will also have to add all the references for the supported algorithms (i.e. [SHA1], [MD5], [DSS] and [NEWPKCS#1]) if you agree to add the new Section 4 above on Supported Algorithms. Regards, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 ------_=_NextPart_001_01BFD6EC.50BA7A8C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt

Salut Denis,

Here are few comments on version 8, some a which are = a repeat of previous comments:

a.  Under Section 2.3, the first sentence = indicates that "The TSA MUST sign all time stamp messages with one = or more keys reserved specifically for that purpose". As suggested = before, I would recommend that you add the following sentence after the = first sentence to explain the reason(s) why a TSA could have more than = one key reserved specifically for that purpose: "A TSA MAY have = more than one key to accommodate different policies, different = algorithms and/or different private key sizes".

b.  In Section 2.4.2, the structure = "PKIStatusInfo" is missing the OPTIONAL = "statusString" field, which is defined in RFC 2510 as = PKIFreeText. Because later in Section 2.4.2 it is mentioned that = "The statusString field of PKIStatusInfo MAY be used to include = reason text such as 'messageImprint field is not correctly = formatted'", it would be preferable if the structure = "PKIStatusInfo" in this document was made consistent with the = one in RFC 2510.

c.  Under Section 2.4.2, the structure = "PKIStatus" can take the value of one (1) (i.e. = grantedWithMods), which is defined in RFC 2510 as:

         = grantedWithMods        (1),
         -- = you got something like what you asked for; the
         -- = requester is responsible for ascertaining the differences

However, base on this definition from RFC 2510, it is = not clear in the context of a TSA if this means that a Time Stamp Token = can be present, but its format was modified from what the requester = demanded. If so, some text will need to be modified to also indicate = that when the PKIStatus contains the value one (1) and not just zero = (0), a Time Stamp Token can also be present. Otherwise, it should be = clear what values for are allowed in the structure = "PKIStatus" of a response by a TSA. In this case, I would = suggest that you then indicate that the value of one (1) MUST not be = used in a time stamping response.

d.  Under Section 2.4.2, in the definition for = the TSTInfo "policy" field, it would be more meaningful to = the requester if the document mandated that the error = "unacceptedPolicy (15)" be returned instead of the error = "badRequest (5)" when the TSA can not produce a response with = a the same policy as requested by the requester in the = TimeStampReq.

e.  Since there is no "automated" way = for a TSA announce to the world what algorithms it supports to sign = Time Stamp Tokens and also what algorithms it supports in = messageImprints although I had previously suggested using the = S/MIME

capabilities attribute for this, I would then suggest = that a new Section be added between the current Sections 3 and 4, which = would define the minimum set of algorithm that MUST and SHOULD be = supported by requesters and TSAs. Based on Section 12 of RFC 2630 = [CMS], it could read as follows:

4  Supported Algorithms

   This section lists the algorithms that = must be supported.
   Additional algorithms that should be = supported are also included.

4.1  Hash Algorithms

   TSA implementations MUST support = SHA-1.  TSA implementations SHOULD
   support MD5.

   Hash algorithm identifiers are located = in the MessageImprint
   hashAlgorithm field, the [CMS] = SignedData digestAlgorithms field and
   the [CMS] SignerInfo digestAlgorithm = field.

   Hash values are located in the = MessageImprint and the [CMS] Message
   Digest authenticated attribute.  = In addition, hash values are input
   to signature algorithms.

4.1.1  SHA-1

   The SHA-1 hash algorithm is defined in = FIPS Pub 180-1 [SHA1]. The
   algorithm identifier for SHA-1 = is:

      sha-1 OBJECT = IDENTIFIER ::=3D { iso(1) identified-organization(3)
          oiw(14) = secsig(3) algorithm(2) 26 }

   The AlgorithmIdentifier parameters field = is optional.  If present,
   the parameters field must contain an = ASN.1 NULL.  Implementations
   should accept SHA-1 = AlgorithmIdentifiers with absent parameters as
   well as NULL parameters.  = Implementations should generate SHA-1
   AlgorithmIdentifiers with NULL = parameters.

4.1.2  MD5

   The MD5 hash algorithm is defined in RFC = 1321 [MD5].  The algorithm
   identifier for MD5 is:

      md5 OBJECT IDENTIFIER = ::=3D { iso(1) member-body(2) us(840)
          = rsadsi(113549) digestAlgorithm(2) 5 }

   The AlgorithmIdentifier parameters field = must be present, and the
   parameters field must contain = NULL.  Implementations may accept the
   MD5 AlgorithmIdentifiers with absent = parameters as well as NULL
   parameters.

4.2  Signature Algorithms

   TSA implementations MUST support = DSA.  TSA implementations MAY
   include RSA.

   Signature algorithm identifiers are = located in the [CMS] SignerInfo
   signatureAlgorithm field.

   Signature values are located in the = [CMS] SignerInfo signature
   field.

4.2.1  DSA

   The DSA signature algorithm is defined = in FIPS Pub 186 [DSS].  DSA
   is always used with the SHA-1 message = digest algorithm.  The
   algorithm identifier for DSA is:

      id-dsa-with-sha1 = OBJECT IDENTIFIER ::=3D  { iso(1) member-body(2)
          us(840) = x9-57 (10040) x9cm(4) 3 }

   The AlgorithmIdentifier parameters field = must not be present.

4.2.2  RSA

   The RSA signature algorithm is defined = in RFC 2347 [NEWPKCS#1]. RFC
   2347 specifies the use of the RSA = signature algorithm with the SHA-1
   and MD5 message digest = algorithms.  The algorithm identifier for RSA
   is:

      rsaEncryption OBJECT = IDENTIFIER ::=3D { iso(1) member-body(2)
          us(840) = rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

f.  Under Section 6, you will have to add the = [son of RFC 2459], which you are now referring under Section 2.3 for = the Subject Information Access (SIA). You will also have to add all the = references for the supported algorithms (i.e. [SHA1], [MD5], [DSS] and = [NEWPKCS#1]) if you agree to add the new Section 4 above on Supported = Algorithms.

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

------_=_NextPart_001_01BFD6EC.50BA7A8C-- Received: from imo12.mx.aol.com (imo12.mx.aol.com [152.163.225.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27257 for ; Thu, 15 Jun 2000 09:50:58 -0700 (PDT) From: Scruggs01@aol.com Received: from Scruggs01@aol.com by imo12.mx.aol.com (mail_out_v27.10.) id 7.e3.5c95f91 (4419) for ; Thu, 15 Jun 2000 12:49:05 -0400 (EDT) Message-ID: Date: Thu, 15 Jun 2000 12:48:36 EDT Subject: Unsubscribe To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 109 Unsubscribe Received: from prithvi.psi.soft.net (prithvi.psi.soft.net [164.164.48.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA17146 for ; Thu, 15 Jun 2000 03:55:30 -0700 (PDT) Received: from prithvi (prithvi [164.164.48.3]) by prithvi.psi.soft.net (8.9.0/8.9.0) with ESMTP id QAA72090 for ; Thu, 15 Jun 2000 16:21:21 +0500 Date: Thu, 15 Jun 2000 16:21:21 +0500 (PAKST) From: Venkateshwara Reddy A To: ietf-pkix@imc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16395 for ; Thu, 15 Jun 2000 03:41:17 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26141; Thu, 15 Jun 2000 06:40:55 -0400 (EDT) Message-Id: <200006151040.GAA26141@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt Date: Thu, 15 Jun 2000 06:40:55 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) Author(s) : C. Adams, D. Pinkas, P. Cain, R. Zuccherato Filename : draft-ietf-pkix-time-stamp-08.txt Pages : 22 Date : 14-Jun-00 A time stamping service allows to prove that a datum existed before a particular time and can be used by a Trusted Third Party (TTP) as one component in building reliable non-repudiation services (see [ISONR]). This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. An example of how to prove that a digital signature was generated during the validity period of a public key certificate is given in an annex. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-time-stamp-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-time-stamp-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000614110622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-time-stamp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-time-stamp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000614110622.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA29806 for ; Wed, 14 Jun 2000 18:34:45 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id NAA23027; Thu, 15 Jun 2000 13:34:11 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <96103285213203>; Thu, 15 Jun 2000 13:34:12 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ccwilliams@ntlworld.com, ietf-pkix@imc.org Subject: Re: Are there any TSAs out there? Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Thu, 15 Jun 2000 13:34:12 (NZST) Message-ID: <96103285213203@kahu.cs.auckland.ac.nz> "Christopher Williams" writes: >Does anybody know of any commercial / free implementations of Time Stamp >Protocol server software? I made some quiet inquiries about this a few months back, but there don't seem to be any implementations around. Does anyone have something to test against? Peter. Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA13437 for ; Wed, 14 Jun 2000 10:13:59 -0700 (PDT) Received: (qmail 3122 invoked from network); 14 Jun 2000 17:13:34 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 14 Jun 2000 17:13:34 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Wed, 14 Jun 2000 12:13:32 -0500 Message-ID: <3947BD3E.7AF7CE81@nma.com> Date: Wed, 14 Jun 2000 10:13:34 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Denis Pinkas CC: "'ietf-pkix@imc.org'" Subject: Re: TSA Response serialNumber Field References: <852568F2.0050472B.00@D51MTA04.pok.ibm.com> <393BA827.6487CB21@bull.net> <393C6F32.C7B0BEF8@nma.com> <39479BC0.A23EF657@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Denis Pinkas wrote: > Ed, > > Sorry for the delay to answer. No problem, my comment was not timestamped ;-) Let me retain the thread, for continuity. > > Denis Pinkas wrote: > > > > > I propose that we all look back > > > at the definition we have in the current document. > > > > > > " By adding the XXXX value to the GeneralizedTime, an upper limit of > > > the time at which the timestamp has been created by the TSA can be > > > obtained. In the same way, by subtracting the XXXX to the > > > GeneralizedTime, a lower limit of the time at which the timestamp > > > has been created by the TSA can be obtained." > > > > > > The single remaining question is how do you call XXXX, while > > > sticking to THIS definition. It is currently called "accuracy". If > > > this term is not adequate, please make a proposal. I would like to > > > close this issue soon. > > > > > > > Ed Gerck wrote: > > > > The question is not so much what it is called (even though it would be > > nice to use an already accepted name for it) but that THIS definition is > > broken. > > The *concept* is quite clear and is *not* broken. Since you have not > proposed an alternative to define this concept, I assume that the > word chosen to define the concept is acceptable. Please see the WG archives -- the alternative I suggested and was accepted by some is "uncertainty", and was also defined. > > Pls see the former emails. So, one should not stick to THIS > > definition. > > The definition says what it says and is very clear. It might not be > what you want (we are not making measurements of a value), but we > are seeking 100 % GUARANTEES for the value we get, even if the > "accuracy", as we call it, is pretty large. We are not seeking a > probabilistic answer, even with 99,99 % confidence. My comment is not whether you are seeking a probabilistic answer, but that seeking 100% guarantees is moot in this case -- this is NOT a digital signature, this represents a measurement of a value. So, if the standard wants to warrant that which cannot be warranted then I suggest that this be made clear to this WG and in the standard itself for those that might not have time to wade through all PKIX WG messages. IMO, though, this should NOT be done and the standard should make clear that there is no 100% guarantee on the time stamp -- which does not mean it is useless either, because if the deviation is known (as I suggested must be) then it is possible to get assurances which approach 100% as much as you please as a function of the error bar you want to consider. Cheers, Ed Gerck Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05463 for ; Wed, 14 Jun 2000 07:56:56 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA220174 for ; Wed, 14 Jun 2000 16:59:37 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA21746 for ; Wed, 14 Jun 2000 16:55:56 +0200 Message-ID: <39479CFF.ED3AC6AC@bull.net> Date: Wed, 14 Jun 2000 16:55:59 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: IETF-PXIX Subject: TSP Draft 08 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I take advantage of a pause on the mailing list about TSP, to post a new draft and provide a summary of the main modifications performed to produce draft 8: 1. serial number now matches with the definition of serial number from RFC 2459. 2. The Authority Information Access (AIA) extension has been replaced by a Subject Information Access (SIA) extension which *should* appear in the son of RFC2459. 3. The field: extensions [0] Extensions OPTIONAL has been replaced by: extensions [0] IMPLICIT Extensions OPTIONAL 4. The explanations around the certReq field have been corrected/clarified. 5. Time Stamps users must now be ready to accommodate serial number integers up to 160 bits. 6. An additional field called ordering has been introduced in the response after accuracy: ordering BOOLEAN DEFAULT FALSE, This allows to build two categories of TSAs, whether ordering of Time Stamp tokens from the same TSA within the accuracy of the genTime (e.g. within the same second) is or is not a requirement. 7. The tagging of the two last parameters of the response has been modified in the following way: tsa [0] GeneralName OPTIONAL, extensions [1] Extensions OPTIONAL 8. The tagging of the three parameters of Accuracy has been simplified: Accuracy ::= SEQUENCE { seconds INTEGER OPTIONAL, millis [0] INTEGER (1..999) OPTIONAL, micros [1] INTEGER (1..999) OPTIONAL } 9. A new item 6 has been added to the security considerations section. If you have any comment (I hope you have none. :-| ), please wait until the new draft is made available. Denis Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05201 for ; Wed, 14 Jun 2000 07:51:49 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA366072; Wed, 14 Jun 2000 16:54:26 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA22448; Wed, 14 Jun 2000 16:50:37 +0200 Message-ID: <39479BC0.A23EF657@bull.net> Date: Wed, 14 Jun 2000 16:50:40 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Ed Gerck CC: "'ietf-pkix@imc.org'" Subject: Re: TSA Response serialNumber Field References: <852568F2.0050472B.00@D51MTA04.pok.ibm.com> <393BA827.6487CB21@bull.net> <393C6F32.C7B0BEF8@nma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ed, Sorry for the delay to answer. > Denis Pinkas wrote: > > > I propose that we all look back > > at the definition we have in the current document. > > > > " By adding the XXXX value to the GeneralizedTime, an upper limit of > > the time at which the timestamp has been created by the TSA can be > > obtained. In the same way, by subtracting the XXXX to the > > GeneralizedTime, a lower limit of the time at which the timestamp > > has been created by the TSA can be obtained." > > > > The single remaining question is how do you call XXXX, while > > sticking to THIS definition. It is currently called "accuracy". If > > this term is not adequate, please make a proposal. I would like to > > close this issue soon. > > > > Dennis: > > The question is not so much what it is called (even though it would be > nice to use an already accepted name for it) but that THIS definition is > broken. The *concept* is quite clear and is *not* broken. Since you have not proposed an alternative to define this concept, I assume that the word chosen to define the concept is acceptable. > Pls see the former emails. So, one should not stick to THIS > definition. The definition says what it says and is very clear. It might not be what you want (we are not making measurements of a value), but we are seeking 100 % GUARANTEES for the value we get, even if the "accuracy", as we call it, is pretty large. We are not seeking a probabilistic answer, even with 99,99 % confidence. I have just posted a new draft to the web editor. This new draft should be available soon. Regards, Denis > Cheers, > > Ed Gerck Received: from mail-relay-1.maz.net (mail-relay-1.maz.net [194.163.252.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA00292 for ; Wed, 14 Jun 2000 05:11:55 -0700 (PDT) Received: from sysiphos.maz-hh.de (sysiphos.maz-hh.de [192.109.56.14]) by mail-relay-1.maz.net (8.9.3) with ESMTP id (multiple receipients); Wed, 14 Jun 2000 14:11:28 +0200 (MET DST) Received: from timeproof.de (sp-pc-sej.maz-hh.de [192.109.56.145]) by sysiphos.maz-hh.de (8.9.3/8.9.3) with ESMTP id OAA11549; Wed, 14 Jun 2000 14:10:58 +0200 (MEST) Message-ID: <39477901.9E73A007@timeproof.de> Date: Wed, 14 Jun 2000 14:22:25 +0200 From: Joerg Seidel Organization: timeproof X-Mailer: Mozilla 4.5 [de] (WinNT; U) X-Accept-Language: de MIME-Version: 1.0 To: Christopher Williams CC: PKIX Mailing List Subject: Re: Are there any TSAs out there? References: <002101bfd5df$c2173f70$76c6fc3e@darxstar> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, it is not a software but hardware implementation, but timeproof is planning to implement the time-stamp-protocol as soon as it's draft becomes stable. For details please have a look at our website or contact or sales manager Mr. Förster . Joerg -- __________________________________________________________________ Jörg Seidel phone +49-40-76629-1911 Director Technology fax +49-40-76629-551 timeproof GmbH Harburger Schloßstraße 6-12 mailto:seidel@timeproof.de DE 21079 Hamburg http://www.timeproof.de __________________________________________________________________ Christopher Williams schrieb: > > Does anybody know of any commercial / free implementations of Time Stamp > Protocol server software? > > Christopher Williams > > Software engineer, NetLexis Ltd. > Solutions for secure electronic commerce > http://www.netlexis.com Received: from mta02-svc.server.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA21789 for ; Wed, 14 Jun 2000 02:05:55 -0700 (PDT) Received: from darxstar ([62.252.198.118]) by mta02-svc.server.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20000614100502.HQVN10065.mta02-svc.server.ntlworld.com@darxstar> for ; Wed, 14 Jun 2000 10:05:02 +0000 Message-ID: <002101bfd5df$c2173f70$76c6fc3e@darxstar> From: "Christopher Williams" To: "PKIX Mailing List" Subject: Are there any TSAs out there? Date: Wed, 14 Jun 2000 10:00:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Does anybody know of any commercial / free implementations of Time Stamp Protocol server software? Christopher Williams Software engineer, NetLexis Ltd. Solutions for secure electronic commerce http://www.netlexis.com Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA13515 for ; Wed, 14 Jun 2000 00:36:21 -0700 (PDT) Received: from [38.29.123.149] (ip180.phoenix11.az.pub-ip.psi.net [38.29.123.180]) by snipe.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id AAA24302; Wed, 14 Jun 2000 00:35:06 -0700 (PDT) Mime-Version: 1.0 X-Sender: hoytkesterson@mail.earthlink.net Message-Id: Date: Wed, 14 Jun 2000 00:34:45 -0700 To: OSI Directory List , ietf-pkix@imc.org, ABA Information Security Committee From: "Hoyt L. Kesterson II" Subject: a new revision of the 4th edition of x.509 is on the server Content-Type: text/plain; charset="us-ascii" ; format="flowed" we have recently made a critical fix to x.509. a ballot comment was not accurately captured in the text. the revised text has been placed on the server as ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV4.doc ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV4.pdf the change is to clause 15.1.2.2 Targeting information extension Replace the 6th paragraph following the ASN.1, that currently reads "This extension is always non-critical." with "This extension is always critical." this is likely to be the last change to the text before it ballots in ISO/IEC as a Final Draft International Standard. Once that ballot completes (a yes/no) and the standard can be purchased, this version will be removed from this server. hoyt Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23906 for ; Tue, 13 Jun 2000 08:40:32 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA105958; Tue, 13 Jun 2000 17:43:07 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA37834; Tue, 13 Jun 2000 17:39:28 +0200 Message-ID: <394655B0.33640501@bull.net> Date: Tue, 13 Jun 2000 17:39:28 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Paul Koning CC: martin.szotkowski@ica.cz, ietf-pkix@imc.org Subject: Re: TSA signing key? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> <164901bfd234$2cb1b7c0$0c7011ac@SZOTKOWSKI> <39464FE0.60CFF540@bull.net> <14662.21012.864694.380020@xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Paul, Please, before answering, take a look at the document: 10. to sign each time stamp token using a key generated exclusively for this purpose and have this property of the key indicated on the corresponding certificate. Denis > >>>>> "Denis" == Denis Pinkas writes: > > Denis> Martin, > > Denis> I guess that they are several arguments for that. Let me give > Denis> one. > > Denis> This allows you to build a black box, to place the TSA private > Denis> key in it and then to close the box, only making sure that the > Denis> clock inside is still synchronized with UTC (with respect to > Denis> the accuracy that is guaranted by the TSA). If not, the box > Denis> shall stop working. The private key will not be used for > Denis> signing anything else which would require a management > Denis> interface. If the implementation is poor, this management > Denis> interface could possibly be used to sign, e.g. a wrong > Denis> token. :-( > > >> In draft is written that TSA cert must be used exclusively for > >> time stamp. Why TSA certificate cann't be same as CA certificate? > > If the intent is that the *key* should not be used for other purposes, > it should say that -- restricting the cert doesn't necessarily > constrain the use of the key. > > paul Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22813 for ; Tue, 13 Jun 2000 08:24:45 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQitkn26901; Tue, 13 Jun 2000 15:24:06 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA14649; Tue, 13 Jun 00 11:20:29 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA07114; Tue, 13 Jun 2000 11:24:05 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14662.21012.864694.380020@xedia.com> Date: Tue, 13 Jun 2000 11:24:04 -0400 (EDT) To: Denis.Pinkas@bull.net Cc: martin.szotkowski@ica.cz, ietf-pkix@imc.org Subject: Re: TSA signing key? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> <164901bfd234$2cb1b7c0$0c7011ac@SZOTKOWSKI> <39464FE0.60CFF540@bull.net> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid >>>>> "Denis" == Denis Pinkas writes: Denis> Martin, Denis> I guess that they are several arguments for that. Let me give Denis> one. Denis> This allows you to build a black box, to place the TSA private Denis> key in it and then to close the box, only making sure that the Denis> clock inside is still synchronized with UTC (with respect to Denis> the accuracy that is guaranted by the TSA). If not, the box Denis> shall stop working. The private key will not be used for Denis> signing anything else which would require a management Denis> interface. If the implementation is poor, this management Denis> interface could possibly be used to sign, e.g. a wrong Denis> token. :-( >> In draft is written that TSA cert must be used exclusively for >> time stamp. Why TSA certificate cann't be same as CA certificate? If the intent is that the *key* should not be used for other purposes, it should say that -- restricting the cert doesn't necessarily constrain the use of the key. paul Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22064 for ; Tue, 13 Jun 2000 08:15:54 -0700 (PDT) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA116010; Tue, 13 Jun 2000 17:18:21 +0200 Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA40022; Tue, 13 Jun 2000 17:14:39 +0200 Message-ID: <39464FE0.60CFF540@bull.net> Date: Tue, 13 Jun 2000 17:14:40 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Martin Szotkowski CC: ietf-pkix@imc.org Subject: Re: TSA signing key? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> <164901bfd234$2cb1b7c0$0c7011ac@SZOTKOWSKI> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Martin, I guess that they are several arguments for that. Let me give one. This allows you to build a black box, to place the TSA private key in it and then to close the box, only making sure that the clock inside is still synchronized with UTC (with respect to the accuracy that is guaranted by the TSA). If not, the box shall stop working. The private key will not be used for signing anything else which would require a management interface. If the implementation is poor, this management interface could possibly be used to sign, e.g. a wrong token. :-( Denis > In draft is written that TSA cert must be used exclusively for time stamp. > Why TSA certificate cann't be same as CA certificate? > > thanks Martin Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA19784 for ; Mon, 12 Jun 2000 17:59:07 -0700 (PDT) Received: (qmail 1501 invoked from network); 13 Jun 2000 00:58:24 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.hosting4u.net with SMTP; 13 Jun 2000 00:58:24 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Mon, 12 Jun 2000 19:58:20 -0500 Message-ID: <3945872C.3ABDCA0@nma.com> Date: Mon, 12 Jun 2000 17:58:20 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Ed Gerck , ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> <3941320A.6D65328A@celocom.com> <39415C00.773D4669@nma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Kent wrote: > Ed Gerck wrote: > >A checkbox with "Enforce name chaining" could take care of all cases > >where name chaining is desired, much in the same way that the depth > >of certificate signing can also be chosen by the user in Apache SSL for > >example (or, do you really must trust a CA you don't trust just because it > >chains with a CA you trust? -- maybe, possibly not). > > Based on this approach we could make all aspects of cert processing > user selectable options. No, this is not what I say -- this would be using my words to an extreme limit where they are obviously false and never intended to apply, with the intent to "prove them wrong." However, anything is wrong if taken out of context. If we stay with the case at hand and don' try to outwit the argument by such tricks, then we could recognize that there are cases where a "one size fits all" does not apply. Name chaining is, I suggest, one such case. Again, this does NOT mean that ALL cases are like it. The name PKIX, for example, should not be optional ;-) > >Making name chaining mandatory, OTOH, still does not mean that > >the name is: (i) correct, (ii) valid, (iii) legal, (iv) unique, etc. So, > >if constraints are placed on names this is still much weaker than the > >nonce authentication constraints placed on keys -- where a principal > >must have had use of the private-key in order to sign a nonce. They > >are like apples and speedboats, names and keys. Why then should we > >not differentiate between name validation and certificate validation? > >Cert validation may include name validation but not necessarily and > >there is no cryptographic value to be gained thereby. > > Nonce? What syntax are you referring to? Ed, we've all had the > pleasure of your efforts to redefine X.509 on an ab initio basis. > Please spare us a repeat of such efforts again. I recall much of my efforts have been in the direction of avoding that some, including oftentimes you, would needlessly redefine X.509. For example, as I showed in my analysis of "non-repudiation" as it occurs in the X.509 text itself, in contrast to what was being defined in PKIX. Now, if that discussion left some sour tones as I see between the lines in your text above, please recall that this is an open group based on consensus and that there are no "winners" or "losers" here -- except our loss of time to go back to that which is already closed. Unless, of course, you think that there was something in your arguments then which were not clearly understood by this WG. Regarding the term "nonce" -- in cryptography, "nonce" is a value used no more than once for the same purpose. In X.509, you will find it under the designation "a non-repeating number" when "strong authentication" is defined. To avoid confusion and nitpicking, this what I said above: ...if constraints are placed on names this is still much weaker than the strong authentication constraints placed on keys -- where a principal must have had use of the private-key in order to sign the non-repeating number. They are like apples and speedboats, names and keys. Why then should we not differentiate between name validation and certificate validation? Cert validation may include name validation but not necessarily and there is no cryptographic value to be gained thereby. > >Of course, some years ago everything was quite undifferentiated and > >there was no distinction between different functions which we now > >perceive as distinct. For example, the CA and the NA roles -- as well as > >the CA and the TTP roles. > > the concept of a naming authority (vs. a CA or a directory service > provider) have been recognized in the directory community that begat > X.509, probably for about 15 years. But, some of the names spaces we > use, including DNs, don't have universally recognized NAs, so the > concept is not universally applicable. CAs vs. TTPs? I still think > that a TTP is just one form of CA, so what's the issue here? As you have shown with your own words, some issues do have more than one universally recognized answer. Thus, where there is no bad security consequence the standard must recognize them. Cheers, Ed Gerck Received: from stargate.zergo.com.au (IDENT:root@stargate.zergo.com.au [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19256 for ; Mon, 12 Jun 2000 17:28:30 -0700 (PDT) Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id KAA21264; Tue, 13 Jun 2000 10:32:37 +1000 Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Jun 2000 10:26:46 +1000 Message-ID: From: Michael Zolotarev To: Martin Szotkowski , ietf-pkix@imc.org Subject: RE: TSA signing key? Date: Tue, 13 Jun 2000 10:26:45 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Martin, Not allowing using the same cert for CA and TSA is simply a matter of clearly specifying what a TTP is doing. An entity claiming that it is a TSA (by putting a special value of extKeyUsage flag), accepts certain legal responsibilities which makes it distinct in the PKI world. The responsibilities of CA are 100% different from those of TSA, and you would not generally expect the same physical(!) entity to operate as both a CA and a TSA. A CA which signs a TSA cert (if it is not a self-signed), is expected to perform a diligent check that the subject (TSA) complies to whatever a TSA must be compliant to. For those very reasons, as a verifier of a timestamp, I'd never trust a TSA cert which does not have the extKeyUsage set to "timestamping", and I would be very suspicious about a TSA cert which has both "timestamping" and "CA" flags set. Also, in a TSA cert there may be certain extensions specific to TSA only. And there are heaps of CA-specific extensions too. Mixing them in one certificate will be just messy and more than confusing. If a CA organisation wants to run a TSA, it won't be a problem to issue a dedicated cert for the TSS, be it a self-signed or a CA-signed certificate. Hope it answered your question. Regards Michael > -----Original Message----- > From: Martin Szotkowski [mailto:martin.szotkowski@ica.cz] > Sent: Saturday, June 10, 2000 3:00 AM > To: ietf-pkix@imc.org > Subject: TSA signing key? > > > In draft is written that TSA cert must be used exclusively > for time stamp. > Why TSA certificate cann't be same as CA certificate? > > thanks Martin > Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16991 for ; Mon, 12 Jun 2000 15:16:41 -0700 (PDT) Received: from [128.33.238.77] (TC077.BBN.COM [128.33.238.77]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id SAA25645; Mon, 12 Jun 2000 18:15:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <024701bfd22b$f50eae70$eb0f970a@lon-williamb.intra> References: <024701bfd22b$f50eae70$eb0f970a@lon-williamb.intra> Date: Mon, 12 Jun 2000 17:56:30 -0400 To: "william bamberg" From: Stephen Kent Subject: Re: HTTP over TLS: dNSName syntax question Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Will, >Sorry if this is marginally off topic, but I'd like to know people's >opinions... > >RFC 2818, 'HTTP over TLS', Section 3.1, 'Server Identity' describes how to >compare the name in the server's certificate with the server domain name: > >'If a subjectAltName extension of type dNSName is present, that MUST be used >as the identity. Otherwise, the (most specific) Common Name field in the >Subject field of the certificate MUST be used...Matching is performed using >the matching rules specified by [RFC2459].' > >RFC 2459 says that the dNSName 'MUST be in the "preferred name syntax," as >specified by RFC 1034.' > >So, presumably the matching here is performed by comparing every subdomain >in the dNSName against the corresponding subdomain in the server's domain >name. > >But RFC 2818 goes on to say that 'Names may contain the wildcard character >*' >and goes on to specify how these names should be handled. > >The 'preferred name syntax' says nothing about wildcards, so my question >really is, how can the dNSName component both be represented according to >the 'preferred name syntax', and contain wildcards? RFC 2459 does not allow wildcards in the dNSname attribute, as that would result in strings that are NOT DNS names. The 2818 text refers to an historic convention employed when CAs put DNS names in the CN field of a DN. In fact, the text you cite refers to this convention (that is disparaged in 2459). Note the reference to "Common Name" in that text. So, it seems that the 2818 text is a bit schizophrenic, based on what you say above. (I have not read 2818, so I am taking your word for the relevant quote.) Steve Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16893 for ; Mon, 12 Jun 2000 15:16:02 -0700 (PDT) Received: from [128.33.238.77] (TC077.BBN.COM [128.33.238.77]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id SAA25553; Mon, 12 Jun 2000 18:15:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <39415C00.773D4669@nma.com> References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> <3941320A.6D65328A@celocom.com> <39415C00.773D4669@nma.com> Date: Mon, 12 Jun 2000 17:44:58 -0400 To: Ed Gerck From: Stephen Kent Subject: Re: Correct approach to certificate validation? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Ed, >Oscar Jacobsson wrote: > > > Ed Gerck wrote: > > > So, now the name should trump the key? The tail wants to wag the > > > dog, we may as well say. > > > > > However: if constraints are placed on subject names, they are most > > probably placed there for a reason. Ignoring said constraints, having > > been deemed important enough to distribute signed and in-band, could > > surely hardly be considered prudent? > >A checkbox with "Enforce name chaining" could take care of all cases >where name chaining is desired, much in the same way that the depth >of certificate signing can also be chosen by the user in Apache SSL for >example (or, do you really must trust a CA you don't trust just because it >chains with a CA you trust? -- maybe, possibly not). Based on this approach we could make all aspects of cert processing user selectable options. But, that's not what we have done. We have divided processing rules into those that are uniformly enforced (in principle), those under CA control, and those under user control. Given the difficulty of getting local configuration info right, it's preferable to minimize this last set. >Making name chaining mandatory, OTOH, still does not mean that >the name is: (i) correct, (ii) valid, (iii) legal, (iv) unique, etc. So, >if constraints are placed on names this is still much weaker than the >nonce authentication constraints placed on keys -- where a principal >must have had use of the private-key in order to sign a nonce. They >are like apples and speedboats, names and keys. Why then should we >not differentiate between name validation and certificate validation? >Cert validation may include name validation but not necessarily and >there is no cryptographic value to be gained thereby. Nonce? What syntax are you referring to? Ed, we've all had the pleasure of your efforts to redefine X.509 on an ab initio basis. Please spare us a repeat of such efforts again. >Of course, some years ago everything was quite undifferentiated and >there was no distinction between different functions which we now >perceive as distinct. For example, the CA and the NA roles -- as well as >the CA and the TTP roles. the concept of a naming authority (vs. a CA or a directory service provider) have been recognized in the directory community that begat X.509, probably for about 15 years. But, some of the names spaces we use, including DNs, don't have universally recognized NAs, so the concept is not universally applicable. CAs vs. TTPs? I still think that a TTP is just one form of CA, so what's the issue here? Steve Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16857 for ; Mon, 12 Jun 2000 15:15:53 -0700 (PDT) Received: from [128.33.238.77] (TC077.BBN.COM [128.33.238.77]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id SAA25418; Mon, 12 Jun 2000 18:14:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 12 Jun 2000 17:36:35 -0400 To: "Trevor Freeman" From: Stephen Kent Subject: RE: Correct approach to certificate validation? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Trevor, >Steve, >With the Internet today, if you are relying on directory lookup >based on a DN as you only solution to certificate discovery - I >think you will be disappointed. There will be "communities" who will >be able to get this to work, but there is no sign of a universal >solution equivalent to DNS where I can take any DN and find an >object in a directory with that name. Therefore failure to find a >certificate based on a issuer DN in a certificate is a reality that >will have to be dealt with - for much more fundamental reasons. In general I agree if we're talking about most DNs, and that's why I alluded to use of AIA. But, if one used DC-based DNs, we could leverage the DNS and that would be very powerful. So, for those who might choose to rely on this or analogous discovery approaches, mismatches between CA names in subject and issuer fields would pose a problem. Facilitating an environment in which such mismatches are tolerated by client software undermines the efforts of those who might be trying to use CA DNs for repository discovery. > >There are a couple of instances of by design behavior that have been >presented to me. There are mergers and acquisitions where names and >affiliation are changing. There are also instances where one CA does >not want to endorse the name of another when it cross certifies. The first example does not seem very good; as someone else noted, I would want to reissue the EE certs as much as I want to change the CA cert. I've gone through a bunch of business cards over the last few years as we wer bought, reorganized, bought again, etc. > >The search path mechanism is very similar to AIA, in that given a >set of URLs, you can access the URL looking for certificates. With >LDAP URLs, it's not difficult to construct a generic query. With >other, the underlying assumption is that you find a pkcs#7. The "algorithm" you allude to seems a bit squishy :-), and its scaling features are not at all clear. Steve Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14744 for ; Mon, 12 Jun 2000 13:23:40 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA02664; Mon, 12 Jun 2000 16:23:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39412146.B5FC28EB@nma.com> References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <39412146.B5FC28EB@nma.com> Date: Mon, 12 Jun 2000 16:17:56 -0400 To: Ed Gerck From: Stephen Kent Subject: Re: Correct approach to certificate validation? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Ed, >Stephen Kent wrote: > > > Ed, > > >List: > > > > > >Why should we continue to confuse name validation with > > >certificate validation? Name chaining should be optional IMO, > > >not expected behavior. 'Be liberal in what you expect' can be > > >applied here without A N Y decrease in cryptographic > > >authentication security. > > > > > > > Jon's protocol design advice is good in general, but inappropriate in > > security contexts, where liberal acceptance policies often lead to > > vulnerabilities. > >In this case, however, I see no vulnerability in what X.509/PKIX >intend to provide -- a cryptographic authentication protocol. In >regard to name assignment vulnerabilities, I note that this is also >declared out of scope in X.509/PKIX and delegated to the CA/NA >+ CPS. My observation about the applicability of Jon's admonition to security protocols in general is true. So far we don't have a killer example of a new vulnerability created by this deviation from the standards, just user confusion. Someone suggested to me that if a user is examining the CA names in a path to make a trust judgement, then this inconsistency might cause the user to make a wrong trust decision. I don't know if this is critical, because I doubt that many users would be so diligent, but it is an example of what might happen. You state that our standards do not address name assignment vulnerabilities; we'll PKIX is trying to do this to some extent. There was already some text about a CA's responsibility to verify name data in a cert, although that must be qualified by the CPS/policy. As others have pointed out, there is a fine line here. We don't want to usurp the CA's options here, yet we want to make a general statement about what an RP can expect in a cert. >So, why should that which is declared out of scope trump that >which is the only thing that the protocol verifies? Logic would >indicate that since name validation by name chaining verification >is a weaker concept than the one it is blocking, then this should >not be mandatory behavior. Making it mandatory is what is >confusing, IMO. We disagree on fundamentals here. Name verification in the context of chaining is what one would expect from reading ANY description of X.509 certificates for over a decade and a half. There should be a very good reason to NOT do it before such a deviation from the standards is considered reasonable. Steve Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04109 for ; Mon, 12 Jun 2000 08:05:26 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 11:04:20 -0400 Message-ID: <4B0D36365AD3D2118FF40060972A16C001558BF0@wfhqex01.wangfed.com> From: "Pawling, John" To: "'Sharon Boeyen'" , "'500 list'" Cc: "'ietf-pkix@imc.org'" , "'pki-twg@nist.gov'" , "'Hoyt Kesterson'" Subject: RE: New X.509 defect is 244 Date: Mon, 12 Jun 2000 11:04:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" All, I strongly agree with the solutions proposed in X.509 defect report 244. These changes are important to ensure that certification path verification implementations process all non-critical extensions that they recognize and are capable of processing. ============================================ John Pawling, john.pawling@wang.com Wang Government Services, Inc., A Getronics Company ============================================ Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03803 for ; Mon, 12 Jun 2000 07:59:28 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 10:58:22 -0400 Message-ID: From: Sharon Boeyen To: "'500 list'" Cc: "'ietf-pkix@imc.org'" , "'pki-twg@nist.gov'" , "'Hoyt Kesterson'" Subject: RE: New X.509 defect is 244 Date: Mon, 12 Jun 2000 10:58:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Oops, we were actually more efficient that I thought. I did get the defect report number from Hoyt before I went on vacation. This is defect report number 244. (Note that we may also probably should look at the conformance statements in X.519 and, duplicate appropriate material in 509 itself so that it can stand alone. > -----Original Message----- > From: Sharon Boeyen > Sent: Monday, June 12, 2000 10:41 AM > To: '500 list' > Cc: 'ietf-pkix@imc.org'; 'pki-twg@nist.gov'; 'Hoyt Kesterson' > Subject: New X.509 defect report > > > This is a new defect report against X.509 (1997 and 2000 > editions). It > emerged from the US Bridge CA project participants and indicates that > text regarding handling of non-critical extensions has flaws > and needs > to be fixed. > > I'm submitting this defect report but it represents the result of > discussion that occured among the Bridge CA project participants. > > Also, I apologize for not including a defect report number but Hoyt > is away and I was unable to reach him to get one. > > Hoyt, can you tell us what DR number this will be? > > Sharon > > > DEFECT REPORT FORM > > 1. Defect Report Number: 9594/XXX > > > Title: Handling non-critical extensions > > 2. Source: X.509 Editor (on behalf of US Bridge CA project > participants) > > 3. Addressed to: > 4. (a) > (b) > > 5. Date circulated by WG Secretariat: > > 6. Deadline for Response from Editor: > > 7. Defect Report Concerning: > > ITU-T X.509 (1997 and 2000 editions) | ISO/IEC 9594-8:1997 > and 2000 editions > > 8. Qualifier: > > Error/Clarification > > 9. References in Document: > > Several, See solution proposed by source > > 10. Nature of Defect: > > X.509 clearly states what a certificate-using > system is do in the case where certificate extensions are present and > are are flagged critical. It also clearly states what a > certificate-using > system is to do in the case where certificate extensions are > present, flagged > non-critical, but are not recognized by a certificate-using > system. However, > there are errors, ambiguities and omissions about what a > certificate-using system > is to do when encountering a certificate extension flagged > non-critical, that it > does recognize and is capable of processing. To ensure that > the requirements of > certificate and CRL issuers, as well as requirements for > consistent treatment > of extensions by certificate-using systems, these errors must > be fixed. > > > 11. Solution Proposed by the Source: > > In ITU-T Rec. X.509 and ISO/IEC 9594-8: > > Change 1: In 1997 edition clause 8 and 2000 edition clause 7: > > In the paragraph that begins "The extensions field allows > addition of new ...", > add the following two sentences to the end of the paragraph: > > " When a certificate-using implementation recognizes and is > able to process an extension, then > the certificate-using implementation shall process the > extension regardless of the value > of the criticality flag. Note that any extension that is > flagged non-critical will cause > inconsistent behaviour between certificate-using systems that > will process the extension and > certificate-using that do not recognize the extension and > will ignore it." > > Change 2: In 1997 edition clause 8 and 2000 edition clause 7: > > Add the following immediately after the paragraph that begins "If > unknown elements appear within the extension ...": > > A CA has three options with respect to an extension: > i) it can exclude the extension from the certificate; > ii) it can include the extension and flag it non-critical; > iii) it can include the extension and flag it critical. > > A validation engine has two possible actions to take with > respect to an extension: > i) it can ignore the extension and accept the certificate > (all other things being equal); > ii) it can process the extension and accept or reject the > certificate depending on the > content of the extension and the conditions under which > processing is occuring > (e.g. the current values of the path processing variables). > > Some extensions can ONLY be marked critical. In these cases a > validation engine that > understands the extension, processes it and > acceptance/rejection of the certificate > is dependent (at least in part) on the content of the > extension. A validation engine > that does not understand the extension rejects the certificate. > > Some extensions can ONLY be marked non-critical. In these > cases a validation engine that > understands the extension processes it and > acceptance/rejection of the certificate is > dependent (at least in part) on the content of the extension. > A validation engine that > does not understand the extension accepts the certificate > (unless factors other than > this extension cause it to be rejected). > > Some extensions can be marked critical or non-critical. In > these cases a validation engine > that understands the extension processes it and > acceptance/rejection of the certificate is > dependent (at least in part) on the content of the extension, > regardless of the criticality > flag. A validation engine that does not understand the > extension accepts the certificate if > the extension is marked non-critical (unless factors other > than this extension cause it to > be rejected) and rejects the certificate if the extension is > marked critical. > > When a CA considers including an extension in a certificate > it does so with > the expectation that its intent will be adhered to wherever > possible. If it > is necessary that the content of the extension be considered > prior to ANY > reliance on the certificate, a CA would flag the extension > critical. This > must be done with the realization that any validation engine > that does not > process the extension will reject the certificate (probably > limiting the set > of applications that can verify the certificate). The a CA > may mark certain > extensions non-critical to achieve backward compatibility > with validation > applications that cannot process the extensions. Where the > need for backward > compatibility and interoperability with validation > applications incapable of > processing the extensions is more vital than the ability of the CA to > enforce the extensions, then these optionally critical > extensions would be > marked non-critical. It is most likely that CAs would set > optionally critical > extensions as non-critical during a transition period while > the verifiers' > certificate processing applications are upgraded to ones that > can process the > extensions. > > Change 3: In 1997 edition clause 12.1 and 2000 edition clause 8: > > In the paragraph that begins "In a certificate or CRL, an > extension is flagged ...", > add the following immediately after the third sentence that > ends with "...ignoring > the extension": > > " If an extension is flagged non-critical, a > certificate-using system that does > recognize the extension, shall process the extension." > > Change 4: In 1997 edition clause 12.2.2.3 and 2000 edition > clause 8.2.2.3: > > In the paragraph that begins "If the extension is flagged > non-critical ...", replace > the second sentence with the following: > > "If this extension is present, and the certificate-using > system recognizes and processes > the keyUsage extension type, then the certificate using > system shall ensure that the > certificate shall be used only for a purpose for which the > corresponding key usage > bit is set to one." > > Change 5: In 1997 edition clause 12.2.2.4 and 2000 edition > clause 8.2.2.4: > > In the paragraph that begins "If the extension is flagged > non-critical ...", replace > the second and third sentences with the following: > > "If this extension is present, and the certificate-using > system recognizes and processes > the extendedKeyUsage extension type, then the certificate > using system shall ensure that the > certificate shall be used only for one of the purposes indicated." > > Change 6: In 1997 edition clause 12.4.2.1 and 2000 edition > clause 8.4.2.1: > > In the 4th paragraph following the ASN.1, replace: > "If this extension is present and is flagged critical then:" > with the following: > "If this extension is present and is flagged critical, or is > flagged non-critical but is > recognized by the certificate-using system, then:" > > Change 7: In 1997 edition clause 12.4.2.2 and 2000 edition > clause 8.4.2.2: > > Replace the last sentence "If this extension is present and > is flagged critical ..." with the > following: > > "If this extension is present and is flagged critical, or is > flagged non-critical but > is recognized by the certificate-using system, then the > certificate-using system shall > check that the certification path being processed is > consistent with the value in this > extension." > > > > 12. Editor's Response: > > tbd > > > > Sharon Boeyen > Entrust Technologies > sharon.boeyen@entrust.com > Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03289 for ; Mon, 12 Jun 2000 07:41:58 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 10:40:52 -0400 Message-ID: From: Sharon Boeyen To: "'500 list'" Cc: "'ietf-pkix@imc.org'" , "'pki-twg@nist.gov'" , "'Hoyt Kesterson'" Subject: New X.509 defect report Date: Mon, 12 Jun 2000 10:40:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" This is a new defect report against X.509 (1997 and 2000 editions). It emerged from the US Bridge CA project participants and indicates that text regarding handling of non-critical extensions has flaws and needs to be fixed. I'm submitting this defect report but it represents the result of discussion that occured among the Bridge CA project participants. Also, I apologize for not including a defect report number but Hoyt is away and I was unable to reach him to get one. Hoyt, can you tell us what DR number this will be? Sharon DEFECT REPORT FORM 1. Defect Report Number: 9594/XXX Title: Handling non-critical extensions 2. Source: X.509 Editor (on behalf of US Bridge CA project participants) 3. Addressed to: 4. (a) (b) 5. Date circulated by WG Secretariat: 6. Deadline for Response from Editor: 7. Defect Report Concerning: ITU-T X.509 (1997 and 2000 editions) | ISO/IEC 9594-8:1997 and 2000 editions 8. Qualifier: Error/Clarification 9. References in Document: Several, See solution proposed by source 10. Nature of Defect: X.509 clearly states what a certificate-using system is do in the case where certificate extensions are present and are are flagged critical. It also clearly states what a certificate-using system is to do in the case where certificate extensions are present, flagged non-critical, but are not recognized by a certificate-using system. However, there are errors, ambiguities and omissions about what a certificate-using system is to do when encountering a certificate extension flagged non-critical, that it does recognize and is capable of processing. To ensure that the requirements of certificate and CRL issuers, as well as requirements for consistent treatment of extensions by certificate-using systems, these errors must be fixed. 11. Solution Proposed by the Source: In ITU-T Rec. X.509 and ISO/IEC 9594-8: Change 1: In 1997 edition clause 8 and 2000 edition clause 7: In the paragraph that begins "The extensions field allows addition of new ...", add the following two sentences to the end of the paragraph: " When a certificate-using implementation recognizes and is able to process an extension, then the certificate-using implementation shall process the extension regardless of the value of the criticality flag. Note that any extension that is flagged non-critical will cause inconsistent behaviour between certificate-using systems that will process the extension and certificate-using that do not recognize the extension and will ignore it." Change 2: In 1997 edition clause 8 and 2000 edition clause 7: Add the following immediately after the paragraph that begins "If unknown elements appear within the extension ...": A CA has three options with respect to an extension: i) it can exclude the extension from the certificate; ii) it can include the extension and flag it non-critical; iii) it can include the extension and flag it critical. A validation engine has two possible actions to take with respect to an extension: i) it can ignore the extension and accept the certificate (all other things being equal); ii) it can process the extension and accept or reject the certificate depending on the content of the extension and the conditions under which processing is occuring (e.g. the current values of the path processing variables). Some extensions can ONLY be marked critical. In these cases a validation engine that understands the extension, processes it and acceptance/rejection of the certificate is dependent (at least in part) on the content of the extension. A validation engine that does not understand the extension rejects the certificate. Some extensions can ONLY be marked non-critical. In these cases a validation engine that understands the extension processes it and acceptance/rejection of the certificate is dependent (at least in part) on the content of the extension. A validation engine that does not understand the extension accepts the certificate (unless factors other than this extension cause it to be rejected). Some extensions can be marked critical or non-critical. In these cases a validation engine that understands the extension processes it and acceptance/rejection of the certificate is dependent (at least in part) on the content of the extension, regardless of the criticality flag. A validation engine that does not understand the extension accepts the certificate if the extension is marked non-critical (unless factors other than this extension cause it to be rejected) and rejects the certificate if the extension is marked critical. When a CA considers including an extension in a certificate it does so with the expectation that its intent will be adhered to wherever possible. If it is necessary that the content of the extension be considered prior to ANY reliance on the certificate, a CA would flag the extension critical. This must be done with the realization that any validation engine that does not process the extension will reject the certificate (probably limiting the set of applications that can verify the certificate). The a CA may mark certain extensions non-critical to achieve backward compatibility with validation applications that cannot process the extensions. Where the need for backward compatibility and interoperability with validation applications incapable of processing the extensions is more vital than the ability of the CA to enforce the extensions, then these optionally critical extensions would be marked non-critical. It is most likely that CAs would set optionally critical extensions as non-critical during a transition period while the verifiers' certificate processing applications are upgraded to ones that can process the extensions. Change 3: In 1997 edition clause 12.1 and 2000 edition clause 8: In the paragraph that begins "In a certificate or CRL, an extension is flagged ...", add the following immediately after the third sentence that ends with "...ignoring the extension": " If an extension is flagged non-critical, a certificate-using system that does recognize the extension, shall process the extension." Change 4: In 1997 edition clause 12.2.2.3 and 2000 edition clause 8.2.2.3: In the paragraph that begins "If the extension is flagged non-critical ...", replace the second sentence with the following: "If this extension is present, and the certificate-using system recognizes and processes the keyUsage extension type, then the certificate using system shall ensure that the certificate shall be used only for a purpose for which the corresponding key usage bit is set to one." Change 5: In 1997 edition clause 12.2.2.4 and 2000 edition clause 8.2.2.4: In the paragraph that begins "If the extension is flagged non-critical ...", replace the second and third sentences with the following: "If this extension is present, and the certificate-using system recognizes and processes the extendedKeyUsage extension type, then the certificate using system shall ensure that the certificate shall be used only for one of the purposes indicated." Change 6: In 1997 edition clause 12.4.2.1 and 2000 edition clause 8.4.2.1: In the 4th paragraph following the ASN.1, replace: "If this extension is present and is flagged critical then:" with the following: "If this extension is present and is flagged critical, or is flagged non-critical but is recognized by the certificate-using system, then:" Change 7: In 1997 edition clause 12.4.2.2 and 2000 edition clause 8.4.2.2: Replace the last sentence "If this extension is present and is flagged critical ..." with the following: "If this extension is present and is flagged critical, or is flagged non-critical but is recognized by the certificate-using system, then the certificate-using system shall check that the certification path being processed is consistent with the value in this extension." 12. Editor's Response: tbd Sharon Boeyen Entrust Technologies sharon.boeyen@entrust.com Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA01495 for ; Sun, 11 Jun 2000 18:29:42 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 11 Jun 2000 18:30:15 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Sun, 11 Jun 2000 18:36:54 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD40E.AFF1AEB2" Subject: RE: Correct approach to certificate validation? X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Date: Sun, 11 Jun 2000 18:36:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/Ru2F5TWCKgxP7QKScErHf0p2sTACUb6Jg From: "Trevor Freeman" To: "Al Arsenault" Cc: X-OriginalArrivalTime: 12 Jun 2000 01:36:54.0273 (UTC) FILETIME=[B0562710:01BFD40E] This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD40E.AFF1AEB2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Al, There are two players in this piece. CA and relying parties. THE only point where the name chaining rule can be enforced reliably is when building a self signed root certificate.=20 It you are asserting that if by some change a set of certificate was built where the names did not chain, and that clients who enforced the name chaining rule would consider the chain invalid, whereas clients which did not enforce the rule would consider the chain as valid, then I agree.=20 What I don't see is justification of the rule as being necessary. Why is this rule considered necessary in the standard? Trevor -----Original Message----- From: Al Arsenault [mailto:awa1@home.com]=20 Sent: Thursday, June 08, 2000 7:32 PM To: Trevor Freeman Cc: David P. Kemp; ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? Trevor, Here's the justification: Suppose that a CA system (by, e.g., Netscape, Entrust, VeriSign, whomever) has been built to conform to existing/understood X.509/RFC2459 name chaining rules. Suppose that such a system has been deployed for, oh, say, a large Government department, or a large corporation, or... Now, suppose that a CA from some other corporation that follows the rules you suggest - i.e., name chaining doesn't matter. We want to integrate that CA into the existing PKI. =20 Now, for whatever reason - human frailty, whatever - that new CA is used to create a certificate whose distinguish name is "C=3DAW, O=3DGovernment, OU=3D Computers, CN=3D CA1", and then that CA creates = user certs where the issuer name is "C=3DAW, O=3DGovernment, OU=3DComputer, CN=3DCA1". Note that these names are not equivalent.* Suppose that all other information - AKI, AIA, etc. - is set up properly. Now, whenever a cert path is validated using the new CA, it will be validated, because the fact that the end entity cert's issuer name and the CA cert's subject name aren't the same doesn't matter. However, whenever that same cert path is validated by a node in the existing PKI, validation will fail, because of the name chaining failure. The notion of obtaining different results by different points in the system is disconcerting, to say the least. That's the reason: by building your system this way, you cause the multi-vendor interoperable PKI to fail. If you were building your system to not interoperate with any other existing products, then I think we could probably agree that you were right; there is no real reason that names have to chain. However, lots of people do want your system to interoperate with other products. I'm fairly confident that Dave wants them to. I know that in some of the cases I'm dealing with now, I need them to. And they don't. Al Arsenault Chief Security Architect Diversinet Corp. *And yes, I have seen cases where name chaining failed - and thus certificate validation failed when it shouldn't have - because of a misplaced comma in a CN field. I've also seen it fail because of an extra space in an OU field, and several other situations. > Trevor Freeman wrote: >=20 > Life is complicated, but this is not so bad - Isaac Newton's rules > where around a lot longer before they were found to be wrong. > I am still waiting to here further justification (beyond the old > ground of "its in the spec"). and so far you are confirming my > suspicions that there are none. >=20 > -----Original Message----- > From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > Sent: Thursday, June 08, 2000 8:35 AM > To: ietf-pkix@imc.org > Subject: RE: Correct approach to certificate validation? >=20 > Trevor, >=20 > > From: "Trevor Freeman" > > > > David, > > Interoperability is a primary goal, however that is often scarified > by > > standards. It is very easy to produce a document with a set of do's > and > > don'ts without any regard for the previous standard, the impact on > the > > deployed products or how migration is achieved between the old and > new > > standard. It is also unrealistic to think that all products deployed > > would conform to a single standard. Most products have a lifetime of > > years. The interoperability matrix is vast and getting worse every > time > > a new version of a standard is released. > > So to return to the original point, besides citing a 20 year old > clause > > in a standard, and saying we should do it because its in the > standard, > > and requiring administrators to have a faultless record, I have > still > > not hear any reasoned, argument as to what is actually achieved by > this > > behavior. > > No standard or clause in a standard has a divine right of existence. > > Trevor >=20 > On the one hand, you seem to be decrying the ease of producing new > specifications without regard for previous standards and deployed > products. >=20 > On the other, you seem to support discarding a 20 year old clause > in a standard without regard for its impact on deployed products which > have been built according to the standard. >=20 > The "divine right" of any clause comes not from heaven or inheritance, > but from the fact that it has been vetted internationally (in the ISO > and the IETF) over a period of many years. Over that time (whether > it's > 12 or 20 years is immaterial), the requirement that certificates point > to the correct issuer has not only survived, it has not to my > knowledge > been even mildly controversial. Now that there is discussion of > the topic, the requirement will either survive or be discarded based > on international consensus. There is no divine right, just the > stability (inertia?) of a consensus-based standard-setting > process. >=20 > You may present a case that the requirement should be removed from > X.509 > and then from the PKIX profile of X.509. > Or you may choose not to comply with X.509. >=20 > But you can't both ignore the requirement and claim compliance. >=20 > > Certificate discovery is not the issue here. > > > > For certificate discovery, we have a domain push mechanism as well > as > > AIA. We are also adding a lookup by name, and a configurable URL > search > > path i.e. a set of URLs to search (LDAP, HTTP, FTP) >=20 > Certificate discovery *is* the issue. >=20 > If you are adding a "lookup by name" function to your products, > how will that work if certificates do not have correct issuer > names? If I have someone's End Entity certificate, how do I find a > path of CA certs that leads to my trust point (not necessarily the > certificate subject's trust point), in the multi-vendor, > multi-administrative-domain environment of the Internet. >=20 > Products may support many certificate discovery mechanisms, both > standards-based and differentiating. But there needs to be at > least one "Internet" interoperability mode which all products > support. That mode is defined by PKIX: the certificate profile > and the LDAP schema. >=20 > One "Internet mode" mechanism which follows the current PKIX > specifications is for organizations to place public information, > including CA and EE certificates, in border directories, and to link > the border directories together using directory-to-directory chaining, > LDAP referrals, or both. If you propose to eliminate the X.509 > requirement for correct issuer names, you will need to address the > impact on current applications built to the current standards, > as well as the feasability of future applications built to an > amended standard. >=20 > Dave >=20 > P.S. I don't understand why you keep referring to "punishing > administrators" and "requiring administrators to have a flawless > record" and "eliminating imperfection". A CA workstation has its own > signing key and certificate. If the workstation cannot correctly > place > its own name in the issuer field of every certificate it signs, that > is > a product flaw. This X.509 requirement does not hinge upon human > perfectability. ------_=_NextPart_001_01BFD40E.AFF1AEB2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

Al,
There are two players in this piece. CA and relying = parties. THE only point where the name chaining rule can be enforced = reliably is when building a self signed root certificate.

It you are asserting that if by some change a set of = certificate was built where the names did not chain, and that clients = who enforced the name chaining rule would consider the chain invalid, = whereas clients which did not enforce the rule would consider the chain = as valid, then I agree.

What I don't see is justification of the rule as being = necessary.
Why is this rule considered necessary in the = standard?
Trevor

 -----Original Message-----
From:   Al Arsenault [mailto:awa1@home.com]
Sent:   Thursday, June 08, 2000 7:32 = PM
To:     Trevor Freeman
Cc:     David P. Kemp; = ietf-pkix@imc.org
Subject:        = Re: Correct approach to certificate validation?

Trevor,

        Here's the = justification:

        Suppose = that a CA system (by, e.g., Netscape, Entrust, VeriSign,
whomever) has been built to conform to = existing/understood X.509/RFC2459
name chaining rules.  Suppose that such a system = has been deployed for,
oh, say, a large Government department, or a large = corporation, or...

        Now, = suppose that a CA from some other corporation that follows the
rules you suggest - i.e., name chaining doesn't = matter.  We want to
integrate that CA into the existing PKI.  =

        Now, for = whatever reason - human frailty, whatever - that new CA is
used to create a certificate whose distinguish name = is "C=3DAW,
O=3DGovernment, OU=3D Computers, CN=3D CA1", and = then that CA creates user
certs where the issuer name is "C=3DAW, = O=3DGovernment, OU=3DComputer,
CN=3DCA1".  Note that these names are not = equivalent.*

        Suppose = that all other information - AKI, AIA, etc. - is set up
properly.

        Now, = whenever a cert path is validated using the new CA, it will be
validated, because the fact that the end entity = cert's issuer name and
the CA cert's subject name aren't the same doesn't = matter.  However,
whenever that same cert path is validated by a node = in the existing PKI,
validation will fail, because of the name chaining = failure. The notion
of obtaining different results by different points in = the system is
disconcerting, to say the least.

        That's the = reason:  by building your system this way, you cause the
multi-vendor interoperable PKI to fail.  If you = were building your
system to not interoperate with any other existing = products, then I
think we could probably agree that you were right; = there is no real
reason that names have to chain.  However, lots = of people do want your
system to interoperate with other products.  I'm = fairly confident that
Dave wants them to.  I know that in some of the = cases I'm dealing with
now, I need them to.  And they don't.

        =         =         Al = Arsenault
        =         =         Chief Security = Architect
        =         =         Diversinet = Corp.

*And yes, I have seen cases where name chaining failed = - and thus
certificate validation failed when it shouldn't have = - because of a
misplaced comma in a CN field.  I've also seen = it fail because of an
extra space in an OU field, and several other = situations.


> Trevor Freeman wrote:
>
> Life is complicated, but this is not so bad - = Isaac Newton's rules
> where around a lot longer before they were found = to be wrong.
> I am still waiting to here further justification = (beyond the old
> ground of "its in the spec"). and so = far you are confirming my
> suspicions that there are none.
>
>  -----Original Message-----
> From:   David P. Kemp [mailto:dpkemp@missi.ncsc.mil]
> Sent:   Thursday, June 08, 2000 8:35 = AM
> To:     = ietf-pkix@imc.org
> = Subject:        RE: Correct approach = to certificate validation?
>
> Trevor,
>
> > From: "Trevor Freeman" = <trevorf@Exchange.Microsoft.com>
> >
> > David,
> > Interoperability is a primary goal, however = that is often scarified
> by
> > standards. It is very easy to produce a = document with a set of do's
> and
> > don'ts  without any regard for the = previous standard, the impact on
> the
> > deployed products or how migration is = achieved between the old and
> new
> > standard. It is also unrealistic to think = that all products deployed
> > would conform to a single standard. Most = products have a lifetime of
> > years. The interoperability matrix is vast = and getting worse every
> time
> > a new version of  a standard is = released.
> > So to return to the original point, besides = citing a 20 year old
> clause
> > in a standard, and saying we should do it = because its in the
> standard,
> > and requiring administrators to have a = faultless record, I have
> still
> > not hear any reasoned, argument as to what = is actually achieved by
> this
> > behavior.
> > No standard or clause in a standard has a = divine right of existence.
> > Trevor
>
> On the one hand, you seem to be decrying the = ease of producing new
> specifications without regard for previous = standards and deployed
> products.
>
> On the other, you seem to support discarding a = 20 year old clause
> in a standard without regard for its impact on = deployed products which
> have been built according to the = standard.
>
> The "divine right" of any clause comes = not from heaven or inheritance,
> but from the fact that it has been vetted = internationally (in the ISO
> and the IETF) over a period of many years.  = Over that time (whether
> it's
> 12 or 20 years is immaterial), the requirement = that certificates point
> to the correct issuer has not only survived, it = has not to my
> knowledge
> been even mildly controversial.   Now = that there is discussion of
> the topic, the requirement will either survive = or be discarded based
> on international consensus.   There is = no divine right, just the
> stability (inertia?) of a consensus-based = standard-setting
> process.
>
> You may present a case that the requirement = should be removed from
> X.509
> and then from the PKIX profile of X.509.
> Or you may choose not to comply with = X.509.
>
> But you can't both ignore the requirement and = claim compliance.
>
> > Certificate discovery is not the issue = here.
> >
> > For certificate discovery,  we have a = domain push mechanism as well
> as
> > AIA. We are also adding a lookup by name, = and a configurable URL
> search
> > path i.e. a set of URLs to search (LDAP, = HTTP, FTP)
>
> Certificate discovery *is* the issue.
>
> If you are adding a "lookup by name" = function to your products,
> how will that work if certificates do not have = correct issuer
> names?  If I have someone's End Entity = certificate, how do I find a
> path of CA certs that leads to my trust point = (not necessarily the
> certificate subject's trust point), in the = multi-vendor,
> multi-administrative-domain environment of the = Internet.
>
> Products may support many certificate discovery = mechanisms, both
> standards-based and differentiating.  But = there needs to be at
> least one "Internet" interoperability = mode which all products
> support.  That mode is defined by PKIX: the = certificate profile
> and the LDAP schema.
>
> One "Internet mode" mechanism which = follows the current PKIX
> specifications is for organizations to place = public information,
> including CA and EE certificates, in border = directories, and to link
> the border directories together using = directory-to-directory chaining,
> LDAP referrals, or both.  If you propose to = eliminate the X.509
> requirement for correct issuer names, you will = need to address the
> impact on current applications built to the = current standards,
> as well as the feasability of future = applications built to an
> amended standard.
>
> Dave
>
> P.S.  I don't understand why you keep = referring to "punishing
> administrators" and "requiring = administrators to have a flawless
> record" and "eliminating = imperfection".  A CA workstation has its own
> signing key and certificate.  If the = workstation cannot correctly
> place
> its own name in the issuer field of every = certificate it signs, that
> is
> a product flaw.  This X.509 requirement = does not hinge upon human
> perfectability.

------_=_NextPart_001_01BFD40E.AFF1AEB2-- Received: from notes-gate.yamato.ibm.com (notes-gate.yamato.ibm.co.jp [203.141.89.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15002 for ; Sun, 11 Jun 2000 07:10:42 -0700 (PDT) Received: from d22mta10.yamato.ibm.com (d22mta10.yamato.ibm.com [9.68.246.85]) by notes-gate.yamato.ibm.com (8.9.3/3.7W/NG3.6) with SMTP id XAA283322 for ; Sun, 11 Jun 2000 23:19:38 +0900 Received: by d22mta10.yamato.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 492568FB.004ED608 ; Sun, 11 Jun 2000 23:21:06 +0900 X-Lotus-FromDomain: IBMJP@INTERNET From: "Motoyuki J Suzuki" To: ietf-pkix@imc.org Message-ID: <492568FB.004ED581.00@d22mta10.yamato.ibm.com> Date: Sun, 11 Jun 2000 23:11:27 +0900 Subject: unsubscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii unsubscribe Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07452 for ; Fri, 9 Jun 2000 14:18:34 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FVW00F01OX6UN@ext-mail.valicert.com> for ietf-pkix@imc.org; Fri, 09 Jun 2000 14:27:06 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FVW00FLROX62A@ext-mail.valicert.com>; Fri, 09 Jun 2000 14:27:06 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 09 Jun 2000 14:21:16 -0700 Content-return: allowed Date: Fri, 09 Jun 2000 14:21:15 -0700 From: Frank Balluffi Subject: RE: Correct approach to certificate validation? To: "'jimsch@nwlink.com'" , "'David P. Kemp'" , ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE2E08B10@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=windows-1252 Regarding a company changing its name, it is difficult for me to imagine a scenario in which a company would need to change the subject in its certificate but not need to change the issuer in the certificates that it has issued. Frank > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Thursday, June 08, 2000 9:36 PM > To: 'David P. Kemp'; ietf-pkix@imc.org > Subject: RE: Correct approach to certificate validation? > > > David, > > My draft has nothing to do with the fact that the name chaining may be > incorrect but applies even in the cases where name chaining > is present and > correct. > > There are various cases where not going strictly on name > chaining can be > benifitual. For example, if a company changes names the CA > certificate can > be updated without having to re-issue all subordiante > certificates at the > same time. (This may happen due to merges, splits, name > changes or court > ordered actions.) > > jim > > -----Original Message----- > From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > Sent: Wednesday, June 07, 2000 7:00 AM > To: ietf-pkix@imc.org > Subject: RE: Correct approach to certificate validation? > > > Trevor, > > It isn't about punishing administrators for minor errors, it is > about achieving an overall system with the goals of being both > secure and non-intrusive to the end user. That may well mean that > administrators have to do more thinking, planning, and > quality control, > but that is what they (we, the providers of a PKI for our branch of > Govt) are paid to do. > > The specific case I'm referring to is Jim Schaad's assertion that an > S/MIME-specific cert path attribute is needed because applications > can't find CA certificates. I didn't realize until now that that was > because in your environment subject certificates are not required to > have a correct issuer name! It seemed obvious to me that the PKI is > responsible for correctly binding names to keys. But you are saying > that Issuer names don't really matter, they're just a hint to help > applications search for a cert with a signing key that validates the > subject cert signature. Well no wonder applications can't find CA > certs in that environment! > > That isn't necessarily a wrong theoretical approach - SPKI is based > on the premise that only keys are important, names are simply optional > attributes attached to keys. But it is wrong in X.509 because X.509 > certificates are identified by and stored under Distinguished Names, > not public keys or SubjectKeyIdentifiers. > > Standards are about interworking in a multi-vendor environment; the > testable requirements contained in standards are covenants between > supplier and customer. My goal is for a CMI purchased from vendor > X and operated by company A to work with applications purchased from > vendors Y and Z and operated by companies B and C. I understand > that that is not your primary goal, but I expect you to acknowledge > that when as a result of non-conformance some applications work and > others don't, it is NOT the fault of the conforming applications even > when they are the ones that fail. And that when someone from company > X proposes as a Standard a workaround for a problem created somewhere > else in company X, the IETF is entitled to disregard the > company-specific rationale for that workaround. > > Regards, > Dave > > > > > From: "Trevor Freeman" > > > > Hi David, > > I am afraid I don't see it necessary to eradicate every little > > imperfection because it is there. To err is human, and people make > > mistakes. People also have a wide list of requires which > you may or may > > not agree with, but it does not mean that it is less real to them. > > So I don't see this as an error, simple a different point > of view, and > > we will obviously disagree on this point. > > At the end of the day it is up to any product vendor to > make the call as > > to what is\is not in their product, regardless what is in > the standard. > > It is up to the market place to decide. History certainly > tells us that > > customers like robustness in a product. > > If you can cite a specific issue, then we will obviously > reconsider, but > > I don't find punishing minor infractions of administrators > a compelling > > case. > > Trevor > > Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA06741 for ; Fri, 9 Jun 2000 13:56:28 -0700 (PDT) Received: (qmail 6345 invoked from network); 9 Jun 2000 21:05:01 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.communitech.net with SMTP; 9 Jun 2000 21:05:01 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 09 Jun 2000 16:04:59 -0500 Message-ID: <39415C00.773D4669@nma.com> Date: Fri, 09 Jun 2000 14:05:04 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> <3941320A.6D65328A@celocom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oscar Jacobsson wrote: > Ed Gerck wrote: > > So, now the name should trump the key? The tail wants to wag the > > dog, we may as well say. > > However: if constraints are placed on subject names, they are most > probably placed there for a reason. Ignoring said constraints, having > been deemed important enough to distribute signed and in-band, could > surely hardly be considered prudent? A checkbox with "Enforce name chaining" could take care of all cases where name chaining is desired, much in the same way that the depth of certificate signing can also be chosen by the user in Apache SSL for example (or, do you really must trust a CA you don't trust just because it chains with a CA you trust? -- maybe, possibly not). Making name chaining mandatory, OTOH, still does not mean that the name is: (i) correct, (ii) valid, (iii) legal, (iv) unique, etc. So, if constraints are placed on names this is still much weaker than the nonce authentication constraints placed on keys -- where a principal must have had use of the private-key in order to sign a nonce. They are like apples and speedboats, names and keys. Why then should we not differentiate between name validation and certificate validation? Cert validation may include name validation but not necessarily and there is no cryptographic value to be gained thereby. Of course, some years ago everything was quite undifferentiated and there was no distinction between different functions which we now perceive as distinct. For example, the CA and the NA roles -- as well as the CA and the TTP roles. Cheers, Ed Gerck Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA04581 for ; Fri, 9 Jun 2000 12:01:49 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Jun 2000 11:27:55 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Fri, 9 Jun 2000 11:36:13 -0700 content-class: urn:content-classes:message Subject: RE: Correct approach to certificate validation? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD241.964A9470" Date: Fri, 9 Jun 2000 11:36:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4390.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/RpYvr/R0mTULqScSPtcRBnaryigACZ76w From: "Trevor Freeman" To: "Stephen Kent" Cc: X-OriginalArrivalTime: 09 Jun 2000 18:36:13.0177 (UTC) FILETIME=[96A50E90:01BFD241] This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD241.964A9470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Steve, With the Internet today, if you are relying on directory lookup based on a DN as you only solution to certificate discovery - I think you will be disappointed. There will be "communities" who will be able to get this to work, but there is no sign of a universal solution equivalent to DNS where I can take any DN and find an object in a directory with that name. Therefore failure to find a certificate based on a issuer DN in a certificate is a reality that will have to be dealt with - for much more fundamental reasons. There are a couple of instances of by design behavior that have been presented to me. There are mergers and acquisitions where names and affiliation are changing. There are also instances where one CA does not want to endorse the name of another when it cross certifies. The search path mechanism is very similar to AIA, in that given a set of URLs, you can access the URL looking for certificates. With LDAP URLs, it's not difficult to construct a generic query. With other, the underlying assumption is that you find a pkcs#7. Trevor -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Thursday, June 08, 2000 12:21 PM To: Trevor Freeman Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, >Certificate discovery is not the issue here. I know that the focus of the discussion has been matching up subject=20 and issuer names when validating a cert path. However, since cert=20 path discovery logically precedes validation, and since the nominal=20 model for discovery is based on looking for a CA cert that contains a=20 subject name that was the issuer name on the "lower" level cert, I=20 think it appropriate to ask the discovery question. >The question is that if you have a certificate who's signature=20 >integrity can be traced up to a trusted root, containing acceptable=20 >policy as defined by that root, and who's names lie within the=20 >allowed namespaces as defined by the name constraints in parent=20 >certificates to the certificate in question, what is the value in=20 >checking that the issuer-subject names chain? >We have encountered such situations, by design, and by accident. In=20 >all cases, the cost\benefit analysis in our view is stacked in favor=20 >of not performing the name chaining check, and tolerating this=20 >situation. Could you provide some examples of the "by design" situations you=20 have encountered? >I agree that name constraints are important as the certificate is=20 >making those names available to the applications, so it is important=20 >that we can filter acceptable from not-acceptable names. We actually=20 >follow a methodology similar to one you mentioned in a previous=20 >thread which is to build all possible paths, then apply the name=20 >constraints to determine the quality of the path. I don't recall suggesting the approach you mention here. I would=20 guess that path discovery performed using subject/issuer name=20 matching and AIK/SIK discrimination would rarely yield multiple=20 paths. But, if it did, then I agree that application of the name=20 constraints extension as part of path validation would discard paths=20 that violated the constraints. >For certificate discovery, we have a domain push mechanism as well=20 >as AIA. We are also adding a lookup by name, and a configurable URL=20 >search path i.e. a set of URLs to search (LDAP, HTTP, FTP) The domain push mechanism sounds local, perhaps MS specific? AIA=20 would be definitive. Does one look at the issuer name to select a=20 subset of the search search paths you allude to, or do you just try=20 to do lookups via ll of them? Steve ------_=_NextPart_001_01BFD241.964A9470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

Steve,
With the Internet today, if you are relying on = directory lookup based on a DN as you only solution to certificate = discovery - I think you will be disappointed. There will be = "communities" who will be able to get this to work, but there = is no sign of a universal solution equivalent to DNS where I can take = any DN and find an object in a directory with that name. Therefore = failure to find a certificate based on a issuer DN in a certificate is a = reality that will have to be dealt with - for much more fundamental = reasons.

There are a couple of instances of by design behavior = that have been presented to me. There are mergers and acquisitions where = names and affiliation are changing. There are also instances where one = CA does not want to endorse the name of another when it cross = certifies.

The search path mechanism is very similar to AIA, in = that given a set of URLs, you can access the URL looking for = certificates. With LDAP URLs, it's not difficult to construct a generic = query. With other, the underlying assumption is that you find a = pkcs#7.

Trevor

 -----Original Message-----
From:   Stephen Kent [mailto:kent@bbn.com]
Sent:   Thursday, June 08, 2000 12:21 = PM
To:     Trevor Freeman
Cc:     ietf-pkix@imc.org
Subject:        = RE: Correct approach to certificate validation?

Trevor,

>Certificate discovery is not the issue = here.

I know that the focus of the discussion has been = matching up subject
and issuer names when validating a cert path.  = However, since cert
path discovery logically precedes validation, and = since the nominal
model for discovery is based on looking for a CA cert = that contains a
subject name that was the issuer name on the = "lower" level cert, I
think it appropriate to ask the discovery = question.

>The question is that if you have a certificate = who's signature
>integrity can be traced up to a trusted root, = containing acceptable
>policy as defined by that root, and  who's = names lie within the
>allowed namespaces as defined by the name = constraints in parent
>certificates to the certificate in question, what = is the value in
>checking that the issuer-subject names = chain?
>We have encountered such situations, by design, = and by accident. In
>all cases, the cost\benefit analysis in our view = is stacked in favor
>of not performing the name chaining check, and = tolerating this
>situation.

Could you provide some examples of the "by = design" situations you
have encountered?

>I agree that name constraints are important as the = certificate is
>making those names available to the applications, = so it is important
>that we can filter acceptable from not-acceptable = names. We actually
>follow a methodology similar to one you mentioned = in a previous
>thread which is to build all possible paths, then = apply the name
>constraints to determine the quality of the = path.

I don't recall suggesting the approach you mention = here.  I would
guess that path discovery performed using = subject/issuer name
matching and AIK/SIK discrimination would rarely = yield multiple
paths. But, if it did, then I agree that application = of the name
constraints extension as part of path validation = would discard paths
that violated the constraints.

>For certificate discovery,  we have a domain = push mechanism as well
>as AIA. We are also adding a lookup by name, and = a configurable URL
>search path i.e. a set of URLs to search (LDAP, = HTTP, FTP)

The domain push mechanism sounds local, perhaps MS = specific?  AIA
would be definitive.  Does one look at the = issuer name to select a
subset of the search search paths you allude to, or = do you just try
to do lookups via ll of them?

Steve


------_=_NextPart_001_01BFD241.964A9470-- Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02969 for ; Fri, 9 Jun 2000 10:58:17 -0700 (PDT) Received: by ns.celocom.se; id UAA28669; Fri, 9 Jun 2000 20:06:47 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma028638; Fri, 9 Jun 00 20:06:03 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id UAA01628; Fri, 9 Jun 2000 20:08:38 +0200 Message-ID: <3941320A.6D65328A@celocom.com> Date: Fri, 09 Jun 2000 20:06:02 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ed Gerck CC: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCE6C76DA8CA93233F3045CEB" This is a cryptographically signed message in MIME format. --------------msCE6C76DA8CA93233F3045CEB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ed Gerck wrote: > So, now the name should trump the key? The tail wants to wag the > dog, we may as well say. Neither name nor key would amount to much on their own, IMHO. I agree that there is a great deal of ambiguity regarding how certificate subjects are named. Naming conventions are decided on a per-issuer basis, IIRC, which has confused quite a few of my countrymen, being used to having access to a government-issued personal identification number. However: if constraints are placed on subject names, they are most probably placed there for a reason. Ignoring said constraints, having been deemed important enough to distribute signed and in-band, could surely hardly be considered prudent? //oscar --------------msCE6C76DA8CA93233F3045CEB Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjA5MTgwNjAz WjAjBgkqhkiG9w0BCQQxFgQUfcp3P3jCw6IVzn7N0416FZPGZdYwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBk/U6KE0mQz5d6vQfBrrKxkwbCsgTt uYFHV65vPxTLAbHWgC/aKBl5Ji/PQpg2f+wWwz9X7rrn3Z1DLt1G0qI261M0H8fi0U/7CEsw Wjs7mvkhR6P4fNEk5JJ4Hthb6KZ4mBLtDCa+iwX2tSEAirGuefEgMETLFace1cX9B+okFA== --------------msCE6C76DA8CA93233F3045CEB-- Received: from server.ica.cz (server.ica.cz [195.47.13.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01698 for ; Fri, 9 Jun 2000 09:51:55 -0700 (PDT) Received: from SZOTKOWSKI (com.ica.cz [195.47.13.10]) by server.ica.cz (8.9.2/8.8.7) with SMTP id TAA11854 for ; Fri, 9 Jun 2000 19:00:11 +0200 (CEST) Message-ID: <164901bfd234$2cb1b7c0$0c7011ac@SZOTKOWSKI> From: "Martin Szotkowski" To: References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <39411D1C.795C399D@nma.com> Subject: TSA signing key? Date: Fri, 9 Jun 2000 19:00:10 +0200 Organization: PVT, a.s. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In draft is written that TSA cert must be used exclusively for time stamp. Why TSA certificate cann't be same as CA certificate? thanks Martin Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01410 for ; Fri, 9 Jun 2000 09:45:58 -0700 (PDT) Received: (qmail 5578 invoked from network); 9 Jun 2000 16:54:30 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.communitech.net with SMTP; 9 Jun 2000 16:54:30 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 09 Jun 2000 11:54:26 -0500 Message-ID: <39412146.B5FC28EB@nma.com> Date: Fri, 09 Jun 2000 09:54:30 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Kent wrote: > Ed, > >List: > > > >Why should we continue to confuse name validation with > >certificate validation? Name chaining should be optional IMO, > >not expected behavior. 'Be liberal in what you expect' can be > >applied here without A N Y decrease in cryptographic > >authentication security. > > > > Jon's protocol design advice is good in general, but inappropriate in > security contexts, where liberal acceptance policies often lead to > vulnerabilities. In this case, however, I see no vulnerability in what X.509/PKIX intend to provide -- a cryptographic authentication protocol. In regard to name assignment vulnerabilities, I note that this is also declared out of scope in X.509/PKIX and delegated to the CA/NA + CPS. So, why should that which is declared out of scope trump that which is the only thing that the protocol verifies? Logic would indicate that since name validation by name chaining verification is a weaker concept than the one it is blocking, then this should not be mandatory behavior. Making it mandatory is what is confusing, IMO. Cheers, Ed Gerck Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA00995 for ; Fri, 9 Jun 2000 09:28:10 -0700 (PDT) Received: (qmail 27848 invoked from network); 9 Jun 2000 16:36:42 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.communitech.net with SMTP; 9 Jun 2000 16:36:42 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Fri, 09 Jun 2000 11:36:40 -0500 Message-ID: <39411D1C.795C399D@nma.com> Date: Fri, 09 Jun 2000 09:36:44 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oscar Jacobsson wrote: > Ed Gerck wrote: > > Why should we continue to confuse name validation with > > certificate validation? Name chaining should be optional IMO, > > not expected behavior. 'Be liberal in what you expect' can be > > applied here without A N Y decrease in cryptographic > > authentication security. > > My personal opinion, and humble one at that, is that the issue is of > greater importance than "simply" one of cryptographic security. > > The principals of X.509, as has been previously stated in this thread, > are in the naming, and not in the cryptographic keys themselves. But X.509 is moot on how to verify such names [1,2], which task it delegates to the CA (and NA). The ONLY verification procedure that X.509 specifies [2] is on the subject's key pair by requiring nonce authentication -- the subject must prove possession of the private-key. So, in X.509 (and PKIX) what we have are *two* pieces of data with different validity levels: 1. the public-key was positively verified 2. the name was hearsay. So, now the name should trump the key? The tail wants to wag the dog, we may as well say. Of course, I agree that an additional function COULD provide for name validation according to chaining rules but satisfying such a function should be optional, not expected. Cheers, Ed Gerck [1] Section 11.2 of X.509v3, "Management of certificates", states that the certificate allows an association between a name called "unique distinguished name" or DN for the user and the user's public-key: "A certificate associates the public key and unique distinguished name of the user it describes.", while Section 7 explains that such DNs are essential to the security design of X.509: "Authentication relies on each user possessing a unique distinguished name." But, how are such DNs assigned? Where are they unique? The DN is denoted by a NA (Naming Authority) and accepted by a CA (Certification Authority) as unique within the CA's domain, where the CA can double as a NA. HOWEVER, note that the same user can have different DNs in different CAs, or can use the same DN in different CAs even if it is not the first one to use it in a CA -- so that different DNs for different CAs do not necessarily mean different users and vice-versa. Further, a DN does not have to contain the user's real-world name or location. Thus, semantically, the CA certificate refers to a name; however it does not denote it. [2] X.509 is moot on validation procedures for data included in a certificate such as the user's name, with the exception of validation procedures for the user's public-key which are suggested (not mandated) in Section 10 of X.509v3. For example, regarding validation procedures for the user's identity, Section 11.2.a states that: "a certification authority shall be satisfied of the identity of a user before creating a certificate for it", which means that identity validation procedures are to be satisfied in the CA's frame of reference by following the CA's own self-defined rules (CPS), which are declared outside the scope of X.509 and can be entirely different for different CAs. Received: from symbianuk05.symbian.com ([194.200.144.243]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28242 for ; Fri, 9 Jun 2000 08:56:09 -0700 (PDT) Received: from lon-williamb ([10.151.15.235]) by symbianuk05.symbian.com (Lotus Domino Release 5.0.1b (Intl)) with SMTP id 2000060917011389:25271 ; Fri, 9 Jun 2000 17:01:13 +0100 Message-ID: <024701bfd22b$f50eae70$eb0f970a@lon-williamb.intra> From: "william bamberg" To: Subject: HTTP over TLS: dNSName syntax question Date: Fri, 9 Jun 2000 17:00:53 +0100 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-MIMETrack: Itemize by SMTP Server on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 09/06/2000 05:01:13 PM, Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 09/06/2000 05:01:46 PM, Serialize complete at 09/06/2000 05:01:46 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Sorry if this is marginally off topic, but I'd like to know people's opinions... RFC 2818, 'HTTP over TLS', Section 3.1, 'Server Identity' describes how to compare the name in the server's certificate with the server domain name: 'If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used...Matching is performed using the matching rules specified by [RFC2459].' RFC 2459 says that the dNSName 'MUST be in the "preferred name syntax," as specified by RFC 1034.' So, presumably the matching here is performed by comparing every subdomain in the dNSName against the corresponding subdomain in the server's domain name. But RFC 2818 goes on to say that 'Names may contain the wildcard character *' and goes on to specify how these names should be handled. The 'preferred name syntax' says nothing about wildcards, so my question really is, how can the dNSName component both be represented according to the 'preferred name syntax', and contain wildcards? Thanks very much for any help you can offer. Will Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27976 for ; Fri, 9 Jun 2000 08:55:19 -0700 (PDT) Received: by ns.celocom.se; id SAA25342; Fri, 9 Jun 2000 18:03:48 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma025297; Fri, 9 Jun 00 18:03:25 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id SAA30768; Fri, 9 Jun 2000 18:06:01 +0200 Message-ID: <3941154C.22D86807@celocom.com> Date: Fri, 09 Jun 2000 18:03:24 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <3940DF3A.7D592D88@celocom.com> <394102D9.AF41B95A@celocom.com> <39410C15.4A2EECDF@celocom.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5A69A9209B0A2DAD24DDBCF3" This is a cryptographically signed message in MIME format. --------------ms5A69A9209B0A2DAD24DDBCF3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Kent wrote: > Actually, the "local" CA issues a cross cert to the "foreign" CA, and > thus the local CA asserts in the name constraints extension the part > of the portion of the name space for which it considers the foreign > CA to be authoritative. So, the foreign CA does not make the claim > in terms of the name constraints. But you are right in asserting > that some OOB mechanism is used by the local CA to decide what set of > name constraints are appropriate re the foreign CA. Naming constraints in cross-certificates hadn't even begun to occur to me. I seem to have missed the actual point. Again. :-( My reasoning was along the line that it would not only be polite of a Certification Authority to clearly define the limits of its intended certification, both generally as in its Certification Practise Statement and specifically as in its naming constraints, but would also, IMHO, make the decision of the relying party to trust that CA less "critical". I can't really see the current on/off trust mechanisms usually employed as one that even attempts to approximate reality. There are completely different levels of trust involved between, as an example, allowing somone to fix your car and allowing someone to baby-sit (sp?) your children. Even if the level of trust were the same, the level of authority would differ. One would not necessarily expect one person to be suitable to perform both roles, trusted or not. Note to self: or am I just not a very trusting person? //oscar --------------ms5A69A9209B0A2DAD24DDBCF3 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjA5MTYwMzI2 WjAjBgkqhkiG9w0BCQQxFgQUIVc8JbpF4FVCT5aNuE8pWq2S/WYwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCDO4S9a64bMEP95NkoxEVv/fIY7HBb iSBplpG9TA4EjEdLJBn+LiXHQgOfYMeJzYy819gxs2E5pZRZxVLi0/C3d2/eXg7+2MNZKaUD ZVA2VtrMU/3WLbojcgwZAng1juZZwLKs/XYXgBfS7MUMMkskFbO5xo+IRA9MlX6FwYipJQ== --------------ms5A69A9209B0A2DAD24DDBCF3-- Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA27325 for ; Fri, 9 Jun 2000 08:50:46 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 09 Jun 2000 09:26:41 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 09 Jun 2000 09:26:30 -0600 From: "Bob Jueneman" To: , Cc: , Subject: Re: Correct approach to certificate validation? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA27326 Trevor, putting aside for a moment the issue of what the standard says, doesn't say, or ought to say, I'm still not sure that I understand the issue that you are raising. I thought that when you said that you were using the issuer name in a subordinate certificate as a "hint" in finding the correct certificate issuer, you might referring to some kind of fancy heuristic algorithm that would try to divine where the next certificate up the chain might actually be found -- something I would very much like to see. But if Al's example is a correct presentation of what you are saying, then I don't understand how or why the CA created the certificate in that manner in the first place. I have a reasonable fertile imagination, and so I can imagine situations where the issuer name might not match, deliberately -- for example a merger or company name change, where the CA certificate is reissued with the new name, but all of the end-user certs haven't been rolled over yet. (Why the old certificate with the old name would have been left in place escapes me, however.) I tend to agree with the rest of the community -- if this is just the result of sloppy programming of the CA implementation in not enforcing reasonable behavior when the certificates were created, then this is indefensible. However, if you have a real reason or justification, I'd like to hear it. It does disturb me just a little to be over-constraining the chaining relationship. If name subordination really matters, then a constraint ought to be expressed. If name subordination doesn't matter, then I suppose I could question why the reverse chaining issue is important, assuming the path can still be constructed somehow. One example that might be interesting to consider would be a bilingual country such as Canada, where the CA's certificate might be in English, and yet the end-user's certificate might be in French, including the French version of the issuer's name. Other multilingual examples might include certificates where the CA's DN is written in one character set, and for reasons of national pride, local laws, custom, or merely comprehensibility by the consumer, the subject and issuer name are written in a different character set. Generally speaking, accepted standards ought to be followed, unless there are good reasons not to (not including programming bugs).. If there is such a good reason, the standards ought to be revised. I'm trying to understand where there is in fact a good reason. Bob << 06/08/00 08:31PM >>> Trevor, Here's the justification: Suppose that a CA system (by, e.g., Netscape, Entrust, VeriSign, whomever) has been built to conform to existing/understood X.509/RFC2459 name chaining rules. Suppose that such a system has been deployed for, oh, say, a large Government department, or a large corporation, or... Now, suppose that a CA from some other corporation that follows the rules you suggest - i.e., name chaining doesn't matter. We want to integrate that CA into the existing PKI. Now, for whatever reason - human frailty, whatever - that new CA is used to create a certificate whose distinguish name is "C=AW, O=Government, OU= Computers, CN= CA1", and then that CA creates user certs where the issuer name is "C=AW, O=Government, OU=Computer, CN=CA1". Note that these names are not equivalent.* Suppose that all other information - AKI, AIA, etc. - is set up properly. Now, whenever a cert path is validated using the new CA, it will be validated, because the fact that the end entity cert's issuer name and the CA cert's subject name aren't the same doesn't matter. However, whenever that same cert path is validated by a node in the existing PKI, validation will fail, because of the name chaining failure. The notion of obtaining different results by different points in the system is disconcerting, to say the least. That's the reason: by building your system this way, you cause the multi-vendor interoperable PKI to fail. If you were building your system to not interoperate with any other existing products, then I think we could probably agree that you were right; there is no real reason that names have to chain. However, lots of people do want your system to interoperate with other products. I'm fairly confident that Dave wants them to. I know that in some of the cases I'm dealing with now, I need them to. And they don't. Al Arsenault Chief Security Architect Diversinet Corp. *And yes, I have seen cases where name chaining failed - and thus certificate validation failed when it shouldn't have - because of a misplaced comma in a CN field. I've also seen it fail because of an extra space in an OU field, and several other situations. > Trevor Freeman wrote: > > Life is complicated, but this is not so bad - Isaac Newton's rules > where around a lot longer before they were found to be wrong. > I am still waiting to here further justification (beyond the old > ground of "its in the spec"). and so far you are confirming my > suspicions that there are none. > > -----Original Message----- > From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > Sent: Thursday, June 08, 2000 8:35 AM > To: ietf-pkix@imc.org > Subject: RE: Correct approach to certificate validation? > > Trevor, > > > From: "Trevor Freeman" > > > > David, > > Interoperability is a primary goal, however that is often scarified > by > > standards. It is very easy to produce a document with a set of do's > and > > don'ts without any regard for the previous standard, the impact on > the > > deployed products or how migration is achieved between the old and > new > > standard. It is also unrealistic to think that all products deployed > > would conform to a single standard. Most products have a lifetime of > > years. The interoperability matrix is vast and getting worse every > time > > a new version of a standard is released. > > So to return to the original point, besides citing a 20 year old > clause > > in a standard, and saying we should do it because its in the > standard, > > and requiring administrators to have a faultless record, I have > still > > not hear any reasoned, argument as to what is actually achieved by > this > > behavior. > > No standard or clause in a standard has a divine right of existence. > > Trevor > > On the one hand, you seem to be decrying the ease of producing new > specifications without regard for previous standards and deployed > products. > > On the other, you seem to support discarding a 20 year old clause > in a standard without regard for its impact on deployed products which > have been built according to the standard. > > The "divine right" of any clause comes not from heaven or inheritance, > but from the fact that it has been vetted internationally (in the ISO > and the IETF) over a period of many years. Over that time (whether > it's > 12 or 20 years is immaterial), the requirement that certificates point > to the correct issuer has not only survived, it has not to my > knowledge > been even mildly controversial. Now that there is discussion of > the topic, the requirement will either survive or be discarded based > on international consensus. There is no divine right, just the > stability (inertia?) of a consensus-based standard-setting > process. > > You may present a case that the requirement should be removed from > X.509 > and then from the PKIX profile of X.509. > Or you may choose not to comply with X.509. > > But you can't both ignore the requirement and claim compliance. > > > Certificate discovery is not the issue here. > > > > For certificate discovery, we have a domain push mechanism as well > as > > AIA. We are also adding a lookup by name, and a configurable URL > search > > path i.e. a set of URLs to search (LDAP, HTTP, FTP) > > Certificate discovery *is* the issue. > > If you are adding a "lookup by name" function to your products, > how will that work if certificates do not have correct issuer > names? If I have someone's End Entity certificate, how do I find a > path of CA certs that leads to my trust point (not necessarily the > certificate subject's trust point), in the multi-vendor, > multi-administrative-domain environment of the Internet. > > Products may support many certificate discovery mechanisms, both > standards-based and differentiating. But there needs to be at > least one "Internet" interoperability mode which all products > support. That mode is defined by PKIX: the certificate profile > and the LDAP schema. > > One "Internet mode" mechanism which follows the current PKIX > specifications is for organizations to place public information, > including CA and EE certificates, in border directories, and to link > the border directories together using directory-to-directory chaining, > LDAP referrals, or both. If you propose to eliminate the X.509 > requirement for correct issuer names, you will need to address the > impact on current applications built to the current standards, > as well as the feasability of future applications built to an > amended standard. > > Dave > > P.S. I don't understand why you keep referring to "punishing > administrators" and "requiring administrators to have a flawless > record" and "eliminating imperfection". A CA workstation has its own > signing key and certificate. If the workstation cannot correctly > place > its own name in the issuer field of every certificate it signs, that > is > a product flaw. This X.509 requirement does not hinge upon human > perfectability. Received: from crack.x509.com (root@crack.x509.com [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26920 for ; Fri, 9 Jun 2000 08:47:01 -0700 (PDT) Received: from xcert.com (home.x509.com [199.175.150.4]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e59FtUV16227 for ; Fri, 9 Jun 2000 08:55:31 -0700 (PDT) Message-ID: <394113ED.D38CD417@xcert.com> Date: Fri, 09 Jun 2000 11:57:33 -0400 From: Michael Young Organization: Xcert International X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: remove Content-Type: multipart/mixed; boundary="------------D27A8B7D42B16DA9DC4CB9B3" This is a multi-part message in MIME format. --------------D27A8B7D42B16DA9DC4CB9B3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit remove --------------D27A8B7D42B16DA9DC4CB9B3 Content-Type: text/x-vcard; charset=us-ascii; name="myoung.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Michael Young Content-Disposition: attachment; filename="myoung.vcf" begin:vcard n:Young;Michael tel;cell:1-914-572-2803 tel;work:1-203-969-2387 x-mozilla-html:FALSE url:http://www.xcert.com org:Xcert International Inc. adr:;;463-3 Cove Road;Stamford;Connecticut;06902;USA version:2.1 email;internet:myoung@xcert.com title:Sales Engineer note:No notes at this time. fn:Michael Young end:vcard --------------D27A8B7D42B16DA9DC4CB9B3-- Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24327 for ; Fri, 9 Jun 2000 08:26:58 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA07428; Fri, 9 Jun 2000 11:35:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39410C15.4A2EECDF@celocom.com> References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <3940DF3A.7D592D88@celocom.com> <394102D9.AF41B95A@celocom.com> <39410C15.4A2EECDF@celocom.com> Date: Fri, 9 Jun 2000 11:36:43 -0400 To: Oscar Jacobsson From: Stephen Kent Subject: Re: Correct approach to certificate validation? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Oscar, >Oscar Jacobsson wrote: > > Besides, the notion of "authoritative CA" becomes a bit vague without > > some in-band method of communicating precisely what said CA claims to be > > an authority on. > >Oh dear. > >I'm still not entirely lucid, I guess. What I was referring to, which >might not have been perfectly obvious, was the role of naming >constraints in defining exactly which Authority a given CA is claiming. Actually, the "local" CA issues a cross cert to the "foreign" CA, and thus the local CA asserts in the name constraints extension the part of the portion of the name space for which it considers the foreign CA to be authoritative. So, the foreign CA does not make the claim in terms of the name constraints. But you are right in asserting that some OOB mechanism is used by the local CA to decide what set of name constraints are appropriate re the foreign CA. Steve Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22863 for ; Fri, 9 Jun 2000 08:16:18 -0700 (PDT) Received: by ns.celocom.se; id RAA22777; Fri, 9 Jun 2000 17:24:47 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma022692; Fri, 9 Jun 00 17:24:07 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id RAA29711; Fri, 9 Jun 2000 17:26:42 +0200 Message-ID: <39410C15.4A2EECDF@celocom.com> Date: Fri, 09 Jun 2000 17:24:05 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent , ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <3940DF3A.7D592D88@celocom.com> <394102D9.AF41B95A@celocom.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB956762982A67F23934ADFD8" This is a cryptographically signed message in MIME format. --------------msB956762982A67F23934ADFD8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oscar Jacobsson wrote: > Besides, the notion of "authoritative CA" becomes a bit vague without > some in-band method of communicating precisely what said CA claims to be > an authority on. Oh dear. I'm still not entirely lucid, I guess. What I was referring to, which might not have been perfectly obvious, was the role of naming constraints in defining exactly which Authority a given CA is claiming. //oscar --------------msB956762982A67F23934ADFD8 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjA5MTUyNDA3 WjAjBgkqhkiG9w0BCQQxFgQUc4D9ZGb4uwyauw1b0aKtP+aeoi4wUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYABQy5KFUq1j9da9TKJD3l9tmZwNXiu 42cYr3+NQg+CR7KcqbmTG64gqypWFTfKCNIeJhVqm1kOxogffHLS43OhcVtC5+EXWABw7xdk sHyWCimKcNryg6mdHjGN+C2SNm/d6g6Knbdw1kjoMZh6EVxKVaoDk4OEHCxF+YekDbQkCg== --------------msB956762982A67F23934ADFD8-- Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20114 for ; Fri, 9 Jun 2000 07:36:17 -0700 (PDT) Received: by ns.celocom.se; id QAA21043; Fri, 9 Jun 2000 16:44:47 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma021032; Fri, 9 Jun 00 16:44:42 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id QAA28666; Fri, 9 Jun 2000 16:47:17 +0200 Message-ID: <394102D9.AF41B95A@celocom.com> Date: Fri, 09 Jun 2000 16:44:41 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <3940DF3A.7D592D88@celocom.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5ECF4F507BB3224147ED10B9" This is a cryptographically signed message in MIME format. --------------ms5ECF4F507BB3224147ED10B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Kent wrote: > I prefer this phrasing because it emphasizes the difference between TTPs where one has to trust the CA, vs. various types of authoritative CAs, where the trust is implicit. A very good point. Besides, the notion of "authoritative CA" becomes a bit vague without some in-band method of communicating precisely what said CA claims to be an authority on. //oscar --------------ms5ECF4F507BB3224147ED10B9 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjA5MTQ0NDQy WjAjBgkqhkiG9w0BCQQxFgQU3I8NRe1o1AgzEtgvUgGDy2Cb8pgwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB12GSJwBCmmToMdUufDO68VE+KOD0Y V/zyjqSQ0i4zon8muysmluU1MeEBtTplBq2XYXkJz8cNeDedPjQD5FEFsi8qVJlRyMZzY3Fs /47PChSoPmI+/AoYH1LhTAgHhd9rL8x7/Stsc5z5w+ExJxKU420Aa27XKSXjiLNo/m2+xg== --------------ms5ECF4F507BB3224147ED10B9-- Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19002 for ; Fri, 9 Jun 2000 07:22:26 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQisvq08638; Fri, 9 Jun 2000 14:30:56 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA23110; Fri, 9 Jun 00 10:27:20 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA26228; Fri, 9 Jun 2000 10:30:54 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14656.65438.308754.800587@xedia.com> Date: Fri, 9 Jun 2000 10:30:54 -0400 (EDT) To: trevorf@Exchange.Microsoft.com Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid >>>>> "Trevor" == Trevor Freeman writes: Trevor> Life is complicated, but this is not so bad - Isaac Newton's Trevor> rules where around a lot longer before they were found to be Trevor> wrong. I am still waiting to here further justification Trevor> (beyond the old ground of "its in the spec"). and so far you Trevor> are confirming my suspicions that there are none. That's interesting. It sounds to me like you're saying "Nothing in any standard matters unless someone can come up with a specific justification for each and every rule I've chosen to ignore". That's comical. In standardization, it often occurs that there are several incompatible ways of doing something, and one has to be chosen. And it may well be that several of the alternatives are equally valid technically. In that case, when one is picked, you have to use that one to interoperate, and the only justification for that one rather than one of the alternatives is indeed "it's in the spec". So are you now claiming that such a standards process is not acceptable? Bizarre. Incidentally, your statement about Newton is incorrect, too. paul Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17839 for ; Fri, 9 Jun 2000 07:07:08 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA23965; Fri, 9 Jun 2000 10:15:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3940DF3A.7D592D88@celocom.com> References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> <3940DF3A.7D592D88@celocom.com> Date: Fri, 9 Jun 2000 10:09:37 -0400 To: Oscar Jacobsson From: Stephen Kent Subject: Re: Correct approach to certificate validation? Cc: ietf-pkix@imc.org Content-Type: multipart/alternative; boundary="============_-1251562280==_ma============" --============_-1251562280==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Oscar, > > >To try to summarize: > >Constraining one's intended certification is essential, since it will >allow for a much finer granularity in the delegation of trust than the >current model with it's childish boolean trusted/not trusted mechanism. Another way to state this is that use of name constraints allows one to recognize the authority of a CA for a portion of a name space, e.g., a company CA is responsible for issuing certs to employees, a university to faculty, staff and students, etc. I prefer this phrasing because it emphasizes the difference between TTPs where one has to trust the CA, vs. various types of authoritative CAs, where the trust is implicit. Steve --============_-1251562280==_ma============ Content-Type: text/enriched; charset="us-ascii" Oscar, < To try to summarize: Constraining one's intended certification is essential, since it will allow for a much finer granularity in the delegation of trust than the current model with it's childish boolean trusted/not trusted mechanism. Another way to state this is that use of name constraints allows one to recognize the authority of a CA for a portion of a name space, e.g., a company CA is responsible for issuing certs to employees, a university to faculty, staff and students, etc. I prefer this phrasing because it emphasizes the difference between TTPs where one has to trust the CA, vs. various types of authoritative CAs, where the trust is implicit. Steve --============_-1251562280==_ma============-- Received: from corp.tivoli.com (corp.tivoli.com [216.140.178.60]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16961 for ; Fri, 9 Jun 2000 06:56:09 -0700 (PDT) From: Edward_Dobner@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id JAA16472 for ; Fri, 9 Jun 2000 09:04:39 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568F9.004DA21E ; Fri, 9 Jun 2000 09:07:57 -0500 X-Lotus-FromDomain: TIVOLI SYSTEMS To: ietf-pkix@imc.org Message-ID: <862568F9.004DA193.00@tivmta4.tivoli.com> Date: Fri, 9 Jun 2000 09:56:39 -0400 Subject: March 10, 2000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In section 6.3.3 and the third paragraph from the end of that section. "If all CRLs named in the crl distribution points extension have been exhausted, and the reasons_mask is not "all-reasons" and the cert_status is still UNREVOKED, the verifier must obtain addi- tional CRLs. If the " Is more intended to be here or should the "If the" be removed? Edward J. Dobner Network Security Products Address: IBM; 3039 Cornwallis Drive; NGEA/B502; Research Triangle Park, NC 27709 Telephone: 919-254-4169 (T/L 444-4169) Email: edward.dobner@tivoli.com VM: edobner@tivoli.com Lotus Notes: Edward Dobner/Tivoli Systems@Tivoli Systems Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16205 for ; Fri, 9 Jun 2000 06:47:00 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA20681; Fri, 9 Jun 2000 09:55:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39405E88.13BADEF8@nma.com> References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> Date: Fri, 9 Jun 2000 09:48:17 -0400 To: Ed Gerck From: Stephen Kent Subject: Re: Correct approach to certificate validation? Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Ed, >List: > >Why should we continue to confuse name validation with >certificate validation? Name chaining should be optional IMO, >not expected behavior. 'Be liberal in what you expect' can be >applied here without A N Y decrease in cryptographic >authentication security. > Jon's protocol design advice is good in general, but inappropriate in security contexts, where liberal acceptance policies often lead to vulnerabilities. Steve Received: from mars.syndata.com ([208.195.248.153]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15528 for ; Fri, 9 Jun 2000 06:40:17 -0700 (PDT) Received: from syndata.com (CHICKENMAN5 [10.50.1.196]) by mars.syndata.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MQ74GN95; Fri, 9 Jun 2000 09:48:39 -0400 Message-ID: <3940F5D5.6A20878F@syndata.com> Date: Fri, 09 Jun 2000 09:49:09 -0400 From: "Carol A. McNab" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: unsubscribe Content-Type: multipart/mixed; boundary="------------1B086A00A26C151F0CF07A10" This is a multi-part message in MIME format. --------------1B086A00A26C151F0CF07A10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe --------------1B086A00A26C151F0CF07A10 Content-Type: text/x-vcard; charset=us-ascii; name="cmcnab.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Carol A. McNab Content-Disposition: attachment; filename="cmcnab.vcf" begin:vcard n:McNab;Carol A. tel;work:(201)836-6200 x1147 x-mozilla-html:TRUE org:Syndata Technologies, Inc. adr:;;500 Frank W. Burr Blvd.;Teaneck;NJ;07666; version:2.1 email;internet:cmcnab@syndata.com title:Senior Software Engineer x-mozilla-cpt:;15600 fn:Carol A. McNab end:vcard --------------1B086A00A26C151F0CF07A10-- Received: from corp.tivoli.com (corp.tivoli.com [216.140.178.60]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14919 for ; Fri, 9 Jun 2000 06:33:11 -0700 (PDT) From: Edward_Dobner@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id IAA10300 for ; Fri, 9 Jun 2000 08:41:39 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568F9.004B84DD ; Fri, 9 Jun 2000 08:44:52 -0500 X-Lotus-FromDomain: TIVOLI SYSTEMS To: ietf-pkix@imc.org Message-ID: <862568F9.004B82D2.00@tivmta4.tivoli.com> Date: Fri, 9 Jun 2000 09:33:30 -0400 Subject: of March 10, 2000 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline I have a question. In section 6.3.3 CRL Processing, is the following text " (d) Perform the checks in step 1 (b) and (c): 1. obtain and validate the certification path for the delta issuer 2. validate the signature on the delta CRL" I am assuming that steps 1 and 2 here are summarising what steps 1(b) and 1(c) are. But step 1 is not step 1(b) and step 2 is not step 1(c). Should this be "perform the checks in step 1 (b), (c) and (d)" or something else. I am working on the review of the java.cert.CertPath apis that are being defined. I work on IBM tools and API's that incorporate PKI technology in IBM products. Edward J. Dobner Network Security Products Address: IBM; 3039 Cornwallis Drive; NGEA/B502; Research Triangle Park, NC 27709 Telephone: 919-254-4169 (T/L 444-4169) Email: edward.dobner@tivoli.com VM: edobner@tivoli.com Lotus Notes: Edward Dobner/Tivoli Systems@Tivoli Systems Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14302 for ; Fri, 9 Jun 2000 06:26:07 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA13009 for ; Fri, 9 Jun 2000 09:27:12 -0400 (EDT) Message-Id: <200006091327.JAA13004@roadblock.missi.ncsc.mil> Date: Fri, 9 Jun 2000 09:32:00 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Correct approach to certificate validation? To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: v/aXcAcK82QGq+2aKGRB0Q== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Peter, No, I didn't realize that RFC 2459's name matching process is a subset of X.509's. What I read is: (a) Verify the basic certificate information, including: ... (4) the subject and issuer names chain correctly (that is, the issuer of this certificate was the subject of the previous certificate.) Although I could understand the motivation for PKIX profiling a binary match (identical RDN tags and values - much simpler to implement than forming equivalence classes for all possible values of DirectoryString), I don't see that PKIX has, in fact, required exact comparison. >From reading requirement (4), I would assume that "X.509 name matching" is permitted by RFC 2459. What I object to, and what I am assuming Trevor is referring to, are name chaining failures that would be failures under even the most liberal and complex string matching rules. The extent to which applications handle equivalent but not identical names is an implementation detail, best handled by the "be conservative in what you generate" rule - CA's should create certificates with binary-exact chaining, and applications should do as much string matching as the developer feels is appropriate for the targeted certificate profiles. Dave > From: Peter Williams > Subject: RE: Correct approach to certificate validation? > To: "'David P. Kemp'" > Cc: ietf-pkix@imc.org > > Dave, > > I agree that (1), (2) and (3) are true assertions. Perhaps you > could be as clear for me...for the PKIX profile of X.509: > > Do you realize, and agree, that > the way NIST/NSA designers deliberately constructed > RFC 2459's name matching process (during > path validation of an intermediate or > EE certificate) is such that implementations > of the X.509 path processing algorithm produce a different > validity result to the PKIX algorithm. > > To keep your schema, I would suggest that it is not enough to > ask Q1. In fact, one can be easily deceived by considering > only Q1. You must ask the PKIX-specific version of Q1, > and then consider the ramifications on testable > X.509 conformance. (Q3 seems irrelevant.) > > Q1 refers to the rule: > > "10.5 Certificate processing > ... > > The following checks are applied to a certificate: > a) Check that the signature verifies, that dates are valid, that > the certificate subject and certificate issuer names chain correctly, and > that the certificate has not been revoked." > > PKIX Q1 refers to a particular definition of what > chaining names "correctly" is. And the 2459 definition > of name matching in *PKIX-conforming* systems is not compatible > with systems tested/certified to be conforming to the X509 standard, by > specific intent of the NIST/NSA authors, evidently. > > As Trevor said, its all a big mess that requires practical > treatment, not religious dogma, in today's products > that are "based on RFC 2459". The list will no doubt > diverge here between the paper-architects and product > builders. > > Why we cannot just implement X.509 name matching defeats me. > > Peter. Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10534 for ; Fri, 9 Jun 2000 05:04:18 -0700 (PDT) Received: by ns.celocom.se; id OAA11579; Fri, 9 Jun 2000 14:12:47 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma011577; Fri, 9 Jun 00 14:12:43 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id OAA24569 for ; Fri, 9 Jun 2000 14:15:18 +0200 Message-ID: <3940DF3A.7D592D88@celocom.com> Date: Fri, 09 Jun 2000 14:12:42 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> <3940B8BB.8ACAE8AC@celocom.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBE97078F8A0220D47D35FEB4" This is a cryptographically signed message in MIME format. --------------msBE97078F8A0220D47D35FEB4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Ed Gerck wrote: > > 'Be liberal in what you expect' can be > > applied here without A N Y decrease in cryptographic > > authentication security. I wasn't particularly lucid in my earlier response, so feel I should probably try again. A few nights' worth of heavy drinking works all but wonders on one's faculties for reason. Being liberal should certainly remain an option, since potential customers will no doubt continue to insist that one's applications be interoperable with broken, or non-conformant if you prefer that term, Public Key Infrastructures and their components. I feel that name constraints are a valuable tool for delegating trust to external parties. Rather than my current behavior, which is to trust whomever AOL tells me to trust, I would be much more comfortable using a certificate issued by a local administrator here at Celo. Such a certificate would, hopefully, hold more worth to the recipient than merely the ability to send me encrypted e-mail, by virtue of being issued by my employer, who should be able to vouch for my identity with a reasonably high degree of certainty. Rather than expecting all recipients to blindly trust the Celo-local issuer for any and all extents, which I personally consider rather rude, an rfc822Name constraint could be included in order to inform the relying party that this issuer intends to issue certificates to Celo employees exclusively, thus requiring far less blind faith from the relying party. To try to summarize: Constraining one's intended certification is essential, since it will allow for a much finer granularity in the delegation of trust than the current model with it's childish boolean trusted/not trusted mechanism. //oscar --------------msBE97078F8A0220D47D35FEB4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjA5MTIxMjQz WjAjBgkqhkiG9w0BCQQxFgQUAOTCTNzPzvdocJlvcGPW6LtqhdYwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBD0RG19HJib1z38jtVk4OJClCpnpDZ YJ3F2hTgUwl/VWkH4EOhByRFASATzd+nOvjCDMjDbhCRHUmvDirfUyphG5r8LLgLw2QSp9Af RqvPx95bJpyNXs/2fhy6c7CR11Esk+lxKMf/y4YKKinM/UUNLaMHZAYjyLl5mlVC5jrK/Q== --------------msBE97078F8A0220D47D35FEB4-- Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10369 for ; Fri, 9 Jun 2000 05:02:45 -0700 (PDT) Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id NAA21814; Fri, 9 Jun 2000 13:57:23 +0200 From: Sender: "denis bider" To: "'Grant, Alistair'" , "'Trevor Freeman'" Cc: Subject: RE: Correct approach to certificate validation? Date: Fri, 9 Jun 2000 14:05:08 +0200 Message-ID: <000501bfd20a$f5474da0$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 > Inconsistent behaviour amongst various components of a system simply > makes tracking down a problem more difficult, as I expect Denis Bider > can attest to. Grant is correct on this issue. As a user/developer, I would have preferred IE5 and Outlook to use the same validation scheme as is used in other products out there. (Simple example: if IE5/Outlook2000 did use the same validation technique as the rest of the world, I would not have been misled into thinking that the problem is at the IIS side, and, hence, would not have spent tens of hours trying to find the problem where it did not exist. Of course, it was my mistake that caused certificate names not to chain, and nor IE5 nor IIS can be blamed for any of this. Essentially, the fault was mine entirely. But still, where IE's behavior could be helpful, it was misleading. Personally, I would have preferred it to be helpful.) Regards, denis Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29361 for ; Fri, 9 Jun 2000 02:20:27 -0700 (PDT) Received: by ns.celocom.se; id LAA03583; Fri, 9 Jun 2000 11:28:46 +0200 (CEST) Received: from zap.celocom.se(10.10.10.1) by ns.celocom.se via smap (4.1) id xma003529; Fri, 9 Jun 00 11:28:30 +0200 Received: from celocom.com (dhcp121.celocom.se [10.10.11.21]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id LAA20395 for ; Fri, 9 Jun 2000 11:31:03 +0200 Message-ID: <3940B8BB.8ACAE8AC@celocom.com> Date: Fri, 09 Jun 2000 11:28:27 +0200 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> <39405E88.13BADEF8@nma.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms828A2011C597B02E3D4CF8A6" This is a cryptographically signed message in MIME format. --------------ms828A2011C597B02E3D4CF8A6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ed Gerck wrote: > Why should we continue to confuse name validation with > certificate validation? Name chaining should be optional IMO, > not expected behavior. 'Be liberal in what you expect' can be > applied here without A N Y decrease in cryptographic > authentication security. My personal opinion, and humble one at that, is that the issue is of greater importance than "simply" one of cryptographic security. The principals of X.509, as has been previously stated in this thread, are in the naming, and not in the cryptographic keys themselves. The value of authentication, again IMHO, is in the degree of trust which the Relying Party can hold as to the identity of the certificate subject presented and not in the relative merits of the length and/or algorithm employed for the cryptographic key. My two crowns worth, anyway. Cheers! //oscar --------------ms828A2011C597B02E3D4CF8A6 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIH/gYJKoZIhvcNAQcCoIIH7zCCB+sCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bc8wggKzMIICHKADAgECAgMCjYUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDUxMzAwMDEzOVoXDTAxMDUxMzAwMDEz OVowTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYb b3NjYXIuamFjb2Jzc29uQGNlbG9jb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQCZB2URw+NGaMMV/cSk9JoOb4OGMunL44lk/ioXoBR5brSVUcVaB+s+8UmcqOmi9RAAc+Uy wY69hjPn/LWS3HzN4N4KW6jTEiDm0jPE1aVyxMg7un4rjRSGe9htdPL0ut8QoKXLCjafLKIo v/pyudWgC1PxSglWECgKyKVVMl13KwIDAQABo1kwVzAmBgNVHREEHzAdgRtvc2Nhci5qYWNv YnNzb25AY2Vsb2NvbS5jb20wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBSIq/Fgg2ZV9ORY x0YdwGG9I9fDjDANBgkqhkiG9w0BAQQFAAOBgQB8NkKsoEJaIAfecEv+NJp6bBs3xM+ynX5F qJ/ave0p7v2eBBO/fovRoMsmFjF0jHf4RFJqxm9NrpoZWlhehM5nOdS0AyPwFIMEWl7PdSxO pKkxGS8wgEsVammWQc8MAwULu4qy8SdL9LnszsvEKtrsJFG+bILsOf1qBkC6UuSR4DCCAxQw ggJ9oAMCAQICAQswDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29u YWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05OTA5MTYxNDAxNDBaFw0wMTA5MTUxNDAxNDBa MIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJi YW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNjCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAs2lal9TQFgt6tcVd6SGcI3LNEkxL937Px/vKciT0QlKsV5Xj e2F6F4Tn/XI5OJS06u1lp5IGXr3gZfYZu5R5dkw+uWhwdYQc9BF0ALwFLE8JAxcxzPRB1HLG pl3iiESwiy7ETfHw1oU+bPOVlHiRfkDpnNGNFVeOwnPlMN5G9U8CAwEAAaM3MDUwEgYDVR0T AQH/BAgwBgEB/wIBADAfBgNVHSMEGDAWgBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG 9w0BAQQFAAOBgQBrxlnpMfrptuyxA9jfcnL+kWBI6sZV3XvwZ47GYXDnbcKlN9idtxcoVgWL 3Vx1b8aRkMZsZnET0BB8a5FvhuAhNi3B1+qyCa3PLW3Gg1Kb+7v+nIed/LfpdJLkXJeu/H6s yg1vcnpnLGtz9Yb5nfUAbvQdB86dnoJjKe+TCX5V3jGCAfcwggHzAgEBMIGcMIGUMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5OTkuOS4xNgIDAo2FMAkGBSsOAwIaBQCggbEw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwNjA5MDkyODI5 WjAjBgkqhkiG9w0BCQQxFgQUC9AvFfffQuA0UniiUEHZ4mYQveUwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB9hNisgOy8iF1UzMuCfpZzhojE2Ooh Mbu6htNYloq8c278ogmJUMAep7/vnSBGBxoD1iEqrqgInaaubw9ux7WlMi4HeUW03FWsDWDF meKziGn7u2SD137lPMADsoQIVBjm67JU5TN+b0UMFTw1Xe5UCPpMGZCXh6t4VLvaNNTSyA== --------------ms828A2011C597B02E3D4CF8A6-- Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08820 for ; Thu, 8 Jun 2000 20:45:33 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Jun 2000 13:56:40 +1000 Message-ID: From: "Grant, Alistair" To: Trevor Freeman Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Date: Fri, 9 Jun 2000 13:57:51 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Hi Trevor, Trevor Freeman wrote: > To err is human, and people make mistakes. Which is one of the reasons why a certificate may be revoked and re-issued. To add to the list of arguments for following the standard: Inconsistent behaviour amongst various components of a system simply makes tracking down a problem more difficult, as I expect Denis Bider can attest to. I doubt that this change has made the overall system more robust. It seems unlikely that all implementations are going to operate in the same manner. Based on Denis' experience, just taking Microsoft's various systems results in inconsistent behaviour. Cheers, Alistair Grant Project Manager - Development Computer Associates, OpenDirectory Lab Mooroolbark, Victoria, Australia Phone: +61 3 9727 8912 Mobile: +61 408 565 080 Fax: +61 3 9727 3491 E-Mail: Alistair.Grant@ca.com Received: from mail-fwd.verio-web.com ([161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA02778 for ; Thu, 8 Jun 2000 20:01:18 -0700 (PDT) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 03476090; Thu, 8 Jun 2000 23:09:42 -0400 (EDT) Message-ID: <39406032.84762F55@caveosystems.com> Date: Thu, 08 Jun 2000 23:10:42 -0400 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Al Arsenault CC: Trevor Freeman , "David P. Kemp" , ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 Al, You're saying that the current deployed base of CA's ensures that the issuer DN of certs they issue is exactly the same as the subject DN of its own signing cert? If my understanding is correct, not only do I strongly concur, but I don't know of any product that works otherwise, in the course of normal operation/default config. Does anyone know of a product that doesn't? Even if there is one, it doesn't matter. And if the standard is 20 years old, it doesn't matter (heck, TCP's older than that). Generally speaking, "that's what everyone else does" is the kind of argument that, in the IETF, generally trumps anything else. Trevor, I thought you've been around long enough to know this. /r$ Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA01570 for ; Thu, 8 Jun 2000 19:55:17 -0700 (PDT) Received: (qmail 18285 invoked from network); 9 Jun 2000 03:03:37 -0000 Received: from taurus.hosting4u.net (209.15.2.33) by mail-gate.communitech.net with SMTP; 9 Jun 2000 03:03:37 -0000 Received: from nma.com ([63.204.17.82]) by taurus.hosting4u.net ; Thu, 08 Jun 2000 22:03:34 -0500 Message-ID: <39405E88.13BADEF8@nma.com> Date: Thu, 08 Jun 2000 20:03:36 -0700 From: Ed Gerck X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: <39405703.916283C1@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List: Why should we continue to confuse name validation with certificate validation? Name chaining should be optional IMO, not expected behavior. 'Be liberal in what you expect' can be applied here without A N Y decrease in cryptographic authentication security. Cheers, Ed Gerck Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA27271 for ; Thu, 8 Jun 2000 19:25:40 -0700 (PDT) Received: from home.com ([24.180.131.6]) by mail.rdc1.md.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000609023401.QKNA23916.mail.rdc1.md.home.com@home.com>; Thu, 8 Jun 2000 19:34:01 -0700 Message-ID: <39405703.916283C1@home.com> Date: Thu, 08 Jun 2000 22:31:31 -0400 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Trevor Freeman CC: "David P. Kemp" , ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Trevor, Here's the justification: Suppose that a CA system (by, e.g., Netscape, Entrust, VeriSign, whomever) has been built to conform to existing/understood X.509/RFC2459 name chaining rules. Suppose that such a system has been deployed for, oh, say, a large Government department, or a large corporation, or... Now, suppose that a CA from some other corporation that follows the rules you suggest - i.e., name chaining doesn't matter. We want to integrate that CA into the existing PKI. Now, for whatever reason - human frailty, whatever - that new CA is used to create a certificate whose distinguish name is "C=AW, O=Government, OU= Computers, CN= CA1", and then that CA creates user certs where the issuer name is "C=AW, O=Government, OU=Computer, CN=CA1". Note that these names are not equivalent.* Suppose that all other information - AKI, AIA, etc. - is set up properly. Now, whenever a cert path is validated using the new CA, it will be validated, because the fact that the end entity cert's issuer name and the CA cert's subject name aren't the same doesn't matter. However, whenever that same cert path is validated by a node in the existing PKI, validation will fail, because of the name chaining failure. The notion of obtaining different results by different points in the system is disconcerting, to say the least. That's the reason: by building your system this way, you cause the multi-vendor interoperable PKI to fail. If you were building your system to not interoperate with any other existing products, then I think we could probably agree that you were right; there is no real reason that names have to chain. However, lots of people do want your system to interoperate with other products. I'm fairly confident that Dave wants them to. I know that in some of the cases I'm dealing with now, I need them to. And they don't. Al Arsenault Chief Security Architect Diversinet Corp. *And yes, I have seen cases where name chaining failed - and thus certificate validation failed when it shouldn't have - because of a misplaced comma in a CN field. I've also seen it fail because of an extra space in an OU field, and several other situations. > Trevor Freeman wrote: > > Life is complicated, but this is not so bad - Isaac Newton's rules > where around a lot longer before they were found to be wrong. > I am still waiting to here further justification (beyond the old > ground of "its in the spec"). and so far you are confirming my > suspicions that there are none. > > -----Original Message----- > From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > Sent: Thursday, June 08, 2000 8:35 AM > To: ietf-pkix@imc.org > Subject: RE: Correct approach to certificate validation? > > Trevor, > > > From: "Trevor Freeman" > > > > David, > > Interoperability is a primary goal, however that is often scarified > by > > standards. It is very easy to produce a document with a set of do's > and > > don'ts without any regard for the previous standard, the impact on > the > > deployed products or how migration is achieved between the old and > new > > standard. It is also unrealistic to think that all products deployed > > would conform to a single standard. Most products have a lifetime of > > years. The interoperability matrix is vast and getting worse every > time > > a new version of a standard is released. > > So to return to the original point, besides citing a 20 year old > clause > > in a standard, and saying we should do it because its in the > standard, > > and requiring administrators to have a faultless record, I have > still > > not hear any reasoned, argument as to what is actually achieved by > this > > behavior. > > No standard or clause in a standard has a divine right of existence. > > Trevor > > On the one hand, you seem to be decrying the ease of producing new > specifications without regard for previous standards and deployed > products. > > On the other, you seem to support discarding a 20 year old clause > in a standard without regard for its impact on deployed products which > have been built according to the standard. > > The "divine right" of any clause comes not from heaven or inheritance, > but from the fact that it has been vetted internationally (in the ISO > and the IETF) over a period of many years. Over that time (whether > it's > 12 or 20 years is immaterial), the requirement that certificates point > to the correct issuer has not only survived, it has not to my > knowledge > been even mildly controversial. Now that there is discussion of > the topic, the requirement will either survive or be discarded based > on international consensus. There is no divine right, just the > stability (inertia?) of a consensus-based standard-setting > process. > > You may present a case that the requirement should be removed from > X.509 > and then from the PKIX profile of X.509. > Or you may choose not to comply with X.509. > > But you can't both ignore the requirement and claim compliance. > > > Certificate discovery is not the issue here. > > > > For certificate discovery, we have a domain push mechanism as well > as > > AIA. We are also adding a lookup by name, and a configurable URL > search > > path i.e. a set of URLs to search (LDAP, HTTP, FTP) > > Certificate discovery *is* the issue. > > If you are adding a "lookup by name" function to your products, > how will that work if certificates do not have correct issuer > names? If I have someone's End Entity certificate, how do I find a > path of CA certs that leads to my trust point (not necessarily the > certificate subject's trust point), in the multi-vendor, > multi-administrative-domain environment of the Internet. > > Products may support many certificate discovery mechanisms, both > standards-based and differentiating. But there needs to be at > least one "Internet" interoperability mode which all products > support. That mode is defined by PKIX: the certificate profile > and the LDAP schema. > > One "Internet mode" mechanism which follows the current PKIX > specifications is for organizations to place public information, > including CA and EE certificates, in border directories, and to link > the border directories together using directory-to-directory chaining, > LDAP referrals, or both. If you propose to eliminate the X.509 > requirement for correct issuer names, you will need to address the > impact on current applications built to the current standards, > as well as the feasability of future applications built to an > amended standard. > > Dave > > P.S. I don't understand why you keep referring to "punishing > administrators" and "requiring administrators to have a flawless > record" and "eliminating imperfection". A CA workstation has its own > signing key and certificate. If the workstation cannot correctly > place > its own name in the issuer field of every certificate it signs, that > is > a product flaw. This X.509 requirement does not hinge upon human > perfectability. Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA18908 for ; Thu, 8 Jun 2000 18:27:03 -0700 (PDT) Received: from jimsch1t (ip166.du1.bel.nwlink.com [209.20.136.166]) by smtp.nwlink.com (8.9.3/8.9.3) with ESMTP id SAA18616; Thu, 8 Jun 2000 18:35:19 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'David P. Kemp'" , Subject: RE: Correct approach to certificate validation? Date: Thu, 8 Jun 2000 18:35:43 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200006071355.JAA25280@roadblock.missi.ncsc.mil> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 David, My draft has nothing to do with the fact that the name chaining may be incorrect but applies even in the cases where name chaining is present and correct. There are various cases where not going strictly on name chaining can be benifitual. For example, if a company changes names the CA certificate can be updated without having to re-issue all subordiante certificates at the same time. (This may happen due to merges, splits, name changes or court ordered actions.) jim -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Wednesday, June 07, 2000 7:00 AM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, It isn't about punishing administrators for minor errors, it is about achieving an overall system with the goals of being both secure and non-intrusive to the end user. That may well mean that administrators have to do more thinking, planning, and quality control, but that is what they (we, the providers of a PKI for our branch of Govt) are paid to do. The specific case I'm referring to is Jim Schaad's assertion that an S/MIME-specific cert path attribute is needed because applications can't find CA certificates. I didn't realize until now that that was because in your environment subject certificates are not required to have a correct issuer name! It seemed obvious to me that the PKI is responsible for correctly binding names to keys. But you are saying that Issuer names don't really matter, they're just a hint to help applications search for a cert with a signing key that validates the subject cert signature. Well no wonder applications can't find CA certs in that environment! That isn't necessarily a wrong theoretical approach - SPKI is based on the premise that only keys are important, names are simply optional attributes attached to keys. But it is wrong in X.509 because X.509 certificates are identified by and stored under Distinguished Names, not public keys or SubjectKeyIdentifiers. Standards are about interworking in a multi-vendor environment; the testable requirements contained in standards are covenants between supplier and customer. My goal is for a CMI purchased from vendor X and operated by company A to work with applications purchased from vendors Y and Z and operated by companies B and C. I understand that that is not your primary goal, but I expect you to acknowledge that when as a result of non-conformance some applications work and others don't, it is NOT the fault of the conforming applications even when they are the ones that fail. And that when someone from company X proposes as a Standard a workaround for a problem created somewhere else in company X, the IETF is entitled to disregard the company-specific rationale for that workaround. Regards, Dave > From: "Trevor Freeman" > > Hi David, > I am afraid I don't see it necessary to eradicate every little > imperfection because it is there. To err is human, and people make > mistakes. People also have a wide list of requires which you may or may > not agree with, but it does not mean that it is less real to them. > So I don't see this as an error, simple a different point of view, and > we will obviously disagree on this point. > At the end of the day it is up to any product vendor to make the call as > to what is\is not in their product, regardless what is in the standard. > It is up to the market place to decide. History certainly tells us that > customers like robustness in a product. > If you can cite a specific issue, then we will obviously reconsider, but > I don't find punishing minor infractions of administrators a compelling > case. > Trevor Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA13463 for ; Thu, 8 Jun 2000 18:02:27 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 08 Jun 2000 17:29:10 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Thu, 8 Jun 2000 16:02:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD19A.5E79C38C" Subject: RE: Correct approach to certificate validation? Date: Thu, 8 Jun 2000 15:39:12 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/RYJMCXGniSOc7SzajKKMeEOGrKwAOKjCA From: "Trevor Freeman" To: "David P. Kemp" Cc: X-OriginalArrivalTime: 08 Jun 2000 23:02:26.0702 (UTC) FILETIME=[9D31CAE0:01BFD19D] This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD19A.5E79C38C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Life is complicated, but this is not so bad - Isaac Newton's rules where around a lot longer before they were found to be wrong. I am still waiting to here further justification (beyond the old ground of "its in the spec"). and so far you are confirming my suspicions that there are none. -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]=20 Sent: Thursday, June 08, 2000 8:35 AM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, > From: "Trevor Freeman" >=20 > David, > Interoperability is a primary goal, however that is often scarified by > standards. It is very easy to produce a document with a set of do's and > don'ts without any regard for the previous standard, the impact on the > deployed products or how migration is achieved between the old and new > standard. It is also unrealistic to think that all products deployed > would conform to a single standard. Most products have a lifetime of > years. The interoperability matrix is vast and getting worse every time > a new version of a standard is released. > So to return to the original point, besides citing a 20 year old clause > in a standard, and saying we should do it because its in the standard, > and requiring administrators to have a faultless record, I have still > not hear any reasoned, argument as to what is actually achieved by this > behavior. > No standard or clause in a standard has a divine right of existence. > Trevor On the one hand, you seem to be decrying the ease of producing new specifications without regard for previous standards and deployed products. On the other, you seem to support discarding a 20 year old clause in a standard without regard for its impact on deployed products which have been built according to the standard. The "divine right" of any clause comes not from heaven or inheritance, but from the fact that it has been vetted internationally (in the ISO and the IETF) over a period of many years. Over that time (whether it's 12 or 20 years is immaterial), the requirement that certificates point to the correct issuer has not only survived, it has not to my knowledge been even mildly controversial. Now that there is discussion of the topic, the requirement will either survive or be discarded based on international consensus. There is no divine right, just the stability (inertia?) of a consensus-based standard-setting process. You may present a case that the requirement should be removed from X.509 and then from the PKIX profile of X.509. Or you may choose not to comply with X.509. But you can't both ignore the requirement and claim compliance. > Certificate discovery is not the issue here. > > For certificate discovery, we have a domain push mechanism as well as > AIA. We are also adding a lookup by name, and a configurable URL search > path i.e. a set of URLs to search (LDAP, HTTP, FTP) Certificate discovery *is* the issue. If you are adding a "lookup by name" function to your products, how will that work if certificates do not have correct issuer names? If I have someone's End Entity certificate, how do I find a path of CA certs that leads to my trust point (not necessarily the certificate subject's trust point), in the multi-vendor, multi-administrative-domain environment of the Internet. Products may support many certificate discovery mechanisms, both standards-based and differentiating. But there needs to be at least one "Internet" interoperability mode which all products support. That mode is defined by PKIX: the certificate profile and the LDAP schema. One "Internet mode" mechanism which follows the current PKIX specifications is for organizations to place public information, including CA and EE certificates, in border directories, and to link the border directories together using directory-to-directory chaining, LDAP referrals, or both. If you propose to eliminate the X.509 requirement for correct issuer names, you will need to address the impact on current applications built to the current standards, as well as the feasability of future applications built to an amended standard. Dave P.S. I don't understand why you keep referring to "punishing administrators" and "requiring administrators to have a flawless record" and "eliminating imperfection". A CA workstation has its own signing key and certificate. If the workstation cannot correctly place its own name in the issuer field of every certificate it signs, that is a product flaw. This X.509 requirement does not hinge upon human perfectability. ------_=_NextPart_001_01BFD19A.5E79C38C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

Life is complicated, but this is not so bad - Isaac = Newton's rules  where around a lot longer before they were found to = be wrong.
I am still waiting to here further justification (beyond the old ground = of "its in the spec"). and so far you are confirming my = suspicions that there are none.

 -----Original Message-----
From:   David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent:   Thursday, June 08, 2000 8:35 AM
To:     ietf-pkix@imc.org
Subject:        RE: Correct approach = to certificate validation?

Trevor,

> From: "Trevor Freeman" = <trevorf@Exchange.Microsoft.com>
>
> David,
> Interoperability is a primary goal, however that is often scarified = by
> standards. It is very easy to produce a document with a set of do's = and
> don'ts  without any regard for the previous standard, the = impact on the
> deployed products or how migration is achieved between the old and = new
> standard. It is also unrealistic to think that all products = deployed
> would conform to a single standard. Most products have a lifetime = of
> years. The interoperability matrix is vast and getting worse every = time
> a new version of  a standard is released.
> So to return to the original point, besides citing a 20 year old = clause
> in a standard, and saying we should do it because its in the = standard,
> and requiring administrators to have a faultless record, I have = still
> not hear any reasoned, argument as to what is actually achieved by = this
> behavior.
> No standard or clause in a standard has a divine right of = existence.
> Trevor

On the one hand, you seem to be decrying the ease of producing new
specifications without regard for previous standards and deployed
products.

On the other, you seem to support discarding a 20 year old clause
in a standard without regard for its impact on deployed products = which
have been built according to the standard.

The "divine right" of any clause comes not from heaven or = inheritance,
but from the fact that it has been vetted internationally (in the = ISO
and the IETF) over a period of many years.  Over that time (whether = it's
12 or 20 years is immaterial), the requirement that certificates = point
to the correct issuer has not only survived, it has not to my = knowledge
been even mildly controversial.   Now that there is discussion = of
the topic, the requirement will either survive or be discarded based
on international consensus.   There is no divine right, just = the
stability (inertia?) of a consensus-based standard-setting
process.

You may present a case that the requirement should be removed from = X.509
and then from the PKIX profile of X.509.
Or you may choose not to comply with X.509.

But you can't both ignore the requirement and claim compliance.




> Certificate discovery is not the issue here.
>
> For certificate discovery,  we have a domain push mechanism as = well as
> AIA. We are also adding a lookup by name, and a configurable URL = search
> path i.e. a set of URLs to search (LDAP, HTTP, FTP)

Certificate discovery *is* the issue.

If you are adding a "lookup by name" function to your = products,
how will that work if certificates do not have correct issuer
names?  If I have someone's End Entity certificate, how do I find = a
path of CA certs that leads to my trust point (not necessarily the
certificate subject's trust point), in the multi-vendor,
multi-administrative-domain environment of the Internet.

Products may support many certificate discovery mechanisms, both
standards-based and differentiating.  But there needs to be at
least one "Internet" interoperability mode which all = products
support.  That mode is defined by PKIX: the certificate profile
and the LDAP schema.

One "Internet mode" mechanism which follows the current = PKIX
specifications is for organizations to place public information,
including CA and EE certificates, in border directories, and to link
the border directories together using directory-to-directory = chaining,
LDAP referrals, or both.  If you propose to eliminate the X.509
requirement for correct issuer names, you will need to address the
impact on current applications built to the current standards,
as well as the feasability of future applications built to an
amended standard.

Dave


P.S.  I don't understand why you keep referring to = "punishing
administrators" and "requiring administrators to have a = flawless
record" and "eliminating imperfection".  A CA = workstation has its own
signing key and certificate.  If the workstation cannot correctly = place
its own name in the issuer field of every certificate it signs, that = is
a product flaw.  This X.509 requirement does not hinge upon = human
perfectability.

------_=_NextPart_001_01BFD19A.5E79C38C-- Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07273 for ; Thu, 8 Jun 2000 14:44:55 -0700 (PDT) Received: from CONVERSION-DAEMON.ext-mail.valicert.com by ext-mail.valicert.com (PMDF V6.0-24 #45901) id <0FVU00A01VGTDP@ext-mail.valicert.com> for ietf-pkix@imc.org; Thu, 08 Jun 2000 14:53:17 -0700 (PDT) Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V6.0-24 #45901) with ESMTP id <0FVU00A5JVGTA0@ext-mail.valicert.com>; Thu, 08 Jun 2000 14:53:17 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Thu, 08 Jun 2000 14:47:30 -0700 Content-return: allowed Date: Thu, 08 Jun 2000 14:47:27 -0700 From: Peter Williams Subject: RE: Correct approach to certificate validation? To: "'David P. Kemp'" Cc: ietf-pkix@imc.org Message-id: <27FF4FAEA8CDD211B97E00902745CBE235E2D9@seine.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Dave, I agree that (1), (2) and (3) are true assertions. Perhaps you could be as clear for me...for the PKIX profile of X.509: Do you realize, and agree, that the way NIST/NSA designers deliberately constructed RFC 2459's name matching process (during path validation of an intermediate or EE certificate) is such that implementations of the X.509 path processing algorithm produce a different validity result to the PKIX algorithm. To keep your schema, I would suggest that it is not enough to ask Q1. In fact, one can be easily deceived by considering only Q1. You must ask the PKIX-specific version of Q1, and then consider the ramifications on testable X.509 conformance. (Q3 seems irrelevant.) Q1 refers to the rule: "10.5 Certificate processing ... The following checks are applied to a certificate: a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked." PKIX Q1 refers to a particular definition of what chaining names "correctly" is. And the 2459 definition of name matching in *PKIX-conforming* systems is not compatible with systems tested/certified to be conforming to the X509 standard, by specific intent of the NIST/NSA authors, evidently. As Trevor said, its all a big mess that requires practical treatment, not religious dogma, in today's products that are "based on RFC 2459". The list will no doubt diverge here between the paper-architects and product builders. Why we cannot just implement X.509 name matching defeats me. Peter. -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Wednesday, June 07, 2000 2:24 PM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Peter, Do you agree that: 1) path validation requirement "a" of X.509 requires name chaining? 2) if the subject of a certificate is a CA then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field in all certificates issued by the CA (RFC 2459 section 4.2.1.6) 3) A certificate may use a null DN iff the subject/issuer alternative name extension is flagged critical *and* for every name form used in the GeneralName type, there shall be a name registration system that ensures that any name used unambiguously identifies one entity to both certificate issuer and certificate users. (X.509 section 12.3.2.1) Dave Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05017 for ; Thu, 8 Jun 2000 12:16:59 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA13589; Thu, 8 Jun 2000 15:25:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 8 Jun 2000 15:20:47 -0400 To: "Trevor Freeman" From: Stephen Kent Subject: RE: Correct approach to certificate validation? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Trevor, >Certificate discovery is not the issue here. I know that the focus of the discussion has been matching up subject and issuer names when validating a cert path. However, since cert path discovery logically precedes validation, and since the nominal model for discovery is based on looking for a CA cert that contains a subject name that was the issuer name on the "lower" level cert, I think it appropriate to ask the discovery question. >The question is that if you have a certificate who's signature >integrity can be traced up to a trusted root, containing acceptable >policy as defined by that root, and who's names lie within the >allowed namespaces as defined by the name constraints in parent >certificates to the certificate in question, what is the value in >checking that the issuer-subject names chain? >We have encountered such situations, by design, and by accident. In >all cases, the cost\benefit analysis in our view is stacked in favor >of not performing the name chaining check, and tolerating this >situation. Could you provide some examples of the "by design" situations you have encountered? >I agree that name constraints are important as the certificate is >making those names available to the applications, so it is important >that we can filter acceptable from not-acceptable names. We actually >follow a methodology similar to one you mentioned in a previous >thread which is to build all possible paths, then apply the name >constraints to determine the quality of the path. I don't recall suggesting the approach you mention here. I would guess that path discovery performed using subject/issuer name matching and AIK/SIK discrimination would rarely yield multiple paths. But, if it did, then I agree that application of the name constraints extension as part of path validation would discard paths that violated the constraints. >For certificate discovery, we have a domain push mechanism as well >as AIA. We are also adding a lookup by name, and a configurable URL >search path i.e. a set of URLs to search (LDAP, HTTP, FTP) The domain push mechanism sounds local, perhaps MS specific? AIA would be definitive. Does one look at the issuer name to select a subset of the search search paths you allude to, or do you just try to do lookups via ll of them? Steve Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28652 for ; Thu, 8 Jun 2000 09:08:39 -0700 (PDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00DRVF4T39@mta5.rcsntx.swbell.net> for ietf-pkix@imc.org; Thu, 8 Jun 2000 11:06:01 -0500 (CDT) Date: Thu, 08 Jun 2000 11:06:01 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: ietf-pkix@imc.org Message-id: <0FVU00DUOFDZ39@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26247 for ; Thu, 8 Jun 2000 08:29:02 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id LAA15871 for ; Thu, 8 Jun 2000 11:30:08 -0400 (EDT) Message-Id: <200006081530.LAA15867@roadblock.missi.ncsc.mil> Date: Thu, 8 Jun 2000 11:34:52 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Correct approach to certificate validation? To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 066FyQiZQm4F+lXgEhbL+w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Trevor, > From: "Trevor Freeman" > > David, > Interoperability is a primary goal, however that is often scarified by > standards. It is very easy to produce a document with a set of do's and > don'ts without any regard for the previous standard, the impact on the > deployed products or how migration is achieved between the old and new > standard. It is also unrealistic to think that all products deployed > would conform to a single standard. Most products have a lifetime of > years. The interoperability matrix is vast and getting worse every time > a new version of a standard is released. > So to return to the original point, besides citing a 20 year old clause > in a standard, and saying we should do it because its in the standard, > and requiring administrators to have a faultless record, I have still > not hear any reasoned, argument as to what is actually achieved by this > behavior. > No standard or clause in a standard has a divine right of existence. > Trevor On the one hand, you seem to be decrying the ease of producing new specifications without regard for previous standards and deployed products. On the other, you seem to support discarding a 20 year old clause in a standard without regard for its impact on deployed products which have been built according to the standard. The "divine right" of any clause comes not from heaven or inheritance, but from the fact that it has been vetted internationally (in the ISO and the IETF) over a period of many years. Over that time (whether it's 12 or 20 years is immaterial), the requirement that certificates point to the correct issuer has not only survived, it has not to my knowledge been even mildly controversial. Now that there is discussion of the topic, the requirement will either survive or be discarded based on international consensus. There is no divine right, just the stability (inertia?) of a consensus-based standard-setting process. You may present a case that the requirement should be removed from X.509 and then from the PKIX profile of X.509. Or you may choose not to comply with X.509. But you can't both ignore the requirement and claim compliance. > Certificate discovery is not the issue here. > > For certificate discovery, we have a domain push mechanism as well as > AIA. We are also adding a lookup by name, and a configurable URL search > path i.e. a set of URLs to search (LDAP, HTTP, FTP) Certificate discovery *is* the issue. If you are adding a "lookup by name" function to your products, how will that work if certificates do not have correct issuer names? If I have someone's End Entity certificate, how do I find a path of CA certs that leads to my trust point (not necessarily the certificate subject's trust point), in the multi-vendor, multi-administrative-domain environment of the Internet. Products may support many certificate discovery mechanisms, both standards-based and differentiating. But there needs to be at least one "Internet" interoperability mode which all products support. That mode is defined by PKIX: the certificate profile and the LDAP schema. One "Internet mode" mechanism which follows the current PKIX specifications is for organizations to place public information, including CA and EE certificates, in border directories, and to link the border directories together using directory-to-directory chaining, LDAP referrals, or both. If you propose to eliminate the X.509 requirement for correct issuer names, you will need to address the impact on current applications built to the current standards, as well as the feasability of future applications built to an amended standard. Dave P.S. I don't understand why you keep referring to "punishing administrators" and "requiring administrators to have a flawless record" and "eliminating imperfection". A CA workstation has its own signing key and certificate. If the workstation cannot correctly place its own name in the issuer field of every certificate it signs, that is a product flaw. This X.509 requirement does not hinge upon human perfectability. Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA21677 for ; Wed, 7 Jun 2000 17:26:09 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Jun 2000 17:26:14 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Wed, 7 Jun 2000 16:54:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD0DB.C6A84F29" Subject: RE: Correct approach to certificate validation? Date: Wed, 7 Jun 2000 16:54:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/Q0mAlKVrnAUvRSoG9rL6mPiPzkgAAfgNA From: "Trevor Freeman" To: "Stephen Kent" Cc: X-OriginalArrivalTime: 07 Jun 2000 23:54:55.0100 (UTC) FILETIME=[C75F73C0:01BFD0DB] This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD0DB.C6A84F29 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Certificate discovery is not the issue here.=20 The question is that if you have a certificate who's signature integrity can be traced up to a trusted root, containing acceptable policy as defined by that root, and who's names lie within the allowed namespaces as defined by the name constraints in parent certificates to the certificate in question, what is the value in checking that the issuer-subject names chain? We have encountered such situations, by design, and by accident. In all cases, the cost\benefit analysis in our view is stacked in favor of not performing the name chaining check, and tolerating this situation. I agree that name constraints are important as the certificate is making those names available to the applications, so it is important that we can filter acceptable from not-acceptable names. We actually follow a methodology similar to one you mentioned in a previous thread which is to build all possible paths, then apply the name constraints to determine the quality of the path. For certificate discovery, we have a domain push mechanism as well as AIA. We are also adding a lookup by name, and a configurable URL search path i.e. a set of URLs to search (LDAP, HTTP, FTP) Trevor -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Wednesday, June 07, 2000 3:42 PM To: Trevor Freeman Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, Two observations: - path construction (going up toward a root) is nominally=20 based on the use of the issuer name to find the right CA certificate,=20 with the AKI/SKI used to disambiguate among multiple valid CA certs.=20 I recall that the list discussed the potential problems of using just=20 the AKI to locate a CA certificate. I expressed concern then that=20 the AKI didn't provide a means of locating a CA certificate when it=20 was not local, i.e., one would need to have a database that was a=20 flat file for all possible CA certificates to do the lookup. My=20 concern was that we were creating a situation where people might=20 build systems that had all the shortcomings of LAN e-mail systems,=20 e.g., they worked well locally, but did not scale across the=20 Internet. Of course, if one uses the AIA extension this problem might=20 be ameliorated. So, my question is how do MS products locate a CA=20 cert that is not available in a local cache or local LDAP directory,=20 using just the AKI? - name constraints are critical to secure use of certs, so I=20 do hope that you are correctly enforcing this extension, when it is=20 present. Contrary to what Amir said, this is PKIX, not SPKI. We=20 don't buy into the notion that keys are principals here :-). If one=20 always uses name constraints in cross certs that link to other=20 administrative domains, something that a local CA or can enforce=20 unilaterally, then names are reasonably safe to employ for access=20 control purposes. (Of course, one can't do this with TTP, but maybe=20 that's another good reason for not using them when identification for=20 access control is important.) But, if you're violating the standards=20 to accommodate administrative sloppiness in managing CA names for=20 chaining, then maybe you're assuming an environment where one can=20 never rely on names for ACLs anyway. That's a scary environment. Steve ------_=_NextPart_001_01BFD0DB.C6A84F29 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

Certificate discovery is not the issue here.

The question is that if you have a certificate who's signature integrity = can be traced up to a trusted root, containing acceptable policy as = defined by that root, and  who's names lie within the allowed = namespaces as defined by the name constraints in parent certificates to = the certificate in question, what is the value in checking that the = issuer-subject names chain?
We have encountered such situations, by design, and by accident. In all = cases, the cost\benefit analysis in our view is stacked in favor of not = performing the name chaining check, and tolerating this situation.

I agree that name constraints are important as the certificate is making = those names available to the applications, so it is important that we = can filter acceptable from not-acceptable names. We actually follow a = methodology similar to one you mentioned in a previous thread which is = to build all possible paths, then apply the name constraints to = determine the quality of the path.

For certificate discovery,  we have a domain push mechanism as well = as AIA. We are also adding a lookup by name, and a configurable URL = search path i.e. a set of URLs to search (LDAP, HTTP, FTP)

Trevor
 -----Original Message-----
From:   Stephen Kent [mailto:kent@bbn.com]
Sent:   Wednesday, June 07, 2000 3:42 PM
To:     Trevor Freeman
Cc:     ietf-pkix@imc.org
Subject:        RE: Correct approach = to certificate validation?

Trevor,

Two observations:

        - path construction (going up = toward a root) is nominally
based on the use of the issuer name to find the right CA = certificate,
with the AKI/SKI used to disambiguate among multiple valid CA certs.
I recall that the list discussed the potential problems of using = just
the AKI to locate a CA certificate.  I expressed concern then = that
the AKI didn't provide a means of locating a CA certificate when it
was not local, i.e., one would need to have a database that was a
flat file for all possible CA certificates to do the lookup.  = My
concern was that we were creating a situation where people might
build systems that had all the shortcomings of LAN e-mail systems,
e.g., they worked well locally, but did not scale across the
Internet. Of course, if one uses the AIA extension this problem = might
be ameliorated.  So, my question is how do MS products locate a = CA
cert that is not available in a local cache or local LDAP directory,
using just the AKI?

        - name constraints are = critical to secure use of certs, so I
do hope that you are correctly enforcing this extension, when it is
present.  Contrary to what  Amir said, this is PKIX, not = SPKI.  We
don't buy into the notion that keys are principals here :-).  If = one
always uses name constraints in cross certs that link to other
administrative domains, something that a local CA or  can = enforce
unilaterally, then names are reasonably safe to employ for access
control purposes. (Of course, one can't do this with TTP, but maybe
that's another good reason for not using them when identification = for
access control is important.)  But, if you're violating the = standards
to accommodate administrative sloppiness in managing CA names for
chaining, then maybe you're assuming an environment where one can
never rely on names for ACLs anyway. That's a scary environment.

Steve

------_=_NextPart_001_01BFD0DB.C6A84F29-- Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA21198 for ; Wed, 7 Jun 2000 17:10:11 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Jun 2000 17:08:07 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Wed, 7 Jun 2000 16:03:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD0D4.253A6B56" Subject: RE: Correct approach to certificate validation? Date: Wed, 7 Jun 2000 16:00:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/QiWeGxhvxdtQrRjaMEI8dySivbQARqf6g From: "Trevor Freeman" To: "David P. Kemp" Cc: X-OriginalArrivalTime: 07 Jun 2000 23:03:30.0381 (UTC) FILETIME=[98BCAFD0:01BFD0D4] This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD0D4.253A6B56 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, Interoperability is a primary goal, however that is often scarified by standards. It is very easy to produce a document with a set of do's and don'ts without any regard for the previous standard, the impact on the deployed products or how migration is achieved between the old and new standard. It is also unrealistic to think that all products deployed would conform to a single standard. Most products have a lifetime of years. The interoperability matrix is vast and getting worse every time a new version of a standard is released.=20 So to return to the original point, besides citing a 20 year old clause in a standard, and saying we should do it because its in the standard, and requiring administrators to have a faultless record, I have still not hear any reasoned, argument as to what is actually achieved by this behavior. No standard or clause in a standard has a divine right of existence. Trevor -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]=20 Sent: Wednesday, June 07, 2000 7:00 AM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, It isn't about punishing administrators for minor errors, it is about achieving an overall system with the goals of being both secure and non-intrusive to the end user. That may well mean that administrators have to do more thinking, planning, and quality control, but that is what they (we, the providers of a PKI for our branch of Govt) are paid to do. The specific case I'm referring to is Jim Schaad's assertion that an S/MIME-specific cert path attribute is needed because applications can't find CA certificates. I didn't realize until now that that was because in your environment subject certificates are not required to have a correct issuer name! It seemed obvious to me that the PKI is responsible for correctly binding names to keys. But you are saying that Issuer names don't really matter, they're just a hint to help applications search for a cert with a signing key that validates the subject cert signature. Well no wonder applications can't find CA certs in that environment! That isn't necessarily a wrong theoretical approach - SPKI is based on the premise that only keys are important, names are simply optional attributes attached to keys. But it is wrong in X.509 because X.509 certificates are identified by and stored under Distinguished Names, not public keys or SubjectKeyIdentifiers. Standards are about interworking in a multi-vendor environment; the testable requirements contained in standards are covenants between supplier and customer. My goal is for a CMI purchased from vendor X and operated by company A to work with applications purchased from vendors Y and Z and operated by companies B and C. I understand that that is not your primary goal, but I expect you to acknowledge that when as a result of non-conformance some applications work and others don't, it is NOT the fault of the conforming applications even when they are the ones that fail. And that when someone from company X proposes as a Standard a workaround for a problem created somewhere else in company X, the IETF is entitled to disregard the company-specific rationale for that workaround. Regards, Dave > From: "Trevor Freeman" >=20 > Hi David, > I am afraid I don't see it necessary to eradicate every little > imperfection because it is there. To err is human, and people make > mistakes. People also have a wide list of requires which you may or may > not agree with, but it does not mean that it is less real to them. > So I don't see this as an error, simple a different point of view, and > we will obviously disagree on this point. > At the end of the day it is up to any product vendor to make the call as > to what is\is not in their product, regardless what is in the standard. > It is up to the market place to decide. History certainly tells us that > customers like robustness in a product. > If you can cite a specific issue, then we will obviously reconsider, but > I don't find punishing minor infractions of administrators a compelling > case. > Trevor ------_=_NextPart_001_01BFD0D4.253A6B56 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

David,
Interoperability is a primary goal, however that is often scarified by = standards. It is very easy to produce a document with a set of do's and = don'ts  without any regard for the previous standard, the impact on = the deployed products or how migration is achieved between the old and = new standard. It is also unrealistic to think that all products deployed = would conform to a single standard. Most products have a lifetime of = years. The interoperability matrix is vast and getting worse every time = a new version of  a standard is released.
So to return to the original point, besides citing a 20 year old clause = in a standard, and saying we should do it because its in the standard, = and requiring administrators to have a faultless record, I have still = not hear any reasoned, argument as to what is actually achieved by this = behavior.
No standard or clause in a standard has a divine right of existence.
Trevor
 -----Original Message-----
From:   David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent:   Wednesday, June 07, 2000 7:00 AM
To:     ietf-pkix@imc.org
Subject:        RE: Correct approach = to certificate validation?

Trevor,

It isn't about punishing administrators for minor errors, it is
about achieving an overall system with the goals of being both
secure and non-intrusive to the end user.  That may well mean = that
administrators have to do more thinking, planning, and quality = control,
but that is what they (we, the providers of a PKI for our branch of
Govt) are paid to do.

The specific case I'm referring to is Jim Schaad's assertion that an
S/MIME-specific cert path attribute is needed because applications
can't find CA certificates.  I didn't realize until now that that = was
because in your environment subject certificates are not required to
have a correct issuer name!  It seemed obvious to me that the PKI = is
responsible for correctly binding names to keys.  But you are = saying
that Issuer names don't really matter, they're just a hint to help
applications search for a cert with a signing key that validates the
subject cert signature.  Well no wonder applications can't find = CA
certs in that environment!

That isn't necessarily a wrong theoretical approach - SPKI is based
on the premise that only keys are important, names are simply = optional
attributes attached to keys.  But it is wrong in X.509 because = X.509
certificates are identified by and stored under Distinguished Names,
not public keys or SubjectKeyIdentifiers.

Standards are about interworking in a multi-vendor environment; the
testable requirements contained in standards are covenants between
supplier and customer.  My goal is for a CMI purchased from = vendor
X and operated by company A to work with applications purchased from
vendors Y and Z and operated by companies B and C.  I = understand
that that is not your primary goal, but I expect you to acknowledge
that when as a result of non-conformance some applications work and
others don't, it is NOT the fault of the conforming applications = even
when they are the ones that fail.  And that when someone from = company
X proposes as a Standard a workaround for a problem created = somewhere
else in company X, the IETF is entitled to disregard the
company-specific rationale for that workaround.

Regards,
Dave



> From: "Trevor Freeman" = <trevorf@Exchange.Microsoft.com>
>
> Hi David,
> I am afraid I don't see it necessary to eradicate every little
> imperfection because it is there. To err is human, and people = make
> mistakes. People also have a wide list of requires which you may or = may
> not agree with, but it does not mean that it is less real to = them.
> So I don't see this as an error, simple a different point of view, = and
> we will obviously disagree on this point.
> At the end of the day it is up to any product vendor to make the = call as
> to what is\is not in their product, regardless what is in the = standard.
> It is up to the market place to decide. History certainly tells us = that
> customers like robustness in a product.
> If you can cite a specific issue, then we will obviously = reconsider, but
> I don't find punishing minor infractions of administrators a = compelling
> case.
> Trevor

------_=_NextPart_001_01BFD0D4.253A6B56-- Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA20441 for ; Wed, 7 Jun 2000 16:51:45 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 07 Jun 2000 17:26:05 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 07 Jun 2000 17:26:01 -0600 From: "Bob Jueneman" To: , Cc: , Subject: RE: Correct approach to certificate validation? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA20442 At this point I am mightily confused, and would appreciate it if someone would clarify the issue, as I apparently tuned in late. Trevor says that they enforce name constraints, but that they don't support name chaining. I must be missing something important here -- how do the two differ, and/or how is one possible without the other? Are we talking about CA names only, end-entity names, or what? Some concrete examples pro and con would be very helpful. Regards, Bob >>> "Trevor Freeman" 06/06/00 08:42PM >>> We use AKI, but don't require it, as the field can be calculated on the fly so to speak. I am not linking the enforcement of name constrains with the enforcement of name chaining in any. We will enforce name constraints as this is a security issue, we don't enforce name chaining. We trust the CA because we have built a chain of certificate to a trusted root, with valid policy and name constraints. -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent: Tuesday, June 06, 2000 1:33 AM To: Trevor Freeman Cc: denis.bider@siol.net; ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? > Hi Denis, Now there are two Denis on the list. Don't be confused, the one above is not me ! :-) It seems that we are starting a very interesting threat. > We have found that enforcing name chaining in path construction, > causes more problems than it solves. We therefore have reverted to > using the name as just a hint, rather than a critical factor and > will as you have found, use a certificate signed with the right > key as a valid parent in that chain. To be more precise, do you mean that you are using the authority key identifier extension ? This extension provides a means of identifying the public key corresponding to the private key used to sign a certificate. The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate chain building. If this is what you use, this means that you use a field that must be present but does not need to be understood, since this extension is marked NON critical. If your implementation relies on that field, which options of that field are you using (since this is a sequence of three optional fields) ? If I misunderstood what you are using, please clarify. > This applies to intermediate > as well as self signed certificates. We have seen customer > scenarios where you need to deliberately build certificates which > don't chain on names so enforcing name chaining would cause > problems. It is true that enforcing name constraints within certificates themselves provides limitations and causes problems. Enforcing name chaining outside the certificates is much morer flexible ... and should be recognized as a valid additional check in the "son-of-RFC2459". > I know this is at odds with RFC2459, but as this behaviour does > not in our view cause a security problem, but does make the > overall process more robust, we have and will continue to opt for > the more robust solution. It seems to early at this stage to conclude that there are no security problems with such an approach (there are not enough information at this stage to make any conclusion). Just a remainder. The basic principle is the following: it is not because a CA certificate exists that it should be trusted. Denis > I have also posted previously on the list that mandating name > chaining, in addition to signatures and policy chaining is a bad > idea. > > Trevor > > -----Original Message----- > From: denis.bider@siol.net [mailto:denis.bider@siol.net] > Sent: Sunday, June 04, 2000 11:19 AM > To: ietf-pkix@imc.org > Subject: Correct approach to certificate validation? > > Now, based on my previous message, my question for this workgroup: > > Which of these approaches is correct? > - the approach of IE5 and Outlook, which, if an Authority Key > Identifier > extension is present, does not perform a comparison of the > issuer-DN in the > subject-cert to the subject-DN of the root-cert? > - or the approach of Netscape and IIS4, which, even if an > Authority Key > Identifier extension is present, DOES still perform a comparison > of the > subject-cert-issuer-DN to the root-cert-subject-DN? > > Regards, > > denis bider > > PS. I would like to thank Ace Swerling from Microsoft Consulting > Services > for the fact that he bothered to look into my problem, and > especially to > Peter Williams from Valicert who devoted much of his time to help > me solve > this issue. I appreciate your feedback very much. > > -----Original Message----- > From: denis bider [mailto:denis@denisbider.com] On Behalf Of > denis.bider@siol.net > Sent: Sunday, June 04, 2000 20:08 > To: 'ietf-pkix@imc.org' > Subject: Report - certificate validation in IE5, Outlook, > IIS4, Netscape > 4.72 > > Hello, > > a while ago I sent to this list an enquiry regarding Microsoft's > certificate > validation code in IIS4. I have now resolved the problem that was > the reason > for my enquiry. Since the solution to the problem produced some > interesting > insight into how certificate chains are handled in IE5 and Outlook > / IIS4 > and Netscape, and since the behavior in question should be covered > by > RFC2459, but does not seem to be, I am forwarding my findings to > you. > > I produced my own certificate generating utility, the intention of > which was > to generate certificates which could be used by IE5 to login into > an > SSL-protected web site running on IIS4. My problem was that, > although IE5 > claimed my root-cert/subject-cert certificate chain to be valid, > and > although Outlook properly signed and verified messages signed by > these > certificates, IIS4 rejected all attempts to use the subject > certificate for > SSL client authentication. Also, when the subject certificate was > imported > into Netscape, Netscape didn't even show it as an elligible choice > for SSL > client authentication. > > To sum it up, the problem was that there was a glitch in my code > that caused > the subject-DN in root-cert to be slightly different from the > issuer-DN in > the subject-cert. It seems that the certificate verification code > in IE5 and > Outlook2000 is somewhat easy-going, since both of these products > validated > the pair of certificates as valid (they performed cert-chain > validation > solely on the grounds of the key identifier in the Authority Key > Identifier > extension, they did not compare the sub-cert-issuerDN to the > root-cert-subjectDN). IIS4 and Netscape Communicator, on the other > hand, > seem to have a more stringent policy, since they both rejected > these > certificates. > > denis bider Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19378 for ; Wed, 7 Jun 2000 15:32:49 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA02274; Wed, 7 Jun 2000 18:40:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 7 Jun 2000 18:42:12 -0400 To: "Trevor Freeman" From: Stephen Kent Subject: RE: Correct approach to certificate validation? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Trevor, Two observations: - path construction (going up toward a root) is nominally based on the use of the issuer name to find the right CA certificate, with the AKI/SKI used to disambiguate among multiple valid CA certs. I recall that the list discussed the potential problems of using just the AKI to locate a CA certificate. I expressed concern then that the AKI didn't provide a means of locating a CA certificate when it was not local, i.e., one would need to have a database that was a flat file for all possible CA certificates to do the lookup. My concern was that we were creating a situation where people might build systems that had all the shortcomings of LAN e-mail systems, e.g., they worked well locally, but did not scale across the Internet. Of course, if one uses the AIA extension this problem might be ameliorated. So, my question is how do MS products locate a CA cert that is not available in a local cache or local LDAP directory, using just the AKI? - name constraints are critical to secure use of certs, so I do hope that you are correctly enforcing this extension, when it is present. Contrary to what Amir said, this is PKIX, not SPKI. We don't buy into the notion that keys are principals here :-). If one always uses name constraints in cross certs that link to other administrative domains, something that a local CA or can enforce unilaterally, then names are reasonably safe to employ for access control purposes. (Of course, one can't do this with TTP, but maybe that's another good reason for not using them when identification for access control is important.) But, if you're violating the standards to accommodate administrative sloppiness in managing CA names for chaining, then maybe you're assuming an environment where one can never rely on names for ACLs anyway. That's a scary environment. Steve Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17764 for ; Wed, 7 Jun 2000 14:17:51 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id RAA08224 for ; Wed, 7 Jun 2000 17:18:59 -0400 (EDT) Message-Id: <200006072118.RAA08217@roadblock.missi.ncsc.mil> Date: Wed, 7 Jun 2000 17:23:39 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Correct approach to certificate validation? To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: o906YrGPIOvV6INslRpnPw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Peter, Do you agree that: 1) path validation requirement "a" of X.509 requires name chaining? 2) if the subject of a certificate is a CA then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field in all certificates issued by the CA (RFC 2459 section 4.2.1.6) 3) A certificate may use a null DN iff the subject/issuer alternative name extension is flagged critical *and* for every name form used in the GeneralName type, there shall be a name registration system that ensures that any name used unambiguously identifies one entity to both certificate issuer and certificate users. (X.509 section 12.3.2.1) Dave Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16400 for ; Wed, 7 Jun 2000 13:42:47 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Jun 2000 13:45:25 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE235E2D4@seine.valicert.com> From: Peter Williams To: "'David P. Kemp'" Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Date: Wed, 7 Jun 2000 13:45:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" David, "But it is wrong in X.509 because X.509 certificates are identified by and stored under Distinguished Names, not public keys or SubjectKeyIdentifiers." X.509 does not require one to identify a storage location for a cert at all, locate storage using a DN, nor does it require that the DN be used as the subject identity element bound to a key. You should be aware, in further support of my earlier statement, that PKIX certificates need contain no subject DN information. Nor need there be a DN name form populated in the standard alternative name field for subjects, as RFC 2459 authors and chairs declare to the Internet: "The subject alternative names extension allows additional identities to be bound to the subject of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a uniform resource identifier (URI). Other options exist, including completely local definitions [...]" "Further, if the only subject identity included in the certificate is an alternative name form (e.g., an electronic mail address), then the subject distinguished name MUST be empty (an empty sequence), and the subjectAltName extension MUST be present. If the subject field contains an empty sequence, the subjectAltName extension MUST be marked critical." Do you assert that PKIX profile is not aligned with X.509, when you make your various claims concerning DNs? Does a PKIX cert conform to X.509 literally or in spirit, if the actual exampled option stated above in RFC 2459 is used? PS. The PKIX authors' name comparison rules already make PKIX path processing non-conforming against X.509 (i.e. the result of path processing using the PKIX name chaining rule is not the same as if one were to use the X.509 path processing and name matching rule. X.509 conformance is really not an issue in PKIX WG! 2459 already built in the situation that even two PKIX implementations may not process paths the same! A cert chain can be valid in one implementation, and invalid in another; its not clear it the X.509 rules, though permitted by PKIX, make for a conforming path processing implementation. -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent: Wednesday, June 07, 2000 7:00 AM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, It isn't about punishing administrators for minor errors, it is about achieving an overall system with the goals of being both secure and non-intrusive to the end user. That may well mean that administrators have to do more thinking, planning, and quality control, but that is what they (we, the providers of a PKI for our branch of Govt) are paid to do. The specific case I'm referring to is Jim Schaad's assertion that an S/MIME-specific cert path attribute is needed because applications can't find CA certificates. I didn't realize until now that that was because in your environment subject certificates are not required to have a correct issuer name! It seemed obvious to me that the PKI is responsible for correctly binding names to keys. But you are saying that Issuer names don't really matter, they're just a hint to help applications search for a cert with a signing key that validates the subject cert signature. Well no wonder applications can't find CA certs in that environment! That isn't necessarily a wrong theoretical approach - SPKI is based on the premise that only keys are important, names are simply optional attributes attached to keys. But it is wrong in X.509 because X.509 certificates are identified by and stored under Distinguished Names, not public keys or SubjectKeyIdentifiers. Standards are about interworking in a multi-vendor environment; the testable requirements contained in standards are covenants between supplier and customer. My goal is for a CMI purchased from vendor X and operated by company A to work with applications purchased from vendors Y and Z and operated by companies B and C. I understand that that is not your primary goal, but I expect you to acknowledge that when as a result of non-conformance some applications work and others don't, it is NOT the fault of the conforming applications even when they are the ones that fail. And that when someone from company X proposes as a Standard a workaround for a problem created somewhere else in company X, the IETF is entitled to disregard the company-specific rationale for that workaround. Regards, Dave > From: "Trevor Freeman" > > Hi David, > I am afraid I don't see it necessary to eradicate every little > imperfection because it is there. To err is human, and people make > mistakes. People also have a wide list of requires which you may or may > not agree with, but it does not mean that it is less real to them. > So I don't see this as an error, simple a different point of view, and > we will obviously disagree on this point. > At the end of the day it is up to any product vendor to make the call as > to what is\is not in their product, regardless what is in the standard. > It is up to the market place to decide. History certainly tells us that > customers like robustness in a product. > If you can cite a specific issue, then we will obviously reconsider, but > I don't find punishing minor infractions of administrators a compelling > case. > Trevor Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14631 for ; Wed, 7 Jun 2000 12:45:10 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Jun 2000 15:53:00 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B101715960@sothmxs06.entrust.com> From: Carlisle Adams To: borges@sibs.pt, "'stephen.farrell@baltimore.ie'" Cc: ietf-pkix@imc.org Subject: RE: Attribute Certificate Request Date: Wed, 7 Jun 2000 15:53:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Hi Stephen, Pedro, > ---------- > From: Stephen Farrell[SMTP:stephen.farrell@baltimore.ie] > Reply To: stephen.farrell@baltimore.ie > Sent: Monday, June 05, 2000 3:46 PM > To: borges@sibs.pt > Cc: ietf-pkix@imc.org > Subject: Re: Attribute Certificate Request > > Pedro, > > Since the use cases for ACs aren't as well understood as for > public key certificates, there is, as yet, no equivalent to > CMP/CMC for AC requests. I would expect that, in future, we > might get around to writing one. Actually, the future is not that far away... :-) The draft rfc2510bis puts in place a framework that allows CMP to be used as a general protocol for management (including, of course, an initial request) of any kind of certificate. (Note that this was accomplished without requiring any bits-on-the-wire changes to the RFC 2510 syntax.) Formats that have already been envisioned include attribute certificates and WTLS certificates. This strikes me as a very powerful and useful generalization, and should serve to make this PKIX protocol potentially applicable to a number of environments. All that is required is a very short document listing the certificate types of interest and providing a syntax for their corresponding templates. Look for this Internet Draft to appear shortly (within the next 2-3 weeks, I hope). Carlisle. > Meanwhile, there is draft-ietf-pkix-laap-00.txt which describes > an alternative to LDAP for AC retrieval, though this deliberately > doesn't try to provide the equivalent of a CMP certification > request. > > Regards, > Stephen. > > Pedro Miguel Pereira Borges wrote: > > > > Hi all, > > > > I'm currently reading the "An Internet Attribute Certificate > Profile > > for Authorization" draft... > > However, there is a question that I would like to see answered: > is > > there a definition (ASN.1 or not) of what an attribute certificate > request > > should contain like there is one for the "normal" X.509 ID certificates > ? > > > > Thanks in advance, > > > > Pedro Borges > Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27691 for ; Wed, 7 Jun 2000 06:54:30 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA25323 for ; Wed, 7 Jun 2000 09:55:38 -0400 (EDT) Message-Id: <200006071355.JAA25280@roadblock.missi.ncsc.mil> Date: Wed, 7 Jun 2000 10:00:12 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Correct approach to certificate validation? To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BNyxfe4iNnIIbfsREL1EMg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Trevor, It isn't about punishing administrators for minor errors, it is about achieving an overall system with the goals of being both secure and non-intrusive to the end user. That may well mean that administrators have to do more thinking, planning, and quality control, but that is what they (we, the providers of a PKI for our branch of Govt) are paid to do. The specific case I'm referring to is Jim Schaad's assertion that an S/MIME-specific cert path attribute is needed because applications can't find CA certificates. I didn't realize until now that that was because in your environment subject certificates are not required to have a correct issuer name! It seemed obvious to me that the PKI is responsible for correctly binding names to keys. But you are saying that Issuer names don't really matter, they're just a hint to help applications search for a cert with a signing key that validates the subject cert signature. Well no wonder applications can't find CA certs in that environment! That isn't necessarily a wrong theoretical approach - SPKI is based on the premise that only keys are important, names are simply optional attributes attached to keys. But it is wrong in X.509 because X.509 certificates are identified by and stored under Distinguished Names, not public keys or SubjectKeyIdentifiers. Standards are about interworking in a multi-vendor environment; the testable requirements contained in standards are covenants between supplier and customer. My goal is for a CMI purchased from vendor X and operated by company A to work with applications purchased from vendors Y and Z and operated by companies B and C. I understand that that is not your primary goal, but I expect you to acknowledge that when as a result of non-conformance some applications work and others don't, it is NOT the fault of the conforming applications even when they are the ones that fail. And that when someone from company X proposes as a Standard a workaround for a problem created somewhere else in company X, the IETF is entitled to disregard the company-specific rationale for that workaround. Regards, Dave > From: "Trevor Freeman" > > Hi David, > I am afraid I don't see it necessary to eradicate every little > imperfection because it is there. To err is human, and people make > mistakes. People also have a wide list of requires which you may or may > not agree with, but it does not mean that it is less real to them. > So I don't see this as an error, simple a different point of view, and > we will obviously disagree on this point. > At the end of the day it is up to any product vendor to make the call as > to what is\is not in their product, regardless what is in the standard. > It is up to the market place to decide. History certainly tells us that > customers like robustness in a product. > If you can cite a specific issue, then we will obviously reconsider, but > I don't find punishing minor infractions of administrators a compelling > case. > Trevor Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20804 for ; Tue, 6 Jun 2000 21:09:06 -0700 (PDT) Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Jun 2000 14:19:55 +1000 Message-ID: From: "Ramsay, Ron" To: Trevor Freeman , "David P. Kemp" Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Date: Wed, 7 Jun 2000 14:21:04 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Trevor, I don't think David was saying you can't go your own way. In fact, RFC 2459 has a funny statement in it where it recognises that vendors may produce non-conforming products. I think the point he is making is that customers should be made aware that your product conforms neither to RFC 2459 nor to X.509. And I think you agree that it doesn't. Ron. PS These are my views and not those of my employer. -----Original Message----- From: Trevor Freeman [mailto:trevorf@Exchange.Microsoft.com] Sent: Wednesday, 7 June 2000 13:00 To: David P. Kemp Cc: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Hi David, I am afraid I don't see it necessary to eradicate every little imperfection because it is there. To err is human, and people make mistakes. People also have a wide list of requires which you may or may not agree with, but it does not mean that it is less real to them. So I don't see this as an error, simple a different point of view, and we will obviously disagree on this point. At the end of the day it is up to any product vendor to make the call as to what is\is not in their product, regardless what is in the standard. It is up to the market place to decide. History certainly tells us that customers like robustness in a product. If you can cite a specific issue, then we will obviously reconsider, but I don't find punishing minor infractions of administrators a compelling case. Trevor -----Original Message----- From: David P. Kemp [ mailto:dpkemp@missi.ncsc.mil ] Sent: Tuesday, June 06, 2000 11:20 AM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, Could you describe a customer scenario which requires deliberate non-chaining of names? I can't envision any circumstance where a CA 1) does not have a certificate containing the CA's signing key and a subject name for the CA, or 2) cannot populate the issuer and signature-value fields of certificates it issues with values matching the subject name and public key from its own cert. Enforcing name chaining during path construction does not cause problems; it highlights existing problems. When a system continues to function in an environment with errors over which it has no control (transmission bit errors, for example), it is called "robust". But when a system continues to function normally in the face of correctable errors without providing any indication of a problem, "oblivious" is a better term than "robust". Like fixing an engine problem by removing the offending indicator lamp from the dashboard. I agree that ignoring name chaining errors during path construction or validation does not cause a "security" problem, using a sufficiently limited definition of security. But the real security of a system depends on (among other things) correct administration, and anything which promotes sloppy administration promotes sloppy security. I therefore disagree that applications should ignore the path validation requirements of X.509: "a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked." This name chaining requirement wasn't inserted willy-nilly into RFC 2459, it has been a fundamental part of an International Standard for twelve years. Saying "we don't like this requirement, so we are going to ignore it" is undoubtedly an option for a company with the market cap of MSFT. But customers for whom standards conformance is a checklist item should be fully informed that you have chosen not to conform to either X.509 or RFC 2459. Dave > From: "Trevor Freeman" > > Hi Denis, > We have found that enforcing name chaining in path construction, causes > more problems than it solves. We therefore have reverted to using the > name as just a hint, rather than a critical factor and will as you have > found, use a certificate signed with the right key as a valid parent in > that chain. This applies to intermediate as well as self signed > certificates. We have seen customer scenarios where you need to > deliberately build certificates which don't chain on names so enforcing > name chaining would cause problems. Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA18097 for ; Tue, 6 Jun 2000 20:32:52 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Jun 2000 20:27:51 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 6 Jun 2000 19:42:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD029.F8666240" Subject: RE: Correct approach to certificate validation? Date: Tue, 6 Jun 2000 19:42:06 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/PkgXOegneKI+lRJ+EziTFYwDm3QAln9VQ From: "Trevor Freeman" To: "Denis Pinkas" Cc: , X-OriginalArrivalTime: 07 Jun 2000 02:42:08.0015 (UTC) FILETIME=[F90B09F0:01BFD029] This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD029.F8666240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We use AKI, but don't require it, as the field can be calculated on the fly so to speak. I am not linking the enforcement of name constrains with the enforcement of name chaining in any. We will enforce name constraints as this is a security issue, we don't enforce name chaining.=20 We trust the CA because we have built a chain of certificate to a trusted root, with valid policy and name constraints. -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]=20 Sent: Tuesday, June 06, 2000 1:33 AM To: Trevor Freeman Cc: denis.bider@siol.net; ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? > Hi Denis, Now there are two Denis on the list. Don't be confused, the one above is not me ! :-) It seems that we are starting a very interesting threat. > We have found that enforcing name chaining in path construction, > causes more problems than it solves. We therefore have reverted to > using the name as just a hint, rather than a critical factor and > will as you have found, use a certificate signed with the right > key as a valid parent in that chain.=20 To be more precise, do you mean that you are using the authority key identifier extension ? This extension provides a means of identifying the public key corresponding to the private key used to sign a certificate. The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate chain building.=20 If this is what you use, this means that you use a field that must be present but does not need to be understood, since this extension is marked NON critical. If your implementation relies on that field, which options of that field are you using (since this is a sequence of three optional fields) ? If I misunderstood what you are using, please clarify. > This applies to intermediate > as well as self signed certificates. We have seen customer > scenarios where you need to deliberately build certificates which > don't chain on names so enforcing name chaining would cause > problems. It is true that enforcing name constraints within certificates themselves provides limitations and causes problems. Enforcing name chaining outside the certificates is much morer flexible ... and should be recognized as a valid additional check in the "son-of-RFC2459".=20 > I know this is at odds with RFC2459, but as this behaviour does > not in our view cause a security problem, but does make the > overall process more robust, we have and will continue to opt for > the more robust solution. It seems to early at this stage to conclude that there are no security problems with such an approach (there are not enough information at this stage to make any conclusion). Just a remainder. The basic principle is the following: it is not because a CA certificate exists that it should be trusted.=20 Denis =20 > I have also posted previously on the list that mandating name > chaining, in addition to signatures and policy chaining is a bad > idea. >=20 > Trevor >=20 > -----Original Message----- > From: denis.bider@siol.net [mailto:denis.bider@siol.net] > Sent: Sunday, June 04, 2000 11:19 AM > To: ietf-pkix@imc.org > Subject: Correct approach to certificate validation? >=20 > Now, based on my previous message, my question for this workgroup: >=20 > Which of these approaches is correct? > - the approach of IE5 and Outlook, which, if an Authority Key > Identifier > extension is present, does not perform a comparison of the > issuer-DN in the > subject-cert to the subject-DN of the root-cert? > - or the approach of Netscape and IIS4, which, even if an > Authority Key > Identifier extension is present, DOES still perform a comparison > of the > subject-cert-issuer-DN to the root-cert-subject-DN? >=20 > Regards, >=20 > denis bider >=20 > PS. I would like to thank Ace Swerling from Microsoft Consulting > Services > for the fact that he bothered to look into my problem, and > especially to > Peter Williams from Valicert who devoted much of his time to help > me solve > this issue. I appreciate your feedback very much. >=20 > -----Original Message----- > From: denis bider [mailto:denis@denisbider.com] On Behalf Of > denis.bider@siol.net > Sent: Sunday, June 04, 2000 20:08 > To: 'ietf-pkix@imc.org' > Subject: Report - certificate validation in IE5, Outlook, > IIS4, Netscape > 4.72 >=20 > Hello, >=20 > a while ago I sent to this list an enquiry regarding Microsoft's > certificate > validation code in IIS4. I have now resolved the problem that was > the reason > for my enquiry. Since the solution to the problem produced some > interesting > insight into how certificate chains are handled in IE5 and Outlook > / IIS4 > and Netscape, and since the behavior in question should be covered > by > RFC2459, but does not seem to be, I am forwarding my findings to > you. >=20 > I produced my own certificate generating utility, the intention of > which was > to generate certificates which could be used by IE5 to login into > an > SSL-protected web site running on IIS4. My problem was that, > although IE5 > claimed my root-cert/subject-cert certificate chain to be valid, > and > although Outlook properly signed and verified messages signed by > these > certificates, IIS4 rejected all attempts to use the subject > certificate for > SSL client authentication. Also, when the subject certificate was > imported > into Netscape, Netscape didn't even show it as an elligible choice > for SSL > client authentication. >=20 > To sum it up, the problem was that there was a glitch in my code > that caused > the subject-DN in root-cert to be slightly different from the > issuer-DN in > the subject-cert. It seems that the certificate verification code > in IE5 and > Outlook2000 is somewhat easy-going, since both of these products > validated > the pair of certificates as valid (they performed cert-chain > validation > solely on the grounds of the key identifier in the Authority Key > Identifier > extension, they did not compare the sub-cert-issuerDN to the > root-cert-subjectDN). IIS4 and Netscape Communicator, on the other > hand, > seem to have a more stringent policy, since they both rejected > these > certificates. >=20 > denis bider ------_=_NextPart_001_01BFD029.F8666240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

We use AKI, but don't require it, as the field can be = calculated on the fly so to speak.
I am not linking the enforcement of name constrains with the enforcement = of name chaining in any. We will enforce name constraints as this is a = security issue, we don't enforce name chaining.
We trust the CA because we have built a chain of certificate to a = trusted root, with valid policy and name constraints.

 -----Original Message-----
From:   Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent:   Tuesday, June 06, 2000 1:33 AM
To:     Trevor Freeman
Cc:     denis.bider@siol.net; ietf-pkix@imc.org
Subject:        Re: Correct approach = to certificate validation?

> Hi Denis,

Now there are two Denis on the list. Don't be confused, the one
above is not me ! :-)

It seems that we are starting a very interesting threat.

> We have found that enforcing name chaining in path = construction,
> causes more problems than it solves. We therefore have reverted = to
> using the name as just a hint, rather than a critical factor = and
> will as you have found, use a certificate signed with the right
> key as a valid parent in that chain.

To be more precise, do you mean that you are using the authority key
identifier extension ?

This extension provides a means of identifying the public key
corresponding to the private key used to sign a certificate. The
keyIdentifier field of the authorityKeyIdentifier extension MUST be
included in all certificates generated by conforming CAs to
facilitate chain building.

If this is what you use, this means that you use a field that must
be present but does not need to be understood, since this extension
is marked NON critical. If your implementation relies on that field,
which options of that field are you using (since this is a sequence
of three optional fields) ? If I misunderstood what you are using,
please clarify.

> This applies to intermediate
> as well as self signed certificates. We have seen customer
> scenarios where you need to deliberately build certificates = which
> don't chain on names so enforcing name chaining would cause
> problems.

It is true that enforcing name constraints within certificates
themselves provides limitations and causes problems. Enforcing name
chaining outside the certificates is much morer flexible ... and
should be recognized as a valid additional check in the
"son-of-RFC2459".

> I know this is at odds with RFC2459, but as this behaviour does
> not in our view cause a security problem, but does make the
> overall process more robust, we have and will continue to opt = for
> the more robust solution.

It seems to early at this stage to conclude that there are no
security problems with such an approach (there are not enough
information at this stage to make any conclusion). Just a remainder.
The basic principle is the following: it is not because a CA
certificate exists that it should be trusted.

Denis

> I have also posted previously on the list that mandating name
> chaining, in addition to signatures and policy chaining is a = bad
> idea.
>
> Trevor
>
> -----Original Message-----
> From: denis.bider@siol.net [mailto:denis.bider@siol.net]
= > Sent: Sunday, June 04, 2000 11:19 AM
> To: ietf-pkix@imc.org
> Subject: Correct approach to certificate validation?
>
> Now, based on my previous message, my question for this = workgroup:
>
> Which of these approaches is correct?
>   - the approach of IE5 and Outlook, which, if an = Authority Key
> Identifier
> extension is present, does not perform a comparison of the
> issuer-DN in the
> subject-cert to the subject-DN of the root-cert?
>   - or the approach of Netscape and IIS4, which, even if = an
> Authority Key
> Identifier extension is present, DOES still perform a = comparison
> of the
> subject-cert-issuer-DN to the root-cert-subject-DN?
>
> Regards,
>
> denis bider
>
> PS. I would like to thank Ace Swerling from Microsoft = Consulting
> Services
> for the fact that he bothered to look into my problem, and
> especially to
> Peter Williams from Valicert who devoted much of his time to = help
> me solve
> this issue. I appreciate your feedback very much.
>
>  -----Original Message-----
> From:   denis bider [mailto:denis@denisbider.com]&nbs= p; On Behalf Of
> denis.bider@siol.net
> Sent:   Sunday, June 04, 2000 20:08
> To:     'ietf-pkix@imc.org'
> Subject:        Report - = certificate validation in IE5, Outlook,
> IIS4, Netscape
> 4.72
>
> Hello,
>
> a while ago I sent to this list an enquiry regarding = Microsoft's
> certificate
> validation code in IIS4. I have now resolved the problem that = was
> the reason
> for my enquiry. Since the solution to the problem produced some
> interesting
> insight into how certificate chains are handled in IE5 and = Outlook
> / IIS4
> and Netscape, and since the behavior in question should be = covered
> by
> RFC2459, but does not seem to be, I am forwarding my findings = to
> you.
>
> I produced my own certificate generating utility, the intention = of
> which was
> to generate certificates which could be used by IE5 to login = into
> an
> SSL-protected web site running on IIS4. My problem was that,
> although IE5
> claimed my root-cert/subject-cert certificate chain to be = valid,
> and
> although Outlook properly signed and verified messages signed = by
> these
> certificates, IIS4 rejected all attempts to use the subject
> certificate for
> SSL client authentication. Also, when the subject certificate = was
> imported
> into Netscape, Netscape didn't even show it as an elligible = choice
> for SSL
> client authentication.
>
> To sum it up, the problem was that there was a glitch in my = code
> that caused
> the subject-DN in root-cert to be slightly different from the
> issuer-DN in
> the subject-cert. It seems that the certificate verification = code
> in IE5 and
> Outlook2000 is somewhat easy-going, since both of these = products
> validated
> the pair of certificates as valid (they performed cert-chain
> validation
> solely on the grounds of the key identifier in the Authority = Key
> Identifier
> extension, they did not compare the sub-cert-issuerDN to the
> root-cert-subjectDN). IIS4 and Netscape Communicator, on the = other
> hand,
> seem to have a more stringent policy, since they both rejected
> these
> certificates.
>
> denis bider

------_=_NextPart_001_01BFD029.F8666240-- Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA17819 for ; Tue, 6 Jun 2000 20:30:00 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Jun 2000 20:15:43 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 6 Jun 2000 20:00:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD02C.86E28F9E" Subject: RE: Correct approach to certificate validation? Date: Tue, 6 Jun 2000 20:00:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/P5fPg0KFETdn6Ti6T1E20UgYt4wAQ+O0g From: "Trevor Freeman" To: "David P. Kemp" Cc: X-OriginalArrivalTime: 07 Jun 2000 03:00:26.0390 (UTC) FILETIME=[87B9C360:01BFD02C] This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD02C.86E28F9E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi David, I am afraid I don't see it necessary to eradicate every little imperfection because it is there. To err is human, and people make mistakes. People also have a wide list of requires which you may or may not agree with, but it does not mean that it is less real to them.=20 So I don't see this as an error, simple a different point of view, and we will obviously disagree on this point. At the end of the day it is up to any product vendor to make the call as to what is\is not in their product, regardless what is in the standard. It is up to the market place to decide. History certainly tells us that customers like robustness in a product. If you can cite a specific issue, then we will obviously reconsider, but I don't find punishing minor infractions of administrators a compelling case. Trevor -----Original Message----- From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]=20 Sent: Tuesday, June 06, 2000 11:20 AM To: ietf-pkix@imc.org Subject: RE: Correct approach to certificate validation? Trevor, Could you describe a customer scenario which requires deliberate non-chaining of names? I can't envision any circumstance where a CA 1) does not have a certificate containing the CA's signing key and a subject name for the CA, or 2) cannot populate the issuer and signature-value fields of certificates it issues with values matching the subject name and public key from its own cert. Enforcing name chaining during path construction does not cause problems; it highlights existing problems. When a system continues to function in an environment with errors over which it has no control (transmission bit errors, for example), it is called "robust". But when a system continues to function normally in the face of correctable errors without providing any indication of a problem, "oblivious" is a better term than "robust". Like fixing an engine problem by removing the offending indicator lamp from the dashboard. I agree that ignoring name chaining errors during path construction or validation does not cause a "security" problem, using a sufficiently limited definition of security. But the real security of a system depends on (among other things) correct administration, and anything which promotes sloppy administration promotes sloppy security. I therefore disagree that applications should ignore the path validation requirements of X.509: "a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked." This name chaining requirement wasn't inserted willy-nilly into RFC 2459, it has been a fundamental part of an International Standard for twelve years. Saying "we don't like this requirement, so we are going to ignore it" is undoubtedly an option for a company with the market cap of MSFT. But customers for whom standards conformance is a checklist item should be fully informed that you have chosen not to conform to either X.509 or RFC 2459. Dave > From: "Trevor Freeman" >=20 > Hi Denis,=20 > We have found that enforcing name chaining in path construction, causes > more problems than it solves. We therefore have reverted to using the > name as just a hint, rather than a critical factor and will as you have > found, use a certificate signed with the right key as a valid parent in > that chain. This applies to intermediate as well as self signed > certificates. We have seen customer scenarios where you need to > deliberately build certificates which don't chain on names so enforcing > name chaining would cause problems. ------_=_NextPart_001_01BFD02C.86E28F9E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

Hi David,
I am afraid I don't see it necessary to eradicate every little = imperfection because it is there. To err is human, and people make = mistakes. People also have a wide list of requires which you may or may = not agree with, but it does not mean that it is less real to them.
So I don't see this as an error, simple a different point of view, and = we will obviously disagree on this point.
At the end of the day it is up to any product vendor to make the call as = to what is\is not in their product, regardless what is in the standard. = It is up to the market place to decide. History certainly tells us that = customers like robustness in a product.
If you can cite a specific issue, then we will obviously reconsider, but = I don't find punishing minor infractions of administrators a compelling = case.
Trevor

 -----Original Message-----
From:   David P. Kemp [mailto:dpkemp@missi.ncsc.mil] Sent:   Tuesday, June 06, 2000 11:20 AM
To:     ietf-pkix@imc.org
Subject:        RE: Correct approach = to certificate validation?

Trevor,

Could you describe a customer scenario which requires deliberate
non-chaining of names?  I can't envision any circumstance where = a
CA 1) does not have a certificate containing the CA's signing key
and a subject name for the CA, or 2) cannot populate the issuer and
signature-value fields of certificates it issues with values = matching
the subject name and public key from its own cert.

Enforcing name chaining during path construction does not cause
problems; it highlights existing problems.  When a system = continues
to function in an environment with errors over which it has no = control
(transmission bit errors, for example), it is called = "robust".  But
when a system continues to function normally in the face of = correctable
errors without providing any indication of a problem, = "oblivious" is a
better term than "robust".  Like fixing an engine problem = by removing
the offending indicator lamp from the dashboard.

I agree that ignoring name chaining errors during path construction
or validation does not cause a "security" problem, using a = sufficiently
limited definition of security.  But the real security of a = system
depends on (among other things) correct administration, and anything
which promotes sloppy administration promotes sloppy security.
I therefore disagree that applications should ignore the path
validation requirements of X.509:

  "a) Check that the signature verifies, that dates are valid, = that
      the certificate subject and certificate = issuer names chain
      correctly, and that the certificate has = not been revoked."

This name chaining requirement wasn't inserted willy-nilly into RFC
2459, it has been a fundamental part of an International Standard = for
twelve years. Saying "we don't like this requirement, so we are = going
to ignore it" is undoubtedly an option for a company with the = market
cap of MSFT.  But customers for whom standards conformance is a
checklist item should be fully informed that you have chosen not
to conform to either X.509 or RFC 2459.

Dave



> From: "Trevor Freeman" = <trevorf@Exchange.Microsoft.com>
>
> Hi Denis,
> We have found that enforcing name chaining in path construction, = causes
> more problems than it solves. We therefore have reverted to using = the
> name as just a hint, rather than a critical factor and will as you = have
> found, use a certificate signed with the right key as a valid = parent in
> that chain. This applies to intermediate as well as self signed
> certificates. We have seen customer scenarios where you need to
> deliberately build certificates which don't chain on names so = enforcing
> name chaining would cause problems.

------_=_NextPart_001_01BFD02C.86E28F9E-- Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11523 for ; Tue, 6 Jun 2000 11:13:51 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id OAA12643 for ; Tue, 6 Jun 2000 14:15:00 -0400 (EDT) Message-Id: <200006061815.OAA12639@roadblock.missi.ncsc.mil> Date: Tue, 6 Jun 2000 14:19:35 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: RE: Correct approach to certificate validation? To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0LuwLJjq80ZHj0Whgd4ZSQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Trevor, Could you describe a customer scenario which requires deliberate non-chaining of names? I can't envision any circumstance where a CA 1) does not have a certificate containing the CA's signing key and a subject name for the CA, or 2) cannot populate the issuer and signature-value fields of certificates it issues with values matching the subject name and public key from its own cert. Enforcing name chaining during path construction does not cause problems; it highlights existing problems. When a system continues to function in an environment with errors over which it has no control (transmission bit errors, for example), it is called "robust". But when a system continues to function normally in the face of correctable errors without providing any indication of a problem, "oblivious" is a better term than "robust". Like fixing an engine problem by removing the offending indicator lamp from the dashboard. I agree that ignoring name chaining errors during path construction or validation does not cause a "security" problem, using a sufficiently limited definition of security. But the real security of a system depends on (among other things) correct administration, and anything which promotes sloppy administration promotes sloppy security. I therefore disagree that applications should ignore the path validation requirements of X.509: "a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked." This name chaining requirement wasn't inserted willy-nilly into RFC 2459, it has been a fundamental part of an International Standard for twelve years. Saying "we don't like this requirement, so we are going to ignore it" is undoubtedly an option for a company with the market cap of MSFT. But customers for whom standards conformance is a checklist item should be fully informed that you have chosen not to conform to either X.509 or RFC 2459. Dave > From: "Trevor Freeman" > > Hi Denis, > We have found that enforcing name chaining in path construction, causes > more problems than it solves. We therefore have reverted to using the > name as just a hint, rather than a critical factor and will as you have > found, use a certificate signed with the right key as a valid parent in > that chain. This applies to intermediate as well as self signed > certificates. We have seen customer scenarios where you need to > deliberately build certificates which don't chain on names so enforcing > name chaining would cause problems. Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02090 for ; Tue, 6 Jun 2000 07:06:27 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Jun 2000 10:14:12 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B101715958@sothmxs06.entrust.com> From: Carlisle Adams To: "'Alan Shepherd'" Cc: "'ietf-pkix@imc.org'" Subject: RE: Protocol Action: Diffie-Hellman Proof-of-Possession Algorithm s to Proposed Standard Date: Tue, 6 Jun 2000 10:14:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Hi Alan, I make no claim to be "someone wiser", but I will point out that proof-of-possession threads have been both long and numerous on this list in the past. The basic principle is that POP is not primarily done to avoid security problems. A basic underlying assumption in any certificate-using environment is that the entity bound to the certificate actually holds the corresponding private key. POP ensures that this assumption is valid (at least at the time of certificate creation). If I can't assume that you hold the private key, why in the world would I use your certificate? If I have no fundamental reason to use your certificate, why does the certificate (and, through generalization, the PKI) exist? POP is done by a CA (or occasionally as part of an operational protocol between parties) to try and ensure that certificates have some meaning and value and are not just worthless strings of bits. If a particular security problem can be avoided in some cases by doing POP, that's just a useful side benefit. Carlisle. > ---------- > From: Alan Shepherd[SMTP:Alan.Shepherd@protek.com] > Sent: Monday, June 05, 2000 11:58 AM > To: 'ietf-pkix@imc.org' > Subject: RE: Protocol Action: Diffie-Hellman Proof-of-Possession > Algorithm s to Proposed Standard > > Please forgive me if this is a terribly naive question, but I would like > to > know what problems arise if a public key is certified erroneously. I can > not see what security problems arise through this and would very much > appreciate someone wiser explaining it! > > Thanks for you help. > > Alan > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: 31 May 2000 14:03 > > Cc: RFC Editor; RFC Editor; RFC Editor > > Subject: Protocol Action: Diffie-Hellman Proof-of-Possession > > Algorithms > > to Proposed Standard > > > > > > > > > > The IESG has approved the Internet-Draft 'Diffie-Hellman > > Proof-of-Possession Algorithms' as a > > Proposed Standard. This document is the product of the Public-Key > > Infrastructure (X.509) Working Group. The IESG contact persons are > > Jeffrey Schiller and Marcus Leech. > > > > > > > > Technical Summary > > > > One of the important requirements in cryptographic protocols is the > > ability for an entity to prove they have possession of a particular > > key. In particular, Certifying Authorities prior to the > > issuance of a > > certificate, need to prove that the entity for which the certificate > > will be issued in fact does have the private key that corresponds to > > the public key which is included in the certificate. > > > > The traditional approach used with public key encryption > > systems such > > as the RSA system is to have the challenger require the entity > > holding a given private key to sign a challenge string. > > > > However the Diffie-Hellman (DH) algorithm does not directly lend > > itself to providing such signatures, as it is at heart a key > > agreement algorithm. This document describes two methods for > > producing a signature from a Diffie-Hellman key pair. > > > > Working Group Summary > > > > Consensus was reached on the approach used in this document. > > > > Protocol Quality > > > > Jeffrey I. Schiller reviewed this document for the IESG. Furthermore > > the PKIX Working Group contains members with significant > > cryptographic experience who also have reviewed this document. > > > > Note to RFC Editor: > > > > There were some word-wrapping problems introduced in Appendix A of > > the document that need to be corrected: > > > > Appendix A: > > > > OLD: > > DH-Sign DEFINITIONS IMPLICIT TAGS ::= > > > > BEGIN > > --EXPORTS ALL > > -- The types and values defined in this module are exported for use > > in > > -- the other ASN.1 modules. Other applications may use them for > > their > > -- own purposes. > > > > NEW/FIXED: > > DH-Sign DEFINITIONS IMPLICIT TAGS ::= > > > > BEGIN > > --EXPORTS ALL > > -- The types and values defined in this module are exported for use > > -- in the other ASN.1 modules. Other applications may use them > > -- for their own purposes. > > > > -------------------------------------------------------------------------- > ---------------- > This message is for the named person's use only. It may contain > confidential, proprietary or legally privileged information. No > confidentiality or privilege is waived or lost by any mistransmission. If > you receive this message in error, please immediately delete it and all > copies of it from your system, destroy any hard copies of it and notify > the sender. You must not, directly or indirectly, use, disclose, > distribute, print, or copy any part of this message if you are not the > intended recipient. PROTEK Network Management Group and each of its > subsidiaries reserve the right to monitor all e-mail communications > through its networks. Any views expressed in this message are those of > the individual sender, except where the message states otherwise and the > sender is authorised to state them to be the views of any such entity. > > > > Received: from exchng-fairfax.pec.com (exchng-fairfax.pec.com [204.254.216.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA00764 for ; Tue, 6 Jun 2000 06:05:18 -0700 (PDT) Received: by EXCHNG-FAIRFAX with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Jun 2000 08:55:38 -0400 Message-ID: <5023FFCA43D8D311A8360008C7F450FD012440D1@EXCHNG-FAIRFAX> From: AFlyak To: "'ietf-pkix@imc.org'" Subject: Subscribe Date: Tue, 6 Jun 2000 08:55:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCFB6.82FC6A80" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFCFB6.82FC6A80 Content-Type: text/plain ------_=_NextPart_001_01BFCFB6.82FC6A80 Content-Type: text/html Subscribe ------_=_NextPart_001_01BFCFB6.82FC6A80-- Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18023 for ; Tue, 6 Jun 2000 02:13:00 -0700 (PDT) Received: from m1.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX0006-Fujitsu Gateway) id SAA22192 for ; Tue, 6 Jun 2000 18:20:44 +0900 (JST) (envelope-from takiguti@fjh.se.fujitsu.co.jp) Received: from nic10.fjh.se.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-0006-Fujitsu Domain Master) id SAA29009; Tue, 6 Jun 2000 18:20:43 +0900 (JST) Received: from clapton (clapton.fjh.se.fujitsu.co.jp [10.131.201.91]) by nic10.fjh.se.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id SAA04083 for ; Tue, 6 Jun 2000 18:20:42 +0900 (JST) Date: Tue, 06 Jun 2000 18:20:42 +0900 From: TAKIGUCHI Naruhito To: ietf-pkix@imc.org Subject: certificate policies extension in RFC2459 and son of RFC2459 Message-Id: <20000606180010.AFBC.TAKIGUTI@fjh.se.fujitsu.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00 (beta 17) Hi, all. It seems to me that there is an inconsistency between RFC2459 and son of RFC2459 about verifying the certificate policies extension. In RFC2459, if the certificate policies extension is marked as non-critical, it is not processed. But in son of RFC2459, the certificate policies extension is processed regardless of its critical flag. For example, consider there is a certificate path such below, and the acceptable policy set is (A). In RFC2459, this path's validation processing will succeed. But in son of RFC2459, this path's validation processing will be failed. +------------------------+ | root CA cert | | | | critical policy(A) | +------------------------+ | +------------------------+ | end entity cert | | | | non-critical policy(B) | +------------------------+ And, son of RFC2459 requires that certificate must have a certificate policies extension? Thus, son of RFC2459 doesn't have compatibility with a certificate which was issued based on RFC2459? Do I misunderstand? Could anyone advice me? Thanks in advance. ----- Naruhito TAKIGUCHI FUJITSU HOKURIKU SYSTEMS LTD. Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA15883 for ; Tue, 6 Jun 2000 01:25:11 -0700 (PDT) Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA15078; Tue, 6 Jun 2000 10:33:14 +0200 Message-ID: <393CB74A.5F138132@bull.net> Date: Tue, 06 Jun 2000 10:33:14 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Trevor Freeman CC: denis.bider@siol.net, ietf-pkix@imc.org Subject: Re: Correct approach to certificate validation? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Hi Denis, Now there are two Denis on the list. Don't be confused, the one above is not me ! :-) It seems that we are starting a very interesting threat. > We have found that enforcing name chaining in path construction, > causes more problems than it solves. We therefore have reverted to > using the name as just a hint, rather than a critical factor and > will as you have found, use a certificate signed with the right > key as a valid parent in that chain. To be more precise, do you mean that you are using the authority key identifier extension ? This extension provides a means of identifying the public key corresponding to the private key used to sign a certificate. The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate chain building. If this is what you use, this means that you use a field that must be present but does not need to be understood, since this extension is marked NON critical. If your implementation relies on that field, which options of that field are you using (since this is a sequence of three optional fields) ? If I misunderstood what you are using, please clarify. > This applies to intermediate > as well as self signed certificates. We have seen customer > scenarios where you need to deliberately build certificates which > don't chain on names so enforcing name chaining would cause > problems. It is true that enforcing name constraints within certificates themselves provides limitations and causes problems. Enforcing name chaining outside the certificates is much morer flexible ... and should be recognized as a valid additional check in the "son-of-RFC2459". > I know this is at odds with RFC2459, but as this behaviour does > not in our view cause a security problem, but does make the > overall process more robust, we have and will continue to opt for > the more robust solution. It seems to early at this stage to conclude that there are no security problems with such an approach (there are not enough information at this stage to make any conclusion). Just a remainder. The basic principle is the following: it is not because a CA certificate exists that it should be trusted. Denis > I have also posted previously on the list that mandating name > chaining, in addition to signatures and policy chaining is a bad > idea. > > Trevor > > -----Original Message----- > From: denis.bider@siol.net [mailto:denis.bider@siol.net] > Sent: Sunday, June 04, 2000 11:19 AM > To: ietf-pkix@imc.org > Subject: Correct approach to certificate validation? > > Now, based on my previous message, my question for this workgroup: > > Which of these approaches is correct? > - the approach of IE5 and Outlook, which, if an Authority Key > Identifier > extension is present, does not perform a comparison of the > issuer-DN in the > subject-cert to the subject-DN of the root-cert? > - or the approach of Netscape and IIS4, which, even if an > Authority Key > Identifier extension is present, DOES still perform a comparison > of the > subject-cert-issuer-DN to the root-cert-subject-DN? > > Regards, > > denis bider > > PS. I would like to thank Ace Swerling from Microsoft Consulting > Services > for the fact that he bothered to look into my problem, and > especially to > Peter Williams from Valicert who devoted much of his time to help > me solve > this issue. I appreciate your feedback very much. > > -----Original Message----- > From: denis bider [mailto:denis@denisbider.com] On Behalf Of > denis.bider@siol.net > Sent: Sunday, June 04, 2000 20:08 > To: 'ietf-pkix@imc.org' > Subject: Report - certificate validation in IE5, Outlook, > IIS4, Netscape > 4.72 > > Hello, > > a while ago I sent to this list an enquiry regarding Microsoft's > certificate > validation code in IIS4. I have now resolved the problem that was > the reason > for my enquiry. Since the solution to the problem produced some > interesting > insight into how certificate chains are handled in IE5 and Outlook > / IIS4 > and Netscape, and since the behavior in question should be covered > by > RFC2459, but does not seem to be, I am forwarding my findings to > you. > > I produced my own certificate generating utility, the intention of > which was > to generate certificates which could be used by IE5 to login into > an > SSL-protected web site running on IIS4. My problem was that, > although IE5 > claimed my root-cert/subject-cert certificate chain to be valid, > and > although Outlook properly signed and verified messages signed by > these > certificates, IIS4 rejected all attempts to use the subject > certificate for > SSL client authentication. Also, when the subject certificate was > imported > into Netscape, Netscape didn't even show it as an elligible choice > for SSL > client authentication. > > To sum it up, the problem was that there was a glitch in my code > that caused > the subject-DN in root-cert to be slightly different from the > issuer-DN in > the subject-cert. It seems that the certificate verification code > in IE5 and > Outlook2000 is somewhat easy-going, since both of these products > validated > the pair of certificates as valid (they performed cert-chain > validation > solely on the grounds of the key identifier in the Authority Key > Identifier > extension, they did not compare the sub-cert-issuerDN to the > root-cert-subjectDN). IIS4 and Netscape Communicator, on the other > hand, > seem to have a more stringent policy, since they both rejected > these > certificates. > > denis bider Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA08958 for ; Mon, 5 Jun 2000 23:08:05 -0700 (PDT) From: amir.herzberg@il.ibm.com Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA265246; Tue, 6 Jun 2000 08:15:44 +0200 Received: from d12mta05.de.ibm.com (d12mta05_cs0 [9.165.222.239]) by d12relay01.de.ibm.com (8.8.8m3/NCO v2.07) with SMTP id IAA210996; Tue, 6 Jun 2000 08:15:44 +0200 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12568F6.00226433 ; Tue, 6 Jun 2000 08:15:38 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: "Trevor Freeman" cc: denis.bider@siol.net, ietf-pkix@imc.org Message-ID: Date: Tue, 6 Jun 2000 09:11:21 +0300 Subject: RE: Correct approach to certificate validation? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Trevor says, > We have found that enforcing name chaining in path construction, causes > more problems than it solves. We therefore have reverted to using the > name as just a hint, rather than a critical factor and will as you have > I know this is at odds with RFC2459, but as this behaviour does not in > our view cause a security problem, but does make the overall process > more robust, we have and will continue to opt for the more robust I agree. Names are just one of the potential attributes for the holder of the secret key certified; they should not be used for chaining decisions. Also the use of names for access control is dangerous, as the policy makers may not realize that the names are not necessarily secure and they must depend on the proper chain of trust. Best, Amir Herzberg Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA25000 for ; Mon, 5 Jun 2000 20:20:03 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVP00GA6QU60D@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Mon, 5 Jun 2000 20:25:18 -0700 (PDT) Date: Mon, 05 Jun 2000 20:25:38 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: Denis Pinkas Cc: "'ietf-pkix@imc.org'" Message-id: <393C6F32.C7B0BEF8@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <852568F2.0050472B.00@D51MTA04.pok.ibm.com> <393BA827.6487CB21@bull.net> Denis Pinkas wrote: > I propose that we all look back > at the definition we have in the current document. > > " By adding the XXXX value to the GeneralizedTime, an upper limit of > the time at which the timestamp has been created by the TSA can be > obtained. In the same way, by subtracting the XXXX to the > GeneralizedTime, a lower limit of the time at which the timestamp > has been created by the TSA can be obtained." > > The single remaining question is how do you call XXXX, while > sticking to THIS definition. It is currently called "accuracy". If > this term is not adequate, please make a proposal. I would like to > close this issue soon. > Dennis: The question is not so much what it is called (even though it would be nice to use an already accepted name for it) but that THIS definition is broken. Pls see the former emails. So, one should not stick to THIS definition. Cheers, Ed Gerck Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA21014 for ; Mon, 5 Jun 2000 19:51:22 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Jun 2000 18:58:33 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Mon, 5 Jun 2000 19:06:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Content-Class: urn:content-classes:message Subject: RE: Correct approach to certificate validation? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCF5B.E53BE647" Date: Mon, 5 Jun 2000 19:06:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Correct approach to certificate validation? Thread-Index: Ab/OUXENZWU7kKKKSiGW3PjfnPmrlwBBTGGg From: "Trevor Freeman" To: Cc: X-OriginalArrivalTime: 06 Jun 2000 02:06:59.0099 (UTC) FILETIME=[E59E3EB0:01BFCF5B] This is a multi-part message in MIME format. ------_=_NextPart_001_01BFCF5B.E53BE647 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Denis, We have found that enforcing name chaining in path construction, causes more problems than it solves. We therefore have reverted to using the name as just a hint, rather than a critical factor and will as you have found, use a certificate signed with the right key as a valid parent in that chain. This applies to intermediate as well as self signed certificates. We have seen customer scenarios where you need to deliberately build certificates which don't chain on names so enforcing name chaining would cause problems.=20 I know this is at odds with RFC2459, but as this behaviour does not in our view cause a security problem, but does make the overall process more robust, we have and will continue to opt for the more robust solution.=20 I have also posted previously on the list that mandating name chaining, in addition to signatures and policy chaining is a bad idea. Trevor -----Original Message----- From: denis.bider@siol.net [mailto:denis.bider@siol.net] Sent: Sunday, June 04, 2000 11:19 AM To: ietf-pkix@imc.org Subject: Correct approach to certificate validation? Now, based on my previous message, my question for this workgroup: Which of these approaches is correct? - the approach of IE5 and Outlook, which, if an Authority Key Identifier extension is present, does not perform a comparison of the issuer-DN in the subject-cert to the subject-DN of the root-cert? - or the approach of Netscape and IIS4, which, even if an Authority Key Identifier extension is present, DOES still perform a comparison of the subject-cert-issuer-DN to the root-cert-subject-DN? Regards, denis bider PS. I would like to thank Ace Swerling from Microsoft Consulting Services for the fact that he bothered to look into my problem, and especially to Peter Williams from Valicert who devoted much of his time to help me solve this issue. I appreciate your feedback very much. -----Original Message----- From: denis bider [mailto:denis@denisbider.com] On Behalf Of denis.bider@siol.net Sent: Sunday, June 04, 2000 20:08 To: 'ietf-pkix@imc.org' Subject: Report - certificate validation in IE5, Outlook, IIS4, Netscape 4.72 Hello, a while ago I sent to this list an enquiry regarding Microsoft's certificate validation code in IIS4. I have now resolved the problem that was the reason for my enquiry. Since the solution to the problem produced some interesting insight into how certificate chains are handled in IE5 and Outlook / IIS4 and Netscape, and since the behavior in question should be covered by RFC2459, but does not seem to be, I am forwarding my findings to you. I produced my own certificate generating utility, the intention of which was to generate certificates which could be used by IE5 to login into an SSL-protected web site running on IIS4. My problem was that, although IE5 claimed my root-cert/subject-cert certificate chain to be valid, and although Outlook properly signed and verified messages signed by these certificates, IIS4 rejected all attempts to use the subject certificate for SSL client authentication. Also, when the subject certificate was imported into Netscape, Netscape didn't even show it as an elligible choice for SSL client authentication. To sum it up, the problem was that there was a glitch in my code that caused the subject-DN in root-cert to be slightly different from the issuer-DN in the subject-cert. It seems that the certificate verification code in IE5 and Outlook2000 is somewhat easy-going, since both of these products validated the pair of certificates as valid (they performed cert-chain validation solely on the grounds of the key identifier in the Authority Key Identifier extension, they did not compare the sub-cert-issuerDN to the root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand, seem to have a more stringent policy, since they both rejected these certificates. denis bider ------_=_NextPart_001_01BFCF5B.E53BE647 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Correct approach to certificate validation?

Hi Denis,
We have found that enforcing name chaining in path = construction, causes more problems than it solves. We therefore have = reverted to using the name as just a hint, rather than a critical factor = and will as you have found, use a certificate signed with the right key = as a valid parent in that chain. This applies to intermediate as well as = self signed certificates. We have seen customer scenarios where you need = to deliberately build certificates which don't chain on names so = enforcing name chaining would cause problems.

I know this is at odds with RFC2459, but as this = behaviour does not in our view cause a security problem, but does make = the overall process more robust, we have and will continue to opt for = the more robust solution.

I have also posted previously on the list that = mandating name chaining, in addition to signatures and policy chaining = is a bad idea.

Trevor

-----Original Message-----
From: denis.bider@siol.net [mailto:denis.bider@siol.net]
Sent: Sunday, June 04, 2000 11:19 AM
To: ietf-pkix@imc.org
Subject: Correct approach to certificate = validation?


Now, based on my previous message, my question for = this workgroup:

Which of these approaches is correct?
  - the approach of IE5 and Outlook, which, if = an Authority Key Identifier
extension is present, does not perform a comparison = of the issuer-DN in the
subject-cert to the subject-DN of the = root-cert?
  - or the approach of Netscape and IIS4, which, = even if an Authority Key
Identifier extension is present, DOES still perform a = comparison of the
subject-cert-issuer-DN to the = root-cert-subject-DN?

Regards,

denis bider

PS. I would like to thank Ace Swerling from Microsoft = Consulting Services
for the fact that he bothered to look into my = problem, and especially to
Peter Williams from Valicert who devoted much of his = time to help me solve
this issue. I appreciate your feedback very = much.


 -----Original Message-----
From:   denis bider [mailto:denis@denisbider.com]&nbs= p; On Behalf Of
denis.bider@siol.net
Sent:   Sunday, June 04, 2000 20:08
To:     = 'ietf-pkix@imc.org'
Subject:        = Report - certificate validation in IE5, Outlook, IIS4, Netscape
4.72

Hello,

a while ago I sent to this list an enquiry regarding = Microsoft's certificate
validation code in IIS4. I have now resolved the = problem that was the reason
for my enquiry. Since the solution to the problem = produced some interesting
insight into how certificate chains are handled in = IE5 and Outlook / IIS4
and Netscape, and since the behavior in question = should be covered by
RFC2459, but does not seem to be, I am forwarding my = findings to you.

I produced my own certificate generating utility, the = intention of which was
to generate certificates which could be used by IE5 = to login into an
SSL-protected web site running on IIS4. My problem = was that, although IE5
claimed my root-cert/subject-cert certificate chain = to be valid, and
although Outlook properly signed and verified = messages signed by these
certificates, IIS4 rejected all attempts to use the = subject certificate for
SSL client authentication. Also, when the subject = certificate was imported
into Netscape, Netscape didn't even show it as an = elligible choice for SSL
client authentication.

To sum it up, the problem was that there was a glitch = in my code that caused
the subject-DN in root-cert to be slightly different = from the issuer-DN in
the subject-cert. It seems that the certificate = verification code in IE5 and
Outlook2000 is somewhat easy-going, since both of = these products validated
the pair of certificates as valid (they performed = cert-chain validation
solely on the grounds of the key identifier in the = Authority Key Identifier
extension, they did not compare the sub-cert-issuerDN = to the
root-cert-subjectDN). IIS4 and Netscape Communicator, = on the other hand,
seem to have a more stringent policy, since they both = rejected these
certificates.

denis bider

------_=_NextPart_001_01BFCF5B.E53BE647-- Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA01034 for ; Mon, 5 Jun 2000 18:04:13 -0700 (PDT) Received: from [171.78.60.24] ([171.78.60.24]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id VAA22779; Mon, 5 Jun 2000 21:11:52 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <27FF4FAEA8CDD211B97E00902745CBE235E2A9@seine.valicert.com> References: <27FF4FAEA8CDD211B97E00902745CBE235E2A9@seine.valicert.com> Date: Mon, 5 Jun 2000 19:16:09 -0400 To: Peter Williams From: Stephen Kent Subject: RE: SubjectAltName verification Cc: "'Denis Pinkas'" , ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Peter, >Denis, > >The mandatory operational policy element >that was advocated by one co-chair based >off of your suggestion is potentially >very damaging to the current Internet PKI, >as we who built what individual users can >use, know it. Please reconsider your text, given >how others may apply it, carefully. The claim that this text would be "{very damaging to the current Internet PKI" is an overstatement, at best. See below for details. > >Based on Al's and Steve's replies >to my deliberately contentious policy >scenario, we can now apply the interpretive >principles established as community standards. That >exercise showed clearly that naming verification >policy is not only now mandatory on PKIX CAs, but >which policies are conforming is determined by PKIX. >The conformance testing procedure is unspecified >in the text, but none the less it evidently >exists - as a subjective process. I think most people have an informal understanding of what it means to verify information in a cert, even allowing for latitude in a CA's policy on the extent and nature of the verification. I agree that we can debate the details of this forever, especially considering past experience with analogous topics on this list. > >Lets apply >the principles to VeriSign's branded services, to >see the ramifications. > >Some or all of VeriSign's Class 1 offering >of its Public Certification Service(s) is/are >apparently no longer PKIX-conforming, if one applies >the conformance principles now proposed by Steve. It >was conforming, last week. (A "national" >ie governmental CA service to residents also suddenly >became non-conforming last week, also, because >of other subtle tweaks) VeriSign Class 1 certs have been non-conforming in several respects in the past, e.g., the insertion of e-mail addresses into CN attributes. Maybe this, and other practices have ceased; I don't know. Are you seriously saying that that Class 1 certs from VeriSign would be completely PKIX compliant if only we paid not attention to the procedures used to verify the accuracy of their contents? Maybe. But, if so, what are they worth (vs. what do they cost)? > >Goto a formal certificate repository >https://digitalid.verisign.com/services/client/index.html >and perform the instructions. Type in >peterw@valicert.com, and see (apparently) >that a certificate is recorded, with "pending" >status. The common name is "No Such Agency" >and an unverified email address exists >in the name form selected by VeriSign. That sounds like a good example of what one would NOT want in a certificate. Are you sure you're arguing against my position :-)? Still, you seem to have jumped to a conclusion, based on just this example. > >To be fair to VeriSign, I have not completed >all procedures. To complete, someone >must send a challenge-response pin sent >to peterw@valicert.com to VeriSign to >verify that such email account-name exists. >(This is apparently a non-conforming >verification event.) Says who? The point I, and several others are trying to make, is that it is negligent for a CA to include data in a cert without making some effort to verify that data, either directly or via some RA(s). Also, if sending the challenge to the e-mail address does not complete the registration procedure, but rather the recipient must respond, then that does represent some effort at verification. It's not perfect, but it is a credible effort for a low assurance certificate, IF the Subject name or Subject alt name is an e-mail address. If it's some pseudo DN, then NO, this does not count as verification. >The resulting certificate binds one legally >to certain digital signatures, according >to the governing policy. Personally I'm not comfortable with that, because the level of verification is pretty low, but that's just my opinion, and it's one reason I'm not a VeriSign Class 1 certificate holder. (Another reason is that it doesn't seem to be a very useful thing to have, i.e., I don't seem to have much use for one of those certs, personally.) > >VeriSign PCS's Class 1 Service is apparently >(suddenly) no longer conforming with PKIX, under >any interpretion of the new mandatory >policy language concerning name field >verification > >This seems an excessive impact of your >suggestion. I, as one of its co-designers, would >like to include VeriSign PCS's current Class 1 >offering within the PKIX family of conforming CAs. There may be other reasons that it is non-conforming, e.g., other attributes for which VeriSign makes no effort to verify the data, but what you cited above would not rule it out based on the proposed text (if the other constraints I cited above were not violated). Steve Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25149 for ; Mon, 5 Jun 2000 14:54:01 -0700 (PDT) Received: from rhousley_laptop.spyrus.com (russ-35.spyrus.com [207.212.35.226]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id PAA09465; Mon, 5 Jun 2000 15:01:38 -0700 (PDT) Message-Id: <4.2.0.58.20000605130421.00a52160@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 05 Jun 2000 13:09:05 -0400 To: From: Russ Housley Subject: Re: Report - certificate validation in IE5, Outlook, IIS4, Netscape 4.72 Cc: In-Reply-To: <000501bfce4f$df1421c0$0201010a@1div0.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Denis: I do not belive that RFC 2459 is silent on this subject. See 6.1, path processing action (a) (4). Russ At 08:08 PM 06/04/2000 +0200, denis.bider@siol.net wrote: >Hello, > >a while ago I sent to this list an enquiry regarding Microsoft's certificate >validation code in IIS4. I have now resolved the problem that was the reason >for my enquiry. Since the solution to the problem produced some interesting >insight into how certificate chains are handled in IE5 and Outlook / IIS4 >and Netscape, and since the behavior in question should be covered by >RFC2459, but does not seem to be, I am forwarding my findings to you. > >I produced my own certificate generating utility, the intention of which was >to generate certificates which could be used by IE5 to login into an >SSL-protected web site running on IIS4. My problem was that, although IE5 >claimed my root-cert/subject-cert certificate chain to be valid, and >although Outlook properly signed and verified messages signed by these >certificates, IIS4 rejected all attempts to use the subject certificate for >SSL client authentication. Also, when the subject certificate was imported >into Netscape, Netscape didn't even show it as an elligible choice for SSL >client authentication. > >To sum it up, the problem was that there was a glitch in my code that caused >the subject-DN in root-cert to be slightly different from the issuer-DN in >the subject-cert. It seems that the certificate verification code in IE5 and >Outlook2000 is somewhat easy-going, since both of these products validated >the pair of certificates as valid (they performed cert-chain validation >solely on the grounds of the key identifier in the Authority Key Identifier >extension, they did not compare the sub-cert-issuerDN to the >root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand, >seem to have a more stringent policy, since they both rejected these >certificates. > >denis bider Received: from keyon.ch ([194.148.57.155]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA23670 for ; Mon, 5 Jun 2000 13:32:19 -0700 (PDT) Received: (qmail 19391 invoked from network); 5 Jun 2000 20:45:29 -0000 Received: from www.keyon.ch (194.148.57.155) by www.keyon.ch with QMTP; 5 Jun 2000 20:45:29 -0000 Received: (qmail 888 invoked from network); 5 Jun 2000 20:39:06 -0000 Received: from ebe.keyon.ch (HELO ebe) (192.168.0.12) by homer.keyon.ch with SMTP; 5 Jun 2000 20:39:06 -0000 From: "Rene G. Eberhard (keyon)" To: "A.Lakshminarayanan" , Subject: RE: WTLS Certificate format.... Date: Mon, 5 Jun 2000 22:41:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200006050933.RAA00918@phantom.krdl.org.sg> > Hi, > > I am looking for specs on the WTLS Certificate format. Is it > publicly available? Is it similar to the format specified by the PKIX > working group? Are there any similarities? Take a look at http://www.wapforum.org/what/technical.htm and read the latest WTLS document. You may also take a look at www.freecerts.com which offers free WAP certificates for testing purposes. We also offer a public accessible WTLS secured WAPGateway for testing purposes. We run our keyon / WTLSGateway with kannel as WAP Gateway on our internet server at 194.148.57.155. The Nokia 7110 will connect secure just fine and you can download the root certificate at www.freecerts.com. Note that you cannot "escape" our web server but you can display the security parameters of the connection which is quite interesting. This does also work with the Nokia 1.3b 7110 simulator btw. I hope your firewall (if there's any) supports UDP maskerading for accessing our services.... Kind regards Rene Eberhard -- Rene G. Eberhard keyon Herrenberg 35, CH-8640 Rapperswil, Switzerland Phone +41 (0)55 220 71 63, Fax +41 (0)55 220 71 61 www.keyon.ch - applying security to your e-business Get your WAP certificate for free: www.freecerts.com Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22720 for ; Mon, 5 Jun 2000 12:38:38 -0700 (PDT) Received: by balinese.baltimore.ie; id UAA15998; Mon, 5 Jun 2000 20:46:48 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma015990; Mon, 5 Jun 00 20:45:57 +0100 Received: from baltimore.ie ([192.168.20.133]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id UAA18903; Mon, 5 Jun 2000 20:45:54 +0100 Message-ID: <393C03A8.A0F228B4@baltimore.ie> Date: Mon, 05 Jun 2000 20:46:48 +0100 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: borges@sibs.pt CC: ietf-pkix@imc.org Subject: Re: Attribute Certificate Request References: <393B90DA.D09A0005@sibs.pt> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pedro, Since the use cases for ACs aren't as well understood as for public key certificates, there is, as yet, no equivalent to CMP/CMC for AC requests. I would expect that, in future, we might get around to writing one. Meanwhile, there is draft-ietf-pkix-laap-00.txt which describes an alternative to LDAP for AC retrieval, though this deliberately doesn't try to provide the equivalent of a CMP certification request. Regards, Stephen. Pedro Miguel Pereira Borges wrote: > > Hi all, > > I'm currently reading the "An Internet Attribute Certificate Profile > for Authorization" draft... > However, there is a question that I would like to see answered: is > there a definition (ASN.1 or not) of what an attribute certificate request > should contain like there is one for the "normal" X.509 ID certificates ? > > Thanks in advance, > > Pedro Borges -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 647 7406 61 Fitzwilliam Lane, fax: +353 1 647 7499 Dublin 2. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16400 for ; Mon, 5 Jun 2000 08:56:23 -0700 (PDT) Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Mon, 05 Jun 00 17:17:30 +0100 X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2 Received: by BJEX1 with Internet Mail Service (5.5.2448.0) id ; Mon, 5 Jun 2000 16:58:42 +0100 Message-ID: <608D67882786D211B1070090271E4CB990AC1F@BJEX1> From: "Alan Shepherd" To: "'ietf-pkix@imc.org'" Subject: RE: Protocol Action: Diffie-Hellman Proof-of-Possession Algorithm s to Proposed Standard Date: Mon, 5 Jun 2000 16:58:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-WSS-ID: 15250D1099050-01-01 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Please forgive me if this is a terribly naive question, but I would like to know what problems arise if a public key is certified erroneously. I can not see what security problems arise through this and would very much appreciate someone wiser explaining it! Thanks for you help. Alan > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: 31 May 2000 14:03 > Cc: RFC Editor; RFC Editor; RFC Editor > Subject: Protocol Action: Diffie-Hellman Proof-of-Possession > Algorithms > to Proposed Standard > > > > > The IESG has approved the Internet-Draft 'Diffie-Hellman > Proof-of-Possession Algorithms' as a > Proposed Standard. This document is the product of the Public-Key > Infrastructure (X.509) Working Group. The IESG contact persons are > Jeffrey Schiller and Marcus Leech. > > > > Technical Summary > > One of the important requirements in cryptographic protocols is the > ability for an entity to prove they have possession of a particular > key. In particular, Certifying Authorities prior to the > issuance of a > certificate, need to prove that the entity for which the certificate > will be issued in fact does have the private key that corresponds to > the public key which is included in the certificate. > > The traditional approach used with public key encryption > systems such > as the RSA system is to have the challenger require the entity > holding a given private key to sign a challenge string. > > However the Diffie-Hellman (DH) algorithm does not directly lend > itself to providing such signatures, as it is at heart a key > agreement algorithm. This document describes two methods for > producing a signature from a Diffie-Hellman key pair. > > Working Group Summary > > Consensus was reached on the approach used in this document. > > Protocol Quality > > Jeffrey I. Schiller reviewed this document for the IESG. Furthermore > the PKIX Working Group contains members with significant > cryptographic experience who also have reviewed this document. > > Note to RFC Editor: > > There were some word-wrapping problems introduced in Appendix A of > the document that need to be corrected: > > Appendix A: > > OLD: > DH-Sign DEFINITIONS IMPLICIT TAGS ::= > > BEGIN > --EXPORTS ALL > -- The types and values defined in this module are exported for use > in > -- the other ASN.1 modules. Other applications may use them for > their > -- own purposes. > > NEW/FIXED: > DH-Sign DEFINITIONS IMPLICIT TAGS ::= > > BEGIN > --EXPORTS ALL > -- The types and values defined in this module are exported for use > -- in the other ASN.1 modules. Other applications may use them > -- for their own purposes. > ------------------------------------------------------------------------------------------ This message is for the named person’s use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Received: from sch1p218.cna.com (sch1p218.cna.com [159.10.4.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12375 for ; Mon, 5 Jun 2000 06:51:31 -0700 (PDT) Received: from wch1xi04.cna.com (wch1xi04.cna.com [10.20.21.170]) by sch1p218.cna.com (8.9.3/8.9.3) with SMTP id IAA01974 for ; Mon, 5 Jun 2000 08:58:15 -0500 (CDT) Received: from 10.20.23.108 by wch1xi04.cna.com (InterScan E-Mail VirusWall NT); Mon, 05 Jun 2000 08:58:44 -0500 (Central Daylight Time) Received: from 127.0.0.1 by wch1xi02.cna.com (InterScan E-Mail VirusWall NT); Mon, 05 Jun 2000 08:58:44 -0500 (Central Daylight Time) Received: by wch1xi02.cna.com with Internet Mail Service (5.5.2448.0) id <25A52MX6>; Mon, 5 Jun 2000 08:58:44 -0500 Message-ID: <455F017ED470D211815B00805F6F32CD060404F7@wch1xp01.cna.com> From: "Sikac,John E.(NXI)" To: "'ietf-pkix@imc.org'" Subject: UNSUBSCRIBE Date: Mon, 5 Jun 2000 08:58:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain UNSUBSCRIBE Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11764 for ; Mon, 5 Jun 2000 06:08:26 -0700 (PDT) Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA42690; Mon, 5 Jun 2000 15:16:23 +0200 Message-ID: <393BA827.6487CB21@bull.net> Date: Mon, 05 Jun 2000 15:16:23 +0200 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: tgindin@us.ibm.com, "Manger, James H" CC: "'ietf-pkix@imc.org'" Subject: Re: TSA Response serialNumber Field References: <852568F2.0050472B.00@D51MTA04.pok.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have not followed all the rational for using or not using Chebyshev's inequality and since a relying party will NOT be happy with a 95% confidence (nor 99,99%), I propose that we all look back at the definition we have in the current document. " By adding the XXXX value to the GeneralizedTime, an upper limit of the time at which the timestamp has been created by the TSA can be obtained. In the same way, by subtracting the XXXX to the GeneralizedTime, a lower limit of the time at which the timestamp has been created by the TSA can be obtained." The single remaining question is how do you call XXXX, while sticking to THIS definition. It is currently called "accuracy". If this term is not adequate, please make a proposal. I would like to close this issue soon. Denis > One can recast Chebyshev's inequality from > Pr(|x - mean| >= n * sd) <= 1/n**2 > to > Pr(|x - mean| >= (sd / (1 - c)**.5)) <= (1 - c) > or > Pr(|x - mean| < (sd / (1 - c)**.5)) > c > > Where c is just 1 - 1/n**2. > > If c can be described as a confidence level, this answers your > question 2) below. I am not sure that one would describe c here as a > confidence level, but I think it's reasonable to say that if one has > probability > C that a measurement actually lies within a range R, then one > has at least confidence C that the measurement lies within that range. > > Tom Gindin > > "Manger, James H" on 06/02/2000 01:13:25 > AM > > To: "'ietf-pkix@imc.org'" > cc: > Subject: RE: TSA Response serialNumber Field > > Thanks Ed, > > (snip) > > If a relying party is happy with a 95% confidence interval it does not need > to know the exact distribution. If a relying party wants a better > confidence level than the standard specifies (e.g. 99.7% instead of 95%) it > has a couple of choices: > (1) assume, say, a normal distribution and adjust the uncertainty > accordingly (e.g. multiple by 3/2); or > (2) use Chebyshev's inequality to get an upper bound of the required > adjustment [can Chebyshev's inequality be reformulated for this, i.e. for > confidence levels (e.g. 95%) instead of standard deviations (e.g. 2 sd)?]; > or > (3) determine the actual distribution from the TSA's policy document and > adjust the uncertainty by the amount appropriate to that distribution. > We can leave the choice to the relying party. Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA09584 for ; Mon, 5 Jun 2000 04:28:11 -0700 (PDT) Received: (qmail 20431 invoked from network); 5 Jun 2000 11:30:11 -0000 Received: from unknown (HELO sibs.pt) (195.138.0.90) by mail0.sibs.pt with SMTP; 5 Jun 2000 11:30:11 -0000 Message-ID: <393B90DA.D09A0005@sibs.pt> Date: Mon, 05 Jun 2000 12:36:58 +0100 From: Pedro Miguel Pereira Borges Reply-To: borges@sibs.pt Organization: SIBS X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Attribute Certificate Request References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I'm currently reading the "An Internet Attribute Certificate Profile for Authorization" draft... However, there is a question that I would like to see answered: is there a definition (ASN.1 or not) of what an attribute certificate request should contain like there is one for the "normal" X.509 ID certificates ? Thanks in advance, Pedro Borges Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08435 for ; Mon, 5 Jun 2000 03:38:53 -0700 (PDT) From: amir.herzberg@il.ibm.com Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id MAA69202 for ; Mon, 5 Jun 2000 12:46:26 +0200 Received: from d12mta05.de.ibm.com (d12mta05_cs0 [9.165.222.239]) by d12relay01.de.ibm.com (8.8.8m3/NCO v2.07) with SMTP id MAA229242 for ; Mon, 5 Jun 2000 12:46:26 +0200 Received: by d12mta05.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C12568F5.003B2CAC ; Mon, 5 Jun 2000 12:46:20 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: lux@krdl.org.sg (A.Lakshminarayanan) cc: ietf-pkix@imc.org Message-ID: Date: Mon, 5 Jun 2000 13:48:52 +0300 Subject: Re: WTLS Certificate format.... Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Lux asked, > I am looking for specs on the WTLS Certificate format. Is it > publicly available? Is it similar to the format specified by the PKIX > working group? Are there any similarities? Look at http://www.wapforum.org/what/technical.htm Do `find` for WTLS. btw, some other security stuff as well at that page. I think the format takes a lot from PKIX but judge for yourself... Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com Received: from krdl.org.sg (IDENT:root@rodin.krdl.org.sg [192.122.139.27]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA05065 for ; Mon, 5 Jun 2000 02:27:20 -0700 (PDT) Received: from mailhost.krdl.org.sg (mailhost [192.122.134.30]) by krdl.org.sg (8.9.3/8.9.3) with ESMTP id RAA09940 for ; Mon, 5 Jun 2000 17:43:48 +0800 Received: from phantom.krdl.org.sg (phantom [192.122.136.237]) by mailhost.krdl.org.sg (8.9.3/8.9.3) with SMTP id RAA02470 for ; Mon, 5 Jun 2000 17:34:29 +0800 (SGT) Received: by phantom.krdl.org.sg (SMI-8.6/SMI-SVR4) id RAA00918; Mon, 5 Jun 2000 17:33:18 +0800 From: lux@krdl.org.sg (A.Lakshminarayanan) Message-Id: <200006050933.RAA00918@phantom.krdl.org.sg> Subject: WTLS Certificate format.... To: ietf-pkix@imc.org Date: Mon, 5 Jun 2000 17:33:17 +0800 (SGT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am looking for specs on the WTLS Certificate format. Is it publicly available? Is it similar to the format specified by the PKIX working group? Are there any similarities? Cheers Lux Kent Ridge Digital Labs Singapore Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29830 for ; Sun, 4 Jun 2000 11:09:57 -0700 (PDT) Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id UAA08660 for ; Sun, 4 Jun 2000 20:05:08 +0200 From: Sender: "denis bider" To: Subject: Correct approach to certificate validation? Date: Sun, 4 Jun 2000 20:18:43 +0200 Message-ID: <000601bfce51$51752dd0$0201010a@1div0.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Now, based on my previous message, my question for this workgroup: Which of these approaches is correct? - the approach of IE5 and Outlook, which, if an Authority Key Identifier extension is present, does not perform a comparison of the issuer-DN in the subject-cert to the subject-DN of the root-cert? - or the approach of Netscape and IIS4, which, even if an Authority Key Identifier extension is present, DOES still perform a comparison of the subject-cert-issuer-DN to the root-cert-subject-DN? Regards, denis bider PS. I would like to thank Ace Swerling from Microsoft Consulting Services for the fact that he bothered to look into my problem, and especially to Peter Williams from Valicert who devoted much of his time to help me solve this issue. I appreciate your feedback very much. -----Original Message----- From: denis bider [mailto:denis@denisbider.com] On Behalf Of denis.bider@siol.net Sent: Sunday, June 04, 2000 20:08 To: 'ietf-pkix@imc.org' Subject: Report - certificate validation in IE5, Outlook, IIS4, Netscape 4.72 Hello, a while ago I sent to this list an enquiry regarding Microsoft's certificate validation code in IIS4. I have now resolved the problem that was the reason for my enquiry. Since the solution to the problem produced some interesting insight into how certificate chains are handled in IE5 and Outlook / IIS4 and Netscape, and since the behavior in question should be covered by RFC2459, but does not seem to be, I am forwarding my findings to you. I produced my own certificate generating utility, the intention of which was to generate certificates which could be used by IE5 to login into an SSL-protected web site running on IIS4. My problem was that, although IE5 claimed my root-cert/subject-cert certificate chain to be valid, and although Outlook properly signed and verified messages signed by these certificates, IIS4 rejected all attempts to use the subject certificate for SSL client authentication. Also, when the subject certificate was imported into Netscape, Netscape didn't even show it as an elligible choice for SSL client authentication. To sum it up, the problem was that there was a glitch in my code that caused the subject-DN in root-cert to be slightly different from the issuer-DN in the subject-cert. It seems that the certificate verification code in IE5 and Outlook2000 is somewhat easy-going, since both of these products validated the pair of certificates as valid (they performed cert-chain validation solely on the grounds of the key identifier in the Authority Key Identifier extension, they did not compare the sub-cert-issuerDN to the root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand, seem to have a more stringent policy, since they both rejected these certificates. denis bider Received: from levitator.1div0.com ([213.250.43.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29580 for ; Sun, 4 Jun 2000 10:59:37 -0700 (PDT) Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id TAA08632 for ; Sun, 4 Jun 2000 19:54:46 +0200 From: Sender: "denis bider" To: Subject: Report - certificate validation in IE5, Outlook, IIS4, Netscape 4.72 Date: Sun, 4 Jun 2000 20:08:21 +0200 Message-ID: <000501bfce4f$df1421c0$0201010a@1div0.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Hello, a while ago I sent to this list an enquiry regarding Microsoft's certificate validation code in IIS4. I have now resolved the problem that was the reason for my enquiry. Since the solution to the problem produced some interesting insight into how certificate chains are handled in IE5 and Outlook / IIS4 and Netscape, and since the behavior in question should be covered by RFC2459, but does not seem to be, I am forwarding my findings to you. I produced my own certificate generating utility, the intention of which was to generate certificates which could be used by IE5 to login into an SSL-protected web site running on IIS4. My problem was that, although IE5 claimed my root-cert/subject-cert certificate chain to be valid, and although Outlook properly signed and verified messages signed by these certificates, IIS4 rejected all attempts to use the subject certificate for SSL client authentication. Also, when the subject certificate was imported into Netscape, Netscape didn't even show it as an elligible choice for SSL client authentication. To sum it up, the problem was that there was a glitch in my code that caused the subject-DN in root-cert to be slightly different from the issuer-DN in the subject-cert. It seems that the certificate verification code in IE5 and Outlook2000 is somewhat easy-going, since both of these products validated the pair of certificates as valid (they performed cert-chain validation solely on the grounds of the key identifier in the Authority Key Identifier extension, they did not compare the sub-cert-issuerDN to the root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand, seem to have a more stringent policy, since they both rejected these certificates. denis bider Received: from gateway2.ey.com (gateway2.ey.com [199.50.26.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25188 for ; Fri, 2 Jun 2000 13:30:46 -0700 (PDT) Received: by gateway2.ey.com (SMTP Gateway) id QAA28343 for ietf-pkix@imc.org; Fri, 2 Jun 2000 16:38:12 -0400 Message-ID: <200006022038.QAA28343@gateway2.ey.com> Received: by gateway2.ey.com (Protected-side Proxy Mail Agent-1); Fri, 2 Jun 2000 16:38:12 -0400 Date: Fri, 2 Jun 2000 16:23:05 +0100 From: "Christopher R. Ryan" Subject: unsubscribe To: ietf-pkix@imc.org X-Mailer: Worldtalk (NetTalk for Windows NT 4.5-g5)/MIME unsubscribe ******************************************************************************* Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Ernst & Young LLP ******************************************************************************* Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24859 for ; Fri, 2 Jun 2000 13:18:36 -0700 (PDT) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 16:26:02 -0400 Message-ID: <01E1D01C12D7D211AFC70090273D20B10305FDAC@sothmxs06.entrust.com> From: Tim Moses To: "'ietf-pkix@imc.org'" Subject: Criticality marking of the policy mappings extension Date: Fri, 2 Jun 2000 16:26:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Colleagues - I have just reviewed the path processing procedure specified in the certificate and CRL profile Internet draft. I have the following observations. Let's start with very minor ones ... 1. In 6.1.3 (b) it says "If certificate i is not self-issued, verify that the subject name is within one of the permitted_subtrees for X.500 distinguished names, ...". This rule applies to end-user certificates, as well as CA certificates. So, perhaps it should be explicitly stated that a null subject is within all permitted_subtrees, including a null one. 2. There appears to be something missing from 6.1.3 (d) (3). It reads ... "The two nodes at depth i-1 that are marked with an to the resulting tree will cause the node at depth i-2 that is marked with a Y to be deleted." 3. Sub-paras (1) and (2) of 6.1.4 (g) should be indented. 4. Para 6.1.4 (m) should say "If pathLengthConstraint is present in the basic constraints extension of the certificate ..." 5. The reference at the very end of 6.1.4 should be to para 6.1.3, not 6.1.2. 6. The extended path validation described in Para 6.2 deals with the case of multiple trust anchors. In this case it says: "Limitations in the trust path for any particular key may be incorporated into the self-signed certificate's extensions. In this way, the self-signed certificates permit the path validation module to automatically incorporate local security policy and requirements." Setting aside the questions of whether this is a good thing or a bad thing and whether or not it is consistent with X.509. I wonder whether it is appropriate to have different behaviour depending upon the number of trust anchors. 7. The final comment relates to the criticality marking on the policy mappings extension. If an (admittedly non-conformant) client were to encounter a PKIX certificate with a non-critical policy mappings extension, then it could accept the path, when the issuer of the certificate intended it to reject the path. Consider this example. A CA issues a certificate to another CA. The certificate policies extension identifies Policy A, and the non-critical policy mappings extension maps Policy A to Policy B. The other CA issues a certificate under Policy A. The intention of the first CA is that the certificate user would reject this certificate. But, a client that understood certificate policies, but not policy mapping would accept the certificate. Therefore, it should be permissible to mark the policy mappings extension critical. But, this is disallowed by Para 4.2.1.6, which requires the extension to be marked non-critical. The 2000 version of X.509 allows and recommends that the policy mappings extension be marked critical. So, the PKIX profile should make the same recommendation. ---------------------------------------------------------------------------- ----------- Tim Moses Tel: 613.247.3183 Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22110 for ; Fri, 2 Jun 2000 10:06:02 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVJ00IHQE0LY1@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Fri, 2 Jun 2000 10:02:45 -0700 (PDT) Date: Fri, 02 Jun 2000 10:02:49 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: Peter Sylvester Cc: pkoning@xedia.com, James.H.Manger@team.telstra.com, ietf-pkix@imc.org Message-id: <3937E8B9.B546BDDB@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200006020811.KAA06562@emeriau.edelweb.fr> Peter Sylvester wrote: > The question was whether the actual text of requiring a strict monotonically > increasing serial could be replaced by something else or not in order > to allow unique identification, and whether or whether not ordering > among time stamps of one TSA is defined. But the specs were broken, as it is rather obvious now, and what was supposed to be a timestamp was actually a nothing. I guess your examples would be much worse if the TSA did NOT inform the reliability level and did NOT inform the expected distribution, because in such a case instead of saying -- "gee, we may be wrong 5% of the time", the TSA would be saying "gee, we do not know what we are saying". BTW, the only *minor* quibble I still have with Manger is that I do not favor a set reliability level in the standard but we should be making that a variable to be specified by the TSA. The main reason for this is not only to avoid fast obsolescence but also to provide room for improvement. I will not copy again my other arguments, but they are in the archives. Cheers, Ed Gerck PS: I enjoyed your "Dear user of a time stamp " declaration and I have a similar one for digital certificates -- and this is EXACTLY what I am trying to avoid by calling attention to the fact that just supplying what WAS going to be supplied was simply not enough -- as it is clear now after much effort, I suppose. > > > PS Received: from ahmler2.mail.eds.com (ahmler2.mail.eds.com [192.85.154.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17642; Fri, 2 Jun 2000 08:30:08 -0700 (PDT) Received: from ahmlir1.mail.eds.com (ahmlir1-2.mail.eds.com [192.85.154.25]) by ahmler2.mail.eds.com (8.9.3/8.9.3) with ESMTP id LAA23107; Fri, 2 Jun 2000 11:38:02 -0400 (EDT) Received: from ahmlir1.mail.eds.com (localhost [127.0.0.1]) by ahmlir1.mail.eds.com (8.9.3/8.9.3) with ESMTP id LAA07798; Fri, 2 Jun 2000 11:37:31 -0400 (EDT) Received: from usahm006.exmi01.exch.eds.com (usahm006.exmi01.exch.eds.com [207.37.138.146]) by ahmlir1.mail.eds.com (8.9.3/8.9.3) with ESMTP id LAA06614; Fri, 2 Jun 2000 11:36:17 -0400 (EDT) Received: by usahm006.exmi01.exch.eds.com with Internet Mail Service (5.5.2651.32) id ; Fri, 2 Jun 2000 11:36:14 -0400 Message-ID: <3DF5A09BFF4FD2119A2400A02461F0DB0461BAEC@usahm012.exmi01.exch.eds.com> From: "Golod, Alex" To: "'ietf-pkix-request@imc.org'" , "'ietf-pkix@imc.org'" Subject: Would like to subscribe Date: Fri, 2 Jun 2000 11:36:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.32) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFCCA8.48BBF8D6" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFCCA8.48BBF8D6 Content-Type: text/plain; charset="iso-8859-1" Hello, PKI is my area of interest. I would like to subscribe. Please, let me know if I need to do something else to get there. Thanks, Alex Golod (248) 265-6048 <> ------_=_NextPart_000_01BFCCA8.48BBF8D6 Content-Type: application/octet-stream; name="Golod, Alex.vcf" Content-Disposition: attachment; filename="Golod, Alex.vcf" BEGIN:VCARD VERSION:2.1 N:Golod;Aleksander FN:Golod, Alex ORG:EDS;GLOBAL DELIV I.SOLUTIONS TEL;WORK;VOICE:001 248 265 6048 TEL;WORK;VOICE:8 365 6048 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;AUTHENTICATION/ENCRYPTION SECURI 266112;4198=0D=0A800 TOWER DR=0D=0A;TROY;M= I;48098;US LABEL;WORK;ENCODING=QUOTED-PRINTABLE:AUTHENTICATION/ENCRYPTION SECURI 266112=0D=0A4198=0D=0A800 TOWER DR=0D=0A= =0D=0ATROY, MI 48098=0D=0AUS EMAIL;PREF;INTERNET:alex.golod@exmi01.exch.eds.com REV:20000518T131425Z END:VCARD ------_=_NextPart_000_01BFCCA8.48BBF8D6-- Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14578 for ; Fri, 2 Jun 2000 07:41:57 -0700 (PDT) Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 07:44:28 -0700 Message-ID: <27FF4FAEA8CDD211B97E00902745CBE2D7A456@seine.valicert.com> From: Boulos Dib To: "'denis.bider@siol.net'" Cc: ietf-pkix@imc.org Subject: RE: Microsoft Date: Fri, 2 Jun 2000 07:44:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Denis, I take it you need to understand how IIS and Outlook perform certification path validation which includes certificate status checking. If you need to learn more path validation in general, RFC2459 is the official document. PKIX uses the term validation not verification and RFC2459 section 6 defines the details of certification path validation. I am not an expert on the internals of IIS and Outlook, but I understand that they both use Microsoft's CryptoAPI (CAPI) certificate functions. CAPI includes a number of APIs to deal with certificates, certificate stores, and what CAPI calls "Certificate Verification Functions" which use Certificate Revocation Lists (CRLs) and Certificate Trust Lists (CTLs). There is also a way for third party vendors (i.e. Validation Authorities) to plug-in their own implementation of certain APIs to extend the validation to use other protocols such as Online Certificate Status Protocol (OCSP). Check out http://www.valicert.com for information about Email, Web Browser and Web server validators. Microsoft's CryptoAPI documentation is available online on MSDN http://msdn.microsoft.com/library/psdk/crypto/portalapi_3351.htm I hope the above helps to get you started. Boulos. -----Original Message----- From: denis.bider@siol.net [mailto:denis.bider@siol.net] Sent: Wednesday, May 31, 2000 6:42 PM To: ietf-pkix@imc.org Subject: Microsoft Hello, I am developing a certificate-generating application that will be employed in a Microsoft-based environment. I am looking from someone in Microsoft who has the technical insight about how certificate verification has been implemented in IIS, and perhaps also Microsoft Outlook. Is there, perhaps, someone who is reading this list who would know something about this, or someone who would have the appropriate contacts? If so, I would be much obliged if you could send me an email. Kind regards, denis bider Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14198 for ; Fri, 2 Jun 2000 07:29:07 -0700 (PDT) From: tgindin@us.ibm.com Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA56378; Fri, 2 Jun 2000 10:35:15 -0400 Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay01.pok.ibm.com (8.8.8m3/NCO v2.07) with SMTP id KAA104256; Fri, 2 Jun 2000 10:37:00 -0400 Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568F2.005047BE ; Fri, 2 Jun 2000 10:36:52 -0400 X-Lotus-FromDomain: IBMUS To: "Manger, James H" cc: "'ietf-pkix@imc.org'" Message-ID: <852568F2.0050472B.00@D51MTA04.pok.ibm.com> Date: Fri, 2 Jun 2000 10:36:50 -0400 Subject: RE: TSA Response serialNumber Field Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline One can recast Chebyshev's inequality from Pr(|x - mean| >= n * sd) <= 1/n**2 to Pr(|x - mean| >= (sd / (1 - c)**.5)) <= (1 - c) or Pr(|x - mean| < (sd / (1 - c)**.5)) > c Where c is just 1 - 1/n**2. If c can be described as a confidence level, this answers your question 2) below. I am not sure that one would describe c here as a confidence level, but I think it's reasonable to say that if one has probability > C that a measurement actually lies within a range R, then one has at least confidence C that the measurement lies within that range. Tom Gindin "Manger, James H" on 06/02/2000 01:13:25 AM To: "'ietf-pkix@imc.org'" cc: Subject: RE: TSA Response serialNumber Field Thanks Ed, (snip) If a relying party is happy with a 95% confidence interval it does not need to know the exact distribution. If a relying party wants a better confidence level than the standard specifies (e.g. 99.7% instead of 95%) it has a couple of choices: (1) assume, say, a normal distribution and adjust the uncertainty accordingly (e.g. multiple by 3/2); or (2) use Chebyshev's inequality to get an upper bound of the required adjustment [can Chebyshev's inequality be reformulated for this, i.e. for confidence levels (e.g. 95%) instead of standard deviations (e.g. 2 sd)?]; or (3) determine the actual distribution from the TSA's policy document and adjust the uncertainty by the amount appropriate to that distribution. We can leave the choice to the relying party. Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA23937 for ; Fri, 2 Jun 2000 01:03:46 -0700 (PDT) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id KAA22160; Fri, 2 Jun 2000 10:11:28 +0200 (MET DST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 2 Jun 2000 10:11:28 +0200 (MET DST) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id KAA11152; Fri, 2 Jun 2000 10:11:26 +0200 (MET DST) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id KAA06562; Fri, 2 Jun 2000 10:11:25 +0200 (MET DST) Date: Fri, 2 Jun 2000 10:11:25 +0200 (MET DST) Message-Id: <200006020811.KAA06562@emeriau.edelweb.fr> To: pkoning@xedia.com, egerck@nma.com Subject: Re: TSA Response serialNumber Field Cc: James.H.Manger@team.telstra.com, ietf-pkix@imc.org > That is up to each TSA to specify, according to my suggestion. And > I recall that it always makes sense to talk about "mean" and "standard > deviation" for *any* distribution of like things (apples with apples) > -- even if the distribution is not Normal (Gauss). I wonder how the note of the post office etc would look like (flame waring on): Dear user of a time stamp : We are giving you this time stamp, you know, we do our best (95%) to have a good time, but well, it might happen that, so we just tell 95% and then well, if you don't need it better than 1 second, then it is 99% but still there is something left, so we are really sorry, but we can't tell you more, and obviously we do not know how a relying party may interprete this anyway. You know, the background of this is that unfortunately the machine that is reading the atomic clock and the atomic clock are made by unperfect material, it's similar like the 3 of 5687 nails don't have the right size. Actually we look after the values from time to time, so next time, please remember that we highly recommend to arrive at the airport two hours before the plane leaves... A relying party (for example a fiscal authority that verifies whether you met the deadline): - Your declaration is due before midnight. - You've got a time stamp that is shortly (n hours) after midnight ==> no technical decision is made, - A clerk is inspecting your declaration, your previous declarations etc; whether you pay correctly etc., an explanation from you why you think you are late, etc. the clerk obviously has seen the info at the TV which just explained that a huge thunderstorm has destroyed one third of the electric network of the country just during that night. - The cleark acts or doesn't act according the rule that each rule has an exception. > > BTW, just taking a look at the new IETF "glossary" should convince us > that we may have already gone too far in our solipsistic phantasies as we > start to rename that which we ourselves named ;-) Fortunately the dodo in question is marked OPTIONAL, so a TSA doesn't have to implement it at all. One might consider to look back at the Subject of this thread or should one call it threat :-) The question was whether the actual text of requiring a strict monotonically increasing serial could be replaced by something else or not in order to allow unique identification, and whether or whether not ordering among time stamps of one TSA is defined. PS Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA17751 for ; Thu, 1 Jun 2000 23:48:41 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVI00MBGLXZ2N@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 1 Jun 2000 23:56:23 -0700 (PDT) Date: Thu, 01 Jun 2000 23:56:27 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: "Manger, James H" Cc: "'ietf-pkix@imc.org'" Message-id: <39375A9B.313951F8@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <73388857A695D31197EF00508B08F2988A3BC6@ntmsg0131.corpmail.telstra.com.au> James: We are in violent agreement. Cheers, Ed Gerck "Manger, James H" wrote: > Thanks Ed, > > I was ignoring the incorrect labelling of the uncertainty field (hoping the > next draft would fix it). I was assuming the quoted uncertainty was 1 > standard deviation (hoping the next draft would explicitly state this). > > I was assuming the mapping between number of standard deviations and > confidence level was vaguely independent of the exact distribution, at least > independent enough for practical timestamping purposes, so I could use the > mapping that the normal distribution gives. I knew there were some > theoretical bounds on this mapping, though I could not remember the > specifics. I was also assuming that converting from one confidence level to > another was possible (e.g. if uncertainty for 68% confidence level is quoted > just double the uncertainty to get a 95% confidence level). > > After finding a statistics text book.. > > Chebyshev's inequality says the probability of being further than n standard > deviations from the mean is always less than or equal to 1 / n^2, regardless > of the distribution. > Pr(|x - mean| >= n.sd) <= 1/n^2 > > [I think there are some distribution that don't have a finite standard > deviation so Chebyshev's inequality does not hold. I hope this does not > apply to practical distribution for TSA time measurements.] > > Hence the probability that a sample is not within [mean - n.sd, mean + n.sd] > is: > n normal upper bound > 1 32% <= 100% > 2 5% <= 25% > 3 0.3% <= 11% > > Now I can repeat my calculations from my previous e-mail using Cebyshev's > inequality instead of a normal distribution. Instead of calculating the > probability that T2 occurred after T1 the calculation gives an upper bound > on this probability. In that example the upper bound turns out to be 100% > which is useless. This highlights the problem with using Cebyshev's > inequality. It gives a very weak bound, particularly as you get further > from the mean (use a higher confidence level). > > Back to the timestamp standard.. > > For comparing a timestamp to another clock we need time, uncertainty, > confidence level and distribution. Put the time and uncertainty in the > timestamp (as now), put the confidence level in the standard and the > distribution in the TSA's policy document [in future, if required, a policy > qualifier or extension could be added to describe the distribution in the > actual timestamp]. > > The standard could state that the uncertainty field is a given number of > standard deviations (e.g. 2) or a given confidence interval (e.g. 95%). > Previous I suggested the former, but (after reading this thread) I can see > advantages with the latter, though I would be happy either way. Suggested > text (after changing the field name from 'accuracy' to 'uncertainty'): > "The 'uncertainty' value represents the time deviation, in seconds, > between the 'genTime' value and UTC at a 95% confidence level. That is, > there is a 95% chance that the 'genTime' value is within +/-'uncertainty' > seconds of UTC. If the time measurement has a Normal (Gaussian) > Distribution the 'uncertainty' value is approximately 2 standard > deviations." > > If a relying party is happy with a 95% confidence interval it does not need > to know the exact distribution. If a relying party wants a better > confidence level than the standard specifies (e.g. 99.7% instead of 95%) it > has a couple of choices: > (1) assume, say, a normal distribution and adjust the uncertainty > accordingly (e.g. multiple by 3/2); or > (2) use Chebyshev's inequality to get an upper bound of the required > adjustment [can Chebyshev's inequality be reformulated for this, i.e. for > confidence levels (e.g. 95%) instead of standard deviations (e.g. 2 sd)?]; > or > (3) determine the actual distribution from the TSA's policy document and > adjust the uncertainty by the amount appropriate to that distribution. > We can leave the choice to the relying party. Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA17382 for ; Thu, 1 Jun 2000 23:44:50 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVI00L7WLPOHR@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 1 Jun 2000 23:51:25 -0700 (PDT) Date: Thu, 01 Jun 2000 23:51:28 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: William Lattin Cc: Paul Koning , James.H.Manger@team.telstra.com, ietf-pkix@imc.org Message-id: <39375970.9A1843CA@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <000201bfcc25$f7b9abe0$b5cc113f@winnt> William Lattin wrote: > Another place to look for the treatment of time accuracy and deviation is > RFC 1305 - NTP has attempted to deal with these very issues (albeit for NTP > purposes :-)). NTP introduces the concept of dispersion (see Appendix H) > which, I believe, addresses the issues being discussed. No. Appendix H has to do with corrections for delays and offsets in NTP communication paths -- roundtrip delay, synch dispersion, etc. The TSAs timestamps we are talking about have nothing to do with this model -- the timestamps here represent static numbers for which communication delay and synch dispersion is irrelevant after they are issued by the TSA (and before they are issued we as r-ps do not care -- it is the TSA's business). So, not only the issues are different but also the consequences. To our case, what is relevant is a simple question. What does a TSA need to inform together with a timestamp to a relying-party so that the r-p can rely on that timestamp for: (i) a value by itself; (ii) comparison between timestamps from that TSA; and (iii) comparison between timestamps from different TSAs. My suggestion was that the TSDA needs to inform four quantities besides the timestamp itself to the r-p, at least. Otherwise the information may not allow (i), or (ii, or (iii). Cheers, Ed Gerck Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA11365 for ; Thu, 1 Jun 2000 22:09:31 -0700 (PDT) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id PAA11291 for ; Fri, 2 Jun 2000 15:16:42 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdEbHnZ_; Fri Jun 2 15:16:19 2000 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id PAA10036 for ; Fri, 2 Jun 2000 15:16:19 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0GAIId; Fri Jun 2 15:14:03 2000 Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA13703 for ; Fri, 2 Jun 2000 15:14:03 +1000 (EST) Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Jun 2000 15:13:32 +1000 Message-ID: <73388857A695D31197EF00508B08F2988A3BC6@ntmsg0131.corpmail.telstra.com.au> From: "Manger, James H" To: "'ietf-pkix@imc.org'" Subject: RE: TSA Response serialNumber Field Date: Fri, 2 Jun 2000 15:13:25 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Thanks Ed, I was ignoring the incorrect labelling of the uncertainty field (hoping the next draft would fix it). I was assuming the quoted uncertainty was 1 standard deviation (hoping the next draft would explicitly state this). I was assuming the mapping between number of standard deviations and confidence level was vaguely independent of the exact distribution, at least independent enough for practical timestamping purposes, so I could use the mapping that the normal distribution gives. I knew there were some theoretical bounds on this mapping, though I could not remember the specifics. I was also assuming that converting from one confidence level to another was possible (e.g. if uncertainty for 68% confidence level is quoted just double the uncertainty to get a 95% confidence level). After finding a statistics text book.. Chebyshev's inequality says the probability of being further than n standard deviations from the mean is always less than or equal to 1 / n^2, regardless of the distribution. Pr(|x - mean| >= n.sd) <= 1/n^2 [I think there are some distribution that don't have a finite standard deviation so Chebyshev's inequality does not hold. I hope this does not apply to practical distribution for TSA time measurements.] Hence the probability that a sample is not within [mean - n.sd, mean + n.sd] is: n normal upper bound 1 32% <= 100% 2 5% <= 25% 3 0.3% <= 11% Now I can repeat my calculations from my previous e-mail using Cebyshev's inequality instead of a normal distribution. Instead of calculating the probability that T2 occurred after T1 the calculation gives an upper bound on this probability. In that example the upper bound turns out to be 100% which is useless. This highlights the problem with using Cebyshev's inequality. It gives a very weak bound, particularly as you get further from the mean (use a higher confidence level). Back to the timestamp standard.. For comparing a timestamp to another clock we need time, uncertainty, confidence level and distribution. Put the time and uncertainty in the timestamp (as now), put the confidence level in the standard and the distribution in the TSA's policy document [in future, if required, a policy qualifier or extension could be added to describe the distribution in the actual timestamp]. The standard could state that the uncertainty field is a given number of standard deviations (e.g. 2) or a given confidence interval (e.g. 95%). Previous I suggested the former, but (after reading this thread) I can see advantages with the latter, though I would be happy either way. Suggested text (after changing the field name from 'accuracy' to 'uncertainty'): "The 'uncertainty' value represents the time deviation, in seconds, between the 'genTime' value and UTC at a 95% confidence level. That is, there is a 95% chance that the 'genTime' value is within +/-'uncertainty' seconds of UTC. If the time measurement has a Normal (Gaussian) Distribution the 'uncertainty' value is approximately 2 standard deviations." If a relying party is happy with a 95% confidence interval it does not need to know the exact distribution. If a relying party wants a better confidence level than the standard specifies (e.g. 99.7% instead of 95%) it has a couple of choices: (1) assume, say, a normal distribution and adjust the uncertainty accordingly (e.g. multiple by 3/2); or (2) use Chebyshev's inequality to get an upper bound of the required adjustment [can Chebyshev's inequality be reformulated for this, i.e. for confidence levels (e.g. 95%) instead of standard deviations (e.g. 2 sd)?]; or (3) determine the actual distribution from the TSA's policy document and adjust the uncertainty by the amount appropriate to that distribution. We can leave the choice to the relying party. Received: from goose.prod.itd.earthlink.net (goose.prod.itd.earthlink.net [207.217.120.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA10953 for ; Thu, 1 Jun 2000 16:54:49 -0700 (PDT) Received: from winnt (2Cust53.tnt6.sfo1.da.uu.net [63.17.204.181]) by goose.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id RAA09927; Thu, 1 Jun 2000 17:02:20 -0700 (PDT) From: "William Lattin" To: "Ed Gerck" , "Paul Koning" Cc: , Subject: RE: TSA Response serialNumber Field Date: Thu, 1 Jun 2000 17:03:23 -0700 Message-ID: <000201bfcc25$f7b9abe0$b5cc113f@winnt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3936E0E7.AC7B6DF7@nma.com> Another place to look for the treatment of time accuracy and deviation is RFC 1305 - NTP has attempted to deal with these very issues (albeit for NTP purposes :-)). NTP introduces the concept of dispersion (see Appendix H) which, I believe, addresses the issues being discussed. Bill > -----Original Message----- > From: Ed Gerck [mailto:egerck@nma.com] > Sent: Thursday, June 01, 2000 15:17 > To: Paul Koning > Cc: James.H.Manger@team.telstra.com; ietf-pkix@imc.org > Subject: Re: TSA Response serialNumber Field > > > > > Paul Koning wrote: > > > > > Ed> That is up to each TSA to specify, according to my suggestion. > > Ed> And I recall that it always makes sense to talk about "mean" and > > Ed> "standard deviation" for *any* distribution of like things > > Ed> (apples with apples) -- even if the distribution is not Normal > > Ed> (Gauss). > > > > Suppose we define that the timestamp will contain the mean and > > standard deviation. What will that actually tell you? > > > > If you know the distribution (e.g., Normal) you can answer the > > question "with 0.999999 confidence, what are the bounds". With an > > unknown distribution, you cannot do that. So clearly standard > > deviation is not useful. > > Let me recall that you can indeed compare reliability values by using the > standard deviation for statistics other than gaussian (normal). > This shows > why it is useful to include the *four* types of information I > suggested for the > TSA (and not just that "accuracy" -- which is a meaningless number by > itself, and misleadingly named as it was): > > 1. accuracy: that rather arbitrary fine precision that the TSA sets for > its timestamp ordering purposes. > > 2. uncertainty: set and guaranteed by the TSA, as given above. > > 3. reliability: set and guaranteed by the TSA, as given above. > > 4. statistics: set and guaranteed by the TSA, as given above. > > For example ([2] in my posting before), in the case of gaussian > statistics, > 95% reliability corresponds to an uncertainty which is twice the standard > deviation. > > On these matters, to save cyber trees, I looked for some > references on the web > that could help provide some examples for each concept. I found > the ones below, > which can be helpful (I am sure there are many others): > http://bjmath.com/bjmath/Stats/sd.htm http://bjmath.com/bjmath/Stats/sd.htm http://bjmath.com/bjmath/Stats/confide.htm > That leaves two possibilities: > > a. What I suggested before: mean plus bound chosen so the confidence > is "very high". these numbers cannot be taken out of the blue yonder, but must be based on a sound and objective basis -- mean, bound and confidence cannot be arbitrary. Further, "very high" confidence (ie, reliability) may indeed mean 60% in some cases and this may be as good as 99% in other cases -- as I exemplified in my previous posting with 95% and 99%. > b. Mean plus bound plus confidence value -- preferably with the > recommendation that the confidence value should be a number quite > close to 1. (I don't think I want to do business with a TSA that > reports intervals with "confidence 0.68"...) > Would it surprise you to know that a confidence (reliability) level of 68% for an uncertainty of 0.2 s is much better than 99% for an uncertainty of 1 s, in terms of gauss distributions? Further, without specifying to which statistical distribution the value (mean), the uncertainty (bound) and the reliability (confidence) apply to, the TSA is essentially selling snake oil. Let's keep this in mind -- statistics is quite useless unless the terms are well defined, as politics exemplifies all the time ;-) As another example, I wish to recall the case of that guy who drowned in a lake that had one inch depth on average -- he fell in a 40 ft deep hole. Cheers, Ed Gerck Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09708 for ; Thu, 1 Jun 2000 15:16:03 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVH001A5XWT6F@mta5.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 1 Jun 2000 15:17:18 -0700 (PDT) Date: Thu, 01 Jun 2000 15:17:11 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: Paul Koning Cc: James.H.Manger@team.telstra.com, ietf-pkix@imc.org Message-id: <3936E0E7.AC7B6DF7@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <73388857A695D31197EF00508B08F2988A3BC3@ntmsg0131.corpmail.telstra.com.au> <3936BAE1.ECCBB0DD@nma.com> <14646.48754.723416.282742@xedia.com> <3936CC5D.C8F444E3@nma.com> <14646.53892.318970.319672@xedia.com> Paul Koning wrote: > > Ed> That is up to each TSA to specify, according to my suggestion. > Ed> And I recall that it always makes sense to talk about "mean" and > Ed> "standard deviation" for *any* distribution of like things > Ed> (apples with apples) -- even if the distribution is not Normal > Ed> (Gauss). > > Suppose we define that the timestamp will contain the mean and > standard deviation. What will that actually tell you? > > If you know the distribution (e.g., Normal) you can answer the > question "with 0.999999 confidence, what are the bounds". With an > unknown distribution, you cannot do that. So clearly standard > deviation is not useful. Let me recall that you can indeed compare reliability values by using the standard deviation for statistics other than gaussian (normal). This shows why it is useful to include the *four* types of information I suggested for the TSA (and not just that "accuracy" -- which is a meaningless number by itself, and misleadingly named as it was): 1. accuracy: that rather arbitrary fine precision that the TSA sets for its timestamp ordering purposes. 2. uncertainty: set and guaranteed by the TSA, as given above. 3. reliability: set and guaranteed by the TSA, as given above. 4. statistics: set and guaranteed by the TSA, as given above. For example ([2] in my posting before), in the case of gaussian statistics, 95% reliability corresponds to an uncertainty which is twice the standard deviation. On these matters, to save cyber trees, I looked for some references on the web that could help provide some examples for each concept. I found the ones below, which can be helpful (I am sure there are many others): http://bjmath.com/bjmath/Stats/sd.htm http://bjmath.com/bjmath/Stats/sd.htm http://bjmath.com/bjmath/Stats/confide.htm > That leaves two possibilities: > > a. What I suggested before: mean plus bound chosen so the confidence > is "very high". these numbers cannot be taken out of the blue yonder, but must be based on a sound and objective basis -- mean, bound and confidence cannot be arbitrary. Further, "very high" confidence (ie, reliability) may indeed mean 60% in some cases and this may be as good as 99% in other cases -- as I exemplified in my previous posting with 95% and 99%. > b. Mean plus bound plus confidence value -- preferably with the > recommendation that the confidence value should be a number quite > close to 1. (I don't think I want to do business with a TSA that > reports intervals with "confidence 0.68"...) > Would it surprise you to know that a confidence (reliability) level of 68% for an uncertainty of 0.2 s is much better than 99% for an uncertainty of 1 s, in terms of gauss distributions? Further, without specifying to which statistical distribution the value (mean), the uncertainty (bound) and the reliability (confidence) apply to, the TSA is essentially selling snake oil. Let's keep this in mind -- statistics is quite useless unless the terms are well defined, as politics exemplifies all the time ;-) As another example, I wish to recall the case of that guy who drowned in a lake that had one inch depth on average -- he fell in a 40 ft deep hole. Cheers, Ed Gerck Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08802 for ; Thu, 1 Jun 2000 14:08:00 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirtd20806; Thu, 1 Jun 2000 21:15:49 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA07615; Thu, 1 Jun 00 17:12:19 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id RAA04622; Thu, 1 Jun 2000 17:15:48 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14646.53892.318970.319672@xedia.com> Date: Thu, 1 Jun 2000 17:15:48 -0400 (EDT) To: egerck@nma.com Cc: James.H.Manger@team.telstra.com, ietf-pkix@imc.org Subject: Re: TSA Response serialNumber Field References: <73388857A695D31197EF00508B08F2988A3BC3@ntmsg0131.corpmail.telstra.com.au> <3936BAE1.ECCBB0DD@nma.com> <14646.48754.723416.282742@xedia.com> <3936CC5D.C8F444E3@nma.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid >>>>> "Ed" == Ed Gerck writes: Ed> Paul Koning wrote: >> If we had a well defined distribution of the random variable, we >> could talk about mean and standard deviation. But I don't believe >> we do; in particular I do know that it is a mistake to think that >> the distribution is Normal. Ed> That is up to each TSA to specify, according to my suggestion. Ed> And I recall that it always makes sense to talk about "mean" and Ed> "standard deviation" for *any* distribution of like things Ed> (apples with apples) -- even if the distribution is not Normal Ed> (Gauss). Well, I never got very far in that area of Math. Here's why I brought up the issue: Suppose we define that the timestamp will contain the mean and standard deviation. What will that actually tell you? If you know the distribution (e.g., Normal) you can answer the question "with 0.999999 confidence, what are the bounds". With an unknown distribution, you cannot do that. So clearly standard deviation is not useful. That leaves two possibilities: a. What I suggested before: mean plus bound chosen so the confidence is "very high". b. Mean plus bound plus confidence value -- preferably with the recommendation that the confidence value should be a number quite close to 1. (I don't think I want to do business with a TSA that reports intervals with "confidence 0.68"...) paul Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08492 for ; Thu, 1 Jun 2000 13:58:55 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVH00LGXTURLO@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 1 Jun 2000 13:49:39 -0700 (PDT) Date: Thu, 01 Jun 2000 13:49:33 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: Paul Koning Cc: James.H.Manger@team.telstra.com, ietf-pkix@imc.org Message-id: <3936CC5D.C8F444E3@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <73388857A695D31197EF00508B08F2988A3BC3@ntmsg0131.corpmail.telstra.com.au> <3936BAE1.ECCBB0DD@nma.com> <14646.48754.723416.282742@xedia.com> Paul Koning wrote: > Whenever someone creates a discussion like this where "reliability" > and "accuracy" (or, similarly, "accuracy" and "tolerance" or > "accuracy" and "precision") are used with the intent of describing > quite *different* things, alarms go off. ;-) My alarms too -- especially when such terms are used to mean quite *different* things than usage in the corresponding technical field. > If we had a well defined distribution of the random variable, we could > talk about mean and standard deviation. But I don't believe we do; in > particular I do know that it is a mistake to think that the > distribution is Normal. That is up to each TSA to specify, according to my suggestion. And I recall that it always makes sense to talk about "mean" and "standard deviation" for *any* distribution of like things (apples with apples) -- even if the distribution is not Normal (Gauss). > Also, consider the intended usage. One major reason we want to have > TSAs is so we can timestamp information with legally convincing > timestamps. In other words, we want to be able to answer the question > "did T1 occur before T2" well enough that we can stand up in court and > give that answer. Not just here on this list... :-) > That is why we need: (i) to call a dodo a dodo, (ii) to make sure that we are comparing dodos to dodos and not to platipus. Of course, this WG is free to create all sorts of names and concepts de novo, as well as to rename the entire corpus of engineering and law. I suggest this is not in our best interest, though. BTW, just taking a look at the new IETF "glossary" should convince us that we may have already gone too far in our solipsistic phantasies as we start to rename that which we ourselves named ;-) > This gives me a criterion for chosing the bounds I would advertise in > a timestamp: they are chosen reasonably tightly, but such that I am > willing to stand up in court and testify to the effect that an event > timestamped as [t - a .. t + a] did indeed occur within a of UTC t. > In other words, I pick "a" large enough that I am not worried about > the likelihood of being shown wrong when I make that testimony. > > Does that mean that I'm implicitly setting "reliability" as Ed and engineering textbooks > uses > the term, to the value "high enough for legal work"? well, that means you *wish* to do so -- and you may not suceed if the other side can show with *equal* reliability that you are wrong. Perhaps, even less than equal would suffice -- reasonable doubt is enough. To exemplify why the concept of reliability is important, and quite disticnt from uncertainty and accuracy, pls read my former email when I wrote: Clearly, just saying "uncertainty = 2.4 s" is not enough, without the reliability. If the reliability would be 99% then the standard deviation for the *same* uncertainty of 2.4 s would be 0.8 s [2]. (and not 1.2 s) Cheers, Ed Gerck Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06975 for ; Thu, 1 Jun 2000 12:42:24 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirsx16707; Thu, 1 Jun 2000 19:50:12 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA06534; Thu, 1 Jun 00 15:46:42 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA04330; Thu, 1 Jun 2000 15:50:10 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14646.48754.723416.282742@xedia.com> Date: Thu, 1 Jun 2000 15:50:10 -0400 (EDT) To: egerck@nma.com Cc: James.H.Manger@team.telstra.com, ietf-pkix@imc.org Subject: Re: TSA Response serialNumber Field References: <73388857A695D31197EF00508B08F2988A3BC3@ntmsg0131.corpmail.telstra.com.au> <3936BAE1.ECCBB0DD@nma.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Whenever someone creates a discussion like this where "reliability" and "accuracy" (or, similarly, "accuracy" and "tolerance" or "accuracy" and "precision") are used with the intent of describing quite *different* things, alarms go off. I find that such discussions tend to be difficult if not impossible to understand, and it isn't at all clear whether the conclusions are meaningful. Take the case discussed here. Since we're dealing with variables having some statistical distribution (though very likely *not* one of the mathematically tractable ones statisticians like to work with) it is clear that any bounds specified have some probability associated with them. If I specify bounds such that the probability of being outside those bounds is high, I suppose one might speak of this as "low reliability". I'd rather not, because to me reliability is a term that describes the lack of brokenness. (Or do you want to say that specifying overly optimistic bounds means you're broken? I guess I could go for that...) If we had a well defined distribution of the random variable, we could talk about mean and standard deviation. But I don't believe we do; in particular I do know that it is a mistake to think that the distribution is Normal. Also, consider the intended usage. One major reason we want to have TSAs is so we can timestamp information with legally convincing timestamps. In other words, we want to be able to answer the question "did T1 occur before T2" well enough that we can stand up in court and give that answer. Not just here on this list... :-) This gives me a criterion for chosing the bounds I would advertise in a timestamp: they are chosen reasonably tightly, but such that I am willing to stand up in court and testify to the effect that an event timestamped as [t - a .. t + a] did indeed occur within a of UTC t. In other words, I pick "a" large enough that I am not worried about the likelihood of being shown wrong when I make that testimony. Does that mean that I'm implicitly setting "reliability" as Ed uses the term, to the value "high enough for legal work"? paul Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06587 for ; Thu, 1 Jun 2000 12:28:28 -0700 (PDT) Received: from nma.com ([63.204.17.82]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FVH00IJ7QEEMV@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Thu, 1 Jun 2000 12:35:03 -0700 (PDT) Date: Thu, 01 Jun 2000 12:34:57 -0700 From: Ed Gerck Subject: Re: TSA Response serialNumber Field To: "Manger, James H" Cc: ietf-pkix@imc.org Message-id: <3936BAE1.ECCBB0DD@nma.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <73388857A695D31197EF00508B08F2988A3BC3@ntmsg0131.corpmail.telstra.com.au> "Manger, James H" wrote: > Ed, > > The TSTInfo ASN.1 type has a field labelled "accuracy" that "represents the > time deviation around the UTC time contained in GeneralizedTime" (quoting > from the draft) [a misleading label & poorly worded sentence]. Its function > is to indicate how close the stated time is likely to be to UTC. The field > is meant to be useful to a relying party when they compare the time in the > timestamp to any other time (e.g. a deadline, a revocation date in a CRL, > validity dates in a certificate, another timestamp). I think the field > should be labelled "uncertainty" and I suspect you would label it > "reliability". I would label it "uncertainty" -- so we are in agreement on this change, but would rewrite the quote also. I initially suggest: "uncertainty" -- represents the time deviation around the UTC time contained in GeneralizedTime, with high reliability. which, btw, explains why I would NOT name it "reliability" [1]. The draft must also define "high reliability" and the allowed statistics (see [1] and my comments below). Using this definition, we may say that with a reliability of 95% the UTC time lies between [To - 1.2] and [To + 1.2] s -- when we are given an uncertainty of 2.4 s and consider "high reliability" defined as 95% for a gaussian distribution. With gaussian distributions, this directly means that the standard deviation is 1.2 s [2]. Clearly, just saying "uncertainty = 2.4 s" is not enough, without the reliability. If the reliability would be 99% then the standard deviation for the *same* uncertainty of 2.4 s would be 0.8 s [2]. About "high reliability" in my suggested definition change -- I know that defining high reliability may be tricky (and soon, outdated) -- but this can be done well by reference. The draft could define a parameter called "reliability level" (for example) which the TSA associates to a statistic distribution and sets as high as it can put its money to it ;-) -- for example, 99,9997% [2]. This limit will also provide a useful parameter to estimate the quality of service, to calculate risks, to estimate insurance costs, etc. Note that the TSA bears a risk not only in setting the reliability level but also in declaring that its data follows a statistic distribution -- for example, if we use gaussian statistics to model the stock market there is a tail that significantly exceeds that expected from Gaussian statistics, where the 1929 and 1987 stock market crashes were each about a 10 sigma event (ie, 10 times than the standard deviation), which would only happen once in the lifetime of the planet under Gaussian statistics [2]. It is also interesting to note that even if "high reliability" is 70% it might still be useful if the uncertainty is low enough -- and the price. It is a one sigma event [2]. > Now, given that the "accuracy" field actually conveys uncertainty, do I > really need to know the accuracy as well? How would a comparison work if > you knew the uncertainty and accuracy? ;-) let's make clear which is which, first. We have four quantitites: 1. accuracy: that rather arbitrary fine precision that the TSA sets for its timestamp ordering purposes. 2. uncertainty: set and guaranteed by the TSA, as given above. 3. reliability: set and guaranteed by the TSA, as given above. 4. statistics: set and guaranteed by the TSA, as given above. Thus, just having uncertainty and even accuracy does not allow you to compare time between two different TSAs for which you know nothing about their reliability nor about their statistics (as was the case in that example [3]) So, how would a comparison work for two timestamps T1 and T2, each one from a different TSA -- with different accuracies, uncertainties, reliabilities and statistics? For each timestamp, you have the uncertainty AND the reliability as given by each TSA. You would use a statistical model that both TSAs agree with (eg, gaussian) with each value in respective full accuracy and compute the probability that T1 >= T2. If this probability is larger than 50%, then T1 >- T2, otherwise it is T1 < T2. Let me build an example using data from Michaels': T1. Stamp from TSA_1: 20000529053138.34509878Z. accuracy = 8 digits uncertainty = 1 s reliability = 95% statistics: gauss T2. Stamp from TSA_2: 20000529053138.876Z. accuracy = 3 digits uncertainty = 1.5 s reliability = 99% statistics: gauss How do I do it [compare the stamps]? Even though the uncertainties are different, the sigmas are the same for each case, as we see from [2]. The sigma is 0.5 s and we see that T2 - T1 > sigma. Thus we may directly compare T1 with T2 and say that T2 > T1. Otherwise, we would need to calculate using the appropriate gaussian statistics for each. Now, if we had (with an added "9" in the timestamp for ordering purposes): T1'. Stamp from TSA_1: 20000529053138.345098789Z. accuracy = 8 digits uncertainty = 1 s reliability = 95% statistics: gauss then we could NOT say that T1' > T1 even if we take into account that they came from the same TSA. We could only say that the TSA issued T1' AFTER issuing T1. Further, if we had: T2'. Stamp from TSA_2: 20000529053138.345098789Z. accuracy = 3 digits uncertainty = 1.5 s reliability = 99% statistics: gauss then we could say nothing about T2' being issued before or after T1, much less whether T1' > T1 or not. Cheers, Ed Gerck [1] When estimating the mean of a normal distribution, the sample average provides a point estimate or best guess about the value of the mean. However, this estimate is almost surely not exactly correct. A confidence interval provides a range of values around that estimate to show how precise the estimate is. The reliability level (also called confidence level) associated with the interval, usually 90%, 95%, or 99%, is the percentage of times in repeated sampling that the intervals will contain the true value of the unknown parameter. See [2]. [2] A gaussian distribution with a standard deviation value "sigma" has, approximately: 69% of all events within one sigma, 95% of all events within two sigma, 99% of all events within three sigma. Nearly 100% (exactly: 99,9997%) of all events are covered in the range of six sigma -- in other words: out of an amount of 1 Million events only 3 events are outside the range of six sigma. [3] > -----Original Message----- > From: Ed Gerck [ mailto:egerck@nma.com] > Sent: Wednesday, 31 May 2000 13:42 > > .. > Now, if by "accuracy" above you mean uncertainty then I would have to > ask about their accuracies, since the time values may have very low > uncertainty > and still be as far apart as apples and speedboats. > > So, to the original question: "How do I do it [compare the stamps]?" > The answer must be (for what was provided): insufficient data. Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04566 for ; Thu, 1 Jun 2000 10:10:57 -0700 (PDT) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 13:19:20 -0400 Message-ID: <918C70B01822D411A87400B0D0204DFF04BFE3@panda.chrysalis-its.com> To: Denis.Pinkas@bull.net Cc: ietf-pkix@imc.org Subject: RE: Rationale for Nonce in Time Stamp Protocol Date: Thu, 1 Jun 2000 13:18:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id KAA04567 Saying only "or" instead of "and/or" would be fine with me. Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent: Wednesday, May 31, 2000 10:52 AM To: FRousseau@chrysalis-its.com Cc: ietf-pkix@imc.org Subject: Re: Rationale for Nonce in Time Stamp Protocol François, > Salut Denis, > > I agree with both the word change and the proposed pointer. > > However, I still think that leaving the term "timeliness" in Section 2.2 > could be misinterpreted to mean that a requesting entity MUST reject a > totally valid response because of possible delays in the intervening network > elements and/or a drifting of this requesting entity own local time > reference. > > According to Section 2.2, what would a requesting entity be required to do > if he/she receives a time stamp token with the right hash value and nonce, > however the time included in the response is before or very much later than > his/her own local trusted time reference? The current sentence is: ... by verifying *either* the time included in the response against a local trusted time reference, if one is available, *and/or* the value of the nonce (large random number with a high probability that it is generated by the client only once) included in the response against the value included in the request. Instead of "and/or", we could say "or". Would this solve your concern ? Denis Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14260 for ; Thu, 1 Jun 2000 02:14:13 -0700 (PDT) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id TAA16230; Thu, 1 Jun 2000 19:21:26 +1000 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd00Q4mO; Thu Jun 1 19:21:05 2000 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id TAA17337; Thu, 1 Jun 2000 19:21:05 +1000 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdpqC0x_; Thu Jun 1 19:20:47 2000 Received: from ntmsg0011.corpmail.telstra.com.au (ntmsg0011.corpmail.telstra.com.au [192.74.168.81]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id TAA06118; Thu, 1 Jun 2000 19:20:46 +1000 (EST) Received: by ntmsg0011.corpmail.telstra.com.au with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Jun 2000 19:20:16 +1000 Message-ID: <73388857A695D31197EF00508B08F2988A3BC3@ntmsg0131.corpmail.telstra.com.au> From: "Manger, James H" To: "'Ed Gerck'" Cc: ietf-pkix@imc.org Subject: RE: TSA Response serialNumber Field Date: Thu, 1 Jun 2000 19:20:07 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Ed, The TSTInfo ASN.1 type has a field labelled "accuracy" that "represents the time deviation around the UTC time contained in GeneralizedTime" (quoting from the draft) [a misleading label & poorly worded sentence]. Its function is to indicate how close the stated time is likely to be to UTC. The field is meant to be useful to a relying party when they compare the time in the timestamp to any other time (e.g. a deadline, a revocation date in a CRL, validity dates in a certificate, another timestamp). I think the field should be labelled "uncertainty" and I suspect you would label it "reliability". A TSA would determine the value of the field from historical measurements of how much adjustment was required when synchronising with other clocks, perhaps factoring in the clock drift specification from the manufacture (e.g. +/-3 milliseconds/day) plus a safety margin (to err on the conservative side). Now, given that the "accuracy" field actually conveys uncertainty, do I really need to know the accuracy as well? How would a comparison work if you knew the uncertainty and accuracy? -----Original Message----- From: Ed Gerck [ mailto:egerck@nma.com] Sent: Wednesday, 31 May 2000 13:42 .. Now, if by "accuracy" above you mean uncertainty then I would have to ask about their accuracies, since the time values may have very low uncertainty and still be as far apart as apples and speedboats. So, to the original question: "How do I do it [compare the stamps]?" The answer must be (for what was provided): insufficient data.