Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QNB1lO027257; Wed, 26 Oct 2005 16:11:01 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QNB1QI027256; Wed, 26 Oct 2005 16:11:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QNB0F7027243 for ; Wed, 26 Oct 2005 16:11:00 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j9QNAswS011155; Wed, 26 Oct 2005 19:10:55 -0400 From: "Santosh Chokhani" To: "'Tobias Gondrom'" Cc: Subject: RE: Suggested Topic for LTANS WG Meeting Date: Wed, 26 Oct 2005 19:10:49 -0400 Message-ID: <004901c5da82$841ffe20$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01C5DA60.FD0E5E20" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <3C1BE8610E44734499EF92FB35F5B070013E15B0@MUCXGC1.opentext.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_004A_01C5DA60.FD0E5E20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tobias, =20 I do not propose this as an I-D. I simply wanted to brainstorm the = idea. I have vetted the scheme with a crypto math person. The scheme's = principal drawback is that it is slower than what is desired of hash functions. = But, in long term archive, the performance penalty may be worth paying if it protects against structural problems with today's hash functions (be it = SHA series or MD series) as some have alluded to. That is what motivated to figure this out since I am not a crypto math person and not qualified to invent new hashing paradigms. =20 Here is a description of the scheme: =20 Let us a say you want to sign message M. You create M' =3D M | random = key K. That is concatenate key K with M. This step is optional. Now, you = perform CBC encryption of M'. Let us call this E. Next you sign E, i.e., = calculate the of hash E and compute a digital signature on it. Assume that the signature us S. Now, the signed object is M', S. =20 We can send key K as part of SIGNED MACRO since the whole thing can be considered new signature algorithm and thus whatever signature algorithm = you were using, the new algorithm OID can use that syntax with an extra = value of encryption key K in the SEQUENCE. =20 The recipient can use the key from the SIGNED MACRO or from M', encrypt = M' to get E and get the hash of E. Now, depending on the signature = algorithm, verification can occur. =20 -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Wednesday, October 26, 2005 1:36 PM To: Santosh Chokhani Cc: ietf-ltans@imc.org Subject: RE: Suggested Topic for LTANS WG Meeting Importance: Low Hi Santosh, =20 Sounds interesting, also I am not fully sure that I can follow the = scheme completely.=20 (small remark: I consider signing algs most of the time more in danger = of being broken than hash) =20 Definitely vote for putting on the agenda as "informational" to the WG, = if Carl can spare the 5-10 minutes from the meeting time? =20 Probably you could describe this with a few more words here on the = Mailing list (not ID) just a few more lines? =20 Regards and Thanks, Tobias =20 =20 _____ =20 From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Monday, October 24, 2005 11:15 PM To: ietf-ltans@imc.org Subject: Suggested Topic for LTANS WG Meeting =20 I have an idea that makes it harder to exploit SHA-1 collision. The = idea can be applied to PKI objects such as certificates, CRLs, OCSP = responses, SCVP responses, signed application objects, etc. =20 I do not know if this has been discussed before in any forum. =20 The idea is to generate a random key, encrypt the structure, hash the encrypted structure and sign the structure with the random key in it. = As an alternative, the random key may be appended to the structure, prior to encryption. Thus, if you want to sign X, you will do the following: =20 1. Generate a random key K 2. Append K to X (optional) 3. Encrypt the outcome of step 2 using K 4. Hash the outcome of step 3 5. Sign the hash 6. Your object is X, K, signature =20 There are ways to include K in the SIGNED MACRO that Carl Wallace has explored. Carl can describe those also. =20 I think this should be discussed for 5-10 minutes. If you agree, Carl Wallace would present since I will not be able to attend this IETF = meeting. Santosh Chokhani=20 Orion Security Solutions, Inc.=20 1489 Chain Bridge Road, Suite 300=20 McLean, Virginia 22101=20 (703) 917-0060 Ext. 35 (voice)=20 (703) 917-0260 (Fax)=20 chokhani@orionsec.com=20 Visit our Web site=20 http://www.orionsec.com =20 =20 ------=_NextPart_000_004A_01C5DA60.FD0E5E20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Tobias,
 
I do not propose this as an I-D.  I simply wanted to = brainstorm the=20 idea.  I have vetted the scheme with a crypto math = person. =20 The scheme's principal drawback is that it is slower than what is = desired of=20 hash functions.  But, in long term archive, the performance penalty = may be=20 worth paying if it protects against structural problems with today's = hash=20 functions (be it SHA series or MD series) as some have alluded to.  = That is=20 what motivated to figure this out since I am not a crypto math person = and not=20 qualified to invent new hashing paradigms.
 
Here is a description of the = scheme:
 
Let us a say you want to sign message M.  You create M' = =3D M | random=20 key K.  That is concatenate key K with M.  This step is=20 optional.  Now, you perform CBC encryption of M'.  Let us call = this=20 E.  Next you sign E, i.e., calculate the of hash E and compute a = digital=20 signature on it.  Assume that the signature us S.  Now, the = signed=20 object is M', S.
 
We can send key K as part of SIGNED MACRO since the whole thing = can be=20 considered new signature algorithm and thus whatever signature algorithm = you=20 were using, the new algorithm OID can use that syntax with an extra = value of=20 encryption key K in the SEQUENCE.
 
The recipient can use the key from the SIGNED MACRO or from M', = encrypt=20 M' to get E and get the hash of E.  Now, depending on the signature = algorithm, verification can occur.
 
-----Original Message-----
From: = owner-ietf-ltans@mail.imc.org=20 [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias=20 Gondrom
Sent: Wednesday, October 26, 2005 1:36 = PM
To:=20 Santosh Chokhani
Cc: ietf-ltans@imc.org
Subject: RE: = Suggested Topic for LTANS WG Meeting
Importance:=20 Low

Hi=20 Santosh,

 

Sounds = interesting,=20 also I am not fully sure that I can follow the scheme completely.=20

(small = remark: I=20 consider signing algs most of the time more in danger of being broken = than=20 hash)

 

Definitely = vote for=20 putting on the agenda as “informational” to the WG, if = Carl can spare the 5-10=20 minutes from the meeting time?

 

Probably = you could=20 describe this with a few more words here on the Mailing list (not ID) = just a=20 few more lines?

 

Regards and = Thanks,=20 Tobias

 

 

From:=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On Behalf Of Santosh = Chokhani
Sent: Monday, October 24, 2005 = 11:15=20 PM
To:=20 ietf-ltans@imc.org
Subject:=20 Suggested Topic for LTANS WG = Meeting

 

I have an idea that = makes it=20 harder to exploit SHA-1 collision.  The idea can be applied to = PKI=20 objects such as certificates, CRLs, OCSP responses, SCVP responses, = signed=20 application objects, etc.

 

I do not know if this = has been=20 discussed before in any forum.

 

The idea is to generate = a random=20 key, encrypt the structure, hash the encrypted structure and sign the=20 structure with the random key in it.  As an alternative, the = random key=20 may be appended to the structure, prior to encryption.  Thus, if = you want=20 to sign X, you will do the = following:

 

1.  Generate a = random key=20 K

2.  Append K to X=20 (optional)

3.  Encrypt the = outcome of=20 step 2 using K

4.  Hash the = outcome of step=20 3

5.  Sign the=20 hash

6.  Your object is = X, K,=20 signature

 

There are ways to = include K in the=20 SIGNED MACRO that Carl Wallace has explored.  Carl can describe = those=20 also.

 

I think this should be = discussed=20 for 5-10 minutes.  If you agree, Carl Wallace would present since = I will=20 not be able to attend this IETF = meeting.

Santosh=20 Chokhani
Orion Security = Solutions,=20 Inc.
1489 Chain=20 Bridge Road, Suite 300
McLean,=20 Virginia 22101 =
(703) = 917-0060  Ext. = 35 (voice) =
(703) = 917-0260=20 (Fax)
chokhani@orionsec.com=20
Visit our Web = site=20
http://www.orionsec.com=20

 

<= /BODY> ------=_NextPart_000_004A_01C5DA60.FD0E5E20-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QHa4N0078527; Wed, 26 Oct 2005 10:36:04 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9QHa4SS078526; Wed, 26 Oct 2005 10:36:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QHa0av078520 for ; Wed, 26 Oct 2005 10:36:03 -0700 (PDT) (envelope-from tgondrom@opentext.com) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id j9QHZvWP020874; Wed, 26 Oct 2005 19:35:58 +0200 (MEST) 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_01C5DA53.B94E8AC7" Subject: RE: Suggested Topic for LTANS WG Meeting Date: Wed, 26 Oct 2005 19:36:12 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B070013E15B0@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Suggested Topic for LTANS WG Meeting Thread-Index: AcXY4P1wsy01RBB9Q9yGbQ9mCw5+1gBcimLg X-Priority: 5 Importance: low From: "Tobias Gondrom" To: "Santosh Chokhani" Cc: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DA53.B94E8AC7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Santosh, =20 Sounds interesting, also I am not fully sure that I can follow the scheme completely.=20 (small remark: I consider signing algs most of the time more in danger of being broken than hash) =20 Definitely vote for putting on the agenda as "informational" to the WG, if Carl can spare the 5-10 minutes from the meeting time? =20 Probably you could describe this with a few more words here on the Mailing list (not ID) just a few more lines? =20 Regards and Thanks, Tobias =20 =20 ________________________________ From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Santosh Chokhani Sent: Monday, October 24, 2005 11:15 PM To: ietf-ltans@imc.org Subject: Suggested Topic for LTANS WG Meeting =20 I have an idea that makes it harder to exploit SHA-1 collision. The idea can be applied to PKI objects such as certificates, CRLs, OCSP responses, SCVP responses, signed application objects, etc. =20 I do not know if this has been discussed before in any forum. =20 The idea is to generate a random key, encrypt the structure, hash the encrypted structure and sign the structure with the random key in it. As an alternative, the random key may be appended to the structure, prior to encryption. Thus, if you want to sign X, you will do the following: =20 1. Generate a random key K 2. Append K to X (optional) 3. Encrypt the outcome of step 2 using K 4. Hash the outcome of step 3 5. Sign the hash 6. Your object is X, K, signature =20 There are ways to include K in the SIGNED MACRO that Carl Wallace has explored. Carl can describe those also. =20 I think this should be discussed for 5-10 minutes. If you agree, Carl Wallace would present since I will not be able to attend this IETF meeting. Santosh Chokhani=20 Orion Security Solutions, Inc.=20 1489 Chain Bridge Road, Suite 300=20 McLean, Virginia 22101=20 (703) 917-0060 Ext. 35 (voice)=20 (703) 917-0260 (Fax)=20 chokhani@orionsec.com=20 Visit our Web site=20 http://www.orionsec.com =20 =20 ------_=_NextPart_001_01C5DA53.B94E8AC7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi = Santosh,

 

Sounds interesting, also I am not = fully sure that I can follow the scheme completely. =

(small remark: I consider signing = algs most of the time more in danger of being broken than = hash)

 

Definitely vote for putting on the = agenda as “informational” to the WG, if Carl can spare the 5-10 = minutes from the meeting time?

 

Probably you could describe this = with a few more words here on the Mailing list (not ID) just a few more = lines?

 

Regards and Thanks, = Tobias

 

 

From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: Monday, October 24, = 2005 11:15 PM
To: = ietf-ltans@imc.org
Subject: Suggested Topic = for LTANS WG Meeting

 

I have an idea that makes it harder to exploit SHA-1 collision.  The idea can be applied to PKI objects such as = certificates, CRLs, OCSP responses, SCVP responses, signed application objects, = etc.

 

I do not know if this has been discussed before in = any forum.

 

The idea is to generate a random key, encrypt the = structure, hash the encrypted structure and sign the structure with the random key = in it.  As an alternative, the random key may be appended to the = structure, prior to encryption.  Thus, if you want to sign X, you will do the = following:

 

1.  Generate a random key = K

2.  Append K to X = (optional)

3.  Encrypt the outcome of step 2 using = K

4.  Hash the outcome of step = 3

5.  Sign the hash

6.  Your object is X, K, = signature

 

There are ways to include K in the SIGNED MACRO that = Carl Wallace has explored.  Carl can describe those = also.

 

I think this should be discussed for 5-10 = minutes.  If you agree, Carl Wallace would present since I will not be able to attend = this IETF meeting.

Santosh Chokhani
Orion Security Solutions, Inc.
1489 Chain Bridge Road, = Suite 300
McLean, Virginia 22101
(703) 917-0060 = Ext. = 35 (voice)
(703) 917-0260 (Fax)
chokhani@orionsec.com=
Visit our Web site
http://www.orionsec.com

 

------_=_NextPart_001_01C5DA53.B94E8AC7-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9OLFAKG002963; Mon, 24 Oct 2005 14:15:10 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9OLFAs1002962; Mon, 24 Oct 2005 14:15:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9OLF90q002956 for ; Mon, 24 Oct 2005 14:15:10 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j9OLF7HU020780 for ; Mon, 24 Oct 2005 17:15:08 -0400 From: "Santosh Chokhani" To: Subject: Suggested Topic for LTANS WG Meeting Date: Mon, 24 Oct 2005 17:15:02 -0400 Message-ID: <008301c5d8e0$028a7730$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01C5D8BE.7B78D730" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0084_01C5D8BE.7B78D730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have an idea that makes it harder to exploit SHA-1 collision. The = idea can be applied to PKI objects such as certificates, CRLs, OCSP = responses, SCVP responses, signed application objects, etc. =20 I do not know if this has been discussed before in any forum. =20 The idea is to generate a random key, encrypt the structure, hash the encrypted structure and sign the structure with the random key in it. = As an alternative, the random key may be appended to the structure, prior to encryption. Thus, if you want to sign X, you will do the following: =20 1. Generate a random key K 2. Append K to X (optional) 3. Encrypt the outcome of step 2 using K 4. Hash the outcome of step 3 5. Sign the hash 6. Your object is X, K, signature =20 There are ways to include K in the SIGNED MACRO that Carl Wallace has explored. Carl can describe those also. =20 I think this should be discussed for 5-10 minutes. If you agree, Carl Wallace would present since I will not be able to attend this IETF = meeting. Santosh Chokhani=20 Orion Security Solutions, Inc.=20 1489 Chain Bridge Road, Suite 300=20 McLean, Virginia 22101=20 (703) 917-0060 Ext. 35 (voice)=20 (703) 917-0260 (Fax)=20 chokhani@orionsec.com=20 Visit our Web site=20 http://www.orionsec.com =20 =20 ------=_NextPart_000_0084_01C5D8BE.7B78D730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I have = an idea that=20 makes it harder to exploit SHA-1 collision.  The idea can be = applied to PKI=20 objects such as certificates, CRLs, OCSP responses, SCVP responses, = signed=20 application objects, etc.
 
I do = not know if=20 this has been discussed before in any forum.
 
The = idea is to=20 generate a random key, encrypt the structure, hash the encrypted = structure and=20 sign the structure with the random key in it.  As an alternative, = the=20 random key may be appended to the structure, prior to encryption.  = Thus, if=20 you want to sign X, you will do the following:
 
1.  Generate a=20 random key K
2.  Append K to=20 X (optional)
3.  Encrypt the=20 outcome of step 2 using K
4.  Hash the=20 outcome of step 3
5.  Sign the=20 hash
6.  Your object=20 is X, K, signature
 
There = are ways to=20 include K in the SIGNED MACRO that Carl Wallace has explored. =20 Carl can=20 describe those also.
 
I = think this should=20 be discussed for 5-10 minutes.  If you agree, Carl Wallace would = present=20 since I will not be able to attend this IETF = meeting.

Santosh = Chokhani=20
Orion Security = Solutions,=20 Inc.
1489 Chain=20 Bridge Road, Suite 300
McLean, Virginia 22101
(703) 917-0060  Ext. 35 (voice)
(703) 917-0260 (Fax) =
chokhani@orionsec.com
Visit our Web = site
http://www.orionsec.com

 
------=_NextPart_000_0084_01C5D8BE.7B78D730-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JE3Gvq051057; Wed, 19 Oct 2005 07:03:16 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9JE3GAt051056; Wed, 19 Oct 2005 07:03:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JE3F9m051039 for ; Wed, 19 Oct 2005 07:03:15 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (195.sub-70-194-97.myvzw.com [70.194.97.195]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j9JE39hO017816 for ; Wed, 19 Oct 2005 10:03:11 -0400 Message-Id: <200510191403.j9JE39hO017816@host15.websitesource.com> From: "Carl Wallace" To: Subject: RE: 64th IETF (ERS ASN.1 module) Date: Wed, 19 Oct 2005 10:03:01 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0079_01C5D494.49C20EB0" In-Reply-To: <435637DD.6060304@edelweb.fr> Thread-Index: AcXUp1PFzs4/op7zRhOpXewEzmbrhAADf34w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0079_01C5D494.49C20EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > ERS > {iso(1) identified-organization(3) dod(6) internet(1) security(5) > mechanisms(5) pkix(7) id-mod(0) id-mod-ers(4711) } > > DEFINITIONS IMPLICIT TAGS ::= > > BEGIN > > -- EXPORTS ALL -- > > IMPORTS > TimeStampToken > FROM > PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13) } > > id-ATS-1 FROM ATS This should be defined in this module, not imported from ATS. The name should be changed as well to reflect new name for the spec. ------=_NextPart_000_0079_01C5D494.49C20EB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOMDCCBEAw ggMooAMCAQICBEClE7wwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9y aW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGll czEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNzE0MzA1NVoXDTA3MDUxNzE1MDA1NVowWzELMAkGA1UE BhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczESMBAGA1UECxMJRW1wbG95 ZWVzMRUwEwYDVQQDEwxDYXJsIFdhbGxhY2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALLi +sA/Id5PcQ8uPHjuKlWcxrb8kQkBkJrn4Vv/KNrpZZcIO0mTxp28yVqg3fJRWszamV3cbE77oXV/ 0AFxrRhf89avN0lrUmqSBsf7ph8Zfz8HMbNODQvGOsKCGa4HA1jujeTnIqgrlCyyUORELVu4i2a7 uErbLjIX7SHNxGtlAgMBAAGjggGHMIIBgzALBgNVHQ8EBAMCBSAwIAYDVR0RBBkwF4EVY3dhbGxh Y2VAb3Jpb25zZWMuY29tMIHrBgNVHR8EgeMwgeAweaB3oHWkczBxMQswCQYDVQQGEwJVUzEhMB8G A1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0aWVzMQwwCgYDVQQLEwNDQTExDTALBgNVBAMTBENSTDEwMqAwoC6GLGh0dHA6Ly93d3cu b3Jpb25zZWMuY29tL0NSTC9jYTFfY3JsZmlsZTQuY3JsMC+gLaArhilmaWxlOi8vXFxTYmV0ZWxn ZXVzZVxDUkxcY2ExX2NybGZpbGU0LmNybDAfBgNVHSMEGDAWgBTIsjzeuprriQmg1jQymxlChsyY 0jAdBgNVHQ4EFgQUB0yg8DWubbASzzui5JhAF3+oIRYwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAE DDAKGwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAYh0dywIAWMho3sca3AwuMZiepipLDF/+ +vrm9Md+P9AfS6pjwRbsBNcS9425jr56ANJXALioZoxDMKlRKXy+Hmj8wXq8nMgPkmfLYhvP+PVn KgOkoQtT3ym7FSCwrDJEvO0azG6uRxhuIevShRsBaxsCCjdnf6xG6OGV0KrniweAsnNoZPdq6bHI 2ZAk8hZNWHWwGmYo1lP9MeZ+5aYvG1T3OoKI7Kyg4SM/OjjqxwuGC1Zoh1nAJHrBuvRxvhrzvf9t 5ff5r7/YEguVTRfnviUhAyB56auTb1+lY+sz+NQB0kBkSXwvq1+R6pJ3eBWH7o9h5QI87j0IbrL/ ZXhj0zCCBG0wggNVoAMCAQICBEClE74wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAf BgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBB dXRob3JpdGllczEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNzE4MDExNFoXDTA3MDUxNzE4MzExNFow WzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczESMBAGA1UE CxMJRW1wbG95ZWVzMRUwEwYDVQQDEwxDYXJsIFdhbGxhY2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAK+KL0avuOpT0cjCIpk1FxSdLKeXJvS9YoiWX51DoSimpkLJrVj3dxVZW+ixPGTKpnGB RlGMLOnaqhtIgJ7rSw7/c2Ahc52t8QRdb5HFG96/b4FQabd9zgjiKs82ijzsWvwP1wcDm5YwrTcc 5ZXh4BgelpXgUn5I1kOjTvyC4UuTAgMBAAGjggG0MIIBsDALBgNVHQ8EBAMCB4AwKwYDVR0QBCQw IoAPMjAwNDA1MTcxODAxMTRagQ8yMDA2MDYyMzA2MzExNFowIAYDVR0RBBkwF4EVY3dhbGxhY2VA b3Jpb25zZWMuY29tMIHrBgNVHR8EgeMwgeAweaB3oHWkczBxMQswCQYDVQQGEwJVUzEhMB8GA1UE ChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhv cml0aWVzMQwwCgYDVQQLEwNDQTExDTALBgNVBAMTBENSTDEwMqAwoC6GLGh0dHA6Ly93d3cub3Jp b25zZWMuY29tL0NSTC9jYTFfY3JsZmlsZTQuY3JsMC+gLaArhilmaWxlOi8vXFxTYmV0ZWxnZXVz ZVxDUkxcY2ExX2NybGZpbGU0LmNybDAfBgNVHSMEGDAWgBTIsjzeuprriQmg1jQymxlChsyY0jAd BgNVHQ4EFgQUBoyaS8dak6pJpXXiEkLdnVnyngAwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAK GwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAa69I2Ckr0OjSaxgqdueqQczXR74p1qAS9eRC vZjLW23840mKXk/UtiKvF0E9JgZ11/Fqyk/IHHbSnX7r9Z6oLVKvs0Pkk+HlB9X5XGiVm6RXpAzL jHwsKefQsQ9Lsrk8bouPneRqMzoYQ/ea3Azeit1UWMiZYA+Oebv9Lu6oIFVq/ONucRyxTAMN5i91 IZ5bAp3Jb3cUfd3FqmVBctfVemWIOOcgOoRCf7gJKpPqI0CWkR/LIA67F3lD+goNYb07ISIFqVgk VcGhsMJx19lwFl9kXqgHLDhxfTbV6PDb1LkBoIE8O+dhZkYQ2DmH6dHo88+bfOJJ3z6HtA8GpFpb LzCCBXcwggRfoAMCAQICBEClE1EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAfBgNV BAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRo b3JpdGllczEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNDE5MDMxMloXDTI0MDUxNDE5MzMxMlowYjEL MAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZ Q2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEMMAoGA1UECxMDQ0ExMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAoJjL4nDMben23Cn1KTo4DfHDtfNZGOWwBW2XI9djn/VuXXO2hj6nX4r4 G1lNwtCpDYn7Lp80dHRFdpn7GnqrfNMHIsKDaRYxpJ0fgi4gE9LdMwnmsEE8WONj7yPVRuI6Xq43 nfO8LTZehHaN+NwUdgh/rXDQLru1AaxYbaJftkpGGwyMDmPwtfgV3TvNf8g50mCTcAripDVm2tzC 4vIOdNCYQJfsRoQggtLwby9nNyxwHKHHh7OlEZPqVJPGn1S1qzFxKjRcLHwzP4vKD6H8nY5ndVk3 4CLZ5jq59kcpoVTDMLySl5PTg6zBuS+1S0nngBAW9FOqUOTBRMyxqHkmgwIDAQABo4ICMzCCAi8w ggGEBgNVHR8EggF7MIIBdzB5oHegdaRzMHExCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBT ZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAK BgNVBAsTA0NBMTENMAsGA1UEAxMEQ1JMMTAyoDCgLoYsaHR0cDovL3d3dy5vcmlvbnNlYy5jb20v Q1JML2NhMV9jcmxmaWxlNC5jcmwwgZSggZGggY6GgYtsZGFwOi8vU0JFVEVMR0VVU0UvY249V2lu Q29tYmluZWQ0LG91PUNBMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1PcmlvbiUy MFNlY3VyaXR5JTIwU29sdXRpb25zLGM9VVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9CYXNl MC+gLaArhilmaWxlOi8vXFxTYmV0ZWxnZXVzZVxDUkxcY2ExX2NybGZpbGU0LmNybDArBgNVHRAE JDAigA8yMDA0MDUxNDE5MDMxMlqBDzIwMjQwNTE0MTkzMzEyWjALBgNVHQ8EBAMCAQYwHwYDVR0j BBgwFoAUyLI83rqa64kJoNY0MpsZQobMmNIwHQYDVR0OBBYEFMiyPN66muuJCaDWNDKbGUKGzJjS MAwGA1UdEwQFMAMBAf8wHQYJKoZIhvZ9B0EABBAwDhsIVjcuMDo0LjADAgSQMA0GCSqGSIb3DQEB BQUAA4IBAQA9LSuraaiw3bO+TdsvCuppT4dbud3+lw6LekUzC9uVFzKbVpVUohUezNJ4zz7FbTV3 0zFNBUrjM8twoSJQ+pbAdJRhrva9zztJp+zR1hDiF4xUfQ/VhcW5HQ8AuduMAdDOyDbc2qQFeUwR YfonnJpWZINiCyUavFXKoTKoG6KkaDfrBiKLtOXy6m09Qr1dQ7wGnL8i+iEDGVFiCjlJ1JeP0vDP g+oOwWYTraW69me5EfXXhhvghAbYtkwoEfxS8hAxRfFqh+8LTIf9nL8ug9ImcfQqVZhRBsC8W2+Y TzLrexngHUpedXJuas/XVSW1+COqOt/gU9lWPD+GD+59FYJIMYIC0jCCAs4CAQEwajBiMQswCQYD VQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTECBEClE74wCQYFKw4DAhoFAKCCAb4w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMDE5MTQwMzAwWjAj BgkqhkiG9w0BCQQxFgQUVaTVX/uZ8QpbFb8WKkNK6mR1s0AwZwYJKoZIhvcNAQkPMVowWDAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUweQYJKwYBBAGCNxAEMWwwajBiMQswCQYDVQQGEwJV UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTECBEClE7wwewYLKoZIhvcNAQkQAgsxbKBqMGIx CzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsT GUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAKBgNVBAsTA0NBMQIEQKUTvDANBgkqhkiG9w0B AQEFAASBgHt1VuoudW8pGwdENonkMmbj5jW/GaOes64Xy4vuPR7WJ/Q2FV1a038rAOn76xWuKYMM KrPSn9O1k1eBAKq1j0/0it0g/MBYtZdv9VgS4C1Rylbijb1U5uk0Qim+dr5bqNxfuB/xCMuVl086 r5a7JfMPGJe9aXvu9fdyzBn+wyx9AAAAAAAA ------=_NextPart_000_0079_01C5D494.49C20EB0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JCBDc7025089; Wed, 19 Oct 2005 05:11:13 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9JCBDYL025088; Wed, 19 Oct 2005 05:11:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JCBCZX025063 for ; Wed, 19 Oct 2005 05:11:12 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j9JCBAi28564 for ; Wed, 19 Oct 2005 14:11:10 +0200 (MEST) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Wed, 19 Oct 2005 14:11:10 +0200 (MET DST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA26627 for ; Wed, 19 Oct 2005 14:11:10 +0200 (MET DST) Message-ID: <435637DD.6060304@edelweb.fr> Date: Wed, 19 Oct 2005 14:11:09 +0200 From: Peter Sylvester User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ietf-ltans@imc.org Subject: Re: 64th IETF References: <200510191054.j9JAsQhO005480@host15.websitesource.com> <1129720529.43562ad159ed9@kekec.e5.ijs.si> In-Reply-To: <1129720529.43562ad159ed9@kekec.e5.ijs.si> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000108030805070500070807" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms000108030805070500070807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello yesterday evening I have stressed the ERS ASN.1 syntax using asn1c. (a slightly enhance one understanding TYPE-IDENTIFIERs). There were some bugs in the syntax. tags were not places correctly, one alternative was ambiguous. I add SIZE constraints. I also transformed the syntax to current ASN.1. There are two OIDs (the module and id-ATS) which need to be defined. Why is there an EncryptionMethod? Isn't this the same as AlgorithmIdentifier ? Comments are welcome. Peter ERS {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ers(4711) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS TimeStampToken FROM PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13) } id-ATS-1 FROM ATS ContentInfo FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} AlgorithmIdentifier FROM AI ; ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier, reducedHashtree [0] SEQUENCE OF SEQUENCE OF OCTET STRING OPTIONAL, timeStamp ContentInfo} ArchiveTimeStampChain::= SEQUENCE SIZE (1..MAX) OF ArchiveTimeStamp EncryptionMethod ::= SEQUENCE { encryptionAlgorithm TYPE-IDENTIFIER.&id({EncryptionMethods}), encryptionParameters TYPE-IDENTIFIER.&Type({EncryptionMethods}{@encryptionAlgorithm}) OPTIONAL } EncryptionMethods TYPE-IDENTIFIER ::= {cms-Encryption ,... -- dynamically extensible information object set --} cms-Encryption TYPE-IDENTIFIER ::= { CMSEncryptionParams IDENTIFIED BY id-ATS-1 } CMSEncryptionParams ::= SEQUENCE { encryptionCover ContentInfo, publicKey [0] BIT STRING OPTIONAL, params CHOICE { privateKey BIT STRING, encryptionKeyRan EncryptionKeyRandom} } EncryptionKeyRandom::= SEQUENCE { encryptionKey OCTET STRING, randomValue BIT STRING } EvidenceRecord ::= SEQUENCE { version INTEGER { v1(1) }, digestAlgorithms SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier, cryptoInfos [0] SEQUENCE SIZE (1..MAX) OF CryptoInfo OPTIONAL, encryption [1] EncryptionMethod OPTIONAL, archiveTimeStamps SEQUENCE SIZE (1..MAX) OF ArchiveTimeStampChain} CryptoInfo ::= SEQUENCE { cryptoInfoType TYPE-IDENTIFIER.&id({CryptoInfos}), cryptoInfoValue TYPE-IDENTIFIER.&Type({ECryptoInfos}{@cryptoInfoType}) OPTIONAL } CryptoInfos TYPE-IDENTIFIER ::= {... -- dynamically extensible information object set --} END --------------ms000108030805070500070807 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 BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+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 S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMDE5MTIxMTA5WjAjBgkqhkiG9w0B CQQxFgQUvaHeQ7X9zexL3r1ban6eBmhtY+kwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGA59W7s1ZMMYNcINA4 V6jvmxLcqVbhyiD7F/B288gtrJeUEpHV1K1EKLxCf0lMRM+oqPMnD3tc6vrwEWeiLE7G4Bdj 1FZxiXdGUM4v3X/8+YXGcy5+er0Wp7AJr+rucHfwgvhBfdF4/APpYUDkP7KgX7BUWiuzRHlh 3W340UTsBVIAAAAAAAA= --------------ms000108030805070500070807-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JBFVOF020034; Wed, 19 Oct 2005 04:15:31 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9JBFVjn020033; Wed, 19 Oct 2005 04:15:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id j9JBFU6Q020027 for ; Wed, 19 Oct 2005 04:15:30 -0700 (PDT) (envelope-from aljosa@e5.ijs.si) Received: (qmail 10893 invoked by uid 48); 19 Oct 2005 11:15:29 -0000 Received: from eth0.sw1.ACV.at (eth0.sw1.ACV.at [217.19.38.68]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 19 Oct 2005 13:15:29 +0200 Message-ID: <1129720529.43562ad159ed9@kekec.e5.ijs.si> Date: Wed, 19 Oct 2005 13:15:29 +0200 From: aljosa@e5.ijs.si To: Carl Wallace Cc: ietf-ltans@imc.org Subject: RE: 64th IETF References: <200510191054.j9JAsQhO005480@host15.websitesource.com> In-Reply-To: <200510191054.j9JAsQhO005480@host15.websitesource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 217.19.38.68 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry, i will not be able to join. BR Aleksej Quoting Carl Wallace : > > > Unfortunately I can't be with you at the 64th IETF. > > Hope to be able to join via Jabber? > > Is there anyone who plans to attend the meeting that could serve as a Jabber > scribe? The draft agenda for the meeting is as follows: > > Monday November 7th > 18:50-19:50 > > Intro - 5 minutes > Notary review - 15 minutes > ERS review - 15 minutes > LTAP and ERS via SCVP review - 15 minutes > Future/Wrap-up - 5 minutes > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JAsZXh018140; Wed, 19 Oct 2005 03:54:35 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9JAsZOj018139; Wed, 19 Oct 2005 03:54:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9JAsY0u018133 for ; Wed, 19 Oct 2005 03:54:34 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (195.sub-70-194-97.myvzw.com [70.194.97.195]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j9JAsQhO005480 for ; Wed, 19 Oct 2005 06:54:31 -0400 Message-Id: <200510191054.j9JAsQhO005480@host15.websitesource.com> From: "Carl Wallace" To: Subject: RE: 64th IETF Date: Wed, 19 Oct 2005 06:53:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <3C1BE8610E44734499EF92FB35F5B070013E0988@MUCXGC1.opentext.net> Thread-Index: AcXQrbH5BtAt+/IST1KWd7d0UBU9QQCfhvRgAFvNHoA= Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Unfortunately I can't be with you at the 64th IETF. > Hope to be able to join via Jabber? Is there anyone who plans to attend the meeting that could serve as a Jabber scribe? The draft agenda for the meeting is as follows: Monday November 7th 18:50-19:50 Intro - 5 minutes Notary review - 15 minutes ERS review - 15 minutes LTAP and ERS via SCVP review - 15 minutes Future/Wrap-up - 5 minutes Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9II1mVm004104; Tue, 18 Oct 2005 11:01:48 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9II1msF004102; Tue, 18 Oct 2005 11:01:48 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j9II1jQn004086 for ; Tue, 18 Oct 2005 11:01:46 -0700 (PDT) (envelope-from tgondrom@opentext.com) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id j9II1GjL029684; Tue, 18 Oct 2005 20:01:44 +0200 (MEST) 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_01C5D40C.3AF24446" Subject: RE: 64th IETF Date: Tue, 18 Oct 2005 19:49:15 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B070013E0B7E@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 64th IETF Thread-Index: AcXTt/2PIEj5M1gZSGu9em6TUpl63AAU8P4Q X-Priority: 5 Importance: low From: "Tobias Gondrom" To: Cc: , , "Thomas Kunz" , "Wolfgang Schneider" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D40C.3AF24446 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Andreas, =20 Thanks for the information. Would be happy to read from you before the meeting a few of your ideas and proposals on the mailing-list - as other people might also want to comment on them and we can start a good discussion. =20 Thanks, Tobias =20 =20 Ps.: and of course please provide Carl with your slides at least a day or s.th. before the meeting, so that he can consolidate the presentations - quiet sad I can't join the meeting in November. =20 =20 ________________________________ From: Andreas U. Schmidt [mailto:Andreas.U.Schmidt@sit.fraunhofer.de]=20 Sent: Tuesday, October 18, 2005 9:45 AM To: Tobias Gondrom Cc: cwallace@orionsec.com; ietf-ltans@imc.org; Thomas Kunz; Wolfgang Schneider Subject: Re: 64th IETF =20 Tobias, Carl, we would like to contribute a 10-12minute slot on notary comprising: - Requirements review - High-level data structures for notarisations/certifications We hope that can spur progress, but also test people's interest in the first place. (Given the slowness of discussions we waited 'till last minute, sorry about that) Andreas Tobias Gondrom wrote:=20 Carl, =20 Thanks for the proposed agenda. =20 Unfortunately I can't be with you at the 64th IETF. Hope to be able to join via Jabber? =20 >From what I saw on the mailing-list I would really consider to drop notary - so if there is someone you has use cases and a need for it please come up with it now! ;-) =20 For me I would like to see ERS and a protocol to get the data. Will answer on this in more detail to the latest draft of ers via scvp. =20 And fully agree to Carl on the last point: if s.o. has further points of work she would like be covered by LTANS, better speak up now!=20 =20 So read from you soon. =20 Tobias =20 =20 =20 -----Original Message----- From: owner-ietf-ltans@mail.imc.org =20 [mailto:owner-ietf-ltans@mail.imc.org] =20 On Behalf Of Carl Wallace Sent: Friday, October 14, 2005 12:55 PM To: ietf-ltans@imc.org Subject: 64th IETF =20 =20 Folks, =20 If anyone has any topics they'd like to discuss or present during the upcoming IETF meeting please let me know. The group is currently scheduled to meet on Monday evening (Nov. 7th) from 18:50-19:50. Of particular interest would be any information regarding implementations of ERS. =20 The =20 current topics, in no particular order and for list discussion in the meantime, are: =20 - ERS + Review changes to -03 draft and discuss support for non-3161 timestamps. =20 - Review of ERS via SCVP draft and LTAP + Review -00 draft and discuss LTAP structure in general (i.e., bindings to existing protocols like SCVP and WebDAV vs. or in =20 conjunction =20 with new purpose-built protocol). =20 - Future of notary work + Is there sufficient interest to carry this item forward? =20 - Future of LTANS + What is the state of current ERS implementations? Is ERS the =20 only =20 necessary work product? =20 Carl =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C5D40C.3AF24446 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = Andreas,

 

Thanks for the information. Would = be happy to read from you before the meeting a few of your ideas and proposals on = the mailing-list – as other people might also want to comment on them = and we can start a good discussion.

 

Thanks, = Tobias

 

 

Ps.: and of course please provide = Carl with your slides at least a day or s.th. before the meeting, so that he = can consolidate the presentations – quiet sad I can’t join the = meeting in November.

 

 

From: Andreas U. Schmidt [mailto:Andreas.U.Schmidt@sit.fraunhofer.de]
Sent: Tuesday, October = 18, 2005 9:45 AM
To: Tobias Gondrom
Cc: = cwallace@orionsec.com; ietf-ltans@imc.org; Thomas Kunz; Wolfgang Schneider
Subject: Re: 64th = IETF

 

Tobias, Carl,

we would like to contribute a 10-12minute slot on notary comprising:

- Requirements review
- High-level data structures for notarisations/certifications

We hope that can spur progress, but also test people's interest in the = first place.
(Given the slowness of discussions we waited 'till last minute, sorry = about that)

Andreas

Tobias Gondrom wrote: 

Carl,
 
Thanks for the proposed =
agenda.
 
Unfortunately I can't be with you at the 64th =
IETF.
Hope to be able to join via =
Jabber?
 
>From what I saw on the mailing-list I =
would really consider to drop
notary - so if there is someone you has use =
cases and a need for it
please come up with it now! =
;-)
 
For me I would like to see ERS and a protocol =
to get the data.
Will answer on this in more detail to the =
latest draft of ers via scvp.
 
And fully agree to Carl on the last point: if =
s.o. has further points of
work she would like be covered by LTANS, =
better speak up now! 
 
So read from you =
soon.
 
Tobias
 
 
  
-----Original =
Message-----
From: owner-ietf-ltans@mail.imc.o=
rg
    =

[mailto:owner-ietf-ltans@mai=
l.imc.org]
  
On Behalf Of Carl =
Wallace
Sent: Friday, October 14, 2005 12:55 =
PM
To: ietf-ltans@imc.org
Subject: 64th =
IETF
 
 
Folks,
 
If anyone has any topics they'd like to =
discuss or present during the
upcoming IETF meeting please let me =
know.  The group is =
currently
scheduled
<=
font
size=3D2 color=3Dblack face=3D"Courier New">to meet on Monday evening (Nov. 7th) from =
18:50-19:50.  Of =
particular
interest would be any information regarding =
implementations of ERS.
    =

The
  
current topics, in no particular order and =
for list discussion in the
meantime, =
are:
 
- =
ERS
 + Review changes to -03 draft and discuss =
support for non-3161
timestamps.
 
- Review of ERS via SCVP draft and =
LTAP
 + Review -00 draft and discuss LTAP =
structure in general (i.e.,
bindings to existing protocols like SCVP and =
WebDAV vs. or in
    =

conjunction
  
with new purpose-built =
protocol).
 
- Future of notary =
work
 + Is there sufficient interest to carry this =
item forward?
 
- Future of =
LTANS
 + What is the state of current ERS =
implementations?  Is ERS =
the
    =

only
  
necessary work =
product?
 
Carl
    =

 
 
 
 
 
------_=_NextPart_001_01C5D40C.3AF24446-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9I7jlnx042527; Tue, 18 Oct 2005 00:45:47 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9I7jlrF042526; Tue, 18 Oct 2005 00:45:47 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j9I7jhi8042512 for ; Tue, 18 Oct 2005 00:45:44 -0700 (PDT) (envelope-from Andreas.U.Schmidt@sit.fraunhofer.de) Received: from [141.12.86.73] (sitp292.sit.fhg.de [141.12.69.38]) (authenticated bits=0) by mailext.sit.fraunhofer.de (8.13.1/8.12.10) with ESMTP id j9I7jZdE002937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Oct 2005 09:45:36 +0200 Message-ID: <4354A811.8020600@sit.fraunhofer.de> Date: Tue, 18 Oct 2005 09:45:21 +0200 From: "Andreas U. Schmidt" Reply-To: Andreas.U.Schmidt@sit.fraunhofer.de User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tobias Gondrom CC: cwallace@orionsec.com, ietf-ltans@imc.org, Thomas Kunz , Wolfgang Schneider Subject: Re: 64th IETF References: <3C1BE8610E44734499EF92FB35F5B070013E0988@MUCXGC1.opentext.net> In-Reply-To: <3C1BE8610E44734499EF92FB35F5B070013E0988@MUCXGC1.opentext.net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias, Carl,

we would like to contribute a 10-12minute slot on notary comprising:

- Requirements review
- High-level data structures for notarisations/certifications

We hope that can spur progress, but also test people's interest in the first place.
(Given the slowness of discussions we waited 'till last minute, sorry about that)

Andreas

Tobias Gondrom wrote: 
Carl,

Thanks for the proposed agenda.

Unfortunately I can't be with you at the 64th IETF.
Hope to be able to join via Jabber?

>From what I saw on the mailing-list I would really consider to drop
notary - so if there is someone you has use cases and a need for it
please come up with it now! ;-)

For me I would like to see ERS and a protocol to get the data.
Will answer on this in more detail to the latest draft of ers via scvp.

And fully agree to Carl on the last point: if s.o. has further points of
work she would like be covered by LTANS, better speak up now! 

So read from you soon.

Tobias


  
-----Original Message-----
From: owner-ietf-ltans@mail.imc.org
    
[mailto:owner-ietf-ltans@mail.imc.org]
  
On Behalf Of Carl Wallace
Sent: Friday, October 14, 2005 12:55 PM
To: ietf-ltans@imc.org
Subject: 64th IETF


Folks,

If anyone has any topics they'd like to discuss or present during the
upcoming IETF meeting please let me know.  The group is currently
scheduled
to meet on Monday evening (Nov. 7th) from 18:50-19:50.  Of particular
interest would be any information regarding implementations of ERS.
    
The
  
current topics, in no particular order and for list discussion in the
meantime, are:

- ERS
	+ Review changes to -03 draft and discuss support for non-3161
timestamps.

- Review of ERS via SCVP draft and LTAP
	+ Review -00 draft and discuss LTAP structure in general (i.e.,
bindings to existing protocols like SCVP and WebDAV vs. or in
    
conjunction
  
with new purpose-built protocol).

- Future of notary work
	+ Is there sufficient interest to carry this item forward?

- Future of LTANS
	+ What is the state of current ERS implementations?  Is ERS the
    
only
  
necessary work product?

Carl
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HJo30A063315; Mon, 17 Oct 2005 12:50:03 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HJo3ok063314; Mon, 17 Oct 2005 12:50:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HJo25u063300 for ; Mon, 17 Oct 2005 12:50:03 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ERazi-0005KC-FM; Mon, 17 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-03.txt Message-Id: Date: Mon, 17 Oct 2005 15:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Evidence Record Syntax (ERS) Author(s) : R. Brandner, et al. Filename : draft-ietf-ltans-ers-03.txt Pages : 25 Date : 2005-10-17 In many scenarios, users need to be able to ensure and prove the existence and integrity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, designed for long-term non-repudiation of existence of data, which particularly can be used for conservation of evidence of digitally signed data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-ers-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-ers-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-17142503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-17142503.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HFB3jC032095; Mon, 17 Oct 2005 08:11:03 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HFB3qX032094; Mon, 17 Oct 2005 08:11:03 -0700 (PDT) X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id j9HFB2B1032085 for ; Mon, 17 Oct 2005 08:11:02 -0700 (PDT) (envelope-from tgondrom@opentext.com) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id j9HFB1mC017580; Mon, 17 Oct 2005 17:11:01 +0200 (MEST) 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: 64th IETF Date: Mon, 17 Oct 2005 17:11:14 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B070013E0988@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 64th IETF Thread-Index: AcXQrbH5BtAt+/IST1KWd7d0UBU9QQCfhvRg X-Priority: 5 Importance: low From: "Tobias Gondrom" To: "Carl Wallace" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9HFB3B1032088 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Carl, Thanks for the proposed agenda. Unfortunately I can't be with you at the 64th IETF. Hope to be able to join via Jabber? >From what I saw on the mailing-list I would really consider to drop notary - so if there is someone you has use cases and a need for it please come up with it now! ;-) For me I would like to see ERS and a protocol to get the data. Will answer on this in more detail to the latest draft of ers via scvp. And fully agree to Carl on the last point: if s.o. has further points of work she would like be covered by LTANS, better speak up now! So read from you soon. Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Carl Wallace > Sent: Friday, October 14, 2005 12:55 PM > To: ietf-ltans@imc.org > Subject: 64th IETF > > > Folks, > > If anyone has any topics they'd like to discuss or present during the > upcoming IETF meeting please let me know. The group is currently > scheduled > to meet on Monday evening (Nov. 7th) from 18:50-19:50. Of particular > interest would be any information regarding implementations of ERS. The > current topics, in no particular order and for list discussion in the > meantime, are: > > - ERS > + Review changes to -03 draft and discuss support for non-3161 > timestamps. > > - Review of ERS via SCVP draft and LTAP > + Review -00 draft and discuss LTAP structure in general (i.e., > bindings to existing protocols like SCVP and WebDAV vs. or in conjunction > with new purpose-built protocol). > > - Future of notary work > + Is there sufficient interest to carry this item forward? > > - Future of LTANS > + What is the state of current ERS implementations? Is ERS the only > necessary work product? > > Carl Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HEkcUt028896; Mon, 17 Oct 2005 07:46:38 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9HEkc62028895; Mon, 17 Oct 2005 07:46:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9HEkXEl028887 for ; Mon, 17 Oct 2005 07:46:34 -0700 (PDT) (envelope-from tgondrom@opentext.com) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id j9HEkLWP026743; Mon, 17 Oct 2005 16:46:32 +0200 (MEST) 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: ERS resilience Date: Mon, 17 Oct 2005 16:46:34 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B070013E0976@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ERS resilience Thread-Index: AcXMOOo2OsIQie6fTSSGpWw6SDjCTwG75FHA From: "Tobias Gondrom" To: "Young H. Etheridge" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j9HEkZEl028889 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Young H Etheridge, Thanks for you comments. > As an independent, information security consultant, researcher, and > developer, I encounter a significant amount resistance to depending on > public key technology as the only means of "securing" an information > structure. The reasoning is varied. Some reasonable, some not so > reasonable. The important point is that users/customers want choices, > particularly in standards, so that they can make decisions based on > their resources. With regard to security, resilience is exceptionally > important. Therefore, choice within a standard aids resilience to ward > off problems that may arise with a specific algorithm or technique > without needing to revisit a standard. Understood and agreed. Small remark: in the development of standards the overall rule should be KISS (keep it stupid simple) - you may encounter several problems with increase of complexity of the solutions and an increased number of options may rise the number of possible scenarios exponentially. This can be solved by adding SHOULD or CANs to the I-D but should be considered carefully. > I believe that you can make this document more effective and resilient > if you expand beyond your dependency on RFC-3161 and digital signatures > as the only means of offering TimeStampToken. The ANSI X9F4 X9.95-2005 > standard, "Trusted Time Stamp Management and Security", as well as the > ISO standards 18014-1, -2, -3, offers a number of choices including the > public key signature choice found in 3161. How would be the best way to integrate these other standards and most important what would be their benefit in addition to RFC3161. > Also, your suggestion of CMS to be a choice to manage cryptoInfoType is > a valuable choice. But, since CMS is resilient with respect to > encryption, I believe that it would be instructive to go beyond merely > mentioning public key as the means to manage encryption. My reasoning > is due to reasons offered above. > > Since there are a number of editorial changes necessary before this > draft can be ready for consideration for RFC, I propose that the five > (5) references to 3161 be expanded to also include references to ANSI > X9.95-2005, ISO 18014-1, ISO 18014-2, and ISO 18014-3 in order to give > credence to alternatives to public key signatures. This is a minor > change to the draft and does not alter your original choices or effect > any products which might meet your original draft. It seems to only > strengthen your draft. While in the past referencing ANSI or ISO > standards has not been acceptable since IETF standards tend to precede > final versions of ANSI or ISO standards, such is not the case in this > instance. I would happily consider this - maybe you could five me some arguments where these standards exceed the 3161. Thanks a lot for your comments and sorry for the delay of the answer. Tobias Ps.: remark: ERS is shortly before completion. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EAt7cs039531; Fri, 14 Oct 2005 03:55:07 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9EAt7J7039530; Fri, 14 Oct 2005 03:55:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9EAt6QS039520 for ; Fri, 14 Oct 2005 03:55:06 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j9EAsuFE028806 for ; Fri, 14 Oct 2005 06:55:05 -0400 Message-Id: <200510141055.j9EAsuFE028806@host15.websitesource.com> From: "Carl Wallace" To: Subject: 64th IETF Date: Fri, 14 Oct 2005 06:54:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXQrbH5BtAt+/IST1KWd7d0UBU9QQ== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Folks, If anyone has any topics they'd like to discuss or present during the upcoming IETF meeting please let me know. The group is currently scheduled to meet on Monday evening (Nov. 7th) from 18:50-19:50. Of particular interest would be any information regarding implementations of ERS. The current topics, in no particular order and for list discussion in the meantime, are: - ERS + Review changes to -03 draft and discuss support for non-3161 timestamps. - Review of ERS via SCVP draft and LTAP + Review -00 draft and discuss LTAP structure in general (i.e., bindings to existing protocols like SCVP and WebDAV vs. or in conjunction with new purpose-built protocol). - Future of notary work + Is there sufficient interest to carry this item forward? - Future of LTANS + What is the state of current ERS implementations? Is ERS the only necessary work product? Carl Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9AEo340030503; Mon, 10 Oct 2005 07:50:03 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j9AEo367030502; Mon, 10 Oct 2005 07:50:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9AEo3p2030496 for ; Mon, 10 Oct 2005 07:50:03 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EOyyY-0005ki-LL; Mon, 10 Oct 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-reqs-05.txt Message-Id: Date: Mon, 10 Oct 2005 10:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Long-Term Archive Service Requirements Author(s) : C. Wallace, et al. Filename : draft-ietf-ltans-reqs-05.txt Pages : 22 Date : 2005-10-10 There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-reqs-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-reqs-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-10104001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-reqs-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-10104001.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j98IhBYH083114; Sat, 8 Oct 2005 11:43:11 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j98IhBrR083113; Sat, 8 Oct 2005 11:43:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from burrens.yandk.org (yhetheridge.org [64.139.78.42]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j98IhAo3083107 for ; Sat, 8 Oct 2005 11:43:10 -0700 (PDT) (envelope-from yhe@yhetheridge.org) Received: from [192.168.1.11] (moors.yandk.org [192.168.1.11]) by burrens.yandk.org (Postfix) with ESMTP id D2C131578E for ; Sat, 8 Oct 2005 14:43:09 -0400 (EDT) Message-ID: <4348133D.9050204@yhetheridge.org> Date: Sat, 08 Oct 2005 14:43:09 -0400 From: "Young H. Etheridge" User-Agent: Thunderbird 1.4.1 (X11/20051004) MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: ERS resilience Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for your standards efforts on "Evidence Record Syntax (ERS)". I believe that this is important to a number of industries, in particular, health-care, insurance, and finance. However, I have a few concerns regarding some of the limitations presented in the -02 draft. As an independent, information security consultant, researcher, and developer, I encounter a significant amount resistance to depending on public key technology as the only means of "securing" an information structure. The reasoning is varied. Some reasonable, some not so reasonable. The important point is that users/customers want choices, particularly in standards, so that they can make decisions based on their resources. With regard to security, resilience is exceptionally important. Therefore, choice within a standard aids resilience to ward off problems that may arise with a specific algorithm or technique without needing to revisit a standard. I believe that you can make this document more effective and resilient if you expand beyond your dependency on RFC-3161 and digital signatures as the only means of offering TimeStampToken. The ANSI X9F4 X9.95-2005 standard, "Trusted Time Stamp Management and Security", as well as the ISO standards 18014-1, -2, -3, offers a number of choices including the public key signature choice found in 3161. Also, your suggestion of CMS to be a choice to manage cryptoInfoType is a valuable choice. But, since CMS is resilient with respect to encryption, I believe that it would be instructive to go beyond merely mentioning public key as the means to manage encryption. My reasoning is due to reasons offered above. Since there are a number of editorial changes necessary before this draft can be ready for consideration for RFC, I propose that the five (5) references to 3161 be expanded to also include references to ANSI X9.95-2005, ISO 18014-1, ISO 18014-2, and ISO 18014-3 in order to give credence to alternatives to public key signatures. This is a minor change to the draft and does not alter your original choices or effect any products which might meet your original draft. It seems to only strengthen your draft. While in the past referencing ANSI or ISO standards has not been acceptable since IETF standards tend to precede final versions of ANSI or ISO standards, such is not the case in this instance. I'll be happy to edit my suggestions into your latest working draft if you desire. Young H. Etheridge