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 kBLNT4hO038545; Thu, 21 Dec 2006 16:29:04 -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 kBLNT4Pb038544; Thu, 21 Dec 2006 16:29:04 -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 kBLNT2kV038529 for ; Thu, 21 Dec 2006 16:29:03 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id kBLNT0cq024136 for ; Fri, 22 Dec 2006 00:29:01 +0100 (MET) 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_01C72557.CB2C8E13" Subject: LTANS-ERS-10: example for CryptoInfos and encryptionInfo Date: Fri, 22 Dec 2006 00:28:59 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A78689379EF@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS-ERS-10: example for CryptoInfos and encryptionInfo Thread-Index: AcclV8qYHsMB3gVTTc6jGYzdpVdxVQ== X-Priority: 5 Importance: low From: "Tobias Gondrom" To: 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_01C72557.CB2C8E13 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, as the optional fields CryptoInfos and EncryptionInfo in the EvidenceRecord structure in the draft are currently simply placeholders that can flexibly be filled as needed, I wanted to outline the use a bit more to give you the opportunity to object if s.th. is unclear or going the wrong way. In the standard application most probably both fields are not necessary - but may be required in certain situations. (small personal comment: up to today I did never use or need the fields as I did neither need to provide additional information in the CryptoInfos nor had the problem to store additional information with encrypted content, so those two fields have only been discussed in theoretical technical discussions of certain combinations/contexts which most probably require this additional information but never happened to me. But if s.o. else already implemented one of those classes I would be happy to read about it on the mailing-list.) =20 We should also consider that we should provide at least one example of the two fields in the Appendix of ERS: Just for historic information: until including ERS version-08 we used the following syntax for both structures: CryptoInfos ::=3D SEQUENCE SIZE (1..MAX) OF CryptoInfo CryptoInfo ::=3D SEQUENCE { cryptoInfoType OBJECT IDENTIFIER cryptoInfoValue ANY DEFINED BY cryptoInfoType } EncryptionInfo ::=3D SEQUENCE { encryptionInfoType OBJECT IDENTIFIER, encryptionInfoValue [0] EXPLICIT ANY DEFINED BY encryptionInfoType } With version-09 we changed them to a more modern ASN.1 struct: CRYPT-INFO-CLASS ::=3D TYPE-IDENTIFIER CryptoInfos ::=3D SEQUENCE SIZE (1..MAX) OF INSTANCE OF CRYPT-INFO-CLASS cryptoInfos allows the storage of data useful in the validation of the archiveTimeStampSequence. This could include possible=20 Trust Anchors, certificates, revocation information or the current definition of the suitability of cryptographic algorithms, past and present (e.g. RSA 768bit valid until 1998, RSA 1024bit valid until=20 2008, SHA1 valid until 2010). These items may be added based on the policy used. Since this data is not protected within any timestamp, the data should be verifiable through other mechanisms. Such verification is out-of-scope of this document. And similar: ENCRYPTION-INFO-CLASS ::=3D TYPE-IDENTIFIER EncryptionInfos ::=3D SEQUENCE SIZE (1..MAX) OF INSTANCE OF ENCRYPTION-INFO-CLASS encryptionInfos contains a set of instances of ENCRYPTION-INFO-CLASS objects=20 that contain various pieces of information necessary for the unambiguous=20 re-encryption of unencrypted content so that it exactly matches with the=20 encrypted data objects protected by the EvidenceRecord. An example for the CryptoInfo would be e.g. objects that contain a used algorithm identifiers and the date until it has been considered secure: e.g.=20 CRYPTO-INFO-CLASS:=20 AlgTimeFrame::=3D SEQUENCE { usedAlgorithm AlgorithmIdentifier, validFrom GeneralizedTime, validUntil GeneralizedTime, } With GeneralizedTime from RFC2459 as also used in RFC3161. An example instance of a ENCRYPTION-INFO-CLASS: E.g. the content protected by the ERS is encrypted with a usual combination of asymm. and symm. encryption of RSA-1024 combined with.AES-256. (RSA-1024 to encrypt the key and the IV for the AES-256 encryption.) In this case an instance (and probably the only one) of the class would be: ENCRYPTION-INFO-CLASS: UsedEncryptionAlgorithmsAndParameters::=3D SEQUENCE=20 { usedAlgorithm AlgorithmIdentifier } >From looking at the structures it seems even easier to understand if you use the normal structures we had in version-08 but I hope this correctly matches with the new structure in version-09/version-10. Please provide your opinion/feedback on this implementations example/detail.=20 Thank you very much, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 This e-mail is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This e-mail may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for which it was sent by OTC. All other rights and licenses to this e-mail are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this e-mail in its entirety without printing, copying, using, and/or re-transmitting this e-mail, either in whole or in part. The transmission of this e-mail by OTC is not to be construed as a waiver by OTC and/or the individual sending this e-mail on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C72557.CB2C8E13 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LTANS-ERS-10: example for CryptoInfos and encryptionInfo

Hello,

as = the optional = fields CryptoInfos and EncryptionInfo in the EvidenceRecord structure in the draft are = currently simply placeholders that can flexibly be filled as needed, I = wanted to outline the use a bit more to give you the opportunity to = object if s.th. is unclear or going the wrong way. In the standard application most probably both = fields are not necessary – = but may be required in certain situations.

(small personal comment: up to today I did never use or = need the fields as I did neither = need to provide additional = information in the CryptoInfos nor had the problem to store additional = information with encrypted content, so those two = fields have only been discussed in theoretical technical discussions of certain = combinations/contexts = which most probably require this additional information but never happened to me. = But if s.o. else already implemented one of those classes I would be = happy to read about it on the mailing-list.) 

We = should also consider that we should provide at least one = example of the two fields in the Appendix of ERS:


Just = for historic information: until including ERS version-08 we used the = following syntax for both structures:

CryptoInfos ::=3D SEQUENCE SIZE (1..MAX) OF = CryptoInfo

   CryptoInfo ::=3D SEQUENCE

   {

      cryptoInfoType    = OBJECT IDENTIFIER

      cryptoInfoValue   ANY = DEFINED BY cryptoInfoType

   }

   EncryptionInfo ::=3D SEQUENCE

   {

      encryptionInfoType OBJECT = IDENTIFIER,

      encryptionInfoValue [0] EXPLICIT ANY = DEFINED BY encryptionInfoType

   }


With version-09 we changed them to a more modern ASN.1 = struct:

CRYPT-INFO-CLASS ::=3D TYPE-IDENTIFIER

   CryptoInfos ::=3D SEQUENCE SIZE (1..MAX) = OF

         INSTANCE OF = CRYPT-INFO-CLASS

cryptoInfos allows the storage of data useful in = the validation of

   the archiveTimeStampSequence. This = could include possible

   Trust Anchors, certificates, = revocation information or the current

   definition of the suitability of = cryptographic algorithms, past and

   present (e.g. RSA 768bit valid until = 1998, RSA 1024bit valid until =

   2008, SHA1 valid until 2010). These = items may be added based on the

   policy used. Since this data is not = protected within any timestamp,

   the data should be verifiable through = other mechanisms. Such verification

   is out-of-scope of this = document.

And = similar:

ENCRYPTION-INFO-CLASS ::=3D TYPE-IDENTIFIER

   EncryptionInfos ::=3D SEQUENCE SIZE (1..MAX) = OF

         INSTANCE OF = ENCRYPTION-INFO-CLASS


  encryptionInfos contains = a set of instances of ENCRYPTION-INFO-CLASS objects =

   that contain various pieces of = information necessary for the unambiguous =

   re-encryption of unencrypted content = so that it exactly matches with the =

   encrypted data objects protected by = the EvidenceRecord.



An = example for the CryptoInfo would be e.g. objects that contain a used = algorithm identifiers and the date until it has been considered = secure:

e.g. =

CRYPTO-INFO-CLASS: =

AlgTimeFrame::=3D = SEQUENCE

   {

      usedAlgorithm     = AlgorithmIdentifier,

        validFrom       =         = GeneralizedTime,

        validUntil      =         = GeneralizedTime,

   }

With GeneralizedTime from RFC2459 as also used in = RFC3161.

An = example instance of a ENCRYPTION-INFO-CLASS:

E.g. = the content protected by the ERS is encrypted with a usual combination = of asymm. and symm. encryption of RSA-1024 combined with.AES-256. = (RSA-1024 to encrypt the key and the IV for the AES-256 = encryption.)

In = this case an instance (and probably the only one) of the class would = be:

ENCRYPTION-INFO-CLASS:

UsedEncryptionAlgorithmsAndParameters::=3D SEQUENCE =

{

        usedAlgorithm   = AlgorithmIdentifier

}



From = looking at the structures it seems even easier to understand if you use = the normal structures we had in version-08 but I hope this correctly = matches with the new structure in = version-09/version-10.

Please provide your opinion/feedback on this = implementations example/detail.

Thank = you very much, Tobias



__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team

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

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

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

------_=_NextPart_001_01C72557.CB2C8E13-- 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 kBLNSt01038493; Thu, 21 Dec 2006 16:28:55 -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 kBLNStlu038492; Thu, 21 Dec 2006 16:28:55 -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 mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBLNSrnP038476 for ; Thu, 21 Dec 2006 16:28:54 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id kBLNSqex007914 for ; Fri, 22 Dec 2006 00:28:52 +0100 (MET) 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_01C72557.C5F56B63" Subject: ltans-ers-10 has been submitted to the IETF Date: Fri, 22 Dec 2006 00:28:50 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A78689379EE@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ltans-ers-10 has been submitted to the IETF Thread-Index: AcclV8WDlINhisY3R5WLjywW8jg8iQ== X-Priority: 5 Importance: low From: "Tobias Gondrom" To: 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_01C72557.C5F56B63 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, the next version of the draft ers-10 has been submitted to the IETF secretariat and it should be published by the secretariat to the WG list in the next few days. It contained basically two changes:=20 1) a number of wording and grammar corrections identified in a thorough review by Carl and others. 2) and second, it also contained the roll-back of the IMPORTS as discussed in the last WG meeting in San Diego: "ContentInfo FROM CryptographicMessageSyntax2004 -- FROM [RFC3852] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } -- Imports from RFC 3280 [RFC3280], Appendix A.1 AlgorithmIdentifier FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) }" Proposal from Peter which we incorporated in ERS-09 was: "ContentInfo FROM PKCS-7=20 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-7(7) modules(0) pkcs-7(1)} AlgorithmIdentifier FROM AuthenticationFramework=20 {joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 4}" Thanks, Tobias Ps.: as I would like to go into cross review with S/MIME ASAP and proceed with the IETF last call, it would be kind if you could provide feedback until Jan-04. Especially I would be interested on your opinion or alternatives to the IMPORT. And second also on the two generic fields cryptoInfos and encryptionInfos. Pss.: I will be out of office until Jan-02 and will only have limited access to email in these 10 days. __________________________________________ Tobias Gondrom Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 This e-mail is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This e-mail may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for which it was sent by OTC. All other rights and licenses to this e-mail are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this e-mail in its entirety without printing, copying, using, and/or re-transmitting this e-mail, either in whole or in part. The transmission of this e-mail by OTC is not to be construed as a waiver by OTC and/or the individual sending this e-mail on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C72557.C5F56B63 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ltans-ers-10 has been submitted to the IETF

Hi,

the = next version of the draft ers-10 has been submitted to the IETF = secretariat and it should be published by the secretariat to the WG list in the next few = days.


It = contained basically two changes:

1)  a = number of wording and grammar corrections identified in a thorough = review by Carl and others.

2) = and second, it also contained the roll-back of the = IMPORTS = as discussed in the last WG meeting in San Diego:

"ContentInfo

    FROM CryptographicMessageSyntax2004 -- FROM = [RFC3852]

     { iso(1) member-body(2) us(840) = rsadsi(113549)

       pkcs(1) pkcs-9(9) smime(16) = modules(0) cms-2004(24) }


  -- Imports from RFC 3280 [RFC3280], Appendix = A.1

  AlgorithmIdentifier

    FROM PKIX1Explicit88

        { iso(1) = identified-organization(3) dod(6)

        internet(1) security(5) = mechanisms(5) pkix(7)

        mod(0) = pkix1-explicit(18) }"



Proposal from Peter which we incorporated in ERS-09 = was:

"ContentInfo FROM PKCS-7

  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) = pkcs-7(7)

   modules(0) pkcs-7(1)}

AlgorithmIdentifier FROM AuthenticationFramework

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



Thanks, Tobias


Ps.: = as I would like to go into cross review with S/MIME ASAP and proceed = with the IETF last call, = it would be kind if you could provide feedback until = Jan-04.

Especially I would be interested on your opinion or = alternatives to the IMPORT. And second also on the two generic fields = cryptoInfos and encryptionInfos.

Pss.: I will be out of office until Jan-02 and will only = have limited access to email in these = 10 days.


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team

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

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

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

------_=_NextPart_001_01C72557.C5F56B63-- 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 kBLNCpOT035012; Thu, 21 Dec 2006 16:12: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 kBLNCpDf035009; Thu, 21 Dec 2006 16:12:51 -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 kBLNCjLJ034980 for ; Thu, 21 Dec 2006 16:12:46 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id kBLNCed5023473; Fri, 22 Dec 2006 00:12:41 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LTANS summary Date: Fri, 22 Dec 2006 00:12:38 +0100 Content-Type: multipart/signed; boundary="----=_NextPart_000_006A_01C7255D.E3471060"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <2666EB2A846BAC4BB2D7F593301A78689379EC@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS summary Thread-Index: AccSCDueG376GokbTmGKMfa+NjSbwATPLrCg From: "Tobias Gondrom" To: "Peter Sylvester" , "Carl Wallace" 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_000_006A_01C7255D.E3471060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Peter and Carl, I do not agree: I do not think that two alternative imports is a good = idea. Because the definition and import to the document should be = unambiguous. (How can developers decide which imports to use or have = been used, and how to ensure interoperability of different implementers? = For this we would have to implement an own additional ID just to define = which import has been used.) But maybe I misunderstood s.th.? Tobias Ps.: note, according to the WG meeting in San Diego, I reverted the = change of the import back to the ERS-08 syntax: "ContentInfo FROM CryptographicMessageSyntax2004 -- FROM [RFC3852] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } -- Imports from RFC 3280 [RFC3280], Appendix A.1 AlgorithmIdentifier FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) }" Proposal from Peter which we incorporated in ERS-09 was: "ContentInfo FROM PKCS-7=20 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-7(7) modules(0) pkcs-7(1)} AlgorithmIdentifier FROM AuthenticationFramework=20 {joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 4}" =20 > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Peter Sylvester > Sent: Monday, November 27, 2006 10:26 AM > To: Carl Wallace > Cc: ietf-ltans@imc.org > Subject: Re: LTANS summary >=20 > Carl Wallace wrote: > > Seems like you are suggesting we have one appendix that imports from > > PKIX/CMS and another that uses later syntax. That seems like a good = way > > forward to me. Tobias should have all of the materials necessary to > produce > > the two appendices. > > > yes, basically. It seems that the intention of the comments from Russ = are > to help implementers as much as possible. To me this means that >=20 > 1 - there should be a syntax that allows to use new asn.1 syntactic > features > so that compiler features may be used as much as possible, e.g. = to > avoid > some hand coded additions for constraints or to type reolution. >=20 > 2 - making a complementary syntax to help those who use tools from the > last millenaire :-) >=20 > It is not the current syntax that is normative because it is richer. > > > >> -----Original Message----- > >> From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] > >> Sent: Thursday, November 23, 2006 5:11 AM > >> To: Carl Wallace > >> Cc: saag@mit.edu; ietf-ltans@imc.org > >> Subject: Re: LTANS summary > >> > >> The LTANS minutes contain the following: > >> > >> "ERS completed working group last call. A new version will > >> be posted that addresses some offlist comments that were > >> submitted during last call. That version will be cross-posted > >> to the S/MIME working group to elicit wider review prior to > >> submission to IESG, which will ideally occur before the end > >> of the year. One comment related to the source for the > >> ContentInfo and AlgorithmIdentifier IMPORT statements in the > >> ASN.1 module. Russ indicated that free compiler support was > >> still lacking and recommended that we maintain the CMS and > >> PKIX IMPORTS. There was no objection, so this change will > >> not be made in version -09. " > >> > >> First: making a decision in this way doesn't seem > >> appropriate. people present at the meeting are not > >> necessarily representative. > >> > >> I object strongly: It is absolutely necessary to provide an > >> ASN1 module that uses current ASN.1 in order to allow modern > >> compilers to work. It is unacceptable to force compiler > >> writers to maintain a difficult and obsololete syntax form, > >> in fact a feature that is assumed not to be implementable > >> correctly at all. > >> > >> It is possible though to provide a module in obsolete syntax > >> that make some existing tools happy. > >> > >> The modules from which imports are done are rather > >> complicated because the also use rather new features of ASN1 > >> like parameterized types. > >> > >> Peter > >> > >> > >> > >> > >> > >> >=20 >=20 > -- > To verify the signature, see http://edelpki.edelweb.fr/ > Cela vous permet de charger le certificat de l'autorit=E9; > die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch. =00 ------=_NextPart_000_006A_01C7255D.E3471060 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 DQEJBTEPFw0wNjEyMjEyMzEyMzdaMCMGCSqGSIb3DQEJBDEWBBQ/Vk8VhxXv6nGF9YvJk05zClUg OjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG SIb3DQEBAQUABIICAGh6J5eHDz3ZWk4K9/54r/cgLvGRguNvEdmxdPz2YtqGMKUVD3Q0TJU4sKjH qXy6wkjMDROso7EYtIV7+T1wgdKzGEYMJ8c+3OablKJSfn1aZmiTigkfXpF5MhZRxg3U774/6qe7 FYRdAEvYq67SinBRsErj7z1uhUY91NUif9YzQnvWsEbHv/7Ugvnm6Q//2kv7bXKbneqCIT0WBwZo qGSAXqaIN0SWPfmFiJ/MgZl3CMrDj18GtHCnhgl8a9r293iJwlhUR5qEpI3Xhxk4u4XWAlK4h+U2 5yhh4E8Fq0JIRERAkpBSM/kKsm6qo51QxfhBf4P9PgKAg/Y7gtCs7rWFCayO3PeZZjorzZ4+hSb+ uC8zvWSLytjpvmG4+n16ZyZ89V5dC2mrzgn7f97jAsuPz+JI0lM3UNKFjE+XVbuOxitF2iY8PxbP ZcpfY1qA5BEQMT7H10O4Cvl5fSEhDtuwG1DniUgBliYliMzjqwSIoZggGNqZ4x6KI/z/L93BGnNH D0TftjIakk5Ek0ZTwwaFRiHsNHgm8uqPnhrDI4xf084wpyssTN/6JZUJpLj2+uvapLV5vC3mEtOB v0GPZeI4gizw638KJJ/KR+dcGHHkSRIOj9EfCjZ2HT3RdHjJP6i5HibF3G2g31Nfj0fx+guC73xL 8X0a6F7AaumP6Fk2AAAAAAAA ------=_NextPart_000_006A_01C7255D.E3471060-- 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 kBEKo3mT074788; Thu, 14 Dec 2006 13:50:03 -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 kBEKo3NX074787; Thu, 14 Dec 2006 13:50:03 -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 ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEKo3qK074781 for ; Thu, 14 Dec 2006 13:50:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8B280175AA; Thu, 14 Dec 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GuxWk-000891-2O; Thu, 14 Dec 2006 15:50:02 -0500 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-10.txt Message-Id: Date: Thu, 14 Dec 2006 15:50:02 -0500 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-10.txt Pages : 19 Date : 2006-12-14 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-10.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-10.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-10.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: <2006-12-14124351.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-reqs-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-reqs-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-14124351.I-D@ietf.org> --OtherAccess-- --NextPart--