Subject: Rechartering the LTANS WG.

From: "TS Glassey" <[email-masked]>
Date: Sat, 19 Jan 2008 17:21:11 -0800

The LTANS WG is scheduled to review the charter in the May time frame. I 
want to propose the addition of language to the charter to provide key 
support in establishing an industry review panel to review this work which 
will extend the LTANS operations for an additional year while those external 
parties who want time to review and comment on the RFC's prior to their 
standardization or advancement along the Standards Practice.

Todd Glassey

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 19 Jan 2008 20:52:31 -0800

Todd and all,

  This your proposal, seems like a very good idea...

Regards,

Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: "Carl Wallace" <[email-masked]>
Date: Sun, 20 Jan 2008 20:12:05 -0500

OK.  There's no need to wait until May to commence the review.  The
specs are and have been available for review for quite some time.
Tobias and I have tried to stimulate broader review (with limited
success).  If you can facilitate this, that'd be great.  Thanks. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of TS Glassey
Sent: Saturday, January 19, 2008 8:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: Rechartering the LTANS WG.

The LTANS WG is scheduled to review the charter in the May time frame. I
want to propose the addition of language to the charter to provide key
support in establishing an industry review panel to review this work
which will extend the LTANS operations for an additional year while
those external parties who want time to review and comment on the RFC's
prior to their standardization or advancement along the Standards
Practice.

Todd Glassey

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 20 Jan 2008 18:19:51 -0800

Thanks Carl - my intent is to foster a public set of use models for using 
LTANS in an evidentiary manner. It will be interesting to see if the ISC 
itself comments on the technology and its use which was my intent.

Todd Glassey

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

Todd Glassey

From: "TS Glassey" <[email-masked]>
To: "Carl Wallace" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "Adrian McCullagh" <[email-masked]>, "Theodore Tso" <[email-masked]>
Subject: Re: Rechartering the LTANS WG.
Date: Sun, 20 Jan 2008 18:19:51 -0800
Sender: [email-masked]

Thanks Carl - my intent is to foster a public set of use models for using 
LTANS in an evidentiary manner. It will be interesting to see if the ISC 
itself comments on the technology and its use which was my intent.

Todd Glassey

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

Todd Glassey

Content-class: urn:content-classes:message
Subject: RE: Rechartering the LTANS WG.
Date: Sun, 20 Jan 2008 20:12:05 -0500
From: "Carl Wallace" <[email-masked]>
To: "TS Glassey" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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

Todd Glassey

Date: Sat, 19 Jan 2008 20:52:31 -0800
From: "Jeffrey A. Williams" <[email-masked]>
Organization: IDNS
To: TS Glassey <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Rechartering the LTANS WG.
Sender: [email-masked]

Todd and all,

Regards,

> standardization or advancement along the Standards Practice.

From: "TS Glassey" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Rechartering the LTANS WG.
Date: Sat, 19 Jan 2008 17:21:11 -0800
Sender: [email-masked]

Todd Glassey

From: "TS Glassey" <[email-masked]>
To: "Jeffrey A. Williams" <[email-masked]>
Cc: "Thomas Kunz" <[email-masked]>, "Turner, Sean P." <[email-masked]>, <[email-masked]>, "Dan Swanson" <[email-masked]>, "DHS cert" <[email-masked]>, "DHS info" <[email-masked]>
Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
Date: Thu, 17 Jan 2008 17:29:43 -0800
Sender: [email-masked]

----- Original Message ----- 
From: "Jeffrey A. Williams" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Thomas Kunz" <[email-masked]>; "Turner, Sean P." 
<[email-masked]>; <[email-masked]>; "Dan Swanson" 
<[email-masked]>; "DHS cert" <[email-masked]>; "DHS info" 
<[email-masked]>
Sent: Thursday, January 17, 2008 5:45 PM
Subject: Re: comment on draft-ietf-ltans-dssc-01.txt

>
> Todd and all,
>
>  I believe that Todd has a good and valuable point here that
> should not be discounted or otherwise ignored.

The issue is simple here - these protocols are to perform tasks which have 
an actual impact under the law and as such the effect they produce or which 
can be had by using the protocol MUST be properly defined otherwise there is 
NO POSSIBLE REASON for building this protocol since it will be prevented 
from its being used by the Audit and Insurance Industry who will simply say 
they wont bond or recognize those that use the protocol.

What we need is formal support and buy-in from any number of professional 
industries for LTANS and if we cannot get it, then anyone who uses the 
protocol will  have to have their own protocol certified individually 
including the entire design. The problem is that this would give them 
leverage over what anyone else did with that protocol, since that 
certification would be for a specific implementation and not the actual 
protocol standard under their workproduct.

The problem with this is that this 'commercial ownership of the 
certification' will encumber ALL of the other users who claim that their 
protocol is 'certified' as well.

The reasoning is that one where basic protocol of party "A" was certified, 
to derivative claims against those other users by the first party to have 
their protocol certified. This also includes damages against the IETF in the 
process, and with this type of liability, IMHO no one will touch LTANS with 
a ten foot pole. That said, this can all be set aside by soliciting outside 
critique of the LTANS protocol by the people who would be responsible for 
using it and auditing it's implementation and use.

Just my two cents

Todd Glassey

>  It could
> be however that whomever the "WE" is which Thomas is referring
> to is unknown or not specifically defined or is a broader group that
> has little or no concern or consideration as to whether all
> are defined, ergo some international rather than US based/centric
> legalistic requirement.  If so, and I cannot myself determine base
> on what I have seen or read thus far clearly enough to make such
> a definitive determination, than I can only logically conclude that
> the "Flat sequence" approach in this protocol will face significant
> resistance as a viable standard.  As such, it may be that the IETF
> will face some significant resistance as a comprehensive standards
> body.
>
>  From my own perspective, I am beginning to find these latest
> comments in this dialog, increasingly troubling....
>
> Regards,
>
> todd glassey wrote:
>> ----- Original Message -----
>> From: "Thomas Kunz" <[email-masked]>
>> To: "Turner, Sean P." <[email-masked]>
>> Cc: <[email-masked]>
>> Sent: Friday, December 07, 2007 7:06 AM
>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
>>
>> > We think, our flat sequence is sufficient.
>>
>> Actually - this is the problem we are facing now Thomas, that is from an
>> evidence management perspective, this "We Think" is not sufficient to 
>> assure
>> LTANS encapsulated documents meet the emerging and followon legal
>> constraints for document archiving is a key flaw in the mindset.
>>
>> >
>> > The goal of a policy is to specify a range for specific 
>> > (safety-critical)
>> > parameters of an algorithm. Therefor it's not necessary to define all
>> > parameters.
>>
>> Uh NO... A policy is a 'rule based on a set of constraints' and as such
>> those constraints and the policy itself need to be defined and verifiable 
>> as
>> well.
>>
>> >
>> > In the evaluations of BSI and NIST
>> > (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms 
>> > only
>> > one value is defined (namely q). By NIST a q_length of 160 is suitable
>> > until 2010.
>>
>> But NIST itself nor BSI are underwriting anyone and those are the key
>> issues. Also ANY service MUST meet the new US Rules of Civil Procedure 
>> and
>> the updated Federal Rules of Evidence in specific to that content's
>> admissibility in US Courts as 'ESI'...
>>
>> >
>> > In this case, the XML structure would be:
>> >
>> > <Algorithm>
>> > <AlgorithmIdentifier>
>> >         <Name>EC-DSA 160</Name>
>> >         <ObjectIdentifier>...</ObjectIdentifier>
>> >        </AlgorithmIdentifier>
>> >         <Parameter name="qLength"><Min>160</Min></Parameter>
>> >         <Validity><End>2010-12-31</End></Validity>
>> > </Algorithm>
>> >
>> >
>> > so & tk
>> >
>> >
>> >
>> >
>> >
>> > Turner, Sean P. schrieb:
>> >> Yes I did misunderstand. With algorithms like DSA where there are few
>> >> parameters your structure might work but for EC algorithms (I attached
>> >> some
>> >> of the ASN.1 for their parameters) I don't think the flat sequence of
>> >> will
>> >> work.
>> >>
>> >>   ECParameters ::= CHOICE {
>> >>     namedCurve      CURVE.&id({NamedCurve}),
>> >>     specifiedCuve   SpecifiedCurve,
>> >>     implicitCurve   NULL
>> >>   }
>> >>
>> >>   CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE }
>> >>     WITH SYNTAX { ID &id }
>> >>
>> >>   NamedCurve CURVE ::= {
>> >>    { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } |
>> >>    { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } |
>> >>    { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } |
>> >>    { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } |
>> >>    { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } |
>> >>    ... -- Extensible
>> >>   }
>> >>
>> >>   SpecifiedCurve ::= SEQUENCE {
>> >>     version  SpecifiedCurveVersion
>> >>                    ( ecpVer1 | ecpVer2 | ecpVer3 ),
>> >>     fieldID  FieldID {{FieldTypes}},
>> >>     curve    Curve,            -- Curve E
>> >>     base     ECPoint,          -- Base point P
>> >>     order    INTEGER,          -- Order n of the base point
>> >>     cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n
>> >>     hash     HashAlgorithm OPTIONAL,
>> >>     ...                        -- Extensible
>> >>   }
>> >>
>> >>   SpecifiedCurveVersion ::= INTEGER {
>> >>     ecpVer1(1),
>> >>     ecpVer2(2),
>> >>     ecpVer3(3),
>> >>     ... -- Extensible
>> >>   }
>> >>   FIELD-ID ::= TYPE-IDENTIFIER
>> >>
>> >>   FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType
>> >> FIELD-ID.&id({IOSet}),
>> >>     parameters FIELD-ID.&Type({IOSet}{@fieldType})
>> >>   }
>> >>
>> >>   FieldTypes FIELD-ID ::= {
>> >>     { Prime-p IDENTIFIED BY prime-field } |
>> >>     { Characteristic-two IDENTIFIED BY characteristic-two-field } |
>> >>     ... -- Extensible
>> >>   }
>> >>
>> >>   prime-field OBJECT IDENTIFIER ::= {
>> >>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 }
>> >>
>> >>   Prime-p ::= INTEGER
>> >>
>> >>   characteristic-two-field OBJECT IDENTIFIER ::= {
>> >>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 }
>> >>
>> >>   Characteristic-two ::= SEQUENCE {
>> >>     m INTEGER, -- Field size 2^m
>> >>     basis CHARACTERISTIC-TWO.&id({BasisTypes}),
>> >>     parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis})
>> >>   }
>> >>
>> >>   CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER
>> >>
>> >>   BasisTypes CHARACTERISTIC-TWO ::= {
>> >>     { NULL        IDENTIFIED BY gnBasis } |
>> >>     { Trinomial   IDENTIFIED BY tpBasis } |
>> >>     { Pentanomial IDENTIFIED BY ppBasis } |
>> >>     ...  -- Extensible
>> >>   }
>> >>
>> >>   gnBasis OBJECT IDENTIFIER ::= {
>> >>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
>> >>     characteristic-two-basis(2) 1 }
>> >>
>> >>   tpBasis OBJECT IDENTIFIER ::= {
>> >>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
>> >>     characteristic-two-basis(2) 2 }
>> >>
>> >>   Trinomial ::= INTEGER
>> >>
>> >>   ppBasis OBJECT IDENTIFIER ::= {
>> >>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
>> >>     characteristic-two-basis(2) 3 }
>> >>
>> >>   Pentanomial ::= SEQUENCE {
>> >>     k1 INTEGER, -- k1 > 0
>> >>     k2 INTEGER, -- k2 > k1
>> >>     k3 INTEGER  -- k3 > k2
>> >>   }
>> >>
>> >>   Curve ::= SEQUENCE {
>> >>     a     FieldElement,
>> >>     b     FieldElement,
>> >>     seed  BIT STRING OPTIONAL
>> >>     -- Shall be present if used in SpecifiedCurve
>> >>     -- with version of ecdpVer2 or ecdpVer3
>> >>   }
>> >>   FieldElement ::= OCTET STRING
>> >>
>> >>   ECPoint ::= OCTET STRING
>> >>> [mailto:[email-masked]] On Behalf Of Thomas Kunz
>> >>> Sent: Thursday, December 06, 2007 4:52 AM
>> >>> To: Turner, Sean P.
>> >>> Cc: [email-masked]
>> >>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
>> >>>
>> >>> We think, You misunderstood our last post.
>> >>> With the mentioned structure (AlgorithmValidityInfo) we wanted to 
>> >>> show
>> >>> that we CANNOT use the AlgorithmIdentifier.
>> >>>
>> >>> The reason is, we cannot model the following cases:
>> >>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 
>> >>> in
>> >>> case of DSA).
>> >>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048)
>> >>>
>> >>> The main problem is that AlgorithmIdentifier describes entirely one
>> >>> algorithm with all its parameters. Therefor it is not possible to set
>> >>> different constraints for the parameters.
>> >>>
>> >>> so & tk
>> >>>
>> >>>
>> >>>
>> >>> Turner, Sean P. schrieb:
>> >>>> This would work for me.
>> >>>>
>> >>>> spt
>> >>>>
>> >>>>> From: Thomas Kunz [mailto:[email-masked]]
>> >>>>> Sent: Wednesday, December 05, 2007 8:02 AM
>> >>>>> To: Turner, Sean P.
>> >>>>> Cc: [email-masked]
>> >>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
>> >>>>>
>> >>>>> The problem with your suggested syntax is the definition of the our
>> >>>>> constraints. If we used the RFC3280 AlgorithmIdentifier
>> >>> structure, we
>> >>>>> would integrate the constraints as follows:
>> >>>>>
>> >>>>> AlgorithmValidityInfo ::= SEQUENCE {
>> >>>>> identifier  AlgorithmIdentifier,
>> >>>>> constraint  CHOICE {
>> >>>>>                        exact  [0] OCTET STRING,
>> >>>>>                        min    [1] OCTET STRING,
>> >>>>>                        max    [2] OCTET STRING,
>> >>>>>                        range  [3] Range,
>> >>>>>                        other  [4] OtherConstraints
>> >>>>> validity    Validity OPTIONAL,
>> >>>>> information Information OPTIONAL }
>> >>>>>
>> >>>>> It's not possible to determine constraints for more than one 
>> >>>>> parameter
>> >>>>> (e.g. p > 1024 and q > 160 in case of DSA).
>> >>>>> Additionally defining ranges is impossible (e.g. modulus <
>> >>>>> 2048 and modulus > 1024).
>> >>>>>
>> >>>>>
>> >>>>> so & tk
>> >>>>>
>> >>>>>
>> >>>>> Turner, Sean P. schrieb:
>> >>>>>> I'm only commenting on the Parameter structure in the
>> >>> ASN.1. I think
>> >>>>>> that it might be better to change Algorithm to be a sequence of
>> >>>>>> algorithmIdentifier, validity, and information - call it
>> >>>>>> AlgorithmValidityInfo. I suggest this for two reasons:
>> >>>>>>
>> >>>>>> 1. The AlgorithmIdentifier structure that is used to assign an
>> >>>>>> algorithm's object identifier also define the parameters. So it
>> >>>>>> probably makes sense to reuse this structure.
>> >>>>>>
>> >>>>>> 2. The parameters structures for some of the newer
>> >>>>> algorithms is quite
>> >>>>>> complicated. For example,  RSASSA-PSS [RFC4055] and ECC Algs
>> >>>>> [RFC3279]
>> >>>>>> aren't just an OID they are nested structure.
>> >>>>>>
>> >>>>>> (not sure how to do it in XML)
>> >>>>>>
>> >>>>>> Replace:
>> >>>>>>
>> >>>>>> Algorithm ::= SEQUENCE {
>> >>>>>>         algorithmIdentifier  AlgID,
>> >>>>>>         parameters           [0] SEQUENCE OF Parameter  OPTIONAL,
>> >>>>>>         validity             [1] Validity,
>> >>>>>>         information          [2] SEQUENCE OF UTF8String OPTIONAL
>> >>>>>>    }
>> >>>>>>
>> >>>>>>    AlgID ::= SEQUENCE {
>> >>>>>>         name  UTF8String,
>> >>>>>>         oid   [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
>> >>>>>>         uri   [1] SEQUENCE OF IA5String OPTIONAL
>> >>>>>>    }
>> >>>>>>
>> >>>>>>    Parameter ::= SEQUENCE {
>> >>>>>>         name        UTF8String,
>> >>>>>>         constraint  CHOICE {
>> >>>>>>                       exact  [0] OCTET STRING,
>> >>>>>>                       min    [1] OCTET STRING,
>> >>>>>>                       max    [2] OCTET STRING,
>> >>>>>>                       range  [3] Range,
>> >>>>>>                       other  [4] OtherConstraints
>> >>>>>>         }
>> >>>>>>    }
>> >>>>>>
>> >>>>>> With:
>> >>>>>>
>> >>>>>> AlgorithmValidityInfo ::= SEQUENCE {  identifier
>> >>>>>> AlgorithmIdentifier,
>> >>>>>>  validity    Validity OPTIONAL,
>> >>>>>>  information Information OPTIONAL }
>> >>>>>>
>> >>>>>> Validity ::= SEQUENCE {
>> >>>>>>   start  [0] GeneralizedTime OPTIONAL,
>> >>>>>>   end    [1] GeneralizedTime OPTIONAL }
>> >>>>>>
>> >>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String
>> >>>>>>
>> >>>>>> -- From RFC3280
>> >>>>>> AlgorithmIdentifier  ::=  SEQUENCE  {
>> >>>>>>      algorithm               OBJECT IDENTIFIER,
>> >>>>>>      parameters              ANY DEFINED BY algorithm OPTIONAL  }
>> >>>>>>                                 -- contains a value of the type
>> >>>>>>                                 -- registered for use with the
>> >>>>>>                                 -- algorithm object
>> >>> identifier value
>> >>>>>> spt
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>
>> >>
>> >
> 

Date: Thu, 17 Jan 2008 17:45:26 -0800
From: "Jeffrey A. Williams" <[email-masked]>
Organization: IDNS
To: todd glassey <[email-masked]>
CC: Thomas Kunz <[email-masked]>, "Turner, Sean P." <[email-masked]>, [email-masked], Dan Swanson <[email-masked]>, DHS cert <[email-masked]>, DHS info <[email-masked]>
Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
Sender: [email-masked]

Todd and all,

  I believe that Todd has a good and valuable point here that
should not be discounted or otherwise ignored.  It could
be however that whomever the "WE" is which Thomas is referring
to is unknown or not specifically defined or is a broader group that
has little or no concern or consideration as to whether all
are defined, ergo some international rather than US based/centric
legalistic requirement.  If so, and I cannot myself determine base
on what I have seen or read thus far clearly enough to make such
a definitive determination, than I can only logically conclude that
the "Flat sequence" approach in this protocol will face significant
resistance as a viable standard.  As such, it may be that the IETF
will face some significant resistance as a comprehensive standards
body.

  From my own perspective, I am beginning to find these latest
comments in this dialog, increasingly troubling....

Regards,

todd glassey wrote:

> ----- Original Message -----
> From: "Thomas Kunz" <[email-masked]>
> To: "Turner, Sean P." <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, December 07, 2007 7:06 AM
> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
>
> > We think, our flat sequence is sufficient.
>
> Actually - this is the problem we are facing now Thomas, that is from an
> evidence management perspective, this "We Think" is not sufficient to assure
> LTANS encapsulated documents meet the emerging and followon legal
> constraints for document archiving is a key flaw in the mindset.
>
> >
> > The goal of a policy is to specify a range for specific (safety-critical)
> > parameters of an algorithm. Therefor it's not necessary to define all
> > parameters.
>
> Uh NO... A policy is a 'rule based on a set of constraints' and as such
> those constraints and the policy itself need to be defined and verifiable as
> well.
>
> >
> > In the evaluations of BSI and NIST
> > (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only
> > one value is defined (namely q). By NIST a q_length of 160 is suitable
> > until 2010.
>
> But NIST itself nor BSI are underwriting anyone and those are the key
> issues. Also ANY service MUST meet the new US Rules of Civil Procedure and
> the updated Federal Rules of Evidence in specific to that content's
> admissibility in US Courts as 'ESI'...
>
> >
> > In this case, the XML structure would be:
> >
> > <Algorithm>
> > <AlgorithmIdentifier>
> >         <Name>EC-DSA 160</Name>
> >         <ObjectIdentifier>...</ObjectIdentifier>
> >        </AlgorithmIdentifier>
> >         <Parameter name="qLength"><Min>160</Min></Parameter>
> >         <Validity><End>2010-12-31</End></Validity>
> > </Algorithm>
> >
> >
> > so & tk
> >
> >
> >
> >
> >
> > Turner, Sean P. schrieb:
> >> Yes I did misunderstand. With algorithms like DSA where there are few
> >> parameters your structure might work but for EC algorithms (I attached
> >> some
> >> of the ASN.1 for their parameters) I don't think the flat sequence of
> >> will
> >> work.
> >>
> >>   ECParameters ::= CHOICE {
> >>     namedCurve      CURVE.&id({NamedCurve}),
> >>     specifiedCuve   SpecifiedCurve,
> >>     implicitCurve   NULL
> >>   }
> >>
> >>   CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE }
> >>     WITH SYNTAX { ID &id }
> >>
> >>   NamedCurve CURVE ::= {
> >>    { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } |
> >>    { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } |
> >>    { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } |
> >>    { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } |
> >>    { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } |
> >>    ... -- Extensible
> >>   }
> >>
> >>   SpecifiedCurve ::= SEQUENCE {
> >>     version  SpecifiedCurveVersion
> >>                    ( ecpVer1 | ecpVer2 | ecpVer3 ),
> >>     fieldID  FieldID {{FieldTypes}},
> >>     curve    Curve,            -- Curve E
> >>     base     ECPoint,          -- Base point P
> >>     order    INTEGER,          -- Order n of the base point
> >>     cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n
> >>     hash     HashAlgorithm OPTIONAL,
> >>     ...                        -- Extensible
> >>   }
> >>
> >>   SpecifiedCurveVersion ::= INTEGER {
> >>     ecpVer1(1),
> >>     ecpVer2(2),
> >>     ecpVer3(3),
> >>     ... -- Extensible
> >>   }
> >>   FIELD-ID ::= TYPE-IDENTIFIER
> >>
> >>   FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType
> >> FIELD-ID.&id({IOSet}),
> >>     parameters FIELD-ID.&Type({IOSet}{@fieldType})
> >>   }
> >>
> >>   FieldTypes FIELD-ID ::= {
> >>     { Prime-p IDENTIFIED BY prime-field } |
> >>     { Characteristic-two IDENTIFIED BY characteristic-two-field } |
> >>     ... -- Extensible
> >>   }
> >>
> >>   prime-field OBJECT IDENTIFIER ::= {
> >>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 }
> >>
> >>   Prime-p ::= INTEGER
> >>
> >>   characteristic-two-field OBJECT IDENTIFIER ::= {
> >>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 }
> >>
> >>   Characteristic-two ::= SEQUENCE {
> >>     m INTEGER, -- Field size 2^m
> >>     basis CHARACTERISTIC-TWO.&id({BasisTypes}),
> >>     parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis})
> >>   }
> >>
> >>   CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER
> >>
> >>   BasisTypes CHARACTERISTIC-TWO ::= {
> >>     { NULL        IDENTIFIED BY gnBasis } |
> >>     { Trinomial   IDENTIFIED BY tpBasis } |
> >>     { Pentanomial IDENTIFIED BY ppBasis } |
> >>     ...  -- Extensible
> >>   }
> >>
> >>   gnBasis OBJECT IDENTIFIER ::= {
> >>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
> >>     characteristic-two-basis(2) 1 }
> >>
> >>   tpBasis OBJECT IDENTIFIER ::= {
> >>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
> >>     characteristic-two-basis(2) 2 }
> >>
> >>   Trinomial ::= INTEGER
> >>
> >>   ppBasis OBJECT IDENTIFIER ::= {
> >>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
> >>     characteristic-two-basis(2) 3 }
> >>
> >>   Pentanomial ::= SEQUENCE {
> >>     k1 INTEGER, -- k1 > 0
> >>     k2 INTEGER, -- k2 > k1
> >>     k3 INTEGER  -- k3 > k2
> >>   }
> >>
> >>   Curve ::= SEQUENCE {
> >>     a     FieldElement,
> >>     b     FieldElement,
> >>     seed  BIT STRING OPTIONAL
> >>     -- Shall be present if used in SpecifiedCurve
> >>     -- with version of ecdpVer2 or ecdpVer3
> >>   }
> >>   FieldElement ::= OCTET STRING
> >>
> >>   ECPoint ::= OCTET STRING
> >>> [mailto:[email-masked]] On Behalf Of Thomas Kunz
> >>> Sent: Thursday, December 06, 2007 4:52 AM
> >>> To: Turner, Sean P.
> >>> Cc: [email-masked]
> >>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
> >>>
> >>> We think, You misunderstood our last post.
> >>> With the mentioned structure (AlgorithmValidityInfo) we wanted to show
> >>> that we CANNOT use the AlgorithmIdentifier.
> >>>
> >>> The reason is, we cannot model the following cases:
> >>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in
> >>> case of DSA).
> >>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048)
> >>>
> >>> The main problem is that AlgorithmIdentifier describes entirely one
> >>> algorithm with all its parameters. Therefor it is not possible to set
> >>> different constraints for the parameters.
> >>>
> >>> so & tk
> >>>
> >>>
> >>>
> >>> Turner, Sean P. schrieb:
> >>>> This would work for me.
> >>>>
> >>>> spt
> >>>>
> >>>>> From: Thomas Kunz [mailto:[email-masked]]
> >>>>> Sent: Wednesday, December 05, 2007 8:02 AM
> >>>>> To: Turner, Sean P.
> >>>>> Cc: [email-masked]
> >>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
> >>>>>
> >>>>> The problem with your suggested syntax is the definition of the our
> >>>>> constraints. If we used the RFC3280 AlgorithmIdentifier
> >>> structure, we
> >>>>> would integrate the constraints as follows:
> >>>>>
> >>>>> AlgorithmValidityInfo ::= SEQUENCE {
> >>>>> identifier  AlgorithmIdentifier,
> >>>>> constraint  CHOICE {
> >>>>>                        exact  [0] OCTET STRING,
> >>>>>                        min    [1] OCTET STRING,
> >>>>>                        max    [2] OCTET STRING,
> >>>>>                        range  [3] Range,
> >>>>>                        other  [4] OtherConstraints
> >>>>> validity    Validity OPTIONAL,
> >>>>> information Information OPTIONAL }
> >>>>>
> >>>>> It's not possible to determine constraints for more than one parameter
> >>>>> (e.g. p > 1024 and q > 160 in case of DSA).
> >>>>> Additionally defining ranges is impossible (e.g. modulus <
> >>>>> 2048 and modulus > 1024).
> >>>>>
> >>>>>
> >>>>> so & tk
> >>>>>
> >>>>>
> >>>>> Turner, Sean P. schrieb:
> >>>>>> I'm only commenting on the Parameter structure in the
> >>> ASN.1. I think
> >>>>>> that it might be better to change Algorithm to be a sequence of
> >>>>>> algorithmIdentifier, validity, and information - call it
> >>>>>> AlgorithmValidityInfo. I suggest this for two reasons:
> >>>>>>
> >>>>>> 1. The AlgorithmIdentifier structure that is used to assign an
> >>>>>> algorithm's object identifier also define the parameters. So it
> >>>>>> probably makes sense to reuse this structure.
> >>>>>>
> >>>>>> 2. The parameters structures for some of the newer
> >>>>> algorithms is quite
> >>>>>> complicated. For example,  RSASSA-PSS [RFC4055] and ECC Algs
> >>>>> [RFC3279]
> >>>>>> aren't just an OID they are nested structure.
> >>>>>>
> >>>>>> (not sure how to do it in XML)
> >>>>>>
> >>>>>> Replace:
> >>>>>>
> >>>>>> Algorithm ::= SEQUENCE {
> >>>>>>         algorithmIdentifier  AlgID,
> >>>>>>         parameters           [0] SEQUENCE OF Parameter  OPTIONAL,
> >>>>>>         validity             [1] Validity,
> >>>>>>         information          [2] SEQUENCE OF UTF8String OPTIONAL
> >>>>>>    }
> >>>>>>
> >>>>>>    AlgID ::= SEQUENCE {
> >>>>>>         name  UTF8String,
> >>>>>>         oid   [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
> >>>>>>         uri   [1] SEQUENCE OF IA5String OPTIONAL
> >>>>>>    }
> >>>>>>
> >>>>>>    Parameter ::= SEQUENCE {
> >>>>>>         name        UTF8String,
> >>>>>>         constraint  CHOICE {
> >>>>>>                       exact  [0] OCTET STRING,
> >>>>>>                       min    [1] OCTET STRING,
> >>>>>>                       max    [2] OCTET STRING,
> >>>>>>                       range  [3] Range,
> >>>>>>                       other  [4] OtherConstraints
> >>>>>>         }
> >>>>>>    }
> >>>>>>
> >>>>>> With:
> >>>>>>
> >>>>>> AlgorithmValidityInfo ::= SEQUENCE {  identifier
> >>>>>> AlgorithmIdentifier,
> >>>>>>  validity    Validity OPTIONAL,
> >>>>>>  information Information OPTIONAL }
> >>>>>>
> >>>>>> Validity ::= SEQUENCE {
> >>>>>>   start  [0] GeneralizedTime OPTIONAL,
> >>>>>>   end    [1] GeneralizedTime OPTIONAL }
> >>>>>>
> >>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String
> >>>>>>
> >>>>>> -- From RFC3280
> >>>>>> AlgorithmIdentifier  ::=  SEQUENCE  {
> >>>>>>      algorithm               OBJECT IDENTIFIER,
> >>>>>>      parameters              ANY DEFINED BY algorithm OPTIONAL  }
> >>>>>>                                 -- contains a value of the type
> >>>>>>                                 -- registered for use with the
> >>>>>>                                 -- algorithm object
> >>> identifier value
> >>>>>> spt
> >>>>>>
> >>>>>>
> >>>>
> >>
> >>
> >

From: "todd glassey" <[email-masked]>
To: "Thomas Kunz" <[email-masked]>, "Turner, Sean P." <[email-masked]>
Cc: <[email-masked]>
Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
Date: Thu, 17 Jan 2008 13:07:25 -0800
Sender: [email-masked]

----- Original Message ----- 
From: "Thomas Kunz" <[email-masked]>
To: "Turner, Sean P." <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 07, 2007 7:06 AM
Subject: Re: comment on draft-ietf-ltans-dssc-01.txt

> We think, our flat sequence is sufficient.

Actually - this is the problem we are facing now Thomas, that is from an 
evidence management perspective, this "We Think" is not sufficient to assure 
LTANS encapsulated documents meet the emerging and followon legal 
constraints for document archiving is a key flaw in the mindset.

>
> The goal of a policy is to specify a range for specific (safety-critical) 
> parameters of an algorithm. Therefor it's not necessary to define all 
> parameters.

Uh NO... A policy is a 'rule based on a set of constraints' and as such 
those constraints and the policy itself need to be defined and verifiable as 
well.

>
> In the evaluations of BSI and NIST
> (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only 
> one value is defined (namely q). By NIST a q_length of 160 is suitable 
> until 2010.

But NIST itself nor BSI are underwriting anyone and those are the key 
issues. Also ANY service MUST meet the new US Rules of Civil Procedure and 
the updated Federal Rules of Evidence in specific to that content's 
admissibility in US Courts as 'ESI'...

>
> In this case, the XML structure would be:
>
> <Algorithm>
> <AlgorithmIdentifier>
>         <Name>EC-DSA 160</Name>
>         <ObjectIdentifier>...</ObjectIdentifier>
>        </AlgorithmIdentifier>
>         <Parameter name="qLength"><Min>160</Min></Parameter>
>         <Validity><End>2010-12-31</End></Validity>
> </Algorithm>
>
>
> so & tk
>
>
>
>
>
> Turner, Sean P. schrieb:
>> Yes I did misunderstand. With algorithms like DSA where there are few
>> parameters your structure might work but for EC algorithms (I attached 
>> some
>> of the ASN.1 for their parameters) I don't think the flat sequence of 
>> will
>> work.
>>
>>   ECParameters ::= CHOICE {
>>     namedCurve      CURVE.&id({NamedCurve}),
>>     specifiedCuve   SpecifiedCurve,
>>     implicitCurve   NULL
>>   }
>>
>>   CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE }
>>     WITH SYNTAX { ID &id }
>>
>>   NamedCurve CURVE ::= {
>>    { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } |
>>    { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } |
>>    { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } |
>>    { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } |
>>    { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } |
>>    ... -- Extensible
>>   }
>>
>>   SpecifiedCurve ::= SEQUENCE {
>>     version  SpecifiedCurveVersion
>>                    ( ecpVer1 | ecpVer2 | ecpVer3 ),
>>     fieldID  FieldID {{FieldTypes}},
>>     curve    Curve,            -- Curve E
>>     base     ECPoint,          -- Base point P
>>     order    INTEGER,          -- Order n of the base point
>>     cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n
>>     hash     HashAlgorithm OPTIONAL,
>>     ...                        -- Extensible
>>   }
>>
>>   SpecifiedCurveVersion ::= INTEGER {
>>     ecpVer1(1),
>>     ecpVer2(2),
>>     ecpVer3(3),
>>     ... -- Extensible
>>   }
>>   FIELD-ID ::= TYPE-IDENTIFIER
>>
>>   FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType 
>> FIELD-ID.&id({IOSet}),
>>     parameters FIELD-ID.&Type({IOSet}{@fieldType})
>>   }
>>
>>   FieldTypes FIELD-ID ::= {
>>     { Prime-p IDENTIFIED BY prime-field } |
>>     { Characteristic-two IDENTIFIED BY characteristic-two-field } |
>>     ... -- Extensible
>>   }
>>
>>   prime-field OBJECT IDENTIFIER ::= {
>>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 }
>>
>>   Prime-p ::= INTEGER
>>
>>   characteristic-two-field OBJECT IDENTIFIER ::= {
>>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 }
>>
>>   Characteristic-two ::= SEQUENCE {
>>     m INTEGER, -- Field size 2^m
>>     basis CHARACTERISTIC-TWO.&id({BasisTypes}),
>>     parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis})
>>   }
>>
>>   CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER
>>
>>   BasisTypes CHARACTERISTIC-TWO ::= {
>>     { NULL        IDENTIFIED BY gnBasis } |
>>     { Trinomial   IDENTIFIED BY tpBasis } |
>>     { Pentanomial IDENTIFIED BY ppBasis } |
>>     ...  -- Extensible
>>   }
>>
>>   gnBasis OBJECT IDENTIFIER ::= {
>>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
>>     characteristic-two-basis(2) 1 }
>>
>>   tpBasis OBJECT IDENTIFIER ::= {
>>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
>>     characteristic-two-basis(2) 2 }
>>
>>   Trinomial ::= INTEGER
>>
>>   ppBasis OBJECT IDENTIFIER ::= {
>>     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
>>     characteristic-two-basis(2) 3 }
>>
>>   Pentanomial ::= SEQUENCE {
>>     k1 INTEGER, -- k1 > 0
>>     k2 INTEGER, -- k2 > k1
>>     k3 INTEGER  -- k3 > k2
>>   }
>>
>>   Curve ::= SEQUENCE {
>>     a     FieldElement,
>>     b     FieldElement,
>>     seed  BIT STRING OPTIONAL
>>     -- Shall be present if used in SpecifiedCurve
>>     -- with version of ecdpVer2 or ecdpVer3
>>   }
>>   FieldElement ::= OCTET STRING
>>
>>   ECPoint ::= OCTET STRING
>>> [mailto:[email-masked]] On Behalf Of Thomas Kunz
>>> Sent: Thursday, December 06, 2007 4:52 AM
>>> To: Turner, Sean P.
>>> Cc: [email-masked]
>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
>>>
>>> We think, You misunderstood our last post.
>>> With the mentioned structure (AlgorithmValidityInfo) we wanted to show 
>>> that we CANNOT use the AlgorithmIdentifier.
>>>
>>> The reason is, we cannot model the following cases:
>>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in 
>>> case of DSA).
>>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048)
>>>
>>> The main problem is that AlgorithmIdentifier describes entirely one 
>>> algorithm with all its parameters. Therefor it is not possible to set 
>>> different constraints for the parameters.
>>>
>>> so & tk
>>>
>>>
>>>
>>> Turner, Sean P. schrieb:
>>>> This would work for me.
>>>>
>>>> spt
>>>>
>>>>> From: Thomas Kunz [mailto:[email-masked]]
>>>>> Sent: Wednesday, December 05, 2007 8:02 AM
>>>>> To: Turner, Sean P.
>>>>> Cc: [email-masked]
>>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt
>>>>>
>>>>> The problem with your suggested syntax is the definition of the our 
>>>>> constraints. If we used the RFC3280 AlgorithmIdentifier
>>> structure, we
>>>>> would integrate the constraints as follows:
>>>>>
>>>>> AlgorithmValidityInfo ::= SEQUENCE {
>>>>> identifier  AlgorithmIdentifier,
>>>>> constraint  CHOICE {
>>>>>                        exact  [0] OCTET STRING,
>>>>>                        min    [1] OCTET STRING,
>>>>>                        max    [2] OCTET STRING,
>>>>>                        range  [3] Range,
>>>>>                        other  [4] OtherConstraints
>>>>> validity    Validity OPTIONAL,
>>>>> information Information OPTIONAL }
>>>>>
>>>>> It's not possible to determine constraints for more than one parameter 
>>>>> (e.g. p > 1024 and q > 160 in case of DSA).
>>>>> Additionally defining ranges is impossible (e.g. modulus <
>>>>> 2048 and modulus > 1024).
>>>>>
>>>>>
>>>>> so & tk
>>>>>
>>>>>
>>>>> Turner, Sean P. schrieb:
>>>>>> I'm only commenting on the Parameter structure in the
>>> ASN.1. I think
>>>>>> that it might be better to change Algorithm to be a sequence of 
>>>>>> algorithmIdentifier, validity, and information - call it 
>>>>>> AlgorithmValidityInfo. I suggest this for two reasons:
>>>>>>
>>>>>> 1. The AlgorithmIdentifier structure that is used to assign an 
>>>>>> algorithm's object identifier also define the parameters. So it 
>>>>>> probably makes sense to reuse this structure.
>>>>>>
>>>>>> 2. The parameters structures for some of the newer
>>>>> algorithms is quite
>>>>>> complicated. For example,  RSASSA-PSS [RFC4055] and ECC Algs
>>>>> [RFC3279]
>>>>>> aren't just an OID they are nested structure.
>>>>>>
>>>>>> (not sure how to do it in XML)
>>>>>>
>>>>>> Replace:
>>>>>>
>>>>>> Algorithm ::= SEQUENCE {
>>>>>>         algorithmIdentifier  AlgID,
>>>>>>         parameters           [0] SEQUENCE OF Parameter  OPTIONAL,
>>>>>>         validity             [1] Validity,
>>>>>>         information          [2] SEQUENCE OF UTF8String OPTIONAL
>>>>>>    }
>>>>>>
>>>>>>    AlgID ::= SEQUENCE {
>>>>>>         name  UTF8String,
>>>>>>         oid   [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
>>>>>>         uri   [1] SEQUENCE OF IA5String OPTIONAL
>>>>>>    }
>>>>>>
>>>>>>    Parameter ::= SEQUENCE {
>>>>>>         name        UTF8String,
>>>>>>         constraint  CHOICE {
>>>>>>                       exact  [0] OCTET STRING,
>>>>>>                       min    [1] OCTET STRING,
>>>>>>                       max    [2] OCTET STRING,
>>>>>>                       range  [3] Range,
>>>>>>                       other  [4] OtherConstraints
>>>>>>         }
>>>>>>    }
>>>>>>
>>>>>> With:
>>>>>>
>>>>>> AlgorithmValidityInfo ::= SEQUENCE {  identifier 
>>>>>> AlgorithmIdentifier,
>>>>>>  validity    Validity OPTIONAL,
>>>>>>  information Information OPTIONAL }
>>>>>>
>>>>>> Validity ::= SEQUENCE {
>>>>>>   start  [0] GeneralizedTime OPTIONAL,
>>>>>>   end    [1] GeneralizedTime OPTIONAL }
>>>>>>
>>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String
>>>>>>
>>>>>> -- From RFC3280
>>>>>> AlgorithmIdentifier  ::=  SEQUENCE  {
>>>>>>      algorithm               OBJECT IDENTIFIER,
>>>>>>      parameters              ANY DEFINED BY algorithm OPTIONAL  }
>>>>>>                                 -- contains a value of the type
>>>>>>                                 -- registered for use with the
>>>>>>                                 -- algorithm object
>>> identifier value
>>>>>> spt
>>>>>>
>>>>>>
>>>>
>>
>>
> 

Date: Wed, 02 Jan 2008 17:57:59 +0100
From: Peter Sylvester <[email-masked]>
To: todd glassey <[email-masked]>
Cc: Jesus Maria Mendez Perez <[email-masked]>, Tobias Gondrom <[email-masked]>, [email-masked]
Subject: Re: ERS - using hash tree?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040405070401050002030504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

>
> As to your commentary - Those five hours of data are spoiled and well=20
> - that makes this a real issue I think.
>
What is the issue in your opinion?
- The archive does not yet agree to have a safe copy? (and may be in=20
fact it is lying?)
- The archive may loose everything withing these 5 hours (+1 day etc),=20
before sending
  the ack.

If you want to make the group listen to you comments you should provide
at least more details of the problem space, ideas of possibles approaches=

or ask for clarifications about something concrete.

The approach used in this group (as well as in others) is to define=20
technology
not just as a minimalistic reaction to whatever concrete legislation or=20
jurisprudence.
No games between 'Hase und Igel'.

Happy new year
Peter

--=20
To verify the signature, see http://edelpki.edelweb.fr/=20
Cela vous permet de charger le certificat de l'autorit=E9;=20
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20

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

--------------ms040405070401050002030504--

Date: Wed, 02 Jan 2008 17:49:01 +0100
From: Peter Sylvester <[email-masked]>
To: Jesus Maria Mendez Perez <[email-masked]>
Cc: Tobias Gondrom <[email-masked]>, [email-masked]
Subject: Re: ERS - using hash tree?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060904010506020201080909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Jesus Maria Mendez Perez wrote:
> Hello Tobias, I=B4m Jesus.
Merry Christmas.
>
> I have some questions and I hope you can help me.
>
> First, about what happen with the gap of time that pass while you send =

> a data object and finally at the evening the ERS-system build
> the hastree for all documents that were archived during that day?. For =

> example, if you send a data object at 3:00 pm and the ERS-system build =

> the hashtree at 8:00 pm... you have 5 hours during which that data=20
> object could lose its integrity. What can we do in this situation?
> Could be the solution to timestamp every data object separately and=20
> inmediately after they are sent by the client and when the ERS-system=20
> have to build the hashtree, the hash-tree will built with all these=20
> data objects and its timestamps?
IMO opinion you need to distingusih two events: A 3:00pm a client enters =

something into an archive.Looking
at LTAP, this may result in a first 'receipt', indicating that archiving =

is 'in progress'. At 8:00 or
even a day later (when backup copies etc are made), the archive may=20
return a 'now we have a safe archived copy'
message.
>
> And now about the ARCHIVE operation. In the LTAP Protocol draft is=20
> said LTAP Protocol is asynchronous by nature. And my question is about =

> then second response (service response). Will a client receive the=20
> second response when the TAS hast just received the data object or=20
> when the archive operation has just finished (the hashtree has been=20
> built)?
The second message is sent when the TAS can safely assume that it has a=20
good recoverable copy.
If ERS is part of the policy of the TAS, then the TAS most likely does=20
not respond before having
created a good tree, and backups and backups of the trees ... etc
> If the ARCHIVE operation is asynchronous we really need another=20
> operation to permit a client to check if the full archive operation=20
> has finished...
Which is the case with LTAP.
The protocol does not necessarily be mapped to HTTP, you
can map the second ack to a mail based service.
The abstract protocol allows to 'poll for a response' in several ways:
After having received the initial response or even before, you can=20
repeat the archive
operation using the hash of the data as reference or the reference=20
return by the initial ack.
You do this until you get the final response.

What this means is that a client does have to do some housekeeping in=20
some 'spooling server'
similar to email or to a tcp stack.

Even the initial ack is conceptually asynchronous allow a client API=20
implementation
to be completely non-blocking, etc.
>
> Finally about the information called "Complementary data" in the=20
> article "Long-term trusted preservation service using service=20
> interaction protocol and evidence records", does it include only=20
> timestamping certificates?, or does it include timestamps' certificates=

> and user signer=B4s certificates?. Are they obtain by SCVP and save up =

> as complementary data in the archive operation?
I let Aljosa answer this.
>
> Thanks and Happy Christmas
>
Happy new year.
Peter

--=20
To verify the signature, see http://edelpki.edelweb.fr/=20
Cela vous permet de charger le certificat de l'autorit=E9;=20
die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20

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

--------------ms060904010506020201080909--