Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8DCwdTO098140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2007 05:58:39 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8DCwdBB098139; Thu, 13 Sep 2007 05:58:39 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8DCwZGr098125 for <ietf-ltans@imc.org>; Thu, 13 Sep 2007 05:58:38 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l8DCwC1g029599; Thu, 13 Sep 2007 14:58:12 +0200 (MEST)
Received: from MUCXGC2.opentext.net (mucxg01.opentext.net [149.235.128.135]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id l8DCwBRK017877; Thu, 13 Sep 2007 08:58:12 -0400 (envelope-from tgondrom@opentext.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: draft-ietf-ltans-dssc-00 comments
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0023_01C7F616.809AA3C0"
Date: Thu, 13 Sep 2007 14:58:12 +0200
Message-ID: <2666EB2A846BAC4BB2D7F593301A78680187FA26@MUCXGC2.opentext.net>
In-Reply-To: <46E924BC.6030309@edelweb.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-ltans-dssc-00 comments
Thread-Index: Acf1/puBRgQ1q3oySkSNFYSunP5/4AABSkCg
X-Priority: 5
Importance: low
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Peter Sylvester" <Peter.Sylvester@edelweb.fr>, "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>
Cc: <ietf-ltans@imc.org>, "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>
X-Archived: msg.BaZeJvy:2007-09-13:mucpm02.smtp.dmz.opentext.com
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0023_01C7F616.809AA3C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Peter and Thomas,

just a comment: I like the constraint mechanisms you propose and would like
to see them in the draft, but I do not think they are mandatory. So if this
is possible, please go ahead. If not, I believe a list of algorithms with
their parameters will do the job as well. Remember the parameters are
usually not continuously distributed values n of N, but usually use only a
certain limited sub-set of discrete values element of N. (e.g. discrete
values: 256, 512, 1024, 1280, 1536, 2048, 4096, ...) 

So we will be able to define lifetimes for all used key lengths for a
specific algorithm and not absolutely require the constraint rule. 

But as I said, if you find a solution with the constraints I'll be very
happy, just wanted to let you know I believe you also have other options
which would work as well. 

Just my 5cents, 

Tobias



> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org]
> On Behalf Of Peter Sylvester
> Sent: Thursday, September 13, 2007 1:54 PM
> To: Thomas Kunz
> Cc: ietf-ltans@imc.org; Susanne Okunick
> Subject: Re: draft-ietf-ltans-dssc-00 comments
> 
> Thomas Kunz wrote:
> > Hello Peter,
> >
> > yes, your proposal sounds quite good. In the next version of our
> > draft, we will propose a new XML structure for parameter constraints:
> >
> > <Parameter name="modulus">
> >    <Value>1024</Value>
> >    <Constraint>minimum value</Constraint>
> > </Parameter>
> >
> > I think, that's just about what you mean.
> Not exactly. See below
> >
> > Another advantage of this approach would be that we will have only one
> > XML schema, which doesn't need to be extended for future algorithms.
> This is the main goal. A policy and the information that are to be
> provided by an implementation follow one
> schema that does not need to be extended for any new algorithm.
> 
> IMO there are two things to cover:
> 
> 
> 1 - Information from an implementation that contains actual implemented
> values.
> 2 - a policy that contains constraints
> 
> A verifier tests whether the actual values match the constraints.
> 
> I am not whether there is a need to type the parameter, i.e. can
> we assume that all parameters can be represented always as integers
> in a convenient way, i.e. in a such a way that a constraint can be
> formulated nicely.
> 
> To take the example above:
> 
> For the information 1
> 
> <Parameter name="modulus" value="1024 "/>
> 
> and  for 2
> 
> <Parameter name="modulus">
> <Constraint notAfter=.. notbefore=... >
> <greater>1024</greater>
> <and>
> <smaller>4096</smaller>
> <Constraint>
> 
> 
> >
> > The "name" attribute is optional and only for better readability and
> > understandability of the policy. It should not be processed by a
> > verifying entity.
> It can be used in error message: "Parameter 'modulus' of algo  xxx'
> doesn't meet the
> its constraint. You have a similar thing in SNMP, a user friendly name
> of a parameter.
> 
> But you also need  this in oder to identify correspondance of 1 and 2. I
> wouldn't
> rely on the order, or  in other words, it may be that some parameter has
> no
> constraints but is part of the algorithm characteristics.
> >
> > The "Constraint" element defines how the parameter has to be processed
> > and evaluated. In the example above, "minimum value" would mean, that
> > all keys with a modulus greater then 1024 are also valid at least as
> > long as the 1024 modulus.
> > At this point, I'm not sure, if it's sufficient to give only a textual
> > value like "minimum value" or if it would be better to define
> > URIs/OIDs to express such processing constraints.
> I think a contaraint language that can define value subsets is necssary
> and not
> very difficult.
> >
> > Regards,
> > Thomas
> >
> >
> > Peter Sylvester schrieb:
> >>
> >>>>
> >>> I'm not sure whether I understand your suggestion.
> >>>
> >>> In your example above, you suggest to have simply a list of all
> >>> currently valid key lengths?
> >> Not in the policy but in the information about what is actually
> >> implemented by
> >> an algorithm. I was not quite clear here.
> >>
> >>> But where do you have the validity periods of the particular values
> >>> (key  lengths)?
> >> As part of the policy, you make constraints about values, e.g.
> >> parameter 1 may only have this
> >> or that etc. You can CHECK such statements without knowing the actual
> >> semantics.
> >>
> >>> A second problem I see is, that some algorithms are defined by more
> >>> than one parameter (e.g. DSA: 'p' and 'q'). So in the XML encoding,
> >>> you have to distinguish the different parameters (e.g. via its name).
> >> There is the point. You do not have to distinguish any semantics of
> >> what p q, or keys or else would mean.
> >> I think a verifying entity can be made of two compoents: A very
> >> generic one, which verifies the
> >> conformity of ALL alogorithms and, for each algorithm implementation,
> >> a specific module which,
> >> depending on the algorithm implementation can indicate how some
> >> values are filled. The verification
> >> module does not need to know anything about the actual semantics of a
> >> particular parameter.
> >>
> >> Compare this with SNMP: If you have some "box" with a mib, onlmy the
> >> box knows the semantics
> >> of the values, not the SNMP client and network supervision tools.
> >> They just can set value and display
> >> textuals labels defined by a mib.
> >>
> >> If one wants to define policies about certain values, then the
> >> network tool need to know the specific
> >> mibs, there is no way to make a generic policy for each kind of mib.
> >> But in our case, the potential
> >> number of algorithms is not extremely high, and in any way, the
> >> policy will say not say more than
> >> constraints of a few values.
> >>>
> >>>
> >>>> in a policy one would only specify value constraints parameters for
> >>>> an actual algorithms,
> >>>> a kind of pattern which can always be checked, example
> >>>>   first parameter must be greater than  1023, second less than 8192
> >>>> or whatever.
> >>> >
> >>> Do you mean to encode this pattern in XML? And for example such a
> >>> pattern would say: 'If a value of 1024 is valid, every value greater
> >>> than 1024 is also valid'?
> >>>
> >>> In principle I agree with you. We are also discussing the problem
> >>> which arises if new algorithms are added (see Susanne's mail which
> >>> also addresses this topic).
> >> Yes, the proble is how one assumes that an implementation would work.
> >> Who will check the policy?
> >> Is it part of the algorithm implementation, or part of a generic
> >> module that asks some parts
> >> of the algorithm implementation to give 'its parameter 1 and 2'?
> >>>
> >>> Thomas
> >>>
> >>


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwzCCBhow
ggQCoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZh
cmlhMQ8wDQYDVQQHEwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5
MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20u
b3JnMB4XDTA2MTEwMzAwMjA0OFoXDTA5MDczMDAwMjA0OFowgZExCzAJBgNVBAYTAkRFMRAwDgYD
VQQIEwdCYXZhcmlhMR4wHAYDVQQKExVPcGVuIFRleHQgQ29ycG9yYXRpb24xETAPBgNVBAsTCFNl
Y3VyaXR5MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEkMCIGCSqGSIb3DQEJARYVdGdvbmRyb21A
b3BlbnRleHQuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4dYGy7tHBES4+h3Z
NS3dQi4TFm0TE84vyqzWPIwPZHpP927sRb3jh5PD7WChVPcb4KG8P4q2c+bJ+EVdaRv1Uvw57n3n
uhAbXtb7kcnFPIMfYn92GOBZpHoDCgT8DRYuQHvScH8l4W9WDtc2NHLkIldIBybxHLVdXX3QJsk3
/OFmJ9shKangwS+AT25cgGj5Ltu9iB2CFCrIKn5CCWDvObwoxEsYPj84Z3ygKUEOijNfkISuKiby
/xLIfjDPozpWdb2rb0Oi9pYJkjuzmzF5qwHZDFySeJoVKMIHi4n956m7Etahow+7hQk57+XwQyIL
l+s62FlMzsyMCZZ6MlpTs+OrymeobB44ttUn6F370N9GNXg/eV388IYA8e9Mui5F459mrM/9ub9T
fQmqoW+SdF4AvBi7BOWTHRJ/DrAWeBcw+9UeX3bWgX6cLNNv+SlNSKSiGV+syf5tqD4APvgfIY0a
PPmRLsbUy1Urwfe+BjqOLXZe6w+4WFbbKbAdltpUQCK04eA+g5tIT1ZT8zOxH+EvlJFSoV+i4btp
Y7Ni2AfJLvf9OdgwoOJBp3gXQL4o5VWzd362GHYjj94X0sqlJf8Ggcdxz4BR4/EsFRt6MQPXrfoi
wPBku/q08YwXPe1hvaW4k8MVosddaka88UY8LJrtXkZWXRERyPMH+cIJNw0CAwEAAaN7MHkwCQYD
VR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD
VR0OBBYEFDwj2KwaDOuWxUz/MiFFnt7sOYVoMB8GA1UdIwQYMBaAFH1WtHxZxnLGHnuMc6Pu+Gv9
BD5CMA0GCSqGSIb3DQEBBQUAA4ICAQCne6u3Ko8FefZSDqOq8pKEYAKbuV5NoGZqImoamelDm1Yd
6GQzacZF1aJyfHEytazk2GqmcGGB/yrqaFeQopiSTqGGnB7/8fgYMAUlv+S4NHJoohAVZC/onG0W
PDtWKnOyARntV2UxWIikKZZaYKlinvAwaBnmguqboWgbKBpYiV1+U7TgHlYdd9W25k1D+0n+E1mN
GvqEfPFxRHEiFdLxWuTtSZnvLDAihAEcTlcKOKGz5RIMHPxG4OcVz+acGKEi8WBHQRVx7KKUkLOy
SprjUpxSnEi1AbOEK2y0T/Bao3UkkxQiqKC67OUK0GPbvwat18GLmvesHArtTI8SVty63qdEmxnB
CKYLuSOJbXBe5SFPrcruMvumiA4QPdcGMyTiLqDtn97QcN+F5HfB93mKFZfqZwOqi86R6jgzFd3J
HsujJXDpZ0tIFRcDespNBcUIV+A38JxHsxF7xHw5wVQMEEsMceMjqEB3X58yAssNnXKD0E7WjIoO
SxlnODM++6xTBOIFB3N34ENNuj2Ck8196DUOei/YBEmI5oLIlXEKU/lHiDrq1D9TsjO7vhYoG+wC
vAFpGAicl25AGhaOTVeXKh+pTvHHlYva62Stww8eB/fHOW6VASWiUddE4OoxZfQiRkpn91K0rJc4
WHsP9HsBVEdA8xrfN36UXb3SXURnRzCCBqEwggSJoAMCAQICCQCamHOHv2sJlzANBgkqhkiG9w0B
AQUFADCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQ
MA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25k
cm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwHhcNMDYxMTAzMDAxMzMxWhcN
MDkwNzMwMDAxMzMxWjCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcT
Bk11bmljaDEQMA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRv
YmlhcyBHb25kcm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDRNLo77UVeV/wQ+ml3Nb5XWzkYT4Q8zo7Sl7CkuCT7UE9g
v8oFNJbzedTDn//SHkUKQJ3RpZf5VP/8gHvcFUVoiZjCMXYCsjlSJppouau3F0ED2wOle+nE9suX
lOuZVSsyuFSF89Yff8oD+wzHWi/9naeHrgKMVeqKa0Pcu1+tJ/zAoeeZHXlxHAuLQbF8XY2RGG0l
qSYXBwPuGqSVS9OKUP5kxLm+1Cd928h7PhwKJv9JP34YOWaQmxGL6KjkVnTacKpXPbhtqgtNsHC2
QWkmyyBAS8so5qAfIdOnlRi+U0hgwAKBiAF9OQh9g+xPoqLRmb81+Q18zjPDiIQ+KhwXfJeftUZp
fRy8k3thtOnkTqfKHTTaM+KaWR1bRY9DKR5u+zd/6qZ3/snVqBCNAKM0hktcSt7zQUcDo+1RsdW7
H8uJp/avtmYrmt21+Fy5+sN23sGWKNI/E3agPlTr0/jALm17ZomMP7/J4FUHsrxt5Sh6d1bWlxcR
xRIhU/8JU0BqbRSW1EKeBpzGnUJ3O65wHfyMrXi5aHG2gGXXoo2AiVTEUZylMsYxTCotEeZijfQN
zDH6oCvzePh4LF/Qo9u7T16Ovu3tRhOPQGfWltwC9gs+eJn4j7T2HJSEzVNZ3XTStzu8i/yKCcQZ
xWYy0j7ZXKZBSUmPyzuviSOvaU/K+QIDAQABo4H5MIH2MB0GA1UdDgQWBBR9VrR8WcZyxh57jHOj
7vhr/QQ+QjCBxgYDVR0jBIG+MIG7gBR9VrR8WcZyxh57jHOj7vhr/QQ+QqGBl6SBlDCBkTELMAkG
A1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQMA4GA1UEChMHR29u
ZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25kcm9tMSEwHwYJKoZI
hvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmeCCQCamHOHv2sJlzAMBgNVHRMEBTADAQH/MA0GCSqG
SIb3DQEBBQUAA4ICAQAmu3wb0JFEPQLfb9PLVEfSldtE9sLdEM4dpiJe1XqvgiI3pQI/lBzKbqcR
vg4fdP7muS3tcsqrI31L14+YzphrTLTWev86JdR23ir2oJCqrsHupuqYHI0egTRshejcTjnlBlmk
OSfxidjl+7RYjFAquFQEqHPEBb4Tcf6jXFbKzSLp/TcVG9a9x05C8wEJjDbINWxxb4EwjanKcMbh
ZNS8Vm0x4IwJhOYwkhx980WXruCoMKec9LwrPkAO/H/ZcpW2gR174oayrNXDYZIZ4nVU248jB52R
rrZxCt6/TbC8ftMzcafOLxP933RWtnf79qJbZLV9YspUEzQbuPbrb4nNuK/ZdOgJ9rNtLgZKqoa2
l5j9pNW4+yAh10s2+ZAUOlPv5wICK5gIGJo1Lj1P6cNOp3Yh03mudwM4XhQYyRCg2GbUIj0xXv/e
NkYfMGA5ljKmt9qnJ3qZKwgiFwMs2+nMfLDh6GuheAaCaWewHFMcgSoMYHNc43osufcygnKno3Eq
Fn8sn9YWM7X5vCuFK7+TGoJRVzVuwmzDqSG3l908auEKLetv03frw5v9cCB0ttExvsITo60lkuK3
Vy4CBDvE2U6BvuEr682hIUirV/X6oVORu3h44fTm1t5aibqwdWI3EpENwg9956Qpbo7uATZtQeWp
J6lsIPBAfc6YE6crOTGCBOEwggTdAgEBMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2
YXJpYTEPMA0GA1UEBxMGTXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0
eTEXMBUGA1UEAxMOVG9iaWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9t
Lm9yZwIBATAJBgUrDgMCGgUAoIICHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wNzA5MTMxMjU4MTFaMCMGCSqGSIb3DQEJBDEWBBQHNXc8cUgMellomf+Q3ttFMCcI
5DBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB
BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG
TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i
aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI
hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH
EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U
b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG
SIb3DQEBAQUABIICAHxN7fnrUbZvVB+ZCHmogk9TfsyPBoQ1ABjDFdkSQkui5tciYFjmSEhnuVf0
3XEoaHQTaCIbv75WQMCLiWi7XE+U+bkTXr8TBHLXILAFXB4SmEf+KeZapcTmVfrurFyvTnlKK2+N
h7oumrKCCSnkc/CsPJ2J8Ppv45jFpncBE3IfLLywdCC3m41qfoxLYCvvrVmLRcZ0YO1kNydcDsTi
fE/+L4Y0JjdAMy79tqdbiaVIq/fOG6xmJI6Hz9voZ4SlvQ08RxcmV+LvwPMxpC/3qO40ZQ4/IQWC
/vudUjnC/yy7NyApDbxMPXBM8/mnGx58DfWmyrrXSoZSv7Sbfrhcc01OtrVl/lxEwPGO6s3BU6HW
grswoI8NdnE5bw5ZSNw1EEJzBrBatd2e3QQIjyF/RfjpWV+ta75SQFRq73TaSVSWpbYYkX/nXFak
Swfbw9DvZzXqwmJdnDHVrd7tl9tZ0ecrIU397wT4n3baBtGTtFtr+6tbjSX8KJiENOdKdr5hriHi
CfeGJtD7QyMM5GRS2tQVKlF7Poke4tGDpkur9YbaGah/5n8pkctUq5foBa4ngHKkDKeiiEdJpbJG
Fldsxdn69+LW7ycrzFfTKu0JBb3ncdmveGJHV2mkSZsm65VqQQ/fGhCjwFW9jTzT2P78qJA9UL2x
JE3Pi+mizHkBmC/HAAAAAAAA

------=_NextPart_000_0023_01C7F616.809AA3C0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8DBufCj091206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2007 04:56:41 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8DBuf8I091205; Thu, 13 Sep 2007 04:56:41 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8DBucAD091198 for <ietf-ltans@imc.org>; Thu, 13 Sep 2007 04:56:40 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr)
Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 0713D40; Thu, 13 Sep 2007 13:56:34 +0200 (CEST)
Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02557-01; Thu, 13 Sep 2007 13:56:30 +0200 (CEST)
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id A29DC3C; Thu, 13 Sep 2007 13:56:30 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007091313562971:41225 ; Thu, 13 Sep 2007 13:56:29 +0200 
Message-ID: <46E924BC.6030309@edelweb.fr>
Date: Thu, 13 Sep 2007 13:53:32 +0200
From: Peter Sylvester <Peter.Sylvester@edelweb.fr>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Thomas Kunz <thomas.kunz@sit.fraunhofer.de>
Cc: ietf-ltans@imc.org, Susanne Okunick <susanne.okunick@sit.fraunhofer.de>
Subject: Re: draft-ietf-ltans-dssc-00 comments
References: <886F5D4C78AFB14D87261206BFB9612E1D31D982@scygmxs1.cygnacom.com> <46DC965F.3040506@sit.fraunhofer.de> <46DD9104.9070401@edelweb.fr> <46DFC57A.9000509@sit.fraunhofer.de> <46E50B10.4020507@edelweb.fr> <46E8419C.9070301@sit.fraunhofer.de>
In-Reply-To: <46E8419C.9070301@sit.fraunhofer.de>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 09/13/2007 01:56:29 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 09/13/2007 01:56:30 PM, Serialize complete at 09/13/2007 01:56:30 PM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070201040602050904070207"
X-Virus-Scanned: by amavisd-new at on-x.com
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a cryptographically signed message in MIME format.

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

Thomas Kunz wrote:
> Hello Peter,
>
> yes, your proposal sounds quite good. In the next version of our 
> draft, we will propose a new XML structure for parameter constraints:
>
> <Parameter name="modulus">
>    <Value>1024</Value>
>    <Constraint>minimum value</Constraint>
> </Parameter>
>
> I think, that's just about what you mean.
Not exactly. See below
>
> Another advantage of this approach would be that we will have only one 
> XML schema, which doesn't need to be extended for future algorithms.
This is the main goal. A policy and the information that are to be 
provided by an implementation follow one
schema that does not need to be extended for any new algorithm.

IMO there are two things to cover:


1 - Information from an implementation that contains actual implemented 
values.
2 - a policy that contains constraints
 
A verifier tests whether the actual values match the constraints.

I am not whether there is a need to type the parameter, i.e. can
we assume that all parameters can be represented always as integers
in a convenient way, i.e. in a such a way that a constraint can be
formulated nicely.

To take the example above:

For the information 1

<Parameter name="modulus" value="1024 "/>

and  for 2

<Parameter name="modulus">
<Constraint notAfter=.. notbefore=... >
<greater>1024</greater>
<and>
<smaller>4096</smaller>
<Constraint>


>
> The "name" attribute is optional and only for better readability and 
> understandability of the policy. It should not be processed by a 
> verifying entity.
It can be used in error message: "Parameter 'modulus' of algo  xxx' 
doesn't meet the
its constraint. You have a similar thing in SNMP, a user friendly name 
of a parameter.

But you also need  this in oder to identify correspondance of 1 and 2. I 
wouldn't
rely on the order, or  in other words, it may be that some parameter has no
constraints but is part of the algorithm characteristics.
>
> The "Constraint" element defines how the parameter has to be processed 
> and evaluated. In the example above, "minimum value" would mean, that 
> all keys with a modulus greater then 1024 are also valid at least as 
> long as the 1024 modulus.
> At this point, I'm not sure, if it's sufficient to give only a textual 
> value like "minimum value" or if it would be better to define 
> URIs/OIDs to express such processing constraints.
I think a contaraint language that can define value subsets is necssary 
and not
very difficult.
>
> Regards,
> Thomas
>
>
> Peter Sylvester schrieb:
>>
>>>>
>>> I'm not sure whether I understand your suggestion.
>>>
>>> In your example above, you suggest to have simply a list of all 
>>> currently valid key lengths?
>> Not in the policy but in the information about what is actually 
>> implemented by
>> an algorithm. I was not quite clear here.
>>
>>> But where do you have the validity periods of the particular values 
>>> (key  lengths)?
>> As part of the policy, you make constraints about values, e.g. 
>> parameter 1 may only have this
>> or that etc. You can CHECK such statements without knowing the actual 
>> semantics.
>>
>>> A second problem I see is, that some algorithms are defined by more 
>>> than one parameter (e.g. DSA: 'p' and 'q'). So in the XML encoding, 
>>> you have to distinguish the different parameters (e.g. via its name).
>> There is the point. You do not have to distinguish any semantics of 
>> what p q, or keys or else would mean.
>> I think a verifying entity can be made of two compoents: A very 
>> generic one, which verifies the
>> conformity of ALL alogorithms and, for each algorithm implementation, 
>> a specific module which,
>> depending on the algorithm implementation can indicate how some 
>> values are filled. The verification
>> module does not need to know anything about the actual semantics of a 
>> particular parameter.
>>
>> Compare this with SNMP: If you have some "box" with a mib, onlmy the 
>> box knows the semantics
>> of the values, not the SNMP client and network supervision tools. 
>> They just can set value and display
>> textuals labels defined by a mib.
>>
>> If one wants to define policies about certain values, then the 
>> network tool need to know the specific
>> mibs, there is no way to make a generic policy for each kind of mib. 
>> But in our case, the potential
>> number of algorithms is not extremely high, and in any way, the 
>> policy will say not say more than
>> constraints of a few values.
>>>
>>>
>>>> in a policy one would only specify value constraints parameters for 
>>>> an actual algorithms,
>>>> a kind of pattern which can always be checked, example
>>>>   first parameter must be greater than  1023, second less than 8192 
>>>> or whatever.
>>> >
>>> Do you mean to encode this pattern in XML? And for example such a 
>>> pattern would say: 'If a value of 1024 is valid, every value greater 
>>> than 1024 is also valid'?
>>>
>>> In principle I agree with you. We are also discussing the problem 
>>> which arises if new algorithms are added (see Susanne's mail which 
>>> also addresses this topic).
>> Yes, the proble is how one assumes that an implementation would work. 
>> Who will check the policy?
>> Is it part of the algorithm implementation, or part of a generic 
>> module that asks some parts
>> of the algorithm implementation to give 'its parameter 1 and 2'?
>>>
>>> Thomas
>>>
>>


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwOTEzMTE1MzMyWjAjBgkqhkiG9w0B
CQQxFgQUVMxGH9BsHWlyLJDfKhLnlDKd9ScwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGABfGN0mny8VaOzptp
sxLWi6aYGogQyGiGi1y0LMqFmAJZ6n+088qyjkx8DGDRcRxogKzGBIanvhJAFWKhsAAiFA86
hyqmBX8w30GcbJemMCSVm/n/kMTk4pKKWt8b9nC449D4GCBjfXVNLntdWvxZCmOiqGGX8lnr
npw1SyNPT+0AAAAAAAA=
--------------ms070201040602050904070207--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8CJj0Xh093777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Sep 2007 12:45:00 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8CJj0g2093776; Wed, 12 Sep 2007 12:45:00 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8CJivhO093761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-ltans@imc.org>; Wed, 12 Sep 2007 12:44:59 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de)
Received: from [141.12.111.2] (vpnsit2_2.sit.fraunhofer.de [141.12.111.2]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id l8CJiYMC031988; Wed, 12 Sep 2007 21:44:34 +0200
Message-ID: <46E8419C.9070301@sit.fraunhofer.de>
Date: Wed, 12 Sep 2007 21:44:28 +0200
From: Thomas Kunz <thomas.kunz@sit.fraunhofer.de>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Peter Sylvester <Peter.Sylvester@edelweb.fr>
CC: ietf-ltans@imc.org, Susanne Okunick <susanne.okunick@sit.fraunhofer.de>
Subject: Re: draft-ietf-ltans-dssc-00 comments
References: <886F5D4C78AFB14D87261206BFB9612E1D31D982@scygmxs1.cygnacom.com> <46DC965F.3040506@sit.fraunhofer.de> <46DD9104.9070401@edelweb.fr> <46DFC57A.9000509@sit.fraunhofer.de> <46E50B10.4020507@edelweb.fr>
In-Reply-To: <46E50B10.4020507@edelweb.fr>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050905040907090503080902"
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a cryptographically signed message in MIME format.

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

Hello Peter,

yes, your proposal sounds quite good. In the next version of our draft, 
we will propose a new XML structure for parameter constraints:

<Parameter name="modulus">
    <Value>1024</Value>
    <Constraint>minimum value</Constraint>
</Parameter>

I think, that's just about what you mean.
Another advantage of this approach would be that we will have only one 
XML schema, which doesn't need to be extended for future algorithms.

The "name" attribute is optional and only for better readability and 
understandability of the policy. It should not be processed by a 
verifying entity.

The "Constraint" element defines how the parameter has to be processed 
and evaluated. In the example above, "minimum value" would mean, that 
all keys with a modulus greater then 1024 are also valid at least as 
long as the 1024 modulus.
At this point, I'm not sure, if it's sufficient to give only a textual 
value like "minimum value" or if it would be better to define URIs/OIDs 
to express such processing constraints.

Regards,
Thomas


Peter Sylvester schrieb:
> 
>>>
>> I'm not sure whether I understand your suggestion.
>>
>> In your example above, you suggest to have simply a list of all 
>> currently valid key lengths?
> Not in the policy but in the information about what is actually 
> implemented by
> an algorithm. I was not quite clear here.
> 
>> But where do you have the validity periods of the particular values 
>> (key  lengths)?
> As part of the policy, you make constraints about values, e.g. parameter 
> 1 may only have this
> or that etc. You can CHECK such statements without knowing the actual 
> semantics.
> 
>> A second problem I see is, that some algorithms are defined by more 
>> than one parameter (e.g. DSA: 'p' and 'q'). So in the XML encoding, 
>> you have to distinguish the different parameters (e.g. via its name).
> There is the point. You do not have to distinguish any semantics of what 
> p q, or keys or else would mean.
> I think a verifying entity can be made of two compoents: A very generic 
> one, which verifies the
> conformity of ALL alogorithms and, for each algorithm implementation, a 
> specific module which,
> depending on the algorithm implementation can indicate how some values 
> are filled. The verification
> module does not need to know anything about the actual semantics of a 
> particular parameter.
> 
> Compare this with SNMP: If you have some "box" with a mib, onlmy the box 
> knows the semantics
> of the values, not the SNMP client and network supervision tools. They 
> just can set value and display
> textuals labels defined by a mib.
> 
> If one wants to define policies about certain values, then the network 
> tool need to know the specific
> mibs, there is no way to make a generic policy for each kind of mib. But 
> in our case, the potential
> number of algorithms is not extremely high, and in any way, the policy 
> will say not say more than
> constraints of a few values.
>>
>>
>>> in a policy one would only specify value constraints parameters for 
>>> an actual algorithms,
>>> a kind of pattern which can always be checked, example
>>>   first parameter must be greater than  1023, second less than 8192 
>>> or whatever.
>> >
>> Do you mean to encode this pattern in XML? And for example such a 
>> pattern would say: 'If a value of 1024 is valid, every value greater 
>> than 1024 is also valid'?
>>
>> In principle I agree with you. We are also discussing the problem 
>> which arises if new algorithms are added (see Susanne's mail which 
>> also addresses this topic).
> Yes, the proble is how one assumes that an implementation would work. 
> Who will check the policy?
> Is it part of the algorithm implementation, or part of a generic module 
> that asks some parts
> of the algorithm implementation to give 'its parameter 1 and 2'?
>>
>> Thomas
>>
> 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCC
BacwggSPoAMCAQICAgDfMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK
EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB
IHYyMB4XDTA0MDYwOTA3MzQyM1oXDTA4MTIzMTIzMDAwMFowVzELMAkGA1UEBhMCREUxEzAR
BgNVBAoTCkZyYXVuaG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRQwEgYD
VQQDEwtUaG9tYXMgS3VuejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALFclK+E
n2p85uM4bbfxKqpHBUOd9qSCNnuPcITixktM7A1rRmbu1nbQcppKj40Bjv/rOqTavvux1oiS
O+mzrOq9Aa0MmjPyFpjcPOK62EaGFMNuHx7cafnLe4Y8EJcdl9RZdBO+SY/2gr5wq9/jvaaF
fkU0Q+5iY4NS2/nLZ2mYaqRI2wCxaLAMyfJYL4z5/qEW51KTQ0LHHm9qiVZg2hempXSMABC9
6/BzYKwaGMh0vaSCppUFdJvhVNwAUHsUkosNTFiU9ks2fIpzlNPJv7UE8wfTrCzAf4CBgWTA
jHXJdgaAF2rD0JjbbpA/G1w3rAT8yKy3mfljJOcLcuUZYBMCAwEAAaOCAoMwggJ/MIGeBglg
hkgBhvhCAQ0EgZAWgY1Tb2Z0d2FyZSBaZXJ0aWZpa2F0IGRlciBaZXJ0aWZpemllcnVuZ2lu
c3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNoZW47
IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wTQYIKwYB
BQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvRmhHLUNB
X3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9wa2kuZnJhdW5o
b2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwCQYDVR0TBAIwADBKBgNV
HRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIuZGWGGWh0dHA6Ly9w
a2kuZnJhdW5ob2Zlci5kZS8wKAYDVR0RBCEwH4EddGhvbWFzLmt1bnpAc2l0LmZyYXVuaG9m
ZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8v
cGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsG
AQUFBwMDBggrBgEFBQcDBDALBgNVHQ8EBAMCA/gwHQYDVR0OBBYEFAT5q7Rw9gTlubggX/wN
+6oZowK3MB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0GCSqGSIb3DQEBBQUA
A4IBAQDoyyNHTB3tv3kVsap2axcaFKsKwzTNqq/bnj+a6VFpy5ejBbtusHG8njqa+LheRT/k
Vi6xFYFXegw54Cf6IGCJ2E1EBWfgJXqyaO+PgUggd6bLOy/8fZauR1oIlt4nQNjoXyJxqV9x
tpgxZsF7pHtqcwh4ZYA+nsEC6DdCfsUqegrqzmtA7hZ34o3yeZCR5qs3M9jja3lw9KfxnbHh
6CM/vM7o6KIEFdx8RlIWpYEJB05rqMO7PrXiRrmJDHeCwRtx+R5iskUX3grhh6yHBRM1NKHx
LY/waDKxBj3ZXPSkN0k7PBppeuYHgJ4ZVAuvP9v2GKkyU3pHOcwE5iZOiQyNMIIFpzCCBI+g
AwIBAgICAN8wDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu
aG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjIwHhcN
MDQwNjA5MDczNDIzWhcNMDgxMjMxMjMwMDAwWjBXMQswCQYDVQQGEwJERTETMBEGA1UEChMK
RnJhdW5ob2ZlcjEMMAoGA1UECxMDU0lUMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1Ro
b21hcyBLdW56MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsVyUr4Sfanzm4zht
t/EqqkcFQ532pII2e49whOLGS0zsDWtGZu7WdtBymkqPjQGO/+s6pNq++7HWiJI76bOs6r0B
rQyaM/IWmNw84rrYRoYUw24fHtxp+ct7hjwQlx2X1Fl0E75Jj/aCvnCr3+O9poV+RTRD7mJj
g1Lb+ctnaZhqpEjbALFosAzJ8lgvjPn+oRbnUpNDQsceb2qJVmDaF6aldIwAEL3r8HNgrBoY
yHS9pIKmlQV0m+FU3ABQexSSiw1MWJT2SzZ8inOU08m/tQTzB9OsLMB/gIGBZMCMdcl2BoAX
asPQmNtukD8bXDesBPzIrLeZ+WMk5wty5RlgEwIDAQABo4ICgzCCAn8wgZ4GCWCGSAGG+EIB
DQSBkBaBjVNvZnR3YXJlIFplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5naW5zdGFueiAo
Q0EpIGRlciBGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVs
emVydGlmaWthdCB2aWEgaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlLzBNBggrBgEFBQcBAQRB
MD8wPQYIKwYBBQUHMAGGMWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0FfdjJfT0NT
UC1SZXNwb25kZXIwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL3BraS5mcmF1bmhvZmVyLmRl
L0ZoRy1DQS1DZXJ0cy9GaEctQ0FfdjJfQ1JMLmNybDAJBgNVHRMEAjAAMEoGA1UdEgRDMEGB
JHplcnRpZml6aWVydW5nc2luc3RhbnpAZnJhdW5ob2Zlci5kZYYZaHR0cDovL3BraS5mcmF1
bmhvZmVyLmRlLzAoBgNVHREEITAfgR10aG9tYXMua3VuekBzaXQuZnJhdW5ob2Zlci5kZTBM
BgNVHSAERTBDMEEGCysGAQQBhgpQAgEBMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly9wa2kuZnJh
dW5ob2Zlci5kZS9wb2xpY3kuaHRtbDAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMG
CCsGAQUFBwMEMAsGA1UdDwQEAwID+DAdBgNVHQ4EFgQUBPmrtHD2BOW5uCBf/A37qhmjArcw
HwYDVR0jBBgwFoAUAMP872PCVigvUQt1Vv97BekcyfEwDQYJKoZIhvcNAQEFBQADggEBAOjL
I0dMHe2/eRWxqnZrFxoUqwrDNM2qr9ueP5rpUWnLl6MFu26wcbyeOpr4uF5FP+RWLrEVgVd6
DDngJ/ogYInYTUQFZ+AlerJo74+BSCB3pss7L/x9lq5HWgiW3idA2OhfInGpX3G2mDFmwXuk
e2pzCHhlgD6ewQLoN0J+xSp6CurOa0DuFnfijfJ5kJHmqzcz2ONreXD0p/GdseHoIz+8zujo
ogQV3HxGUhalgQkHTmuow7s+teJGuYkMd4LBG3H5HmKyRRfeCuGHrIcFEzU0ofEtj/BoMrEG
Pdlc9KQ3STs8Gml65geAnhlUC68/2/YYqTJTekc5zATmJk6JDI0xggL/MIIC+wIBATBVME8x
CzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVy
LUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zAJBgUrDgMCGgUAoIIBfzAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA5MTIxOTQ0MjhaMCMGCSqGSIb3
DQEJBDEWBBSGAP0PZ78QnXJU9O82NKwXXTlK+jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3
DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv
ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm
BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx
KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG
SIb3DQEBAQUABIIBADLT236X5BNMO8hbD0um4Ox/55llw7PeASPjUXujp9+yk4dZEMSZixcb
iE+SoM83Pr47R/1JhV1QXNR64sPdDKTgp/uZ0LsBebCULUnpGWIz9n/ht4B5NgqlTVDHPfGQ
8G2PtoYmHPBH8WEQN8F1O51ABMu2jC5D4OyU4XLq6x+8tHc47ANrWcrgwWoY5yq2lMCrkQpw
R4CsJNZE6N/9apsnDUEMcSfPvqL47ldMn5BOk/i/SQSo2T7EOk/vDgZvXTmlFnGd3I6yDvyp
qdEML+ftcI7imEsVtJEhIsoa8z7QJ/G/xUhykKlrOvhbxQHN4HWZzBZLlPqlhCpbdfMyl78A
AAAAAAA=
--------------ms050905040907090503080902--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8CHOKYW080207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Sep 2007 10:24:20 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8CHOKiS080206; Wed, 12 Sep 2007 10:24:20 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8CHOH4A080193 for <ietf-ltans@imc.org>; Wed, 12 Sep 2007 10:24:18 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l8CHOEmV027981; Wed, 12 Sep 2007 19:24:15 +0200 (MEST)
Received: from MUCXGC2.opentext.net (mucxg01.opentext.net [149.235.128.135]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id l8CHODLF011813; Wed, 12 Sep 2007 13:24:13 -0400 (envelope-from tgondrom@opentext.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: security issue in archive timestamp chain?
Date: Wed, 12 Sep 2007 19:24:13 +0200
Message-ID: <2666EB2A846BAC4BB2D7F593301A78680187F912@MUCXGC2.opentext.net>
In-Reply-To: <20070912164711.GU29940@mars.cry.pto>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: security issue in archive timestamp chain?
Thread-Index: Acf1XbGWr2nTDmSORIayWx08ae9GsAAAwgnw
X-Priority: 5
Importance: low
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Julien Stern" <julien.stern@cryptolog.com>
Cc: <ietf-ltans@imc.org>
X-Archived: msg.BQ2Rkzv:2007-09-12:mucpm02.smtp.dmz.opentext.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l8CHOJ4A080199
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Hi Julien, 
I agree. 

And maybe one additional comments:
ERS also recommends to use 2 or more redundant ERS (in parallel) with different TSAs to even further reduce this already small risk. (Of course assuming that not all of the different TSAs' keys will be compromised at the very same time....)

- Tobias





> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org]
> On Behalf Of Julien Stern
> Sent: Wednesday, September 12, 2007 6:47 PM
> To: ietf-ltans@imc.org
> Subject: Re: security issue in archive timestamp chain?
> 
> 
> Hello Vittek and all,
> 
> I'm getting more and more confused by the discussion :)
> 
> If I understand correctly, you are concerned by the fact that the
> "re-timestamping" of a timestamp does not include a "grace period"
> in a way similar to the original XAdES or CAdES signature that you
> want to protect.
> 
> If this is indeed your concern, my humble opinion is that:
> 
> 1) You are perfectly correct
> 
>     if the inner timestamp certificate is revoked minutes before the
>     "re-timestamping", you may not be able to catch it.
> 
> 2) There is nothing that can be done about it
> 
>     The grace period of the original signature is made possible with
>     a first timestamp. A grace period on a timestamp would imply the
>     need to timestamp the timestamp as soon as possible, resulting
>     in a infinite chain of timestamps ;)
> 
> 3) It is not a big issue
> 
>     A timestamp or CA compromise is a very rare and drastic event. View
> ERS
>     as a way to automatically maintain trust after expiration of some
>     certificates and after cryptanalysis of some algorithms. In the case
>     of a compromise, a manual or semi-manual process will probably be
> needed
>     anyway (at least to input the date of the compromise in the system).
> 
> 4) So do your best
> 
>     The "best" you can do is to gather all verification information at
>     the date of your latest timestamp and to "protect" them, either
>     inside the ERS or by an other ERS. Hence the sentence in the RFC:
>     "the last Archive Timestamp has to be valid at the time the
>      verification is performed."
> 
> Regards,
> 
> --
> Julien
> 
> On Wed, Sep 12, 2007 at 06:12:15PM +0200, Tobias Gondrom wrote:
> > Hello Vittek,
> >
> > I am not sure I fully understand your problem.
> >
> > Maybe this recommendation helps: in real world usage an initial ATS-1 is
> applied ASAP (right after any potential grace period), which I personally
> would assume as a very short time span.
> >
> > This means by applying a first ATS initially after archiving you keep t5
> very near to t4 and also have the advantage that you do not need to watch
> over all the signatures and their cryptographic algorithms individually
> but rather watch the algorithms used in ATS-1.
> >
> >
> >
> > We had a validate draft, which recently expired, which also describes a
> bit how to handle these things, but I did not find the time to update the
> draft yet:
> >
> > http://tools.ietf.org/html/draft-ietf-ltans-validate-01
> >
> >
> >
> > greetings, Tobias
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-
> ltans@mail.imc.org] On Behalf Of Vittek Robert
> > Sent: Friday, September 07, 2007 5:57 PM
> > To: ietf-ltans@imc.org
> > Cc: Santosh Chokhani; Carl Wallace; todd glassey
> > Subject: RE: security issue in archive timestamp chain?
> >
> >
> >
> > Thank all of you for answers. Well, first I have to explain why I
> submitted my question to LTANS group.
> >
> >
> >
> > I know that LTANS does not deal with electronic signatures or XAdES but
> in fact it addresses very similar problem of long term archiving.
> >
> > XAdES itself does not address verification of validation data of
> signature time-stamps or archive time-stamps, it only requires to protect
> these data together with previous time-stamps by next archive time-stamp.
> >
> > As I wanted to get inspired how to do it, I read the ERS specification
> but I did not find the answer anyway. Verification of TS validation data
> seems to be out od scope of every document.
> >
> >
> >
> > This is the scenarion which I considered:
> >
> > t1. contract document D is electronically signed resulting in ES (D
> states e.g. that 10 years from signature somebody is due to pay a lot of
> money).
> >
> > t2. TS is applied to ES to prove its existence in time t2 (countdown of
> 10 years begins).
> >
> > t3. all validation data for signer's certificate (certificates,
> revocations) are gathered after grace period and the contract signature ES
> is proved valid in time t2.
> >
> > t4. all validation data for TS certificate are gathered and TS is found
> valid in t4.
> >
> > t5. archive ATS is applied to bundle (D, ES, TS, validation data for
> signer's certificate, validation data for TS certificate) to safeguard D,
> ES, TS and all validation data used.
> >
> >
> >
> > Question is: How can I be sure that TS certificate is still valid in t5?
> Next CRL can list TS certificate with revocationDate (or perhaps even
> invalidityDate) < t5!! And if TS certificate is NOT valid, then it may be
> even possible that ES did not exist in t2 but only later. There is no mean
> how to incorporate Next CRL into XAdES structures.
> >
> >
> >
> > t6. long after the CA (which issued signer's certificate) and TSA (which
> issued TS) ceased operation and availability of the issued CRLs is
> history, D and ES come under dispute, but arbitrator (a very wise human)
> can only say: There is a valid archive ATS (issued e.g. by another TSA,
> still operating) applied to the bundle of data but truly I am not sure
> about the validity of TS certificate as the evidence - "Next CRL" - is not
> available to me anymore. So there is a possibility that TS certificate was
> revoked before ATS to safeguard bundle of validation data was issued.
> >
> >
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From: Santosh Chokhani [mailto:chokhani@orionsec.com]
> > Sent: Wednesday, September 05, 2007 12:15 AM
> > To: Carl Wallace; Vittek Robert; ietf-ltans@imc.org
> > Subject: RE: security issue in archive timestamp chain?
> >
> > In the last sentence, I meant tc > t2 (t2 being the time stamp time).
> >
> >
> >
> > ________________________________
> >
> > From: Santosh Chokhani
> > Sent: Tuesday, September 04, 2007 6:12 PM
> > To: 'Carl Wallace'; Vittek Robert; ietf-ltans@imc.org
> > Subject: RE: security issue in archive timestamp chain?
> >
> >
> >
> > Carl,
> >
> >
> >
> > While what you say is correct, I do not think this answers the question
> Robert has.  Let us consider the following scenario
> >
> >
> >
> > Time t1 is the thisUpdate for a CRL used to verify the time stamp
> applied at time t2.
> >
> >
> >
> > Time t3 is when the time stamp is renewed.
> >
> >
> >
> > We know t3 > t2 > t1.
> >
> >
> >
> > Time tr is thisUpdate for a CRL when the TSA first appear as
> compromised.  tr > t1.
> >
> >
> >
> > Time tc is the actual time of compromise.  tr > tc
> >
> >
> >
> > As long as CRL for t1 is produced using ERS as Carl says, the claimant
> can prove the legitimacy of the time stamp.
> >
> >
> >
> > If CRL for tr is also produced, the time stamp can come under dispute.
> If there is an invalidity date associated with the TSA entry and that date
> is past t2, the time stamp is legitimate.
> >
> >
> >
> > Note that checking revocation status of TSA at time t3 technically does
> not help since tr can come at any time, including after t3.
> >
> >
> >
> > Also, if one were to check the revocation status of TSA at time t3,
> legitimate time stamps that were applied prior to tc or tr may be
> rejected.  It is tc that is hard to deal with.  That is why we have humans
> and courts and other supporting evidence to ferret things out.
> >
> >
> >
> > I have not purposely included nextUpdate analysis in this since
> compromise of TSA may or may not be detected by the nextUpdate.
> >
> >
> >
> > In summary, there will be situations when TSA is compromised, some of
> the time stamps will come under dispute and that dispute will need to be
> resolved using other evidence.
> >
> >
> >
> > This also points to the value of having invalidity date in CRL for TSA
> entries.  As long as tc is present in tr and tc > t1, the time stamp will
> not come under dispute.
> >
> > ________________________________
> >
> > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-
> ltans@mail.imc.org] On Behalf Of Carl Wallace
> > Sent: Tuesday, September 04, 2007 1:45 PM
> > To: Vittek Robert; ietf-ltans@imc.org
> > Subject: RE: security issue in archive timestamp chain?
> >
> >
> >
> > There's no need to safeguard the validation data for ATS1 at the time
> ATS2 is applied.  The validation data can be preserved independently of
> the data and retrieved using SCVP/ERS.  Amongst other benefits, this
> allows for a grace period to be applied between the time ATS2 was
> generated and the time of interest for validating the TSA1 credentials.
> >
> > > -----Original Message-----
> > > From: owner-ietf-ltans@mail.imc.org
> > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert
> > > Sent: Tuesday, September 04, 2007 1:23 PM
> > > To: ietf-ltans@imc.org
> > > Subject: security issue in archive timestamp chain?
> > >
> > >
> > > We are currently implementing a long term electronic
> > > signature based on XAdES, so I went through TS 101 903, TS
> > > 101 733 and other RFCs that led me finaly to LTANS group
> > > because XAdES does not address the problem of validation of
> > > TSA certificates ("Rules for acceptance of the validity of
> > > the signature within the time-stamp, involving trust
> > > decisions, are out of the scope of the present document.").
> > >
> > > I am interested in solving the following problem.
> > >
> > > http://tools.ietf.org/html/rfc4998#section-5.3 states that:
> > > Each Archive Timestamp MUST be valid relative to the time of
> > > the following Archive Timestamp.
> > >
> > > Let's assume that we have Archive Time-Stamp 1 (ATS1) and we
> > > need to renew it and safeguard the validation data for ATS1
> > > at the same time. But the next Archive Time-Stamp 2 (ATS2)
> > > can prove existence only of the CRLs issued before time T2
> > > (from ATS2). ATS2 does NOT give any evidence that there was
> > > not another CRL2 (issued by CA that issued TSA1 certificate)
> > > which contained information on revocation of TSA1 certificate.
> > >
> > > I think that arbitration on validity of ATS1 might take place
> > > long after the archive of relevant CRLs is available and long
> > > after the used cryptography is strong enough, so the attacker
> > > might produce such CRL2 himself just to cast doubt upon the
> > > archived data.
> > >
> > > In other words: while T2 - safeguardedCRLforTSA1.thisUpdate >
> > > 0, arbitrator can not be sure that there was not another CRL2
> > > that listed TSA1 certificate.
> > >
> > > Am I missing something or is it a security issue?
> > >
> > >
> > > Mgr. Robert Vittek
> > >
> > > DITEC, a.s.
> > > Bratislava Business Center V
> > > Plynárenská 7/C
> > > 821 09 Bratislava
> > >
> > > voice: +421 2 58 222 487
> > > fax: +421 2 58 222 777
> > > cell: +421 908 797 827
> > > mailto:vittek@ditec.sk
> > >
> >




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8CGlQCm076159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Sep 2007 09:47:26 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8CGlQCp076158; Wed, 12 Sep 2007 09:47:26 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mallaury.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8CGlOuf076149 for <ietf-ltans@imc.org>; Wed, 12 Sep 2007 09:47:25 -0700 (MST) (envelope-from julien.stern@cryptolog.com)
Received: from uranus.cry.pto (cryptolog2.pck.nerim.net [213.41.184.9]) by mallaury.nerim.net (Postfix) with ESMTP id 6523D4F3BF for <ietf-ltans@imc.org>; Wed, 12 Sep 2007 18:47:07 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id A570D4401A for <ietf-ltans@imc.org>; Wed, 12 Sep 2007 18:47:17 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at cryptolog.com
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus.cry.pto [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6JVQkhChnnQ for <ietf-ltans@imc.org>; Wed, 12 Sep 2007 18:47:13 +0200 (CEST)
Received: from mars.cry.pto (isonoe.cry.pto [10.0.1.15]) by uranus.cry.pto (Postfix) with SMTP id 19F154400C for <ietf-ltans@imc.org>; Wed, 12 Sep 2007 18:47:12 +0200 (CEST)
Received: by mars.cry.pto (sSMTP sendmail emulation); Wed, 12 Sep 2007 18:47:12 +0200
From: "Julien Stern" <julien.stern@cryptolog.com>
Date: Wed, 12 Sep 2007 18:47:11 +0200
To: ietf-ltans@imc.org
Subject: Re: security issue in archive timestamp chain?
Message-ID: <20070912164711.GU29940@mars.cry.pto>
Mail-Followup-To: Julien Stern <julien.stern@cryptolog.com>, ietf-ltans@imc.org
References: <E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7430@mail.intra.ditec.sk> <2666EB2A846BAC4BB2D7F593301A78680187F8FE@MUCXGC2.opentext.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78680187F8FE@MUCXGC2.opentext.net>
User-Agent: Mutt/1.5.13 (2006-08-11)
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Hello Vittek and all,

I'm getting more and more confused by the discussion :)

If I understand correctly, you are concerned by the fact that the
"re-timestamping" of a timestamp does not include a "grace period"
in a way similar to the original XAdES or CAdES signature that you
want to protect.

If this is indeed your concern, my humble opinion is that:

1) You are perfectly correct

    if the inner timestamp certificate is revoked minutes before the
    "re-timestamping", you may not be able to catch it.

2) There is nothing that can be done about it

    The grace period of the original signature is made possible with
    a first timestamp. A grace period on a timestamp would imply the
    need to timestamp the timestamp as soon as possible, resulting
    in a infinite chain of timestamps ;)

3) It is not a big issue

    A timestamp or CA compromise is a very rare and drastic event. View ERS
    as a way to automatically maintain trust after expiration of some
    certificates and after cryptanalysis of some algorithms. In the case
    of a compromise, a manual or semi-manual process will probably be needed
    anyway (at least to input the date of the compromise in the system).

4) So do your best

    The "best" you can do is to gather all verification information at
    the date of your latest timestamp and to "protect" them, either
    inside the ERS or by an other ERS. Hence the sentence in the RFC:
    "the last Archive Timestamp has to be valid at the time the
     verification is performed."

Regards,

--
Julien

On Wed, Sep 12, 2007 at 06:12:15PM +0200, Tobias Gondrom wrote:
> Hello Vittek, 
> 
> I am not sure I fully understand your problem. 
> 
> Maybe this recommendation helps: in real world usage an initial ATS-1 is applied ASAP (right after any potential grace period), which I personally would assume as a very short time span. 
> 
> This means by applying a first ATS initially after archiving you keep t5 very near to t4 and also have the advantage that you do not need to watch over all the signatures and their cryptographic algorithms individually but rather watch the algorithms used in ATS-1. 
> 
>  
> 
> We had a validate draft, which recently expired, which also describes a bit how to handle these things, but I did not find the time to update the draft yet: 
> 
> http://tools.ietf.org/html/draft-ietf-ltans-validate-01 
> 
>  
> 
> greetings, Tobias
> 
>  
> 
>  
> 
>  
> 
>  
> 
> ________________________________
> 
> From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert
> Sent: Friday, September 07, 2007 5:57 PM
> To: ietf-ltans@imc.org
> Cc: Santosh Chokhani; Carl Wallace; todd glassey
> Subject: RE: security issue in archive timestamp chain?
> 
>  
> 
> Thank all of you for answers. Well, first I have to explain why I submitted my question to LTANS group.
> 
>  
> 
> I know that LTANS does not deal with electronic signatures or XAdES but in fact it addresses very similar problem of long term archiving.
> 
> XAdES itself does not address verification of validation data of signature time-stamps or archive time-stamps, it only requires to protect these data together with previous time-stamps by next archive time-stamp.
> 
> As I wanted to get inspired how to do it, I read the ERS specification but I did not find the answer anyway. Verification of TS validation data seems to be out od scope of every document.
> 
>  
> 
> This is the scenarion which I considered:
> 
> t1. contract document D is electronically signed resulting in ES (D states e.g. that 10 years from signature somebody is due to pay a lot of money).
> 
> t2. TS is applied to ES to prove its existence in time t2 (countdown of 10 years begins).
> 
> t3. all validation data for signer's certificate (certificates, revocations) are gathered after grace period and the contract signature ES is proved valid in time t2.
> 
> t4. all validation data for TS certificate are gathered and TS is found valid in t4.
> 
> t5. archive ATS is applied to bundle (D, ES, TS, validation data for signer's certificate, validation data for TS certificate) to safeguard D, ES, TS and all validation data used.
> 
>  
> 
> Question is: How can I be sure that TS certificate is still valid in t5? Next CRL can list TS certificate with revocationDate (or perhaps even invalidityDate) < t5!! And if TS certificate is NOT valid, then it may be even possible that ES did not exist in t2 but only later. There is no mean how to incorporate Next CRL into XAdES structures.
> 
>  
> 
> t6. long after the CA (which issued signer's certificate) and TSA (which issued TS) ceased operation and availability of the issued CRLs is history, D and ES come under dispute, but arbitrator (a very wise human) can only say: There is a valid archive ATS (issued e.g. by another TSA, still operating) applied to the bundle of data but truly I am not sure about the validity of TS certificate as the evidence - "Next CRL" - is not available to me anymore. So there is a possibility that TS certificate was revoked before ATS to safeguard bundle of validation data was issued.
> 
>  
> 
>  
> 
>  
> 
> ________________________________
> 
> From: Santosh Chokhani [mailto:chokhani@orionsec.com] 
> Sent: Wednesday, September 05, 2007 12:15 AM
> To: Carl Wallace; Vittek Robert; ietf-ltans@imc.org
> Subject: RE: security issue in archive timestamp chain?
> 
> In the last sentence, I meant tc > t2 (t2 being the time stamp time).
> 
>  
> 
> ________________________________
> 
> From: Santosh Chokhani 
> Sent: Tuesday, September 04, 2007 6:12 PM
> To: 'Carl Wallace'; Vittek Robert; ietf-ltans@imc.org
> Subject: RE: security issue in archive timestamp chain?
> 
>  
> 
> Carl,
> 
>  
> 
> While what you say is correct, I do not think this answers the question Robert has.  Let us consider the following scenario
> 
>  
> 
> Time t1 is the thisUpdate for a CRL used to verify the time stamp applied at time t2.
> 
>  
> 
> Time t3 is when the time stamp is renewed.
> 
>  
> 
> We know t3 > t2 > t1.
> 
>  
> 
> Time tr is thisUpdate for a CRL when the TSA first appear as compromised.  tr > t1.
> 
>  
> 
> Time tc is the actual time of compromise.  tr > tc
> 
>  
> 
> As long as CRL for t1 is produced using ERS as Carl says, the claimant can prove the legitimacy of the time stamp.
> 
>  
> 
> If CRL for tr is also produced, the time stamp can come under dispute.  If there is an invalidity date associated with the TSA entry and that date is past t2, the time stamp is legitimate.
> 
>  
> 
> Note that checking revocation status of TSA at time t3 technically does not help since tr can come at any time, including after t3.
> 
>  
> 
> Also, if one were to check the revocation status of TSA at time t3, legitimate time stamps that were applied prior to tc or tr may be rejected.  It is tc that is hard to deal with.  That is why we have humans and courts and other supporting evidence to ferret things out.
> 
>  
> 
> I have not purposely included nextUpdate analysis in this since compromise of TSA may or may not be detected by the nextUpdate.
> 
>  
> 
> In summary, there will be situations when TSA is compromised, some of the time stamps will come under dispute and that dispute will need to be resolved using other evidence.
> 
>  
> 
> This also points to the value of having invalidity date in CRL for TSA entries.  As long as tc is present in tr and tc > t1, the time stamp will not come under dispute.
> 
> ________________________________
> 
> From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace
> Sent: Tuesday, September 04, 2007 1:45 PM
> To: Vittek Robert; ietf-ltans@imc.org
> Subject: RE: security issue in archive timestamp chain?
> 
>  
> 
> There's no need to safeguard the validation data for ATS1 at the time ATS2 is applied.  The validation data can be preserved independently of the data and retrieved using SCVP/ERS.  Amongst other benefits, this allows for a grace period to be applied between the time ATS2 was generated and the time of interest for validating the TSA1 credentials.    
> 
> > -----Original Message----- 
> > From: owner-ietf-ltans@mail.imc.org 
> > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert 
> > Sent: Tuesday, September 04, 2007 1:23 PM 
> > To: ietf-ltans@imc.org 
> > Subject: security issue in archive timestamp chain? 
> > 
> > 
> > We are currently implementing a long term electronic 
> > signature based on XAdES, so I went through TS 101 903, TS 
> > 101 733 and other RFCs that led me finaly to LTANS group 
> > because XAdES does not address the problem of validation of 
> > TSA certificates ("Rules for acceptance of the validity of 
> > the signature within the time-stamp, involving trust 
> > decisions, are out of the scope of the present document."). 
> > 
> > I am interested in solving the following problem. 
> > 
> > http://tools.ietf.org/html/rfc4998#section-5.3 states that: 
> > Each Archive Timestamp MUST be valid relative to the time of 
> > the following Archive Timestamp. 
> > 
> > Let's assume that we have Archive Time-Stamp 1 (ATS1) and we 
> > need to renew it and safeguard the validation data for ATS1 
> > at the same time. But the next Archive Time-Stamp 2 (ATS2) 
> > can prove existence only of the CRLs issued before time T2 
> > (from ATS2). ATS2 does NOT give any evidence that there was 
> > not another CRL2 (issued by CA that issued TSA1 certificate) 
> > which contained information on revocation of TSA1 certificate. 
> > 
> > I think that arbitration on validity of ATS1 might take place 
> > long after the archive of relevant CRLs is available and long 
> > after the used cryptography is strong enough, so the attacker 
> > might produce such CRL2 himself just to cast doubt upon the 
> > archived data. 
> > 
> > In other words: while T2 - safeguardedCRLforTSA1.thisUpdate > 
> > 0, arbitrator can not be sure that there was not another CRL2 
> > that listed TSA1 certificate. 
> > 
> > Am I missing something or is it a security issue? 
> > 
> > 
> > Mgr. Robert Vittek 
> > 
> > DITEC, a.s. 
> > Bratislava Business Center V 
> > Plynárenská 7/C 
> > 821 09 Bratislava 
> > 
> > voice: +421 2 58 222 487 
> > fax: +421 2 58 222 777 
> > cell: +421 908 797 827 
> > mailto:vittek@ditec.sk 
> > 
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8CGFNlj071501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Sep 2007 09:15:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8CGFNPj071499; Wed, 12 Sep 2007 09:15:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8CGFKDK071487 for <ietf-ltans@imc.org>; Wed, 12 Sep 2007 09:15:21 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l8CGCJbe025556; Wed, 12 Sep 2007 18:12:19 +0200 (MEST)
Received: from MUCXGC2.opentext.net (mucxg01.opentext.net [149.235.128.135]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id l8CGCH9x016244; Wed, 12 Sep 2007 12:12:17 -0400 (envelope-from tgondrom@opentext.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F557.B043C4F5"
Subject: RE: security issue in archive timestamp chain?
Date: Wed, 12 Sep 2007 18:12:15 +0200
Message-ID: <2666EB2A846BAC4BB2D7F593301A78680187F8FE@MUCXGC2.opentext.net>
In-Reply-To: <E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7430@mail.intra.ditec.sk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: security issue in archive timestamp chain?
Thread-Index: AcfvHQtk4Sjkc7G8Qw2xNDTuvpRCWwAI1VtAAAAjl8AAh9HkcAD9nupw
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Vittek Robert" <vittek@ditec.sk>, <ietf-ltans@imc.org>
Cc: "Santosh Chokhani" <chokhani@orionsec.com>, "Carl Wallace" <CWallace@cygnacom.com>, "todd glassey" <tglassey@earthlink.net>
X-Archived: msg.BNyAX9c:2007-09-12:mucpm02.smtp.dmz.opentext.com
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

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

Hello Vittek,=20

=20

I am not sure I fully understand your problem.=20

=20

Maybe this recommendation helps: in real world usage an initial ATS-1 is =
applied ASAP (right after any potential grace period), which I =
personally would assume as a very short time span.=20

This means by applying a first ATS initially after archiving you keep t5 =
very near to t4 and also have the advantage that you do not need to =
watch over all the signatures and their cryptographic algorithms =
individually but rather watch the algorithms used in ATS-1.=20

=20

We had a validate draft, which recently expired, which also describes a =
bit how to handle these things, but I did not find the time to update =
the draft yet:=20

http://tools.ietf.org/html/draft-ietf-ltans-validate-01=20

=20

greetings, Tobias

=20

=20

=20

=20

________________________________

From: owner-ietf-ltans@mail.imc.org =
[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert
Sent: Friday, September 07, 2007 5:57 PM
To: ietf-ltans@imc.org
Cc: Santosh Chokhani; Carl Wallace; todd glassey
Subject: RE: security issue in archive timestamp chain?

=20

Thank all of you for answers. Well, first I have to explain why I =
submitted my question to LTANS group.

=20

I know that LTANS does not deal with electronic signatures or XAdES but =
in fact it addresses very similar problem of long term archiving.

XAdES itself does not address verification of validation data of =
signature time-stamps or archive time-stamps, it only requires to =
protect these data together with previous time-stamps by next archive =
time-stamp.

As I wanted to get inspired how to do it, I read the ERS specification =
but I did not find the answer anyway. Verification of TS validation data =
seems to be out od scope of every document.

=20

This is the scenarion which I considered:

t1. contract document D is electronically signed resulting in ES (D =
states e.g. that 10 years from signature somebody is due to pay a lot of =
money).

t2. TS is applied to ES to prove its existence in time t2 (countdown of =
10 years begins).

t3. all validation data for signer's certificate (certificates, =
revocations) are gathered after grace period and the contract signature =
ES is proved valid in time t2.

t4. all validation data for TS certificate are gathered and TS is found =
valid in t4.

t5. archive ATS is applied to bundle (D, ES, TS, validation data for =
signer's certificate, validation data for TS certificate) to safeguard =
D, ES, TS and all validation data used.

=20

Question is: How can I be sure that TS certificate is still valid in t5? =
Next CRL can list TS certificate with revocationDate (or perhaps even =
invalidityDate) < t5!! And if TS certificate is NOT valid, then it may =
be even possible that ES did not exist in t2 but only later. There is no =
mean how to incorporate Next CRL into XAdES structures.

=20

t6. long after the CA (which issued signer's certificate) and TSA (which =
issued TS) ceased operation and availability of the issued CRLs is =
history, D and ES come under dispute, but arbitrator (a very wise human) =
can only say: There is a valid archive ATS (issued e.g. by another TSA, =
still operating) applied to the bundle of data but truly I am not sure =
about the validity of TS certificate as the evidence - "Next CRL" - is =
not available to me anymore. So there is a possibility that TS =
certificate was revoked before ATS to safeguard bundle of validation =
data was issued.

=20

=20

=20

________________________________

From: Santosh Chokhani [mailto:chokhani@orionsec.com]=20
Sent: Wednesday, September 05, 2007 12:15 AM
To: Carl Wallace; Vittek Robert; ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?

In the last sentence, I meant tc > t2 (t2 being the time stamp time).

=20

________________________________

From: Santosh Chokhani=20
Sent: Tuesday, September 04, 2007 6:12 PM
To: 'Carl Wallace'; Vittek Robert; ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?

=20

Carl,

=20

While what you say is correct, I do not think this answers the question =
Robert has.  Let us consider the following scenario

=20

Time t1 is the thisUpdate for a CRL used to verify the time stamp =
applied at time t2.

=20

Time t3 is when the time stamp is renewed.

=20

We know t3 > t2 > t1.

=20

Time tr is thisUpdate for a CRL when the TSA first appear as =
compromised.  tr > t1.

=20

Time tc is the actual time of compromise.  tr > tc

=20

As long as CRL for t1 is produced using ERS as Carl says, the claimant =
can prove the legitimacy of the time stamp.

=20

If CRL for tr is also produced, the time stamp can come under dispute.  =
If there is an invalidity date associated with the TSA entry and that =
date is past t2, the time stamp is legitimate.

=20

Note that checking revocation status of TSA at time t3 technically does =
not help since tr can come at any time, including after t3.

=20

Also, if one were to check the revocation status of TSA at time t3, =
legitimate time stamps that were applied prior to tc or tr may be =
rejected.  It is tc that is hard to deal with.  That is why we have =
humans and courts and other supporting evidence to ferret things out.

=20

I have not purposely included nextUpdate analysis in this since =
compromise of TSA may or may not be detected by the nextUpdate.

=20

In summary, there will be situations when TSA is compromised, some of =
the time stamps will come under dispute and that dispute will need to be =
resolved using other evidence.

=20

This also points to the value of having invalidity date in CRL for TSA =
entries.  As long as tc is present in tr and tc > t1, the time stamp =
will not come under dispute.

________________________________

From: owner-ietf-ltans@mail.imc.org =
[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace
Sent: Tuesday, September 04, 2007 1:45 PM
To: Vittek Robert; ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?

=20

There's no need to safeguard the validation data for ATS1 at the time =
ATS2 is applied.  The validation data can be preserved independently of =
the data and retrieved using SCVP/ERS.  Amongst other benefits, this =
allows for a grace period to be applied between the time ATS2 was =
generated and the time of interest for validating the TSA1 credentials.  =
 =20

> -----Original Message-----=20
> From: owner-ietf-ltans@mail.imc.org=20
> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert=20
> Sent: Tuesday, September 04, 2007 1:23 PM=20
> To: ietf-ltans@imc.org=20
> Subject: security issue in archive timestamp chain?=20
>=20
>=20
> We are currently implementing a long term electronic=20
> signature based on XAdES, so I went through TS 101 903, TS=20
> 101 733 and other RFCs that led me finaly to LTANS group=20
> because XAdES does not address the problem of validation of=20
> TSA certificates ("Rules for acceptance of the validity of=20
> the signature within the time-stamp, involving trust=20
> decisions, are out of the scope of the present document.").=20
>=20
> I am interested in solving the following problem.=20
>=20
> http://tools.ietf.org/html/rfc4998#section-5.3 states that:=20
> Each Archive Timestamp MUST be valid relative to the time of=20
> the following Archive Timestamp.=20
>=20
> Let's assume that we have Archive Time-Stamp 1 (ATS1) and we=20
> need to renew it and safeguard the validation data for ATS1=20
> at the same time. But the next Archive Time-Stamp 2 (ATS2)=20
> can prove existence only of the CRLs issued before time T2=20
> (from ATS2). ATS2 does NOT give any evidence that there was=20
> not another CRL2 (issued by CA that issued TSA1 certificate)=20
> which contained information on revocation of TSA1 certificate.=20
>=20
> I think that arbitration on validity of ATS1 might take place=20
> long after the archive of relevant CRLs is available and long=20
> after the used cryptography is strong enough, so the attacker=20
> might produce such CRL2 himself just to cast doubt upon the=20
> archived data.=20
>=20
> In other words: while T2 - safeguardedCRLforTSA1.thisUpdate >=20
> 0, arbitrator can not be sure that there was not another CRL2=20
> that listed TSA1 certificate.=20
>=20
> Am I missing something or is it a security issue?=20
>=20
>=20
> Mgr. Robert Vittek=20
>=20
> DITEC, a.s.=20
> Bratislava Business Center V=20
> Plyn=E1rensk=E1 7/C=20
> 821 09 Bratislava=20
>=20
> voice: +421 2 58 222 487=20
> fax: +421 2 58 222 777=20
> cell: +421 908 797 827=20
> mailto:vittek@ditec.sk=20
>=20


------_=_NextPart_001_01C7F557.B043C4F5
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>RE: security issue in archive timestamp chain?</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<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:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h1
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:21.6pt;
	text-indent:-21.6pt;
	mso-list:l0 level1 lfo2;
	font-size:12.0pt;
	font-family:Arial;
	font-weight:bold;}
h2
	{margin-top:12.0pt;
	margin-right:0cm;
	margin-bottom:3.0pt;
	margin-left:28.8pt;
	text-indent:-28.8pt;
	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:blue;
	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";}
p.stylecentered, li.stylecentered, div.stylecentered
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
p.stylecentered0, li.stylecentered0, div.stylecentered0
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:877472175;
	mso-list-template-ids:-1258658728;}
@list l0:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>

</head>

<body lang=3DDE link=3Dblue vlink=3Dblue>

<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'>Hello Vittek, =
<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 =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I am not sure I =
fully
understand your problem. <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'>Maybe this =
recommendation
helps: in real world usage an initial ATS-1 is applied ASAP (right after =
any
potential grace period), which I personally would assume as a very short =
time
span. <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 means by =
applying a
first ATS initially after archiving you keep t5 very near to t4 and also =
have
the advantage that you do not need to watch over all the signatures and =
their
cryptographic algorithms individually but rather watch the algorithms =
used in
ATS-1. <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'>We had a =
validate draft, which
recently expired, which also describes a bit how to handle these things, =
but I
did not find the time to update the draft yet: =
<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'><a
href=3D"http://tools.ietf.org/html/draft-ietf-ltans-validate-01">http://t=
ools.ietf.org/html/draft-ietf-ltans-validate-01</a>
<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'>greetings, =
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>

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Vittek Robert<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, September =
07, 2007
5:57 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
ietf-ltans@imc.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Santosh Chokhani; =
Carl
Wallace; todd glassey<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: security =
issue in
archive timestamp chain?</span></font><span =
lang=3DEN-US><o:p></o:p></span></p>

</div>

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

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Thank all of you =
for
answers.&nbsp;Well, first I have to explain why I submitted my =
question&nbsp;to
LTANS group.</span></font><span lang=3DEN-US><o:p></o:p></span></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>I know =
that&nbsp;LTANS
does not deal with electronic signatures or XAdES but in fact it =
addresses very
similar problem of long term archiving.</span></font><span =
lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>XAdES itself =
does not
address verification of validation data of signature time-stamps or =
archive
time-stamps, it only requires to protect these data together with =
previous
time-stamps by next archive time-stamp.</span></font><span =
lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>As I wanted to =
get
inspired how to do it, I read the ERS specification but I did not find =
the
answer anyway. Verification of TS validation data seems to be out od =
scope of
every document.</span></font><span lang=3DEN-US><o:p></o:p></span></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>This is the =
scenarion
which I considered:</span></font><span =
lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>t1. contract =
document D
is electronically signed&nbsp;resulting in&nbsp;ES (D states e.g. that =
10 years
from signature somebody is due to pay a lot of =
money).</span></font><span
lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>t2. TS is =
applied
to&nbsp;ES to prove its existence&nbsp;in time t2 (countdown of 10 years
begins).</span></font><span lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>t3. all =
validation data
for signer's certificate (certificates, revocations) are gathered after =
grace
period and the contract signature ES is proved valid in time =
t2.</span></font><span
lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>t4. all =
validation data
for TS certificate are gathered and TS is found valid in =
t4.</span></font><span
lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>t5. archive ATS =
is
applied to bundle (D, ES, TS, validation data for signer's certificate,
validation data for TS certificate) to safeguard D, ES, TS and&nbsp;all
validation data used.</span></font><span =
lang=3DEN-US><o:p></o:p></span></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Question is: How =
can I be
sure that TS certificate is still valid in t5? Next CRL can list TS =
certificate
with revocationDate (or perhaps even invalidityDate) &lt; t5!! And =
if&nbsp;TS
certificate&nbsp;is NOT valid, then it may be even possible that&nbsp;ES =
did
not exist in t2 but only later. There is no mean how to incorporate Next =
CRL
into XAdES structures.</span></font><span =
lang=3DEN-US><o:p></o:p></span></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>t6. long after =
the CA
(which issued signer's certificate) and TSA (which issued TS) ceased =
operation
and availability of the issued CRLs is history, D and ES come under =
dispute,
but arbitrator (a very wise human) can only say: There is a valid =
archive ATS (issued
e.g. by another TSA, still operating) applied to the bundle of data but =
truly I
am not sure about the validity of TS certificate as the evidence - =
&quot;Next
CRL&quot; - is not available to me anymore. So there is a possibility =
that TS
certificate was revoked before ATS to safeguard bundle of validation =
data was
issued.</span></font><span lang=3DEN-US><o:p></o:p></span></p>

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

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

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

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

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

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 =
face=3DTahoma><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma'>
Santosh Chokhani [mailto:chokhani@orionsec.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, =
September 05,
2007 12:15 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Carl Wallace; Vittek =
Robert;
ietf-ltans@imc.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: security =
issue in archive
timestamp chain?</span></font><span lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>In the last =
sentence, I
meant tc &gt; t2 (t2 being the time stamp =
time).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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 lang=3DEN-US style=3D'font-size:12.0pt'>

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma'>
<st1:PersonName w:st=3D"on">Santosh Chokhani</st1:PersonName> <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, September =
04, 2007
6:12 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">'<st1:PersonName
 w:st=3D"on">Carl Wallace</st1:PersonName>'</st1:PersonName>; Vittek =
Robert; <st1:PersonName
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: security =
issue in
archive timestamp chain?</span></font><span =
lang=3DEN-US><o:p></o:p></span></p>

</div>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>While what you =
say is
correct, I do not think this answers the question Robert has.&nbsp; Let =
us
consider the following scenario<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Time t1 is the =
thisUpdate
for a CRL used to verify the time stamp applied at time =
t2.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Time t3 is when =
the time
stamp is renewed.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>We know t3 &gt; =
t2 &gt;
t1.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Time tr is =
thisUpdate for
a CRL when the TSA first appear as compromised.&nbsp; tr &gt; =
t1.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Time tc is the =
actual
time of compromise. &nbsp;tr &gt; tc<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>As long as CRL =
for t1 is
produced using ERS as Carl says, the claimant can prove the legitimacy =
of the
time stamp.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>If CRL for tr is =
also
produced, the time stamp can come under dispute. &nbsp;If there is an
invalidity date associated with the TSA entry and that date is past t2, =
the
time stamp is legitimate.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Note that =
checking revocation
status of TSA at time t3 technically does not help since tr can come at =
any
time, including after t3.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Also, if one =
were to
check the revocation status of TSA at time t3, legitimate time stamps =
that were
applied prior to tc or tr may be rejected. &nbsp;It is tc that is hard =
to deal
with.&nbsp; That is why we have humans and courts and other supporting =
evidence
to ferret things out.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I have not =
purposely
included nextUpdate analysis in this since compromise of TSA may or may =
not be
detected by the nextUpdate.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>In summary, =
there will be
situations when TSA is compromised, some of the time stamps will come =
under
dispute and that dispute will need to be resolved using other =
evidence.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-US
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-US
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>This also points =
to the
value of having invalidity date in CRL for TSA entries.&nbsp; As long as =
tc is
present in tr and tc &gt; t1, the time stamp will not come under =
dispute.<o:p></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 lang=3DEN-US style=3D'font-size:12.0pt'>

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] =
<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> Tuesday, September =
04, 2007
1:45 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Vittek Robert; =
<st1:PersonName
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: security =
issue in
archive timestamp chain?</span></font><span =
lang=3DEN-US><o:p></o:p></span></p>

</div>

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

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:10.0pt'>There's
no need to safeguard the validation data for ATS1 at the time ATS2 is
applied.&nbsp; The validation data can be preserved independently of the =
data
and retrieved using SCVP/ERS.&nbsp; Amongst other benefits, this allows =
for a
grace period to be applied between the time ATS2 was generated and the =
time of
interest for validating the TSA1 credentials.&nbsp;&nbsp;&nbsp; =
</span></font><span
lang=3DEN-US><o:p></o:p></span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:10.0pt'>&gt;
-----Original Message-----</span></font><span lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
From:
owner-ietf-ltans@mail.imc.org </span></font><span lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
[<a
href=3D"mailto:owner-ietf-ltans@mail.imc.org">mailto:owner-ietf-ltans@mai=
l.imc.org</a>]
On Behalf Of Vittek Robert</span></font><span lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
Sent:
Tuesday, September 04, 2007 1:23 PM</span></font><span lang=3DEN-US> =
<br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
To: <st1:PersonName
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName></span></font><span =
lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
Subject:
security issue in archive timestamp chain?</span></font><span =
lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
We are
currently implementing a long term electronic </span></font><span =
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
signature
based on XAdES, so I went through TS 101 903, TS </span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
101 733 and
other RFCs that led me finaly to LTANS group </span></font><span =
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
because
XAdES does not address the problem of validation of </span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
TSA
certificates (&quot;Rules for acceptance of the validity of =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
the
signature within the time-stamp, involving trust </span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
decisions,
are out of the scope of the present document.&quot;).</span></font><span
lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
I am
interested in solving the following problem.</span></font><span =
lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
<a
href=3D"http://tools.ietf.org/html/rfc4998#section-5.3" =
target=3D"_blank">http://tools.ietf.org/html/rfc4998#section-5.3</a>
states that: </span></font><span lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
Each Archive
Timestamp MUST be valid relative to the time of </span></font><span =
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
the
following Archive Timestamp.</span></font><span lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
Let's assume
that we have Archive Time-Stamp 1 (ATS1) and we </span></font><span =
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
need to
renew it and safeguard the validation data for ATS1 </span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
at the same
time. But the next Archive Time-Stamp 2 (ATS2) </span></font><span =
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
can prove
existence only of the CRLs issued before time T2 </span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
(from ATS2).
ATS2 does NOT give any evidence that there was </span></font><span =
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
not another
CRL2 (issued by CA that issued TSA1 certificate) </span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
which
contained information on revocation of TSA1 =
certificate.</span></font><span
lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
I think that
arbitration on validity of ATS1 might take place </span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
long after
the archive of relevant CRLs is available and long </span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
after the
used cryptography is strong enough, so the attacker </span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
might
produce such CRL2 himself just to cast doubt upon the =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
archived
data.</span></font><span lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
In other
words: while T2 - safeguardedCRLforTSA1.thisUpdate &gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
0,
arbitrator can not be sure that there was not another CRL2 =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
that listed
TSA1 certificate.</span></font><span lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
Am I missing
something or is it a security issue?</span></font><span lang=3DEN-US> =
<br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
Mgr. Robert
Vittek</span></font><span lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
DITEC, a.s.</span></font><span
lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
Bratislava
Business Center V</span></font><span lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
Plyn=E1rensk=E1
7/C</span></font><span lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
821 09 <st1:place
w:st=3D"on"><st1:City =
w:st=3D"on">Bratislava</st1:City></st1:place></span></font><span
lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
voice: +421
2 58 222 487</span></font><span lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
fax: +421 2
58 222 777</span></font><span lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
cell: +421
908 797 827</span></font><span lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
<a
href=3D"mailto:vittek@ditec.sk">mailto:vittek@ditec.sk</a></span></font><=
span
lang=3DEN-US> <br>
</span><font size=3D2><span lang=3DEN-US style=3D'font-size:10.0pt'>&gt; =
</span></font><span
lang=3DEN-US><o:p></o:p></span></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C7F557.B043C4F5--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8BIq7Ug031840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2007 11:52:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8BIq7xv031839; Tue, 11 Sep 2007 11:52:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8BIq5BN031831 for <ietf-ltans@imc.org>; Tue, 11 Sep 2007 11:52:06 -0700 (MST) (envelope-from tglassey@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=MrPPf8SOUm0N2SffHnuynNfHuPgulObjvu62WR5QtthA5olcMlNpxKt87w10Q+M9; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=gw) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IVAqB-00082V-P5; Tue, 11 Sep 2007 14:52:03 -0400
Message-ID: <017c01c7f4a4$de983780$174f7d40@home.glassey.com>
From: "todd glassey" <tglassey@earthlink.net>
To: "Tobias Gondrom" <tgondrom@opentext.com>, "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>
Cc: <ietf-ltans@imc.org>
References: <2666EB2A846BAC4BB2D7F593301A78680187F7C4@MUCXGC2.opentext.net>
Subject: Re: LTANS: please try to keep discussions on topic with email subject and start new email threads with separate subjects for different topics
Date: Tue, 11 Sep 2007 11:50:32 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_016F_01C7F469.F4FFD9A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79b4a07c3f0ba1a3093e51e6e524c4e4ad350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

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

LTANS: please try to keep discussions on topic with email subject and =
start new email threads with separate subjects for different =
topicsTobias - WAY COOL - let me ask - do you/we want to spin the USE =
MODEL convo's off onto a new mailing list? - I think that might be a =
good idea.  The USE MODELS we can actually also bring the Audit =
Community into which will allow us to insure that the Auditors are =
totally in-synch with NEA and its use.=20

This will more than grease the skids for the roll-out of the commercial =
and Opensource versions of NEA and will pretty much guarantee their =
acceptance!=20

Also Microsoft is a primary possible sponsor here since their MGA tool =
would be something that they would want to integrate into NEA. I also =
suggest that we talk with the "Systems Change-Management" and "HIDS" =
vendors about how they play in the same sandbox too. All of which (I =
believe) WILL INSURE the industry and its sponsors pick up NEA as a =
mandatory addition.

Yeeeeee Ha! :-)

Todd=20
  ----- Original Message -----=20
  From: Tobias Gondrom=20
  To: todd glassey ; Susanne Okunick=20
  Cc: ietf-ltans@imc.org=20
  Sent: Tuesday, September 11, 2007 10:49 AM
  Subject: LTANS: please try to keep discussions on topic with email =
subject and start new email threads with separate subjects for different =
topics


  Hello all,=20

  this comment is more in my role as chair of LTANS: please try to keep =
email communication on topic with the subject of emails and start new =
email communication with reflecting new subjects on different issues. =
Otherwise they might get lost or not recognized correctly by others.

  As inspired by Todd and Susanne: I'd like to invite to discuss the =
general audit and other legal related questions about LTANS separate =
from the specific comments on dssc.=20

  In general, to allow easier following the email discussion threads: =
please try to keep answers to a draft focussed on the draft/topic.=20

  And start new email communication for discussions that are not =
specifically about the draft mentioned in the subject of the email.=20

  It's easier to work on multiple clearly separated discussion streams =
than on one large mixed one. ;-)=20

  So, I would propose to start the discussion about the legal problems =
of LTANS drafts by starting with a new specific email subject line.=20

  Thanks, Tobias

  __________________________________________
  Tobias Gondrom
  Head of Open Text Security Team
  Director, Product Security

  Open Text
  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:tobias.gondrom@opentext.com
  Internet: http://www.opentext.com/ =20

  Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, =
Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 =
4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: =
M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number =
/USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John =
Shackleton, Walter K=F6hler


------=_NextPart_000_016F_01C7F469.F4FFD9A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>LTANS: please try to keep discussions on topic with =
email subject and start new email threads with separate subjects for =
different topics</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman" size=3D2>Tobias - WAY COOL - let me =
ask -=20
do&nbsp;you/we want to spin the USE MODEL convo's off onto a new mailing =
list? -=20
I think that might be a good idea.&nbsp; The USE MODELS we can actually =
also=20
bring the Audit Community into which will allow us to insure that the =
Auditors=20
are totally in-synch with NEA and its use. </FONT></DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2>This will more than grease =
the skids=20
for the roll-out of the commercial and Opensource versions of NEA and =
will=20
pretty much guarantee their acceptance! </FONT></DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2>Also Microsoft is a primary =
possible=20
sponsor here since their MGA tool would be something that they would =
want to=20
integrate into NEA. I also suggest that we talk with the "Systems=20
Change-Management" and "HIDS" vendors about how they play in the same =
sandbox=20
too. All of which (I believe) WILL INSURE the industry and its sponsors =
pick up=20
NEA as a mandatory addition.</FONT></DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2>Yeeeeee Ha! =
:-)</FONT></DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2>Todd </FONT><FONT=20
face=3D"Times New Roman" size=3D2></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dtgondrom@opentext.com =
href=3D"mailto:tgondrom@opentext.com">Tobias=20
  Gondrom</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dtglassey@earthlink.net=20
  href=3D"mailto:tglassey@earthlink.net">todd glassey</A> ; <A=20
  title=3Dsusanne.okunick@sit.fraunhofer.de=20
  href=3D"mailto:susanne.okunick@sit.fraunhofer.de">Susanne Okunick</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Dietf-ltans@imc.org=20
  href=3D"mailto:ietf-ltans@imc.org">ietf-ltans@imc.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, September 11, =
2007 10:49=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> LTANS: please try to =
keep=20
  discussions on topic with email subject and start new email threads =
with=20
  separate subjects for different topics</DIV>
  <DIV><BR></DIV><!-- Converted from text/rtf format -->
  <P align=3Dleft><SPAN lang=3Dde><FONT face=3DArial =
size=3D2>Hello</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde><FONT face=3DArial size=3D2> =
all</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde><FONT face=3DArial size=3D2>, =
</FONT></SPAN></P>
  <P align=3Dleft><SPAN lang=3Den-gb><FONT face=3DArial =
size=3D2>t</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT =
face=3DArial=20
  size=3D2>his</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb> <FONT face=3DArial size=3D2>comment</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT =
face=3DArial=20
  size=3D2>is more in my role as chair of LTANS: please try to keep=20
  email</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Den-gb>=20
  <FONT face=3DArial size=3D2>communication</FONT></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT face=3DArial size=3D2>on =
topic with the=20
  subject of emails and start new email communication with reflecting =
new=20
  subjects on different issues.</FONT></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT face=3DArial =
size=3D2>Otherwise they might=20
  get lost or not recognized correctly by others.</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb></SPAN></P>
  <P align=3Dleft><SPAN lang=3Den-gb><FONT face=3DArial =
size=3D2>A</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT =
face=3DArial size=3D2>s=20
  inspired by Todd</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb><FONT face=3DArial size=3D2> and =
Susanne:</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT =
face=3DArial=20
  size=3D2>I</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb><FONT face=3DArial size=3D2>=92</FONT></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT face=3DArial size=3D2>d like =
to invite to=20
  discuss the general audit and other legal related questions about =
LTANS=20
  separate from th</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb><FONT face=3DArial size=3D2>e</FONT></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT face=3DArial size=3D2> =
specific comments on=20
  dssc</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb><FONT face=3DArial size=3D2>. </FONT></SPAN></P>
  <P align=3Dleft><SPAN lang=3Den-gb><FONT face=3DArial size=3D2>In=20
  general,</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb> <FONT face=3DArial size=3D2>to allow</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT =
face=3DArial=20
  size=3D2>easier following the</FONT></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT face=3DArial size=3D2>email =

  discussion</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb> <FONT face=3DArial size=3D2>threads</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT =
face=3DArial=20
  size=3D2>:</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb><FONT face=3DArial size=3D2></FONT></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT face=3DArial =
size=3D2>p</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT =
face=3DArial=20
  size=3D2>lease try to keep answers to a draft focussed on the=20
  draft/topic</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb><FONT face=3DArial size=3D2>. </FONT></SPAN></P>
  <P align=3Dleft><SPAN lang=3Den-gb><FONT face=3DArial =
size=3D2>A</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT =
face=3DArial=20
  size=3D2>nd start new email communication for =
discussions</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT =
face=3DArial=20
  size=3D2>that are not specifically about the draft =
mentioned</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT =
face=3DArial=20
  size=3D2></FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb> <FONT face=3DArial size=3D2>in the subject of the=20
  email.</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb> </SPAN></P>
  <P align=3Dleft><SPAN lang=3Den-gb><FONT face=3DArial =
size=3D2>It</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT =
face=3DArial=20
  size=3D2>=92</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb><FONT face=3DArial size=3D2>s easier to work =
on</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT =
face=3DArial=20
  size=3D2>multiple</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb> <FONT face=3DArial size=3D2>clearly separated discussion =
streams than=20
  on one large mixed on</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT face=3DArial =
size=3D2>e</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT =
face=3DArial=20
  size=3D2>.</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb><FONT face=3DArial size=3D2> ;-)</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT =
face=3DArial=20
  size=3D2></FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb> </SPAN></P>
  <P align=3Dleft><SPAN lang=3Den-gb><FONT face=3DArial =
size=3D2>So,</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT =
face=3DArial=20
  size=3D2>I would propose to</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT face=3DArial=20
  size=3D2>start</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb> <FONT face=3DArial size=3D2>the discussion =
about</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT =
face=3DArial=20
  size=3D2>the</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb> <FONT face=3DArial size=3D2>legal problems of LTANS=20
  drafts</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb> <FONT face=3DArial size=3D2>by</FONT></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT face=3DArial=20
  size=3D2>start</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb><FONT face=3DArial size=3D2>ing</FONT></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT face=3DArial =
size=3D2></FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT =
face=3DArial=20
  size=3D2>with</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb> <FONT face=3DArial size=3D2>a</FONT></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT face=3DArial=20
  size=3D2>new</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb><FONT face=3DArial size=3D2> specific</FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Den-gb> <FONT =
face=3DArial=20
  size=3D2>email subject</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Den-gb><FONT face=3DArial size=3D2>=20
  line</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb><FONT face=3DArial size=3D2>. </FONT></SPAN></P>
  <P align=3Dleft><SPAN lang=3Den-gb><FONT face=3DArial size=3D2>Thanks, =

  Tobias</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Den-gb></SPAN></P>
  <P align=3Dleft><B><SPAN lang=3Dde-de></SPAN></B><A name=3D""><B><SPAN =

  lang=3Dde-de><FONT face=3DArial=20
  =
size=3D2>__________________________________________</FONT></SPAN></B></A>=
<SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde-de><BR></SPAN><SPAN =
lang=3Dde><B></B></SPAN><SPAN=20
  lang=3Dde><B></B></SPAN><B><SPAN lang=3Dde-de><FONT face=3DArial =
color=3D#000000=20
  size=3D2>Tobias Gondrom</FONT></SPAN></B><SPAN lang=3Dde></SPAN><SPAN=20
  lang=3Dde-de><BR></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Dde-de><FONT face=3DArial color=3D#000000 size=3D2>Head of Open =
Text Security=20
  Team<BR>Director, Product Security<BR></FONT></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Dde-de><BR></SPAN><SPAN lang=3Dde><B></B></SPAN><SPAN=20
  lang=3Dde><B></B></SPAN><B><SPAN lang=3Dde-de><FONT face=3DArial =
color=3D#000000=20
  size=3D2>Open Text</FONT></SPAN></B><SPAN lang=3Dde></SPAN><SPAN=20
  lang=3Dde-de><BR></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde-de><FONT=20
  color=3D#000000>Technopark 2<BR>Werner-von-Siemens-Ring 20<BR>D-85630=20
  Grasbrunn</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN =
lang=3Dde-de><BR></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Dde-de></SPAN></P>
  <P align=3Dleft><SPAN lang=3Dde-de><FONT face=3DArial color=3D#000000 =
size=3D2>Phone:=20
  +49 (0) 89 4629-1816<BR>Mobile: +49 (0) 173 5942987<BR>Telefax: +49 =
(0) 89=20
  4629-33-1816<BR>eMail:</FONT></SPAN><SPAN lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde-de> <FONT face=3DArial size=3D2><A=20
  =
href=3D"mailto:tobias.gondrom@opentext.com">mailto:tobias.gondrom@opentex=
t.com</A><BR></FONT></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde></SPAN><SPAN lang=3Dde-de><FONT =
face=3DArial=20
  color=3D#000000 size=3D2>Internet:</FONT></SPAN><SPAN =
lang=3Dde></SPAN><SPAN=20
  lang=3Dde></SPAN><SPAN lang=3Dde-de> <FONT face=3DArial size=3D2><A=20
  href=3D"http://www.opentext.com/">http://www.opentext.com/</A>&nbsp;=20
  </FONT></SPAN></P>
  <P align=3Dleft><SPAN lang=3Dde-de><FONT face=3DArial size=3D1>Place =
of Incorporation=20
  / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, =
85630=20
  Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 =
1199 |=20
  Register Court / Registergericht: M=FCnchen, Germany | Trade Register =
Number /=20
  HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing =
Director /=20
  Gesch=E4ftsf=FChrer: John Shackleton, Walter =
K=F6hler</FONT></SPAN></P>
  <P align=3Dleft><SPAN lang=3Dde></SPAN></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_016F_01C7F469.F4FFD9A0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8BI1o66026287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2007 11:01:50 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8BI1oSY026286; Tue, 11 Sep 2007 11:01:50 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8BI1mWC026278 for <ietf-ltans@imc.org>; Tue, 11 Sep 2007 11:01:49 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l8BI1msp016663; Tue, 11 Sep 2007 20:01:48 +0200 (MEST)
Received: from MUCXGC2.opentext.net (mucxg01.opentext.net [149.235.128.135]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id l8BI1lck005666; Tue, 11 Sep 2007 14:01:47 -0400 (envelope-from tgondrom@opentext.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: draft-ietf-ltans-dssc-00 comments --constraints--
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001C_01C7F4AE.94196E90"
Date: Tue, 11 Sep 2007 20:01:46 +0200
Message-ID: <2666EB2A846BAC4BB2D7F593301A78680187F7CC@MUCXGC2.opentext.net>
In-Reply-To: <1189432770.10925.58.camel@pc-arwen>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-ltans-dssc-00 comments --constraints--
Thread-Index: Acfzsqtv4lhse/6fSR2FS2OYqWktVgA6nbrg
X-Priority: 5
Importance: low
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>
Cc: <ietf-ltans@imc.org>
X-Archived: msg.BBvD0QK:2007-09-11:mucpm02.smtp.dmz.opentext.com
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

------=_NextPart_000_001C_01C7F4AE.94196E90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Susanne,=20
answers inline.
- Tobias

> -----Original Message-----
> From: Susanne Okunick [mailto:susanne.okunick@sit.fraunhofer.de]
> Sent: Monday, September 10, 2007 4:00 PM
> To: Tobias Gondrom
> Cc: ietf-ltans@imc.org
> Subject: RE: draft-ietf-ltans-dssc-00 comments --constraints--
>=20
> Hi Tobias,
>=20
> > Hello Susanne,
> >
> > yes, I think it should be sufficient to give an example of current
> > constraints in the draft.
> We will pick up an example like this in our draft.

That's great.

> > We could also define an OID e.g. to define specific constraints:
> > OID for "larger key is always more secure than less"
> We are thinking about this issue... we don't think, that OIDs are
> satisfying solution, because of bad readability.

Hm, at the moment I can't even think of other constraints than "larger =
key
size". As an alternative to constraints, dssc could also list all =
algorithm
parameters it knows (refering to algorithmIdentifier) and leave the =
decision
about deductions from this information to the verification application.=20

> > What other constraints do you have in mind?
> I meant constraints that are currently not known and evaluated for the
> first time in the future. For such contraints we cannot give a
> definition now.

Ok, obviously. (Personal comment: Don't worry too much about the =
unknown.
;-) )
(See also comment on using constraints in future verification =
applications.)

>=20
> Susanne and Thomas
> >
> > Tobias
> >
> >
> >
> > > -----Original Message-----
> > > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-
> ltans@mail.imc.org]
> > > On Behalf Of Susanne Okunick
> > > Sent: Tuesday, September 04, 2007 12:29 PM
> > > To: ietf-ltans@imc.org
> > > Subject: draft-ietf-ltans-dssc-00 comments --constraints--
> > >
> > > Hello,
> > >
> > > for now we could define current constraints for public key =
algorithm
> and
> > > give a guidance how to process/interprete them. A guidance may be: =
a
> > > modulus (for RSA) greater than 1024 is as suitable as the modulus =
1024
> > > itself.
> > >
> > > But what about algorithms that are unknown till now? If an =
algorithm
> > > occurs as recently as in the future someone else has to define the =
new
> > > constraints, e. g. the publisher of a policy, expert committees or
> even
> > > a new RFC.
> > >
> > > Advantage for giving a definition: On the basis of the draft the
> > > operator/user is directly able to write/interpret a policy. But:
> Perhaps
> > > it suffices only to give an example for current contraints in this
> > > draft.
> > >
> > > What do you think about this problem?
> > >
> > > Best regards
> > > Susanne Okunick
> > >
> > > --
> > > ___________________________________________________________
> > >
> > > Dipl.-Math.(FH) Susanne Okunick
> > > Fraunhofer Institute for Secure Information Technology
> > > Department Transaction and Document Security
> > > Rheinstra=DFe 75, 64295 Darmstadt, Germany
> > > phone ++49 / (0)6151 869 60005, fax ++49 / (0)6151 869 322
> > > homepage: http://www.sit.fraunhofer.de
> > > ___________________________________________________________
> --
> ___________________________________________________________
>=20
> Dipl.-Math.(FH) Susanne Okunick
> Fraunhofer Institute for Secure Information Technology
> Department Transaction and Document Security
> Rheinstra=DFe 75, 64295 Darmstadt, Germany
> phone ++49 / (0)6151 869 60005, fax ++49 / (0)6151 869 322
> homepage: http://www.sit.fraunhofer.de
> ___________________________________________________________
>=20
> The electronic Signature is certified by the Fraunhofer CA:
> http://pki.fraunhofer.de/FhG-CA-Certs/FhG-CA_v2_cert.der
> ___________________________________________________________

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwzCCBhow
ggQCoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZh
cmlhMQ8wDQYDVQQHEwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5
MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20u
b3JnMB4XDTA2MTEwMzAwMjA0OFoXDTA5MDczMDAwMjA0OFowgZExCzAJBgNVBAYTAkRFMRAwDgYD
VQQIEwdCYXZhcmlhMR4wHAYDVQQKExVPcGVuIFRleHQgQ29ycG9yYXRpb24xETAPBgNVBAsTCFNl
Y3VyaXR5MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEkMCIGCSqGSIb3DQEJARYVdGdvbmRyb21A
b3BlbnRleHQuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4dYGy7tHBES4+h3Z
NS3dQi4TFm0TE84vyqzWPIwPZHpP927sRb3jh5PD7WChVPcb4KG8P4q2c+bJ+EVdaRv1Uvw57n3n
uhAbXtb7kcnFPIMfYn92GOBZpHoDCgT8DRYuQHvScH8l4W9WDtc2NHLkIldIBybxHLVdXX3QJsk3
/OFmJ9shKangwS+AT25cgGj5Ltu9iB2CFCrIKn5CCWDvObwoxEsYPj84Z3ygKUEOijNfkISuKiby
/xLIfjDPozpWdb2rb0Oi9pYJkjuzmzF5qwHZDFySeJoVKMIHi4n956m7Etahow+7hQk57+XwQyIL
l+s62FlMzsyMCZZ6MlpTs+OrymeobB44ttUn6F370N9GNXg/eV388IYA8e9Mui5F459mrM/9ub9T
fQmqoW+SdF4AvBi7BOWTHRJ/DrAWeBcw+9UeX3bWgX6cLNNv+SlNSKSiGV+syf5tqD4APvgfIY0a
PPmRLsbUy1Urwfe+BjqOLXZe6w+4WFbbKbAdltpUQCK04eA+g5tIT1ZT8zOxH+EvlJFSoV+i4btp
Y7Ni2AfJLvf9OdgwoOJBp3gXQL4o5VWzd362GHYjj94X0sqlJf8Ggcdxz4BR4/EsFRt6MQPXrfoi
wPBku/q08YwXPe1hvaW4k8MVosddaka88UY8LJrtXkZWXRERyPMH+cIJNw0CAwEAAaN7MHkwCQYD
VR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD
VR0OBBYEFDwj2KwaDOuWxUz/MiFFnt7sOYVoMB8GA1UdIwQYMBaAFH1WtHxZxnLGHnuMc6Pu+Gv9
BD5CMA0GCSqGSIb3DQEBBQUAA4ICAQCne6u3Ko8FefZSDqOq8pKEYAKbuV5NoGZqImoamelDm1Yd
6GQzacZF1aJyfHEytazk2GqmcGGB/yrqaFeQopiSTqGGnB7/8fgYMAUlv+S4NHJoohAVZC/onG0W
PDtWKnOyARntV2UxWIikKZZaYKlinvAwaBnmguqboWgbKBpYiV1+U7TgHlYdd9W25k1D+0n+E1mN
GvqEfPFxRHEiFdLxWuTtSZnvLDAihAEcTlcKOKGz5RIMHPxG4OcVz+acGKEi8WBHQRVx7KKUkLOy
SprjUpxSnEi1AbOEK2y0T/Bao3UkkxQiqKC67OUK0GPbvwat18GLmvesHArtTI8SVty63qdEmxnB
CKYLuSOJbXBe5SFPrcruMvumiA4QPdcGMyTiLqDtn97QcN+F5HfB93mKFZfqZwOqi86R6jgzFd3J
HsujJXDpZ0tIFRcDespNBcUIV+A38JxHsxF7xHw5wVQMEEsMceMjqEB3X58yAssNnXKD0E7WjIoO
SxlnODM++6xTBOIFB3N34ENNuj2Ck8196DUOei/YBEmI5oLIlXEKU/lHiDrq1D9TsjO7vhYoG+wC
vAFpGAicl25AGhaOTVeXKh+pTvHHlYva62Stww8eB/fHOW6VASWiUddE4OoxZfQiRkpn91K0rJc4
WHsP9HsBVEdA8xrfN36UXb3SXURnRzCCBqEwggSJoAMCAQICCQCamHOHv2sJlzANBgkqhkiG9w0B
AQUFADCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQ
MA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25k
cm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwHhcNMDYxMTAzMDAxMzMxWhcN
MDkwNzMwMDAxMzMxWjCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcT
Bk11bmljaDEQMA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRv
YmlhcyBHb25kcm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDRNLo77UVeV/wQ+ml3Nb5XWzkYT4Q8zo7Sl7CkuCT7UE9g
v8oFNJbzedTDn//SHkUKQJ3RpZf5VP/8gHvcFUVoiZjCMXYCsjlSJppouau3F0ED2wOle+nE9suX
lOuZVSsyuFSF89Yff8oD+wzHWi/9naeHrgKMVeqKa0Pcu1+tJ/zAoeeZHXlxHAuLQbF8XY2RGG0l
qSYXBwPuGqSVS9OKUP5kxLm+1Cd928h7PhwKJv9JP34YOWaQmxGL6KjkVnTacKpXPbhtqgtNsHC2
QWkmyyBAS8so5qAfIdOnlRi+U0hgwAKBiAF9OQh9g+xPoqLRmb81+Q18zjPDiIQ+KhwXfJeftUZp
fRy8k3thtOnkTqfKHTTaM+KaWR1bRY9DKR5u+zd/6qZ3/snVqBCNAKM0hktcSt7zQUcDo+1RsdW7
H8uJp/avtmYrmt21+Fy5+sN23sGWKNI/E3agPlTr0/jALm17ZomMP7/J4FUHsrxt5Sh6d1bWlxcR
xRIhU/8JU0BqbRSW1EKeBpzGnUJ3O65wHfyMrXi5aHG2gGXXoo2AiVTEUZylMsYxTCotEeZijfQN
zDH6oCvzePh4LF/Qo9u7T16Ovu3tRhOPQGfWltwC9gs+eJn4j7T2HJSEzVNZ3XTStzu8i/yKCcQZ
xWYy0j7ZXKZBSUmPyzuviSOvaU/K+QIDAQABo4H5MIH2MB0GA1UdDgQWBBR9VrR8WcZyxh57jHOj
7vhr/QQ+QjCBxgYDVR0jBIG+MIG7gBR9VrR8WcZyxh57jHOj7vhr/QQ+QqGBl6SBlDCBkTELMAkG
A1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQMA4GA1UEChMHR29u
ZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25kcm9tMSEwHwYJKoZI
hvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmeCCQCamHOHv2sJlzAMBgNVHRMEBTADAQH/MA0GCSqG
SIb3DQEBBQUAA4ICAQAmu3wb0JFEPQLfb9PLVEfSldtE9sLdEM4dpiJe1XqvgiI3pQI/lBzKbqcR
vg4fdP7muS3tcsqrI31L14+YzphrTLTWev86JdR23ir2oJCqrsHupuqYHI0egTRshejcTjnlBlmk
OSfxidjl+7RYjFAquFQEqHPEBb4Tcf6jXFbKzSLp/TcVG9a9x05C8wEJjDbINWxxb4EwjanKcMbh
ZNS8Vm0x4IwJhOYwkhx980WXruCoMKec9LwrPkAO/H/ZcpW2gR174oayrNXDYZIZ4nVU248jB52R
rrZxCt6/TbC8ftMzcafOLxP933RWtnf79qJbZLV9YspUEzQbuPbrb4nNuK/ZdOgJ9rNtLgZKqoa2
l5j9pNW4+yAh10s2+ZAUOlPv5wICK5gIGJo1Lj1P6cNOp3Yh03mudwM4XhQYyRCg2GbUIj0xXv/e
NkYfMGA5ljKmt9qnJ3qZKwgiFwMs2+nMfLDh6GuheAaCaWewHFMcgSoMYHNc43osufcygnKno3Eq
Fn8sn9YWM7X5vCuFK7+TGoJRVzVuwmzDqSG3l908auEKLetv03frw5v9cCB0ttExvsITo60lkuK3
Vy4CBDvE2U6BvuEr682hIUirV/X6oVORu3h44fTm1t5aibqwdWI3EpENwg9956Qpbo7uATZtQeWp
J6lsIPBAfc6YE6crOTGCBOEwggTdAgEBMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2
YXJpYTEPMA0GA1UEBxMGTXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0
eTEXMBUGA1UEAxMOVG9iaWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9t
Lm9yZwIBATAJBgUrDgMCGgUAoIICHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wNzA5MTExODAxNDRaMCMGCSqGSIb3DQEJBDEWBBShoN/Tp2sa3Mi0htfoX+GkGzbH
dzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB
BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG
TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i
aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI
hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH
EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U
b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG
SIb3DQEBAQUABIICAJ7+B17tsG11XNM9piXB+tFWUeNPrxXYlKjDm3q0Fewrj5NhioX/ioDGf8c1
fsiV6aqg8FqfSvD1Y+7GCmZnEMGZRzyqCiWS4EeMAkRrcRSOA7i4upRVk26TfSzJc1KFoR7R8etV
Im9+CUrt9lMujScgnqllaOY35GIGz8pT+8wfF2p20ImAbnHJ9j9VW8/dGEQHq2xQGED+sGbGgjCI
IwQ+Ua8pRdVS0PP2D7BwDFtDqi4WEw9tjRUXPExE3SeTLyWE63g6VipwYMVLN3niz+dkzMzsRLDG
m/eoJkAGBdoVuikB8QGpc5jpxhlcO6tfC7yjzSTMF8/vYeTSL5KZ3RT5lBdDgTKci+7NhwWafC6r
vsjwEyhwBvW3pS18ErjYgVh8c/VwrFo9BVV0cysbXiK9od6t1slVew2RxesbdH9ucZiobWHS8AxW
X3gELqYnor3CiUBkvMWN0VD7e6cVrCShTizwmSkz4BglsANVmv3jLB7YlXa9GGRc/NiluLy0rbyk
yZ2hpvDKwNMNN6ESqJl/G33kjI1NsTQaonMFQCVTsDQqKCEv0OsmwP3krFy+msdauZbNcBzA/Q9M
Jhb1H/c4xOMsiJIBiSEZjnaHfNi0RTsppUKA11XSvmDpXH6SwyvbOfMQfprSKpJu2DCuUAXOQ4pr
ynKjpqz69w2yPjg9AAAAAAAA

------=_NextPart_000_001C_01C7F4AE.94196E90--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8BHnMX0023933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2007 10:49:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8BHnML0023932; Tue, 11 Sep 2007 10:49:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8BHnKjd023921 for <ietf-ltans@imc.org>; Tue, 11 Sep 2007 10:49:21 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l8BHnG6d016306; Tue, 11 Sep 2007 19:49:16 +0200 (MEST)
Received: from MUCXGC2.opentext.net (mucxg01.opentext.net [149.235.128.135]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id l8BHnEm5028420; Tue, 11 Sep 2007 13:49:15 -0400 (envelope-from tgondrom@opentext.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F49C.1167B7AF"
Subject: LTANS: please try to keep discussions on topic with email subject and start new email threads with separate subjects for different topics
Date: Tue, 11 Sep 2007 19:49:14 +0200
Message-ID: <2666EB2A846BAC4BB2D7F593301A78680187F7C4@MUCXGC2.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: LTANS: please try to keep discussions on topic with email subject and start new email threads with separate subjects for different topics
Thread-Index: Acf0nBEZXOddRdCYSq67D6Yl0YYSpg==
X-Priority: 5
Importance: low
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "todd glassey" <tglassey@earthlink.net>, "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>
Cc: <ietf-ltans@imc.org>
X-Archived: msg.BBK9T4L:2007-09-11:mucpm02.smtp.dmz.opentext.com
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

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

Hello all,=20

this comment is more in my role as chair of LTANS: please try to keep =
email communication on topic with the subject of emails and start new =
email communication with reflecting new subjects on different issues. =
Otherwise they might get lost or not recognized correctly by others.

As inspired by Todd and Susanne: I'd like to invite to discuss the =
general audit and other legal related questions about LTANS separate =
from the specific comments on dssc.=20

In general, to allow easier following the email discussion threads: =
please try to keep answers to a draft focussed on the draft/topic.=20
And start new email communication for discussions that are not =
specifically about the draft mentioned in the subject of the email.=20
It's easier to work on multiple clearly separated discussion streams =
than on one large mixed one. ;-)=20

So, I would propose to start the discussion about the legal problems of =
LTANS drafts by starting with a new specific email subject line.=20

Thanks, Tobias

__________________________________________
Tobias Gondrom
Head of Open Text Security Team
Director, Product Security

Open Text
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:tobias.gondrom@opentext.com=20
Internet: http://www.opentext.com/ =20

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, =
Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 =
4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: =
M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number =
/USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John =
Shackleton, Walter K=F6hler


------_=_NextPart_001_01C7F49C.1167B7AF
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: please try to keep discussions on topic with email subject =
and start new email threads with separate subjects for different =
topics</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

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

<P ALIGN=3DLEFT><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">his</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">comment</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">is more in my role as chair of LTANS: please try to keep =
email</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">communication</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">on topic with the subject of emails and start new email =
communication with reflecting new subjects on different =
issues.</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">Otherwise they might get lost or not recognized correctly =
by others.</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">A</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">s =
inspired by Todd</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
and Susanne:</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">I</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">&#8217;</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">d =
like to invite to discuss the general audit and other legal related =
questions about LTANS separate from th</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Arial">e</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
specific comments on dssc</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">In =
general,</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">to allow</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">easier following the</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">email discussion</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">threads</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"></FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">p</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">lease try to keep answers to a draft focussed on the =
draft/topic</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">A</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">nd =
start new email communication for discussions</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">that are not specifically about the draft =
mentioned</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">in the subject of the email.</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">It</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">&#8217;</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial">s =
easier to work on</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">multiple</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">clearly separated discussion streams than on one large =
mixed on</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">e</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"> =
;-)</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"> =
</SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">So,</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Arial">I =
would propose to</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">start</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">the discussion about</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">legal problems of LTANS drafts</FONT></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Arial">by</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">start</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Arial">ing</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">with</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></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">new</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
specific</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Arial">email subject</FONT></SPAN><SPAN LANG=3D"de"></SPAN><SPAN =
LANG=3D"de"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Arial"> =
line</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">Thanks, Tobias</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"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>
Director, Product Security<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</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:tobias.gondrom@opentext.com">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, =
Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 =
4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: =
M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number =
/USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John =
Shackleton, Walter K=F6hler</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"de"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C7F49C.1167B7AF--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8AI4Ro4078148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 11:04:27 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8AI4Rmi078147; Mon, 10 Sep 2007 11:04:27 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8AI4Q72078141 for <ietf-ltans@imc.org>; Mon, 10 Sep 2007 11:04:26 -0700 (MST) (envelope-from tglassey@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=CD5GiCuCSCKb4UGGa+5tRCtpbyS+x70wSa7aGeTxM/vcX8lAISIqmiRRyRgL4wVA; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=gw) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IUncX-0001x5-A0; Mon, 10 Sep 2007 14:04:25 -0400
Message-ID: <013301c7f3d5$124bf560$174f7d40@home.glassey.com>
From: "todd glassey" <tglassey@earthlink.net>
To: "todd glassey" <tglassey@earthlink.net>, "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>
Cc: <ietf-ltans@imc.org>, <thomas.kunz@sit.fraunhofer.de>
References: <2666EB2A846BAC4BB2D7F593301A78680187F4D4@MUCXGC2.opentext.net> <1189432255.10925.50.camel@pc-arwen> <004c01c7f3b9$aacb0680$174f7d40@home.glassey.com> <46E56352.1020900@sit.fraunhofer.de> <00b101c7f3cd$9d9436d0$174f7d40@home.glassey.com>
Subject: Re: draft-ietf-ltans-dssc-00 comments
Date: Mon, 10 Sep 2007 11:04:44 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79eba65e5bb004193426dfb0322d8b018e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Oops typo - sorry...

----- Original Message ----- 
From: "todd glassey" <tglassey@earthlink.net>
To: "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>
Cc: <ietf-ltans@imc.org>; <thomas.kunz@sit.fraunhofer.de>
Sent: Monday, September 10, 2007 10:09 AM
Subject: Re: draft-ietf-ltans-dssc-00 comments


>
> Susanne ...
> ----- Original Message ----- 
> From: "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>
> To: "todd glassey" <tglassey@earthlink.net>
> Cc: <ietf-ltans@imc.org>; <thomas.kunz@sit.fraunhofer.de>
> Sent: Monday, September 10, 2007 8:31 AM
> Subject: Re: draft-ietf-ltans-dssc-00 comments
>
>
>>
>>
>>
>>> Susanne
>>> that doesn't make sense from either EU Laws or those of the US as well. 
>>> Sorry if this is a like a bucket of very cold water in the face, but its 
>>> time to wake up and smell the coffee... Any long term document storage 
>>> and management protocol MUST take into account any and all laws which 
>>> would constrain the operations and formulation of the proofing models it 
>>> (said protocol) produces.
>>
>> You are right.
>
> Thanks!
>
>>
>>>
>>> And within that global requirement, all evidence-standards pretty much 
>>> require a 'full chain of custody' to be proven and without that, their 
>>> content will not be admissible in the US Courts and any Court's the US 
>>> has Joint Judicial MRA's with(Mutual Recognition Agreements).  As such 
>>> the entire chain of custody and each signing and resigning needs to be 
>>> resolved and proven or there is an imperfect history for the LTANS 
>>> protected file.
>>> While this may seem like its not something that is important the 
>>> 'setting aside of this requirement' will in the US Make LTANS unusable 
>>> since the Court's wont accept it as a reliable method of storing 
>>> information. That means the ETSI TSA recommendation is PROBABLY also in 
>>> jeopardy since it clearly violates the intent and scope of those same 
>>> laws as well...
>>
>> The requirement 'full chain of custody' does not contradict LTANS/our 
>> draft.
>
> But its not the focus or only form that the LTANS system can be used in - 
> creating wiggle room for introducing problems to the trust model and its 
> portability... The idea is to create ' trusted records which are 
> ultimately portable"...
>
> The LTANS system is supposed to provide the "Trust Anchor" for those 
> records...
>
>>  E. g. ERS does not prohibit to keep policies, protocols or whatever 
>> needed for the complete evidence as required in the respective country.
>
> No but it doesnt differentiate between hierarchical trust models and 
> flattened-out ones. I.e. ones compressed so only the most recent 
> trust-event is visible externally. .. and why this is important is that if 
> the document is routinely 'flattened' out - that is 'made such that there 
> is only one operable layer of policy and history' visible, then that chain 
> of custody is eliminated even if there is some history provided internally 
> to the file. Each 'stage' and each certification(IMHO)  MUST be 
> reproduceable over the storage lifetime of the LTANS-stored Object.
>
>> Actually ERS allows the integration of such data.
>
> yes butit gets converted to payload as opposed to keeping it as operable 
> policy.
>
>> The same is true for our draft: All policies additionally may kept by an 
>> archive service and presented to court.
>
> As to multiple proofs, the key issue is whether they are presented as an 
> integrated part of the document/signature proofing blob or as an external 
> 'assurance' tool. My concern is that the Court's

are VERY clear now on what makes ESI (Electronicly Stored Information) 
admissible and there is a whole new set of qualifications for each end-use 
type of data. LTANS type data is not included in this and that also is 
something that we would want to address and perhaps get Judge Grimm himself 
to sign off on the use of LTANS Data for admissibility before the Courts per 
se... Let me think about the best way to do that.


>>
>>>
>>> The funniest part is that this WG wants to take the word (and the 
>>> consensus) of technical people who have NO EXPERIENCE in pursuing legal 
>>> recourse for IP issues or the complexity and pain of that process, which 
>>> is typical for the IETF... "We know everything" &  "Our consensus is 
>>> always right".
>>
>> If you have some constructive improvement suggestions concerning our 
>> draft, we will be grateful.
>
> Suzzane - as a positive suggestion - and one which I have already on 
> numerous occaisions suggested to that IETF for its technical solutions for 
> any protocols that are to provide evidence in a court of law or other 
> mediation type forum, that for those initiatives, in addition to their 
> being vetted by Security and Network Guru's which is what is done here in 
> the IETF, that they in addition are vetted by the Audit Community that 
> will be forced to use them as well.
>
>> Perhaps it makes sense, to put the general discussion about LTANS in an 
>> own thread.
>
> I think that might be a good idea. Especially since specific use models 
> for LTANS will need to be developed and handed to that Audit Community to 
> get them to sign off on LTAN's use.
>
>>
>> Susanne and Thomas
>>
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8AHB5Qp072401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 10:11:05 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8AHB5Ge072400; Mon, 10 Sep 2007 10:11:05 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8AHB3H1072394 for <ietf-ltans@imc.org>; Mon, 10 Sep 2007 10:11:04 -0700 (MST) (envelope-from tglassey@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=PaABejWqhuXGomeKdMGY/WmOimGORV5hBjFKET/U1v+/Y1lVbKMAPjB7tno2XjcX; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=gw) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IUmms-00078S-UC; Mon, 10 Sep 2007 13:11:03 -0400
Message-ID: <00b101c7f3cd$9d9436d0$174f7d40@home.glassey.com>
From: "todd glassey" <tglassey@earthlink.net>
To: "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>
Cc: <ietf-ltans@imc.org>, <thomas.kunz@sit.fraunhofer.de>
References: <2666EB2A846BAC4BB2D7F593301A78680187F4D4@MUCXGC2.opentext.net> <1189432255.10925.50.camel@pc-arwen> <004c01c7f3b9$aacb0680$174f7d40@home.glassey.com> <46E56352.1020900@sit.fraunhofer.de>
Subject: Re: draft-ietf-ltans-dssc-00 comments
Date: Mon, 10 Sep 2007 10:09:05 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7914106beea200faaa4d0689d181af2d25350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Susanne ...
----- Original Message ----- 
From: "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>
To: "todd glassey" <tglassey@earthlink.net>
Cc: <ietf-ltans@imc.org>; <thomas.kunz@sit.fraunhofer.de>
Sent: Monday, September 10, 2007 8:31 AM
Subject: Re: draft-ietf-ltans-dssc-00 comments


>
>
>
>> Susanne
>> that doesn't make sense from either EU Laws or those of the US as well. 
>> Sorry if this is a like a bucket of very cold water in the face, but its 
>> time to wake up and smell the coffee... Any long term document storage 
>> and management protocol MUST take into account any and all laws which 
>> would constrain the operations and formulation of the proofing models it 
>> (said protocol) produces.
>
> You are right.

Thanks!

>
>>
>> And within that global requirement, all evidence-standards pretty much 
>> require a 'full chain of custody' to be proven and without that, their 
>> content will not be admissible in the US Courts and any Court's the US 
>> has Joint Judicial MRA's with(Mutual Recognition Agreements).  As such 
>> the entire chain of custody and each signing and resigning needs to be 
>> resolved and proven or there is an imperfect history for the LTANS 
>> protected file.
>> While this may seem like its not something that is important the 'setting 
>> aside of this requirement' will in the US Make LTANS unusable since the 
>> Court's wont accept it as a reliable method of storing information. That 
>> means the ETSI TSA recommendation is PROBABLY also in jeopardy since it 
>> clearly violates the intent and scope of those same laws as well...
>
> The requirement 'full chain of custody' does not contradict LTANS/our 
> draft.

But its not the focus or only form that the LTANS system can be used in - 
creating wiggle room for introducing problems to the trust model and its 
portability... The idea is to create ' trusted records which are ultimately 
portable"...

The LTANS system is supposed to provide the "Trust Anchor" for those 
records...

>  E. g. ERS does not prohibit to keep policies, protocols or whatever 
> needed for the complete evidence as required in the respective country.

No but it doesnt differentiate between hierarchical trust models and 
flattened-out ones. I.e. ones compressed so only the most recent trust-event 
is visible externally. .. and why this is important is that if the document 
is routinely 'flattened' out - that is 'made such that there is only one 
operable layer of policy and history' visible, then that chain of custody is 
eliminated even if there is some history provided internally to the file. 
Each 'stage' and each certification(IMHO)  MUST be reproduceable over the 
storage lifetime of the LTANS-stored Object.

> Actually ERS allows the integration of such data.

yes butit gets converted to payload as opposed to keeping it as operable 
policy.

> The same is true for our draft: All policies additionally may kept by an 
> archive service and presented to court.

As to multiple proofs, the key issue is whether they are presented as an 
integrated part of the document/signature proofing blob or as an external 
'assurance' tool. My concern is that the Court's
>
>>
>> The funniest part is that this WG wants to take the word (and the 
>> consensus) of technical people who have NO EXPERIENCE in pursuing legal 
>> recourse for IP issues or the complexity and pain of that process, which 
>> is typical for the IETF... "We know everything" &  "Our consensus is 
>> always right".
>
> If you have some constructive improvement suggestions concerning our 
> draft, we will be grateful.

Suzzane - as a positive suggestion - and one which I have already on 
numerous occaisions suggested to that IETF for its technical solutions for 
any protocols that are to provide evidence in a court of law or other 
mediation type forum, that for those initiatives, in addition to their being 
vetted by Security and Network Guru's which is what is done here in the 
IETF, that they in addition are vetted by the Audit Community that will be 
forced to use them as well.

> Perhaps it makes sense, to put the general discussion about LTANS in an 
> own thread.

I think that might be a good idea. Especially since specific use models for 
LTANS will need to be developed and handed to that Audit Community to get 
them to sign off on LTAN's use.

>
> Susanne and Thomas
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8AFUTYO059370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 08:30:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8AFUTTi059369; Mon, 10 Sep 2007 08:30:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8AFURan059363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-ltans@imc.org>; Mon, 10 Sep 2007 08:30:28 -0700 (MST) (envelope-from susanne.okunick@sit.fraunhofer.de)
Received: from [141.12.89.207] (sitp1_182.sit.fraunhofer.de [141.12.68.182]) (authenticated bits=0) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id l8AFUPfU028063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 17:30:25 +0200
Message-ID: <46E56352.1020900@sit.fraunhofer.de>
Date: Mon, 10 Sep 2007 17:31:30 +0200
From: Susanne Okunick <susanne.okunick@sit.fraunhofer.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
X-Accept-Language: de
MIME-Version: 1.0
To: todd glassey <tglassey@earthlink.net>
CC: ietf-ltans@imc.org, thomas.kunz@sit.fraunhofer.de
Subject: Re: draft-ietf-ltans-dssc-00 comments
References: <2666EB2A846BAC4BB2D7F593301A78680187F4D4@MUCXGC2.opentext.net> <1189432255.10925.50.camel@pc-arwen> <004c01c7f3b9$aacb0680$174f7d40@home.glassey.com>
In-Reply-To: <004c01c7f3b9$aacb0680$174f7d40@home.glassey.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

 

> Susanne
> that doesn't make sense from either EU Laws or those of the US as 
> well. Sorry if this is a like a bucket of very cold water in the face, 
> but its time to wake up and smell the coffee... Any long term document 
> storage and management protocol MUST take into account any and all 
> laws which would constrain the operations and formulation of the 
> proofing models it (said protocol) produces.

You are right.

>
> And within that global requirement, all evidence-standards pretty much 
> require a 'full chain of custody' to be proven and without that, their 
> content will not be admissible in the US Courts and any Court's the US 
> has Joint Judicial MRA's with(Mutual Recognition Agreements).  As such 
> the entire chain of custody and each signing and resigning needs to be 
> resolved and proven or there is an imperfect history for the LTANS 
> protected file.
> While this may seem like its not something that is important the 
> 'setting aside of this requirement' will in the US Make LTANS unusable 
> since the Court's wont accept it as a reliable method of storing 
> information. That means the ETSI TSA recommendation is PROBABLY also 
> in jeopardy since it clearly violates the intent and scope of those 
> same laws as well...

The requirement 'full chain of custody' does not contradict LTANS/our 
draft. E. g. ERS does not prohibit to keep policies, protocols or 
whatever needed for the complete evidence as required in the respective 
country. Actually ERS allows the integration of such data. The same is 
true for our draft: All policies additionally may kept by an archive 
service and presented to court.

>
> The funniest part is that this WG wants to take the word (and the 
> consensus) of technical people who have NO EXPERIENCE in pursuing 
> legal recourse for IP issues or the complexity and pain of that 
> process, which is typical for the IETF... "We know everything" &  "Our 
> consensus is always right".

If you have some constructive improvement suggestions concerning our 
draft, we will be grateful. Perhaps it makes sense, to put the general 
discussion about LTANS in an own thread.

Susanne and Thomas



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8AEmK7x056296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 07:48:20 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8AEmKYt056295; Mon, 10 Sep 2007 07:48:20 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8AEmJCE056289 for <ietf-ltans@imc.org>; Mon, 10 Sep 2007 07:48:19 -0700 (MST) (envelope-from tglassey@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=FV20+yUZntF6eYoye+mrAWgbTQta+c2gQBKF+lUgdWeKJJQInAnKKooFnTHiGfiv; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=gw) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IUkYh-0002sv-Cm; Mon, 10 Sep 2007 10:48:15 -0400
Message-ID: <004c01c7f3b9$aacb0680$174f7d40@home.glassey.com>
From: "todd glassey" <tglassey@earthlink.net>
To: "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>, "Tobias Gondrom" <tgondrom@opentext.com>
Cc: <ietf-ltans@imc.org>
References: <2666EB2A846BAC4BB2D7F593301A78680187F4D4@MUCXGC2.opentext.net> <1189432255.10925.50.camel@pc-arwen>
Subject: Re: draft-ietf-ltans-dssc-00 comments
Date: Mon, 10 Sep 2007 07:48:19 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79f0497c175bd9ab4a7ce5710782b09ee1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Susanne
that doesn't make sense from either EU Laws or those of the US as well. 
Sorry if this is a like a bucket of very cold water in the face, but its 
time to wake up and smell the coffee... Any long term document storage and 
management protocol MUST take into account any and all laws which would 
constrain the operations and formulation of the proofing models it (said 
protocol) produces.

And within that global requirement, all evidence-standards pretty much 
require a 'full chain of custody' to be proven and without that, their 
content will not be admissible in the US Courts and any Court's the US has 
Joint Judicial MRA's with(Mutual Recognition Agreements).  As such the 
entire chain of custody and each signing and resigning needs to be resolved 
and proven or there is an imperfect history for the LTANS protected file.

While this may seem like its not something that is important the 'setting 
aside of this requirement' will in the US Make LTANS unusable since the 
Court's wont accept it as a reliable method of storing information. That 
means the ETSI TSA recommendation is PROBABLY also in jeopardy since it 
clearly violates the intent and scope of those same laws as well...

The funniest part is that this WG wants to take the word (and the consensus) 
of technical people who have NO EXPERIENCE in pursuing legal recourse for IP 
issues or the complexity and pain of that process, which is typical for the 
IETF... "We know everything" &  "Our consensus is always right".

The reality here is that without specific and very particular controls and 
legal processes LTANS isn't going to get used anywhere because the Audit 
Community cannot take the chance that the client's who use LTANS's wont be 
able to prove anything with it.



Todd Glassey

----- Original Message ----- 
From: "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>
To: "Tobias Gondrom" <tgondrom@opentext.com>
Cc: <ietf-ltans@imc.org>
Sent: Monday, September 10, 2007 6:50 AM
Subject: RE: draft-ietf-ltans-dssc-00 comments


Hello Tobias,

we agree with all of your remarks. Thanx.

We also don't see any complications regarding the legislation (at least
German law requires the renewal of signatures).

We are going to adapt our draft in this way, that a policy should also
contain expired algorithms. So for verfication only the current policy
is needed.

Best regards
Thomas and Susanne

> Hi Thomas, Susanne, Todd, Carl and all,
>
> Maybe a few thoughts about the discussed items:
>
> Starting with the simple things:
> I agree with Carls assessment that for the verification the critical
> information is the policy stating which algorithms had been valid from
> date a to date b. Period.
> I understand your idea of providing older policies to support the fact
> that an archive service did operate correctly, but this is not the main
> reason for the policy in the verification process.
> The main use for the policy is that any verification party can use it
> and check an ERS or other signatures whether any of the used algorithms
> had been broken before they were renewed. (this is a precise
> mathematical test, and does not automatically imply careless handling of
> the archive system).
> For the verification party only this hard facts count: Has the signature
> been renewed in time or not, defined by the current policy.
> (the old policies may indicate a wrong-doing of the archive system or
> justify its actions but they must not influence the evaluation of
> "valid"/"not-valid".
>
> (comment: and if it happens that the policy issuing authority
> retrospectively shortens the timespan of an algorithm, this will be for
> a reason which should not be ignored.)
>
>
> Concerning the issuing of the policy: I think that to prove its
> authenticity and integrity it should be sufficient to sign it (via CMS)
> by the authority (e.g. NIST, German Bundesnetzagentur, ...)
>
>
> I can not see any real problematic legal inter-country related
> implications.
> A signature must be valid in the country where it is presented to the
> court.
> Which includes the renewal done with ERS must be so as well.
> In court the judge will call upon the guidance of the countries security
> authority (in case of US this would be NIST) to decide whether
> algorithms are secure or have been broken and when. If these authorities
> publish this statement in the form of a signed policy, this would be a
> clear and reliable statement. (today they publish this in unsigned pdf
> and on paper)
>
> Dito in other countries.
> (obviously as these judgements of algorithms can vary between countries,
> an archiving service would have the duty to watch carefully for
> algorithm lifetime announcements the local national bodies corresponding
> to its stored documents make)
>
> Best regards, Tobias
>

-- 
___________________________________________________________

Dipl.-Math.(FH) Susanne Okunick
Fraunhofer Institute for Secure Information Technology
Department Transaction and Document Security
RheinstraĂźe 75, 64295 Darmstadt, Germany
phone ++49 / (0)6151 869 60005, fax ++49 / (0)6151 869 322
homepage: http://www.sit.fraunhofer.de
___________________________________________________________

The electronic Signature is certified by the Fraunhofer CA:
http://pki.fraunhofer.de/FhG-CA-Certs/FhG-CA_v2_cert.der
___________________________________________________________



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8ADwNNR050953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 06:58:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8ADwNIi050952; Mon, 10 Sep 2007 06:58:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8ADwLlP050941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-ltans@imc.org>; Mon, 10 Sep 2007 06:58:22 -0700 (MST) (envelope-from susanne.okunick@sit.fraunhofer.de)
Received: from [141.12.89.207] (sitp1_182.sit.fraunhofer.de [141.12.68.182]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id l8ADwKGT021830; Mon, 10 Sep 2007 15:58:20 +0200
Subject: RE: draft-ietf-ltans-dssc-00 comments --constraints--
From: Susanne Okunick <susanne.okunick@sit.fraunhofer.de>
To: Tobias Gondrom <tgondrom@opentext.com>
Cc: ietf-ltans@imc.org
In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78680187F4D6@MUCXGC2.opentext.net>
References: <2666EB2A846BAC4BB2D7F593301A78680187F4D6@MUCXGC2.opentext.net>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-f2wx5fKJFJq/b2sPpD1m"
Date: Mon, 10 Sep 2007 15:59:30 +0200
Message-Id: <1189432770.10925.58.camel@pc-arwen>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1 
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

--=-f2wx5fKJFJq/b2sPpD1m
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Tobias,

> Hello Susanne,=20
>=20
> yes, I think it should be sufficient to give an example of current
> constraints in the draft.=20
We will pick up an example like this in our draft.

> We could also define an OID e.g. to define specific constraints:=20
> OID for "larger key is always more secure than less"
We are thinking about this issue... we don't think, that OIDs are
satisfying solution, because of bad readability.=20

> What other constraints do you have in mind?
I meant constraints that are currently not known and evaluated for the
first time in the future. For such contraints we cannot give a
definition now.

Susanne and Thomas
>=20
> Tobias
>=20
>=20
>=20
> > -----Original Message-----
> > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.o=
rg]
> > On Behalf Of Susanne Okunick
> > Sent: Tuesday, September 04, 2007 12:29 PM
> > To: ietf-ltans@imc.org
> > Subject: draft-ietf-ltans-dssc-00 comments --constraints--
> >=20
> > Hello,
> >=20
> > for now we could define current constraints for public key algorithm an=
d
> > give a guidance how to process/interprete them. A guidance may be: a
> > modulus (for RSA) greater than 1024 is as suitable as the modulus 1024
> > itself.
> >=20
> > But what about algorithms that are unknown till now? If an algorithm
> > occurs as recently as in the future someone else has to define the new
> > constraints, e. g. the publisher of a policy, expert committees or even
> > a new RFC.
> >=20
> > Advantage for giving a definition: On the basis of the draft the
> > operator/user is directly able to write/interpret a policy. But: Perhap=
s
> > it suffices only to give an example for current contraints in this
> > draft.
> >=20
> > What do you think about this problem?
> >=20
> > Best regards
> > Susanne Okunick
> >=20
> > --
> > ___________________________________________________________
> >=20
> > Dipl.-Math.(FH) Susanne Okunick
> > Fraunhofer Institute for Secure Information Technology
> > Department Transaction and Document Security
> > Rheinstra=C3=9Fe 75, 64295 Darmstadt, Germany
> > phone ++49 / (0)6151 869 60005, fax ++49 / (0)6151 869 322
> > homepage: http://www.sit.fraunhofer.de
> > ___________________________________________________________
--=20
___________________________________________________________

Dipl.-Math.(FH) Susanne Okunick
Fraunhofer Institute for Secure Information Technology
Department Transaction and Document Security
Rheinstra=C3=9Fe 75, 64295 Darmstadt, Germany
phone ++49 / (0)6151 869 60005, fax ++49 / (0)6151 869 322
homepage: http://www.sit.fraunhofer.de
___________________________________________________________

The electronic Signature is certified by the Fraunhofer CA:
http://pki.fraunhofer.de/FhG-CA-Certs/FhG-CA_v2_cert.der=20
___________________________________________________________

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFuzCCBbcw
ggSfoAMCAQICAg8yMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1
bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyMB4XDTA1
MTAwNjE0MDQwMVoXDTA5MTIzMTIzMDAwMFowWzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu
aG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRgwFgYDVQQDEw9TdXNhbm5lIE9r
dW5pY2swggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCixKdSLwHlBFCBau215sA8INJp
6zEcpvmq4p3oUk3h3IOY2Ph4+8XJuCUzO2f6/vwfL4AVMUcV4h2YqgMDJ2y8rahOtU4WZW8k10Cd
QE7VbPFF6U+unvGuizJZFZb3k0Kbs2FUzJ2hP5sjlb0tnW15NPFivRs764hwTzzRjiPYTKAc0MOv
2hR/8mgp6Oso6cQE2GA/sgkhzRXzY00FjFwvbKcvMx+3Ww1sd66GN6Y5A5YXjIahntdPBFxWq/5O
sf9rMUodghMQUXJNkyw5Pt+sNnEYiFrQZF2PtqPq57EGeQ7Yh50ZNEzQZUOWoHgtat7m0nD9a7f4
aXEMlrG1VZrBAgMBAAGjggKPMIICizCBoAYJYIZIAYb4QgENBIGSFoGPU29mdHdhcmUtWmVydGlm
aWthdCBkZXIgWmVydGlmaXppZXJ1bmdzaW5zdGFueiAoQ0EpIGRlciBGcmF1bmhvZmVyLUdlc2Vs
bHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVsemVydGlmaWthdCB2aWEgaHR0cHM6Ly9wa2ku
ZnJhdW5ob2Zlci5kZS8wTQYIKwYBBQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZy
YXVuaG9mZXIuZGUvRmhHLUNBX3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0
dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwDAYD
VR0TAQH/BAIwADBKBgNVHRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIu
ZGWGGWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wLAYDVR0RBCUwI4Ehc3VzYW5uZS5va3VuaWNr
QHNpdC5mcmF1bmhvZmVyLmRlMEwGA1UdIARFMEMwQQYLKwYBBAGGClACAQEwMjAwBggrBgEFBQcC
ARYkaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlL3BvbGljeS5odG1sMCcGA1UdJQQgMB4GCCsGAQUF
BwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgbAMB0GA1UdDgQWBBREDzmsUZxs
4FvzGJN5Y4eWpmaoNDAfBgNVHSMEGDAWgBQAw/zvY8JWKC9RC3VW/3sF6RzJ8TANBgkqhkiG9w0B
AQUFAAOCAQEAXPZIkjp87kqTdv/8oj2kyTXD4eix2OtEpXiKbgrfb0ErWwe60cymp5hrgdScw/Y8
TXvk+nYwt0OvWCnOG+QhBLyJdgvDiS5DiXjQPVtb/rCPTsJPuXXVCyQQfTdQ1smSmvrGQROTMPzG
DYu3iWtQnPrSx/vtdIZcAng29T81nkEr7FCVn3FxDA2ZzbPBR3g5L320t6hSKYxFssVBvZKOVmQm
hFePgIyXz7n6Yto39/48knrLF4uGwSzKvdPOeW3CLhdn5BAAuP+2vD9L5UI+fXEOAfYJTckUV4kq
bM4tyosNR6QrE5tK+ygV+Hk5CfQ4EIhixR+LBX+ry73zSpKzozGCAdswggHXAgEBMFUwTzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxs
c2NoYWZ0IFJvb3QtQ0EgdjICAg8yMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA5MTAxMzU5MzBaMCMGCSqGSIb3DQEJBDEWBBTlKmUquAlg
8qREhdd1ff1IAF9fXDANBgkqhkiG9w0BAQEFAASCAQBe6f+ZaeOaspP68s7scmhc8oYs85EanJQ9
3IUiaoR0/oosyfcnrqHJvEVZucl1Fo6XtZl7oyDMRxzMKxiVJIFSjHtWG2QOTsSORU4uba+K0wNQ
fsCJibHARMT8dzXBiD599K3C5YrGKP3e82aGhWt/ZNZZ0PTFNBk/qDewEEK6j1U2pkrOWUG7H7bi
G1kAL40KjY1fmi18M4sriBlYEPwmlQN09Wosk9sAv9npmEfCfpoSZKgQ01KeF0i0OQAG0DWVfRXs
VAcCgchpH0BtY12AcAH7Wj2yj4uma51zdF2yD3EE12nFsMQ6tQ9ly9a23XaFXfalGuttI9+YHiav
igGtAAAAAAAA


--=-f2wx5fKJFJq/b2sPpD1m--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8ADnqXc049912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 06:49:52 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8ADnqPm049911; Mon, 10 Sep 2007 06:49:52 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8ADnlsd049895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-ltans@imc.org>; Mon, 10 Sep 2007 06:49:50 -0700 (MST) (envelope-from susanne.okunick@sit.fraunhofer.de)
Received: from [141.12.89.207] (sitp1_182.sit.fraunhofer.de [141.12.68.182]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id l8ADnj2x021190; Mon, 10 Sep 2007 15:49:45 +0200
Subject: RE: draft-ietf-ltans-dssc-00 comments
From: Susanne Okunick <susanne.okunick@sit.fraunhofer.de>
To: Tobias Gondrom <tgondrom@opentext.com>
Cc: ietf-ltans@imc.org
In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78680187F4D4@MUCXGC2.opentext.net>
References: <2666EB2A846BAC4BB2D7F593301A78680187F4D4@MUCXGC2.opentext.net>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-HSLDYYkA125hVGJt65ZW"
Date: Mon, 10 Sep 2007 15:50:55 +0200
Message-Id: <1189432255.10925.50.camel@pc-arwen>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1 
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

--=-HSLDYYkA125hVGJt65ZW
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Tobias,

we agree with all of your remarks. Thanx.=20

We also don't see any complications regarding the legislation (at least
German law requires the renewal of signatures).=20

We are going to adapt our draft in this way, that a policy should also
contain expired algorithms. So for verfication only the current policy
is needed.=20

Best regards=20
Thomas and Susanne

> Hi Thomas, Susanne, Todd, Carl and all,=20
>=20
> Maybe a few thoughts about the discussed items:=20
>=20
> Starting with the simple things:=20
> I agree with Carls assessment that for the verification the critical
> information is the policy stating which algorithms had been valid from
> date a to date b. Period.=20
> I understand your idea of providing older policies to support the fact
> that an archive service did operate correctly, but this is not the main
> reason for the policy in the verification process.=20
> The main use for the policy is that any verification party can use it
> and check an ERS or other signatures whether any of the used algorithms
> had been broken before they were renewed. (this is a precise
> mathematical test, and does not automatically imply careless handling of
> the archive system).=20
> For the verification party only this hard facts count: Has the signature
> been renewed in time or not, defined by the current policy.=20
> (the old policies may indicate a wrong-doing of the archive system or
> justify its actions but they must not influence the evaluation of
> "valid"/"not-valid".=20
>=20
> (comment: and if it happens that the policy issuing authority
> retrospectively shortens the timespan of an algorithm, this will be for
> a reason which should not be ignored.)
>=20
>=20
> Concerning the issuing of the policy: I think that to prove its
> authenticity and integrity it should be sufficient to sign it (via CMS)
> by the authority (e.g. NIST, German Bundesnetzagentur, ...)
>=20
>=20
> I can not see any real problematic legal inter-country related
> implications.=20
> A signature must be valid in the country where it is presented to the
> court.=20
> Which includes the renewal done with ERS must be so as well.=20
> In court the judge will call upon the guidance of the countries security
> authority (in case of US this would be NIST) to decide whether
> algorithms are secure or have been broken and when. If these authorities
> publish this statement in the form of a signed policy, this would be a
> clear and reliable statement. (today they publish this in unsigned pdf
> and on paper)
>=20
> Dito in other countries.=20
> (obviously as these judgements of algorithms can vary between countries,
> an archiving service would have the duty to watch carefully for
> algorithm lifetime announcements the local national bodies corresponding
> to its stored documents make)
>=20
> Best regards, Tobias
>=20

--=20
___________________________________________________________

Dipl.-Math.(FH) Susanne Okunick
Fraunhofer Institute for Secure Information Technology
Department Transaction and Document Security
Rheinstra=C3=9Fe 75, 64295 Darmstadt, Germany
phone ++49 / (0)6151 869 60005, fax ++49 / (0)6151 869 322
homepage: http://www.sit.fraunhofer.de
___________________________________________________________

The electronic Signature is certified by the Fraunhofer CA:
http://pki.fraunhofer.de/FhG-CA-Certs/FhG-CA_v2_cert.der=20
___________________________________________________________

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFuzCCBbcw
ggSfoAMCAQICAg8yMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1
bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyMB4XDTA1
MTAwNjE0MDQwMVoXDTA5MTIzMTIzMDAwMFowWzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu
aG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRgwFgYDVQQDEw9TdXNhbm5lIE9r
dW5pY2swggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCixKdSLwHlBFCBau215sA8INJp
6zEcpvmq4p3oUk3h3IOY2Ph4+8XJuCUzO2f6/vwfL4AVMUcV4h2YqgMDJ2y8rahOtU4WZW8k10Cd
QE7VbPFF6U+unvGuizJZFZb3k0Kbs2FUzJ2hP5sjlb0tnW15NPFivRs764hwTzzRjiPYTKAc0MOv
2hR/8mgp6Oso6cQE2GA/sgkhzRXzY00FjFwvbKcvMx+3Ww1sd66GN6Y5A5YXjIahntdPBFxWq/5O
sf9rMUodghMQUXJNkyw5Pt+sNnEYiFrQZF2PtqPq57EGeQ7Yh50ZNEzQZUOWoHgtat7m0nD9a7f4
aXEMlrG1VZrBAgMBAAGjggKPMIICizCBoAYJYIZIAYb4QgENBIGSFoGPU29mdHdhcmUtWmVydGlm
aWthdCBkZXIgWmVydGlmaXppZXJ1bmdzaW5zdGFueiAoQ0EpIGRlciBGcmF1bmhvZmVyLUdlc2Vs
bHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVsemVydGlmaWthdCB2aWEgaHR0cHM6Ly9wa2ku
ZnJhdW5ob2Zlci5kZS8wTQYIKwYBBQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZy
YXVuaG9mZXIuZGUvRmhHLUNBX3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0
dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwDAYD
VR0TAQH/BAIwADBKBgNVHRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIu
ZGWGGWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wLAYDVR0RBCUwI4Ehc3VzYW5uZS5va3VuaWNr
QHNpdC5mcmF1bmhvZmVyLmRlMEwGA1UdIARFMEMwQQYLKwYBBAGGClACAQEwMjAwBggrBgEFBQcC
ARYkaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlL3BvbGljeS5odG1sMCcGA1UdJQQgMB4GCCsGAQUF
BwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgbAMB0GA1UdDgQWBBREDzmsUZxs
4FvzGJN5Y4eWpmaoNDAfBgNVHSMEGDAWgBQAw/zvY8JWKC9RC3VW/3sF6RzJ8TANBgkqhkiG9w0B
AQUFAAOCAQEAXPZIkjp87kqTdv/8oj2kyTXD4eix2OtEpXiKbgrfb0ErWwe60cymp5hrgdScw/Y8
TXvk+nYwt0OvWCnOG+QhBLyJdgvDiS5DiXjQPVtb/rCPTsJPuXXVCyQQfTdQ1smSmvrGQROTMPzG
DYu3iWtQnPrSx/vtdIZcAng29T81nkEr7FCVn3FxDA2ZzbPBR3g5L320t6hSKYxFssVBvZKOVmQm
hFePgIyXz7n6Yto39/48knrLF4uGwSzKvdPOeW3CLhdn5BAAuP+2vD9L5UI+fXEOAfYJTckUV4kq
bM4tyosNR6QrE5tK+ygV+Hk5CfQ4EIhixR+LBX+ry73zSpKzozGCAdswggHXAgEBMFUwTzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxs
c2NoYWZ0IFJvb3QtQ0EgdjICAg8yMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA5MTAxMzUwNTVaMCMGCSqGSIb3DQEJBDEWBBRiFsAWnw6E
gNZ/pQ/tFQOLc62HhzANBgkqhkiG9w0BAQEFAASCAQBYJ9NeMVN3WF/AnUxdKSRlbxTP+3zeH/sm
yJtRkimXC7T4ZpbZ2jWqZIyv47evWpf5+Yof0R7Al2afmrUofu21oxlQ3kC1iK3m52q+ycd6ZoJF
JmzMEh9JmmUrukovuhm+TCI4c06mB927n8Xhp0Q51KwuEKkNIbYZtvMRBH+fd9PZNPorkKBQfIgk
D/asl3xN0bUABGfdtZPoj7EJy6L4R69SUT9XpLmjAVkexT2ao0oPmSeK1EqrS8YX+q66Ehn1LgBg
yFQGRz10ffx2BuhsNYREOJZ7xnzXVHeCVbw1c8eTEoUfMIZLGfTupze4i245l5iC9zlOV69vRn+w
0ETmAAAAAAAA


--=-HSLDYYkA125hVGJt65ZW--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8A9IO4a017857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 02:18:24 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8A9IO69017856; Mon, 10 Sep 2007 02:18:24 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8A9IMS8017848 for <ietf-ltans@imc.org>; Mon, 10 Sep 2007 02:18:23 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr)
Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 3664A2E; Mon, 10 Sep 2007 11:18:22 +0200 (CEST)
Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07001-01; Mon, 10 Sep 2007 11:18:17 +0200 (CEST)
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 47D892C; Mon, 10 Sep 2007 11:17:57 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007091011175309:35291 ; Mon, 10 Sep 2007 11:17:53 +0200 
Message-ID: <46E50B10.4020507@edelweb.fr>
Date: Mon, 10 Sep 2007 11:14:56 +0200
From: Peter Sylvester <Peter.Sylvester@edelweb.fr>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Thomas Kunz <thomas.kunz@sit.fraunhofer.de>
Cc: ietf-ltans@imc.org
Subject: Re: draft-ietf-ltans-dssc-00 comments
References: <886F5D4C78AFB14D87261206BFB9612E1D31D982@scygmxs1.cygnacom.com> <46DC965F.3040506@sit.fraunhofer.de> <46DD9104.9070401@edelweb.fr> <46DFC57A.9000509@sit.fraunhofer.de>
In-Reply-To: <46DFC57A.9000509@sit.fraunhofer.de>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 09/10/2007 11:17:53 AM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 09/10/2007 11:18:16 AM, Serialize complete at 09/10/2007 11:18:16 AM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000006090002000309050200"
X-Virus-Scanned: by amavisd-new at on-x.com
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a cryptographically signed message in MIME format.

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


>>
> I'm not sure whether I understand your suggestion.
>
> In your example above, you suggest to have simply a list of all 
> currently valid key lengths?
Not in the policy but in the information about what is actually 
implemented by
an algorithm. I was not quite clear here.

> But where do you have the validity periods of the particular values 
> (key  lengths)?
As part of the policy, you make constraints about values, e.g. parameter 
1 may only have this
or that etc. You can CHECK such statements without knowing the actual 
semantics.

> A second problem I see is, that some algorithms are defined by more 
> than one parameter (e.g. DSA: 'p' and 'q'). So in the XML encoding, 
> you have to distinguish the different parameters (e.g. via its name).
There is the point. You do not have to distinguish any semantics of what 
p q, or keys or else would mean.
I think a verifying entity can be made of two compoents: A very generic 
one, which verifies the
conformity of ALL alogorithms and, for each algorithm implementation, a 
specific module which,
depending on the algorithm implementation can indicate how some values 
are filled. The verification
module does not need to know anything about the actual semantics of a 
particular parameter.

Compare this with SNMP: If you have some "box" with a mib, onlmy the box 
knows the semantics
of the values, not the SNMP client and network supervision tools. They 
just can set value and display
textuals labels defined by a mib.

If one wants to define policies about certain values, then the network 
tool need to know the specific
mibs, there is no way to make a generic policy for each kind of mib. But 
in our case, the potential
number of algorithms is not extremely high, and in any way, the policy 
will say not say more than
constraints of a few values.
>
>
>> in a policy one would only specify value constraints parameters for 
>> an actual algorithms,
>> a kind of pattern which can always be checked, example
>>   first parameter must be greater than  1023, second less than 8192 
>> or whatever.
> >
> Do you mean to encode this pattern in XML? And for example such a 
> pattern would say: 'If a value of 1024 is valid, every value greater 
> than 1024 is also valid'?
>
> In principle I agree with you. We are also discussing the problem 
> which arises if new algorithms are added (see Susanne's mail which 
> also addresses this topic).
Yes, the proble is how one assumes that an implementation would work. 
Who will check the policy?
Is it part of the algorithm implementation, or part of a generic module 
that asks some parts
of the algorithm implementation to give 'its parameter 1 and 2'?
>
> Thomas
>


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwOTEwMDkxNDU2WjAjBgkqhkiG9w0B
CQQxFgQUvoTnmmexPjsfAQjtsKRFkG0lQ/8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAG+Prz+P3Nhyyx11s
0YAeIHzwu5n15Lz6YJgT4l4/nDP/EfZmih25Rz9jgLPn46nLclVs6Ii7KFIU3m3sxY8fXDbp
oLybjOgy3usPjJpaxYJye6adP6mNw5VC80CGCsuyhxx1x7QeEsJm0ZSJK2Om+GSOdhkF799C
SgThmX8ncHUAAAAAAAA=
--------------ms000006090002000309050200--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l87Ma2lc025388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2007 15:36:02 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l87Ma2US025387; Fri, 7 Sep 2007 15:36:02 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l87Ma0Dx025380 for <ietf-ltans@imc.org>; Fri, 7 Sep 2007 15:36:01 -0700 (MST) (envelope-from tglassey@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=A60/JXN+zolNlYWdPXLxUlDgFtg9GVLS0ZyBiWPmaRcHfi/yLmJtabO9Euz9AW4P; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=gw) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1ITmQh-00081Y-Sc; Fri, 07 Sep 2007 18:36:00 -0400
Message-ID: <004701c7f19f$8b182d20$174f7d40@home.glassey.com>
From: "todd glassey" <tglassey@earthlink.net>
To: "Carl Wallace" <CWallace@cygnacom.com>, "Vittek Robert" <vittek@ditec.sk>, <ietf-ltans@imc.org>
References: <886F5D4C78AFB14D87261206BFB9612E1D31DE45@scygmxs1.cygnacom.com>
Subject: Re: security issue in archive timestamp chain?
Date: Fri, 7 Sep 2007 15:36:28 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C7F164.DB4256D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79f51ca1ee36d3fa8241e023584f9f9d91350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

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

RE: security issue in archive timestamp chain?Carl -=20
  ----- Original Message -----=20
  From: Carl Wallace=20
  To: Vittek Robert ; ietf-ltans@imc.org=20
  Sent: Friday, September 07, 2007 9:10 AM
  Subject: RE: security issue in archive timestamp chain?


  The information needs to be preserved. =20

As does its "Chain of Custody" ...  And the key here is that this data =
MUST be preserved in a manner that makes it admissible in Courts of Law =
or there is no reason to store the data... in fact if LTANS' is not =
setup to meet the legal requirements in place today - LTANS operators =
would not be allowed to submit data to the Courts, and further that data =
wouldnt meet the Compliance Audit requirements for SOX and other =
legislation.=20

So who would use LTANS then?=20

Todd G.
------=_NextPart_000_0044_01C7F164.DB4256D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: security issue in archive timestamp =
chain?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman" size=3D2>Carl - </FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3DCWallace@cygnacom.com =
href=3D"mailto:CWallace@cygnacom.com">Carl=20
  Wallace</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=3Dvittek@ditec.sk=20
  href=3D"mailto:vittek@ditec.sk">Vittek Robert</A> ; <A =
title=3Dietf-ltans@imc.org=20
  href=3D"mailto:ietf-ltans@imc.org">ietf-ltans@imc.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, September 07, =
2007 9:10=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: security issue in =
archive=20
  timestamp chain?</DIV>
  <DIV><BR></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D467440816-07092007><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>The information needs to be preserved.&nbsp;=20
  </FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D467440816-07092007><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D467440816-07092007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>As does its "Chain of Custody" ...&nbsp; And =
the key here=20
is that this&nbsp;data MUST be&nbsp;preserved in a manner that makes it=20
admissible in Courts of Law or there is no reason to store the data... =
in fact=20
if LTANS' is not setup to meet the legal requirements in place today - =
LTANS=20
operators would not be allowed to submit data to the Courts, and further =
that=20
data wouldnt meet the Compliance Audit requirements for SOX and other=20
legislation. </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D467440816-07092007><FONT =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D467440816-07092007><FONT =
color=3D#0000ff=20
size=3D2>So who would use LTANS then? </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D467440816-07092007><FONT =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D467440816-07092007><FONT =
color=3D#0000ff=20
size=3D2>Todd G.</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_0044_01C7F164.DB4256D0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l87GAPYF088954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2007 09:10:25 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l87GAPgE088953; Fri, 7 Sep 2007 09:10:25 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l87GAMYK088941 for <ietf-ltans@imc.org>; Fri, 7 Sep 2007 09:10:23 -0700 (MST) (envelope-from CWallace@cygnacom.com)
Received: (qmail 13374 invoked from network); 7 Sep 2007 16:06:50 -0000
Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;07 Sep 2007 16:06:50 -0000
Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 7 Sep 2007 16:06:50 -0000
Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id <L49PHC65>; Fri, 7 Sep 2007 12:10:21 -0400
Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31DE45@scygmxs1.cygnacom.com>
From: Carl Wallace <CWallace@cygnacom.com>
To: Vittek Robert <vittek@ditec.sk>, ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?
Date: Fri, 7 Sep 2007 12:10:15 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F169.93D3090C"
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

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_01C7F169.93D3090C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The information needs to be preserved.  Storing the information and
preserving it multiple times seems like a greater hassle and waste to =
me.
The TSAs will be used to verify a great many evidence records.  If =
stored
and verified separately, it's not even necessary to verify them for =
each
evidence record verification.  There are pros and cons both ways.


  _____ =20

From: Vittek Robert [mailto:vittek@ditec.sk]=20
Sent: Friday, September 07, 2007 11:58 AM
To: Carl Wallace; ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?
Importance: Low


Yes, that would be my next question - how to incorporate "grace period" =
to
process of verification of TS validation data to be fully compliant =
with
requirement of section 5.3 of ERS. :-)
=20
I think that protecting the TS validation data independently but
nevertheless by another TS only raises the number of necessary time =
stamps
exponentially.

  _____ =20

From: Carl Wallace [mailto:CWallace@cygnacom.com]=20
Sent: Tuesday, September 04, 2007 7:45 PM
To: Vittek Robert; ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?



There's no need to safeguard the validation data for ATS1 at the time =
ATS2
is applied.  The validation data can be preserved independently of the =
data
and retrieved using SCVP/ERS.  Amongst other benefits, this allows for =
a
grace period to be applied between the time ATS2 was generated and the =
time
of interest for validating the TSA1 credentials.   =20

> -----Original Message-----=20
> From: owner-ietf-ltans@mail.imc.org=20
> [mailto:owner-ietf-ltans@mail.imc.org
<mailto:owner-ietf-ltans@mail.imc.org> ] On Behalf Of Vittek Robert=20
> Sent: Tuesday, September 04, 2007 1:23 PM=20
> To: ietf-ltans@imc.org=20
> Subject: security issue in archive timestamp chain?=20
>=20
>=20
> We are currently implementing a long term electronic=20
> signature based on XAdES, so I went through TS 101 903, TS=20
> 101 733 and other RFCs that led me finaly to LTANS group=20
> because XAdES does not address the problem of validation of=20
> TSA certificates ("Rules for acceptance of the validity of=20
> the signature within the time-stamp, involving trust=20
> decisions, are out of the scope of the present document.").=20
>=20
> I am interested in solving the following problem.=20
>=20
> http://tools.ietf.org/html/rfc4998#section-5.3
<http://tools.ietf.org/html/rfc4998#section-5.3>  states that:=20
> Each Archive Timestamp MUST be valid relative to the time of=20
> the following Archive Timestamp.=20
>=20
> Let's assume that we have Archive Time-Stamp 1 (ATS1) and we=20
> need to renew it and safeguard the validation data for ATS1=20
> at the same time. But the next Archive Time-Stamp 2 (ATS2)=20
> can prove existence only of the CRLs issued before time T2=20
> (from ATS2). ATS2 does NOT give any evidence that there was=20
> not another CRL2 (issued by CA that issued TSA1 certificate)=20
> which contained information on revocation of TSA1 certificate.=20
>=20
> I think that arbitration on validity of ATS1 might take place=20
> long after the archive of relevant CRLs is available and long=20
> after the used cryptography is strong enough, so the attacker=20
> might produce such CRL2 himself just to cast doubt upon the=20
> archived data.=20
>=20
> In other words: while T2 - safeguardedCRLforTSA1.thisUpdate >=20
> 0, arbitrator can not be sure that there was not another CRL2=20
> that listed TSA1 certificate.=20
>=20
> Am I missing something or is it a security issue?=20
>=20
>=20
> Mgr. Robert Vittek=20
>=20
> DITEC, a.s.=20
> Bratislava Business Center V=20
> Plyn=E1rensk=E1 7/C=20
> 821 09 Bratislava=20
>=20
> voice: +421 2 58 222 487=20
> fax: +421 2 58 222 777=20
> cell: +421 908 797 827=20
> mailto:vittek@ditec.sk <mailto:vittek@ditec.sk> =20
>=20


------_=_NextPart_001_01C7F169.93D3090C
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: security issue in archive timestamp chain?</TITLE>

<META content="MSHTML 6.00.2900.3157" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=467440816-07092007><FONT face=Arial 
color=#0000ff size=2>The information needs to be preserved.&nbsp; Storing the 
information and preserving it multiple times seems like a greater hassle and 
waste to me.&nbsp; The TSAs will be used to verify a great many evidence 
records.&nbsp; If stored and verified separately, it's not even necessary to 
verify them for each evidence record verification.&nbsp; There are pros and cons 
both ways.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> Vittek Robert [mailto:vittek@ditec.sk] 
  <BR><B>Sent:</B> Friday, September 07, 2007 11:58 AM<BR><B>To:</B> Carl 
  Wallace; ietf-ltans@imc.org<BR><B>Subject:</B> RE: security issue in archive 
  timestamp chain?<BR><B>Importance:</B> Low<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV dir=ltr align=left><SPAN class=117504114-07092007><FONT face=Arial 
  color=#0000ff size=2>Yes, that would be my next question - how to incorporate 
  "grace period" to process of verification of TS validation data to be fully 
  compliant with requirement of section 5.3 of ERS. :-)</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=117504114-07092007><FONT face=Arial 
  color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=117504114-07092007><FONT face=Arial 
  color=#0000ff size=2>I think that protecting the TS validation data 
  independently but nevertheless by another TS only raises the number 
  of&nbsp;necessary time stamps exponentially.</FONT></SPAN></DIV><BR>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> Carl Wallace 
  [mailto:CWallace@cygnacom.com] <BR><B>Sent:</B> Tuesday, September 04, 2007 
  7:45 PM<BR><B>To:</B> Vittek Robert; ietf-ltans@imc.org<BR><B>Subject:</B> RE: 
  security issue in archive timestamp chain?<BR></FONT><BR></DIV>
  <DIV></DIV>
  <P><FONT size=2>There's no need to safeguard the validation data for ATS1 at 
  the time ATS2 is applied.&nbsp; The validation data can be preserved 
  independently of the data and retrieved using SCVP/ERS.&nbsp; Amongst other 
  benefits, this allows for a grace period to be applied between the time ATS2 
  was generated and the time of interest for validating the TSA1 
  credentials.&nbsp;&nbsp;&nbsp; </FONT></P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: owner-ietf-ltans@mail.imc.org </FONT><BR><FONT size=2>&gt; [<A 
  href="mailto:owner-ietf-ltans@mail.imc.org">mailto:owner-ietf-ltans@mail.imc.org</A>] 
  On Behalf Of Vittek Robert</FONT> <BR><FONT size=2>&gt; Sent: Tuesday, 
  September 04, 2007 1:23 PM</FONT> <BR><FONT size=2>&gt; To: 
  ietf-ltans@imc.org</FONT> <BR><FONT size=2>&gt; Subject: security issue in 
  archive timestamp chain?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; We are currently implementing a long 
  term electronic </FONT><BR><FONT size=2>&gt; signature based on XAdES, so I 
  went through TS 101 903, TS </FONT><BR><FONT size=2>&gt; 101 733 and other 
  RFCs that led me finaly to LTANS group </FONT><BR><FONT size=2>&gt; because 
  XAdES does not address the problem of validation of </FONT><BR><FONT 
  size=2>&gt; TSA certificates ("Rules for acceptance of the validity of 
  </FONT><BR><FONT size=2>&gt; the signature within the time-stamp, involving 
  trust </FONT><BR><FONT size=2>&gt; decisions, are out of the scope of the 
  present document.").</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  I am interested in solving the following problem.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; <A 
  href="http://tools.ietf.org/html/rfc4998#section-5.3" 
  target=_blank>http://tools.ietf.org/html/rfc4998#section-5.3</A> states that: 
  </FONT><BR><FONT size=2>&gt; Each Archive Timestamp MUST be valid relative to 
  the time of </FONT><BR><FONT size=2>&gt; the following Archive 
  Timestamp.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Let's 
  assume that we have Archive Time-Stamp 1 (ATS1) and we </FONT><BR><FONT 
  size=2>&gt; need to renew it and safeguard the validation data for ATS1 
  </FONT><BR><FONT size=2>&gt; at the same time. But the next Archive Time-Stamp 
  2 (ATS2) </FONT><BR><FONT size=2>&gt; can prove existence only of the CRLs 
  issued before time T2 </FONT><BR><FONT size=2>&gt; (from ATS2). ATS2 does NOT 
  give any evidence that there was </FONT><BR><FONT size=2>&gt; not another CRL2 
  (issued by CA that issued TSA1 certificate) </FONT><BR><FONT size=2>&gt; which 
  contained information on revocation of TSA1 certificate.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; I think that arbitration on validity 
  of ATS1 might take place </FONT><BR><FONT size=2>&gt; long after the archive 
  of relevant CRLs is available and long </FONT><BR><FONT size=2>&gt; after the 
  used cryptography is strong enough, so the attacker </FONT><BR><FONT 
  size=2>&gt; might produce such CRL2 himself just to cast doubt upon the 
  </FONT><BR><FONT size=2>&gt; archived data.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; In other words: while T2 - 
  safeguardedCRLforTSA1.thisUpdate &gt; </FONT><BR><FONT size=2>&gt; 0, 
  arbitrator can not be sure that there was not another CRL2 </FONT><BR><FONT 
  size=2>&gt; that listed TSA1 certificate.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Am I missing something or is it a security 
  issue?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Mgr. Robert Vittek</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; DITEC, a.s.</FONT> <BR><FONT size=2>&gt; 
  Bratislava Business Center V</FONT> <BR><FONT size=2>&gt; Plynárenská 
  7/C</FONT> <BR><FONT size=2>&gt; 821 09 Bratislava</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; voice: +421 2 58 222 487</FONT> 
  <BR><FONT size=2>&gt; fax: +421 2 58 222 777</FONT> <BR><FONT size=2>&gt; 
  cell: +421 908 797 827</FONT> <BR><FONT size=2>&gt; <A 
  href="mailto:vittek@ditec.sk">mailto:vittek@ditec.sk</A></FONT> <BR><FONT 
  size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C7F169.93D3090C--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l87G8NqH088682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2007 09:08:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l87G8NOg088681; Fri, 7 Sep 2007 09:08:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l87G8Lq6088673 for <ietf-ltans@imc.org>; Fri, 7 Sep 2007 09:08:22 -0700 (MST) (envelope-from tglassey@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gSWBfb0IILbjFj213uNnijDelSdi4+Ngyt/8OtvczK0WeGkdHRLhTrw+QD65cQA+; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=gw) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1ITgNE-0001jZ-Hg; Fri, 07 Sep 2007 12:08:00 -0400
Message-ID: <003c01c7f169$4542bc10$174f7d40@home.glassey.com>
From: "todd glassey" <tglassey@earthlink.net>
To: "Vittek Robert" <vittek@ditec.sk>, "Carl Wallace" <CWallace@cygnacom.com>, <ietf-ltans@imc.org>
References: <886F5D4C78AFB14D87261206BFB9612E1D31DC6C@scygmxs1.cygnacom.com> <E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7431@mail.intra.ditec.sk>
Subject: Re: security issue in archive timestamp chain?
Date: Fri, 7 Sep 2007 09:07:44 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C7F12E.8D33CB80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79f31dc2238461111d1faa1d5965ec17bb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01C7F12E.8D33CB80
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

RE: security issue in archive timestamp chain?This next comment is =
formally spoken as an Industry Forensics Specialist...

Its not the grace period - its the issue with "that without the history =
parts of that document's Chain-Of-Custody information is missing" and as =
such its not what you may think it is... =20

Todd Glassey=20
(as a Certified Information Forensics Investigator).
  ----- Original Message -----=20
  From: Vittek Robert=20
  To: Carl Wallace ; ietf-ltans@imc.org=20
  Sent: Friday, September 07, 2007 8:57 AM
  Subject: RE: security issue in archive timestamp chain?


  Yes, that would be my next question - how to incorporate "grace =
period" to process of verification of TS validation data to be fully =
compliant with requirement of section 5.3 of ERS. :-)

  I think that protecting the TS validation data independently but =
nevertheless by another TS only raises the number of necessary time =
stamps exponentially.



-------------------------------------------------------------------------=
-----
  From: Carl Wallace [mailto:CWallace@cygnacom.com]=20
  Sent: Tuesday, September 04, 2007 7:45 PM
  To: Vittek Robert; ietf-ltans@imc.org
  Subject: RE: security issue in archive timestamp chain?


  There's no need to safeguard the validation data for ATS1 at the time =
ATS2 is applied.  The validation data can be preserved independently of =
the data and retrieved using SCVP/ERS.  Amongst other benefits, this =
allows for a grace period to be applied between the time ATS2 was =
generated and the time of interest for validating the TSA1 credentials.  =
 =20

  > -----Original Message-----=20
  > From: owner-ietf-ltans@mail.imc.org=20
  > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert=20
  > Sent: Tuesday, September 04, 2007 1:23 PM=20
  > To: ietf-ltans@imc.org=20
  > Subject: security issue in archive timestamp chain?=20
  >=20
  >=20
  > We are currently implementing a long term electronic=20
  > signature based on XAdES, so I went through TS 101 903, TS=20
  > 101 733 and other RFCs that led me finaly to LTANS group=20
  > because XAdES does not address the problem of validation of=20
  > TSA certificates ("Rules for acceptance of the validity of=20
  > the signature within the time-stamp, involving trust=20
  > decisions, are out of the scope of the present document.").=20
  >=20
  > I am interested in solving the following problem.=20
  >=20
  > http://tools.ietf.org/html/rfc4998#section-5.3 states that:=20
  > Each Archive Timestamp MUST be valid relative to the time of=20
  > the following Archive Timestamp.=20
  >=20
  > Let's assume that we have Archive Time-Stamp 1 (ATS1) and we=20
  > need to renew it and safeguard the validation data for ATS1=20
  > at the same time. But the next Archive Time-Stamp 2 (ATS2)=20
  > can prove existence only of the CRLs issued before time T2=20
  > (from ATS2). ATS2 does NOT give any evidence that there was=20
  > not another CRL2 (issued by CA that issued TSA1 certificate)=20
  > which contained information on revocation of TSA1 certificate.=20
  >=20
  > I think that arbitration on validity of ATS1 might take place=20
  > long after the archive of relevant CRLs is available and long=20
  > after the used cryptography is strong enough, so the attacker=20
  > might produce such CRL2 himself just to cast doubt upon the=20
  > archived data.=20
  >=20
  > In other words: while T2 - safeguardedCRLforTSA1.thisUpdate >=20
  > 0, arbitrator can not be sure that there was not another CRL2=20
  > that listed TSA1 certificate.=20
  >=20
  > Am I missing something or is it a security issue?=20
  >=20
  >=20
  > Mgr. Robert Vittek=20
  >=20
  > DITEC, a.s.=20
  > Bratislava Business Center V=20
  > Plyn=E1rensk=E1 7/C=20
  > 821 09 Bratislava=20
  >=20
  > voice: +421 2 58 222 487=20
  > fax: +421 2 58 222 777=20
  > cell: +421 908 797 827=20
  > mailto:vittek@ditec.sk=20
  >=20

------=_NextPart_000_0031_01C7F12E.8D33CB80
Content-Type: text/html;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: security issue in archive timestamp =
chain?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-2">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman" size=3D2>This next comment is =
formally spoken as=20
an Industry Forensics Specialist...</FONT></DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2>Its not the grace period - =
its the=20
issue with "that without the history parts of that document's =
Chain-Of-Custody=20
information is missing" and as such its not what you may think it =
is...&nbsp;=20
</FONT></DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2>Todd Glassey </FONT></DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2>(as a Certified Information =
Forensics=20
Investigator).</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dvittek@ditec.sk href=3D"mailto:vittek@ditec.sk">Vittek =
Robert</A>=20
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3DCWallace@cygnacom.com=20
  href=3D"mailto:CWallace@cygnacom.com">Carl Wallace</A> ; <A=20
  title=3Dietf-ltans@imc.org=20
  href=3D"mailto:ietf-ltans@imc.org">ietf-ltans@imc.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, September 07, =
2007 8:57=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: security issue in =
archive=20
  timestamp chain?</DIV>
  <DIV><BR></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Yes, that would be my next question - how to =
incorporate=20
  "grace period" to process of verification of TS validation data to be =
fully=20
  compliant with requirement of section 5.3 of ERS. =
:-)</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>I think that protecting the TS validation =
data=20
  independently but nevertheless by another TS only raises the number=20
  of&nbsp;necessary time stamps exponentially.</FONT></SPAN></DIV><BR>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Carl Wallace=20
  [mailto:CWallace@cygnacom.com] <BR><B>Sent:</B> Tuesday, September 04, =
2007=20
  7:45 PM<BR><B>To:</B> Vittek Robert; =
ietf-ltans@imc.org<BR><B>Subject:</B> RE:=20
  security issue in archive timestamp chain?<BR></FONT><BR></DIV>
  <DIV></DIV>
  <P><FONT size=3D2>There's no need to safeguard the validation data for =
ATS1 at=20
  the time ATS2 is applied.&nbsp; The validation data can be preserved=20
  independently of the data and retrieved using SCVP/ERS.&nbsp; Amongst =
other=20
  benefits, this allows for a grace period to be applied between the =
time ATS2=20
  was generated and the time of interest for validating the TSA1=20
  credentials.&nbsp;&nbsp;&nbsp; </FONT></P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: owner-ietf-ltans@mail.imc.org </FONT><BR><FONT size=3D2>&gt; [<A =

  =
href=3D"mailto:owner-ietf-ltans@mail.imc.org">mailto:owner-ietf-ltans@mai=
l.imc.org</A>]=20
  On Behalf Of Vittek Robert</FONT> <BR><FONT size=3D2>&gt; Sent: =
Tuesday,=20
  September 04, 2007 1:23 PM</FONT> <BR><FONT size=3D2>&gt; To:=20
  ietf-ltans@imc.org</FONT> <BR><FONT size=3D2>&gt; Subject: security =
issue in=20
  archive timestamp chain?</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; We are currently =
implementing a long=20
  term electronic </FONT><BR><FONT size=3D2>&gt; signature based on =
XAdES, so I=20
  went through TS 101 903, TS </FONT><BR><FONT size=3D2>&gt; 101 733 and =
other=20
  RFCs that led me finaly to LTANS group </FONT><BR><FONT size=3D2>&gt; =
because=20
  XAdES does not address the problem of validation of </FONT><BR><FONT=20
  size=3D2>&gt; TSA certificates ("Rules for acceptance of the validity =
of=20
  </FONT><BR><FONT size=3D2>&gt; the signature within the time-stamp, =
involving=20
  trust </FONT><BR><FONT size=3D2>&gt; decisions, are out of the scope =
of the=20
  present document.").</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  I am interested in solving the following problem.</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; <A=20
  href=3D"http://tools.ietf.org/html/rfc4998#section-5.3"=20
  target=3D_blank>http://tools.ietf.org/html/rfc4998#section-5.3</A> =
states that:=20
  </FONT><BR><FONT size=3D2>&gt; Each Archive Timestamp MUST be valid =
relative to=20
  the time of </FONT><BR><FONT size=3D2>&gt; the following Archive=20
  Timestamp.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; Let's=20
  assume that we have Archive Time-Stamp 1 (ATS1) and we =
</FONT><BR><FONT=20
  size=3D2>&gt; need to renew it and safeguard the validation data for =
ATS1=20
  </FONT><BR><FONT size=3D2>&gt; at the same time. But the next Archive =
Time-Stamp=20
  2 (ATS2) </FONT><BR><FONT size=3D2>&gt; can prove existence only of =
the CRLs=20
  issued before time T2 </FONT><BR><FONT size=3D2>&gt; (from ATS2). ATS2 =
does NOT=20
  give any evidence that there was </FONT><BR><FONT size=3D2>&gt; not =
another CRL2=20
  (issued by CA that issued TSA1 certificate) </FONT><BR><FONT =
size=3D2>&gt; which=20
  contained information on revocation of TSA1 certificate.</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; I think that arbitration =
on validity=20
  of ATS1 might take place </FONT><BR><FONT size=3D2>&gt; long after the =
archive=20
  of relevant CRLs is available and long </FONT><BR><FONT size=3D2>&gt; =
after the=20
  used cryptography is strong enough, so the attacker </FONT><BR><FONT=20
  size=3D2>&gt; might produce such CRL2 himself just to cast doubt upon =
the=20
  </FONT><BR><FONT size=3D2>&gt; archived data.</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; In other words: while T2 -=20
  safeguardedCRLforTSA1.thisUpdate &gt; </FONT><BR><FONT size=3D2>&gt; =
0,=20
  arbitrator can not be sure that there was not another CRL2 =
</FONT><BR><FONT=20
  size=3D2>&gt; that listed TSA1 certificate.</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Am I missing something or is it a =
security=20
  issue?</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Mgr. Robert Vittek</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; DITEC, a.s.</FONT> <BR><FONT =
size=3D2>&gt;=20
  Bratislava Business Center V</FONT> <BR><FONT size=3D2>&gt; =
Plyn=E1rensk=E1=20
  7/C</FONT> <BR><FONT size=3D2>&gt; 821 09 Bratislava</FONT> <BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; voice: +421 2 58 222 =
487</FONT>=20
  <BR><FONT size=3D2>&gt; fax: +421 2 58 222 777</FONT> <BR><FONT =
size=3D2>&gt;=20
  cell: +421 908 797 827</FONT> <BR><FONT size=3D2>&gt; <A=20
  href=3D"mailto:vittek@ditec.sk">mailto:vittek@ditec.sk</A></FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0031_01C7F12E.8D33CB80--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l87FvhE0087282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2007 08:57:43 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l87Fvhrv087280; Fri, 7 Sep 2007 08:57:43 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mail.ditec.sk (mail.ditec.sk [82.119.228.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l87Fvd77087270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-ltans@imc.org>; Fri, 7 Sep 2007 08:57:41 -0700 (MST) (envelope-from vittek@ditec.sk)
Received: from mail.intra.ditec.sk (mail.intra.ditec.sk [172.24.31.14]) by mail.ditec.sk (8.14.1/8.14.1) with ESMTP id l87FvdOo003786 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 7 Sep 2007 17:57:39 +0200
Received: from mail.intra.ditec.sk ([172.24.31.14]) by mail.intra.ditec.sk ([172.24.31.14]) with mapi; Fri, 7 Sep 2007 17:57:37 +0200
From: Vittek Robert <vittek@ditec.sk>
To: Carl Wallace <CWallace@cygnacom.com>, "ietf-ltans@imc.org" <ietf-ltans@imc.org>
Importance: low
Date: Fri, 7 Sep 2007 17:57:36 +0200
Subject: RE: security issue in archive timestamp chain?
Thread-Topic: security issue in archive timestamp chain?
Thread-Index: AcfvG2AC4+fJ66FbRD6UUxOpq6IrGwCQdi+g
Message-ID: <E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7431@mail.intra.ditec.sk>
References: <886F5D4C78AFB14D87261206BFB9612E1D31DC6C@scygmxs1.cygnacom.com>
In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31DC6C@scygmxs1.cygnacom.com>
Accept-Language: en-US, sk-SK
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, sk-SK
Content-Type: multipart/alternative; boundary="_000_E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7431mailintradite_"
MIME-Version: 1.0
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

--_000_E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7431mailintradite_
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Yes, that would be my next question - how to incorporate "grace period" to =
process of verification of TS validation data to be fully compliant with re=
quirement of section 5.3 of ERS. :-)

I think that protecting the TS validation data independently but neverthele=
ss by another TS only raises the number of necessary time stamps exponentia=
lly.

________________________________
From: Carl Wallace [mailto:CWallace@cygnacom.com]
Sent: Tuesday, September 04, 2007 7:45 PM
To: Vittek Robert; ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?


There's no need to safeguard the validation data for ATS1 at the time ATS2 =
is applied.  The validation data can be preserved independently of the data=
 and retrieved using SCVP/ERS.  Amongst other benefits, this allows for a g=
race period to be applied between the time ATS2 was generated and the time =
of interest for validating the TSA1 credentials.

> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org
> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert
> Sent: Tuesday, September 04, 2007 1:23 PM
> To: ietf-ltans@imc.org
> Subject: security issue in archive timestamp chain?
>
>
> We are currently implementing a long term electronic
> signature based on XAdES, so I went through TS 101 903, TS
> 101 733 and other RFCs that led me finaly to LTANS group
> because XAdES does not address the problem of validation of
> TSA certificates ("Rules for acceptance of the validity of
> the signature within the time-stamp, involving trust
> decisions, are out of the scope of the present document.").
>
> I am interested in solving the following problem.
>
> http://tools.ietf.org/html/rfc4998#section-5.3 states that:
> Each Archive Timestamp MUST be valid relative to the time of
> the following Archive Timestamp.
>
> Let's assume that we have Archive Time-Stamp 1 (ATS1) and we
> need to renew it and safeguard the validation data for ATS1
> at the same time. But the next Archive Time-Stamp 2 (ATS2)
> can prove existence only of the CRLs issued before time T2
> (from ATS2). ATS2 does NOT give any evidence that there was
> not another CRL2 (issued by CA that issued TSA1 certificate)
> which contained information on revocation of TSA1 certificate.
>
> I think that arbitration on validity of ATS1 might take place
> long after the archive of relevant CRLs is available and long
> after the used cryptography is strong enough, so the attacker
> might produce such CRL2 himself just to cast doubt upon the
> archived data.
>
> In other words: while T2 - safeguardedCRLforTSA1.thisUpdate >
> 0, arbitrator can not be sure that there was not another CRL2
> that listed TSA1 certificate.
>
> Am I missing something or is it a security issue?
>
>
> Mgr. Robert Vittek
>
> DITEC, a.s.
> Bratislava Business Center V
> Plyn=E1rensk=E1 7/C
> 821 09 Bratislava
>
> voice: +421 2 58 222 487
> fax: +421 2 58 222 777
> cell: +421 908 797 827
> mailto:vittek@ditec.sk
>

--_000_E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7431mailintradite_
Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: security issue in archive timestamp chain?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-2"=
>
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Yes, that would be my next question - how to incor=
porate=20
"grace period" to process of verification of TS validation data to be fully=
=20
compliant with requirement of section 5.3 of ERS. :-)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>I think that protecting the TS validation data=20
independently but nevertheless by another TS only raises the number=20
of&nbsp;necessary time stamps exponentially.</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Carl Wallace=20
[mailto:CWallace@cygnacom.com] <BR><B>Sent:</B> Tuesday, September 04, 2007=
 7:45=20
PM<BR><B>To:</B> Vittek Robert; ietf-ltans@imc.org<BR><B>Subject:</B> RE:=20
security issue in archive timestamp chain?<BR></FONT><BR></DIV>
<DIV></DIV>
<P><FONT size=3D2>There's no need to safeguard the validation data for ATS1=
 at the=20
time ATS2 is applied.&nbsp; The validation data can be preserved independen=
tly=20
of the data and retrieved using SCVP/ERS.&nbsp; Amongst other benefits, thi=
s=20
allows for a grace period to be applied between the time ATS2 was generated=
 and=20
the time of interest for validating the TSA1 credentials.&nbsp;&nbsp;&nbsp;=
=20
</FONT></P>
<P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT size=3D2=
>&gt;=20
From: owner-ietf-ltans@mail.imc.org </FONT><BR><FONT size=3D2>&gt; [<A=20
href=3D"mailto:owner-ietf-ltans@mail.imc.org">mailto:owner-ietf-ltans@mail.=
imc.org</A>]=20
On Behalf Of Vittek Robert</FONT> <BR><FONT size=3D2>&gt; Sent: Tuesday, Se=
ptember=20
04, 2007 1:23 PM</FONT> <BR><FONT size=3D2>&gt; To: ietf-ltans@imc.org</FON=
T>=20
<BR><FONT size=3D2>&gt; Subject: security issue in archive timestamp chain?=
</FONT>=20
<BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT siz=
e=3D2>&gt;=20
We are currently implementing a long term electronic </FONT><BR><FONT=20
size=3D2>&gt; signature based on XAdES, so I went through TS 101 903, TS=20
</FONT><BR><FONT size=3D2>&gt; 101 733 and other RFCs that led me finaly to=
 LTANS=20
group </FONT><BR><FONT size=3D2>&gt; because XAdES does not address the pro=
blem of=20
validation of </FONT><BR><FONT size=3D2>&gt; TSA certificates ("Rules for=20
acceptance of the validity of </FONT><BR><FONT size=3D2>&gt; the signature =
within=20
the time-stamp, involving trust </FONT><BR><FONT size=3D2>&gt; decisions, a=
re out=20
of the scope of the present document.").</FONT> <BR><FONT size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; I am interested in solving the following=20
problem.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; <A=20
href=3D"http://tools.ietf.org/html/rfc4998#section-5.3"=20
target=3D_blank>http://tools.ietf.org/html/rfc4998#section-5.3</A> states t=
hat:=20
</FONT><BR><FONT size=3D2>&gt; Each Archive Timestamp MUST be valid relativ=
e to=20
the time of </FONT><BR><FONT size=3D2>&gt; the following Archive Timestamp.=
</FONT>=20
<BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Let's assume that we=
 have=20
Archive Time-Stamp 1 (ATS1) and we </FONT><BR><FONT size=3D2>&gt; need to r=
enew it=20
and safeguard the validation data for ATS1 </FONT><BR><FONT size=3D2>&gt; a=
t the=20
same time. But the next Archive Time-Stamp 2 (ATS2) </FONT><BR><FONT size=
=3D2>&gt;=20
can prove existence only of the CRLs issued before time T2 </FONT><BR><FONT=
=20
size=3D2>&gt; (from ATS2). ATS2 does NOT give any evidence that there was=20
</FONT><BR><FONT size=3D2>&gt; not another CRL2 (issued by CA that issued T=
SA1=20
certificate) </FONT><BR><FONT size=3D2>&gt; which contained information on=
=20
revocation of TSA1 certificate.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><=
FONT=20
size=3D2>&gt; I think that arbitration on validity of ATS1 might take place=
=20
</FONT><BR><FONT size=3D2>&gt; long after the archive of relevant CRLs is=20
available and long </FONT><BR><FONT size=3D2>&gt; after the used cryptograp=
hy is=20
strong enough, so the attacker </FONT><BR><FONT size=3D2>&gt; might produce=
 such=20
CRL2 himself just to cast doubt upon the </FONT><BR><FONT size=3D2>&gt; arc=
hived=20
data.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; In othe=
r words:=20
while T2 - safeguardedCRLforTSA1.thisUpdate &gt; </FONT><BR><FONT size=3D2>=
&gt; 0,=20
arbitrator can not be sure that there was not another CRL2 </FONT><BR><FONT=
=20
size=3D2>&gt; that listed TSA1 certificate.</FONT> <BR><FONT size=3D2>&gt;=
=20
</FONT><BR><FONT size=3D2>&gt; Am I missing something or is it a security=20
issue?</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
</FONT><BR><FONT size=3D2>&gt; Mgr. Robert Vittek</FONT> <BR><FONT size=3D2=
>&gt;=20
</FONT><BR><FONT size=3D2>&gt; DITEC, a.s.</FONT> <BR><FONT size=3D2>&gt; B=
ratislava=20
Business Center V</FONT> <BR><FONT size=3D2>&gt; Plyn=E1rensk=E1 7/C</FONT>=
 <BR><FONT=20
size=3D2>&gt; 821 09 Bratislava</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><=
FONT=20
size=3D2>&gt; voice: +421 2 58 222 487</FONT> <BR><FONT size=3D2>&gt; fax: =
+421 2 58=20
222 777</FONT> <BR><FONT size=3D2>&gt; cell: +421 908 797 827</FONT> <BR><F=
ONT=20
size=3D2>&gt; <A href=3D"mailto:vittek@ditec.sk">mailto:vittek@ditec.sk</A>=
</FONT>=20
<BR><FONT size=3D2>&gt; </FONT></P></BODY></HTML>

--_000_E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7431mailintradite_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l87FvUqE087255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2007 08:57:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l87FvUO4087254; Fri, 7 Sep 2007 08:57:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mail.ditec.sk (mail.ditec.sk [82.119.228.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l87FvPBk087241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-ltans@imc.org>; Fri, 7 Sep 2007 08:57:27 -0700 (MST) (envelope-from vittek@ditec.sk)
Received: from mail.intra.ditec.sk (mail.intra.ditec.sk [172.24.31.14]) by mail.ditec.sk (8.14.1/8.14.1) with ESMTP id l87FvKQg003779 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 7 Sep 2007 17:57:20 +0200
Received: from mail.intra.ditec.sk ([172.24.31.14]) by mail.intra.ditec.sk ([172.24.31.14]) with mapi; Fri, 7 Sep 2007 17:57:18 +0200
From: Vittek Robert <vittek@ditec.sk>
To: "ietf-ltans@imc.org" <ietf-ltans@imc.org>
CC: Santosh Chokhani <chokhani@orionsec.com>, Carl Wallace <CWallace@cygnacom.com>, todd glassey <tglassey@earthlink.net>
Date: Fri, 7 Sep 2007 17:57:16 +0200
Subject: RE: security issue in archive timestamp chain?
Thread-Topic: security issue in archive timestamp chain?
Thread-Index: AcfvHQtk4Sjkc7G8Qw2xNDTuvpRCWwAI1VtAAAAjl8AAh9HkcA==
Message-ID: <E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7430@mail.intra.ditec.sk>
References: <886F5D4C78AFB14D87261206BFB9612E1D31DC6C@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879090DD6E7@EXVS01.ex.dslextreme.net>
In-Reply-To: <82D5657AE1F54347A734BDD33637C879090DD6E7@EXVS01.ex.dslextreme.net>
Accept-Language: en-US, sk-SK
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, sk-SK
Content-Type: multipart/alternative; boundary="_000_E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7430mailintradite_"
MIME-Version: 1.0
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

--_000_E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7430mailintradite_
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Thank all of you for answers. Well, first I have to explain why I submitted=
 my question to LTANS group.

I know that LTANS does not deal with electronic signatures or XAdES but in =
fact it addresses very similar problem of long term archiving.
XAdES itself does not address verification of validation data of signature =
time-stamps or archive time-stamps, it only requires to protect these data =
together with previous time-stamps by next archive time-stamp.
As I wanted to get inspired how to do it, I read the ERS specification but =
I did not find the answer anyway. Verification of TS validation data seems =
to be out od scope of every document.

This is the scenarion which I considered:
t1. contract document D is electronically signed resulting in ES (D states =
e.g. that 10 years from signature somebody is due to pay a lot of money).
t2. TS is applied to ES to prove its existence in time t2 (countdown of 10 =
years begins).
t3. all validation data for signer's certificate (certificates, revocations=
) are gathered after grace period and the contract signature ES is proved v=
alid in time t2.
t4. all validation data for TS certificate are gathered and TS is found val=
id in t4.
t5. archive ATS is applied to bundle (D, ES, TS, validation data for signer=
's certificate, validation data for TS certificate) to safeguard D, ES, TS =
and all validation data used.

Question is: How can I be sure that TS certificate is still valid in t5? Ne=
xt CRL can list TS certificate with revocationDate (or perhaps even invalid=
ityDate) < t5!! And if TS certificate is NOT valid, then it may be even pos=
sible that ES did not exist in t2 but only later. There is no mean how to i=
ncorporate Next CRL into XAdES structures.

t6. long after the CA (which issued signer's certificate) and TSA (which is=
sued TS) ceased operation and availability of the issued CRLs is history, D=
 and ES come under dispute, but arbitrator (a very wise human) can only say=
: There is a valid archive ATS (issued e.g. by another TSA, still operating=
) applied to the bundle of data but truly I am not sure about the validity =
of TS certificate as the evidence - "Next CRL" - is not available to me any=
more. So there is a possibility that TS certificate was revoked before ATS =
to safeguard bundle of validation data was issued.



________________________________
From: Santosh Chokhani [mailto:chokhani@orionsec.com]
Sent: Wednesday, September 05, 2007 12:15 AM
To: Carl Wallace; Vittek Robert; ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?

In the last sentence, I meant tc > t2 (t2 being the time stamp time).

________________________________
From: Santosh Chokhani
Sent: Tuesday, September 04, 2007 6:12 PM
To: 'Carl Wallace'; Vittek Robert; ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?

Carl,

While what you say is correct, I do not think this answers the question Rob=
ert has.  Let us consider the following scenario

Time t1 is the thisUpdate for a CRL used to verify the time stamp applied a=
t time t2.

Time t3 is when the time stamp is renewed.

We know t3 > t2 > t1.

Time tr is thisUpdate for a CRL when the TSA first appear as compromised.  =
tr > t1.

Time tc is the actual time of compromise.  tr > tc

As long as CRL for t1 is produced using ERS as Carl says, the claimant can =
prove the legitimacy of the time stamp.

If CRL for tr is also produced, the time stamp can come under dispute.  If =
there is an invalidity date associated with the TSA entry and that date is =
past t2, the time stamp is legitimate.

Note that checking revocation status of TSA at time t3 technically does not=
 help since tr can come at any time, including after t3.

Also, if one were to check the revocation status of TSA at time t3, legitim=
ate time stamps that were applied prior to tc or tr may be rejected.  It is=
 tc that is hard to deal with.  That is why we have humans and courts and o=
ther supporting evidence to ferret things out.

I have not purposely included nextUpdate analysis in this since compromise =
of TSA may or may not be detected by the nextUpdate.

In summary, there will be situations when TSA is compromised, some of the t=
ime stamps will come under dispute and that dispute will need to be resolve=
d using other evidence.

This also points to the value of having invalidity date in CRL for TSA entr=
ies.  As long as tc is present in tr and tc > t1, the time stamp will not c=
ome under dispute.
________________________________
From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] =
On Behalf Of Carl Wallace
Sent: Tuesday, September 04, 2007 1:45 PM
To: Vittek Robert; ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?


There's no need to safeguard the validation data for ATS1 at the time ATS2 =
is applied.  The validation data can be preserved independently of the data=
 and retrieved using SCVP/ERS.  Amongst other benefits, this allows for a g=
race period to be applied between the time ATS2 was generated and the time =
of interest for validating the TSA1 credentials.

> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org
> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert
> Sent: Tuesday, September 04, 2007 1:23 PM
> To: ietf-ltans@imc.org
> Subject: security issue in archive timestamp chain?
>
>
> We are currently implementing a long term electronic
> signature based on XAdES, so I went through TS 101 903, TS
> 101 733 and other RFCs that led me finaly to LTANS group
> because XAdES does not address the problem of validation of
> TSA certificates ("Rules for acceptance of the validity of
> the signature within the time-stamp, involving trust
> decisions, are out of the scope of the present document.").
>
> I am interested in solving the following problem.
>
> http://tools.ietf.org/html/rfc4998#section-5.3 states that:
> Each Archive Timestamp MUST be valid relative to the time of
> the following Archive Timestamp.
>
> Let's assume that we have Archive Time-Stamp 1 (ATS1) and we
> need to renew it and safeguard the validation data for ATS1
> at the same time. But the next Archive Time-Stamp 2 (ATS2)
> can prove existence only of the CRLs issued before time T2
> (from ATS2). ATS2 does NOT give any evidence that there was
> not another CRL2 (issued by CA that issued TSA1 certificate)
> which contained information on revocation of TSA1 certificate.
>
> I think that arbitration on validity of ATS1 might take place
> long after the archive of relevant CRLs is available and long
> after the used cryptography is strong enough, so the attacker
> might produce such CRL2 himself just to cast doubt upon the
> archived data.
>
> In other words: while T2 - safeguardedCRLforTSA1.thisUpdate >
> 0, arbitrator can not be sure that there was not another CRL2
> that listed TSA1 certificate.
>
> Am I missing something or is it a security issue?
>
>
> Mgr. Robert Vittek
>
> DITEC, a.s.
> Bratislava Business Center V
> Plyn=E1rensk=E1 7/C
> 821 09 Bratislava
>
> voice: +421 2 58 222 487
> fax: +421 2 58 222 777
> cell: +421 908 797 827
> mailto:vittek@ditec.sk
>

--_000_E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7430mailintradite_
Content-Type: text/html; charset="iso-8859-2"
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" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>RE: security issu=
e in archive timestamp chain?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-2"=
>
<META content=3D"MSHTML 6.00.2900.3157" 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]--><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"City"></o:SmartTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"place"></o:SmartTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"PersonName"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
H1 {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt 0.3in; TEXT-INDEN=
T: -0.3in; FONT-FAMILY: Arial; mso-list: l0 level1 lfo4
}
H2 {
	FONT-WEIGHT: bold; FONT-SIZE: 11pt; MARGIN: 12pt 0in 3pt 0.4in; TEXT-INDEN=
T: -0.4in; FONT-FAMILY: Arial; mso-list: l0 level2 lfo4
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times =
New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
P.StyleCentered {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
LI.StyleCentered {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
DIV.StyleCentered {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
P.stylecentered0 {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
LI.stylecentered0 {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
DIV.stylecentered0 {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Arial
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle21 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT face=3DA=
rial><FONT=20
color=3D#0000ff><FONT size=3D2><SPAN class=3D133140315-07092007>Thank all o=
f you for=20
answers.&nbsp;</SPAN><SPAN class=3D133140315-07092007>W</SPAN>ell, first I =
have to=20
explain why I submitted my question&nbsp;<SPAN class=3D133140315-07092007>t=
o LTANS=20
group</SPAN>.</FONT></FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>I know that&nbsp;LTANS does not deal with electron=
ic=20
signatures or XAdES but in fact it addresses very similar problem of long t=
erm=20
archiving.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>XAdES itself does not address verification of vali=
dation=20
data of signature time-stamps<SPAN class=3D133140315-07092007> or archive=20
time-stamps</SPAN>, it only requires to protect these data together with=20
previous time-stamps by next archive time-stamp.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>As I wanted to get inspired how to do it<SPAN=20
class=3D133140315-07092007>,</SPAN> I read the ERS specification but I did =
not=20
find the answer anyway. Verification of TS validation data seems to be out =
od=20
scope of every document.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><SPAN=20
class=3D133140315-07092007><FONT face=3DArial color=3D#0000ff size=3D2>This=
 is the=20
scenarion which I considered:</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><SPAN=20
class=3D133140315-07092007><FONT face=3DArial color=3D#0000ff size=3D2>t1. =
contract=20
document D is electronically signed&nbsp;resulting in&nbsp;ES (D states e.g=
.=20
that 10 years from signature somebody is due to pay a lot of=20
money).</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><SPAN=20
class=3D133140315-07092007><FONT face=3DArial color=3D#0000ff size=3D2>t2. =
TS is applied=20
to&nbsp;ES to prove its existence&nbsp;in time t2 (countdown of 10 years=20
begins).</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><SPAN=20
class=3D133140315-07092007><FONT face=3DArial color=3D#0000ff size=3D2>t3. =
all=20
validation data for signer's certificate (certificates, revocations) are=20
gathered after grace period and the contract signature ES is proved valid i=
n=20
time t2.</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><SPAN=20
class=3D133140315-07092007><FONT face=3DArial color=3D#0000ff size=3D2>t4. =
all=20
validation data for TS certificate are gathered and TS is found valid in=20
t4.</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><SPAN=20
class=3D133140315-07092007><FONT face=3DArial color=3D#0000ff size=3D2>t5. =
archive ATS=20
is applied to bundle (D, ES, TS, validation data for signer's certificate,=
=20
validation data for TS certificate) to safeguard D, ES, TS and&nbsp;all=20
validation data used.</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><SPAN=20
class=3D133140315-07092007><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><SPAN=20
class=3D133140315-07092007><FONT face=3DArial color=3D#0000ff size=3D2>Ques=
tion is: How=20
can I be sure that TS certificate is still valid in t5? Next CRL can list T=
S=20
certificate with revocationDate (or perhaps even invalidityDate) &lt; t5!! =
And=20
if&nbsp;TS certificate&nbsp;is NOT valid, then it may be even possible=20
that&nbsp;ES did not exist in t2 but only later. There is no mean how to=20
incorporate Next CRL into XAdES structures.</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><SPAN=20
class=3D133140315-07092007><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><SPAN=20
class=3D133140315-07092007><FONT face=3DArial color=3D#0000ff size=3D2>t6. =
long after=20
the CA (which issued signer's certificate) and TSA (which issued TS) ceased=
=20
operation and availability of the issued CRLs is history, D and ES come und=
er=20
dispute, but arbitrator (a very wise human) can only say: There is a valid=
=20
archive ATS (issued e.g. by another TSA, still operating) applied to the bu=
ndle=20
of data but truly I am not sure about the validity of TS certificate as the=
=20
evidence - "Next CRL" - is not available to me anymore. So there is a=20
possibility that TS certificate was revoked before ATS to safeguard bundle =
of=20
validation data was issued.</FONT></SPAN></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><SPAN=20
class=3D133140315-07092007><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D117504114-07092007><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Santosh Chokhani=20
[mailto:chokhani@orionsec.com] <BR><B>Sent:</B> Wednesday, September 05, 20=
07=20
12:15 AM<BR><B>To:</B> Carl Wallace; Vittek Robert;=20
ietf-ltans@imc.org<BR><B>Subject:</B> RE: security issue in archive timesta=
mp=20
chain?<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In the last sent=
ence, I=20
meant tc &gt; t2 (t2 being the time stamp time).<o:p></o:p></SPAN></FONT></=
P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p=
></SPAN></FONT></P>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT=20
face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SP=
AN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"=
>=20
<st1:PersonName w:st=3D"on">Santosh Chokhani</st1:PersonName> <BR><B><SPAN=
=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, September 04, 2007 6:=
12=20
PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> <st1:PersonName=20
w:st=3D"on">'<st1:PersonName w:st=3D"on">Carl=20
Wallace</st1:PersonName>'</st1:PersonName>; Vittek Robert; <st1:PersonName=
=20
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName><BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: security issue in archi=
ve=20
timestamp chain?</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Carl,<o:p></o:p>=
</SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">While what you s=
ay is=20
correct, I do not think this answers the question Robert has.&nbsp; Let us=
=20
consider the following scenario<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Time t1 is the=20
thisUpdate for a CRL used to verify the time stamp applied at time=20
t2.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Time t3 is when =
the=20
time stamp is renewed.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">We know t3 &gt; =
t2 &gt;=20
t1.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Time tr is thisU=
pdate=20
for a CRL when the TSA first appear as compromised.&nbsp; tr &gt;=20
t1.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Time tc is the a=
ctual=20
time of compromise. &nbsp;tr &gt; tc<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As long as CRL f=
or t1=20
is produced using ERS as Carl says, the claimant can prove the legitimacy o=
f the=20
time stamp.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">If CRL for tr is=
 also=20
produced, the time stamp can come under dispute. &nbsp;If there is an inval=
idity=20
date associated with the TSA entry and that date is past t2, the time stamp=
 is=20
legitimate.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Note that checki=
ng=20
revocation status of TSA at time t3 technically does not help since tr can =
come=20
at any time, including after t3.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Also, if one wer=
e to=20
check the revocation status of TSA at time t3, legitimate time stamps that =
were=20
applied prior to tc or tr may be rejected. &nbsp;It is tc that is hard to d=
eal=20
with.&nbsp; That is why we have humans and courts and other supporting evid=
ence=20
to ferret things out.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I have not purpo=
sely=20
included nextUpdate analysis in this since compromise of TSA may or may not=
 be=20
detected by the nextUpdate.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In summary, ther=
e will=20
be situations when TSA is compromised, some of the time stamps will come un=
der=20
dispute and that dispute will need to be resolved using other=20
evidence.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">This also points=
 to the=20
value of having invalidity date in CRL for TSA entries.&nbsp; As long as tc=
 is=20
present in tr and tc &gt; t1, the time stamp will not come under=20
dispute.<o:p></o:p></SPAN></FONT></P>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT=20
face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SP=
AN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"=
>=20
owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] <B><SP=
AN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B><st1:PersonName w:st=3D=
"on">Carl=20
Wallace</st1:PersonName><BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPA=
N></B>=20
Tuesday, September 04, 2007 1:45 PM<BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Vittek Robert; <st1:PersonName=20
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName><BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: security issue in archi=
ve=20
timestamp chain?</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">=
There's no=20
need to safeguard the validation data for ATS1 at the time ATS2 is=20
applied.&nbsp; The validation data can be preserved independently of the da=
ta=20
and retrieved using SCVP/ERS.&nbsp; Amongst other benefits, this allows for=
 a=20
grace period to be applied between the time ATS2 was generated and the time=
 of=20
interest for validating the TSA1 credentials.&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT><o:p></o:p></P>
<P><FONT face=3D"Times New Roman" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">=
&gt;=20
-----Original Message-----</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; From: owner-ietf-ltans@mail.imc.org=20
</SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; [<A=20
href=3D"mailto:owner-ietf-ltans@mail.imc.org">mailto:owner-ietf-ltans@mail.=
imc.org</A>]=20
On Behalf Of Vittek Robert</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; Sent: Tuesday, September 04, 2007 1:23=20
PM</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; To=
:=20
<st1:PersonName w:st=3D"on">ietf-ltans@imc.org</st1:PersonName></SPAN></FON=
T>=20
<BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; Subject: security i=
ssue in=20
archive timestamp chain?</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; We are currently implementing a long term=20
electronic </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt"=
>&gt;=20
signature based on XAdES, so I went through TS 101 903, TS=20
</SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; 101 7=
33 and=20
other RFCs that led me finaly to LTANS group </SPAN></FONT><BR><FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; because XAdES does not addres=
s the=20
problem of validation of </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; TSA certificates ("Rules for acceptance of t=
he=20
validity of </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt=
">&gt;=20
the signature within the time-stamp, involving trust </SPAN></FONT><BR><FON=
T=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; decisions, are out of the sco=
pe of the=20
present document.").</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; I am interested in solving the following=20
problem.</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&=
gt;=20
</SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; <A=20
href=3D"http://tools.ietf.org/html/rfc4998#section-5.3"=20
target=3D_blank>http://tools.ietf.org/html/rfc4998#section-5.3</A> states t=
hat:=20
</SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; Each =
Archive=20
Timestamp MUST be valid relative to the time of </SPAN></FONT><BR><FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; the following Archive=20
Timestamp.</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt"=
>&gt;=20
</SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; Let's=
 assume=20
that we have Archive Time-Stamp 1 (ATS1) and we </SPAN></FONT><BR><FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; need to renew it and safeguar=
d the=20
validation data for ATS1 </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; at the same time. But the next Archive Time-=
Stamp 2=20
(ATS2) </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt=
; can=20
prove existence only of the CRLs issued before time T2 </SPAN></FONT><BR><F=
ONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; (from ATS2). ATS2 does NOT gi=
ve any=20
evidence that there was </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; not another CRL2 (issued by CA that issued T=
SA1=20
certificate) </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10p=
t">&gt;=20
which contained information on revocation of TSA1 certificate.</SPAN></FONT=
>=20
<BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><=
FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; I think that arbitration on v=
alidity=20
of ATS1 might take place </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; long after the archive of relevant CRLs is=20
available and long </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; after the used cryptography is strong enough=
, so=20
the attacker </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10p=
t">&gt;=20
might produce such CRL2 himself just to cast doubt upon the=20
</SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; archi=
ved=20
data.</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt;=
=20
</SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; In ot=
her=20
words: while T2 - safeguardedCRLforTSA1.thisUpdate &gt; </SPAN></FONT><BR><=
FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; 0, arbitrator can not be sure=
 that=20
there was not another CRL2 </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; that listed TSA1 certificate.</SPAN></FONT>=
=20
<BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><=
FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; Am I missing something or is =
it a=20
security issue?</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; Mgr. Robert Vittek</SPAN></FONT> <BR><FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=
=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; DITEC, a.s.</SPAN></FONT> <BR><FONT size=3D2=
><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; Bratislava Business Center V</SPAN></FONT>=20
<BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; Plyn=E1rensk=E1=20
7/C</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; 8=
21 09=20
<st1:place w:st=3D"on"><st1:City=20
w:st=3D"on">Bratislava</st1:City></st1:place></SPAN></FONT> <BR><FONT size=
=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">&gt; voice: +421 2 58 222 487</SPAN></FONT> <BR><=
FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; fax: +421 2 58 222 777</SPAN>=
</FONT>=20
<BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; cell: +421 908 797=
=20
827</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; <=
A=20
href=3D"mailto:vittek@ditec.sk">mailto:vittek@ditec.sk</A></SPAN></FONT> <B=
R><FONT=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt;=20
</SPAN></FONT><o:p></o:p></P></DIV></BODY></HTML>

--_000_E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF7430mailintradite_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l86JULtC082540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2007 12:30:21 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l86JULsn082538; Thu, 6 Sep 2007 12:30:21 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l86JUJmf082521 for <ietf-ltans@imc.org>; Thu, 6 Sep 2007 12:30:20 -0700 (MST) (envelope-from tglassey@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=CA4GOjPE34kgv2s5KKlY7nfBG4m2Es+xotqF+TgJ0QbEc9eNiBfB319NnBZjqopW; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1ITN35-00047P-9c; Thu, 06 Sep 2007 15:29:55 -0400
Message-ID: <009d01c7f0bc$4ed44300$174f7d40@home.glassey.com>
From: "todd glassey" <tglassey@earthlink.net>
To: "Tobias Gondrom" <tgondrom@opentext.com>, "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>, "Carl Wallace" <CWallace@cygnacom.com>
Cc: <ietf-ltans@imc.org>
References: <2666EB2A846BAC4BB2D7F593301A78680187F4D4@MUCXGC2.opentext.net>
Subject: Re: draft-ietf-ltans-dssc-00 comments
Date: Thu, 6 Sep 2007 10:55:58 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec795e46a2deb443e6f86f719ae0caddf383350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Tobias - good response. As it happens, I want to disagree with parts of the 
post and document why I disagree, so that's inline below...

Todd
----- Original Message ----- 
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "todd glassey" <tglassey@earthlink.net>; "Thomas Kunz" 
<thomas.kunz@sit.fraunhofer.de>; "Carl Wallace" <CWallace@cygnacom.com>
Cc: <ietf-ltans@imc.org>
Sent: Thursday, September 06, 2007 9:04 AM
Subject: RE: draft-ietf-ltans-dssc-00 comments


Hi Thomas, Susanne, Todd, Carl and all,

Maybe a few thoughts about the discussed items:

Starting with the simple things:
I agree with Carls assessment that for the verification the critical
information is the policy stating which algorithms had been valid from
date a to date b. Period.

TSG: OK... we need to document whether this is a single system or a 
distributed one, so POLICY and its Expiry can be managed properly. If its a 
single system and there is no need to communicate legacy policy status, then 
that's cool. If its a stand-alone trust model where the document carries 
everything needed to process it and validate it under the LTANS framework, 
then its an issue.

I understand your idea of providing older policies to support the fact
that an archive service did operate correctly, but this is not the main
reason for the policy in the verification process.

TSG: It may not from a technical standpoint be needed at all, but this is 
about LAW AND THE RULE OF LAW, and the technology MUST (and I do mean "MUST" 
in caps) meet those needs or its use will be banned... or just ignored 
meaning that this work is for naught either way unless we are real clear 
what LTANS use requires and what it provides at the individual document 
level.

TSG: That said the use model is key to this whole bigger picture. And if the 
use model template is such that 'any document must be verifable forever with 
what it carries internally to it from the LTANS framework, then LTANS MUST 
also carry the legal policy for review as well. Especially in any document's 
where the original signing policy is changed or expired. This is simple 
Evidence 101... and while its offensive to many of us as being 
technologically 'wasted overhead', it satisfies real world law and process 
models that exist today.

TSG: As to why we need to understand the Law requirements behind long-term 
document storage is somewhat based in numerous attempts in previous 
technologoies from this very IETF to force social changes to existing 
processes by claiming that technology wont support those specific use 
models.

TSG: In continuing down that rat hole, the argument that we as technologists 
can change the world by lying to people about 'what is and is not 
technologically possible' is a black-eye on the Technology Industries since 
so many know its pure hog-wash and that anything - any process or ceremony 
in the real world, can be directly reduced to "a dance that is performed 
between  parties across a network" - i.e. some protocol.

TSG: That said LTANS should directly also meet legal framework use models 
100% from the gate  and not be 'yet another disappointing' IETF effort which 
intentionally seeks to 'force change' into the World, rather than just 
implementing the processes as they are committed in the real-world today.

The main use for the policy is that any verification party can use it
and check an ERS or other signatures whether any of the used algorithms
had been broken before they were renewed. (this is a precise
mathematical test, and does not automatically imply careless handling of
the archive system).

TSG: FWIW - The verifying party would actually be the "relying party" in 
most instances. As to the precision of the test, I agree its binary but it 
may not be relevant to that document if I can show that the document was 
unaltered from the time it was initially stored or 'timestamped'.

For the verification party only this hard facts count: Has the signature
been renewed in time or not, defined by the current policy.

TSG: Uhhhh - no. In any commercial process which is constrained under a 
'standard of care', that standard of care is the test. So the actual 
breaking of MD5 for instance is irrelevant in the bigger picture of whether 
my internal-only MD5 hashes are valid or not. The same is true for many 
other crypto functions.

(the old policies may indicate a wrong-doing of the archive system or
justify its actions but they must not influence the evaluation of
"valid"/"not-valid".

TSG: In order for that to work, there also needs to be a periodic process 
which scans all documents indexed in the system to determine whether their 
signature is still valid and for how long.

(comment: and if it happens that the policy issuing authority
retrospectively shortens the timespan of an algorithm, this will be for
a reason which should not be ignored.)

TSG: One perhaps like 'that the Underwriter's commercial coverage of that 
document's content' has expired or has been set aside for some reason?


Concerning the issuing of the policy: I think that to prove its
authenticity and integrity it should be sufficient to sign it (via CMS)
by the authority (e.g. NIST, German Bundesnetzagentur, ...)


I can not see any real problematic legal inter-country related
implications.

TSG: I do... I see them all over... including that to legally pass documents 
across from the EU to the US there will have to be time used in concert with 
National Law and technically competent sources. This is a VERY serious 
failing of RFC3161 and needs to be brought into the picture so that 3161 is 
updated or set aside.

A signature must be valid in the country where it is presented to the
court.
Which includes the renewal done with ERS must be so as well.

TSG: You may want to read Judge Grimm's ruling from Lorraine v Markel then 
from May 4th 2007... since it directly effects this WG's operations since it 
now constrains the types of Digital Content the US District Court's can 
accept as evidence of anything.

In court the judge will call upon the guidance of the countries security
authority (in case of US this would be NIST) to decide whether
algorithms are secure or have been broken and when.

TSG: Uh no they wont... And this is one of the key things that we choked on. 
The Court's have already set standards and the Industry has forensic audit 
models in place as well (as an Auditor I assure you this is auditing 
commentary is 100%  accurate). What the Court's will rule on in Evidentiary 
hearings is whether the five key tests under the Federal Rules of Evidence 
were met. The laboratory or National Crypto Authority isnt likely to ever 
say anything in Court unless they themselves are sued or prosecuted.


If these authorities
publish this statement in the form of a signed policy, this would be a
clear and reliable statement. (today they publish this in unsigned pdf
and on paper)

TSG: I propose the change of the term 'would' for 'should' since it is the 
individual judges until national standards are set who make these decisions.

Dito in other countries.
(obviously as these judgements of algorithms can vary between countries,
an archiving service would have the duty to watch carefully for
algorithm lifetime announcements the local national bodies corresponding
to its stored documents make)

TSG: Where in this requirement documented in any of the LTANS papers to 
date?

Best regards, Tobias




> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org
[mailto:owner-ietf-ltans@mail.imc.org]
> On Behalf Of todd glassey
> Sent: Tuesday, September 04, 2007 5:11 PM
> To: Thomas Kunz; Carl Wallace
> Cc: ietf-ltans@imc.org
> Subject: Re: draft-ietf-ltans-dssc-00 comments
>
>
> Thomas - vie gehts? I wanted to disagree to some extent and talk about
> this
> specific use model...
>
> The reality of the matter is that a full chain-of-management headers
MUST
> be
> included with each document showing any changes in the policies or
keys
> used
> to demonstrate the integrity of the document controlled with LTANS...
>
> More below.
>
> ----- Original Message -----
> From: "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>
> To: "Carl Wallace" <CWallace@cygnacom.com>
> Cc: <ietf-ltans@imc.org>
> Sent: Monday, September 03, 2007 4:18 PM
> Subject: Re: draft-ietf-ltans-dssc-00 comments
>
>
> > Carl Wallace schrieb:
> >> <snip>
> >>>> - The assumption in Section 3.2 that one must find an old policy
in
> >>>> order to determine if an algorithm was valid at a point in
> >>> the past is
> >>>> too complicated.  Suitability definitions should accumulate in a
> single
> >>>> policy definition.  An enterprise could maintain several
policies.
> For
> >>>> example, one complete, one current and one
> >>> past policy could be maintained.
> >>> In our notion, the policies are published by specific institutions
> (e.g.
> >>> annually) and one policy represents the evaluations based on
current
> >>> knowledge (e.g. on current findings, RSA with 1024 bit key length
> could
> >>> be valid until end of 2007, but next year a new policy could be
> >>> published which states that RSA 1024 is valid until end of 2008).
> >>> To expect, that a policy also contains all past evaluations of an
> >>> algorithms could be error-prone.
> >>> In our opinion, the question, if the evaluation of an algorithm in
an
> >>> old policy is different from that in the current policy is
primarily
> >>> important in law cases. And there you cannot trust, that the
current
> >>> policy correctly quotes past evaluations, instead you will have to
> look
> >>> in the old policy.
> >>
> >> I wasn't suggesting that a policy contain all past evaluations.
>
> I Was - the policy header needs to for legal reasons track the
document
> and
> its original content/signing as well as any changes made to that
document
> allong the way including any instances where policies changed or just
> expired. All of these MUST be a part of the Long Term Management
> structures
> that any and all documents are controlled by or a full chain of
custody
> will
> not be demonsterable and the outcome of the LTANS system will be
'hear-
> say'
> based on the Federal Rules of Evidence, the Federal Rules of Civil
> Procedure, and a ruling of the District Court of Maryland in the US
> Federal
> District Courts called Lorraine v Markel from May 4th 2007.
>
> >> I was
> >> suggesting that the current policy would contain the current
position
> >> with
> >> regard to an algorithm's life span, even if the algorithm is no
longer
> >> viable, and that's the only thing that matters.  I don't see the
value
> in
> >> referring to an old policy since the position on an algorithm can
> change
> >> over time.  Using your example, in my opinion, the only thing that
> >> matters
> >> to the verifier is what the current position is with regard to an
> >> algorithm.
> >> The fact that an algorithm's expected life span at the time a
signature
> >> was
> >> generated was thought to be shorter than it turned out to be isn't
> >> important.
> > OK, I agree. Since our data structures allow this anyway, we will
> > recommend for an easy policy handling that a policy should also
contain
> > the evaluations of all algorithms which are no longer valid. But
it's up
> > to the publisher to decide to do so.
> >
> > But never the less, in our opinion there is at least one case for
> > consulting old policies:
>
> You mean the period's around "the time when all instances of
old-policy
> reliance are flushed out"... i.e. that period of overlap when due to
other
> policies, the relying parties do not refresh their operating integrity
> entitlement....
>
> I dont think that this is a valid use. Its possible if a number of
other
> policies are broken but the LTANS operator must be ready to address
that
> certain signatures or policies may become invalid based on their
> technologies being cracked at a level which creates a real and
palpable
> risk
> or they just expire based on their exceeding their timebase lives.
>
> > Assume the current (2007) policy states that RSA 1024 is valid until
end
> > of 2008. Because of this policy, an archive service today doesn't
renew
> > signatures created with RSA 1024.
>
> Uh - then the Operator has a problem I think and their integrity of
> operations model is broken based on the first instance when something
that
> they relied on was made retroactively invalid. LTANS must have a
> restamping
> process built into it to address changes in document policy and access
> controls as well as regeneration events around accessing the document
or
> demonstrating its integrity.
>
> > Next year (2008), a new policy will be published which retroactively
> > repositions the validity of RSA 1024: The new policy states that RSA
> 1024
> > has only been valid until mid of 2007.
>
>
> This is a SEVERE problem. NO policy control model should have a hole
this
> big in it. There is NO reason to 'after the fact' re-stamp documents
as no
> longer being valid after a certain time frame unless there was a
> technological hack and there is a very good probability (not just a
> possibility) that those documents are either altered or are fakes.
>
> Remeber that these are documents stored for historical purposes and
that
> in
> the instance of a policy or a key, that the object isnt good anymore
is
> irrelevant to whether the key was good when the document was stored,
and
> to
> whether functionally is capable of being used whether its valid or not
> based
> on some time-specific expiry.
>
> > That means, in 2007 RSA 1024 signatures could have been forged and
> > therefore the archive service should have done the renewal already
in
> > 2007.
>
> Mechanically yes, but in reality no... those signatures are controlled
by
> a
> number of external and internal processes which (while possible) will
make
> it very very unlikely that those signatures were forged.
>
> > Now in 2008 the archive service must attest that he acted correctly
and
> > that he fulfilled his duty to take care although he has not timely
> renewed
> > the RSA 1024 signatures.
>
> The failure of the timely renewall of the RSA 1024 Bit signatures FOR
ANY
> REASON invalidates that operator's status as being a competent
operator
> one
> would think.
>
> > And therefore he needs the old (2007) policy which says that
according
> to
> > the knowledge at that time, the algorithm was valid and he acted
> > correctly. He cannot use the current (2008) policy because this
policy
> > states that the algorithm has only been valid until mid 2007.
>
> So this isnt an issue about policy expiry, its a use model issue...
this
> is
> WHY a formal set of use models MUST be drafted for this type of thing.
It
> also might help to have someone with any real-world audit
responsibility
> on
> this panel because its pretty clear that this is a panel of
technologists
> building what they through public argument are negotiating that the
> Auditor's need and its yet another instance where the IETF built
> technology
> for solving a problem it wasnt on-track "as to what the actual problem
> is".
>
> See what I mean?
>
> T
>
>
> >
> >
> > Regards
> > Thomas
> >
> >
> >



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l86G7sb6062315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2007 09:07:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l86G7sS4062314; Thu, 6 Sep 2007 09:07:54 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l86G7q2c062305 for <ietf-ltans@imc.org>; Thu, 6 Sep 2007 09:07:53 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l86G7pP9003391; Thu, 6 Sep 2007 18:07:52 +0200 (MEST)
Received: from MUCXGC2.opentext.net (mucxg01.opentext.net [149.235.128.135]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id l86G7pHM005302; Thu, 6 Sep 2007 12:07:51 -0400 (envelope-from tgondrom@opentext.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: draft-ietf-ltans-dssc-00 comments --constraints--
Date: Thu, 6 Sep 2007 18:07:50 +0200
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0046_01C7F0B0.D517DE10"
Message-ID: <2666EB2A846BAC4BB2D7F593301A78680187F4D6@MUCXGC2.opentext.net>
In-Reply-To: <1188901738.5727.39.camel@pc-arwen>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-ltans-dssc-00 comments --constraints--
Thread-Index: Acfu38rNKtwqOBOpSyyC2LxXh4kTYgBv/Q6w
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Susanne Okunick" <susanne.okunick@sit.fraunhofer.de>
Cc: <ietf-ltans@imc.org>
X-Archived: msg.B32vR9J:2007-09-06:mucpm02.smtp.dmz.opentext.com
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

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

Hello Susanne,=20

yes, I think it should be sufficient to give an example of current
constraints in the draft.=20
We could also define an OID e.g. to define specific constraints:=20
OID for "larger key is always more secure than less"

What other constraints do you have in mind?

Tobias



> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org =
[mailto:owner-ietf-ltans@mail.imc.org]
> On Behalf Of Susanne Okunick
> Sent: Tuesday, September 04, 2007 12:29 PM
> To: ietf-ltans@imc.org
> Subject: draft-ietf-ltans-dssc-00 comments --constraints--
>=20
> Hello,
>=20
> for now we could define current constraints for public key algorithm =
and
> give a guidance how to process/interprete them. A guidance may be: a
> modulus (for RSA) greater than 1024 is as suitable as the modulus 1024
> itself.
>=20
> But what about algorithms that are unknown till now? If an algorithm
> occurs as recently as in the future someone else has to define the new
> constraints, e. g. the publisher of a policy, expert committees or =
even
> a new RFC.
>=20
> Advantage for giving a definition: On the basis of the draft the
> operator/user is directly able to write/interpret a policy. But: =
Perhaps
> it suffices only to give an example for current contraints in this
> draft.
>=20
> What do you think about this problem?
>=20
> Best regards
> Susanne Okunick
>=20
> --
> ___________________________________________________________
>=20
> Dipl.-Math.(FH) Susanne Okunick
> Fraunhofer Institute for Secure Information Technology
> Department Transaction and Document Security
> Rheinstra=DFe 75, 64295 Darmstadt, Germany
> phone ++49 / (0)6151 869 60005, fax ++49 / (0)6151 869 322
> homepage: http://www.sit.fraunhofer.de
> ___________________________________________________________

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwzCCBhow
ggQCoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZh
cmlhMQ8wDQYDVQQHEwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5
MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20u
b3JnMB4XDTA2MTEwMzAwMjA0OFoXDTA5MDczMDAwMjA0OFowgZExCzAJBgNVBAYTAkRFMRAwDgYD
VQQIEwdCYXZhcmlhMR4wHAYDVQQKExVPcGVuIFRleHQgQ29ycG9yYXRpb24xETAPBgNVBAsTCFNl
Y3VyaXR5MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEkMCIGCSqGSIb3DQEJARYVdGdvbmRyb21A
b3BlbnRleHQuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4dYGy7tHBES4+h3Z
NS3dQi4TFm0TE84vyqzWPIwPZHpP927sRb3jh5PD7WChVPcb4KG8P4q2c+bJ+EVdaRv1Uvw57n3n
uhAbXtb7kcnFPIMfYn92GOBZpHoDCgT8DRYuQHvScH8l4W9WDtc2NHLkIldIBybxHLVdXX3QJsk3
/OFmJ9shKangwS+AT25cgGj5Ltu9iB2CFCrIKn5CCWDvObwoxEsYPj84Z3ygKUEOijNfkISuKiby
/xLIfjDPozpWdb2rb0Oi9pYJkjuzmzF5qwHZDFySeJoVKMIHi4n956m7Etahow+7hQk57+XwQyIL
l+s62FlMzsyMCZZ6MlpTs+OrymeobB44ttUn6F370N9GNXg/eV388IYA8e9Mui5F459mrM/9ub9T
fQmqoW+SdF4AvBi7BOWTHRJ/DrAWeBcw+9UeX3bWgX6cLNNv+SlNSKSiGV+syf5tqD4APvgfIY0a
PPmRLsbUy1Urwfe+BjqOLXZe6w+4WFbbKbAdltpUQCK04eA+g5tIT1ZT8zOxH+EvlJFSoV+i4btp
Y7Ni2AfJLvf9OdgwoOJBp3gXQL4o5VWzd362GHYjj94X0sqlJf8Ggcdxz4BR4/EsFRt6MQPXrfoi
wPBku/q08YwXPe1hvaW4k8MVosddaka88UY8LJrtXkZWXRERyPMH+cIJNw0CAwEAAaN7MHkwCQYD
VR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD
VR0OBBYEFDwj2KwaDOuWxUz/MiFFnt7sOYVoMB8GA1UdIwQYMBaAFH1WtHxZxnLGHnuMc6Pu+Gv9
BD5CMA0GCSqGSIb3DQEBBQUAA4ICAQCne6u3Ko8FefZSDqOq8pKEYAKbuV5NoGZqImoamelDm1Yd
6GQzacZF1aJyfHEytazk2GqmcGGB/yrqaFeQopiSTqGGnB7/8fgYMAUlv+S4NHJoohAVZC/onG0W
PDtWKnOyARntV2UxWIikKZZaYKlinvAwaBnmguqboWgbKBpYiV1+U7TgHlYdd9W25k1D+0n+E1mN
GvqEfPFxRHEiFdLxWuTtSZnvLDAihAEcTlcKOKGz5RIMHPxG4OcVz+acGKEi8WBHQRVx7KKUkLOy
SprjUpxSnEi1AbOEK2y0T/Bao3UkkxQiqKC67OUK0GPbvwat18GLmvesHArtTI8SVty63qdEmxnB
CKYLuSOJbXBe5SFPrcruMvumiA4QPdcGMyTiLqDtn97QcN+F5HfB93mKFZfqZwOqi86R6jgzFd3J
HsujJXDpZ0tIFRcDespNBcUIV+A38JxHsxF7xHw5wVQMEEsMceMjqEB3X58yAssNnXKD0E7WjIoO
SxlnODM++6xTBOIFB3N34ENNuj2Ck8196DUOei/YBEmI5oLIlXEKU/lHiDrq1D9TsjO7vhYoG+wC
vAFpGAicl25AGhaOTVeXKh+pTvHHlYva62Stww8eB/fHOW6VASWiUddE4OoxZfQiRkpn91K0rJc4
WHsP9HsBVEdA8xrfN36UXb3SXURnRzCCBqEwggSJoAMCAQICCQCamHOHv2sJlzANBgkqhkiG9w0B
AQUFADCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQ
MA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25k
cm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwHhcNMDYxMTAzMDAxMzMxWhcN
MDkwNzMwMDAxMzMxWjCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcT
Bk11bmljaDEQMA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRv
YmlhcyBHb25kcm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDRNLo77UVeV/wQ+ml3Nb5XWzkYT4Q8zo7Sl7CkuCT7UE9g
v8oFNJbzedTDn//SHkUKQJ3RpZf5VP/8gHvcFUVoiZjCMXYCsjlSJppouau3F0ED2wOle+nE9suX
lOuZVSsyuFSF89Yff8oD+wzHWi/9naeHrgKMVeqKa0Pcu1+tJ/zAoeeZHXlxHAuLQbF8XY2RGG0l
qSYXBwPuGqSVS9OKUP5kxLm+1Cd928h7PhwKJv9JP34YOWaQmxGL6KjkVnTacKpXPbhtqgtNsHC2
QWkmyyBAS8so5qAfIdOnlRi+U0hgwAKBiAF9OQh9g+xPoqLRmb81+Q18zjPDiIQ+KhwXfJeftUZp
fRy8k3thtOnkTqfKHTTaM+KaWR1bRY9DKR5u+zd/6qZ3/snVqBCNAKM0hktcSt7zQUcDo+1RsdW7
H8uJp/avtmYrmt21+Fy5+sN23sGWKNI/E3agPlTr0/jALm17ZomMP7/J4FUHsrxt5Sh6d1bWlxcR
xRIhU/8JU0BqbRSW1EKeBpzGnUJ3O65wHfyMrXi5aHG2gGXXoo2AiVTEUZylMsYxTCotEeZijfQN
zDH6oCvzePh4LF/Qo9u7T16Ovu3tRhOPQGfWltwC9gs+eJn4j7T2HJSEzVNZ3XTStzu8i/yKCcQZ
xWYy0j7ZXKZBSUmPyzuviSOvaU/K+QIDAQABo4H5MIH2MB0GA1UdDgQWBBR9VrR8WcZyxh57jHOj
7vhr/QQ+QjCBxgYDVR0jBIG+MIG7gBR9VrR8WcZyxh57jHOj7vhr/QQ+QqGBl6SBlDCBkTELMAkG
A1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQMA4GA1UEChMHR29u
ZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25kcm9tMSEwHwYJKoZI
hvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmeCCQCamHOHv2sJlzAMBgNVHRMEBTADAQH/MA0GCSqG
SIb3DQEBBQUAA4ICAQAmu3wb0JFEPQLfb9PLVEfSldtE9sLdEM4dpiJe1XqvgiI3pQI/lBzKbqcR
vg4fdP7muS3tcsqrI31L14+YzphrTLTWev86JdR23ir2oJCqrsHupuqYHI0egTRshejcTjnlBlmk
OSfxidjl+7RYjFAquFQEqHPEBb4Tcf6jXFbKzSLp/TcVG9a9x05C8wEJjDbINWxxb4EwjanKcMbh
ZNS8Vm0x4IwJhOYwkhx980WXruCoMKec9LwrPkAO/H/ZcpW2gR174oayrNXDYZIZ4nVU248jB52R
rrZxCt6/TbC8ftMzcafOLxP933RWtnf79qJbZLV9YspUEzQbuPbrb4nNuK/ZdOgJ9rNtLgZKqoa2
l5j9pNW4+yAh10s2+ZAUOlPv5wICK5gIGJo1Lj1P6cNOp3Yh03mudwM4XhQYyRCg2GbUIj0xXv/e
NkYfMGA5ljKmt9qnJ3qZKwgiFwMs2+nMfLDh6GuheAaCaWewHFMcgSoMYHNc43osufcygnKno3Eq
Fn8sn9YWM7X5vCuFK7+TGoJRVzVuwmzDqSG3l908auEKLetv03frw5v9cCB0ttExvsITo60lkuK3
Vy4CBDvE2U6BvuEr682hIUirV/X6oVORu3h44fTm1t5aibqwdWI3EpENwg9956Qpbo7uATZtQeWp
J6lsIPBAfc6YE6crOTGCBOEwggTdAgEBMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2
YXJpYTEPMA0GA1UEBxMGTXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0
eTEXMBUGA1UEAxMOVG9iaWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9t
Lm9yZwIBATAJBgUrDgMCGgUAoIICHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wNzA5MDYxNjA3NDhaMCMGCSqGSIb3DQEJBDEWBBRRA23A78/ngNfssSRdKUqzR/S1
pjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D
AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB
BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG
TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i
aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI
hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH
EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U
b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG
SIb3DQEBAQUABIICAIWRWTQgTfQbaTaRxeWVQ7EXnHoqBmtZpulT01G3egLa4gwynjvf2u3KXM9V
bZo9/+jXF2nTcV9bHtuuD7U98bH7z57ADqzsSY6Y2zAgqmtQoQZZbxiHpIYWoEh6xsIPNBMa5IbU
/75aUlp+5D9mjr02g6LDVrvOFHBoupYSsBODGN9vpeYtvMLYu6kBKaVpdm5cBw0/5NFJaxDu4x8p
/BqrGQMUMb5O9N/BYpsGa84HtewuNw1IFz9SmxE7lq/7S4EKadBPQwMxmtgMPEzeVydjsQPp1NYH
AAjE327vJda/lIZ7X3b2p4G2K9W43IJpFF2KXB/nlXtNKiJBWAiOcbnpzIYtKmGhcYUghxv4hlpY
sv1a/o5aQrPdlhZC5dJZ6HsYIVVseI7wtmc3BSm8YnUjnlu4/829AOuhDRvBX0dQ3l+jKRmvF6Yq
gJ6puT3eXOg48vLOBKaRSBFssCuejboPncRf06/qDGuuJJf5ivY2uqU1Ou5wp6eox+TsKMurRTot
ohmQMfyRe+4lCpUaCIW8SMuwN6/U5CyjcabnWqIHl6Nu8W0lBwtpm/gN3nXWjOK01ZB3XICezAvI
4N7Bdg0Zrn7MMgqLaSF43mY8QS9a9LYXkZ4fT6pmyvXHvxwKBrCdSgwSdYhO7EJcTBA1+fPBBIxP
1jGk1TLMBdRiOevIAAAAAAAA

------=_NextPart_000_0046_01C7F0B0.D517DE10--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l86G4a2b061931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2007 09:04:36 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l86G4awt061930; Thu, 6 Sep 2007 09:04:36 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l86G4WqI061915 for <ietf-ltans@imc.org>; Thu, 6 Sep 2007 09:04:33 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id l86G4OBX003255; Thu, 6 Sep 2007 18:04:25 +0200 (MEST)
Received: from MUCXGC2.opentext.net (mucxg01.opentext.net [149.235.128.135]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id l86G4NNc002513; Thu, 6 Sep 2007 12:04:23 -0400 (envelope-from tgondrom@opentext.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-ltans-dssc-00 comments
Date: Thu, 6 Sep 2007 18:04:22 +0200
Message-ID: <2666EB2A846BAC4BB2D7F593301A78680187F4D4@MUCXGC2.opentext.net>
In-Reply-To: <006d01c7ef05$de5c3bd0$174f7d40@home.glassey.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-ltans-dssc-00 comments
Thread-Index: AcfvBz07Y+hhTa19QkeupmUuPR8JQABlaLdg
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "todd glassey" <tglassey@earthlink.net>, "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>, "Carl Wallace" <CWallace@cygnacom.com>
Cc: <ietf-ltans@imc.org>
X-Archived: msg.BgR8NWE:2007-09-06:mucpm02.smtp.dmz.opentext.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l86G4XqI061917
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Hi Thomas, Susanne, Todd, Carl and all, 

Maybe a few thoughts about the discussed items: 

Starting with the simple things: 
I agree with Carls assessment that for the verification the critical
information is the policy stating which algorithms had been valid from
date a to date b. Period. 
I understand your idea of providing older policies to support the fact
that an archive service did operate correctly, but this is not the main
reason for the policy in the verification process. 
The main use for the policy is that any verification party can use it
and check an ERS or other signatures whether any of the used algorithms
had been broken before they were renewed. (this is a precise
mathematical test, and does not automatically imply careless handling of
the archive system). 
For the verification party only this hard facts count: Has the signature
been renewed in time or not, defined by the current policy. 
(the old policies may indicate a wrong-doing of the archive system or
justify its actions but they must not influence the evaluation of
"valid"/"not-valid". 

(comment: and if it happens that the policy issuing authority
retrospectively shortens the timespan of an algorithm, this will be for
a reason which should not be ignored.)


Concerning the issuing of the policy: I think that to prove its
authenticity and integrity it should be sufficient to sign it (via CMS)
by the authority (e.g. NIST, German Bundesnetzagentur, ...)


I can not see any real problematic legal inter-country related
implications. 
A signature must be valid in the country where it is presented to the
court. 
Which includes the renewal done with ERS must be so as well. 
In court the judge will call upon the guidance of the countries security
authority (in case of US this would be NIST) to decide whether
algorithms are secure or have been broken and when. If these authorities
publish this statement in the form of a signed policy, this would be a
clear and reliable statement. (today they publish this in unsigned pdf
and on paper)

Dito in other countries. 
(obviously as these judgements of algorithms can vary between countries,
an archiving service would have the duty to watch carefully for
algorithm lifetime announcements the local national bodies corresponding
to its stored documents make)

Best regards, Tobias




> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org
[mailto:owner-ietf-ltans@mail.imc.org]
> On Behalf Of todd glassey
> Sent: Tuesday, September 04, 2007 5:11 PM
> To: Thomas Kunz; Carl Wallace
> Cc: ietf-ltans@imc.org
> Subject: Re: draft-ietf-ltans-dssc-00 comments
> 
> 
> Thomas - vie gehts? I wanted to disagree to some extent and talk about
> this
> specific use model...
> 
> The reality of the matter is that a full chain-of-management headers
MUST
> be
> included with each document showing any changes in the policies or
keys
> used
> to demonstrate the integrity of the document controlled with LTANS...
> 
> More below.
> 
> ----- Original Message -----
> From: "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>
> To: "Carl Wallace" <CWallace@cygnacom.com>
> Cc: <ietf-ltans@imc.org>
> Sent: Monday, September 03, 2007 4:18 PM
> Subject: Re: draft-ietf-ltans-dssc-00 comments
> 
> 
> > Carl Wallace schrieb:
> >> <snip>
> >>>> - The assumption in Section 3.2 that one must find an old policy
in
> >>>> order to determine if an algorithm was valid at a point in
> >>> the past is
> >>>> too complicated.  Suitability definitions should accumulate in a
> single
> >>>> policy definition.  An enterprise could maintain several
policies.
> For
> >>>> example, one complete, one current and one
> >>> past policy could be maintained.
> >>> In our notion, the policies are published by specific institutions
> (e.g.
> >>> annually) and one policy represents the evaluations based on
current
> >>> knowledge (e.g. on current findings, RSA with 1024 bit key length
> could
> >>> be valid until end of 2007, but next year a new policy could be
> >>> published which states that RSA 1024 is valid until end of 2008).
> >>> To expect, that a policy also contains all past evaluations of an
> >>> algorithms could be error-prone.
> >>> In our opinion, the question, if the evaluation of an algorithm in
an
> >>> old policy is different from that in the current policy is
primarily
> >>> important in law cases. And there you cannot trust, that the
current
> >>> policy correctly quotes past evaluations, instead you will have to
> look
> >>> in the old policy.
> >>
> >> I wasn't suggesting that a policy contain all past evaluations.
> 
> I Was - the policy header needs to for legal reasons track the
document
> and
> its original content/signing as well as any changes made to that
document
> allong the way including any instances where policies changed or just
> expired. All of these MUST be a part of the Long Term Management
> structures
> that any and all documents are controlled by or a full chain of
custody
> will
> not be demonsterable and the outcome of the LTANS system will be
'hear-
> say'
> based on the Federal Rules of Evidence, the Federal Rules of Civil
> Procedure, and a ruling of the District Court of Maryland in the US
> Federal
> District Courts called Lorraine v Markel from May 4th 2007.
> 
> >> I was
> >> suggesting that the current policy would contain the current
position
> >> with
> >> regard to an algorithm's life span, even if the algorithm is no
longer
> >> viable, and that's the only thing that matters.  I don't see the
value
> in
> >> referring to an old policy since the position on an algorithm can
> change
> >> over time.  Using your example, in my opinion, the only thing that
> >> matters
> >> to the verifier is what the current position is with regard to an
> >> algorithm.
> >> The fact that an algorithm's expected life span at the time a
signature
> >> was
> >> generated was thought to be shorter than it turned out to be isn't
> >> important.
> > OK, I agree. Since our data structures allow this anyway, we will
> > recommend for an easy policy handling that a policy should also
contain
> > the evaluations of all algorithms which are no longer valid. But
it's up
> > to the publisher to decide to do so.
> >
> > But never the less, in our opinion there is at least one case for
> > consulting old policies:
> 
> You mean the period's around "the time when all instances of
old-policy
> reliance are flushed out"... i.e. that period of overlap when due to
other
> policies, the relying parties do not refresh their operating integrity
> entitlement....
> 
> I dont think that this is a valid use. Its possible if a number of
other
> policies are broken but the LTANS operator must be ready to address
that
> certain signatures or policies may become invalid based on their
> technologies being cracked at a level which creates a real and
palpable
> risk
> or they just expire based on their exceeding their timebase lives.
> 
> > Assume the current (2007) policy states that RSA 1024 is valid until
end
> > of 2008. Because of this policy, an archive service today doesn't
renew
> > signatures created with RSA 1024.
> 
> Uh - then the Operator has a problem I think and their integrity of
> operations model is broken based on the first instance when something
that
> they relied on was made retroactively invalid. LTANS must have a
> restamping
> process built into it to address changes in document policy and access
> controls as well as regeneration events around accessing the document
or
> demonstrating its integrity.
> 
> > Next year (2008), a new policy will be published which retroactively
> > repositions the validity of RSA 1024: The new policy states that RSA
> 1024
> > has only been valid until mid of 2007.
> 
> 
> This is a SEVERE problem. NO policy control model should have a hole
this
> big in it. There is NO reason to 'after the fact' re-stamp documents
as no
> longer being valid after a certain time frame unless there was a
> technological hack and there is a very good probability (not just a
> possibility) that those documents are either altered or are fakes.
> 
> Remeber that these are documents stored for historical purposes and
that
> in
> the instance of a policy or a key, that the object isnt good anymore
is
> irrelevant to whether the key was good when the document was stored,
and
> to
> whether functionally is capable of being used whether its valid or not
> based
> on some time-specific expiry.
> 
> > That means, in 2007 RSA 1024 signatures could have been forged and
> > therefore the archive service should have done the renewal already
in
> > 2007.
> 
> Mechanically yes, but in reality no... those signatures are controlled
by
> a
> number of external and internal processes which (while possible) will
make
> it very very unlikely that those signatures were forged.
> 
> > Now in 2008 the archive service must attest that he acted correctly
and
> > that he fulfilled his duty to take care although he has not timely
> renewed
> > the RSA 1024 signatures.
> 
> The failure of the timely renewall of the RSA 1024 Bit signatures FOR
ANY
> REASON invalidates that operator's status as being a competent
operator
> one
> would think.
> 
> > And therefore he needs the old (2007) policy which says that
according
> to
> > the knowledge at that time, the algorithm was valid and he acted
> > correctly. He cannot use the current (2008) policy because this
policy
> > states that the algorithm has only been valid until mid 2007.
> 
> So this isnt an issue about policy expiry, its a use model issue...
this
> is
> WHY a formal set of use models MUST be drafted for this type of thing.
It
> also might help to have someone with any real-world audit
responsibility
> on
> this panel because its pretty clear that this is a panel of
technologists
> building what they through public argument are negotiating that the
> Auditor's need and its yet another instance where the IETF built
> technology
> for solving a problem it wasnt on-track "as to what the actual problem
> is".
> 
> See what I mean?
> 
> T
> 
> 
> >
> >
> > Regards
> > Thomas
> >
> >
> >




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l869HHCo016055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2007 02:17:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l869HH7h016054; Thu, 6 Sep 2007 02:17:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l869HEtw016047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-ltans@imc.org>; Thu, 6 Sep 2007 02:17:15 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de)
Received: from [141.12.111.5] (vpnsit2_5.sit.fraunhofer.de [141.12.111.5]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id l869GmbK008009; Thu, 6 Sep 2007 11:16:48 +0200
Message-ID: <46DFC57A.9000509@sit.fraunhofer.de>
Date: Thu, 06 Sep 2007 11:16:42 +0200
From: Thomas Kunz <thomas.kunz@sit.fraunhofer.de>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Peter Sylvester <Peter.Sylvester@edelweb.fr>
CC: ietf-ltans@imc.org
Subject: Re: draft-ietf-ltans-dssc-00 comments
References: <886F5D4C78AFB14D87261206BFB9612E1D31D982@scygmxs1.cygnacom.com> <46DC965F.3040506@sit.fraunhofer.de> <46DD9104.9070401@edelweb.fr>
In-Reply-To: <46DD9104.9070401@edelweb.fr>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030401060604070600030504"
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a cryptographically signed message in MIME format.

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

Peter,

Peter Sylvester schrieb:

> But what is actually needed by a policy checker? it doesn't even
> know keylength or hash size or whatever else. It only has to
> know that  for each algorithm there are some values defined.
> 
> I think one should have an approach like in Mibs in SNMP so
> one would say (now in XML) something like
> 
>   <Algorithm Name="urifor RSA" Oid="xxx">
>     <param>1024</param>
>     <param>4096</param>
>   </Algorithm>
>
I'm not sure whether I understand your suggestion.

In your example above, you suggest to have simply a list of all 
currently valid key lengths?
But where do you have the validity periods of the particular values (key 
  lengths)?
A second problem I see is, that some algorithms are defined by more than 
one parameter (e.g. DSA: 'p' and 'q'). So in the XML encoding, you have 
to distinguish the different parameters (e.g. via its name).


> in a policy one would only specify value constraints parameters for an 
> actual algorithms,
> a kind of pattern which can always be checked, example
>   first parameter must be greater than  1023, second less than 8192 or 
> whatever.
 >
Do you mean to encode this pattern in XML? And for example such a 
pattern would say: 'If a value of 1024 is valid, every value greater 
than 1024 is also valid'?

In principle I agree with you. We are also discussing the problem which 
arises if new algorithms are added (see Susanne's mail which also 
addresses this topic).

Thomas


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCC
BacwggSPoAMCAQICAgDfMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK
EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB
IHYyMB4XDTA0MDYwOTA3MzQyM1oXDTA4MTIzMTIzMDAwMFowVzELMAkGA1UEBhMCREUxEzAR
BgNVBAoTCkZyYXVuaG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRQwEgYD
VQQDEwtUaG9tYXMgS3VuejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALFclK+E
n2p85uM4bbfxKqpHBUOd9qSCNnuPcITixktM7A1rRmbu1nbQcppKj40Bjv/rOqTavvux1oiS
O+mzrOq9Aa0MmjPyFpjcPOK62EaGFMNuHx7cafnLe4Y8EJcdl9RZdBO+SY/2gr5wq9/jvaaF
fkU0Q+5iY4NS2/nLZ2mYaqRI2wCxaLAMyfJYL4z5/qEW51KTQ0LHHm9qiVZg2hempXSMABC9
6/BzYKwaGMh0vaSCppUFdJvhVNwAUHsUkosNTFiU9ks2fIpzlNPJv7UE8wfTrCzAf4CBgWTA
jHXJdgaAF2rD0JjbbpA/G1w3rAT8yKy3mfljJOcLcuUZYBMCAwEAAaOCAoMwggJ/MIGeBglg
hkgBhvhCAQ0EgZAWgY1Tb2Z0d2FyZSBaZXJ0aWZpa2F0IGRlciBaZXJ0aWZpemllcnVuZ2lu
c3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNoZW47
IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wTQYIKwYB
BQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvRmhHLUNB
X3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9wa2kuZnJhdW5o
b2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwCQYDVR0TBAIwADBKBgNV
HRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIuZGWGGWh0dHA6Ly9w
a2kuZnJhdW5ob2Zlci5kZS8wKAYDVR0RBCEwH4EddGhvbWFzLmt1bnpAc2l0LmZyYXVuaG9m
ZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8v
cGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsG
AQUFBwMDBggrBgEFBQcDBDALBgNVHQ8EBAMCA/gwHQYDVR0OBBYEFAT5q7Rw9gTlubggX/wN
+6oZowK3MB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0GCSqGSIb3DQEBBQUA
A4IBAQDoyyNHTB3tv3kVsap2axcaFKsKwzTNqq/bnj+a6VFpy5ejBbtusHG8njqa+LheRT/k
Vi6xFYFXegw54Cf6IGCJ2E1EBWfgJXqyaO+PgUggd6bLOy/8fZauR1oIlt4nQNjoXyJxqV9x
tpgxZsF7pHtqcwh4ZYA+nsEC6DdCfsUqegrqzmtA7hZ34o3yeZCR5qs3M9jja3lw9KfxnbHh
6CM/vM7o6KIEFdx8RlIWpYEJB05rqMO7PrXiRrmJDHeCwRtx+R5iskUX3grhh6yHBRM1NKHx
LY/waDKxBj3ZXPSkN0k7PBppeuYHgJ4ZVAuvP9v2GKkyU3pHOcwE5iZOiQyNMIIFpzCCBI+g
AwIBAgICAN8wDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu
aG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjIwHhcN
MDQwNjA5MDczNDIzWhcNMDgxMjMxMjMwMDAwWjBXMQswCQYDVQQGEwJERTETMBEGA1UEChMK
RnJhdW5ob2ZlcjEMMAoGA1UECxMDU0lUMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1Ro
b21hcyBLdW56MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsVyUr4Sfanzm4zht
t/EqqkcFQ532pII2e49whOLGS0zsDWtGZu7WdtBymkqPjQGO/+s6pNq++7HWiJI76bOs6r0B
rQyaM/IWmNw84rrYRoYUw24fHtxp+ct7hjwQlx2X1Fl0E75Jj/aCvnCr3+O9poV+RTRD7mJj
g1Lb+ctnaZhqpEjbALFosAzJ8lgvjPn+oRbnUpNDQsceb2qJVmDaF6aldIwAEL3r8HNgrBoY
yHS9pIKmlQV0m+FU3ABQexSSiw1MWJT2SzZ8inOU08m/tQTzB9OsLMB/gIGBZMCMdcl2BoAX
asPQmNtukD8bXDesBPzIrLeZ+WMk5wty5RlgEwIDAQABo4ICgzCCAn8wgZ4GCWCGSAGG+EIB
DQSBkBaBjVNvZnR3YXJlIFplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5naW5zdGFueiAo
Q0EpIGRlciBGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVs
emVydGlmaWthdCB2aWEgaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlLzBNBggrBgEFBQcBAQRB
MD8wPQYIKwYBBQUHMAGGMWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0FfdjJfT0NT
UC1SZXNwb25kZXIwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL3BraS5mcmF1bmhvZmVyLmRl
L0ZoRy1DQS1DZXJ0cy9GaEctQ0FfdjJfQ1JMLmNybDAJBgNVHRMEAjAAMEoGA1UdEgRDMEGB
JHplcnRpZml6aWVydW5nc2luc3RhbnpAZnJhdW5ob2Zlci5kZYYZaHR0cDovL3BraS5mcmF1
bmhvZmVyLmRlLzAoBgNVHREEITAfgR10aG9tYXMua3VuekBzaXQuZnJhdW5ob2Zlci5kZTBM
BgNVHSAERTBDMEEGCysGAQQBhgpQAgEBMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly9wa2kuZnJh
dW5ob2Zlci5kZS9wb2xpY3kuaHRtbDAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMG
CCsGAQUFBwMEMAsGA1UdDwQEAwID+DAdBgNVHQ4EFgQUBPmrtHD2BOW5uCBf/A37qhmjArcw
HwYDVR0jBBgwFoAUAMP872PCVigvUQt1Vv97BekcyfEwDQYJKoZIhvcNAQEFBQADggEBAOjL
I0dMHe2/eRWxqnZrFxoUqwrDNM2qr9ueP5rpUWnLl6MFu26wcbyeOpr4uF5FP+RWLrEVgVd6
DDngJ/ogYInYTUQFZ+AlerJo74+BSCB3pss7L/x9lq5HWgiW3idA2OhfInGpX3G2mDFmwXuk
e2pzCHhlgD6ewQLoN0J+xSp6CurOa0DuFnfijfJ5kJHmqzcz2ONreXD0p/GdseHoIz+8zujo
ogQV3HxGUhalgQkHTmuow7s+teJGuYkMd4LBG3H5HmKyRRfeCuGHrIcFEzU0ofEtj/BoMrEG
Pdlc9KQ3STs8Gml65geAnhlUC68/2/YYqTJTekc5zATmJk6JDI0xggL/MIIC+wIBATBVME8x
CzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVy
LUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zAJBgUrDgMCGgUAoIIBfzAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA5MDYwOTE2NDJaMCMGCSqGSIb3
DQEJBDEWBBSlzhwC2mVupUDtDuIvMQDmJR1IQzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3
DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv
ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm
BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx
KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG
SIb3DQEBAQUABIIBAFIqvUUHysBSWqlnLpUMEfeItQu/JI+Kvx+6sjhnXmMzGShd9wizdKTY
iLelF4/b5gbyDgNIC+303f0QYgN/NfcNmTmWP2IQPRKiUmhvuWklTG40sh6ySl+1dOqWBeae
PTXWDrybyI+yg7+oo5aFmp1vel0xipar6KTIjxCkM/7ingVsDiliNAKGX3BQGui1Anll+/HI
iLAKl0hYZyz9HWTgzLwNfVscJsW4wInCEVkQbwzxPNK01uhGEjGke9IgI+7iwvHM7BiyLGxc
xOMRnqr0LX/7gAKQmgEAn3HRAyqL47xz1zH6azvhyzQeFdZMYU1RR2AYIg/7Q+6Q7CJ1jvcA
AAAAAAA=
--------------ms030401060604070600030504--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8500fmT029787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 17:00:41 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l8500fxt029786; Tue, 4 Sep 2007 17:00:41 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l8500deq029780 for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 17:00:40 -0700 (MST) (envelope-from tglassey@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=sdIago9in+sgJyWEbN1MPKpDYUhWlcnLzjSsNxJBpwV3/UuadgFlRfTtA9k8qBY+; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=gw) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1ISiJw-0003HA-Pg; Tue, 04 Sep 2007 20:00:37 -0400
Message-ID: <009b01c7ef4f$c9bf22b0$174f7d40@home.glassey.com>
From: "todd glassey" <tglassey@earthlink.net>
To: "todd glassey" <tglassey@earthlink.net>, "Santosh Chokhani" <chokhani@orionsec.com>, "Carl Wallace" <CWallace@cygnacom.com>, "Vittek Robert" <vittek@ditec.sk>, <ietf-ltans@imc.org>
References: <886F5D4C78AFB14D87261206BFB9612E1D31DC6C@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879090DD6DB@EXVS01.ex.dslextreme.net> <007f01c7ef4e$915f2dd0$174f7d40@home.glassey.com>
Subject: Re: security issue in archive timestamp chain?
Date: Tue, 4 Sep 2007 17:00:34 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01C7EF15.1C174FF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79ce2529a12aac90e17e0b70df309f868d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

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

RE: security issue in archive timestamp chain?oops typo below... sorry.

t
  ----- Original Message -----=20
  From: todd glassey=20
  To: Santosh Chokhani ; Carl Wallace ; Vittek Robert ; =
ietf-ltans@imc.org=20
  Sent: Tuesday, September 04, 2007 4:51 PM
  Subject: Re: security issue in archive timestamp chain?


  Santosh
    ----- Original Message -----=20
    From: Santosh Chokhani=20
    To: Carl Wallace ; Vittek Robert ; ietf-ltans@imc.org=20
    Sent: Tuesday, September 04, 2007 3:12 PM
    Subject: RE: security issue in archive timestamp chain?


    Carl,

    =20

    While what you say is correct, I do not think this answers the =
question Robert has.  Let us consider the following scenario

    =20

    Time t1 is the thisUpdate for a CRL used to verify the time stamp =
applied at time t2.

    =20

    Time t3 is when the time stamp is renewed.

    =20

    We know t3 > t2 > t1.

    =20

    Time tr is thisUpdate for a CRL when the TSA first appear as =
compromised.  tr > t1.

    =20

    Time tc is the actual time of compromise.  tr > tc

    =20

    As long as CRL for t1 is produced using ERS as Carl says, the =
claimant can prove the legitimacy of the time stamp.

    =20

    If CRL for tr is also produced, the time stamp can come under =
dispute.  If there is an invalidity date associated with the TSA entry =
and that date is past t2, the time stamp is legitimate.

    =20

    Note that checking revocation status of TSA at time t3 technically =
does not help since tr can come at any time, including after t3.

    =20

    Also, if one were to check the revocation status of TSA at time t3, =
legitimate time stamps that were applied prior to tc or tr may be =
rejected.  It is tc that is hard to deal with.  That is why we have =
humans and courts and other supporting evidence to ferret things out.



    =20

  I strongly suggest reviewing this =
http://www.lexisnexis.com/applieddiscovery/LawLibrary/whitePapers/ADI_WP_=
LorraineVMarkel.pdf or perhaps Surety's response there as well =
http://www.surety.com/images/whitepapers/Lorraine_v_Markel_Summary_Analys=
is.pdf - or any of the 100 or so other relevent Digital Evidence Links =
from  this Search=20

  =20

  =
http://www.google.com/search?q=3DJudge+Grimm+Lorraine+v+Markel&rls=3Dcom.=
microsoft:en-us:IE-SearchBox&ie=3DUTF-8&oe=3DUTF-8&sourceid=3Die7&rlz=3D1=
I7GGID

    =20

    =20

    =20

    I have not purposely included nextUpdate analysis in this since =
compromise of TSA may or may not be detected by the nextUpdate.

    =20

    In summary, there will be situations when TSA is compromised, some =
of the time stamps will come under dispute and that dispute will need to =
be resolved using other evidence.



  Then LTANS by itself is not=20



enough



  without a BCP for operating it or did I miss something in your =
response.

    =20

    This also points to the value of having invalidity date in CRL for =
TSA entries.  As long as tc is present in tr and tc > t1, the time stamp =
will not come under dispute.



  You mean the question of the cyptographic integrity of the timestamp =
process or its management may not come under fire... the timestamp =
itself will for the reasons I quoted, & I believe it to bevery likely =
inadmissible in a court of law, and as such worthless in anyones view =
without building those requirements into the LTANS process and protcol. =
That's the problem with technology - its controlled by a number of =
non-technical constraints which do effect the reality of its use whether =
we as technologists like it or not.



  t


-------------------------------------------------------------------------=
---

    From: owner-ietf-ltans@mail.imc.org =
[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace
    Sent: Tuesday, September 04, 2007 1:45 PM
    To: Vittek Robert; ietf-ltans@imc.org
    Subject: RE: security issue in archive timestamp chain?

    =20

    There's no need to safeguard the validation data for ATS1 at the =
time ATS2 is applied.  The validation data can be preserved =
independently of the data and retrieved using SCVP/ERS.  Amongst other =
benefits, this allows for a grace period to be applied between the time =
ATS2 was generated and the time of interest for validating the TSA1 =
credentials.   =20

    > -----Original Message-----=20
    > From: owner-ietf-ltans@mail.imc.org=20
    > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert=20
    > Sent: Tuesday, September 04, 2007 1:23 PM=20
    > To: ietf-ltans@imc.org=20
    > Subject: security issue in archive timestamp chain?=20
    >=20
    >=20
    > We are currently implementing a long term electronic=20
    > signature based on XAdES, so I went through TS 101 903, TS=20
    > 101 733 and other RFCs that led me finaly to LTANS group=20
    > because XAdES does not address the problem of validation of=20
    > TSA certificates ("Rules for acceptance of the validity of=20
    > the signature within the time-stamp, involving trust=20
    > decisions, are out of the scope of the present document.").=20
    >=20
    > I am interested in solving the following problem.=20
    >=20
    > http://tools.ietf.org/html/rfc4998#section-5.3 states that:=20
    > Each Archive Timestamp MUST be valid relative to the time of=20
    > the following Archive Timestamp.=20
    >=20
    > Let's assume that we have Archive Time-Stamp 1 (ATS1) and we=20
    > need to renew it and safeguard the validation data for ATS1=20
    > at the same time. But the next Archive Time-Stamp 2 (ATS2)=20
    > can prove existence only of the CRLs issued before time T2=20
    > (from ATS2). ATS2 does NOT give any evidence that there was=20
    > not another CRL2 (issued by CA that issued TSA1 certificate)=20
    > which contained information on revocation of TSA1 certificate.=20
    >=20
    > I think that arbitration on validity of ATS1 might take place=20
    > long after the archive of relevant CRLs is available and long=20
    > after the used cryptography is strong enough, so the attacker=20
    > might produce such CRL2 himself just to cast doubt upon the=20
    > archived data.=20
    >=20
    > In other words: while T2 - safeguardedCRLforTSA1.thisUpdate >=20
    > 0, arbitrator can not be sure that there was not another CRL2=20
    > that listed TSA1 certificate.=20
    >=20
    > Am I missing something or is it a security issue?=20
    >=20
    >=20
    > Mgr. Robert Vittek=20
    >=20
    > DITEC, a.s.=20
    > Bratislava Business Center V=20
    > Plyn=E1rensk=E1 7/C=20
    > 821 09 Bratislava=20
    >=20
    > voice: +421 2 58 222 487=20
    > fax: +421 2 58 222 777=20
    > cell: +421 908 797 827=20
    > mailto:vittek@ditec.sk=20
    >=20

------=_NextPart_000_0098_01C7EF15.1C174FF0
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" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>RE: security =
issue in archive timestamp chain?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" 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]--><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"City"></o:SmartTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"place"></o:SmartTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"PersonName"></o:SmartTagType><!--[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:blue;
	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 vLink=3Dblue link=3Dblue bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman" size=3D2>oops typo below... =
sorry.</FONT></DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman" size=3D2>t</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dtglassey@earthlink.net =
href=3D"mailto:tglassey@earthlink.net">todd=20
  glassey</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dchokhani@orionsec.com=20
  href=3D"mailto:chokhani@orionsec.com">Santosh Chokhani</A> ; <A=20
  title=3DCWallace@cygnacom.com =
href=3D"mailto:CWallace@cygnacom.com">Carl=20
  Wallace</A> ; <A title=3Dvittek@ditec.sk =
href=3D"mailto:vittek@ditec.sk">Vittek=20
  Robert</A> ; <A title=3Dietf-ltans@imc.org=20
  href=3D"mailto:ietf-ltans@imc.org">ietf-ltans@imc.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, September 04, =
2007 4:51=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: security issue in =
archive=20
  timestamp chain?</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3D"Times New Roman" size=3D2>Santosh</FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=3Dchokhani@orionsec.com =
href=3D"mailto:chokhani@orionsec.com">Santosh=20
    Chokhani</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3DCWallace@cygnacom.com=20
    href=3D"mailto:CWallace@cygnacom.com">Carl Wallace</A> ; <A=20
    title=3Dvittek@ditec.sk href=3D"mailto:vittek@ditec.sk">Vittek =
Robert</A> ; <A=20
    title=3Dietf-ltans@imc.org=20
    href=3D"mailto:ietf-ltans@imc.org">ietf-ltans@imc.org</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, September 04, =
2007 3:12=20
    PM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: security issue =
in archive=20
    timestamp chain?</DIV>
    <DIV><BR></DIV>
    <DIV class=3DSection1>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Carl,<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">While =
what you say=20
    is correct, I do not think this answers the question Robert =
has.&nbsp; Let=20
    us consider the following scenario<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Time t1 =
is the=20
    thisUpdate for a CRL used to verify the time stamp applied at time=20
    t2.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Time t3 =
is when the=20
    time stamp is renewed.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">We know =
t3 &gt; t2=20
    &gt; t1.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Time tr =
is=20
    thisUpdate for a CRL when the TSA first appear as compromised.&nbsp; =
tr &gt;=20
    t1.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Time tc =
is the=20
    actual time of compromise. &nbsp;tr &gt; =
tc<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As long =
as CRL for=20
    t1 is produced using ERS as Carl says, the claimant can prove the =
legitimacy=20
    of the time stamp.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">If CRL =
for tr is=20
    also produced, the time stamp can come under dispute. &nbsp;If there =
is an=20
    invalidity date associated with the TSA entry and that date is past =
t2, the=20
    time stamp is legitimate.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Note that =
checking=20
    revocation status of TSA at time t3 technically does not help since =
tr can=20
    come at any time, including after t3.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Also, if =
one were=20
    to check the revocation status of TSA at time t3, legitimate time =
stamps=20
    that were applied prior to tc or tr may be rejected. &nbsp;It is tc =
that is=20
    hard to deal with.&nbsp; That is why we have humans and courts and =
other=20
    supporting evidence to ferret things out.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P></DIV></BLOCKQUOTE>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>I =
strongly=20
  suggest reviewing this <A=20
  =
href=3D"http://www.lexisnexis.com/applieddiscovery/LawLibrary/whitePapers=
/ADI_WP_LorraineVMarkel.pdf">http://www.lexisnexis.com/applieddiscovery/L=
awLibrary/whitePapers/ADI_WP_LorraineVMarkel.pdf</A>&nbsp;or=20
  perhaps Surety's response there as well <A=20
  =
href=3D"http://www.surety.com/images/whitepapers/Lorraine_v_Markel_Summar=
y_Analysis.pdf">http://www.surety.com/images/whitepapers/Lorraine_v_Marke=
l_Summary_Analysis.pdf</A>&nbsp;-=20
  or any of the 100 or so other relevent Digital Evidence Links =
from&nbsp; this=20
  Search </o:p></SPAN></FONT></P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><A=20
  =
href=3D"http://www.google.com/search?q=3DJudge+Grimm+Lorraine+v+Markel&am=
p;rls=3Dcom.microsoft:en-us:IE-SearchBox&amp;ie=3DUTF-8&amp;oe=3DUTF-8&am=
p;sourceid=3Die7&amp;rlz=3D1I7GGID">http://www.google.com/search?q=3DJudg=
e+Grimm+Lorraine+v+Markel&amp;rls=3Dcom.microsoft:en-us:IE-SearchBox&amp;=
ie=3DUTF-8&amp;oe=3DUTF-8&amp;sourceid=3Die7&amp;rlz=3D1I7GGID</A></o:p><=
/SPAN></FONT></P>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I have =
not=20
    purposely included nextUpdate analysis in this since compromise of =
TSA may=20
    or may not be detected by the =
nextUpdate.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In =
summary, there=20
    will be situations when TSA is compromised, some of the time stamps =
will=20
    come under dispute and that dispute will need to be resolved using =
other=20
    evidence.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P></BLOCKQUOTE>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Then LTANS =
by itself=20
  is not </SPAN></FONT></P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P></BLOCKQUOTE>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">enough</SPAN></FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">without a =
BCP for=20
  operating it or did I miss something in your =
response.</SPAN></FONT></P>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">This also =
points to=20
    the value of having invalidity date in CRL for TSA entries.&nbsp; As =
long as=20
    tc is present in tr and tc &gt; t1, the time stamp will not come =
under=20
    dispute.</SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P></BLOCKQUOTE>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">You mean =
the question=20
  of the cyptographic integrity of the timestamp process or its =
management may=20
  not come under fire... the timestamp itself will for the reasons I =
quoted,=20
  &amp; I believe it to bevery likely inadmissible in a court of law, =
and as=20
  such worthless in anyones view without building those requirements =
into the=20
  LTANS process and protcol. That's the problem with technology - its =
controlled=20
  by a number of non-technical constraints which do effect the reality =
of its=20
  use whether we as technologists like it or not.</SPAN></FONT></P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">t</SPAN></FONT></P>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=3DSection1><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">
    <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter>
    <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
    </DIV></SPAN></FONT>
    <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
    style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
    face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
    owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] =

    <B><SPAN style=3D"FONT-WEIGHT: bold">On Behalf Of =
</SPAN></B><st1:PersonName=20
    w:st=3D"on">Carl Wallace</st1:PersonName><BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, September 04, =
2007 1:45=20
    PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Vittek =
Robert;=20
    <st1:PersonName =
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName><BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: security issue =
in archive=20
    timestamp chain?</SPAN></FONT><o:p></o:p></P></DIV>
    <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DSection1><FONT face=3D"Times New Roman" size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">There's no need to safeguard the =
validation data for=20
    ATS1 at the time ATS2 is applied.&nbsp; The validation data can be =
preserved=20
    independently of the data and retrieved using SCVP/ERS.&nbsp; =
Amongst other=20
    benefits, this allows for a grace period to be applied between the =
time ATS2=20
    was generated and the time of interest for validating the TSA1=20
    credentials.&nbsp;&nbsp;&nbsp; </SPAN></FONT><o:p></o:p></P>
    <P class=3DSection1><FONT face=3D"Times New Roman" size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; -----Original =
Message-----</SPAN></FONT>=20
    <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; From:=20
    owner-ietf-ltans@mail.imc.org </SPAN></FONT><BR><FONT size=3D2><SPAN =

    style=3D"FONT-SIZE: 10pt">&gt; [<A=20
    =
href=3D"mailto:owner-ietf-ltans@mail.imc.org">mailto:owner-ietf-ltans@mai=
l.imc.org</A>]=20
    On Behalf Of Vittek Robert</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; Sent: Tuesday, September 04, 2007 =
1:23=20
    PM</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt; To:=20
    <st1:PersonName =
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName></SPAN></FONT>=20
    <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; Subject: =
security issue=20
    in archive timestamp chain?</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; We are currently implementing a long =
term=20
    electronic </SPAN></FONT><BR><FONT size=3D2><SPAN =
style=3D"FONT-SIZE: 10pt">&gt;=20
    signature based on XAdES, so I went through TS 101 903, TS=20
    </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt; 101 733=20
    and other RFCs that led me finaly to LTANS group =
</SPAN></FONT><BR><FONT=20
    size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; because XAdES does not =
address the=20
    problem of validation of </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; TSA certificates ("Rules for =
acceptance of the=20
    validity of </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; the signature within the time-stamp, =
involving=20
    trust </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
    decisions, are out of the scope of the present =
document.").</SPAN></FONT>=20
    <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
</SPAN></FONT><BR><FONT=20
    size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; I am interested in =
solving the=20
    following problem.</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; <A=20
    href=3D"http://tools.ietf.org/html/rfc4998#section-5.3"=20
    target=3D_blank>http://tools.ietf.org/html/rfc4998#section-5.3</A> =
states=20
    that: </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt; Each=20
    Archive Timestamp MUST be valid relative to the time of=20
    </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt; the=20
    following Archive Timestamp.</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; Let's assume that we have Archive =
Time-Stamp 1=20
    (ATS1) and we </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; need to renew it and safeguard the =
validation=20
    data for ATS1 </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; at the same time. But the next =
Archive=20
    Time-Stamp 2 (ATS2) </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; can prove existence only of the CRLs =
issued=20
    before time T2 </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; (from ATS2). ATS2 does NOT give any =
evidence=20
    that there was </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; not another CRL2 (issued by CA that =
issued TSA1=20
    certificate) </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; which contained information on =
revocation of=20
    TSA1 certificate.</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; I think that arbitration on validity =
of ATS1=20
    might take place </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; long after the archive of relevant =
CRLs is=20
    available and long </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; after the used cryptography is strong =
enough,=20
    so the attacker </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; might produce such CRL2 himself just =
to cast=20
    doubt upon the </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; archived data.</SPAN></FONT> =
<BR><FONT=20
    size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
</SPAN></FONT><BR><FONT=20
    size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; In other words: while =
T2 -=20
    safeguardedCRLforTSA1.thisUpdate &gt; </SPAN></FONT><BR><FONT =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; 0, arbitrator can not be sure that =
there was=20
    not another CRL2 </SPAN></FONT><BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; that listed TSA1 =
certificate.</SPAN></FONT>=20
    <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
</SPAN></FONT><BR><FONT=20
    size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; Am I missing something =
or is it a=20
    security issue?</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; Mgr. Robert Vittek</SPAN></FONT> =
<BR><FONT=20
    size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
</SPAN></FONT><BR><FONT=20
    size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; DITEC, =
a.s.</SPAN></FONT>=20
    <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; Bratislava =
Business=20
    Center V</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
    Plyn=E1rensk=E1 7/C</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; 821 09 <st1:City =
w:st=3D"on"><st1:place=20
    w:st=3D"on">Bratislava</st1:place></st1:City></SPAN></FONT> =
<BR><FONT=20
    size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
</SPAN></FONT><BR><FONT=20
    size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; voice: +421 2 58 222=20
    487</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt; fax:=20
    +421 2 58 222 777</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt">&gt; cell: +421 908 797 827</SPAN></FONT> =
<BR><FONT=20
    size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; <A=20
    =
href=3D"mailto:vittek@ditec.sk">mailto:vittek@ditec.sk</A></SPAN></FONT> =

    <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt;=20
    =
</SPAN></FONT><o:p></o:p></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0098_01C7EF15.1C174FF0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84Npu5h029105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 16:51:56 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l84Npuo6029104; Tue, 4 Sep 2007 16:51:56 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84Npsna029096 for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 16:51:55 -0700 (MST) (envelope-from tglassey@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mcJMzj1m6I4xbD/Q/ZtML59ZbM+0SP2r9iujsLF8kQnPNs0ARQc7QrNHIDq8+CGc; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=gw) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1ISiBU-0005TW-NC; Tue, 04 Sep 2007 19:51:53 -0400
Message-ID: <007f01c7ef4e$915f2dd0$174f7d40@home.glassey.com>
From: "todd glassey" <tglassey@earthlink.net>
To: "Santosh Chokhani" <chokhani@orionsec.com>, "Carl Wallace" <CWallace@cygnacom.com>, "Vittek Robert" <vittek@ditec.sk>, <ietf-ltans@imc.org>
References: <886F5D4C78AFB14D87261206BFB9612E1D31DC6C@scygmxs1.cygnacom.com> <82D5657AE1F54347A734BDD33637C879090DD6DB@EXVS01.ex.dslextreme.net>
Subject: Re: security issue in archive timestamp chain?
Date: Tue, 4 Sep 2007 16:51:26 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C7EF13.D521AEC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79c57d22029b5b4988d342b3c0eea3d200350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

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

RE: security issue in archive timestamp chain?Santosh
  ----- Original Message -----=20
  From: Santosh Chokhani=20
  To: Carl Wallace ; Vittek Robert ; ietf-ltans@imc.org=20
  Sent: Tuesday, September 04, 2007 3:12 PM
  Subject: RE: security issue in archive timestamp chain?


  Carl,

  =20

  While what you say is correct, I do not think this answers the =
question Robert has.  Let us consider the following scenario

  =20

  Time t1 is the thisUpdate for a CRL used to verify the time stamp =
applied at time t2.

  =20

  Time t3 is when the time stamp is renewed.

  =20

  We know t3 > t2 > t1.

  =20

  Time tr is thisUpdate for a CRL when the TSA first appear as =
compromised.  tr > t1.

  =20

  Time tc is the actual time of compromise.  tr > tc

  =20

  As long as CRL for t1 is produced using ERS as Carl says, the claimant =
can prove the legitimacy of the time stamp.

  =20

  If CRL for tr is also produced, the time stamp can come under dispute. =
 If there is an invalidity date associated with the TSA entry and that =
date is past t2, the time stamp is legitimate.

  =20

  Note that checking revocation status of TSA at time t3 technically =
does not help since tr can come at any time, including after t3.

  =20

  Also, if one were to check the revocation status of TSA at time t3, =
legitimate time stamps that were applied prior to tc or tr may be =
rejected.  It is tc that is hard to deal with.  That is why we have =
humans and courts and other supporting evidence to ferret things out.





I strongly suggest reviewing this =
http://www.lexisnexis.com/applieddiscovery/LawLibrary/whitePapers/ADI_WP_=
LorraineVMarkel.pdf or perhaps Surety's response there as well =
http://www.surety.com/images/whitepapers/Lorraine_v_Markel_Summary_Analys=
is.pdf - or any of the 100 or so other relevent Digital Evidence Links =
from  this Search=20



http://www.google.com/search?q=3DJudge+Grimm+Lorraine+v+Markel&rls=3Dcom.=
microsoft:en-us:IE-SearchBox&ie=3DUTF-8&oe=3DUTF-8&sourceid=3Die7&rlz=3D1=
I7GGID





  =20

  I have not purposely included nextUpdate analysis in this since =
compromise of TSA may or may not be detected by the nextUpdate.

  =20

  In summary, there will be situations when TSA is compromised, some of =
the time stamps will come under dispute and that dispute will need to be =
resolved using other evidence.



Then LTANS by itself is not without a BCP for operating it or did I miss =
something in your response.

  =20

  This also points to the value of having invalidity date in CRL for TSA =
entries.  As long as tc is present in tr and tc > t1, the time stamp =
will not come under dispute.



You mean the question of the cyptographic integrity of the timestamp =
process or its management may not come under fire... the timestamp =
itself will for the reasons I quoted, & I believe it to bevery likely =
inadmissible in a court of law, and as such worthless in anyones view =
without building those requirements into the LTANS process and protcol. =
That's the problem with technology - its controlled by a number of =
non-technical constraints which do effect the reality of its use whether =
we as technologists like it or not.



t


-------------------------------------------------------------------------=
-----

  From: owner-ietf-ltans@mail.imc.org =
[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace
  Sent: Tuesday, September 04, 2007 1:45 PM
  To: Vittek Robert; ietf-ltans@imc.org
  Subject: RE: security issue in archive timestamp chain?

  =20

  There's no need to safeguard the validation data for ATS1 at the time =
ATS2 is applied.  The validation data can be preserved independently of =
the data and retrieved using SCVP/ERS.  Amongst other benefits, this =
allows for a grace period to be applied between the time ATS2 was =
generated and the time of interest for validating the TSA1 credentials.  =
 =20

  > -----Original Message-----=20
  > From: owner-ietf-ltans@mail.imc.org=20
  > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert=20
  > Sent: Tuesday, September 04, 2007 1:23 PM=20
  > To: ietf-ltans@imc.org=20
  > Subject: security issue in archive timestamp chain?=20
  >=20
  >=20
  > We are currently implementing a long term electronic=20
  > signature based on XAdES, so I went through TS 101 903, TS=20
  > 101 733 and other RFCs that led me finaly to LTANS group=20
  > because XAdES does not address the problem of validation of=20
  > TSA certificates ("Rules for acceptance of the validity of=20
  > the signature within the time-stamp, involving trust=20
  > decisions, are out of the scope of the present document.").=20
  >=20
  > I am interested in solving the following problem.=20
  >=20
  > http://tools.ietf.org/html/rfc4998#section-5.3 states that:=20
  > Each Archive Timestamp MUST be valid relative to the time of=20
  > the following Archive Timestamp.=20
  >=20
  > Let's assume that we have Archive Time-Stamp 1 (ATS1) and we=20
  > need to renew it and safeguard the validation data for ATS1=20
  > at the same time. But the next Archive Time-Stamp 2 (ATS2)=20
  > can prove existence only of the CRLs issued before time T2=20
  > (from ATS2). ATS2 does NOT give any evidence that there was=20
  > not another CRL2 (issued by CA that issued TSA1 certificate)=20
  > which contained information on revocation of TSA1 certificate.=20
  >=20
  > I think that arbitration on validity of ATS1 might take place=20
  > long after the archive of relevant CRLs is available and long=20
  > after the used cryptography is strong enough, so the attacker=20
  > might produce such CRL2 himself just to cast doubt upon the=20
  > archived data.=20
  >=20
  > In other words: while T2 - safeguardedCRLforTSA1.thisUpdate >=20
  > 0, arbitrator can not be sure that there was not another CRL2=20
  > that listed TSA1 certificate.=20
  >=20
  > Am I missing something or is it a security issue?=20
  >=20
  >=20
  > Mgr. Robert Vittek=20
  >=20
  > DITEC, a.s.=20
  > Bratislava Business Center V=20
  > Plyn=E1rensk=E1 7/C=20
  > 821 09 Bratislava=20
  >=20
  > voice: +421 2 58 222 487=20
  > fax: +421 2 58 222 777=20
  > cell: +421 908 797 827=20
  > mailto:vittek@ditec.sk=20
  >=20

------=_NextPart_000_0077_01C7EF13.D521AEC0
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" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>RE: security =
issue in archive timestamp chain?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" 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]--><o:SmartTagType name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[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:blue;
	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 vLink=3Dblue link=3Dblue bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman" size=3D2>Santosh</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dchokhani@orionsec.com =
href=3D"mailto:chokhani@orionsec.com">Santosh=20
  Chokhani</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3DCWallace@cygnacom.com=20
  href=3D"mailto:CWallace@cygnacom.com">Carl Wallace</A> ; <A=20
  title=3Dvittek@ditec.sk href=3D"mailto:vittek@ditec.sk">Vittek =
Robert</A> ; <A=20
  title=3Dietf-ltans@imc.org=20
  href=3D"mailto:ietf-ltans@imc.org">ietf-ltans@imc.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, September 04, =
2007 3:12=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: security issue in =
archive=20
  timestamp chain?</DIV>
  <DIV><BR></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Carl,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">While what =
you say is=20
  correct, I do not think this answers the question Robert has.&nbsp; =
Let us=20
  consider the following scenario<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Time t1 is =
the=20
  thisUpdate for a CRL used to verify the time stamp applied at time=20
  t2.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Time t3 is =
when the=20
  time stamp is renewed.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">We know t3 =
&gt; t2=20
  &gt; t1.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Time tr is =
thisUpdate=20
  for a CRL when the TSA first appear as compromised.&nbsp; tr &gt;=20
  t1.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Time tc is =
the actual=20
  time of compromise. &nbsp;tr &gt; tc<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As long as =
CRL for t1=20
  is produced using ERS as Carl says, the claimant can prove the =
legitimacy of=20
  the time stamp.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">If CRL for =
tr is also=20
  produced, the time stamp can come under dispute. &nbsp;If there is an=20
  invalidity date associated with the TSA entry and that date is past =
t2, the=20
  time stamp is legitimate.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Note that =
checking=20
  revocation status of TSA at time t3 technically does not help since tr =
can=20
  come at any time, including after t3.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Also, if =
one were to=20
  check the revocation status of TSA at time t3, legitimate time stamps =
that=20
  were applied prior to tc or tr may be rejected. &nbsp;It is tc that is =
hard to=20
  deal with.&nbsp; That is why we have humans and courts and other =
supporting=20
  evidence to ferret things out.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P></DIV></BLOCKQUOTE>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>I =
strongly suggest=20
reviewing this <A=20
href=3D"http://www.lexisnexis.com/applieddiscovery/LawLibrary/whitePapers=
/ADI_WP_LorraineVMarkel.pdf">http://www.lexisnexis.com/applieddiscovery/L=
awLibrary/whitePapers/ADI_WP_LorraineVMarkel.pdf</A>&nbsp;or=20
perhaps Surety's response there as well <A=20
href=3D"http://www.surety.com/images/whitepapers/Lorraine_v_Markel_Summar=
y_Analysis.pdf">http://www.surety.com/images/whitepapers/Lorraine_v_Marke=
l_Summary_Analysis.pdf</A>&nbsp;-=20
or any of the 100 or so other relevent Digital Evidence Links from&nbsp; =
this=20
Search </o:p></SPAN></FONT></P>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><A=20
href=3D"http://www.google.com/search?q=3DJudge+Grimm+Lorraine+v+Markel&am=
p;rls=3Dcom.microsoft:en-us:IE-SearchBox&amp;ie=3DUTF-8&amp;oe=3DUTF-8&am=
p;sourceid=3Die7&amp;rlz=3D1I7GGID">http://www.google.com/search?q=3DJudg=
e+Grimm+Lorraine+v+Markel&amp;rls=3Dcom.microsoft:en-us:IE-SearchBox&amp;=
ie=3DUTF-8&amp;oe=3DUTF-8&amp;sourceid=3Die7&amp;rlz=3D1I7GGID</A></o:p><=
/SPAN></FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I have not =
purposely=20
  included nextUpdate analysis in this since compromise of TSA may or =
may not be=20
  detected by the nextUpdate.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In summary, =
there=20
  will be situations when TSA is compromised, some of the time stamps =
will come=20
  under dispute and that dispute will need to be resolved using other=20
  evidence.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P></BLOCKQUOTE>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Then LTANS by =
itself is=20
not without a BCP for operating it or did I miss something in your=20
response.</SPAN></FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=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=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">This also =
points to=20
  the value of having invalidity date in CRL for TSA entries.&nbsp; As =
long as=20
  tc is present in tr and tc &gt; t1, the time stamp will not come under =

  dispute.</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P></BLOCKQUOTE>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">You mean the =
question=20
of the cyptographic integrity of the timestamp process or its management =
may not=20
come under fire... the timestamp itself will for the reasons I quoted, =
&amp; I=20
believe it to bevery likely inadmissible in a court of law, and as such=20
worthless in anyones view without building those requirements into the =
LTANS=20
process and protcol. That's the problem with technology - its controlled =
by a=20
number of non-technical constraints which do effect the reality of its =
use=20
whether we as technologists like it or not.</SPAN></FONT></P>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"></SPAN></FONT>&nbsp;</P>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">t</SPAN></FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=3DSection1><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter>
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </DIV></SPAN></FONT>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] =
<B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B><st1:PersonName=20
  w:st=3D"on">Carl Wallace</st1:PersonName><BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, September 04, =
2007 1:45=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Vittek =
Robert;=20
  <st1:PersonName =
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName><BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: security issue in =
archive=20
  timestamp chain?</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DSection1><FONT face=3D"Times New Roman" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">There's no need to safeguard the validation =
data for=20
  ATS1 at the time ATS2 is applied.&nbsp; The validation data can be =
preserved=20
  independently of the data and retrieved using SCVP/ERS.&nbsp; Amongst =
other=20
  benefits, this allows for a grace period to be applied between the =
time ATS2=20
  was generated and the time of interest for validating the TSA1=20
  credentials.&nbsp;&nbsp;&nbsp; </SPAN></FONT><o:p></o:p></P>
  <P class=3DSection1><FONT face=3D"Times New Roman" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; -----Original =
Message-----</SPAN></FONT>=20
  <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; From:=20
  owner-ietf-ltans@mail.imc.org </SPAN></FONT><BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; [<A=20
  =
href=3D"mailto:owner-ietf-ltans@mail.imc.org">mailto:owner-ietf-ltans@mai=
l.imc.org</A>]=20
  On Behalf Of Vittek Robert</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Sent: Tuesday, September 04, 2007 1:23=20
  PM</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt; To:=20
  <st1:PersonName =
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName></SPAN></FONT>=20
  <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; Subject: =
security issue in=20
  archive timestamp chain?</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; We are currently implementing a long =
term=20
  electronic </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
  signature based on XAdES, so I went through TS 101 903, TS=20
  </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
101 733 and=20
  other RFCs that led me finaly to LTANS group </SPAN></FONT><BR><FONT=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; because XAdES does not =
address the=20
  problem of validation of </SPAN></FONT><BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; TSA certificates ("Rules for acceptance =
of the=20
  validity of </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
  the signature within the time-stamp, involving trust =
</SPAN></FONT><BR><FONT=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; decisions, are out of =
the scope of=20
  the present document.").</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; I am interested in solving the =
following=20
  problem.</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
  </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
<A=20
  href=3D"http://tools.ietf.org/html/rfc4998#section-5.3"=20
  target=3D_blank>http://tools.ietf.org/html/rfc4998#section-5.3</A> =
states that:=20
  </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
Each Archive=20
  Timestamp MUST be valid relative to the time of =
</SPAN></FONT><BR><FONT=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; the following Archive=20
  Timestamp.</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
  </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
Let's assume=20
  that we have Archive Time-Stamp 1 (ATS1) and we =
</SPAN></FONT><BR><FONT=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; need to renew it and =
safeguard the=20
  validation data for ATS1 </SPAN></FONT><BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; at the same time. But the next Archive =
Time-Stamp=20
  2 (ATS2) </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt; can=20
  prove existence only of the CRLs issued before time T2 =
</SPAN></FONT><BR><FONT=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; (from ATS2). ATS2 does =
NOT give any=20
  evidence that there was </SPAN></FONT><BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; not another CRL2 (issued by CA that =
issued TSA1=20
  certificate) </SPAN></FONT><BR><FONT size=3D2><SPAN =
style=3D"FONT-SIZE: 10pt">&gt;=20
  which contained information on revocation of TSA1 =
certificate.</SPAN></FONT>=20
  <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
</SPAN></FONT><BR><FONT=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; I think that arbitration =
on validity=20
  of ATS1 might take place </SPAN></FONT><BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; long after the archive of relevant CRLs =
is=20
  available and long </SPAN></FONT><BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; after the used cryptography is strong =
enough, so=20
  the attacker </SPAN></FONT><BR><FONT size=3D2><SPAN =
style=3D"FONT-SIZE: 10pt">&gt;=20
  might produce such CRL2 himself just to cast doubt upon the=20
  </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
archived=20
  data.</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
  </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
In other=20
  words: while T2 - safeguardedCRLforTSA1.thisUpdate &gt;=20
  </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
0,=20
  arbitrator can not be sure that there was not another CRL2=20
  </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
that listed=20
  TSA1 certificate.</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Am I missing something or is it a =
security=20
  issue?</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
  </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt;=20
  </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
Mgr. Robert=20
  Vittek</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
  </SPAN></FONT><BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
DITEC,=20
  a.s.</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt;=20
  Bratislava Business Center V</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; Plyn=E1rensk=E1 7/C</SPAN></FONT> =
<BR><FONT=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; 821 09 <st1:City=20
  w:st=3D"on"><st1:place =
w:st=3D"on">Bratislava</st1:place></st1:City></SPAN></FONT>=20
  <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; =
</SPAN></FONT><BR><FONT=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; voice: +421 2 58 222=20
  487</SPAN></FONT> <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">&gt; fax:=20
  +421 2 58 222 777</SPAN></FONT> <BR><FONT size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&gt; cell: +421 908 797 827</SPAN></FONT> =
<BR><FONT=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt; <A=20
  =
href=3D"mailto:vittek@ditec.sk">mailto:vittek@ditec.sk</A></SPAN></FONT> =

  <BR><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt">&gt;=20
  </SPAN></FONT><o:p></o:p></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0077_01C7EF13.D521AEC0--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84MFxJJ020459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 15:15:59 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l84MFxA3020458; Tue, 4 Sep 2007 15:15:59 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84MFw2q020451 for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 15:15:58 -0700 (MST) (envelope-from chokhani@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EF41.542C5276"
Subject: RE: security issue in archive timestamp chain?
Date: Tue, 4 Sep 2007 15:14:51 -0700
Message-ID: <82D5657AE1F54347A734BDD33637C879090DD6E7@EXVS01.ex.dslextreme.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: security issue in archive timestamp chain?
Thread-Index: AcfvHQtk4Sjkc7G8Qw2xNDTuvpRCWwAI1VtAAAAjl8A=
References: <886F5D4C78AFB14D87261206BFB9612E1D31DC6C@scygmxs1.cygnacom.com> 
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "Carl Wallace" <CWallace@cygnacom.com>, "Vittek Robert" <vittek@ditec.sk>, <ietf-ltans@imc.org>
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

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

In the last sentence, I meant tc > t2 (t2 being the time stamp time).

=20

________________________________

From: Santosh Chokhani=20
Sent: Tuesday, September 04, 2007 6:12 PM
To: 'Carl Wallace'; Vittek Robert; ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?

=20

Carl,

=20

While what you say is correct, I do not think this answers the question =
Robert has.  Let us consider the following scenario

=20

Time t1 is the thisUpdate for a CRL used to verify the time stamp =
applied at time t2.

=20

Time t3 is when the time stamp is renewed.

=20

We know t3 > t2 > t1.

=20

Time tr is thisUpdate for a CRL when the TSA first appear as =
compromised.  tr > t1.

=20

Time tc is the actual time of compromise.  tr > tc

=20

As long as CRL for t1 is produced using ERS as Carl says, the claimant =
can prove the legitimacy of the time stamp.

=20

If CRL for tr is also produced, the time stamp can come under dispute.  =
If there is an invalidity date associated with the TSA entry and that =
date is past t2, the time stamp is legitimate.

=20

Note that checking revocation status of TSA at time t3 technically does =
not help since tr can come at any time, including after t3.

=20

Also, if one were to check the revocation status of TSA at time t3, =
legitimate time stamps that were applied prior to tc or tr may be =
rejected.  It is tc that is hard to deal with.  That is why we have =
humans and courts and other supporting evidence to ferret things out.

=20

I have not purposely included nextUpdate analysis in this since =
compromise of TSA may or may not be detected by the nextUpdate.

=20

In summary, there will be situations when TSA is compromised, some of =
the time stamps will come under dispute and that dispute will need to be =
resolved using other evidence.

=20

This also points to the value of having invalidity date in CRL for TSA =
entries.  As long as tc is present in tr and tc > t1, the time stamp =
will not come under dispute.

________________________________

From: owner-ietf-ltans@mail.imc.org =
[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace
Sent: Tuesday, September 04, 2007 1:45 PM
To: Vittek Robert; ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?

=20

There's no need to safeguard the validation data for ATS1 at the time =
ATS2 is applied.  The validation data can be preserved independently of =
the data and retrieved using SCVP/ERS.  Amongst other benefits, this =
allows for a grace period to be applied between the time ATS2 was =
generated and the time of interest for validating the TSA1 credentials.  =
 =20

> -----Original Message-----=20
> From: owner-ietf-ltans@mail.imc.org=20
> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert=20
> Sent: Tuesday, September 04, 2007 1:23 PM=20
> To: ietf-ltans@imc.org=20
> Subject: security issue in archive timestamp chain?=20
>=20
>=20
> We are currently implementing a long term electronic=20
> signature based on XAdES, so I went through TS 101 903, TS=20
> 101 733 and other RFCs that led me finaly to LTANS group=20
> because XAdES does not address the problem of validation of=20
> TSA certificates ("Rules for acceptance of the validity of=20
> the signature within the time-stamp, involving trust=20
> decisions, are out of the scope of the present document.").=20
>=20
> I am interested in solving the following problem.=20
>=20
> http://tools.ietf.org/html/rfc4998#section-5.3 states that:=20
> Each Archive Timestamp MUST be valid relative to the time of=20
> the following Archive Timestamp.=20
>=20
> Let's assume that we have Archive Time-Stamp 1 (ATS1) and we=20
> need to renew it and safeguard the validation data for ATS1=20
> at the same time. But the next Archive Time-Stamp 2 (ATS2)=20
> can prove existence only of the CRLs issued before time T2=20
> (from ATS2). ATS2 does NOT give any evidence that there was=20
> not another CRL2 (issued by CA that issued TSA1 certificate)=20
> which contained information on revocation of TSA1 certificate.=20
>=20
> I think that arbitration on validity of ATS1 might take place=20
> long after the archive of relevant CRLs is available and long=20
> after the used cryptography is strong enough, so the attacker=20
> might produce such CRL2 himself just to cast doubt upon the=20
> archived data.=20
>=20
> In other words: while T2 - safeguardedCRLforTSA1.thisUpdate >=20
> 0, arbitrator can not be sure that there was not another CRL2=20
> that listed TSA1 certificate.=20
>=20
> Am I missing something or is it a security issue?=20
>=20
>=20
> Mgr. Robert Vittek=20
>=20
> DITEC, a.s.=20
> Bratislava Business Center V=20
> Plyn=E1rensk=E1 7/C=20
> 821 09 Bratislava=20
>=20
> voice: +421 2 58 222 487=20
> fax: +421 2 58 222 777=20
> cell: +421 908 797 827=20
> mailto:vittek@ditec.sk=20
>=20


------_=_NextPart_001_01C7EF41.542C5276
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>RE: security issue in archive timestamp chain?</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<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 lfo4;
	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 lfo4;
	font-size:11.0pt;
	font-family:Arial;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	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;}
p.stylecentered0, li.stylecentered0, div.stylecentered0
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:Arial;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle21
	{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=3Dblue>

<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'>In the last sentence, I meant tc =
&gt; t2
(t2 being the time stamp time).<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'> =
<st1:PersonName
w:st=3D"on">Santosh Chokhani</st1:PersonName> <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, September =
04, 2007
6:12 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">'<st1:PersonName
 w:st=3D"on">Carl Wallace</st1:PersonName>'</st1:PersonName>; Vittek =
Robert; <st1:PersonName
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: security =
issue in
archive timestamp chain?</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 class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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'>While what you say is correct, I do =
not
think this answers the question Robert has.&nbsp; Let us consider the =
following
scenario<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'>Time t1 is the thisUpdate for a CRL =
used
to verify the time stamp applied at time =
t2.<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'>Time t3 is when the time stamp is =
renewed.<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'>We know t3 &gt; t2 &gt; =
t1.<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'>Time tr is thisUpdate for a CRL =
when the
TSA first appear as compromised.&nbsp; tr &gt; =
t1.<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'>Time tc is the actual time of =
compromise.
&nbsp;tr &gt; tc<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'>As long as CRL for t1 is produced =
using ERS
as Carl says, the claimant can prove the legitimacy of the time =
stamp.<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'>If CRL for tr is also produced, the =
time
stamp can come under dispute. &nbsp;If there is an invalidity date =
associated
with the TSA entry and that date is past t2, the time stamp is =
legitimate.<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'>Note that checking revocation =
status of
TSA at time t3 technically does not help since tr can come at any time,
including after t3.<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'>Also, if one were to check the =
revocation
status of TSA at time t3, legitimate time stamps that were applied prior =
to tc
or tr may be rejected. &nbsp;It is tc that is hard to deal with.&nbsp; =
That is
why we have humans and courts and other supporting evidence to ferret =
things
out.<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 have not purposely included =
nextUpdate
analysis in this since compromise of TSA may or may not be detected by =
the
nextUpdate.<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'>In summary, there will be =
situations when
TSA is compromised, some of the time stamps will come under dispute and =
that
dispute will need to be resolved using other =
evidence.<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'>This also points to the value of =
having
invalidity date in CRL for TSA entries.&nbsp; As long as tc is present =
in tr
and tc &gt; t1, the time stamp will not come under =
dispute.<o:p></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'>
owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] =
<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> Tuesday, September =
04, 2007
1:45 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Vittek Robert; =
<st1:PersonName
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: security =
issue in
archive timestamp chain?</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'>There's
no need to safeguard the validation data for ATS1 at the time ATS2 is
applied.&nbsp; The validation data can be preserved independently of the =
data and
retrieved using SCVP/ERS.&nbsp; Amongst other benefits, this allows for =
a grace
period to be applied between the time ATS2 was generated and the time of
interest for validating the TSA1 credentials.&nbsp;&nbsp;&nbsp; =
</span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;
-----Original Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; From: =
owner-ietf-ltans@mail.imc.org
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; [<a
href=3D"mailto:owner-ietf-ltans@mail.imc.org">mailto:owner-ietf-ltans@mai=
l.imc.org</a>]
On Behalf Of Vittek Robert</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Sent: Tuesday, =
September 04,
2007 1:23 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To: <st1:PersonName =
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName></span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Subject: security =
issue in
archive timestamp chain?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; We are currently =
implementing
a long term electronic </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; signature based on =
XAdES, so I
went through TS 101 903, TS </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; 101 733 and other =
RFCs that
led me finaly to LTANS group </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; because XAdES does =
not address
the problem of validation of </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; TSA certificates =
(&quot;Rules
for acceptance of the validity of </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the signature =
within the
time-stamp, involving trust </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; decisions, are out =
of the
scope of the present document.&quot;).</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I am interested in =
solving the
following problem.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; <a
href=3D"http://tools.ietf.org/html/rfc4998#section-5.3" =
target=3D"_blank">http://tools.ietf.org/html/rfc4998#section-5.3</a>
states that: </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Each Archive =
Timestamp MUST be
valid relative to the time of </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the following =
Archive
Timestamp.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Let's assume that =
we have
Archive Time-Stamp 1 (ATS1) and we </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; need to renew it =
and safeguard
the validation data for ATS1 </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; at the same time. =
But the next
Archive Time-Stamp 2 (ATS2) </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; can prove existence =
only of
the CRLs issued before time T2 </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; (from ATS2). ATS2 =
does NOT
give any evidence that there was </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; not another CRL2 =
(issued by CA
that issued TSA1 certificate) </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; which contained =
information on
revocation of TSA1 certificate.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I think that =
arbitration on
validity of ATS1 might take place </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; long after the =
archive of
relevant CRLs is available and long </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; after the used =
cryptography is
strong enough, so the attacker </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; might produce such =
CRL2
himself just to cast doubt upon the </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; archived =
data.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; In other words: =
while T2 -
safeguardedCRLforTSA1.thisUpdate &gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; 0, arbitrator can =
not be sure
that there was not another CRL2 </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; that listed TSA1 =
certificate.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Am I missing =
something or is
it a security issue?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Mgr. Robert =
Vittek</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; DITEC, =
a.s.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Bratislava Business =
Center V</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Plyn=E1rensk=E1 =
7/C</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; 821 09 <st1:place =
w:st=3D"on"><st1:City
 w:st=3D"on">Bratislava</st1:City></st1:place></span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; voice: +421 2 58 =
222 487</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; fax: +421 2 58 222 =
777</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; cell: +421 908 797 =
827</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; <a
href=3D"mailto:vittek@ditec.sk">mailto:vittek@ditec.sk</a></span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
</span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C7EF41.542C5276--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84MDBFn019915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 15:13:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l84MDBUc019914; Tue, 4 Sep 2007 15:13:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from EXVS01.ex.dslextreme.net (exbe04.ex.dslextreme.net [66.51.199.86]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84MDA8i019903 for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 15:13:11 -0700 (MST) (envelope-from chokhani@orionsec.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EF40.EF85EE7B"
Subject: RE: security issue in archive timestamp chain?
Date: Tue, 4 Sep 2007 15:12:09 -0700
Message-ID: <82D5657AE1F54347A734BDD33637C879090DD6DB@EXVS01.ex.dslextreme.net>
In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31DC6C@scygmxs1.cygnacom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: security issue in archive timestamp chain?
Thread-Index: AcfvHQtk4Sjkc7G8Qw2xNDTuvpRCWwAI1VtA
References: <886F5D4C78AFB14D87261206BFB9612E1D31DC6C@scygmxs1.cygnacom.com>
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "Carl Wallace" <CWallace@cygnacom.com>, "Vittek Robert" <vittek@ditec.sk>, <ietf-ltans@imc.org>
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

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

Carl,

=20

While what you say is correct, I do not think this answers the question =
Robert has.  Let us consider the following scenario

=20

Time t1 is the thisUpdate for a CRL used to verify the time stamp =
applied at time t2.

=20

Time t3 is when the time stamp is renewed.

=20

We know t3 > t2 > t1.

=20

Time tr is thisUpdate for a CRL when the TSA first appear as =
compromised.  tr > t1.

=20

Time tc is the actual time of compromise.  tr > tc

=20

As long as CRL for t1 is produced using ERS as Carl says, the claimant =
can prove the legitimacy of the time stamp.

=20

If CRL for tr is also produced, the time stamp can come under dispute.  =
If there is an invalidity date associated with the TSA entry and that =
date is past t2, the time stamp is legitimate.

=20

Note that checking revocation status of TSA at time t3 technically does =
not help since tr can come at any time, including after t3.

=20

Also, if one were to check the revocation status of TSA at time t3, =
legitimate time stamps that were applied prior to tc or tr may be =
rejected.  It is tc that is hard to deal with.  That is why we have =
humans and courts and other supporting evidence to ferret things out.

=20

I have not purposely included nextUpdate analysis in this since =
compromise of TSA may or may not be detected by the nextUpdate.

=20

In summary, there will be situations when TSA is compromised, some of =
the time stamps will come under dispute and that dispute will need to be =
resolved using other evidence.

=20

This also points to the value of having invalidity date in CRL for TSA =
entries.  As long as tc is present in tr and tc > t1, the time stamp =
will not come under dispute.

________________________________

From: owner-ietf-ltans@mail.imc.org =
[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace
Sent: Tuesday, September 04, 2007 1:45 PM
To: Vittek Robert; ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?

=20

There's no need to safeguard the validation data for ATS1 at the time =
ATS2 is applied.  The validation data can be preserved independently of =
the data and retrieved using SCVP/ERS.  Amongst other benefits, this =
allows for a grace period to be applied between the time ATS2 was =
generated and the time of interest for validating the TSA1 credentials.  =
 =20

> -----Original Message-----=20
> From: owner-ietf-ltans@mail.imc.org=20
> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert=20
> Sent: Tuesday, September 04, 2007 1:23 PM=20
> To: ietf-ltans@imc.org=20
> Subject: security issue in archive timestamp chain?=20
>=20
>=20
> We are currently implementing a long term electronic=20
> signature based on XAdES, so I went through TS 101 903, TS=20
> 101 733 and other RFCs that led me finaly to LTANS group=20
> because XAdES does not address the problem of validation of=20
> TSA certificates ("Rules for acceptance of the validity of=20
> the signature within the time-stamp, involving trust=20
> decisions, are out of the scope of the present document.").=20
>=20
> I am interested in solving the following problem.=20
>=20
> http://tools.ietf.org/html/rfc4998#section-5.3 states that:=20
> Each Archive Timestamp MUST be valid relative to the time of=20
> the following Archive Timestamp.=20
>=20
> Let's assume that we have Archive Time-Stamp 1 (ATS1) and we=20
> need to renew it and safeguard the validation data for ATS1=20
> at the same time. But the next Archive Time-Stamp 2 (ATS2)=20
> can prove existence only of the CRLs issued before time T2=20
> (from ATS2). ATS2 does NOT give any evidence that there was=20
> not another CRL2 (issued by CA that issued TSA1 certificate)=20
> which contained information on revocation of TSA1 certificate.=20
>=20
> I think that arbitration on validity of ATS1 might take place=20
> long after the archive of relevant CRLs is available and long=20
> after the used cryptography is strong enough, so the attacker=20
> might produce such CRL2 himself just to cast doubt upon the=20
> archived data.=20
>=20
> In other words: while T2 - safeguardedCRLforTSA1.thisUpdate >=20
> 0, arbitrator can not be sure that there was not another CRL2=20
> that listed TSA1 certificate.=20
>=20
> Am I missing something or is it a security issue?=20
>=20
>=20
> Mgr. Robert Vittek=20
>=20
> DITEC, a.s.=20
> Bratislava Business Center V=20
> Plyn=E1rensk=E1 7/C=20
> 821 09 Bratislava=20
>=20
> voice: +421 2 58 222 487=20
> fax: +421 2 58 222 777=20
> cell: +421 908 797 827=20
> mailto:vittek@ditec.sk=20
>=20


------_=_NextPart_001_01C7EF40.EF85EE7B
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>RE: security issue in archive timestamp chain?</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<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:blue;
	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=3Dblue>

<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'>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'>While what you say is correct, I do =
not
think this answers the question Robert has.&nbsp; Let us consider the =
following
scenario<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'>Time t1 is the thisUpdate for a CRL =
used
to verify the time stamp applied at time =
t2.<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'>Time t3 is when the time stamp is =
renewed.<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'>We know t3 &gt; t2 &gt; =
t1.<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'>Time tr is thisUpdate for a CRL =
when the
TSA first appear as compromised.&nbsp; tr &gt; =
t1.<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'>Time tc is the actual time of =
compromise.
&nbsp;tr &gt; tc<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'>As long as CRL for t1 is produced =
using
ERS as Carl says, the claimant can prove the legitimacy of the time =
stamp.<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'>If CRL for tr is also produced, the =
time
stamp can come under dispute. &nbsp;If there is an invalidity date =
associated
with the TSA entry and that date is past t2, the time stamp is =
legitimate.<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'>Note that checking revocation =
status of
TSA at time t3 technically does not help since tr can come at any time,
including after t3.<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'>Also, if one were to check the =
revocation
status of TSA at time t3, legitimate time stamps that were applied prior =
to tc
or tr may be rejected. &nbsp;It is tc that is hard to deal with.&nbsp; =
That is
why we have humans and courts and other supporting evidence to ferret =
things
out.<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 have not purposely included =
nextUpdate
analysis in this since compromise of TSA may or may not be detected by =
the
nextUpdate.<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'>In summary, there will be =
situations when
TSA is compromised, some of the time stamps will come under dispute and =
that
dispute will need to be resolved using other =
evidence.<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'>This also points to the value of =
having
invalidity date in CRL for TSA entries.=A0 As long as tc is present in =
tr and tc &gt;
t1, the time stamp will not come under =
dispute.<o:p></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'>
owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] =
<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> Tuesday, September =
04, 2007
1:45 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Vittek Robert; =
<st1:PersonName
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: security =
issue in
archive timestamp chain?</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'>There's
no need to safeguard the validation data for ATS1 at the time ATS2 is
applied.&nbsp; The validation data can be preserved independently of the =
data
and retrieved using SCVP/ERS.&nbsp; Amongst other benefits, this allows =
for a
grace period to be applied between the time ATS2 was generated and the =
time of
interest for validating the TSA1 credentials.&nbsp;&nbsp;&nbsp; =
</span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;
-----Original Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; From:
owner-ietf-ltans@mail.imc.org </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; [<a
href=3D"mailto:owner-ietf-ltans@mail.imc.org">mailto:owner-ietf-ltans@mai=
l.imc.org</a>]
On Behalf Of Vittek Robert</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Sent: Tuesday, =
September 04,
2007 1:23 PM</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; To: <st1:PersonName =
w:st=3D"on">ietf-ltans@imc.org</st1:PersonName></span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Subject: security =
issue in
archive timestamp chain?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; We are currently =
implementing
a long term electronic </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; signature based on =
XAdES, so I
went through TS 101 903, TS </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; 101 733 and other =
RFCs that
led me finaly to LTANS group </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; because XAdES does =
not address
the problem of validation of </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; TSA certificates =
(&quot;Rules
for acceptance of the validity of </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the signature =
within the
time-stamp, involving trust </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; decisions, are out =
of the
scope of the present document.&quot;).</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I am interested in =
solving the
following problem.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; <a
href=3D"http://tools.ietf.org/html/rfc4998#section-5.3" =
target=3D"_blank">http://tools.ietf.org/html/rfc4998#section-5.3</a>
states that: </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Each Archive =
Timestamp MUST be
valid relative to the time of </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; the following =
Archive
Timestamp.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Let's assume that =
we have
Archive Time-Stamp 1 (ATS1) and we </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; need to renew it =
and safeguard
the validation data for ATS1 </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; at the same time. =
But the next
Archive Time-Stamp 2 (ATS2) </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; can prove existence =
only of
the CRLs issued before time T2 </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; (from ATS2). ATS2 =
does NOT
give any evidence that there was </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; not another CRL2 =
(issued by CA
that issued TSA1 certificate) </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; which contained =
information on
revocation of TSA1 certificate.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; I think that =
arbitration on
validity of ATS1 might take place </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; long after the =
archive of
relevant CRLs is available and long </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; after the used =
cryptography is
strong enough, so the attacker </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; might produce such =
CRL2
himself just to cast doubt upon the </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; archived =
data.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; In other words: =
while T2 -
safeguardedCRLforTSA1.thisUpdate &gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; 0, arbitrator can =
not be sure
that there was not another CRL2 </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; that listed TSA1 =
certificate.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Am I missing =
something or is
it a security issue?</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Mgr. Robert =
Vittek</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; DITEC, =
a.s.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Bratislava Business =
Center V</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; Plyn=E1rensk=E1 =
7/C</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; 821 09 <st1:City =
w:st=3D"on"><st1:place
 w:st=3D"on">Bratislava</st1:place></st1:City></span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; voice: +421 2 58 =
222 487</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; fax: +421 2 58 222 =
777</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; cell: +421 908 797 =
827</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; <a
href=3D"mailto:vittek@ditec.sk">mailto:vittek@ditec.sk</a></span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt; =
</span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C7EF40.EF85EE7B--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84IVKCG099408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 11:31:20 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l84IVKLF099402; Tue, 4 Sep 2007 11:31:20 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84IVG2C099359 for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 11:31:17 -0700 (MST) (envelope-from tglassey@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=YiWxnLfhj2Es4lDV+8LzL6rthnly382j+W2zaQjVNInNfSEAJ7MwYBSveo8oCl2O; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=gw) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1ISdBB-000637-UC; Tue, 04 Sep 2007 14:31:14 -0400
Message-ID: <004501c7ef21$ca8324e0$174f7d40@home.glassey.com>
From: "todd glassey" <tglassey@earthlink.net>
To: "Vittek Robert" <vittek@ditec.sk>, <ietf-ltans@imc.org>
References: <E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF6F5A@mail.intra.ditec.sk>
Subject: Re: security issue in archive timestamp chain?
Date: Tue, 4 Sep 2007 11:26:48 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79e595cf19e90ef3c41a368c11ac3aae0c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Robert -
there is another issue and that NO ONE inside the IETF except me has ever 
taken a legal look at RFC3161 to see if it can be legally rolled out , and 
since I am not a lawyer, I can only give a lay opinion as an Auditor, but as 
an Auditor, and someone formally responsible for audit integrity's of my 
client's, I am publicly stating that it is my belief that RFC3161 may be 
illegal to implement in the form its codified in now since it forces certain 
new RFC3161 specific process rules on Financial Service providers which are 
constrained by previously existing regulatory framework.

Further any Country which also has a Mutual Recognition Agreement (MRA) with 
the US is also constrained by that same rule of law... so that means 
Germany, France, Switzerland, Norway, Holland,  and Great Britain, oh hell - 
it means all of the EU for that matter...

Yes it's true - and it has been for about 100 years or more. That being that 
all of the Countries involved have formal legal agreements regarding which 
source of time data is used, and which will prohibit the release and use of 
RFC3161 technologies or the recommendation from ETSI for TSA's which some 
other part of the EU thought would be a good idea  to codify in violation of 
those other free standing MRA's between our government's.

Hell the same Legal Metrological Agreements also constrain this and they 
likewise were shut out of this effort by the Technological Resources groups 
that codified RFC3161 and prevented the other TS processes (which did honor 
those agreement's) from being implemented.

Dont believe me - see www.oiml.org (the Organization International Metrology 
du Legal).

Notice for instance in the language of TS 101 903 (the link follows) that 
there is NO REFERENCE TO LEGAL METROLOGICAL COMPLIANCE but the government's 
of the country's where this work was produced are all constrained by those 
said same treaties and agreement's, in addition to their own local 
Metrological Regulatory requirements.  As noted above - the link follows... 
http://uri.etsi.org/01903/v1.2.2/ts_101903v010202p.pdf



More in response inline below...



----- Original Message ----- 
From: "Vittek Robert" <vittek@ditec.sk>
To: <ietf-ltans@imc.org>
Sent: Tuesday, September 04, 2007 10:23 AM
Subject: security issue in archive timestamp chain?


>
> We are currently implementing a long term electronic signature based on 
> XAdES, so I went through TS 101 903, TS 101 733 and other RFCs that led me 
> finaly to LTANS group because XAdES does not address the problem of 
> validation of TSA certificates ("Rules for acceptance of the validity of 
> the signature within the time-stamp, involving trust decisions, are out of 
> the scope of the present document.").
>
> I am interested in solving the following problem.
>
> http://tools.ietf.org/html/rfc4998#section-5.3 states that: Each Archive 
> Timestamp MUST be valid relative to the time of the following Archive 
> Timestamp.

Which means what? - that there is some chain-of-custody and releative 
relationship between the two time stamps?  Why is this true or necessary?

>
> Let's assume that we have Archive Time-Stamp 1 (ATS1) and we need to renew 
> it and safeguard the validation data for ATS1 at the same time.

Uh from a use standpoint why would this EVER need to be done? - all that 
needs to be done is some record of all active stamps in a given timeframe be 
generated and maintained. Its then that record of the timestamps and not the 
original timestamp that needs to be continuously maintained...

> But the next Archive Time-Stamp 2 (ATS2) can prove existence only of the 
> CRLs issued before time T2 (from ATS2). ATS2 does NOT give any evidence 
> that there was not another CRL2 (issued by CA that issued TSA1 
> certificate) which contained information on revocation of TSA1 
> certificate.

The role of the original timestamp dualy is to prove its validity at the 
time of its issuance and the content at the stamping time. The time of the 
on-going TS Storage Report is to verify that there was a timestamp (the 
original or restamped TS Token) issued at some point with some 
policy/technology involved. Nothing more. The idea that the original TS 
should be good forever is crazy... and potentially a total waste of time and 
effort IMHO...

>
> I think that arbitration on validity of ATS1 might take place long after 
> the archive of relevant CRLs is available and long after the used 
> cryptography is strong enough, so the attacker might produce such CRL2 
> himself just to cast doubt upon the archived data.
>
> In other words: while T2 - safeguardedCRLforTSA1.thisUpdate > 0, 
> arbitrator can not be sure that there was not another CRL2 that listed 
> TSA1 certificate.
>
> Am I missing something or is it a security issue?

yes, the actual usage model is not one which permanently document's the 
current timestamp of the document, but that its original TS was accurate and 
reliable. We are not trying to implement a policy decision here, but rather 
one of 'that the document was controlled and its content provable at the 
time of its filing, and that the process of proving that original filing can 
be continuously proven as accurate at the time of the filing.

The ultimate solution here is actually a Technology that can prove that a 
document is reliable readable and authenticatable continuously, no matter 
what time-specific policies or time-controls were placed on that document.

So Document A is filed on DATE 1 (A1) and now needs to be proven at DATE 2 
(A2 in this instance) and the KEYS or POLICIES for A1 were set to expire 
prior to A2's coming on line. The problem is that Authentication/Entitlement 
and Content Assurance are being controlled through the same set of signings 
and that is a problem since the policies are differing.

Entitlement will likely change over time with any digital document's use, 
but the original Content or Current Content Assurance process shouldnt. That 
is something that LTANS needs to address and its one of the reasons' that 
the uses and interaction procedures with LTANS need to be hammered out 
before the code is built to operate these features IMHO.

//Todd Glassey CIFI, CISM



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84HiokK094172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 10:44:51 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l84HioR3094171; Tue, 4 Sep 2007 10:44:50 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l84HilAM094153 for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 10:44:50 -0700 (MST) (envelope-from CWallace@cygnacom.com)
Received: (qmail 16105 invoked from network); 4 Sep 2007 17:41:19 -0000
Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;04 Sep 2007 17:41:19 -0000
Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 4 Sep 2007 17:41:19 -0000
Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id <L49PG0FR>; Tue, 4 Sep 2007 13:44:46 -0400
Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31DC6C@scygmxs1.cygnacom.com>
From: Carl Wallace <CWallace@cygnacom.com>
To: Vittek Robert <vittek@ditec.sk>, ietf-ltans@imc.org
Subject: RE: security issue in archive timestamp chain?
Date: Tue, 4 Sep 2007 13:44:37 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EF1B.43327F20"
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

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_01C7EF1B.43327F20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

There's no need to safeguard the validation data for ATS1 at the time =
ATS2
is applied.  The validation data can be preserved independently of the =
data
and retrieved using SCVP/ERS.  Amongst other benefits, this allows for =
a
grace period to be applied between the time ATS2 was generated and the =
time
of interest for validating the TSA1 credentials.   =20

> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org=20
> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Vittek Robert
> Sent: Tuesday, September 04, 2007 1:23 PM
> To: ietf-ltans@imc.org
> Subject: security issue in archive timestamp chain?
>=20
>=20
> We are currently implementing a long term electronic=20
> signature based on XAdES, so I went through TS 101 903, TS=20
> 101 733 and other RFCs that led me finaly to LTANS group=20
> because XAdES does not address the problem of validation of=20
> TSA certificates ("Rules for acceptance of the validity of=20
> the signature within the time-stamp, involving trust=20
> decisions, are out of the scope of the present document.").
>=20
> I am interested in solving the following problem.
>=20
> http://tools.ietf.org/html/rfc4998#section-5.3 states that:=20
> Each Archive Timestamp MUST be valid relative to the time of=20
> the following Archive Timestamp.
>=20
> Let's assume that we have Archive Time-Stamp 1 (ATS1) and we=20
> need to renew it and safeguard the validation data for ATS1=20
> at the same time. But the next Archive Time-Stamp 2 (ATS2)=20
> can prove existence only of the CRLs issued before time T2=20
> (from ATS2). ATS2 does NOT give any evidence that there was=20
> not another CRL2 (issued by CA that issued TSA1 certificate)=20
> which contained information on revocation of TSA1 certificate.
>=20
> I think that arbitration on validity of ATS1 might take place=20
> long after the archive of relevant CRLs is available and long=20
> after the used cryptography is strong enough, so the attacker=20
> might produce such CRL2 himself just to cast doubt upon the=20
> archived data.
>=20
> In other words: while T2 - safeguardedCRLforTSA1.thisUpdate >=20
> 0, arbitrator can not be sure that there was not another CRL2=20
> that listed TSA1 certificate.
>=20
> Am I missing something or is it a security issue?
>=20
>=20
> Mgr. Robert Vittek
>=20
> DITEC, a.s.
> Bratislava Business Center V
> Plyn=E1rensk=E1 7/C
> 821 09 Bratislava
>=20
> voice: +421 2 58 222 487
> fax: +421 2 58 222 777
> cell: +421 908 797 827
> mailto:vittek@ditec.sk
>=20

------_=_NextPart_001_01C7EF1B.43327F20
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: security issue in archive timestamp chain?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>There's no need to safeguard the validation data for =
ATS1 at the time ATS2 is applied.&nbsp; The validation data can be =
preserved independently of the data and retrieved using SCVP/ERS.&nbsp; =
Amongst other benefits, this allows for a grace period to be applied =
between the time ATS2 was generated and the time of interest for =
validating the TSA1 credentials.&nbsp;&nbsp;&nbsp; </FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: owner-ietf-ltans@mail.imc.org </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:owner-ietf-ltans@mail.imc.org">mailto:owner-ietf-ltans@ma=
il.imc.org</A>] On Behalf Of Vittek Robert</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, September 04, 2007 1:23 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: ietf-ltans@imc.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: security issue in archive timestamp =
chain?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We are currently implementing a long term =
electronic </FONT>
<BR><FONT SIZE=3D2>&gt; signature based on XAdES, so I went through TS =
101 903, TS </FONT>
<BR><FONT SIZE=3D2>&gt; 101 733 and other RFCs that led me finaly to =
LTANS group </FONT>
<BR><FONT SIZE=3D2>&gt; because XAdES does not address the problem of =
validation of </FONT>
<BR><FONT SIZE=3D2>&gt; TSA certificates (&quot;Rules for acceptance of =
the validity of </FONT>
<BR><FONT SIZE=3D2>&gt; the signature within the time-stamp, involving =
trust </FONT>
<BR><FONT SIZE=3D2>&gt; decisions, are out of the scope of the present =
document.&quot;).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I am interested in solving the following =
problem.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://tools.ietf.org/html/rfc4998#section-5.3" =
TARGET=3D"_blank">http://tools.ietf.org/html/rfc4998#section-5.3</A> =
states that: </FONT>
<BR><FONT SIZE=3D2>&gt; Each Archive Timestamp MUST be valid relative =
to the time of </FONT>
<BR><FONT SIZE=3D2>&gt; the following Archive Timestamp.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Let's assume that we have Archive Time-Stamp 1 =
(ATS1) and we </FONT>
<BR><FONT SIZE=3D2>&gt; need to renew it and safeguard the validation =
data for ATS1 </FONT>
<BR><FONT SIZE=3D2>&gt; at the same time. But the next Archive =
Time-Stamp 2 (ATS2) </FONT>
<BR><FONT SIZE=3D2>&gt; can prove existence only of the CRLs issued =
before time T2 </FONT>
<BR><FONT SIZE=3D2>&gt; (from ATS2). ATS2 does NOT give any evidence =
that there was </FONT>
<BR><FONT SIZE=3D2>&gt; not another CRL2 (issued by CA that issued TSA1 =
certificate) </FONT>
<BR><FONT SIZE=3D2>&gt; which contained information on revocation of =
TSA1 certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think that arbitration on validity of ATS1 =
might take place </FONT>
<BR><FONT SIZE=3D2>&gt; long after the archive of relevant CRLs is =
available and long </FONT>
<BR><FONT SIZE=3D2>&gt; after the used cryptography is strong enough, =
so the attacker </FONT>
<BR><FONT SIZE=3D2>&gt; might produce such CRL2 himself just to cast =
doubt upon the </FONT>
<BR><FONT SIZE=3D2>&gt; archived data.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In other words: while T2 - =
safeguardedCRLforTSA1.thisUpdate &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 0, arbitrator can not be sure that there was =
not another CRL2 </FONT>
<BR><FONT SIZE=3D2>&gt; that listed TSA1 certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Am I missing something or is it a security =
issue?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Mgr. Robert Vittek</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; DITEC, a.s.</FONT>
<BR><FONT SIZE=3D2>&gt; Bratislava Business Center V</FONT>
<BR><FONT SIZE=3D2>&gt; Plyn=E1rensk=E1 7/C</FONT>
<BR><FONT SIZE=3D2>&gt; 821 09 Bratislava</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; voice: +421 2 58 222 487</FONT>
<BR><FONT SIZE=3D2>&gt; fax: +421 2 58 222 777</FONT>
<BR><FONT SIZE=3D2>&gt; cell: +421 908 797 827</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"mailto:vittek@ditec.sk">mailto:vittek@ditec.sk</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C7EF1B.43327F20--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84HNShj091841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 10:23:28 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l84HNS9m091840; Tue, 4 Sep 2007 10:23:28 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mail.ditec.sk (mail.ditec.sk [82.119.228.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84HNPMI091830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 10:23:27 -0700 (MST) (envelope-from vittek@ditec.sk)
Received: from mail.intra.ditec.sk (mail.intra.ditec.sk [172.24.31.14]) by mail.ditec.sk (8.14.1/8.14.1) with ESMTP id l84HNT7X019745 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 19:23:29 +0200
Received: from mail.intra.ditec.sk ([172.24.31.14]) by mail.intra.ditec.sk ([172.24.31.14]) with mapi; Tue, 4 Sep 2007 19:23:24 +0200
From: Vittek Robert <vittek@ditec.sk>
To: "ietf-ltans@imc.org" <ietf-ltans@imc.org>
Date: Tue, 4 Sep 2007 19:23:22 +0200
Subject: security issue in archive timestamp chain?
Thread-Topic: security issue in archive timestamp chain?
Thread-Index: AcfvGEuAr2w+H7avRQGH41J2R5pvMw==
Message-ID: <E69DA98D5D34E54BB7B1CD6BB3EAB0680384BF6F5A@mail.intra.ditec.sk>
Accept-Language: en-US, sk-SK
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, sk-SK
Content-Type: text/plain; charset="iso-8859-2"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l84HNSMH091835
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

We are currently implementing a long term electronic signature based on XAdES, so I went through TS 101 903, TS 101 733 and other RFCs that led me finaly to LTANS group because XAdES does not address the problem of validation of TSA certificates ("Rules for acceptance of the validity of the signature within the time-stamp, involving trust decisions, are out of the scope of the present document.").

I am interested in solving the following problem.

http://tools.ietf.org/html/rfc4998#section-5.3 states that: Each Archive Timestamp MUST be valid relative to the time of the following Archive Timestamp.

Let's assume that we have Archive Time-Stamp 1 (ATS1) and we need to renew it and safeguard the validation data for ATS1 at the same time. But the next Archive Time-Stamp 2 (ATS2) can prove existence only of the CRLs issued before time T2 (from ATS2). ATS2 does NOT give any evidence that there was not another CRL2 (issued by CA that issued TSA1 certificate) which contained information on revocation of TSA1 certificate.

I think that arbitration on validity of ATS1 might take place long after the archive of relevant CRLs is available and long after the used cryptography is strong enough, so the attacker might produce such CRL2 himself just to cast doubt upon the archived data.

In other words: while T2 - safeguardedCRLforTSA1.thisUpdate > 0, arbitrator can not be sure that there was not another CRL2 that listed TSA1 certificate.

Am I missing something or is it a security issue?


Mgr. Robert Vittek

DITEC, a.s.
Bratislava Business Center V
Plynárenská 7/C
821 09 Bratislava

voice: +421 2 58 222 487
fax: +421 2 58 222 777
cell: +421 908 797 827
mailto:vittek@ditec.sk



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84HBThV090786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 10:11:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l84HBTaw090784; Tue, 4 Sep 2007 10:11:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84HBO5K090689 for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 10:11:27 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr)
Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id A0EBF39; Tue,  4 Sep 2007 19:11:19 +0200 (CEST)
Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11497-06; Tue,  4 Sep 2007 19:11:17 +0200 (CEST)
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id AFFB335; Tue,  4 Sep 2007 19:11:17 +0200 (CEST)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007090419111526:29051 ; Tue, 4 Sep 2007 19:11:15 +0200 
Message-ID: <46DD9104.9070401@edelweb.fr>
Date: Tue, 04 Sep 2007 19:08:20 +0200
From: Peter Sylvester <Peter.Sylvester@edelweb.fr>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: Thomas Kunz <thomas.kunz@sit.fraunhofer.de>
Cc: ietf-ltans@imc.org
Subject: Re: draft-ietf-ltans-dssc-00 comments
References: <886F5D4C78AFB14D87261206BFB9612E1D31D982@scygmxs1.cygnacom.com> <46DC965F.3040506@sit.fraunhofer.de>
In-Reply-To: <46DC965F.3040506@sit.fraunhofer.de>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 09/04/2007 07:11:15 PM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 09/04/2007 07:11:16 PM, Serialize complete at 09/04/2007 07:11:16 PM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000409010305040805090000"
X-Virus-Scanned: by amavisd-new at on-x.com
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a cryptographically signed message in MIME format.

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

I have a general comment concerning the use of open syntaxes concerning
the parameters of an algorithm.

I transpose the problem into an ASN.1 view which may be easier to
understand.

If one defines (in old syntax for simplicity) some syntax
like
     algopolicystuff ::= SEQUENCE
           { oid OJECT IDENTIFIER,
              specificforalogo ANY DEFINED BY ALGORITHM }

this creates problems for any routine that wants to check the actual
policy in the case of a new algorithm. One needs to compile code
into such algorithm for each new syntax.

But what is actually needed by a policy checker? it doesn't even
know keylength or hash size or whatever else. It only has to
know that  for each algorithm there are some values defined.

I think one should have an approach like in Mibs in SNMP so
one would say (now in XML) something like

   <Algorithm Name="urifor RSA" Oid="xxx">
     <param>1024</param>
     <param>4096</param>
   </Algorithm>

in a policy one would only specify value constraints parameters for an 
actual algorithms,
a kind of pattern which can always be checked, example
   first parameter must be greater than  1023, second less than 8192 or 
whatever.
An implementation of crypto algorithms
would provide a list of algorithm with the actual values of the parameters.

In the opposite direction, an implementation would also take a policy as
an input for example for key generation or signature validation. Even if an
implementation does provide smaller keys, one can tell it not to do so.

I am not sure whether I am suffiociently clear.
Peter



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC
BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G
A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs
UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx
CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ
S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu
ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ
IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c
IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID
AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5
MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT
VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD
VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F
ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV
HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA
A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb
zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8
oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN
rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi
XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ
TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q
M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd
UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw
MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp
Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA
ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL
PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2
pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3
0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl
Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl
ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F
ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ
RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI
hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS
J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct
BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx
RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl
X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo
ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3
6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py
UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL
MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL
STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0
MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj
ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI
hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M
ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe
1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt
qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd
UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH
pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS
cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB
CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0
dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C
AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV
HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3
UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy
4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz
QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u
US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj
PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq
Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf
Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y
rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6
PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL
d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18
k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg
d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD
VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ
S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwOTA0MTcwODIwWjAjBgkqhkiG9w0B
CQQxFgQUXZjFgG7BP24sszSai5sq3vb5EKIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY
MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy
c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE
ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ
IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGAyTq/249qpC9Iu84y
VQQlIe3tYMHC76egRb5myM/n8nztnK5LiSx++FVpP7y9gO1GUhs/M7daorc9RlZUfEeqLVur
IVWY8xAMuco9mOidaQoNO/it68j7pTWXI1R+b/B6a8otVf6RtTh/yT9W7yfL0lex4jAB9oUE
3oLLvotdEwUAAAAAAAA=
--------------ms000409010305040805090000--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84FBPun074870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 08:11:25 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l84FBPar074868; Tue, 4 Sep 2007 08:11:25 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84FBMMb074853 for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 08:11:23 -0700 (MST) (envelope-from tglassey@earthlink.net)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=cRprZDdkDXyWrNZl016ZjdW9YxzY4vi6YVXbuq1Bk5M0beB9T/yK18fkD0Qq8brF; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=gw) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1ISa3l-0003YQ-I4; Tue, 04 Sep 2007 11:11:21 -0400
Message-ID: <006d01c7ef05$de5c3bd0$174f7d40@home.glassey.com>
From: "todd glassey" <tglassey@earthlink.net>
To: "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>, "Carl Wallace" <CWallace@cygnacom.com>
Cc: <ietf-ltans@imc.org>
References: <886F5D4C78AFB14D87261206BFB9612E1D31D982@scygmxs1.cygnacom.com> <46DC965F.3040506@sit.fraunhofer.de>
Subject: Re: draft-ietf-ltans-dssc-00 comments
Date: Tue, 4 Sep 2007 08:11:16 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7924654a797bc837b12f9efb08acf4c237350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Thomas - vie gehts? I wanted to disagree to some extent and talk about this 
specific use model...

The reality of the matter is that a full chain-of-management headers MUST be 
included with each document showing any changes in the policies or keys used 
to demonstrate the integrity of the document controlled with LTANS...

More below.

----- Original Message ----- 
From: "Thomas Kunz" <thomas.kunz@sit.fraunhofer.de>
To: "Carl Wallace" <CWallace@cygnacom.com>
Cc: <ietf-ltans@imc.org>
Sent: Monday, September 03, 2007 4:18 PM
Subject: Re: draft-ietf-ltans-dssc-00 comments


> Carl Wallace schrieb:
>> <snip>
>>>> - The assumption in Section 3.2 that one must find an old policy in 
>>>> order to determine if an algorithm was valid at a point in
>>> the past is
>>>> too complicated.  Suitability definitions should accumulate in a single 
>>>> policy definition.  An enterprise could maintain several policies.  For 
>>>> example, one complete, one current and one
>>> past policy could be maintained.
>>> In our notion, the policies are published by specific institutions (e.g. 
>>> annually) and one policy represents the evaluations based on current 
>>> knowledge (e.g. on current findings, RSA with 1024 bit key length could 
>>> be valid until end of 2007, but next year a new policy could be 
>>> published which states that RSA 1024 is valid until end of 2008).
>>> To expect, that a policy also contains all past evaluations of an 
>>> algorithms could be error-prone.
>>> In our opinion, the question, if the evaluation of an algorithm in an 
>>> old policy is different from that in the current policy is primarily 
>>> important in law cases. And there you cannot trust, that the current 
>>> policy correctly quotes past evaluations, instead you will have to look 
>>> in the old policy.
>>
>> I wasn't suggesting that a policy contain all past evaluations.

I Was - the policy header needs to for legal reasons track the document and 
its original content/signing as well as any changes made to that document 
allong the way including any instances where policies changed or just 
expired. All of these MUST be a part of the Long Term Management structures 
that any and all documents are controlled by or a full chain of custody will 
not be demonsterable and the outcome of the LTANS system will be 'hear-say' 
based on the Federal Rules of Evidence, the Federal Rules of Civil 
Procedure, and a ruling of the District Court of Maryland in the US Federal 
District Courts called Lorraine v Markel from May 4th 2007.

>> I was
>> suggesting that the current policy would contain the current position 
>> with
>> regard to an algorithm's life span, even if the algorithm is no longer
>> viable, and that's the only thing that matters.  I don't see the value in
>> referring to an old policy since the position on an algorithm can change
>> over time.  Using your example, in my opinion, the only thing that 
>> matters
>> to the verifier is what the current position is with regard to an 
>> algorithm.
>> The fact that an algorithm's expected life span at the time a signature 
>> was
>> generated was thought to be shorter than it turned out to be isn't
>> important.
> OK, I agree. Since our data structures allow this anyway, we will 
> recommend for an easy policy handling that a policy should also contain 
> the evaluations of all algorithms which are no longer valid. But it's up 
> to the publisher to decide to do so.
>
> But never the less, in our opinion there is at least one case for 
> consulting old policies:

You mean the period's around "the time when all instances of old-policy 
reliance are flushed out"... i.e. that period of overlap when due to other 
policies, the relying parties do not refresh their operating integrity 
entitlement....

I dont think that this is a valid use. Its possible if a number of other 
policies are broken but the LTANS operator must be ready to address that 
certain signatures or policies may become invalid based on their 
technologies being cracked at a level which creates a real and palpable risk 
or they just expire based on their exceeding their timebase lives.

> Assume the current (2007) policy states that RSA 1024 is valid until end 
> of 2008. Because of this policy, an archive service today doesn't renew 
> signatures created with RSA 1024.

Uh - then the Operator has a problem I think and their integrity of 
operations model is broken based on the first instance when something that 
they relied on was made retroactively invalid. LTANS must have a restamping 
process built into it to address changes in document policy and access 
controls as well as regeneration events around accessing the document or 
demonstrating its integrity.

> Next year (2008), a new policy will be published which retroactively 
> repositions the validity of RSA 1024: The new policy states that RSA 1024 
> has only been valid until mid of 2007.


This is a SEVERE problem. NO policy control model should have a hole this 
big in it. There is NO reason to 'after the fact' re-stamp documents as no 
longer being valid after a certain time frame unless there was a 
technological hack and there is a very good probability (not just a 
possibility) that those documents are either altered or are fakes.

Remeber that these are documents stored for historical purposes and that in 
the instance of a policy or a key, that the object isnt good anymore is 
irrelevant to whether the key was good when the document was stored, and to 
whether functionally is capable of being used whether its valid or not based 
on some time-specific expiry.

> That means, in 2007 RSA 1024 signatures could have been forged and 
> therefore the archive service should have done the renewal already in 
> 2007.

Mechanically yes, but in reality no... those signatures are controlled by a 
number of external and internal processes which (while possible) will make 
it very very unlikely that those signatures were forged.

> Now in 2008 the archive service must attest that he acted correctly and 
> that he fulfilled his duty to take care although he has not timely renewed 
> the RSA 1024 signatures.

The failure of the timely renewall of the RSA 1024 Bit signatures FOR ANY 
REASON invalidates that operator's status as being a competent operator one 
would think.

> And therefore he needs the old (2007) policy which says that according to 
> the knowledge at that time, the algorithm was valid and he acted 
> correctly. He cannot use the current (2008) policy because this policy 
> states that the algorithm has only been valid until mid 2007.

So this isnt an issue about policy expiry, its a use model issue... this is 
WHY a formal set of use models MUST be drafted for this type of thing. It 
also might help to have someone with any real-world audit responsibility on 
this panel because its pretty clear that this is a panel of technologists 
building what they through public argument are negotiating that the 
Auditor's need and its yet another instance where the IETF built technology 
for solving a problem it wasnt on-track "as to what the actual problem is".

See what I mean?

T


>
>
> Regards
> Thomas
>
>
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84AgGij040899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 03:42:16 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l84AgGAZ040898; Tue, 4 Sep 2007 03:42:16 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84AgDxc040886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 03:42:15 -0700 (MST) (envelope-from susanne.okunick@sit.fraunhofer.de)
Received: from [141.12.89.207] (sitp2_188.sit.fraunhofer.de [141.12.69.188]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id l84AgBKK027784; Tue, 4 Sep 2007 12:42:11 +0200
Subject: Re: draft-ietf-ltans-dssc-00 comments
From: Susanne Okunick <susanne.okunick@sit.fraunhofer.de>
To: Carl Wallace <CWallace@cygnacom.com>
Cc: ietf-ltans@imc.org
In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31D6B9@scygmxs1.cygnacom.com>
References: <886F5D4C78AFB14D87261206BFB9612E1D31D6B9@scygmxs1.cygnacom.com>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-7U757pOBhgE9K6+eiJ56"
Date: Tue, 04 Sep 2007 12:43:12 +0200
Message-Id: <1188902592.5727.50.camel@pc-arwen>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1 
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

--=-7U757pOBhgE9K6+eiJ56
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

> - If an ASN.1 version is to be produced, using an enveloping signature
> would make the mapping to CMS easier.
Because of better readability for the XML policy definition I still
prefer the enveloped signature, unless the difference to CMS (enveloping
signature) offers a problem.

Regards, Susanne Okunick

--=20
___________________________________________________________

Dipl.-Math.(FH) Susanne Okunick
Fraunhofer Institute for Secure Information Technology
Department Transaction and Document Security
Rheinstra=C3=9Fe 75, 64295 Darmstadt, Germany
phone ++49 / (0)6151 869 60005, fax ++49 / (0)6151 869 322
homepage: http://www.sit.fraunhofer.de

--=-7U757pOBhgE9K6+eiJ56
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFuzCCBbcw
ggSfoAMCAQICAg8yMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1
bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyMB4XDTA1
MTAwNjE0MDQwMVoXDTA5MTIzMTIzMDAwMFowWzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu
aG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRgwFgYDVQQDEw9TdXNhbm5lIE9r
dW5pY2swggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCixKdSLwHlBFCBau215sA8INJp
6zEcpvmq4p3oUk3h3IOY2Ph4+8XJuCUzO2f6/vwfL4AVMUcV4h2YqgMDJ2y8rahOtU4WZW8k10Cd
QE7VbPFF6U+unvGuizJZFZb3k0Kbs2FUzJ2hP5sjlb0tnW15NPFivRs764hwTzzRjiPYTKAc0MOv
2hR/8mgp6Oso6cQE2GA/sgkhzRXzY00FjFwvbKcvMx+3Ww1sd66GN6Y5A5YXjIahntdPBFxWq/5O
sf9rMUodghMQUXJNkyw5Pt+sNnEYiFrQZF2PtqPq57EGeQ7Yh50ZNEzQZUOWoHgtat7m0nD9a7f4
aXEMlrG1VZrBAgMBAAGjggKPMIICizCBoAYJYIZIAYb4QgENBIGSFoGPU29mdHdhcmUtWmVydGlm
aWthdCBkZXIgWmVydGlmaXppZXJ1bmdzaW5zdGFueiAoQ0EpIGRlciBGcmF1bmhvZmVyLUdlc2Vs
bHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVsemVydGlmaWthdCB2aWEgaHR0cHM6Ly9wa2ku
ZnJhdW5ob2Zlci5kZS8wTQYIKwYBBQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZy
YXVuaG9mZXIuZGUvRmhHLUNBX3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0
dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwDAYD
VR0TAQH/BAIwADBKBgNVHRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIu
ZGWGGWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wLAYDVR0RBCUwI4Ehc3VzYW5uZS5va3VuaWNr
QHNpdC5mcmF1bmhvZmVyLmRlMEwGA1UdIARFMEMwQQYLKwYBBAGGClACAQEwMjAwBggrBgEFBQcC
ARYkaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlL3BvbGljeS5odG1sMCcGA1UdJQQgMB4GCCsGAQUF
BwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgbAMB0GA1UdDgQWBBREDzmsUZxs
4FvzGJN5Y4eWpmaoNDAfBgNVHSMEGDAWgBQAw/zvY8JWKC9RC3VW/3sF6RzJ8TANBgkqhkiG9w0B
AQUFAAOCAQEAXPZIkjp87kqTdv/8oj2kyTXD4eix2OtEpXiKbgrfb0ErWwe60cymp5hrgdScw/Y8
TXvk+nYwt0OvWCnOG+QhBLyJdgvDiS5DiXjQPVtb/rCPTsJPuXXVCyQQfTdQ1smSmvrGQROTMPzG
DYu3iWtQnPrSx/vtdIZcAng29T81nkEr7FCVn3FxDA2ZzbPBR3g5L320t6hSKYxFssVBvZKOVmQm
hFePgIyXz7n6Yto39/48knrLF4uGwSzKvdPOeW3CLhdn5BAAuP+2vD9L5UI+fXEOAfYJTckUV4kq
bM4tyosNR6QrE5tK+ygV+Hk5CfQ4EIhixR+LBX+ry73zSpKzozGCAdswggHXAgEBMFUwTzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxs
c2NoYWZ0IFJvb3QtQ0EgdjICAg8yMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA5MDQxMDQzMTJaMCMGCSqGSIb3DQEJBDEWBBTscG90PC7E
fJsiyysxUO9VsMe9MTANBgkqhkiG9w0BAQEFAASCAQAOW5iwXBGx4tSG8HddMOCIjpg1VJ+TFdzv
hvD8ZcD8MBYqNMD2Su15cU2Gsh9EBaxZXPBnzlGgfHCqzvt+aVB2bhVAJI3ptXnjrmNkaXoviW/y
H+xfeB8/WOeo0DTkrZLi87TPeMOnZRgArQ7H77LydGv4Ox3rHurrhtgcoAxjX0yOJACGbdTxprUL
RjNojySRrUG/nJadY/9epofX/Ni3NIN/Ux73ZvcVwSvEO/r05tEQZPl6G0B+xgnF2UyT7a/X8XOr
3Obb7dnnfS758wE3siyoyeFTX/+fVfY5J3tttCGDZu/i57fJLhWqPKxiiS2j5kzXem/0//O+Fm3d
zha5AAAAAAAA


--=-7U757pOBhgE9K6+eiJ56--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84AS7au039203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 03:28:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l84AS7AI039202; Tue, 4 Sep 2007 03:28:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l84AS1p5039191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 03:28:05 -0700 (MST) (envelope-from susanne.okunick@sit.fraunhofer.de)
Received: from [141.12.89.207] (sitp2_188.sit.fraunhofer.de [141.12.69.188]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id l84ARvpi027170 for <ietf-ltans@imc.org>; Tue, 4 Sep 2007 12:27:57 +0200
Subject: draft-ietf-ltans-dssc-00 comments --constraints--
From: Susanne Okunick <susanne.okunick@sit.fraunhofer.de>
To: ietf-ltans@imc.org
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-1L0PyY388YcKWqnyWTYE"
Date: Tue, 04 Sep 2007 12:28:58 +0200
Message-Id: <1188901738.5727.39.camel@pc-arwen>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.1 
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

--=-1L0PyY388YcKWqnyWTYE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

for now we could define current constraints for public key algorithm and
give a guidance how to process/interprete them. A guidance may be: a
modulus (for RSA) greater than 1024 is as suitable as the modulus 1024
itself.

But what about algorithms that are unknown till now? If an algorithm
occurs as recently as in the future someone else has to define the new
constraints, e. g. the publisher of a policy, expert committees or even
a new RFC.

Advantage for giving a definition: On the basis of the draft the
operator/user is directly able to write/interpret a policy. But: Perhaps
it suffices only to give an example for current contraints in this
draft.

What do you think about this problem?

Best regards
Susanne Okunick

--=20
___________________________________________________________

Dipl.-Math.(FH) Susanne Okunick
Fraunhofer Institute for Secure Information Technology
Department Transaction and Document Security
Rheinstra=C3=9Fe 75, 64295 Darmstadt, Germany
phone ++49 / (0)6151 869 60005, fax ++49 / (0)6151 869 322
homepage: http://www.sit.fraunhofer.de
___________________________________________________________

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFuzCCBbcw
ggSfoAMCAQICAg8yMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1
bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyMB4XDTA1
MTAwNjE0MDQwMVoXDTA5MTIzMTIzMDAwMFowWzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu
aG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRgwFgYDVQQDEw9TdXNhbm5lIE9r
dW5pY2swggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCixKdSLwHlBFCBau215sA8INJp
6zEcpvmq4p3oUk3h3IOY2Ph4+8XJuCUzO2f6/vwfL4AVMUcV4h2YqgMDJ2y8rahOtU4WZW8k10Cd
QE7VbPFF6U+unvGuizJZFZb3k0Kbs2FUzJ2hP5sjlb0tnW15NPFivRs764hwTzzRjiPYTKAc0MOv
2hR/8mgp6Oso6cQE2GA/sgkhzRXzY00FjFwvbKcvMx+3Ww1sd66GN6Y5A5YXjIahntdPBFxWq/5O
sf9rMUodghMQUXJNkyw5Pt+sNnEYiFrQZF2PtqPq57EGeQ7Yh50ZNEzQZUOWoHgtat7m0nD9a7f4
aXEMlrG1VZrBAgMBAAGjggKPMIICizCBoAYJYIZIAYb4QgENBIGSFoGPU29mdHdhcmUtWmVydGlm
aWthdCBkZXIgWmVydGlmaXppZXJ1bmdzaW5zdGFueiAoQ0EpIGRlciBGcmF1bmhvZmVyLUdlc2Vs
bHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVsemVydGlmaWthdCB2aWEgaHR0cHM6Ly9wa2ku
ZnJhdW5ob2Zlci5kZS8wTQYIKwYBBQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZy
YXVuaG9mZXIuZGUvRmhHLUNBX3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0
dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwDAYD
VR0TAQH/BAIwADBKBgNVHRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIu
ZGWGGWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wLAYDVR0RBCUwI4Ehc3VzYW5uZS5va3VuaWNr
QHNpdC5mcmF1bmhvZmVyLmRlMEwGA1UdIARFMEMwQQYLKwYBBAGGClACAQEwMjAwBggrBgEFBQcC
ARYkaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlL3BvbGljeS5odG1sMCcGA1UdJQQgMB4GCCsGAQUF
BwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgbAMB0GA1UdDgQWBBREDzmsUZxs
4FvzGJN5Y4eWpmaoNDAfBgNVHSMEGDAWgBQAw/zvY8JWKC9RC3VW/3sF6RzJ8TANBgkqhkiG9w0B
AQUFAAOCAQEAXPZIkjp87kqTdv/8oj2kyTXD4eix2OtEpXiKbgrfb0ErWwe60cymp5hrgdScw/Y8
TXvk+nYwt0OvWCnOG+QhBLyJdgvDiS5DiXjQPVtb/rCPTsJPuXXVCyQQfTdQ1smSmvrGQROTMPzG
DYu3iWtQnPrSx/vtdIZcAng29T81nkEr7FCVn3FxDA2ZzbPBR3g5L320t6hSKYxFssVBvZKOVmQm
hFePgIyXz7n6Yto39/48knrLF4uGwSzKvdPOeW3CLhdn5BAAuP+2vD9L5UI+fXEOAfYJTckUV4kq
bM4tyosNR6QrE5tK+ygV+Hk5CfQ4EIhixR+LBX+ry73zSpKzozGCAdswggHXAgEBMFUwTzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxs
c2NoYWZ0IFJvb3QtQ0EgdjICAg8yMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA5MDQxMDI4NThaMCMGCSqGSIb3DQEJBDEWBBQR8dYc/OHX
9+CfUMxf5MBcLcFNmjANBgkqhkiG9w0BAQEFAASCAQCVAzUjSse26NEmuEU1JoGUTkUxjztrCQDr
p9+L3geWr9VOhJ72y8wK9DmzJwd86xCgMQhtl8ItcPQMKztaZkwYO0MKfVNf/nQaxgsjaF6c47VA
uVuSAAJahNa2Hv7z2OG13BqjktkkvSpXQ2tma5AGv0Ng5xnOeLiK1HqsNP5R52/vawGHx2k1EZUQ
Yt8AIrVSFv4RSwiQJxMGXA26LohEWsc58ksu5TpfW0U5lqMzVHQWbf/KjRCD4tk5DYA7jJgU0f6y
fVlJ7B9wrWLH5+JmWAU4uU2Stldu0+e2B3aIXlGcIur1zS2htcvdA9oLLRXrnA3+j9eLViqv7gst
zOBDAAAAAAAA


--=-1L0PyY388YcKWqnyWTYE--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l83NJIid074888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Sep 2007 16:19:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l83NJI8Q074887; Mon, 3 Sep 2007 16:19:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l83NJF0I074875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-ltans@imc.org>; Mon, 3 Sep 2007 16:19:17 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de)
Received: from [141.12.111.2] (vpnsit2_2.sit.fraunhofer.de [141.12.111.2]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id l83NJ2be029757; Tue, 4 Sep 2007 01:19:03 +0200
Message-ID: <46DC965F.3040506@sit.fraunhofer.de>
Date: Tue, 04 Sep 2007 01:18:55 +0200
From: Thomas Kunz <thomas.kunz@sit.fraunhofer.de>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Carl Wallace <CWallace@cygnacom.com>
CC: ietf-ltans@imc.org
Subject: Re: draft-ietf-ltans-dssc-00 comments
References: <886F5D4C78AFB14D87261206BFB9612E1D31D982@scygmxs1.cygnacom.com>
In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31D982@scygmxs1.cygnacom.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070100010803040501070603"
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a cryptographically signed message in MIME format.

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

Carl Wallace schrieb:
> <snip>
>>> - The assumption in Section 3.2 that one must find an old policy in 
>>> order to determine if an algorithm was valid at a point in 
>> the past is 
>>> too complicated.  Suitability definitions should accumulate in a 
>>> single policy definition.  An enterprise could maintain several 
>>> policies.  For example, one complete, one current and one 
>> past policy could be maintained.
>> In our notion, the policies are published by specific 
>> institutions (e.g. 
>> annually) and one policy represents the evaluations based on 
>> current knowledge (e.g. on current findings, RSA with 1024 
>> bit key length could be valid until end of 2007, but next 
>> year a new policy could be published which states that RSA 
>> 1024 is valid until end of 2008).
>> To expect, that a policy also contains all past evaluations 
>> of an algorithms could be error-prone.
>> In our opinion, the question, if the evaluation of an 
>> algorithm in an old policy is different from that in the 
>> current policy is primarily important in law cases. And there 
>> you cannot trust, that the current policy correctly quotes 
>> past evaluations, instead you will have to look in the old policy.
> 
> I wasn't suggesting that a policy contain all past evaluations.  I was
> suggesting that the current policy would contain the current position with
> regard to an algorithm's life span, even if the algorithm is no longer
> viable, and that's the only thing that matters.  I don't see the value in
> referring to an old policy since the position on an algorithm can change
> over time.  Using your example, in my opinion, the only thing that matters
> to the verifier is what the current position is with regard to an algorithm.
> The fact that an algorithm's expected life span at the time a signature was
> generated was thought to be shorter than it turned out to be isn't
> important.  
> 
OK, I agree. Since our data structures allow this anyway, we will 
recommend for an easy policy handling that a policy should also contain 
the evaluations of all algorithms which are no longer valid. But it's up 
to the publisher to decide to do so.

But never the less, in our opinion there is at least one case for 
consulting old policies:
Assume the current (2007) policy states that RSA 1024 is valid until end 
of 2008. Because of this policy, an archive service today doesn't renew 
signatures created with RSA 1024.
Next year (2008), a new policy will be published which retroactively 
repositions the validity of RSA 1024: The new policy states that RSA 
1024 has only been valid until mid of 2007. That means, in 2007 RSA 1024 
signatures could have been forged and therefore the archive service 
should have done the renewal already in 2007.
Now in 2008 the archive service must attest that he acted correctly and 
that he fulfilled his duty to take care although he has not timely 
renewed the RSA 1024 signatures. And therefore he needs the old (2007) 
policy which says that according to the knowledge at that time, the 
algorithm was valid and he acted correctly. He cannot use the current 
(2008) policy because this policy states that the algorithm has only 
been valid until mid 2007.



Regards
Thomas



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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCC
BacwggSPoAMCAQICAgDfMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK
EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB
IHYyMB4XDTA0MDYwOTA3MzQyM1oXDTA4MTIzMTIzMDAwMFowVzELMAkGA1UEBhMCREUxEzAR
BgNVBAoTCkZyYXVuaG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRQwEgYD
VQQDEwtUaG9tYXMgS3VuejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALFclK+E
n2p85uM4bbfxKqpHBUOd9qSCNnuPcITixktM7A1rRmbu1nbQcppKj40Bjv/rOqTavvux1oiS
O+mzrOq9Aa0MmjPyFpjcPOK62EaGFMNuHx7cafnLe4Y8EJcdl9RZdBO+SY/2gr5wq9/jvaaF
fkU0Q+5iY4NS2/nLZ2mYaqRI2wCxaLAMyfJYL4z5/qEW51KTQ0LHHm9qiVZg2hempXSMABC9
6/BzYKwaGMh0vaSCppUFdJvhVNwAUHsUkosNTFiU9ks2fIpzlNPJv7UE8wfTrCzAf4CBgWTA
jHXJdgaAF2rD0JjbbpA/G1w3rAT8yKy3mfljJOcLcuUZYBMCAwEAAaOCAoMwggJ/MIGeBglg
hkgBhvhCAQ0EgZAWgY1Tb2Z0d2FyZSBaZXJ0aWZpa2F0IGRlciBaZXJ0aWZpemllcnVuZ2lu
c3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNoZW47
IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wTQYIKwYB
BQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvRmhHLUNB
X3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9wa2kuZnJhdW5o
b2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwCQYDVR0TBAIwADBKBgNV
HRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIuZGWGGWh0dHA6Ly9w
a2kuZnJhdW5ob2Zlci5kZS8wKAYDVR0RBCEwH4EddGhvbWFzLmt1bnpAc2l0LmZyYXVuaG9m
ZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8v
cGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsG
AQUFBwMDBggrBgEFBQcDBDALBgNVHQ8EBAMCA/gwHQYDVR0OBBYEFAT5q7Rw9gTlubggX/wN
+6oZowK3MB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0GCSqGSIb3DQEBBQUA
A4IBAQDoyyNHTB3tv3kVsap2axcaFKsKwzTNqq/bnj+a6VFpy5ejBbtusHG8njqa+LheRT/k
Vi6xFYFXegw54Cf6IGCJ2E1EBWfgJXqyaO+PgUggd6bLOy/8fZauR1oIlt4nQNjoXyJxqV9x
tpgxZsF7pHtqcwh4ZYA+nsEC6DdCfsUqegrqzmtA7hZ34o3yeZCR5qs3M9jja3lw9KfxnbHh
6CM/vM7o6KIEFdx8RlIWpYEJB05rqMO7PrXiRrmJDHeCwRtx+R5iskUX3grhh6yHBRM1NKHx
LY/waDKxBj3ZXPSkN0k7PBppeuYHgJ4ZVAuvP9v2GKkyU3pHOcwE5iZOiQyNMIIFpzCCBI+g
AwIBAgICAN8wDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu
aG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjIwHhcN
MDQwNjA5MDczNDIzWhcNMDgxMjMxMjMwMDAwWjBXMQswCQYDVQQGEwJERTETMBEGA1UEChMK
RnJhdW5ob2ZlcjEMMAoGA1UECxMDU0lUMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1Ro
b21hcyBLdW56MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsVyUr4Sfanzm4zht
t/EqqkcFQ532pII2e49whOLGS0zsDWtGZu7WdtBymkqPjQGO/+s6pNq++7HWiJI76bOs6r0B
rQyaM/IWmNw84rrYRoYUw24fHtxp+ct7hjwQlx2X1Fl0E75Jj/aCvnCr3+O9poV+RTRD7mJj
g1Lb+ctnaZhqpEjbALFosAzJ8lgvjPn+oRbnUpNDQsceb2qJVmDaF6aldIwAEL3r8HNgrBoY
yHS9pIKmlQV0m+FU3ABQexSSiw1MWJT2SzZ8inOU08m/tQTzB9OsLMB/gIGBZMCMdcl2BoAX
asPQmNtukD8bXDesBPzIrLeZ+WMk5wty5RlgEwIDAQABo4ICgzCCAn8wgZ4GCWCGSAGG+EIB
DQSBkBaBjVNvZnR3YXJlIFplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5naW5zdGFueiAo
Q0EpIGRlciBGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVs
emVydGlmaWthdCB2aWEgaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlLzBNBggrBgEFBQcBAQRB
MD8wPQYIKwYBBQUHMAGGMWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0FfdjJfT0NT
UC1SZXNwb25kZXIwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL3BraS5mcmF1bmhvZmVyLmRl
L0ZoRy1DQS1DZXJ0cy9GaEctQ0FfdjJfQ1JMLmNybDAJBgNVHRMEAjAAMEoGA1UdEgRDMEGB
JHplcnRpZml6aWVydW5nc2luc3RhbnpAZnJhdW5ob2Zlci5kZYYZaHR0cDovL3BraS5mcmF1
bmhvZmVyLmRlLzAoBgNVHREEITAfgR10aG9tYXMua3VuekBzaXQuZnJhdW5ob2Zlci5kZTBM
BgNVHSAERTBDMEEGCysGAQQBhgpQAgEBMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly9wa2kuZnJh
dW5ob2Zlci5kZS9wb2xpY3kuaHRtbDAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMG
CCsGAQUFBwMEMAsGA1UdDwQEAwID+DAdBgNVHQ4EFgQUBPmrtHD2BOW5uCBf/A37qhmjArcw
HwYDVR0jBBgwFoAUAMP872PCVigvUQt1Vv97BekcyfEwDQYJKoZIhvcNAQEFBQADggEBAOjL
I0dMHe2/eRWxqnZrFxoUqwrDNM2qr9ueP5rpUWnLl6MFu26wcbyeOpr4uF5FP+RWLrEVgVd6
DDngJ/ogYInYTUQFZ+AlerJo74+BSCB3pss7L/x9lq5HWgiW3idA2OhfInGpX3G2mDFmwXuk
e2pzCHhlgD6ewQLoN0J+xSp6CurOa0DuFnfijfJ5kJHmqzcz2ONreXD0p/GdseHoIz+8zujo
ogQV3HxGUhalgQkHTmuow7s+teJGuYkMd4LBG3H5HmKyRRfeCuGHrIcFEzU0ofEtj/BoMrEG
Pdlc9KQ3STs8Gml65geAnhlUC68/2/YYqTJTekc5zATmJk6JDI0xggL/MIIC+wIBATBVME8x
CzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVy
LUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zAJBgUrDgMCGgUAoIIBfzAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA5MDMyMzE4NTVaMCMGCSqGSIb3
DQEJBDEWBBT2ll9S4pTls5ce3lKZpiespB57SjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3
DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D
AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv
ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm
BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx
KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG
SIb3DQEBAQUABIIBABKiGS1eVNCQDsE9kZR+/ECzcBONayt1BvkGbEZeDFctMAs8fK7W7CsB
p7TK8HzaBBZiv6+7+CKxFt/ttm1qNSpbap4zF7AUGuDVIgSNuDssbIo8H8xLBm1ecUlHAbQy
UAqG5kn4QvgyuoCdIY5opbujDWi7npmNogMfnHx3WxCek53yxXrKxqCTf13+webc4Jc9EWzS
WubWaHMLrSQ4xED25sdsatect4OjFq5qppYAaPqgPlG4BQbhjN7qlL2Hs5ax5jYlNbMRZaO1
1kmbgp26SiNHW3gOU5T2jwlPBlf6zhwcgyKu0Elzq/m6aa02EUe4S2erf8E3X/SkrCKHYPAA
AAAAAAA=
--------------ms070100010803040501070603--