Subject: RFC 4810 on Long-Term Archive Service Requirements
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 29 Mar 2007 17:56:56 -0700
List-Id: <ietf-ltans.imc.org>

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

        RFC 4810

        Title:      Long-Term Archive Service Requirements 
        Author:     C. Wallace, U. Pordesch,
                    R. Brandner
        Status:     Informational
        Date:       March 2007
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      17
        Characters: 35690
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ltans-reqs-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4810.txt

There are many scenarios in which users must be able to prove the
existence of data at a specific point in time and be able to
demonstrate the integrity of data since that time, even when the
duration from time of existence to time of demonstration spans a
large period of time.  Additionally, users must be able to verify
signatures on digitally signed data many years after the generation
of the signature.  This document describes a class of long-term
archive services to support such scenarios and the technical
requirements for interacting with such services.  This memo provides 
information for the Internet community.

This document is a product of the Long-Term Archive and Notary Services
Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community. 
It does not specify an Internet standard of any kind. 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.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

Date: Tue, 27 Mar 2007 16:57:43 +0200
From: Peter Sylvester <[email-masked]>
To: Greg Werner <[email-masked]>
CC: Santosh Chokhani <[email-masked]>, [email-masked]
Subject: Re: TSA key and revocation checking
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms080702020706060503050509
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Greg Werner wrote:
> >From a technical perspective once the user receives an EOL notification for a particular TSA he/she would have to manually refresh all roots to establish new and updated trust points. Or, another preventive option is to check revocation status for outer layer trust anchors on a periodic basis (once per day or week) and if the TSA root is no longer valid (revoked) then time stamp records from that particular authority should no longer be accepted. 
>
>   
I have a little problem understand this. When should "time stamp 
records" no longer be accepted?
I assume first, time stamp records means 'time stamps' according to RFC 
3161 or ISO stuff.

Accepting a time stamp occurs:

- by the requesting party, at this time revocation checking can be done
  as usual.

- by a relying party that shortly after the event, i.e. in the normal
  course of the distributed workflow. Also I don't see a problem
  using whatever normal checking is done.

I am not considering the third case:

- by whoever trying to 'reverify' a time stamp LONG time
  after the event.

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

--------------ms080702020706060503050509--

Content-class: urn:content-classes:message
Subject: RE: validate draft - RE: TSA key and revocation checking
Date: Mon, 26 Mar 2007 15:40:10 +0200
From: "Tobias Gondrom" <[email-masked]>
To: "todd glassey" <[email-masked]>, "Julien Stern" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hello Todd,

> > 3. is there consensus that we only need either an OCSP _or_ a CRL -
but
> > not both to verify the validity of a certificate?
> 
> no - both should be available.
> 

Why are _both_ needed to verify?

>From my understanding for LTAs and a later party verifying an ERS it is
only important to know and verify that a certificate has been valid at
the time of use (and not been compromised until the time of protection
via the LTA. This information can be gained from either CRL or OCSP. 
Could you please explain which necessary information you can not get
from one of the two (either CRL or OCSP). So that you need to also
retrieve the second one additionally?

Tobias

From: "todd glassey" <[email-masked]>
To: "Julien Stern" <[email-masked]>, <[email-masked]>
Subject: Re: validate draft - RE: TSA key and revocation checking
Date: Fri, 23 Mar 2007 08:31:07 -0700
Sender: [email-masked]

Julien - this pertains to "Public TSA's" only as far as I can tell and a TSA 
that was operated internally to some institution may not have the same 
requirements on its use. That said, the real issue is how the system's to be 
used I think.

Todd Glassey
----- Original Message ----- 
From: "Julien Stern" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 23, 2007 1:59 AM
Subject: Re: validate draft - RE: TSA key and revocation checking

>
> Tobias,
>
> I now agree too with Carl.
> Having a Trusted TSA would indeed be nice to avoid the online lookup
> at verification time, but that does not weight against the ability
> to revoke the certificate. Notably because the RootCA will typically
> be offline and rarely used, while the TSA will be online and heavily
> used.
>
> --
> Julien
>
> On Thu, Mar 22, 2007 at 07:07:17PM -0700, Santosh Chokhani wrote:
>> Tobias,
>>
>>
>>
>> I agree with Carl.
>>
>>
>>
>> For the refreshed time stamps, all the artifacts can be part of the time 
>> stamp or obtained from the PKI archive per I-D drafted by Carl.
>>
>>
>>
>> For current time stamp, objects should be available a la regular PKI.
>>
>> ________________________________
>>
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Carl Wallace
>> Sent: Thursday, March 22, 2007 3:49 PM
>> To: [email-masked]
>> Subject: RE: validate draft - RE: TSA key and revocation checking
>>
>>
>>
>> In this case, I did correctly understand the intent of your proposal and 
>> feel the revocation status of the TSA certs should be checked.  I don't 
>> see where this complicates things.  The TSA is simply another EE 
>> certificate and artifacts necessary to verify EE certificates will 
>> already be preserved to verify signatures on documents.
>>
>>
>>
>>
>> ________________________________
>>
>>
>> From: Tobias Gondrom [mailto:[email-masked]]
>> Sent: Thursday, March 22, 2007 3:33 PM
>> To: [email-masked]
>> Cc: Carl Wallace
>> Subject: validate draft - RE: TSA key and revocation checking
>>
>> Hello Carl, Peter, Santosh and Julien,
>>
>>
>>
>> thank you for bringing this is up:
>>
>> At first this is just a _proposal_ about how to verify and what might be 
>> needed.
>>
>> Stefanie and I thought about what people need to store within the TS in 
>> ERS to verify it at any later point in time.
>>
>> (although we have the protection of the later ArchiveTimestampchains 
>> and -sequences for the integrity of the inner data, but still some 
>> problems arise due to the fact that you can expect _online_ status 
>> requests to fail e.g. when TSAs shut down or even after guaranteed 
>> timeframes of availability of about 30 years.)
>>
>>
>>
>> My thoughts in the presentation (as well as in the validate-draft) are 
>> the following:
>>
>> 0) theoretically to verify a TS it is necessary to store all certificates 
>> up to the root plus check their status (especially for revocation).
>>
>> (and in the case that you are not able to make the status request live 
>> and online you may also start to consider to also store all certificates 
>> used in signing the OCSP or CRLs, and their certificate chains and their 
>> OCSP responses, etc.)
>>
>>
>>
>> 1) What I proposed is that to verify a TS from a trusted TSA (e.g. a 
>> government body itself or certified by a government body) it could be 
>> (depending on the laws and customs of the specific country) sufficient to 
>> only store all certificates up to the root in the RFC3161-TS structures.
>>
>> This idea is based on the fact that it would be (inevitably) publicly 
>> known when a key of a certified TSA would be compromised (and revoked).
>>
>> This way you would not need to store OCSP or CRL for all certificates (up 
>> to the root) used in the TS - and this would make things a lot easier.
>>
>>
>>
>> Tobias
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ________________________________
>>
>>
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Carl Wallace
>> Sent: Thursday, March 22, 2007 3:28 PM
>> To: [email-masked]
>> Subject: RE: TSA key and revocation checking
>>
>>
>>
>> I took the comment during the meeting to refer to scenario 2.
>>
>>
>>
>>
>> ________________________________
>>
>>
>> From: Peter Sylvester [mailto:[email-masked]]
>> Sent: Thursday, March 22, 2007 7:50 AM
>> To: Carl Wallace
>> Cc: [email-masked]
>> Subject: Re: TSA key and revocation checking
>>
>> Carl Wallace a écrit :
>>
>> During yesterday's meeting, Tobias mentioned that a TSA key could be 
>> trusted without checking its revocation status because compromise of the 
>> key would be a widely known problem.  I asked, via Jabber, how one could 
>> confirm they had the correct TSA key and was directed to the mailing 
>> list.  While it may be true that the compromise of the TSA would be 
>> widely known, would the revocation of a certificate issued in error to 
>> the same name be as widely known?  Recommending that revocation status 
>> not be checked seems like a bad idea.  We have means for representing and 
>> processing revocation information, including the time of compromise, and 
>> should simply use them.
>>
>> I am not sure what scenario is addressed:
>>
>> 1 -  a client that obtains a time stamp and determines the aujthenticity 
>> of the response
>> 2 -  a relying party that verifies the time stamp
>>
>>
>>
>>
> 

From: "todd glassey" <[email-masked]>
To: "Tobias Gondrom" <[email-masked]>, "Julien Stern" <[email-masked]>, <[email-masked]>
Subject: Re: validate draft - RE: TSA key and revocation checking
Date: Fri, 23 Mar 2007 08:28:47 -0700
Sender: [email-masked]

----- Original Message ----- 
From: "Tobias Gondrom" <[email-masked]>
To: "Julien Stern" <[email-masked]>; <[email-masked]>
Sent: Friday, March 23, 2007 6:59 AM
Subject: RE: validate draft - RE: TSA key and revocation checking

>
> Hello all,
>
> Ok. (I still do not fully agree, but will wait whether further emails are 
> send to the mailing list on that item. If not I will modify the validate 
> draft as you propose.)
>
> Please let me use the opportunity and ask for your opinion on a few items:
> 1. in the CMS of the TS we can easily store the certificates and the CRLs 
> in the according fields of the structure SignedData.

What is the intent and use in storing the cert's themselves inside the 
CMS? - storing the certs may actually lead to instances where a stored cert 
could be invalidated in the external world for some cause and that would not 
be known to the LTANS provider.

> Any comments on where to best store OCSP responses in the structure?

If you are looking to store validation control information then the CMS area 
is probably reasonable.

>
> 2. as OCSP and CRLs are typically signed:

(responses...)

> a) Shall we also store the certificates with which they are signed?
> b) and shall we also store the OCSP/CRL for the certificates that have 
> been used to sign the OCSP responses?

If there is a need to create an evidence model such that all components of 
the decision/integrity control features are evidenced within the individual 
document instance, then yes you must store all the relevant data from that 
signing.

>
> 3. is there consensus that we only need either an OCSP _or_ a CRL - but 
> not both to verify the validity of a certificate?

no - both should be available.

>
> Any comments?
>
> Tobias
>
>
>
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]]
>> On Behalf Of Julien Stern
>> Sent: Friday, March 23, 2007 10:00 AM
>> To: [email-masked]
>> Subject: Re: validate draft - RE: TSA key and revocation checking
>>
>>
>> Tobias,
>>
>> I now agree too with Carl.
>> Having a Trusted TSA would indeed be nice to avoid the online lookup
>> at verification time, but that does not weight against the ability
>> to revoke the certificate. Notably because the RootCA will typically
>> be offline and rarely used, while the TSA will be online and heavily
>> used.
>>
>> --
>> Julien
>>
>> On Thu, Mar 22, 2007 at 07:07:17PM -0700, Santosh Chokhani wrote:
>> > Tobias,
>> >
>> >
>> >
>> > I agree with Carl.
>> >
>> >
>> >
>> > For the refreshed time stamps, all the artifacts can be part of the 
>> > time
>> stamp or obtained from the PKI archive per I-D drafted by Carl.
>> >
>> >
>> >
>> > For current time stamp, objects should be available a la regular PKI.
>> >
>> > ________________________________
>> >
>> > From: [email-masked] [mailto:owner-ietf-
>> [email-masked]] On Behalf Of Carl Wallace
>> > Sent: Thursday, March 22, 2007 3:49 PM
>> > To: [email-masked]
>> > Subject: RE: validate draft - RE: TSA key and revocation checking
>> >
>> >
>> >
>> > In this case, I did correctly understand the intent of your proposal 
>> > and
>> feel the revocation status of the TSA certs should be checked.  I don't
>> see where this complicates things.  The TSA is simply another EE
>> certificate and artifacts necessary to verify EE certificates will 
>> already
>> be preserved to verify signatures on documents.
>> >
>> >
>> >
>> >
>> > ________________________________
>> >
>> >
>> > From: Tobias Gondrom [mailto:[email-masked]]
>> > Sent: Thursday, March 22, 2007 3:33 PM
>> > To: [email-masked]
>> > Cc: Carl Wallace
>> > Subject: validate draft - RE: TSA key and revocation checking
>> >
>> > Hello Carl, Peter, Santosh and Julien,
>> >
>> >
>> >
>> > thank you for bringing this is up:
>> >
>> > At first this is just a _proposal_ about how to verify and what
>> might be needed.
>> >
>> > Stefanie and I thought about what people need to store within the TS
>> in ERS to verify it at any later point in time.
>> >
>> > (although we have the protection of the later ArchiveTimestampchains
>> and -sequences for the integrity of the inner data, but still some
>> problems arise due to the fact that you can expect _online_ status
>> requests to fail e.g. when TSAs shut down or even after guaranteed
>> timeframes of availability of about 30 years.)
>> >
>> >
>> >
>> > My thoughts in the presentation (as well as in the validate-draft)
>> are the following:
>> >
>> > 0) theoretically to verify a TS it is necessary to store all
>> certificates up to the root plus check their status (especially for
>> revocation).
>> >
>> > (and in the case that you are not able to make the status request
>> live and online you may also start to consider to also store all
>> certificates used in signing the OCSP or CRLs, and their certificate
>> chains and their OCSP responses, etc.)
>> >
>> >
>> >
>> > 1) What I proposed is that to verify a TS from a trusted TSA (e.g. a
>> government body itself or certified by a government body) it could be
>> (depending on the laws and customs of the specific country) sufficient to
>> only store all certificates up to the root in the RFC3161-TS structures.
>> >
>> > This idea is based on the fact that it would be (inevitably)
>> publicly known when a key of a certified TSA would be compromised (and
>> revoked).
>> >
>> > This way you would not need to store OCSP or CRL for all
>> certificates (up to the root) used in the TS - and this would make things
>> a lot easier.
>> >
>> >
>> >
>> > Tobias
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > ________________________________
>> >
>> >
>> > From: [email-masked] [mailto:owner-ietf-
>> [email-masked]] On Behalf Of Carl Wallace
>> > Sent: Thursday, March 22, 2007 3:28 PM
>> > To: [email-masked]
>> > Subject: RE: TSA key and revocation checking
>> >
>> >
>> >
>> > I took the comment during the meeting to refer to scenario 2.
>> >
>> >
>> >
>> >
>> > ________________________________
>> >
>> >
>> > From: Peter Sylvester [mailto:[email-masked]]
>> > Sent: Thursday, March 22, 2007 7:50 AM
>> > To: Carl Wallace
>> > Cc: [email-masked]
>> > Subject: Re: TSA key and revocation checking
>> >
>> > Carl Wallace a écrit :
>> >
>> > During yesterday's meeting, Tobias mentioned that a TSA key
>> could be trusted without checking its revocation status because 
>> compromise
>> of the key would be a widely known problem.  I asked, via Jabber, how one
>> could confirm they had the correct TSA key and was directed to the 
>> mailing
>> list.  While it may be true that the compromise of the TSA would be 
>> widely
>> known, would the revocation of a certificate issued in error to the same
>> name be as widely known?  Recommending that revocation status not be
>> checked seems like a bad idea.  We have means for representing and
>> processing revocation information, including the time of compromise, and
>> should simply use them.
>> >
>> > I am not sure what scenario is addressed:
>> >
>> > 1 -  a client that obtains a time stamp and determines the
>> aujthenticity of the response
>> > 2 -  a relying party that verifies the time stamp
>> >
>> >
>> >
>> >
>
> 

From: Carl Wallace <[email-masked]>
To: [email-masked]
Subject: RE: validate draft - RE: TSA key and revocation checking
Date: Fri, 23 Mar 2007 10:17:41 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C76D56.04D5C1D8
Content-Type: text/plain;
	charset="ISO-8859-1"

> 1. in the CMS of the TS we can easily store the certificates 
> and the CRLs in the according fields of the structure 
> SignedData. Any comments on where to best store OCSP 
> responses in the structure?

OCSP responses can be stored in the same place.  RFC3852 defines the CRLs
bag as a RevocationInfoChoices.  I'm not sure if an OID has been defined for
this purpose yet.

      RevocationInfoChoices ::= SET OF RevocationInfoChoice

      RevocationInfoChoice ::= CHOICE {
        crl CertificateList,
        other [1] IMPLICIT OtherRevocationInfoFormat }

      OtherRevocationInfoFormat ::= SEQUENCE {
        otherRevInfoFormat OBJECT IDENTIFIER,
        otherRevInfo ANY DEFINED BY otherRevInfoFormat }
 
> 2. as OCSP and CRLs are typically signed: 
> a) Shall we also store the certificates with which they are signed?
> b) and shall we also store the OCSP/CRL for the certificates 
> that have been used to sign the OCSP responses?

I think these are configuration options.  The materials could be stored in
each object or could be stored separately under a different evidence record.

> 3. is there consensus that we only need either an OCSP _or_ a 
> CRL - but not both to verify the validity of a certificate?

Either seems fine to me, no need for both.
 
> Any comments?

My preference is to store the artifacts separately from the documents and to
store a single cumulative CRL once a CA has reached the end of its life.
However, the specs will support a range of options, from storing all
materials in each object to storing artifacts once centrally.  The verifier
has the responsibility for verifying each signature fully (including
revocation checks) in accord with their algorithm policy.    
 
> Tobias
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]
> > On Behalf Of Julien Stern
> > Sent: Friday, March 23, 2007 10:00 AM
> > To: [email-masked]
> > Subject: Re: validate draft - RE: TSA key and revocation checking
> > 
> > 
> > Tobias,
> > 
> > I now agree too with Carl.
> > Having a Trusted TSA would indeed be nice to avoid the 
> online lookup 
> > at verification time, but that does not weight against the 
> ability to 
> > revoke the certificate. Notably because the RootCA will 
> typically be 
> > offline and rarely used, while the TSA will be online and heavily 
> > used.
> > 
> > --
> > Julien
> > 
> > On Thu, Mar 22, 2007 at 07:07:17PM -0700, Santosh Chokhani wrote:
> > > Tobias,
> > >
> > >
> > >
> > > I agree with Carl.
> > >
> > >
> > >
> > > For the refreshed time stamps, all the artifacts can be 
> part of the 
> > > time
> > stamp or obtained from the PKI archive per I-D drafted by Carl.
> > >
> > >
> > >
> > > For current time stamp, objects should be available a la 
> regular PKI.
> > >
> > > ________________________________
> > >
> > > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of Carl Wallace
> > > Sent: Thursday, March 22, 2007 3:49 PM
> > > To: [email-masked]
> > > Subject: RE: validate draft - RE: TSA key and revocation checking
> > >
> > >
> > >
> > > In this case, I did correctly understand the intent of 
> your proposal 
> > > and
> > feel the revocation status of the TSA certs should be checked.  I 
> > don't see where this complicates things.  The TSA is simply 
> another EE 
> > certificate and artifacts necessary to verify EE certificates will 
> > already be preserved to verify signatures on documents.
> > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > >
> > > 	From: Tobias Gondrom [mailto:[email-masked]]
> > > 	Sent: Thursday, March 22, 2007 3:33 PM
> > > 	To: [email-masked]
> > > 	Cc: Carl Wallace
> > > 	Subject: validate draft - RE: TSA key and revocation checking
> > >
> > > 	Hello Carl, Peter, Santosh and Julien,
> > >
> > >
> > >
> > > 	thank you for bringing this is up:
> > >
> > > 	At first this is just a _proposal_ about how to verify and what
> > might be needed.
> > >
> > > 	Stefanie and I thought about what people need to store 
> within the 
> > > TS
> > in ERS to verify it at any later point in time.
> > >
> > > 	(although we have the protection of the later 
> > > ArchiveTimestampchains
> > and -sequences for the integrity of the inner data, but still some 
> > problems arise due to the fact that you can expect _online_ status 
> > requests to fail e.g. when TSAs shut down or even after guaranteed 
> > timeframes of availability of about 30 years.)
> > >
> > >
> > >
> > > 	My thoughts in the presentation (as well as in the 
> validate-draft)
> > are the following:
> > >
> > > 	0) theoretically to verify a TS it is necessary to store all
> > certificates up to the root plus check their status (especially for 
> > revocation).
> > >
> > > 	(and in the case that you are not able to make the 
> status request
> > live and online you may also start to consider to also store all 
> > certificates used in signing the OCSP or CRLs, and their 
> certificate 
> > chains and their OCSP responses, etc.)
> > >
> > >
> > >
> > > 	1) What I proposed is that to verify a TS from a 
> trusted TSA (e.g. 
> > > a
> > government body itself or certified by a government body) 
> it could be 
> > (depending on the laws and customs of the specific country) 
> sufficient 
> > to only store all certificates up to the root in the 
> RFC3161-TS structures.
> > >
> > > 	This idea is based on the fact that it would be (inevitably)
> > publicly known when a key of a certified TSA would be 
> compromised (and 
> > revoked).
> > >
> > > 	This way you would not need to store OCSP or CRL for all
> > certificates (up to the root) used in the TS - and this would make 
> > things a lot easier.
> > >
> > >
> > >
> > > 	Tobias
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > >
> > > 	From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of Carl Wallace
> > > 	Sent: Thursday, March 22, 2007 3:28 PM
> > > 	To: [email-masked]
> > > 	Subject: RE: TSA key and revocation checking
> > >
> > >
> > >
> > > 	I took the comment during the meeting to refer to scenario 2.
> > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > >
> > > 		From: Peter Sylvester 
> [mailto:[email-masked]]
> > > 		Sent: Thursday, March 22, 2007 7:50 AM
> > > 		To: Carl Wallace
> > > 		Cc: [email-masked]
> > > 		Subject: Re: TSA key and revocation checking
> > >
> > > 		Carl Wallace a écrit :
> > >
> > > 		During yesterday's meeting, Tobias mentioned 
> that a TSA key
> > could be trusted without checking its revocation status because 
> > compromise of the key would be a widely known problem.  I 
> asked, via 
> > Jabber, how one could confirm they had the correct TSA key and was 
> > directed to the mailing list.  While it may be true that the 
> > compromise of the TSA would be widely known, would the 
> revocation of a 
> > certificate issued in error to the same name be as widely known?  
> > Recommending that revocation status not be checked seems like a bad 
> > idea.  We have means for representing and processing revocation 
> > information, including the time of compromise, and should 
> simply use them.
> > >
> > > 		 I am not sure what scenario is addressed:
> > >
> > > 		1 -  a client that obtains a time stamp and 
> determines the
> > aujthenticity of the response
> > > 		2 -  a relying party that verifies the time stamp
> > >
> > >
> > >
> > >
> 
> 

------_=_NextPart_001_01C76D56.04D5C1D8
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: validate draft - RE: TSA key and revocation checking</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; 1. in the CMS of the TS we can easily store the =
certificates </FONT>
<BR><FONT SIZE=3D2>&gt; and the CRLs in the according fields of the =
structure </FONT>
<BR><FONT SIZE=3D2>&gt; SignedData. Any comments on where to best store =
OCSP </FONT>
<BR><FONT SIZE=3D2>&gt; responses in the structure?</FONT>
</P>

<P><FONT SIZE=3D2>OCSP responses can be stored in the same place.&nbsp; =
RFC3852 defines the CRLs bag as a RevocationInfoChoices.&nbsp; I'm not =
sure if an OID has been defined for this purpose yet.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RevocationInfoChoices =
::=3D SET OF RevocationInfoChoice</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RevocationInfoChoice =
::=3D CHOICE {</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; crl =
CertificateList,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; other [1] =
IMPLICIT OtherRevocationInfoFormat }</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OtherRevocationInfoFormat ::=3D SEQUENCE {</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
otherRevInfoFormat OBJECT IDENTIFIER,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
otherRevInfo ANY DEFINED BY otherRevInfoFormat }</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; 2. as OCSP and CRLs are typically signed: =
</FONT>
<BR><FONT SIZE=3D2>&gt; a) Shall we also store the certificates with =
which they are signed?</FONT>
<BR><FONT SIZE=3D2>&gt; b) and shall we also store the OCSP/CRL for the =
certificates </FONT>
<BR><FONT SIZE=3D2>&gt; that have been used to sign the OCSP =
responses?</FONT>
</P>

<P><FONT SIZE=3D2>I think these are configuration options.&nbsp; The =
materials could be stored in each object or could be stored separately =
under a different evidence record.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; 3. is there consensus that we only need either =
an OCSP _or_ a </FONT>
<BR><FONT SIZE=3D2>&gt; CRL - but not both to verify the validity of a =
certificate?</FONT>
</P>

<P><FONT SIZE=3D2>Either seems fine to me, no need for both.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; Any comments?</FONT>
</P>

<P><FONT SIZE=3D2>My preference is to store the artifacts separately =
from the documents and to store a single cumulative CRL once a CA has =
reached the end of its life.&nbsp; However, the specs will support a =
range of options, from storing all materials in each object to storing =
artifacts once centrally.&nbsp; The verifier has the responsibility for =
verifying each signature fully (including revocation checks) in accord =
with their algorithm policy.&nbsp;&nbsp;&nbsp; </FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; Tobias</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: [email-masked] =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-ltans@ma=
il.imc.org</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; On Behalf Of Julien Stern</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Friday, March 23, 2007 10:00 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: validate draft - RE: TSA key =
and revocation checking</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Tobias,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I now agree too with Carl.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Having a Trusted TSA would indeed be nice =
to avoid the </FONT>
<BR><FONT SIZE=3D2>&gt; online lookup </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; at verification time, but that does not =
weight against the </FONT>
<BR><FONT SIZE=3D2>&gt; ability to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; revoke the certificate. Notably because =
the RootCA will </FONT>
<BR><FONT SIZE=3D2>&gt; typically be </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; offline and rarely used, while the TSA =
will be online and heavily </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; used.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Julien</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; On Thu, Mar 22, 2007 at 07:07:17PM -0700, =
Santosh Chokhani wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Tobias,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I agree with Carl.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; For the refreshed time stamps, all =
the artifacts can be </FONT>
<BR><FONT SIZE=3D2>&gt; part of the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; time</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; stamp or obtained from the PKI archive per =
I-D drafted by Carl.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; For current time stamp, objects =
should be available a la </FONT>
<BR><FONT SIZE=3D2>&gt; regular PKI.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: [email-masked] =
[<A HREF=3D"mailto:owner-ietf-">mailto:owner-ietf-</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [email-masked]] On Behalf Of Carl =
Wallace</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Thursday, March 22, 2007 3:49 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: RE: validate draft - RE: TSA =
key and revocation checking</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; In this case, I did correctly =
understand the intent of </FONT>
<BR><FONT SIZE=3D2>&gt; your proposal </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; feel the revocation status of the TSA =
certs should be checked.&nbsp; I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; don't see where this complicates =
things.&nbsp; The TSA is simply </FONT>
<BR><FONT SIZE=3D2>&gt; another EE </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificate and artifacts necessary to =
verify EE certificates will </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; already be preserved to verify signatures =
on documents.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; From: Tobias Gondrom [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; Sent: Thursday, March 22, 2007 =
3:33 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; Cc: Carl Wallace</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; Subject: validate draft - RE: =
TSA key and revocation checking</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; Hello Carl, Peter, Santosh and =
Julien,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; thank you for bringing this is =
up:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; At first this is just a =
_proposal_ about how to verify and what</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; might be needed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; Stefanie and I thought about =
what people need to store </FONT>
<BR><FONT SIZE=3D2>&gt; within the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; TS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in ERS to verify it at any later point in =
time.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; (although we have the =
protection of the later </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ArchiveTimestampchains</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and -sequences for the integrity of the =
inner data, but still some </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; problems arise due to the fact that you =
can expect _online_ status </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requests to fail e.g. when TSAs shut down =
or even after guaranteed </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; timeframes of availability of about 30 =
years.)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; My thoughts in the =
presentation (as well as in the </FONT>
<BR><FONT SIZE=3D2>&gt; validate-draft)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; are the following:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; 0) theoretically to verify a =
TS it is necessary to store all</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificates up to the root plus check =
their status (especially for </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; revocation).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; (and in the case that you are =
not able to make the </FONT>
<BR><FONT SIZE=3D2>&gt; status request</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; live and online you may also start to =
consider to also store all </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificates used in signing the OCSP or =
CRLs, and their </FONT>
<BR><FONT SIZE=3D2>&gt; certificate </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; chains and their OCSP responses, =
etc.)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; 1) What I proposed is that to =
verify a TS from a </FONT>
<BR><FONT SIZE=3D2>&gt; trusted TSA (e.g. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; government body itself or certified by a =
government body) </FONT>
<BR><FONT SIZE=3D2>&gt; it could be </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (depending on the laws and customs of the =
specific country) </FONT>
<BR><FONT SIZE=3D2>&gt; sufficient </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to only store all certificates up to the =
root in the </FONT>
<BR><FONT SIZE=3D2>&gt; RFC3161-TS structures.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; This idea is based on the fact =
that it would be (inevitably)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; publicly known when a key of a certified =
TSA would be </FONT>
<BR><FONT SIZE=3D2>&gt; compromised (and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; revoked).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; This way you would not need to =
store OCSP or CRL for all</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificates (up to the root) used in the =
TS - and this would make </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; things a lot easier.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; Tobias</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; From: =
[email-masked] [<A =
HREF=3D"mailto:owner-ietf-">mailto:owner-ietf-</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [email-masked]] On Behalf Of Carl =
Wallace</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; Sent: Thursday, March 22, 2007 =
3:28 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; Subject: RE: TSA key and =
revocation checking</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; I took the comment during the =
meeting to refer to scenario 2.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; From: Peter Sylvester =
</FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:peter.sylvester@edelwe=
b.fr</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sent: Thursday, March 22, =
2007 7:50 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To: Carl Wallace</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cc: =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject: Re: TSA key and =
revocation checking</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Carl Wallace a =E9crit =
:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; During yesterday's meeting, =
Tobias mentioned </FONT>
<BR><FONT SIZE=3D2>&gt; that a TSA key</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; could be trusted without checking its =
revocation status because </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; compromise of the key would be a widely =
known problem.&nbsp; I </FONT>
<BR><FONT SIZE=3D2>&gt; asked, via </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Jabber, how one could confirm they had the =
correct TSA key and was </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; directed to the mailing list.&nbsp; While =
it may be true that the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; compromise of the TSA would be widely =
known, would the </FONT>
<BR><FONT SIZE=3D2>&gt; revocation of a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificate issued in error to the same =
name be as widely known?&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Recommending that revocation status not be =
checked seems like a bad </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; idea.&nbsp; We have means for representing =
and processing revocation </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; information, including the time of =
compromise, and should </FONT>
<BR><FONT SIZE=3D2>&gt; simply use them.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I am not sure what =
scenario is addressed:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1 -&nbsp; a client that =
obtains a time stamp and </FONT>
<BR><FONT SIZE=3D2>&gt; determines the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; aujthenticity of the response</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2 -&nbsp; a relying party =
that verifies the time stamp</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C76D56.04D5C1D8--

Content-class: urn:content-classes:message
Subject: RE: validate draft - RE: TSA key and revocation checking
Date: Fri, 23 Mar 2007 14:59:22 +0100
From: "Tobias Gondrom" <[email-masked]>
To: "Julien Stern" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hello all, 

Ok. (I still do not fully agree, but will wait whether further emails are send to the mailing list on that item. If not I will modify the validate draft as you propose.)

Please let me use the opportunity and ask for your opinion on a few items:
1. in the CMS of the TS we can easily store the certificates and the CRLs in the according fields of the structure SignedData. Any comments on where to best store OCSP responses in the structure?

2. as OCSP and CRLs are typically signed: 
a) Shall we also store the certificates with which they are signed?
b) and shall we also store the OCSP/CRL for the certificates that have been used to sign the OCSP responses?

3. is there consensus that we only need either an OCSP _or_ a CRL - but not both to verify the validity of a certificate?

Any comments?

Tobias

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Julien Stern
> Sent: Friday, March 23, 2007 10:00 AM
> To: [email-masked]
> Subject: Re: validate draft - RE: TSA key and revocation checking
> 
> 
> Tobias,
> 
> I now agree too with Carl.
> Having a Trusted TSA would indeed be nice to avoid the online lookup
> at verification time, but that does not weight against the ability
> to revoke the certificate. Notably because the RootCA will typically
> be offline and rarely used, while the TSA will be online and heavily
> used.
> 
> --
> Julien
> 
> On Thu, Mar 22, 2007 at 07:07:17PM -0700, Santosh Chokhani wrote:
> > Tobias,
> >
> >
> >
> > I agree with Carl.
> >
> >
> >
> > For the refreshed time stamps, all the artifacts can be part of the time
> stamp or obtained from the PKI archive per I-D drafted by Carl.
> >
> >
> >
> > For current time stamp, objects should be available a la regular PKI.
> >
> > ________________________________
> >
> > From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Carl Wallace
> > Sent: Thursday, March 22, 2007 3:49 PM
> > To: [email-masked]
> > Subject: RE: validate draft - RE: TSA key and revocation checking
> >
> >
> >
> > In this case, I did correctly understand the intent of your proposal and
> feel the revocation status of the TSA certs should be checked.  I don't
> see where this complicates things.  The TSA is simply another EE
> certificate and artifacts necessary to verify EE certificates will already
> be preserved to verify signatures on documents.
> >
> >
> >
> >
> > ________________________________
> >
> >
> > 	From: Tobias Gondrom [mailto:[email-masked]]
> > 	Sent: Thursday, March 22, 2007 3:33 PM
> > 	To: [email-masked]
> > 	Cc: Carl Wallace
> > 	Subject: validate draft - RE: TSA key and revocation checking
> >
> > 	Hello Carl, Peter, Santosh and Julien,
> >
> >
> >
> > 	thank you for bringing this is up:
> >
> > 	At first this is just a _proposal_ about how to verify and what
> might be needed.
> >
> > 	Stefanie and I thought about what people need to store within the TS
> in ERS to verify it at any later point in time.
> >
> > 	(although we have the protection of the later ArchiveTimestampchains
> and -sequences for the integrity of the inner data, but still some
> problems arise due to the fact that you can expect _online_ status
> requests to fail e.g. when TSAs shut down or even after guaranteed
> timeframes of availability of about 30 years.)
> >
> >
> >
> > 	My thoughts in the presentation (as well as in the validate-draft)
> are the following:
> >
> > 	0) theoretically to verify a TS it is necessary to store all
> certificates up to the root plus check their status (especially for
> revocation).
> >
> > 	(and in the case that you are not able to make the status request
> live and online you may also start to consider to also store all
> certificates used in signing the OCSP or CRLs, and their certificate
> chains and their OCSP responses, etc.)
> >
> >
> >
> > 	1) What I proposed is that to verify a TS from a trusted TSA (e.g. a
> government body itself or certified by a government body) it could be
> (depending on the laws and customs of the specific country) sufficient to
> only store all certificates up to the root in the RFC3161-TS structures.
> >
> > 	This idea is based on the fact that it would be (inevitably)
> publicly known when a key of a certified TSA would be compromised (and
> revoked).
> >
> > 	This way you would not need to store OCSP or CRL for all
> certificates (up to the root) used in the TS - and this would make things
> a lot easier.
> >
> >
> >
> > 	Tobias
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ________________________________
> >
> >
> > 	From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Carl Wallace
> > 	Sent: Thursday, March 22, 2007 3:28 PM
> > 	To: [email-masked]
> > 	Subject: RE: TSA key and revocation checking
> >
> >
> >
> > 	I took the comment during the meeting to refer to scenario 2.
> >
> >
> >
> >
> > ________________________________
> >
> >
> > 		From: Peter Sylvester [mailto:[email-masked]]
> > 		Sent: Thursday, March 22, 2007 7:50 AM
> > 		To: Carl Wallace
> > 		Cc: [email-masked]
> > 		Subject: Re: TSA key and revocation checking
> >
> > 		Carl Wallace a écrit :
> >
> > 		During yesterday's meeting, Tobias mentioned that a TSA key
> could be trusted without checking its revocation status because compromise
> of the key would be a widely known problem.  I asked, via Jabber, how one
> could confirm they had the correct TSA key and was directed to the mailing
> list.  While it may be true that the compromise of the TSA would be widely
> known, would the revocation of a certificate issued in error to the same
> name be as widely known?  Recommending that revocation status not be
> checked seems like a bad idea.  We have means for representing and
> processing revocation information, including the time of compromise, and
> should simply use them.
> >
> > 		 I am not sure what scenario is addressed:
> >
> > 		1 -  a client that obtains a time stamp and determines the
> aujthenticity of the response
> > 		2 -  a relying party that verifies the time stamp
> >
> >
> >
> >

From: "Julien Stern" <[email-masked]>
Date: Fri, 23 Mar 2007 09:59:59 +0100
To: [email-masked]
Subject: Re: validate draft - RE: TSA key and revocation checking
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

Tobias,

I now agree too with Carl.
Having a Trusted TSA would indeed be nice to avoid the online lookup
at verification time, but that does not weight against the ability
to revoke the certificate. Notably because the RootCA will typically
be offline and rarely used, while the TSA will be online and heavily
used.

--
Julien

On Thu, Mar 22, 2007 at 07:07:17PM -0700, Santosh Chokhani wrote:
> Tobias,
> 
>  
> 
> I agree with Carl.
> 
>  
> 
> For the refreshed time stamps, all the artifacts can be part of the time stamp or obtained from the PKI archive per I-D drafted by Carl.
> 
>  
> 
> For current time stamp, objects should be available a la regular PKI.
> 
> ________________________________
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Carl Wallace
> Sent: Thursday, March 22, 2007 3:49 PM
> To: [email-masked]
> Subject: RE: validate draft - RE: TSA key and revocation checking
> 
>  
> 
> In this case, I did correctly understand the intent of your proposal and feel the revocation status of the TSA certs should be checked.  I don't see where this complicates things.  The TSA is simply another EE certificate and artifacts necessary to verify EE certificates will already be preserved to verify signatures on documents.
> 
> 	 
> 
> 	
> ________________________________
> 
> 
> 	From: Tobias Gondrom [mailto:[email-masked]] 
> 	Sent: Thursday, March 22, 2007 3:33 PM
> 	To: [email-masked]
> 	Cc: Carl Wallace
> 	Subject: validate draft - RE: TSA key and revocation checking
> 
> 	Hello Carl, Peter, Santosh and Julien, 
> 
> 	 
> 
> 	thank you for bringing this is up:
> 
> 	At first this is just a _proposal_ about how to verify and what might be needed. 
> 
> 	Stefanie and I thought about what people need to store within the TS in ERS to verify it at any later point in time.
> 
> 	(although we have the protection of the later ArchiveTimestampchains and -sequences for the integrity of the inner data, but still some problems arise due to the fact that you can expect _online_ status requests to fail e.g. when TSAs shut down or even after guaranteed timeframes of availability of about 30 years.)
> 
> 	 
> 
> 	My thoughts in the presentation (as well as in the validate-draft) are the following:
> 
> 	0) theoretically to verify a TS it is necessary to store all certificates up to the root plus check their status (especially for revocation). 
> 
> 	(and in the case that you are not able to make the status request live and online you may also start to consider to also store all certificates used in signing the OCSP or CRLs, and their certificate chains and their OCSP responses, etc.)
> 
> 	 
> 
> 	1) What I proposed is that to verify a TS from a trusted TSA (e.g. a government body itself or certified by a government body) it could be (depending on the laws and customs of the specific country) sufficient to only store all certificates up to the root in the RFC3161-TS structures. 
> 
> 	This idea is based on the fact that it would be (inevitably) publicly known when a key of a certified TSA would be compromised (and revoked).
> 
> 	This way you would not need to store OCSP or CRL for all certificates (up to the root) used in the TS - and this would make things a lot easier. 
> 
> 	 
> 
> 	Tobias
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	 
> 
> 	
> ________________________________
> 
> 
> 	From: [email-masked] [mailto:[email-masked]] On Behalf Of Carl Wallace
> 	Sent: Thursday, March 22, 2007 3:28 PM
> 	To: [email-masked]
> 	Subject: RE: TSA key and revocation checking
> 
> 	 
> 
> 	I took the comment during the meeting to refer to scenario 2.
> 
> 		 
> 
> 		
> ________________________________
> 
> 
> 		From: Peter Sylvester [mailto:[email-masked]] 
> 		Sent: Thursday, March 22, 2007 7:50 AM
> 		To: Carl Wallace
> 		Cc: [email-masked]
> 		Subject: Re: TSA key and revocation checking
> 
> 		Carl Wallace a écrit : 
> 
> 		During yesterday's meeting, Tobias mentioned that a TSA key could be trusted without checking its revocation status because compromise of the key would be a widely known problem.  I asked, via Jabber, how one could confirm they had the correct TSA key and was directed to the mailing list.  While it may be true that the compromise of the TSA would be widely known, would the revocation of a certificate issued in error to the same name be as widely known?  Recommending that revocation status not be checked seems like a bad idea.  We have means for representing and processing revocation information, including the time of compromise, and should simply use them.
> 
> 		 I am not sure what scenario is addressed:
> 		
> 		1 -  a client that obtains a time stamp and determines the aujthenticity of the response
> 		2 -  a relying party that verifies the time stamp
> 		
> 		
> 		
> 

Content-class: urn:content-classes:message
Subject: RE: validate draft - RE: TSA key and revocation checking
Date: Thu, 22 Mar 2007 19:07:17 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C76CF0.06680354
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Tobias,

=20

I agree with Carl.

=20

For the refreshed time stamps, all the artifacts can be part of the time =
stamp or obtained from the PKI archive per I-D drafted by Carl.

=20

For current time stamp, objects should be available a la regular PKI.

________________________________

From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Carl Wallace
Sent: Thursday, March 22, 2007 3:49 PM
To: [email-masked]
Subject: RE: validate draft - RE: TSA key and revocation checking

=20

In this case, I did correctly understand the intent of your proposal and =
feel the revocation status of the TSA certs should be checked.  I don't =
see where this complicates things.  The TSA is simply another EE =
certificate and artifacts necessary to verify EE certificates will =
already be preserved to verify signatures on documents.

	=20

=09
________________________________

	From: Tobias Gondrom [mailto:[email-masked]]=20
	Sent: Thursday, March 22, 2007 3:33 PM
	To: [email-masked]
	Cc: Carl Wallace
	Subject: validate draft - RE: TSA key and revocation checking

	Hello Carl, Peter, Santosh and Julien,=20

	=20

	thank you for bringing this is up:

	At first this is just a _proposal_ about how to verify and what might =
be needed.=20

	Stefanie and I thought about what people need to store within the TS in =
ERS to verify it at any later point in time.

	(although we have the protection of the later ArchiveTimestampchains =
and -sequences for the integrity of the inner data, but still some =
problems arise due to the fact that you can expect _online_ status =
requests to fail e.g. when TSAs shut down or even after guaranteed =
timeframes of availability of about 30 years.)

	=20

	My thoughts in the presentation (as well as in the validate-draft) are =
the following:

	0) theoretically to verify a TS it is necessary to store all =
certificates up to the root plus check their status (especially for =
revocation).=20

	(and in the case that you are not able to make the status request live =
and online you may also start to consider to also store all certificates =
used in signing the OCSP or CRLs, and their certificate chains and their =
OCSP responses, etc.)

	=20

	1) What I proposed is that to verify a TS from a trusted TSA (e.g. a =
government body itself or certified by a government body) it could be =
(depending on the laws and customs of the specific country) sufficient =
to only store all certificates up to the root in the RFC3161-TS =
structures.=20

	This idea is based on the fact that it would be (inevitably) publicly =
known when a key of a certified TSA would be compromised (and revoked).

	This way you would not need to store OCSP or CRL for all certificates =
(up to the root) used in the TS - and this would make things a lot =
easier.=20

	=20

	Tobias

	=20

	=20

	=20

	=20

	=20

=09
________________________________

	From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Carl Wallace
	Sent: Thursday, March 22, 2007 3:28 PM
	To: [email-masked]
	Subject: RE: TSA key and revocation checking

	=20

	I took the comment during the meeting to refer to scenario 2.

		=20

	=09
________________________________

		From: Peter Sylvester [mailto:[email-masked]]=20
		Sent: Thursday, March 22, 2007 7:50 AM
		To: Carl Wallace
		Cc: [email-masked]
		Subject: Re: TSA key and revocation checking

		Carl Wallace a =E9crit :=20

		During yesterday's meeting, Tobias mentioned that a TSA key could be =
trusted without checking its revocation status because compromise of the =
key would be a widely known problem.  I asked, via Jabber, how one could =
confirm they had the correct TSA key and was directed to the mailing =
list.  While it may be true that the compromise of the TSA would be =
widely known, would the revocation of a certificate issued in error to =
the same name be as widely known?  Recommending that revocation status =
not be checked seems like a bad idea.  We have means for representing =
and processing revocation information, including the time of compromise, =
and should simply use them.

		 I am not sure what scenario is addressed:
	=09
		1 -  a client that obtains a time stamp and determines the =
aujthenticity of the response
		2 -  a relying party that verifies the time stamp
	=09
	=09
	=09

------_=_NextPart_001_01C76CF0.06680354
Content-Type: text/html;
	charset="iso-8859-1"
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<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]-->
<title>TSA key and revocation checking</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</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:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;
	color:windowtext;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:11.0pt;
	font-family:Arial;
	color:windowtext;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 56.7pt 70.85pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
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 =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree with =
Carl.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
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 =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>For the refreshed time stamps, all =
the
artifacts can be part of the time stamp or obtained from the PKI archive =
per
I-D drafted by Carl.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
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 =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>For current time stamp, objects =
should be
available a la regular PKI.<o:p></o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:windowtext'>

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

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

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b><st1:PersonName w:st=3D"on">Carl =
Wallace</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, March 22, =
2007
3:49 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">[email-masked]</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: validate =
draft - RE:
TSA key and revocation checking</span></font><font color=3Dblack><span
style=3D'color:windowtext'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack 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 color=3Dblue face=3DArial><span =
lang=3DDE
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>In this case, I =
did
correctly understand the intent of your proposal and feel the revocation =
status
of the TSA certs should be checked.&nbsp; I don't see where this =
complicates
things.&nbsp; The TSA is simply another EE certificate and artifacts =
necessary
to verify EE certificates will already be preserved to verify signatures =
on
documents.</span></font><font color=3Dblack><span lang=3DDE =
style=3D'color:windowtext'><o:p></o:p></span></font></p>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=
>

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

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:windowtext'>

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

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;
font-weight:bold'>From:</span></font></b><font size=3D2 color=3Dblack =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext'> Tobias =
Gondrom
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, March 22, =
2007
3:33 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">[email-masked]</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName =
w:st=3D"on">Carl
 Wallace</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> validate draft - =
RE: TSA
key and revocation checking</span></font><font color=3Dblack><span
style=3D'color:windowtext'><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'>Hello Carl, =
Peter,
Santosh and Julien, <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'>thank you for =
bringing
this is up:<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'>At first this is =
just a _<i><span
style=3D'font-style:italic'>proposal</span></i>_ about how to verify and =
what
might be needed. <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'>Stefanie and I =
thought
about what people need to store within the TS in ERS to verify it at any =
later
point in time.<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'>(although we =
have the
protection of the later ArchiveTimestampchains and -sequences for the =
integrity
of the inner data, but still some problems arise due to the fact that =
you can
expect _<i><span style=3D'font-style:italic'>online</span></i>_ status =
requests
to fail e.g. when TSAs shut down or even after guaranteed timeframes of
availability of about 30 years.)<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'>My thoughts in =
the
presentation (as well as in the validate-draft) are the =
following:<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'>0) theoretically =
to
verify a TS it is necessary to store all certificates up to the root =
plus check
their status (especially for revocation). <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'>(and in the case =
that you
are not able to make the status request live and online you may also =
start to
consider to also store all certificates used in signing the OCSP or =
CRLs, and
their certificate chains and their OCSP responses, =
etc.)<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'>1) What I =
proposed is
that to verify a TS from a trusted TSA (e.g. a government body itself or
certified by a government body) it could be (depending on the laws and =
customs
of the specific country) sufficient to only store all certificates up to =
the
root in the RFC3161-TS structures. <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'>This idea is =
based on the
fact that it would be (inevitably) publicly known when a key of a =
certified TSA
would be compromised (and revoked).<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'>This way you =
would not
need to store OCSP or CRL for all certificates (up to the root) used in =
the TS
- and this would make things a lot easier. <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'>Tobias<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'><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'><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'><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'><o:p>&nbsp;</o:p>=
</span></font></p>

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

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:windowtext'>

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

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

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b><st1:PersonName w:st=3D"on">Carl =
Wallace</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, March 22, =
2007
3:28 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">[email-masked]</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: TSA key and
revocation checking</span></font><font color=3Dblack><span =
style=3D'color:windowtext'><o:p></o:p></span></font></p>

</div>

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

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DDE
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>I took the =
comment during
the meeting to refer to&nbsp;scenario 2.</span></font><span =
lang=3DDE><o:p></o:p></span></p>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=
>

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

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

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

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> Peter
Sylvester [mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, March 22, =
2007
7:50 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Carl
 Wallace</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName =
w:st=3D"on">[email-masked]</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: TSA key and
revocation checking</span></font><o:p></o:p></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D3 =
color=3Dblack
 face=3D"Times New Roman"><span lang=3DDE =
style=3D'font-size:12.0pt'>Carl =
Wallace</span></font></st1:PersonName><span
lang=3DDE> a =E9crit&nbsp;: <o:p></o:p></span></p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span lang=3DDE
style=3D'font-size:10.0pt'>During yesterday's meeting, Tobias mentioned =
that a
TSA key could be trusted without checking its revocation status because
compromise of the key would be a widely known problem.&nbsp; I asked, =
via
Jabber, how one could confirm they had the correct TSA key and was =
directed to
the mailing list.&nbsp; While it may be true that the compromise of the =
TSA
would be widely known, would the revocation of a certificate issued in =
error to
the same name be as widely known?&nbsp; Recommending that revocation =
status not
be checked seems like a bad idea.&nbsp; We have means for representing =
and
processing revocation information, including the time of compromise, and =
should
simply use them.</span></font><span lang=3DDE><o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span lang=3DDE =
style=3D'font-size:12.0pt'>&nbsp;I am not
sure what scenario is addressed:<br>
<br>
1 -&nbsp; a client that obtains a time stamp and determines the =
aujthenticity
of the response<br>
2 -&nbsp; a relying party that verifies the time stamp<br>
<br>
<br>
<o:p></o:p></span></font></p>

</blockquote>

</div>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C76CF0.06680354--

From: Carl Wallace <[email-masked]>
To: [email-masked]
Subject: RE: validate draft - RE: TSA key and revocation checking
Date: Thu, 22 Mar 2007 15:49:29 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C76CBB.34754B36
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

In this case, I did correctly understand the intent of your proposal =
and
feel the revocation status of the TSA certs should be checked.  I don't =
see
where this complicates things.  The TSA is simply another EE =
certificate and
artifacts necessary to verify EE certificates will already be preserved =
to
verify signatures on documents.

  _____ =20

From: Tobias Gondrom [mailto:[email-masked]]=20
Sent: Thursday, March 22, 2007 3:33 PM
To: [email-masked]
Cc: Carl Wallace
Subject: validate draft - RE: TSA key and revocation checking

Hello Carl, Peter, Santosh and Julien,=20

=20

thank you for bringing this is up:

At first this is just a _proposal_ about how to verify and what might =
be
needed.=20

Stefanie and I thought about what people need to store within the TS in =
ERS
to verify it at any later point in time.

(although we have the protection of the later ArchiveTimestampchains =
and
-sequences for the integrity of the inner data, but still some problems
arise due to the fact that you can expect _online_ status requests to =
fail
e.g. when TSAs shut down or even after guaranteed timeframes of =
availability
of about 30 years.)

=20

My thoughts in the presentation (as well as in the validate-draft) are =
the
following:

0) theoretically to verify a TS it is necessary to store all =
certificates up
to the root plus check their status (especially for revocation).=20

(and in the case that you are not able to make the status request live =
and
online you may also start to consider to also store all certificates =
used in
signing the OCSP or CRLs, and their certificate chains and their OCSP
responses, etc.)

=20

1) What I proposed is that to verify a TS from a trusted TSA (e.g. a
government body itself or certified by a government body) it could be
(depending on the laws and customs of the specific country) sufficient =
to
only store all certificates up to the root in the RFC3161-TS =
structures.=20

This idea is based on the fact that it would be (inevitably) publicly =
known
when a key of a certified TSA would be compromised (and revoked).

This way you would not need to store OCSP or CRL for all certificates =
(up to
the root) used in the TS - and this would make things a lot easier.=20

=20

Tobias

=20

=20

=20

=20

=20

  _____ =20

From: [email-masked] =
[mailto:[email-masked]]
On Behalf Of Carl Wallace
Sent: Thursday, March 22, 2007 3:28 PM
To: [email-masked]
Subject: RE: TSA key and revocation checking

=20

I took the comment during the meeting to refer to scenario 2.

=20

  _____ =20

From: Peter Sylvester [mailto:[email-masked]]=20
Sent: Thursday, March 22, 2007 7:50 AM
To: Carl Wallace
Cc: [email-masked]
Subject: Re: TSA key and revocation checking

Carl Wallace a =E9crit :=20

During yesterday's meeting, Tobias mentioned that a TSA key could be =
trusted
without checking its revocation status because compromise of the key =
would
be a widely known problem.  I asked, via Jabber, how one could confirm =
they
had the correct TSA key and was directed to the mailing list.  While it =
may
be true that the compromise of the TSA would be widely known, would the
revocation of a certificate issued in error to the same name be as =
widely
known?  Recommending that revocation status not be checked seems like a =
bad
idea.  We have means for representing and processing revocation =
information,
including the time of compromise, and should simply use them.

 I am not sure what scenario is addressed:

1 -  a client that obtains a time stamp and determines the =
aujthenticity of
the response
2 -  a relying party that verifies the time stamp

------_=_NextPart_001_01C76CBB.34754B36
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<TITLE>TSA key and revocation checking</TITLE>

<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR><!--[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-face {
	font-family: Tahoma;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm =
70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; COLOR: black; FONT-FAMILY: =
"Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; COLOR: black; FONT-FAMILY: =
"Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; COLOR: black; FONT-FAMILY: =
"Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; COLOR: black; MARGIN-RIGHT: 0cm; =
FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DDE vLink=3Dpurple link=3Dblue bgColor=3Dwhite>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D752484319-22032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>In this case, I did correctly understand the =
intent of your=20
proposal and feel the revocation status of the TSA certs should be=20
checked.&nbsp; I don't see where this complicates things.&nbsp; The TSA =
is=20
simply another EE certificate and artifacts necessary to verify EE =
certificates=20
will already be preserved to verify signatures on=20
documents.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Tobias Gondrom=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Thursday, March 22, =
2007 3:33=20
  PM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> Carl=20
  Wallace<BR><B>Subject:</B> validate draft - RE: TSA key and =
revocation=20
  checking<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hello =
Carl, Peter,=20
  Santosh and Julien, <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">thank you =
for=20
  bringing this is up:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">At first =
this is just=20
  a _<I><SPAN style=3D"FONT-STYLE: italic">proposal</SPAN></I>_ about =
how to=20
  verify and what might be needed. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Stefanie =
and I=20
  thought about what people need to store within the TS in ERS to =
verify it at=20
  any later point in time.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">(although =
we have the=20
  protection of the later ArchiveTimestampchains and -sequences for the =

  integrity of the inner data, but still some problems arise due to the =
fact=20
  that you can expect _<I><SPAN style=3D"FONT-STYLE: =
italic">online</SPAN></I>_=20
  status requests to fail e.g. when TSAs shut down or even after =
guaranteed=20
  timeframes of availability of about 30 =
years.)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">My =
thoughts in the=20
  presentation (as well as in the validate-draft) are the=20
  following:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">0) =
theoretically to=20
  verify a TS it is necessary to store all certificates up to the root =
plus=20
  check their status (especially for revocation). =
<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">(and in =
the case that=20
  you are not able to make the status request live and online you may =
also start=20
  to consider to also store all certificates used in signing the OCSP =
or CRLs,=20
  and their certificate chains and their OCSP responses,=20
  etc.)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">1) What I =
proposed is=20
  that to verify a TS from a trusted TSA (e.g. a government body itself =
or=20
  certified by a government body) it could be (depending on the laws =
and customs=20
  of the specific country) sufficient to only store all certificates up =
to the=20
  root in the RFC3161-TS structures. <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">This idea =
is based on=20
  the fact that it would be (inevitably) publicly known when a key of a =

  certified TSA would be compromised (and =
revoked).<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">This way =
you would=20
  not need to store OCSP or CRL for all certificates (up to the root) =
used in=20
  the TS - and this would make things a lot easier.=20
<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Tobias<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN =
lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" color=3Dblack size=3D3><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 12pt; COLOR: windowtext">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma color=3Dblack =
size=3D2><SPAN lang=3DEN-US=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: windowtext; =
FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma color=3Dblack size=3D2><SPAN lang=3DEN-US=20
  style=3D"FONT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: Tahoma">=20
  [email-masked] [mailto:[email-masked]] =
<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Carl =
Wallace<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, March 22, 2007 =
3:28=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
  [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B>=20
  RE: TSA key and revocation checking</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  lang=3DEN-US style=3D"COLOR: =
windowtext"><o:p></o:p></SPAN></FONT></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I took the =
comment=20
  during the meeting to refer to&nbsp;scenario =
2.</SPAN></FONT><o:p></o:p></P>
  <BLOCKQUOTE=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm =
5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
    face=3D"Times New Roman" color=3Dblack size=3D3><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 12pt">
    <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
    </SPAN></FONT></DIV>
    <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma=20
    color=3Dblack size=3D2><SPAN lang=3DEN-US=20
    style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
    face=3DTahoma size=3D2><SPAN lang=3DEN-US=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> Peter Sylvester=20
    [mailto:[email-masked]] <BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, March 22, =
2007 7:50=20
    AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Carl=20
    Wallace<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B>=20
    [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B>=20
    Re: TSA key and revocation checking</SPAN></FONT><SPAN=20
    lang=3DEN-US><o:p></o:p></SPAN></P>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">Carl Wallace a =E9crit&nbsp;:=20
    <o:p></o:p></SPAN></FONT></P>
    <P><FONT face=3D"Times New Roman" color=3Dblack size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">During yesterday's meeting, Tobias =
mentioned that a=20
    TSA key could be trusted without checking its revocation status =
because=20
    compromise of the key would be a widely known problem.&nbsp; I =
asked, via=20
    Jabber, how one could confirm they had the correct TSA key and was =
directed=20
    to the mailing list.&nbsp; While it may be true that the compromise =
of the=20
    TSA would be widely known, would the revocation of a certificate =
issued in=20
    error to the same name be as widely known?&nbsp; Recommending that=20
    revocation status not be checked seems like a bad idea.&nbsp; We =
have means=20
    for representing and processing revocation information, including =
the time=20
    of compromise, and should simply use =
them.</SPAN></FONT><o:p></o:p></P>
    <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT =
face=3D"Times New Roman"=20
    color=3Dblack size=3D3><SPAN style=3D"FONT-SIZE: 12pt">&nbsp;I am =
not sure what=20
    scenario is addressed:<BR><BR>1 -&nbsp; a client that obtains a =
time stamp=20
    and determines the aujthenticity of the response<BR>2 -&nbsp; a =
relying=20
    party that verifies the time=20
    =
stamp<BR><BR><BR><BR><o:p></o:p></SPAN></FONT></P></BLOCKQUOTE></DIV></D=
IV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C76CBB.34754B36--

Content-class: urn:content-classes:message
Subject: validate draft - RE: TSA key and revocation checking
Date: Thu, 22 Mar 2007 20:33:24 +0100
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Cc: "Carl Wallace" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C76CB8.F57876D7
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Carl, Peter, Santosh and Julien,=20

=20

thank you for bringing this is up:

At first this is just a _proposal_ about how to verify and what might be =
needed.=20

Stefanie and I thought about what people need to store within the TS in =
ERS to verify it at any later point in time.

(although we have the protection of the later ArchiveTimestampchains and =
-sequences for the integrity of the inner data, but still some problems =
arise due to the fact that you can expect _online_ status requests to =
fail e.g. when TSAs shut down or even after guaranteed timeframes of =
availability of about 30 years.)

=20

My thoughts in the presentation (as well as in the validate-draft) are =
the following:

0) theoretically to verify a TS it is necessary to store all =
certificates up to the root plus check their status (especially for =
revocation).=20

(and in the case that you are not able to make the status request live =
and online you may also start to consider to also store all certificates =
used in signing the OCSP or CRLs, and their certificate chains and their =
OCSP responses, etc.)

=20

1) What I proposed is that to verify a TS from a trusted TSA (e.g. a =
government body itself or certified by a government body) it could be =
(depending on the laws and customs of the specific country) sufficient =
to only store all certificates up to the root in the RFC3161-TS =
structures.=20

This idea is based on the fact that it would be (inevitably) publicly =
known when a key of a certified TSA would be compromised (and revoked).

This way you would not need to store OCSP or CRL for all certificates =
(up to the root) used in the TS - and this would make things a lot =
easier.=20

=20

Tobias

=20

=20

=20

=20

=20

________________________________

From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Carl Wallace
Sent: Thursday, March 22, 2007 3:28 PM
To: [email-masked]
Subject: RE: TSA key and revocation checking

=20

I took the comment during the meeting to refer to scenario 2.

	=20

=09
________________________________

	From: Peter Sylvester [mailto:[email-masked]]=20
	Sent: Thursday, March 22, 2007 7:50 AM
	To: Carl Wallace
	Cc: [email-masked]
	Subject: Re: TSA key and revocation checking

	Carl Wallace a =E9crit :=20

	During yesterday's meeting, Tobias mentioned that a TSA key could be =
trusted without checking its revocation status because compromise of the =
key would be a widely known problem.  I asked, via Jabber, how one could =
confirm they had the correct TSA key and was directed to the mailing =
list.  While it may be true that the compromise of the TSA would be =
widely known, would the revocation of a certificate issued in error to =
the same name be as widely known?  Recommending that revocation status =
not be checked seems like a bad idea.  We have means for representing =
and processing revocation information, including the time of compromise, =
and should simply use them.

	 I am not sure what scenario is addressed:
=09
	1 -  a client that obtains a time stamp and determines the =
aujthenticity of the response
	2 -  a relying party that verifies the time stamp
=09
=09
=09
=09

------_=_NextPart_001_01C76CB8.F57876D7
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<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]-->
<title>TSA key and revocation checking</title>
<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";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DDE 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'>Hello Carl, =
Peter,
Santosh and Julien, <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'>thank you for =
bringing
this is up:<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'>At first this is =
just a _<i><span
style=3D'font-style:italic'>proposal</span></i>_ about how to verify and =
what
might be needed. <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'>Stefanie and I =
thought
about what people need to store within the TS in ERS to verify it at any =
later
point in time.<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'>(although we =
have the
protection of the later ArchiveTimestampchains and &#8211;sequences for =
the integrity
of the inner data, but still some problems arise due to the fact that =
you can
expect _<i><span style=3D'font-style:italic'>online</span></i>_ status =
requests to
fail e.g. when TSAs shut down or even after guaranteed timeframes of
availability of about 30 years.)<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'>My thoughts in =
the
presentation (as well as in the validate-draft) are the =
following:<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'>0) theoretically =
to
verify a TS it is necessary to store all certificates up to the root =
plus check
their status (especially for revocation). <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'>(and in the case =
that you
are not able to make the status request live and online you may also =
start to
consider to also store all certificates used in signing the OCSP or =
CRLs, and
their certificate chains and their OCSP responses, =
etc.)<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'>1) What I =
proposed is
that to verify a TS from a trusted TSA (e.g. a government body itself or =
certified
by a government body) it could be (depending on the laws and customs of =
the specific
country) sufficient to only store all certificates up to the root in the
RFC3161-TS structures. <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'>This idea is =
based on the
fact that it would be (inevitably) publicly known when a key of a =
certified TSA
would be compromised (and revoked).<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'>This way you =
would not
need to store OCSP or CRL for all certificates (up to the root) used in =
the TS &#8211;
and this would make things a lot easier. <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'>Tobias<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'><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'><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'><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'><o:p>&nbsp;</o:p>=
</span></font></p>

<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
color=3Dblack face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;
color:windowtext'>

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

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

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:Tahoma;color:windowtext'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Carl Wallace<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, March 22, =
2007
3:28 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: TSA key and
revocation checking</span></font><font color=3Dblack><span lang=3DEN-US
style=3D'color:windowtext'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack 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 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I took the comment during the =
meeting to
refer to&nbsp;scenario 2.</span></font><o:p></o:p></p>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=
>

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

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack 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 style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
color=3Dblack
face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma;
font-weight:bold'>From:</span></font></b><font size=3D2 =
face=3DTahoma><span
lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma'> Peter =
Sylvester
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, March 22, =
2007
7:50 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Carl Wallace<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: TSA key and
revocation checking</span></font><span =
lang=3DEN-US><o:p></o:p></span></p>

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

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>During
yesterday's meeting, Tobias mentioned that a TSA key could be trusted =
without
checking its revocation status because compromise of the key would be a =
widely
known problem.&nbsp; I asked, via Jabber, how one could confirm they had =
the
correct TSA key and was directed to the mailing list.&nbsp; While it may =
be
true that the compromise of the TSA would be widely known, would the =
revocation
of a certificate issued in error to the same name be as widely =
known?&nbsp;
Recommending that revocation status not be checked seems like a bad =
idea.&nbsp;
We have means for representing and processing revocation information, =
including
the time of compromise, and should simply use =
them.</span></font><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>&nbsp;I am not =
sure what
scenario is addressed:<br>
<br>
1 -&nbsp; a client that obtains a time stamp and determines the =
aujthenticity
of the response<br>
2 -&nbsp; a relying party that verifies the time stamp<br>
<br>
<br>
<br>
<o:p></o:p></span></font></p>

</blockquote>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C76CB8.F57876D7--

From: Carl Wallace <[email-masked]>
To: [email-masked]
Subject: RE: TSA key and revocation checking
Date: Thu, 22 Mar 2007 10:28:22 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C76C8E.58751240
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

I took the comment during the meeting to refer to scenario 2.

  _____ =20

From: Peter Sylvester [mailto:[email-masked]]=20
Sent: Thursday, March 22, 2007 7:50 AM
To: Carl Wallace
Cc: [email-masked]
Subject: Re: TSA key and revocation checking

Carl Wallace a =E9crit :=20

During yesterday's meeting, Tobias mentioned that a TSA key could be =
trusted
without checking its revocation status because compromise of the key =
would
be a widely known problem.  I asked, via Jabber, how one could confirm =
they
had the correct TSA key and was directed to the mailing list.  While it =
may
be true that the compromise of the TSA would be widely known, would the
revocation of a certificate issued in error to the same name be as =
widely
known?  Recommending that revocation status not be checked seems like a =
bad
idea.  We have means for representing and processing revocation =
information,
including the time of compromise, and should simply use them.

 I am not sure what scenario is addressed:

1 -  a client that obtains a time stamp and determines the =
aujthenticity of
the response
2 -  a relying party that verifies the time stamp

------_=_NextPart_001_01C76C8E.58751240
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<TITLE>TSA key and revocation checking</TITLE>

<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D965532714-22032007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I took the comment during the meeting to refer =

to&nbsp;scenario 2.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Peter Sylvester=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Thursday, March =
22, 2007=20
  7:50 AM<BR><B>To:</B> Carl Wallace<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> Re: TSA key and revocation=20
  checking<BR></FONT><BR></DIV>
  <DIV></DIV>Carl Wallace a =E9crit&nbsp;:=20
  <BLOCKQUOTE=20
  =
cite=[email-masked]=
=20
  type=3D"cite">
    <META content=3D"MS Exchange Server version 5.5.2658.34" =
name=3DGenerator>
    <P><FONT size=3D2>During yesterday's meeting, Tobias mentioned that =
a TSA key=20
    could be trusted without checking its revocation status because =
compromise=20
    of the key would be a widely known problem.&nbsp; I asked, via =
Jabber, how=20
    one could confirm they had the correct TSA key and was directed to =
the=20
    mailing list.&nbsp; While it may be true that the compromise of the =
TSA=20
    would be widely known, would the revocation of a certificate issued =
in error=20
    to the same name be as widely known?&nbsp; Recommending that =
revocation=20
    status not be checked seems like a bad idea.&nbsp; We have means =
for=20
    representing and processing revocation information, including the =
time of=20
    compromise, and should simply use =
them.</FONT></P></BLOCKQUOTE>&nbsp;I am not=20
  sure what scenario is addressed:<BR><BR>1 -&nbsp; a client that =
obtains a time=20
  stamp and determines the aujthenticity of the response<BR>2 -&nbsp; a =
relying=20
  party that verifies the time=20
stamp<BR><BR><BR><BR><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C76C8E.58751240--

Date: Thu, 22 Mar 2007 12:49:47 +0100
From: Peter Sylvester <[email-masked]>
To: Carl Wallace <[email-masked]>
CC: [email-masked]
Subject: Re: TSA key and revocation checking
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060203070402050504070103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Carl Wallace a écrit :
>
> During yesterday's meeting, Tobias mentioned that a TSA key could be 
> trusted without checking its revocation status because compromise of 
> the key would be a widely known problem.  I asked, via Jabber, how one 
> could confirm they had the correct TSA key and was directed to the 
> mailing list.  While it may be true that the compromise of the TSA 
> would be widely known, would the revocation of a certificate issued in 
> error to the same name be as widely known?  Recommending that 
> revocation status not be checked seems like a bad idea.  We have means 
> for representing and processing revocation information, including the 
> time of compromise, and should simply use them.
>
 I am not sure what scenario is addressed:

1 -  a client that obtains a time stamp and determines the aujthenticity 
of the response
2 -  a relying party that verifies the time stamp

--------------060203070402050504070103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Carl Wallace a &eacute;crit&nbsp;:
<blockquote
 cite="[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 5.5.2658.34">
  <title>TSA key and revocation checking</title>
  <p><font size="2">During yesterday's meeting, Tobias mentioned that a
TSA key could be trusted without checking its revocation status because
compromise of the key would be a widely known problem.&nbsp; I asked, via
Jabber, how one could confirm they had the correct TSA key and was
directed to the mailing list.&nbsp; While it may be true that the compromise
of the TSA would be widely known, would the revocation of a certificate
issued in error to the same name be as widely known?&nbsp; Recommending that
revocation status not be checked seems like a bad idea.&nbsp; We have means
for representing and processing revocation information, including the
time of compromise, and should simply use them.</font></p>
</blockquote>
&nbsp;I am not sure what scenario is addressed:<br>
<br>
1 -&nbsp; a client that obtains a time stamp and determines the
aujthenticity of the response<br>
2 -&nbsp; a relying party that verifies the time stamp<br>
<br>
<br>
<br>
<br>
</body>
</html>

--------------060203070402050504070103--

From: "Julien Stern" <[email-masked]>
Date: Wed, 21 Mar 2007 19:26:21 +0100
To: [email-masked]
Subject: Re: TSA key and revocation checking
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

Santosh, Carl,

thanks to you both for your replies.

To summarize:
- a TSA cert is certified by a CA and chains to a Trust Anchor
- the old revocation artifacts of the inner timestamps need not
  be retrieved as they have been checked during refreshing (and/or
  have been protected by inner timestamps)
- the old revocation artifacts of the outer timestamp needs not
  be retrieved as the revocation checking is done at current time

This prohibits the revocation followed by the Remove_From_CRL of the TSA
certificate, but I guess no-one would want to do that anyway :)

After your clarification, I'm definitely also for standard revocation
checking of the TSA certificate and not for out-of-band mechanisms.

Sorry for the interruption and thanks again.

--
Julien

On Wed, Mar 21, 2007 at 10:51:51AM -0700, Santosh Chokhani wrote:
> 
> Julien,
> 
> As Carl Wallace said, for the out most time stamp you need not save the
> trust anchor or CRL.  That should be verified as of present time.
> 
> I may be wrong, but the LTANS specs do not address compromise recovery,
> i.e., what to do about time stamps if the TSA revoked (compromised)
> before a time stamp is refreshed.
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Julien Stern
> Sent: Wednesday, March 21, 2007 11:07 AM
> To: [email-masked]
> Subject: Re: TSA key and revocation checking
> 
> 
> On Wed, Mar 21, 2007 at 07:50:41AM -0700, Santosh Chokhani wrote:
> > 
> > Julien,
> > 
> > If you have not used LTANS work of trusted archive (time stamp
> refresh)
> > and protected the payload, you should be able to verify the time stamp
> > as of the time of time stamp using the revocation artifacts as of that
> > time.
> > 
> > If you are using LTANS trusted archive, look at the step 3 in Section
> > 5.3 of ERS I-D.  It calls for verifying each time stamp as of the time
> > of the next time stamp. In other words, time stamp must be refreshed
> > before the TSA is revoked or expires.
> 
> Santosh,
> 
> I'm all for avoiding the need to store old revocation artifacts,
> especially since they may become invalid at any time after a compromise.
> 
> Also, I have no issue with all the "internal" layers. My only question
> regards the outer layer. In order to verify the outer timestamp
> signature, it seems to me that you need in any case to retrieve the
> revocation artifacts at the time the timestamp was made. But maybe I'm
> missing an hypothesis that enables verification with current revocation
> information instead.
> 
> --
> Julien
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Julien Stern
> > Sent: Wednesday, March 21, 2007 10:08 AM
> > To: [email-masked]
> > Subject: Re: TSA key and revocation checking
> > 
> > 
> > On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote:
> > > I agree with Carl.  Not checking revocation status and relying on
> > > non-automated, other means is a bad idea.
> > 
> > I agree on the general principle. But in the specific LTANS settings,
> I
> > think the TSA certificate will be in some sense more "trusted" than
> the
> > CA that issued it.
> > 
> > The specific setting I have in mind is the following:
> > - say you are doing long term archiving (of signatures for instance)
> > - also say that you have archived ALL artifacts (certs, OCSP, CRLs,
> etc)
> > - Many years after, you want to check your archive
> > 
> > If the TSA key is not trusted out-of-band, you need information to
> > verify its revocation status, but this information cannot be included
> > in the timestamped archive itself as that would cause a chicken and
> egg
> > problem. Question: how do you obtain it ?
> > 
> > I one can come up with a solution that solves this chicken and egg
> > and allows for revocation checking, I'm all for it, but we have to
> > keep this issue in mind.
> > 
> > --
> > Julien
> > 
> > > ________________________________
> > > 
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Carl Wallace
> > > Sent: Wednesday, March 21, 2007 6:46 AM
> > > To: [email-masked]
> > > Subject: TSA key and revocation checking
> > > 
> > >  
> > > 
> > > During yesterday's meeting, Tobias mentioned that a TSA key could be
> > > trusted without checking its revocation status because compromise of
> > the
> > > key would be a widely known problem.  I asked, via Jabber, how one
> > could
> > > confirm they had the correct TSA key and was directed to the mailing
> > > list.  While it may be true that the compromise of the TSA would be
> > > widely known, would the revocation of a certificate issued in error
> to
> > > the same name be as widely known?  Recommending that revocation
> status
> > > not be checked seems like a bad idea.  We have means for
> representing
> > > and processing revocation information, including the time of
> > compromise,
> > > and should simply use them.
> > > 
> > 
> > 
> 
> 

From: "todd glassey" <[email-masked]>
To: "Greg Werner" <[email-masked]>, "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Subject: Re: TSA key and revocation checking
Date: Wed, 21 Mar 2007 11:23:50 -0700
Sender: [email-masked]

----- Original Message ----- 
From: "Greg Werner" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 21, 2007 11:11 AM
Subject: RE: TSA key and revocation checking

>
> From what I understand Policies and Practices would define mechanisms for 
> infrastructure or trust transfer (i.e. takeovers, mergers, insolvency, 
> etc.). Each country or region would define these mechanisms in order to 
> establish procedures and the proper legal framework for continued 
> operations.

The problem is in digitally negotiating which T's and C's are constraining 
any TST's and the legal framework therein.

>
> From a technical perspective once the user receives an EOL notification 
> for a particular TSA he/she would have to manually refresh all roots to 
> establish new and updated trust points.

This is reasonable

> Or, another preventive option is to check revocation status for outer 
> layer trust anchors on a periodic basis (once per day or week) and if the 
> TSA root is no longer valid (revoked) then time stamp records from that 
> particular authority should no longer be accepted.
>
> Does this make sense?

yes, periodic review of the TSA Integrity is a good idea... but should be 
capable of being optionally ignored.

>
> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] 
> En nombre de Santosh Chokhani
> Enviado el: Miércoles, 21 de Marzo de 2007 11:52 a.m.
> Para: [email-masked]
> Asunto: RE: TSA key and revocation checking
>
>
> Julien,
>
> As Carl Wallace said, for the out most time stamp you need not save the
> trust anchor or CRL.  That should be verified as of present time.
>
> I may be wrong, but the LTANS specs do not address compromise recovery,
> i.e., what to do about time stamps if the TSA revoked (compromised)
> before a time stamp is refreshed.
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Julien Stern
> Sent: Wednesday, March 21, 2007 11:07 AM
> To: [email-masked]
> Subject: Re: TSA key and revocation checking
>
>
> On Wed, Mar 21, 2007 at 07:50:41AM -0700, Santosh Chokhani wrote:
>>
>> Julien,
>>
>> If you have not used LTANS work of trusted archive (time stamp
> refresh)
>> and protected the payload, you should be able to verify the time stamp
>> as of the time of time stamp using the revocation artifacts as of that
>> time.
>>
>> If you are using LTANS trusted archive, look at the step 3 in Section
>> 5.3 of ERS I-D.  It calls for verifying each time stamp as of the time
>> of the next time stamp. In other words, time stamp must be refreshed
>> before the TSA is revoked or expires.
>
> Santosh,
>
> I'm all for avoiding the need to store old revocation artifacts,
> especially since they may become invalid at any time after a compromise.
>
> Also, I have no issue with all the "internal" layers. My only question
> regards the outer layer. In order to verify the outer timestamp
> signature, it seems to me that you need in any case to retrieve the
> revocation artifacts at the time the timestamp was made. But maybe I'm
> missing an hypothesis that enables verification with current revocation
> information instead.
>
> --
> Julien
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Julien Stern
>> Sent: Wednesday, March 21, 2007 10:08 AM
>> To: [email-masked]
>> Subject: Re: TSA key and revocation checking
>>
>>
>> On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote:
>> > I agree with Carl.  Not checking revocation status and relying on
>> > non-automated, other means is a bad idea.
>>
>> I agree on the general principle. But in the specific LTANS settings,
> I
>> think the TSA certificate will be in some sense more "trusted" than
> the
>> CA that issued it.
>>
>> The specific setting I have in mind is the following:
>> - say you are doing long term archiving (of signatures for instance)
>> - also say that you have archived ALL artifacts (certs, OCSP, CRLs,
> etc)
>> - Many years after, you want to check your archive
>>
>> If the TSA key is not trusted out-of-band, you need information to
>> verify its revocation status, but this information cannot be included
>> in the timestamped archive itself as that would cause a chicken and
> egg
>> problem. Question: how do you obtain it ?
>>
>> I one can come up with a solution that solves this chicken and egg
>> and allows for revocation checking, I'm all for it, but we have to
>> keep this issue in mind.
>>
>> --
>> Julien
>>
>> > ________________________________
>> >
>> > From: [email-masked]
>> > [mailto:[email-masked]] On Behalf Of Carl Wallace
>> > Sent: Wednesday, March 21, 2007 6:46 AM
>> > To: [email-masked]
>> > Subject: TSA key and revocation checking
>> >
>> >
>> >
>> > During yesterday's meeting, Tobias mentioned that a TSA key could be
>> > trusted without checking its revocation status because compromise of
>> the
>> > key would be a widely known problem.  I asked, via Jabber, how one
>> could
>> > confirm they had the correct TSA key and was directed to the mailing
>> > list.  While it may be true that the compromise of the TSA would be
>> > widely known, would the revocation of a certificate issued in error
> to
>> > the same name be as widely known?  Recommending that revocation
> status
>> > not be checked seems like a bad idea.  We have means for
> representing
>> > and processing revocation information, including the time of
>> compromise,
>> > and should simply use them.
>> >
>>
>>
>
>
>
> 

Content-class: urn:content-classes:message
Subject: RE: TSA key and revocation checking
Date: Wed, 21 Mar 2007 11:20:14 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Greg Werner" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Greg,

Unless you define procedural means, there is a residual threat on detection of TSA compromise before the time stamp is refreshed.

It is possible that if the immediately inner layer is still valid (nothing expired or revoked) and in that case, throwing out the outer layer and getting a new time stamp from a new authority makes sense.

-----Original Message-----
From: Greg Werner [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 2:11 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: TSA key and revocation checking

>From what I understand Policies and Practices would define mechanisms for infrastructure or trust transfer (i.e. takeovers, mergers, insolvency, etc.). Each country or region would define these mechanisms in order to establish procedures and the proper legal framework for continued operations. 

>From a technical perspective once the user receives an EOL notification for a particular TSA he/she would have to manually refresh all roots to establish new and updated trust points. Or, another preventive option is to check revocation status for outer layer trust anchors on a periodic basis (once per day or week) and if the TSA root is no longer valid (revoked) then time stamp records from that particular authority should no longer be accepted. 

Does this make sense?

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Santosh Chokhani
Enviado el: Miércoles, 21 de Marzo de 2007 11:52 a.m.
Para: [email-masked]
Asunto: RE: TSA key and revocation checking

Julien,

As Carl Wallace said, for the out most time stamp you need not save the
trust anchor or CRL.  That should be verified as of present time.

I may be wrong, but the LTANS specs do not address compromise recovery,
i.e., what to do about time stamps if the TSA revoked (compromised)
before a time stamp is refreshed.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Julien Stern
Sent: Wednesday, March 21, 2007 11:07 AM
To: [email-masked]
Subject: Re: TSA key and revocation checking

On Wed, Mar 21, 2007 at 07:50:41AM -0700, Santosh Chokhani wrote:
> 
> Julien,
> 
> If you have not used LTANS work of trusted archive (time stamp
refresh)
> and protected the payload, you should be able to verify the time stamp
> as of the time of time stamp using the revocation artifacts as of that
> time.
> 
> If you are using LTANS trusted archive, look at the step 3 in Section
> 5.3 of ERS I-D.  It calls for verifying each time stamp as of the time
> of the next time stamp. In other words, time stamp must be refreshed
> before the TSA is revoked or expires.

Santosh,

I'm all for avoiding the need to store old revocation artifacts,
especially since they may become invalid at any time after a compromise.

Also, I have no issue with all the "internal" layers. My only question
regards the outer layer. In order to verify the outer timestamp
signature, it seems to me that you need in any case to retrieve the
revocation artifacts at the time the timestamp was made. But maybe I'm
missing an hypothesis that enables verification with current revocation
information instead.

--
Julien

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Julien Stern
> Sent: Wednesday, March 21, 2007 10:08 AM
> To: [email-masked]
> Subject: Re: TSA key and revocation checking
> 
> 
> On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote:
> > I agree with Carl.  Not checking revocation status and relying on
> > non-automated, other means is a bad idea.
> 
> I agree on the general principle. But in the specific LTANS settings,
I
> think the TSA certificate will be in some sense more "trusted" than
the
> CA that issued it.
> 
> The specific setting I have in mind is the following:
> - say you are doing long term archiving (of signatures for instance)
> - also say that you have archived ALL artifacts (certs, OCSP, CRLs,
etc)
> - Many years after, you want to check your archive
> 
> If the TSA key is not trusted out-of-band, you need information to
> verify its revocation status, but this information cannot be included
> in the timestamped archive itself as that would cause a chicken and
egg
> problem. Question: how do you obtain it ?
> 
> I one can come up with a solution that solves this chicken and egg
> and allows for revocation checking, I'm all for it, but we have to
> keep this issue in mind.
> 
> --
> Julien
> 
> > ________________________________
> > 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Carl Wallace
> > Sent: Wednesday, March 21, 2007 6:46 AM
> > To: [email-masked]
> > Subject: TSA key and revocation checking
> > 
> >  
> > 
> > During yesterday's meeting, Tobias mentioned that a TSA key could be
> > trusted without checking its revocation status because compromise of
> the
> > key would be a widely known problem.  I asked, via Jabber, how one
> could
> > confirm they had the correct TSA key and was directed to the mailing
> > list.  While it may be true that the compromise of the TSA would be
> > widely known, would the revocation of a certificate issued in error
to
> > the same name be as widely known?  Recommending that revocation
status
> > not be checked seems like a bad idea.  We have means for
representing
> > and processing revocation information, including the time of
> compromise,
> > and should simply use them.
> > 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: TSA key and revocation checking
Date: Wed, 21 Mar 2007 12:11:06 -0600
From: "Greg Werner" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

>From what I understand Policies and Practices would define mechanisms for infrastructure or trust transfer (i.e. takeovers, mergers, insolvency, etc.). Each country or region would define these mechanisms in order to establish procedures and the proper legal framework for continued operations. 

>From a technical perspective once the user receives an EOL notification for a particular TSA he/she would have to manually refresh all roots to establish new and updated trust points. Or, another preventive option is to check revocation status for outer layer trust anchors on a periodic basis (once per day or week) and if the TSA root is no longer valid (revoked) then time stamp records from that particular authority should no longer be accepted. 

Does this make sense?

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Santosh Chokhani
Enviado el: Miércoles, 21 de Marzo de 2007 11:52 a.m.
Para: [email-masked]
Asunto: RE: TSA key and revocation checking

Julien,

As Carl Wallace said, for the out most time stamp you need not save the
trust anchor or CRL.  That should be verified as of present time.

I may be wrong, but the LTANS specs do not address compromise recovery,
i.e., what to do about time stamps if the TSA revoked (compromised)
before a time stamp is refreshed.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Julien Stern
Sent: Wednesday, March 21, 2007 11:07 AM
To: [email-masked]
Subject: Re: TSA key and revocation checking

On Wed, Mar 21, 2007 at 07:50:41AM -0700, Santosh Chokhani wrote:
> 
> Julien,
> 
> If you have not used LTANS work of trusted archive (time stamp
refresh)
> and protected the payload, you should be able to verify the time stamp
> as of the time of time stamp using the revocation artifacts as of that
> time.
> 
> If you are using LTANS trusted archive, look at the step 3 in Section
> 5.3 of ERS I-D.  It calls for verifying each time stamp as of the time
> of the next time stamp. In other words, time stamp must be refreshed
> before the TSA is revoked or expires.

Santosh,

I'm all for avoiding the need to store old revocation artifacts,
especially since they may become invalid at any time after a compromise.

Also, I have no issue with all the "internal" layers. My only question
regards the outer layer. In order to verify the outer timestamp
signature, it seems to me that you need in any case to retrieve the
revocation artifacts at the time the timestamp was made. But maybe I'm
missing an hypothesis that enables verification with current revocation
information instead.

--
Julien

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Julien Stern
> Sent: Wednesday, March 21, 2007 10:08 AM
> To: [email-masked]
> Subject: Re: TSA key and revocation checking
> 
> 
> On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote:
> > I agree with Carl.  Not checking revocation status and relying on
> > non-automated, other means is a bad idea.
> 
> I agree on the general principle. But in the specific LTANS settings,
I
> think the TSA certificate will be in some sense more "trusted" than
the
> CA that issued it.
> 
> The specific setting I have in mind is the following:
> - say you are doing long term archiving (of signatures for instance)
> - also say that you have archived ALL artifacts (certs, OCSP, CRLs,
etc)
> - Many years after, you want to check your archive
> 
> If the TSA key is not trusted out-of-band, you need information to
> verify its revocation status, but this information cannot be included
> in the timestamped archive itself as that would cause a chicken and
egg
> problem. Question: how do you obtain it ?
> 
> I one can come up with a solution that solves this chicken and egg
> and allows for revocation checking, I'm all for it, but we have to
> keep this issue in mind.
> 
> --
> Julien
> 
> > ________________________________
> > 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Carl Wallace
> > Sent: Wednesday, March 21, 2007 6:46 AM
> > To: [email-masked]
> > Subject: TSA key and revocation checking
> > 
> >  
> > 
> > During yesterday's meeting, Tobias mentioned that a TSA key could be
> > trusted without checking its revocation status because compromise of
> the
> > key would be a widely known problem.  I asked, via Jabber, how one
> could
> > confirm they had the correct TSA key and was directed to the mailing
> > list.  While it may be true that the compromise of the TSA would be
> > widely known, would the revocation of a certificate issued in error
to
> > the same name be as widely known?  Recommending that revocation
status
> > not be checked seems like a bad idea.  We have means for
representing
> > and processing revocation information, including the time of
> compromise,
> > and should simply use them.
> > 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: TSA key and revocation checking
Date: Wed, 21 Mar 2007 10:51:51 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Julien,

As Carl Wallace said, for the out most time stamp you need not save the
trust anchor or CRL.  That should be verified as of present time.

I may be wrong, but the LTANS specs do not address compromise recovery,
i.e., what to do about time stamps if the TSA revoked (compromised)
before a time stamp is refreshed.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Julien Stern
Sent: Wednesday, March 21, 2007 11:07 AM
To: [email-masked]
Subject: Re: TSA key and revocation checking

On Wed, Mar 21, 2007 at 07:50:41AM -0700, Santosh Chokhani wrote:
> 
> Julien,
> 
> If you have not used LTANS work of trusted archive (time stamp
refresh)
> and protected the payload, you should be able to verify the time stamp
> as of the time of time stamp using the revocation artifacts as of that
> time.
> 
> If you are using LTANS trusted archive, look at the step 3 in Section
> 5.3 of ERS I-D.  It calls for verifying each time stamp as of the time
> of the next time stamp. In other words, time stamp must be refreshed
> before the TSA is revoked or expires.

Santosh,

I'm all for avoiding the need to store old revocation artifacts,
especially since they may become invalid at any time after a compromise.

Also, I have no issue with all the "internal" layers. My only question
regards the outer layer. In order to verify the outer timestamp
signature, it seems to me that you need in any case to retrieve the
revocation artifacts at the time the timestamp was made. But maybe I'm
missing an hypothesis that enables verification with current revocation
information instead.

--
Julien

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Julien Stern
> Sent: Wednesday, March 21, 2007 10:08 AM
> To: [email-masked]
> Subject: Re: TSA key and revocation checking
> 
> 
> On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote:
> > I agree with Carl.  Not checking revocation status and relying on
> > non-automated, other means is a bad idea.
> 
> I agree on the general principle. But in the specific LTANS settings,
I
> think the TSA certificate will be in some sense more "trusted" than
the
> CA that issued it.
> 
> The specific setting I have in mind is the following:
> - say you are doing long term archiving (of signatures for instance)
> - also say that you have archived ALL artifacts (certs, OCSP, CRLs,
etc)
> - Many years after, you want to check your archive
> 
> If the TSA key is not trusted out-of-band, you need information to
> verify its revocation status, but this information cannot be included
> in the timestamped archive itself as that would cause a chicken and
egg
> problem. Question: how do you obtain it ?
> 
> I one can come up with a solution that solves this chicken and egg
> and allows for revocation checking, I'm all for it, but we have to
> keep this issue in mind.
> 
> --
> Julien
> 
> > ________________________________
> > 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Carl Wallace
> > Sent: Wednesday, March 21, 2007 6:46 AM
> > To: [email-masked]
> > Subject: TSA key and revocation checking
> > 
> >  
> > 
> > During yesterday's meeting, Tobias mentioned that a TSA key could be
> > trusted without checking its revocation status because compromise of
> the
> > key would be a widely known problem.  I asked, via Jabber, how one
> could
> > confirm they had the correct TSA key and was directed to the mailing
> > list.  While it may be true that the compromise of the TSA would be
> > widely known, would the revocation of a certificate issued in error
to
> > the same name be as widely known?  Recommending that revocation
status
> > not be checked seems like a bad idea.  We have means for
representing
> > and processing revocation information, including the time of
> compromise,
> > and should simply use them.
> > 
> 
> 

From: "Julien Stern" <[email-masked]>
Date: Wed, 21 Mar 2007 16:07:15 +0100
To: [email-masked]
Subject: Re: TSA key and revocation checking
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Mar 21, 2007 at 07:50:41AM -0700, Santosh Chokhani wrote:
> 
> Julien,
> 
> If you have not used LTANS work of trusted archive (time stamp refresh)
> and protected the payload, you should be able to verify the time stamp
> as of the time of time stamp using the revocation artifacts as of that
> time.
> 
> If you are using LTANS trusted archive, look at the step 3 in Section
> 5.3 of ERS I-D.  It calls for verifying each time stamp as of the time
> of the next time stamp. In other words, time stamp must be refreshed
> before the TSA is revoked or expires.

Santosh,

I'm all for avoiding the need to store old revocation artifacts,
especially since they may become invalid at any time after a compromise.

Also, I have no issue with all the "internal" layers. My only question
regards the outer layer. In order to verify the outer timestamp
signature, it seems to me that you need in any case to retrieve the
revocation artifacts at the time the timestamp was made. But maybe I'm
missing an hypothesis that enables verification with current revocation
information instead.

--
Julien

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Julien Stern
> Sent: Wednesday, March 21, 2007 10:08 AM
> To: [email-masked]
> Subject: Re: TSA key and revocation checking
> 
> 
> On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote:
> > I agree with Carl.  Not checking revocation status and relying on
> > non-automated, other means is a bad idea.
> 
> I agree on the general principle. But in the specific LTANS settings, I
> think the TSA certificate will be in some sense more "trusted" than the
> CA that issued it.
> 
> The specific setting I have in mind is the following:
> - say you are doing long term archiving (of signatures for instance)
> - also say that you have archived ALL artifacts (certs, OCSP, CRLs, etc)
> - Many years after, you want to check your archive
> 
> If the TSA key is not trusted out-of-band, you need information to
> verify its revocation status, but this information cannot be included
> in the timestamped archive itself as that would cause a chicken and egg
> problem. Question: how do you obtain it ?
> 
> I one can come up with a solution that solves this chicken and egg
> and allows for revocation checking, I'm all for it, but we have to
> keep this issue in mind.
> 
> --
> Julien
> 
> > ________________________________
> > 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Carl Wallace
> > Sent: Wednesday, March 21, 2007 6:46 AM
> > To: [email-masked]
> > Subject: TSA key and revocation checking
> > 
> >  
> > 
> > During yesterday's meeting, Tobias mentioned that a TSA key could be
> > trusted without checking its revocation status because compromise of
> the
> > key would be a widely known problem.  I asked, via Jabber, how one
> could
> > confirm they had the correct TSA key and was directed to the mailing
> > list.  While it may be true that the compromise of the TSA would be
> > widely known, would the revocation of a certificate issued in error to
> > the same name be as widely known?  Recommending that revocation status
> > not be checked seems like a bad idea.  We have means for representing
> > and processing revocation information, including the time of
> compromise,
> > and should simply use them.
> > 
> 
> 

From: Carl Wallace <[email-masked]>
To: [email-masked]
Subject: RE: TSA key and revocation checking
Date: Wed, 21 Mar 2007 11:07:31 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C76BCA.A60101C8
Content-Type: text/plain

> Doesn't this mean that you need to provide the verification 
> algorithm with the current trust anchor and the revocation 
> information AT THE TIME the outer layer was timestamped? 
> (Implying the need to keep all revocation material for the 
> current CAs for a long time).

No.  The outer layer must be valid at verification time.  There's no need to
capture to revocation information and trust anchor at the time it was
timestamped.  This should be captured when the next timestamp is applied.

------_=_NextPart_001_01C76BCA.A60101C8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: TSA key and revocation checking</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; Doesn't this mean that you need to provide the =
verification </FONT>
<BR><FONT SIZE=3D2>&gt; algorithm with the current trust anchor and the =
revocation </FONT>
<BR><FONT SIZE=3D2>&gt; information AT THE TIME the outer layer was =
timestamped? </FONT>
<BR><FONT SIZE=3D2>&gt; (Implying the need to keep all revocation =
material for the </FONT>
<BR><FONT SIZE=3D2>&gt; current CAs for a long time).</FONT>
</P>

<P><FONT SIZE=3D2>No.&nbsp; The outer layer must be valid at =
verification time.&nbsp; There's no need to capture to revocation =
information and trust anchor at the time it was timestamped.&nbsp; This =
should be captured when the next timestamp is applied.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C76BCA.A60101C8--

From: "Julien Stern" <[email-masked]>
Date: Wed, 21 Mar 2007 16:00:59 +0100
To: [email-masked]
Subject: Re: TSA key and revocation checking
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Mar 21, 2007 at 10:28:52AM -0400, Carl Wallace wrote:
> There is no chicken and egg problem because the outer layer is verifed using
> current information.  You must have the current trust anchor available
> through trusted means and can use it to verify the TSA signature.  Interior
> layers are protected by the adjacent outer layer.  

Doesn't this mean that you need to provide the verification algorithm
with the current trust anchor and the revocation information AT THE TIME
the outer layer was timestamped? (Implying the need to keep all revocation
material for the current CAs for a long time).

--
Julien

> This issue was addressed in the pre-LTANS TAP draft.  Maybe there needs to
> be a mechanism included in LTAP to obtain historical trust anchors.
>
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Julien Stern
> > Sent: Wednesday, March 21, 2007 10:08 AM
> > To: [email-masked]
> > Subject: Re: TSA key and revocation checking
> > 
> > 
> > On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote:
> > > I agree with Carl.  Not checking revocation status and relying on 
> > > non-automated, other means is a bad idea.
> > 
> > I agree on the general principle. But in the specific LTANS 
> > settings, I think the TSA certificate will be in some sense 
> > more "trusted" than the CA that issued it.
> > 
> > The specific setting I have in mind is the following:
> > - say you are doing long term archiving (of signatures for instance)
> > - also say that you have archived ALL artifacts (certs, OCSP, 
> > CRLs, etc)
> > - Many years after, you want to check your archive
> > 
> > If the TSA key is not trusted out-of-band, you need 
> > information to verify its revocation status, but this 
> > information cannot be included in the timestamped archive 
> > itself as that would cause a chicken and egg problem. 
> > Question: how do you obtain it ?
> > 
> > I one can come up with a solution that solves this chicken 
> > and egg and allows for revocation checking, I'm all for it, 
> > but we have to keep this issue in mind.
> > 
> > --
> > Julien
> > 
> > > ________________________________
> > > 
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Carl Wallace
> > > Sent: Wednesday, March 21, 2007 6:46 AM
> > > To: [email-masked]
> > > Subject: TSA key and revocation checking
> > > 
> > >  
> > > 
> > > During yesterday's meeting, Tobias mentioned that a TSA key 
> > could be 
> > > trusted without checking its revocation status because 
> > compromise of 
> > > the key would be a widely known problem.  I asked, via 
> > Jabber, how one 
> > > could confirm they had the correct TSA key and was directed to the 
> > > mailing list.  While it may be true that the compromise of the TSA 
> > > would be widely known, would the revocation of a 
> > certificate issued in 
> > > error to the same name be as widely known?  Recommending that 
> > > revocation status not be checked seems like a bad idea.  We 
> > have means 
> > > for representing and processing revocation information, 
> > including the 
> > > time of compromise, and should simply use them.
> > > 
> > 

Content-class: urn:content-classes:message
Subject: RE: TSA key and revocation checking
Date: Wed, 21 Mar 2007 07:50:41 -0700
From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Julien,

If you have not used LTANS work of trusted archive (time stamp refresh)
and protected the payload, you should be able to verify the time stamp
as of the time of time stamp using the revocation artifacts as of that
time.

If you are using LTANS trusted archive, look at the step 3 in Section
5.3 of ERS I-D.  It calls for verifying each time stamp as of the time
of the next time stamp. In other words, time stamp must be refreshed
before the TSA is revoked or expires.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Julien Stern
Sent: Wednesday, March 21, 2007 10:08 AM
To: [email-masked]
Subject: Re: TSA key and revocation checking

On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote:
> I agree with Carl.  Not checking revocation status and relying on
> non-automated, other means is a bad idea.

I agree on the general principle. But in the specific LTANS settings, I
think the TSA certificate will be in some sense more "trusted" than the
CA that issued it.

The specific setting I have in mind is the following:
- say you are doing long term archiving (of signatures for instance)
- also say that you have archived ALL artifacts (certs, OCSP, CRLs, etc)
- Many years after, you want to check your archive

If the TSA key is not trusted out-of-band, you need information to
verify its revocation status, but this information cannot be included
in the timestamped archive itself as that would cause a chicken and egg
problem. Question: how do you obtain it ?

I one can come up with a solution that solves this chicken and egg
and allows for revocation checking, I'm all for it, but we have to
keep this issue in mind.

--
Julien

> ________________________________
> 
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Carl Wallace
> Sent: Wednesday, March 21, 2007 6:46 AM
> To: [email-masked]
> Subject: TSA key and revocation checking
> 
>  
> 
> During yesterday's meeting, Tobias mentioned that a TSA key could be
> trusted without checking its revocation status because compromise of
the
> key would be a widely known problem.  I asked, via Jabber, how one
could
> confirm they had the correct TSA key and was directed to the mailing
> list.  While it may be true that the compromise of the TSA would be
> widely known, would the revocation of a certificate issued in error to
> the same name be as widely known?  Recommending that revocation status
> not be checked seems like a bad idea.  We have means for representing
> and processing revocation information, including the time of
compromise,
> and should simply use them.
> 

From: Carl Wallace <[email-masked]>
To: [email-masked]
Subject: RE: TSA key and revocation checking
Date: Wed, 21 Mar 2007 10:28:52 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C76BC5.3FF4E4A8
Content-Type: text/plain

There is no chicken and egg problem because the outer layer is verifed using
current information.  You must have the current trust anchor available
through trusted means and can use it to verify the TSA signature.  Interior
layers are protected by the adjacent outer layer.  

This issue was addressed in the pre-LTANS TAP draft.  Maybe there needs to
be a mechanism included in LTAP to obtain historical trust anchors.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julien Stern
> Sent: Wednesday, March 21, 2007 10:08 AM
> To: [email-masked]
> Subject: Re: TSA key and revocation checking
> 
> 
> On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote:
> > I agree with Carl.  Not checking revocation status and relying on 
> > non-automated, other means is a bad idea.
> 
> I agree on the general principle. But in the specific LTANS 
> settings, I think the TSA certificate will be in some sense 
> more "trusted" than the CA that issued it.
> 
> The specific setting I have in mind is the following:
> - say you are doing long term archiving (of signatures for instance)
> - also say that you have archived ALL artifacts (certs, OCSP, 
> CRLs, etc)
> - Many years after, you want to check your archive
> 
> If the TSA key is not trusted out-of-band, you need 
> information to verify its revocation status, but this 
> information cannot be included in the timestamped archive 
> itself as that would cause a chicken and egg problem. 
> Question: how do you obtain it ?
> 
> I one can come up with a solution that solves this chicken 
> and egg and allows for revocation checking, I'm all for it, 
> but we have to keep this issue in mind.
> 
> --
> Julien
> 
> > ________________________________
> > 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Carl Wallace
> > Sent: Wednesday, March 21, 2007 6:46 AM
> > To: [email-masked]
> > Subject: TSA key and revocation checking
> > 
> >  
> > 
> > During yesterday's meeting, Tobias mentioned that a TSA key 
> could be 
> > trusted without checking its revocation status because 
> compromise of 
> > the key would be a widely known problem.  I asked, via 
> Jabber, how one 
> > could confirm they had the correct TSA key and was directed to the 
> > mailing list.  While it may be true that the compromise of the TSA 
> > would be widely known, would the revocation of a 
> certificate issued in 
> > error to the same name be as widely known?  Recommending that 
> > revocation status not be checked seems like a bad idea.  We 
> have means 
> > for representing and processing revocation information, 
> including the 
> > time of compromise, and should simply use them.
> > 
> 

------_=_NextPart_001_01C76BC5.3FF4E4A8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: TSA key and revocation checking</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>There is no chicken and egg problem because the outer =
layer is verifed using current information.&nbsp; You must have the =
current trust anchor available through trusted means and can use it to =
verify the TSA signature.&nbsp; Interior layers are protected by the =
adjacent outer layer.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>This issue was addressed in the pre-LTANS TAP =
draft.&nbsp; Maybe there needs to be a mechanism included in LTAP to =
obtain historical trust anchors.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [email-masked] </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-ltans@ma=
il.imc.org</A>] On Behalf Of Julien Stern</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, March 21, 2007 10:08 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: TSA key and revocation =
checking</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Wed, Mar 21, 2007 at 06:41:52AM -0700, =
Santosh Chokhani wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I agree with Carl.&nbsp; Not checking =
revocation status and relying on </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; non-automated, other means is a bad =
idea.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I agree on the general principle. But in the =
specific LTANS </FONT>
<BR><FONT SIZE=3D2>&gt; settings, I think the TSA certificate will be =
in some sense </FONT>
<BR><FONT SIZE=3D2>&gt; more &quot;trusted&quot; than the CA that =
issued it.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The specific setting I have in mind is the =
following:</FONT>
<BR><FONT SIZE=3D2>&gt; - say you are doing long term archiving (of =
signatures for instance)</FONT>
<BR><FONT SIZE=3D2>&gt; - also say that you have archived ALL artifacts =
(certs, OCSP, </FONT>
<BR><FONT SIZE=3D2>&gt; CRLs, etc)</FONT>
<BR><FONT SIZE=3D2>&gt; - Many years after, you want to check your =
archive</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If the TSA key is not trusted out-of-band, you =
need </FONT>
<BR><FONT SIZE=3D2>&gt; information to verify its revocation status, =
but this </FONT>
<BR><FONT SIZE=3D2>&gt; information cannot be included in the =
timestamped archive </FONT>
<BR><FONT SIZE=3D2>&gt; itself as that would cause a chicken and egg =
problem. </FONT>
<BR><FONT SIZE=3D2>&gt; Question: how do you obtain it ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I one can come up with a solution that solves =
this chicken </FONT>
<BR><FONT SIZE=3D2>&gt; and egg and allows for revocation checking, I'm =
all for it, </FONT>
<BR><FONT SIZE=3D2>&gt; but we have to keep this issue in mind.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Julien</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-ietf-ltans@ma=
il.imc.org</A>] On Behalf Of Carl Wallace</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Wednesday, March 21, 2007 6:46 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: TSA key and revocation =
checking</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; During yesterday's meeting, Tobias =
mentioned that a TSA key </FONT>
<BR><FONT SIZE=3D2>&gt; could be </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; trusted without checking its revocation =
status because </FONT>
<BR><FONT SIZE=3D2>&gt; compromise of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the key would be a widely known =
problem.&nbsp; I asked, via </FONT>
<BR><FONT SIZE=3D2>&gt; Jabber, how one </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; could confirm they had the correct TSA key =
and was directed to the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; mailing list.&nbsp; While it may be true =
that the compromise of the TSA </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; would be widely known, would the =
revocation of a </FONT>
<BR><FONT SIZE=3D2>&gt; certificate issued in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; error to the same name be as widely =
known?&nbsp; Recommending that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; revocation status not be checked seems =
like a bad idea.&nbsp; We </FONT>
<BR><FONT SIZE=3D2>&gt; have means </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for representing and processing revocation =
information, </FONT>
<BR><FONT SIZE=3D2>&gt; including the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; time of compromise, and should simply use =
them.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C76BC5.3FF4E4A8--

From: "Julien Stern" <[email-masked]>
Date: Wed, 21 Mar 2007 15:08:26 +0100
To: [email-masked]
Subject: Re: TSA key and revocation checking
Mail-Followup-To: Julien Stern <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Mar 21, 2007 at 06:41:52AM -0700, Santosh Chokhani wrote:
> I agree with Carl.  Not checking revocation status and relying on
> non-automated, other means is a bad idea.

I agree on the general principle. But in the specific LTANS settings, I
think the TSA certificate will be in some sense more "trusted" than the
CA that issued it.

The specific setting I have in mind is the following:
- say you are doing long term archiving (of signatures for instance)
- also say that you have archived ALL artifacts (certs, OCSP, CRLs, etc)
- Many years after, you want to check your archive

If the TSA key is not trusted out-of-band, you need information to
verify its revocation status, but this information cannot be included
in the timestamped archive itself as that would cause a chicken and egg
problem. Question: how do you obtain it ?

I one can come up with a solution that solves this chicken and egg
and allows for revocation checking, I'm all for it, but we have to
keep this issue in mind.

--
Julien

> ________________________________
> 
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Carl Wallace
> Sent: Wednesday, March 21, 2007 6:46 AM
> To: [email-masked]
> Subject: TSA key and revocation checking
> 
>  
> 
> During yesterday's meeting, Tobias mentioned that a TSA key could be
> trusted without checking its revocation status because compromise of the
> key would be a widely known problem.  I asked, via Jabber, how one could
> confirm they had the correct TSA key and was directed to the mailing
> list.  While it may be true that the compromise of the TSA would be
> widely known, would the revocation of a certificate issued in error to
> the same name be as widely known?  Recommending that revocation status
> not be checked seems like a bad idea.  We have means for representing
> and processing revocation information, including the time of compromise,
> and should simply use them.
> 

Content-class: urn:content-classes:message
Subject: RE: TSA key and revocation checking
Date: Wed, 21 Mar 2007 06:41:52 -0700
From: "Santosh Chokhani" <[email-masked]>
To: "Carl Wallace" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C76BBE.BD882CD3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree with Carl.  Not checking revocation status and relying on
non-automated, other means is a bad idea.

=20

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Carl Wallace
Sent: Wednesday, March 21, 2007 6:46 AM
To: [email-masked]
Subject: TSA key and revocation checking

=20

During yesterday's meeting, Tobias mentioned that a TSA key could be
trusted without checking its revocation status because compromise of the
key would be a widely known problem.  I asked, via Jabber, how one could
confirm they had the correct TSA key and was directed to the mailing
list.  While it may be true that the compromise of the TSA would be
widely known, would the revocation of a certificate issued in error to
the same name be as widely known?  Recommending that revocation status
not be checked seems like a bad idea.  We have means for representing
and processing revocation information, including the time of compromise,
and should simply use them.

------_=_NextPart_001_01C76BBE.BD882CD3
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-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]-->
<title>TSA key and revocation checking</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</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:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	page-break-after:avoid;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.4in;
	text-indent:-.4in;
	page-break-after:avoid;
	mso-list:l0 level2 lfo2;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p.StyleCentered, li.StyleCentered, div.StyleCentered
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:209154939;
	mso-list-template-ids:2064295352;}
@list l0:level1
	{mso-level-style-link:"Heading 1";
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l0:level2
	{mso-level-style-link:"Heading 2";
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l0:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l0:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l0:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l0:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l0:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l0:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l0:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l1
	{mso-list-id:1216352322;
	mso-list-template-ids:-482153376;}
@list l1:level1
	{mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I agree with Carl.&nbsp; Not =
checking
revocation status and relying on non-automated, other means is a bad =
idea.<o:p></o:p></span></font></p>

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

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span 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 =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span 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><st1:PersonName =
w:st=3D"on">Carl
 Wallace</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, March =
21, 2007
6:46 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">[email-masked]</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> TSA key and =
revocation
checking</span></font><o:p></o:p></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><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>During
yesterday's meeting, Tobias mentioned that a TSA key could be trusted =
without
checking its revocation status because compromise of the key would be a =
widely
known problem.&nbsp; I asked, via Jabber, how one could confirm they had =
the
correct TSA key and was directed to the mailing list.&nbsp; While it may =
be
true that the compromise of the TSA would be widely known, would the =
revocation
of a certificate issued in error to the same name be as widely =
known?&nbsp;
Recommending that revocation status not be checked seems like a bad =
idea.&nbsp;
We have means for representing and processing revocation information, =
including
the time of compromise, and should simply use =
them.</span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C76BBE.BD882CD3--

From: Carl Wallace <[email-masked]>
To: [email-masked]
Subject: TSA key and revocation checking
Date: Wed, 21 Mar 2007 06:45:45 -0400
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C76BA6.142921F4
Content-Type: text/plain

During yesterday's meeting, Tobias mentioned that a TSA key could be trusted
without checking its revocation status because compromise of the key would
be a widely known problem.  I asked, via Jabber, how one could confirm they
had the correct TSA key and was directed to the mailing list.  While it may
be true that the compromise of the TSA would be widely known, would the
revocation of a certificate issued in error to the same name be as widely
known?  Recommending that revocation status not be checked seems like a bad
idea.  We have means for representing and processing revocation information,
including the time of compromise, and should simply use them.

------_=_NextPart_001_01C76BA6.142921F4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>TSA key and revocation checking</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>During yesterday's meeting, Tobias mentioned that a =
TSA key could be trusted without checking its revocation status because =
compromise of the key would be a widely known problem.&nbsp; I asked, =
via Jabber, how one could confirm they had the correct TSA key and was =
directed to the mailing list.&nbsp; While it may be true that the =
compromise of the TSA would be widely known, would the revocation of a =
certificate issued in error to the same name be as widely known?&nbsp; =
Recommending that revocation status not be checked seems like a bad =
idea.&nbsp; We have means for representing and processing revocation =
information, including the time of compromise, and should simply use =
them.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C76BA6.142921F4--

Content-class: urn:content-classes:message
Subject: LTANS WG meeting tomorrow
Date: Mon, 19 Mar 2007 17:16:47 +0100
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C76A41.FE531238
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

the WG meeting tomorrow has an audio stream: =
http://videolab.uoregon.edu/events/ietf/ietf687.m3u
(find link also at: http://videolab.uoregon.edu/events/ietf/  - room =
Karlin II )

And I hope I still find a volunteer for the jabber scribe:
Room: ltans
Server: jabber.ietf.org

Agenda etc. can be found on the IETF meeting agenda - slides will be =
uploaded tomorrow morning.

Tobias
Chair of LTANS

__________________________________________
Tobias Gondrom
Head of Open Text Security Team

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:[email-masked]=20
Internet: http://www.opentext.com/ =20

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der =
Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: =
+49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, =
Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:  =
DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John =
Shackleton

This email is protected by domestic and international copyright laws and =
treaties and is the property of Open Text Corporation, it may contain =
confidential and/or trade secret information of the Open Text =
Corporation and/or its subsidiaries (OTC), and may be subject to legal =
privilege in favor of OTC. This email may only be lawfully received, =
accessed, displayed on a computer screen, printed, copied, and/or used =
by the specific addressee(s) named above ("Authorized Recipient") for =
the purpose for which it was sent by OTC. All other rights and licenses =
to this email are fully reserved to OTC. If you are not an Authorized =
Recipient, you are required to immediately delete this email in its =
entirety without printing, copying, using, and/or re-transmitting this =
email, either in whole or in part. The transmission of this email by OTC =
is not to be construed as a waiver by OTC and/or the individual sending =
this email on behalf of OTC of any of their respective rights or =
privileges at law or otherwise, howsoever arising.

------_=_NextPart_001_01C76A41.FE531238
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7234.20">
<TITLE>LTANS WG meeting tomorrow</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P ALIGN=3DLEFT><SPAN LANG=3D"de"><FONT SIZE=3D2 =
FACE=3D"Arial">Hello,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">the =
WG meeting tomorrow has a</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">n</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
audio stream:</FONT></SPAN><SPAN LANG=3D"de"> </SPAN><A =
HREF=3D"http://videolab.uoregon.edu/events/ietf/ietf687.m3u"><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"><U></U></SPAN><U><SPAN =
LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://videolab.uoregon.edu/events/ietf/ietf687.m3u</FONT>=
</SPAN></U><SPAN LANG=3D"de"></SPAN></A><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">(</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">find link also at:</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"de"> </SPAN><A =
HREF=3D"http://videolab.uoregon.edu/events/ietf/"><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"><U></U></SPAN><U><SPAN =
LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://videolab.uoregon.edu/events/ietf/</FONT></SPAN></U>=
<SPAN LANG=3D"de"></SPAN></A><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp; -</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">room Karlin</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
II )</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">And I =
hope I still find a volunteer for the jabber scribe:</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">Room: =
ltans</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Server: jabber.ietf.org</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Agenda etc. can be found on the IETF meeting =
agenda</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">&#8211;</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">slides will be uploaded tomorrow =
morning.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Tobias</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">Chair =
of LTANS</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"></SPAN></P>
<BR>
<BR>

<P ALIGN=3DLEFT><B><SPAN LANG=3D"de-de"></SPAN></B><A NAME=3D""><B><SPAN =
LANG=3D"de-de"><FONT SIZE=3D2 =
FACE=3D"Arial">__________________________________________</FONT></SPAN></=
B></A><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"><B></B></SPAN><SPAN =
LANG=3D"de"><B></B></SPAN><B><SPAN LANG=3D"de-de"><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tobias =
Gondrom</FONT></SPAN></B><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Head of =
Open Text Security Team<BR>
</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"><B></B></SPAN><SPAN =
LANG=3D"de"><B></B></SPAN><B><SPAN LANG=3D"de-de"><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Open Text =
Corporation</FONT></SPAN></B><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"><FONT =
COLOR=3D"#000000">Technopark 2<BR>
Werner-von-Siemens-Ring 20<BR>
D-85630 Grasbrunn</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"de-de"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">Phone: +49 (0) 89 4629-1816<BR>
Mobile: +49 (0) 173 5942987<BR>
Telefax: +49 (0) 89 4629-33-1816<BR>
eMail:</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"> <FONT SIZE=3D2 =
FACE=3D"Arial"><A =
HREF=3D"mailto:[email-masked]">mailto:tobias.gondrom@opentex=
t.com</A><BR>
</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">Internet:</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"> <FONT SIZE=3D2 =
FACE=3D"Arial"><A =
HREF=3D"http://www.opentext.com/">http://www.opentext.com/</A>&nbsp; =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"de-de"><FONT SIZE=3D1 FACE=3D"Arial">Place =
of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift =
65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) =
6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | =
Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:&nbsp; DE 114 =
169 819 | Managing Director / Gesch=E4ftsf=FChrer: John =
Shackleton</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"de-de"><FONT SIZE=3D1 FACE=3D"Arial">This =
email is protected by domestic and international copyright laws and =
treaties and is the property of Open Text Corporation, it may contain =
confidential and/or trade secret information of the Open Text =
Corporation and/or its subsidiaries (OTC), and may be subject to legal =
privilege in favor of OTC. This email may only be lawfully received, =
accessed, displayed on a computer screen, printed, copied, and/or used =
by the specific addressee(s) named above (&quot;Authorized =
Recipient&quot;) for the purpose for which it was sent by OTC. All other =
rights and licenses to this email are fully reserved to OTC. If you are =
not an Authorized Recipient, you are required to immediately delete this =
email in its entirety without printing, copying, using, and/or =
re-transmitting this email, either in whole or in part. The transmission =
of this email by OTC is not to be construed as a waiver by OTC and/or =
the individual sending this email on behalf of OTC of any of their =
respective rights or privileges at law or otherwise, howsoever =
arising.</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C76A41.FE531238--

Content-class: urn:content-classes:message
Subject: agenda for upcoming WG meeting in Prague
Date: Mon, 12 Mar 2007 19:36:48 +0100
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C764D5.654B5EE3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello dear WG members,

this is the agenda for the upcoming WG meeting on Tuesday, March 20th in =
Prague.
(am still searching for a Jabber scribe, and I expect we will have an =
audio broadcast from that room)

http://www3.ietf.org/proceedings/07mar/agenda/ltans.txt=20

LTANS meeting
Meeting : IETF 68, TUESDAY, March 20, 2007.
Location: Hilton Prague, room Karlin II, 1850-1950.
Chairs  : Tobias Gondrom <[email-masked]>, Carl Wallace =
<[email-masked]>
Jabber  : [email-masked]
URL     : http://www.ietf.org/html.charters/ltans-charter.html
Agenda  : version 1.0

Meeting Agenda:
A. MeetinG Administrativia - 5 minutes (chairs)
B. Milestone Review - 5 minutes (Tobias)
C. LTAP update - 10 minutes (Peter)
- draft-ietf-ltans-ltap-04
D. Validation document updates - 5 minutes (Tobias)
- draft-ietf-ltans-validate-01
E. XMLERS - status and presentation - 10 minutes (Aleksej&Svetlana)
- draft-ietf-ltans-xmlers-00.txt=20
F. Implementation of ERS by Fraunhofer: Archisoft - 10 minutes (Michael =
Herfert)
G. Use of other timestamp formats with ERS - 5 minutes (Tobias)
H. Future/Milestone recap/Wrap-up - 10 minutes (chairs)

Drafts you should read to prepare for the meeting:
LTAP, XMLERS, VALIDATE, (and optional: ARI, ERS/SCVP and ERS)

See you next week,=20
Tobias
Chair of LTANS

__________________________________________
Tobias Gondrom
Head of Open Text Security Team

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:[email-masked]=20
Internet: http://www.opentext.com/ =20

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der =
Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: =
+49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, =
Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:  =
DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John =
Shackleton

This email is protected by domestic and international copyright laws and =
treaties and is the property of Open Text Corporation, it may contain =
confidential and/or trade secret information of the Open Text =
Corporation and/or its subsidiaries (OTC), and may be subject to legal =
privilege in favor of OTC. This email may only be lawfully received, =
accessed, displayed on a computer screen, printed, copied, and/or used =
by the specific addressee(s) named above ("Authorized Recipient") for =
the purpose for which it was sent by OTC. All other rights and licenses =
to this email are fully reserved to OTC. If you are not an Authorized =
Recipient, you are required to immediately delete this email in its =
entirety without printing, copying, using, and/or re-transmitting this =
email, either in whole or in part. The transmission of this email by OTC =
is not to be construed as a waiver by OTC and/or the individual sending =
this email on behalf of OTC of any of their respective rights or =
privileges at law or otherwise, howsoever arising.

------_=_NextPart_001_01C764D5.654B5EE3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7234.20">
<TITLE>agenda for upcoming WG meeting in Prague</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P ALIGN=3DLEFT><SPAN LANG=3D"de"><FONT SIZE=3D2 FACE=3D"Arial">Hello =
dear WG members,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">this</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">is</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">the</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
agenda for</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">the</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">upcoming</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">WG</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">meeting</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">on</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">Tuesday</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">, =
March</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
20th in Prague.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">(am =
still searching for a Jabber scribe</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial">, and I expect we will have an audio broadcast =
from that room</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"de"></SPAN><A =
HREF=3D"http://www3.ietf.org/proceedings/07mar/agenda/ltans.txt"><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"><U></U></SPAN><U><SPAN =
LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www3.ietf.org/proceedings/07mar/agenda/ltans.txt</F=
ONT></SPAN></U><SPAN LANG=3D"de"></SPAN></A><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> </SPAN></P>

<P ALIGN=3DLEFT><B><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">LTANS meeting</FONT></SPAN></B><SPAN =
LANG=3D"de"><B></B></SPAN><SPAN LANG=3D"de"><B></B></SPAN><B><SPAN =
LANG=3D"en-gb"></SPAN></B></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Meeting : IETF 68, TUESDAY, March 20, =
2007.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Location: Hilton Prague, room Karlin II, =
1850-1950.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Chairs&nbsp; : Tobias Gondrom =
&lt;[email-masked]&gt;, Carl Wallace =
&lt;[email-masked]&gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Jabber&nbsp; : =
[email-masked]</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">URL&nbsp;&nbsp;&nbsp;&nbsp; : <A =
HREF=3D"http://www.ietf.org/html.charters/ltans-charter.html">http://www.=
ietf.org/html.charters/ltans-charter.html</A></FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Agenda&nbsp; : version 1.0</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Meeting Agenda:</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">A. =
MeetinG Administrativia - 5 minutes (chairs)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">B. =
Milestone Review - 5 minutes (Tobias)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">C. =
LTAP update - 10 minutes (Peter)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">- =
draft-ietf-ltans-ltap-04</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"fr"><FONT SIZE=3D2 FACE=3D"Arial">D. =
Validation document updates - 5 minutes (Tobias)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">- =
draft-ietf-ltans-validate-01</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">E. =
XMLERS - status and presentation - 10 minutes =
(Aleksej&amp;Svetlana)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">- =
draft-ietf-ltans-xmlers-00.txt </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">F. =
Implementation of ERS by Fraunhofer: Archisoft - 10 minutes (Michael =
Herfert)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">G. =
Use of other timestamp formats with ERS - 5 minutes =
(Tobias)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">H. =
Future/Milestone recap/Wrap-up - 10 minutes (chairs)</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Drafts you should read to prepare for the =
meeting:</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">LTAP, =
XMLERS, VALIDATE, (and optional: ARI, ERS/SCVP and =
ERS)</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">See =
you next week,</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> </SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Tobias</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">Chair =
of LTANS</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"></SPAN></P>
<BR>
<BR>

<P ALIGN=3DLEFT><B><SPAN LANG=3D"de-de"></SPAN></B><A NAME=3D""><B><SPAN =
LANG=3D"de-de"><FONT SIZE=3D2 =
FACE=3D"Arial">__________________________________________</FONT></SPAN></=
B></A><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"><B></B></SPAN><SPAN =
LANG=3D"de"><B></B></SPAN><B><SPAN LANG=3D"de-de"><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tobias =
Gondrom</FONT></SPAN></B><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Head of =
Open Text Security Team<BR>
</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"><B></B></SPAN><SPAN =
LANG=3D"de"><B></B></SPAN><B><SPAN LANG=3D"de-de"><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Open Text =
Corporation</FONT></SPAN></B><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"><FONT =
COLOR=3D"#000000">Technopark 2<BR>
Werner-von-Siemens-Ring 20<BR>
D-85630 Grasbrunn</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"de-de"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">Phone: +49 (0) 89 4629-1816<BR>
Mobile: +49 (0) 173 5942987<BR>
Telefax: +49 (0) 89 4629-33-1816<BR>
eMail:</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"> <FONT SIZE=3D2 =
FACE=3D"Arial"><A =
HREF=3D"mailto:[email-masked]">mailto:tobias.gondrom@opentex=
t.com</A><BR>
</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">Internet:</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"> <FONT SIZE=3D2 =
FACE=3D"Arial"><A =
HREF=3D"http://www.opentext.com/">http://www.opentext.com/</A>&nbsp; =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"de-de"><FONT SIZE=3D1 FACE=3D"Arial">Place =
of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift =
65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) =
6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | =
Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:&nbsp; DE 114 =
169 819 | Managing Director / Gesch=E4ftsf=FChrer: John =
Shackleton</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"de-de"><FONT SIZE=3D1 FACE=3D"Arial">This =
email is protected by domestic and international copyright laws and =
treaties and is the property of Open Text Corporation, it may contain =
confidential and/or trade secret information of the Open Text =
Corporation and/or its subsidiaries (OTC), and may be subject to legal =
privilege in favor of OTC. This email may only be lawfully received, =
accessed, displayed on a computer screen, printed, copied, and/or used =
by the specific addressee(s) named above (&quot;Authorized =
Recipient&quot;) for the purpose for which it was sent by OTC. All other =
rights and licenses to this email are fully reserved to OTC. If you are =
not an Authorized Recipient, you are required to immediately delete this =
email in its entirety without printing, copying, using, and/or =
re-transmitting this email, either in whole or in part. The transmission =
of this email by OTC is not to be construed as a waiver by OTC and/or =
the individual sending this email on behalf of OTC of any of their =
respective rights or privileges at law or otherwise, howsoever =
arising.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C764D5.654B5EE3--

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-ltans-ers (Evidence Record Syntax (ERS))  to Proposed Standard 
Reply-To: [email-masked]
Cc: <[email-masked]>
Date: Thu, 08 Mar 2007 17:54:30 -0500
Sender: [email-masked]

The IESG has received a request from the Long-Term Archive and Notary 
Services WG (ltans) to consider the following document:

- 'Evidence Record Syntax (ERS) '
   <draft-ietf-ltans-ers-12.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 substantive comments to the
[email-masked] mailing lists by 2007-03-29. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-12.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11588&rfc_flag=0

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ltans-ers-12.txt 
Date: Thu, 08 Mar 2007 15:50:03 -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 Long-Term Archive and Notary Services Working Group of the IETF.

	Title		: Evidence Record Syntax (ERS)
	Author(s)	: R. Brandner, et al.
	Filename	: draft-ietf-ltans-ers-12.txt
	Pages		: 34
	Date		: 2007-3-8
	
In many scenarios, users must be able prove the existence and
   integrity of data, including digitally signed data, in a common and
   reproducible way over a long and possibly undetermined period of
   time.  This document specifies the syntax and processing of an
   Evidence Record, a structure designed to support long-term non-
   repudiation of existence of data.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-12.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-ltans-ers-12.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-ltans-ers-12.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-ltans-ers-12.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ltans-ltap-04.txt 
Date: Mon, 05 Mar 2007 18:50:02 -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 Long-Term Archive and Notary Services Working Group of the IETF.

	Title		: Long-term Archive Protocol (LTAP)
	Author(s)	: A. Jerman-Blazic, et al.
	Filename	: draft-ietf-ltans-ltap-04.txt
	Pages		: 50
	Date		: 2007-3-5
	
This document describes a service operated as a trusted third party
   to securely archive electronic document called a long-term archive
   service (LTA).  We describe an architecture framework and a protocol
   allowing clients to interact with such a service.  Bindings to
   concrete transport and security protocol layers are given.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-ltap-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-ltans-ltap-04.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-ltans-ltap-04.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-ltans-ltap-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Sun, 04 Mar 2007 14:29:53 +0100
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: asn.1 module identification
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

hello,

before the first technical spec get into stone, I'd suggest a convention for
the ASN.1 module identifiers. it follows the logic that is used in X.500
etc (as far as I understand it).
example:

AuthenticationFramework {joint-iso-itu-t ds(5) module(1)
  authenticationFramework(7) 4}

We have:

- a general prefix for ltans which is

      iso(1) identified-organization(3) dod(6)
      internet(1) security(5) mechanisms(5)
      ltans(11)

- then two identifiers for modules
      module(1)
      module88(2)
      id-em(3)                 ** renumbered **
     
  in order to clearly separate the same modules
  in different syntax.

- under both trees use the same numbers for the
  corresponding modules. e.g.
  module(1) ers(1)
  module88(2) ers(1)

- last, add a version. The X509 are at version 4,
  it is unlikely that we get many version but in case
  of, this is a very simply way to distinguish versions.
  The number has no identifier.

in total this would give something like

ERS iso(1) identified-organization(3) dod(6)
      internet(1) security(5) mechanisms(5)
      ltans(11) module(1) ers(1) 1

ERS iso(1) identified-organization(3) dod(6)
      internet(1) security(5) mechanisms(5)
      ltans(11) module88(1) ers(1) 1

LTAP iso(1) identified-organization(3) dod(6)
      internet(1) security(5) mechanisms(5)
      ltans(11) module(1) ltap(2) 1

LTAP iso(1) identified-organization(3) dod(6)
      internet(1) security(5) mechanisms(5)
      ltans(11) module88(1) ltap(2) 1
 
Besides some renumbering this doesn't change anything in the current
specs.  If id-em should remain 2 then module88 could be 3.

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

--------------ms010203000905000301060200--

Content-class: urn:content-classes:message
Subject: LTANS meeting in Prague - agenda items?
Date: Thu, 1 Mar 2007 15:20:22 +0100
Importance: high
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C75C0C.BEC4E729
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello dear working group,

our meeting at the 68th IETF conference in Prague has been scheduled for =
Tuesday, March 20, 2007, 18:50-19:50 local time
(https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=3D=
68)=20

Please send your input for presentation topics and discussion slots to =
me within the next few days (latest March-10).
(presentation slides themselves can be submitted until one day before =
the meeting - Monday, March 19, 2007)

Some of my current ideas for discussion would be:
-	XMLERS (use of tags and attributes in XML version,
-	LTAP: stabilize version to prepare for WGLC
-	VALIDATE: need which further info?
-	ARI: shall ARI specify which requirements from REQS are solved in =
which I-D
-	ERS-SCVP: status and stabilize
-	List of implementations/products of ERS - prepare coordination of =
compatibility tests for after final release

Who would like to give presentations to some of the above topics or =
others?
Please send proposals for the agenda and presentations via emails =
directly to me.

Thanks, Tobias
Chair of LTANS

Ps.: and some small good news: the REQS draft is now with the editor for =
publishing as informational RFC and ERS has finally been submitted to =
the IESG.

__________________________________________
Tobias Gondrom
Head of Open Text Security Team

Open Text Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:[email-masked]=20
Internet: http://www.opentext.com/ =20

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der =
Trift 65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: =
+49 (0) 6103 89 04 11 | Register Court / Registergericht: Offenbach, =
Germany | Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:  =
DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John =
Shackleton

This email is protected by domestic and international copyright laws and =
treaties and is the property of Open Text Corporation, it may contain =
confidential and/or trade secret information of the Open Text =
Corporation and/or its subsidiaries (OTC), and may be subject to legal =
privilege in favor of OTC. This email may only be lawfully received, =
accessed, displayed on a computer screen, printed, copied, and/or used =
by the specific addressee(s) named above ("Authorized Recipient") for =
the purpose for which it was sent by OTC. All other rights and licenses =
to this email are fully reserved to OTC. If you are not an Authorized =
Recipient, you are required to immediately delete this email in its =
entirety without printing, copying, using, and/or re-transmitting this =
email, either in whole or in part. The transmission of this email by OTC =
is not to be construed as a waiver by OTC and/or the individual sending =
this email on behalf of OTC of any of their respective rights or =
privileges at law or otherwise, howsoever arising.

------_=_NextPart_001_01C75C0C.BEC4E729
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7234.20">
<TITLE>LTANS meeting in Prague - agenda items?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">Hello =
dear working group,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">our =
meeting at the 68th IETF conference in Prague</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">has been</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">scheduled for</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">T</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">uesday</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">, =
March 20, 2007</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">,</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">18:50-19:50 local time</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">(</FONT></SPAN><SPAN LANG=3D"de"></SPAN><A =
HREF=3D"https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeti=
ng_num=3D68"><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"><U></U></SPAN><U><SPAN LANG=3D"en-gb"><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">https://datatracker.ietf.org/public/meeting_agenda_html.cg=
i?meeting_num=3D68</FONT></SPAN></U><SPAN LANG=3D"de"></SPAN></A><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial">) </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Please</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">send</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
your input for presentation</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
topics</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
and discussion slots to me within the next few days</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial"> (latest March-</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial">10</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">).</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">(presentation slides</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">themselves</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">can be submitted until one day before the =
meeting</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">&#8211;</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
Monday, March 19, 2007)</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">S</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">ome</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
of my current ideas for</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">discussion</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
would be</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">:</FONT></SPAN></P>

<P><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-gb"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">XMLERS (use of tags and attributes in XML =
version,</FONT></SPAN>

<BR><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-gb"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">LTAP: stabilize version to prepare for</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">WG</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">LC</FONT></SPAN>

<BR><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-gb"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">V</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">ALIDATE: need which</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">further</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial"> info?</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"></SPAN>

<BR><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Arial">A</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial">RI</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">: =
shall ARI specify which requirements from REQS are</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">solved in which I-D</FONT></SPAN>

<BR><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-gb"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">ERS-SCVP: status and stabilize</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"></SPAN>

<BR><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-gb"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">List of i</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">mplementations</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial">/products</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">of ERS</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">&#8211;</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
prepare coordination of compatibility tests</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial"> for after final release</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"></SPAN>
</P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">W</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">ho =
would like to give presentations to</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">some of the</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">above topics or others?</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Please</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">send proposals for the agenda</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">and presentations</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">via</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">emails</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">directly</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">to me.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">Thanks, Tobias</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">Chair =
of LTANS</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">Ps.: =
and</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Arial">some</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial"> small</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">good</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">news: the</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">REQS</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
draft is now with the editor for publishing</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">as informational RFC</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">and ERS</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">has</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">finally</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">been submitted to the IESG.</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"en-gb"></SPAN></P>
<BR>
<BR>

<P ALIGN=3DLEFT><B><SPAN LANG=3D"de-de"></SPAN></B><A NAME=3D""><B><SPAN =
LANG=3D"de-de"><FONT SIZE=3D2 =
FACE=3D"Arial">__________________________________________</FONT></SPAN></=
B></A><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"><B></B></SPAN><SPAN =
LANG=3D"de"><B></B></SPAN><B><SPAN LANG=3D"de-de"><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tobias =
Gondrom</FONT></SPAN></B><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Head of =
Open Text Security Team<BR>
</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"><B></B></SPAN><SPAN =
LANG=3D"de"><B></B></SPAN><B><SPAN LANG=3D"de-de"><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Open Text =
Corporation</FONT></SPAN></B><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"><FONT =
COLOR=3D"#000000">Technopark 2<BR>
Werner-von-Siemens-Ring 20<BR>
D-85630 Grasbrunn</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><BR>
</SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"de-de"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">Phone: +49 (0) 89 4629-1816<BR>
Mobile: +49 (0) 173 5942987<BR>
Telefax: +49 (0) 89 4629-33-1816<BR>
eMail:</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"> <FONT SIZE=3D2 =
FACE=3D"Arial"><A =
HREF=3D"mailto:[email-masked]">mailto:tobias.gondrom@opentex=
t.com</A><BR>
</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de-de"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">Internet:</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de-de"> <FONT SIZE=3D2 =
FACE=3D"Arial"><A =
HREF=3D"http://www.opentext.com/">http://www.opentext.com/</A>&nbsp; =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"de-de"><FONT SIZE=3D1 FACE=3D"Arial">Place =
of Incorporation / Sitz der Gesellschaft: Open Text GmbH, An der Trift =
65, 63303 Dreieich, Germany | Phone: +49 (0) 6103 890 40 | Fax: +49 (0) =
6103 89 04 11 | Register Court / Registergericht: Offenbach, Germany | =
Trade Register Number / HRB: 33340 | VAT ID Number /USt-ID:&nbsp; DE 114 =
169 819 | Managing Director / Gesch=E4ftsf=FChrer: John =
Shackleton</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"de-de"><FONT SIZE=3D1 FACE=3D"Arial">This =
email is protected by domestic and international copyright laws and =
treaties and is the property of Open Text Corporation, it may contain =
confidential and/or trade secret information of the Open Text =
Corporation and/or its subsidiaries (OTC), and may be subject to legal =
privilege in favor of OTC. This email may only be lawfully received, =
accessed, displayed on a computer screen, printed, copied, and/or used =
by the specific addressee(s) named above (&quot;Authorized =
Recipient&quot;) for the purpose for which it was sent by OTC. All other =
rights and licenses to this email are fully reserved to OTC. If you are =
not an Authorized Recipient, you are required to immediately delete this =
email in its entirety without printing, copying, using, and/or =
re-transmitting this email, either in whole or in part. The transmission =
of this email by OTC is not to be construed as a waiver by OTC and/or =
the individual sending this email on behalf of OTC of any of their =
respective rights or privileges at law or otherwise, howsoever =
arising.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C75C0C.BEC4E729--