Subject: Re: draft-ietf-ltans-dssc-00 comments
From: "todd glassey" <[email-masked]>
To: "Thomas Kunz" <[email-masked]>
Cc: <[email-masked]>, "Mike Fratto" <[email-masked]>
Date: Wed, 29 Aug 2007 09:40:52 -0700
List-Id: <ietf-ltans.imc.org>

Herr Kunz - allow me to expand and provide some links backing up what I am 
saying here. More inline below -

[ By the way - although these rules are specific to US Courts, through the 
MRA's (Mutual Recognition Agreement's) and the Legal Metrological 
Agreement's between our Countries these are important factors to at least 
review in the design of anything that will be used to contain long-term 
legally-provable instances of anything, no matter what Jurisdiction they are 
operated in or pursuant to the rules of...]

----- Original Message ----- 
From: "Thomas Kunz" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 29, 2007 7:56 AM
Subject: Re: draft-ietf-ltans-dssc-00 comments

> todd glassey schrieb:
>
>>
>> That is a decision controlled by the Hosting Entity's Operations Policies 
>> and needs to be retained as such. The answer is that both methods should 
>> work IMHO.
>>
> With "Hosting Entity" do you mean the publisher of a policy?

Yes although that policy may be layered on other local policies and/or 
controls as well.
>
>
>>> > For policy brevity,
>>
>> which  IS NOT a good thing here... Policy is what allows NEA to be used 
>> in a number of different scenario's
>>
> Unfortunately, we are not familiar with the abbreviations you use (NEA, 
> MRA, FRE). So would you please give some explanations? Thanks.

NEA is the IETF NEA  proposed protocol - a toolset for preqwualifing and 
continuously qualifying a node or infrastructure for 'permission to operate' 
within a network at some defined level of Entitlement.

MRA is a term meaning 'Mutual Recognition Agreements' - these are treaties 
and other agreement's like the "Legal Metrological Agreement's" which create 
the ability to internationally timestamp digital content.  Here for example 
is a MRA between the US and Iceland which also notices conformity with EFTA 
and EEA entity rules as well. 
http://ts.nist.gov/Standards/Global/upload/US-EEA_EFTA_States_MRA_Oct_17_051.pdf - 
the point is that there a MANY of these which constrain the operations of 
international commerce - something that LTANS needs to facilitate the 
enduring proof of.

FRE is the US Federal Rules of Evidence - which constrain how content is 
qualified as evidence for the US District and Circuit Courts. 
http://www.law.cornell.edu/rules/fre/

>
>
>> Nope... I dont think this has anything to do with "law cases". I think it 
>> has to do with logging and assurance models and that's about it. What's 
>> missing is to qualify NEA under the new Judge Grimm ruling so that NEA 
>> based testimnoy ius admissible into the US and Foreign Court's that 
>> support similar standards or MRA's.
>>
>> You want to know what is missing here?
>>
>> a.. Relevance; i.e. meets F.R.E. 401
>>
> <snip>
>
> Also at this point, some further explanations would be nice and helpful 
> for understanding.

On May 4th 2007 a US Federal Court Judge (Chief Magistrate Judge Paul W. 
Grimm) from the Maryland District Courts issued what many are referring to 
as a landmark ruling in a key case called Lorraine v Markel, and as to what 
that case has to do with the IETF's LTANS group, it set the standard under 
the US Federal Rules of Evidence for what ESI (Electronically Stored 
Information) MUST comply with in order to be admissible in a US Court. See 
our link at www.wireless-time.com/site/news/news-judicial1.htm for links to 
the Judges ruling itself.

Poof - instant hurdle for anything that would create or maintain digital 
content for legal review.

The scope of this ruling is just now being understood because a number of us 
have actually broken the interacting laws down through flowcharting and 
process mapping to make a mechanical determination of the scope of this 
ruling. 
http://www.ediscoverylaw.com/2007/05/articles/case-summaries/chief-us-magistrate-judge-grimm-provides-detailed-analysis-of-evidentiary-issues-associated-with-electronic-evidence/

That scope not only includes any and all information which civilians may 
bring before the Court but also to any ESI which a US Attorney may come to 
bring before the Federal Court's as evidence of something. That means any 
document which is formally filed with the US Government by ANYONE is 
constrained under this since it is the Courts, which under the 
Constritutions Articles and in particular, US Code's Title 5, provides 
relief from Executive and certain DoD Branch actions as well as Lower Court 
rulings.

So Judge Grimm's District Court (DC) ruling actually effects the use of 
LTANS technology in the US directly but it also forces that same recognition 
by any "Foreign Entity which is tied to the US through Mutual Recognition 
Agreement's for time and other legal standards"... and yes this ruling 
invalidates a number of the components and idea behind RFC3161 as well as 
the ETSI's time stamping directive which violates those MRAs directly 
andIMHO International Law as such.

As to why he could do this - Judge Grimm is one of the US Court Systems 
strongest proponents of rules for digital content. He is a very noted Judge 
who's role as the Chief Magistrate Judge for his district gives him exactly 
this ability.

http://www.msa.md.gov/msa/mdmanual/39fed/04usmag/html/msa13723.html

http://www.thesedonaconference.org/people/profiles/GrimmPaul

Todd

> 

Date: Wed, 29 Aug 2007 16:56:24 +0200
From: Thomas Kunz <[email-masked]>
To: todd glassey <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-ltans-dssc-00 comments
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms020408060809000506050904
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

todd glassey schrieb:

> 
> That is a decision controlled by the Hosting Entity's Operations 
> Policies and needs to be retained as such. The answer is that both 
> methods should work IMHO.
>
With "Hosting Entity" do you mean the publisher of a policy?

>> > For policy brevity,
> 
> which  IS NOT a good thing here... Policy is what allows NEA to be used 
> in a number of different scenario's
>
Unfortunately, we are not familiar with the abbreviations you use (NEA, 
MRA, FRE). So would you please give some explanations? Thanks.

> Nope... I dont think this has anything to do with "law cases". I think 
> it has to do with logging and assurance models and that's about it. 
> What's missing is to qualify NEA under the new Judge Grimm ruling so 
> that NEA based testimnoy ius admissible into the US and Foreign Court's 
> that support similar standards or MRA's.
> 
> You want to know what is missing here?
> 
> a.. Relevance; i.e. meets F.R.E. 401
> 
<snip>

Also at this point, some further explanations would be nice and helpful 
for understanding.

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

--------------ms020408060809000506050904--

Date: Wed, 29 Aug 2007 16:43:02 +0200
From: Thomas Kunz <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-ltans-dssc-00 comments
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Guten Tag,

Peter Sylvester schrieb:
> Guten Abend,
> 
> I have a problem with the first important use case concerning archiving.
> 
> I am not sure what is actually what kind of signatures are addressed here.
> 
> - An archive service can have internal signatures or signatures on 
> attestations
>  concerning that data that are archived.
> - user signatures of data in archive, i.e. the archive stored signed 
> documents.
> 
> Which means also who is supposed to re-sign, time stamp or whatever.
> 
With the first use case (long-term archiving) we address user signatures 
of data in the archive as well as signatures in (archive)timestamps. So 
the re-signing is done by the archive service.

Of course when verifying the internal signatures of the archive service 
(e.g. signatures on attestations), the validity of the used algorithms 
can also be checked, but I think, that is covered by our second use case 
(signing and verifying).

Regards
Thomas

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

--------------ms000200020208070500080706--

Date: Mon, 27 Aug 2007 19:53:35 +0200
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: draft-ietf-ltans-dssc-00 comments
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Guten Abend,

I have a problem with the first important use case concerning archiving.

I am not sure what is actually what kind of signatures are addressed here.

- An archive service can have internal signatures or signatures on 
attestations
  concerning that data that are archived.
- user signatures of data in archive, i.e. the archive stored signed 
documents.

Which means also who is supposed to re-sign, time stamp or whatever.

I think the paragraph needs at least some more precise definition, in 
particular
with regard to what is defined in LTAP.

regards
Peter

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

--------------ms000505010705020608030709--

From: "todd glassey" <[email-masked]>
To: "Thomas Kunz" <[email-masked]>, "Carl Wallace" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-ietf-ltans-dssc-00 comments
Date: Mon, 27 Aug 2007 09:41:22 -0700
Sender: [email-masked]

----- Original Message ----- 
From: "Thomas Kunz" <[email-masked]>
To: "Carl Wallace" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 27, 2007 7:10 AM
Subject: Re: draft-ietf-ltans-dssc-00 comments

> Hello Carl,
>
> sorry for the late answer.
>
> Carl Wallace schrieb:
>> Here are a few comments on DSSC.  I'll send an off list email with some 
>> editorial comments.
>>
>> - In section 4.1, the fifth element in the sequence should be named 
>> SuitableAlgorithm to be consistent with the schema in Appendix B
>>
> OK
>
>
>> - The draft should provide some guidance regarding constraints.  For 
>> example, should one define key size constraints per public key algorithm 
>> or per each signature algorithm?

That is a decision controlled by the Hosting Entity's Operations Policies 
and needs to be retained as such. The answer is that both methods should 
work IMHO.

> > For policy brevity,

which  IS NOT a good thing here... Policy is what allows NEA to be used in a 
number of different scenario's

>> the former would be better.  Perhaps an alternative would be to bind 
>> constraints and validity periods within SuitableAlgorithm.
>>
> I would also prefer the definition of constraints per public key 
> algorithm.

But how is that to be represented? Is it part of the internal policy 
controlled by SuitableAlgorithm or where then is it enumerated?

>
>> - Section 5 should include processing for constraints.
> OK
>
>> - The spec should prohibit including multiple instances of the same 
>> algorithm identifier w/ the same constraints.

If they have those different policy contraints tagged to them then they are 
different policy instances. Hence it would be reasonable to have multiple 
policies around the same PKI model.

>>
> OK
>
>> - If an ASN.1 version is to be produced, using an enveloping signature 
>> would make the mapping to CMS easier.
>>
> OK. An ASN.1 version should come with the next version of the draft.
>
>> - The assumption in Section 3.2 that one must find an old policy in order 
>> to determine if an algorithm was valid at a point in the past is too 
>> complicated.  Suitability definitions should accumulate in a single 
>> policy definition.  An enterprise could maintain several policies.  For 
>> example, one complete, one current and one past policy could be 
>> maintained.

Uh, policies could be setup based on Role and Responsibility Separation 
Models and as such its likely that similar policies would exist in the same 
NEA Domain(s).

>>
> In our notion, the policies are published by specific institutions (e.g. 
> annually) and one policy represents the evaluations based on current 
> knowledge (e.g. on current findings, RSA with 1024 bit key length could be 
> valid until end of 2007, but next year a new policy could be published 
> which states that RSA 1024 is valid until end of 2008).
> To expect, that a policy also contains all past evaluations of an 
> algorithms could be error-prone.

Customized Policies are the creation of those that adopt the NEA system, but 
basic operations policies are what the framework should come out-of-the-bag 
with.

> In our opinion, the question, if the evaluation of an algorithm in an old 
> policy is different from that in the current policy is primarily important 
> in law cases.

Nope... I dont think this has anything to do with "law cases". I think it 
has to do with logging and assurance models and that's about it. What's 
missing is to qualify NEA under the new Judge Grimm ruling so that NEA based 
testimnoy ius admissible into the US and Foreign Court's that support 
similar standards or MRA's.

You want to know what is missing here?

a.. Relevance; i.e. meets F.R.E. 401

So a process for determining relevancy of the information produced and its 
integrity is key.

a.. Authentication; i.e. meets F.R.E. 901

Authentication as to where the information came from is key. Also that the 
material submitted is what was authenticated meaning that content-integrity 
propcesses are mandatory as well.

a.. Hearsay (if offered for truth) i.e. meets  F.R.E 801

The mechanical processes for how this information is produced must be mapped 
out such that it can be demonstrated to a Court that this data is either 
beyond hear-say or that the heay-say exceptions in re statements against 
interest is brouught into play such that this evidence is admissible.

a.. Original or Duplicate i.e. meets F.R.E. 1001-1008

OK so is this the original data from the system or a copy/fake of it?

a.. Probative Value Outweighed by Prejudicial Value i.e. meets F.R.E. 403

This actually is a set of pre-built policy statements which are designed to 
meet the requirements of FRE403. These would be a part of the NEA boiler 
plate and would be the basis of NEA Data's being admitted into the Courts as 
proper Machine-Testimony.

As noted in the above list, these are the five key tests for Digital 
Evidence being admitted to the US Federal Courts.  Of these probably 1,2, 3 
and 4 are key tests. Test 5 would be something that would happen at hearing 
time if the rest of the submission actually meets the other tests and that 
the opposing counsel doesnt object to 'how it meets those tests' which this 
group is directly responsible for designing. otherwise each system fielded 
will have to be proven in Court under a DAUBERT type hearing and if that is 
true then the IETF will have totally failed there.

As to old policy and its review, the review of old policy relative to new 
policy should only come into play when a new system is installed into a 
network hosting NEA service-qualifications, or when an existing policy 
expires and a new one comes into play, and that only has to do with changes 
in the Entitlement and Logging Constraints for that "New Policy" relative to 
the old one.

> And there you cannot trust, that the current policy correctly quotes past 
> evaluations, instead you will have to look in the old policy.

Only if there is a policy saying that. I can think of any number of NEA 
scenario's where the current client doesnt care what the past policies were. 
So I disagree as to 'that the old policies will always need to be reviewed' 
or be maintained as 'reviewable'.

>
> Best regards,
> Thomas
>
>
> 

From: Carl Wallace <[email-masked]>
To: Thomas Kunz <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-ietf-ltans-dssc-00 comments
Date: Mon, 27 Aug 2007 12:36:43 -0400
Sender: [email-masked]

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

------_=_NextPart_001_01C7E8C8.73F01C1A
Content-Type: text/plain

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

I wasn't suggesting that a policy contain all past evaluations.  I was
suggesting that the current policy would contain the current position with
regard to an algorithm's life span, even if the algorithm is no longer
viable, and that's the only thing that matters.  I don't see the value in
referring to an old policy since the position on an algorithm can change
over time.  Using your example, in my opinion, the only thing that matters
to the verifier is what the current position is with regard to an algorithm.
The fact that an algorithm's expected life span at the time a signature was
generated was thought to be shorter than it turned out to be isn't
important.  

Annual publication makes sense and makes it easy to perform the
accumulation.  Someone verifying an evidence record will need to know when
an algorithm stopped being suitable.  It'd be nice if this information could
be contained in one location instead of having to collect old policies,
i.e., verifiers always use the current edition.  My comment that there could
be multiple policies was probably confusing.  The idea there was that for
apps that don't use any expired algorithm, there could be a very brief
policy statement with just the currently viable algorithms.  Having one full
statement is probably easiest though.

------_=_NextPart_001_01C7E8C8.73F01C1A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>RE: draft-ietf-ltans-dssc-00 comments</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I wasn't suggesting that a policy contain all past =
evaluations.&nbsp; I was suggesting that the current policy would =
contain the current position with regard to an algorithm's life span, =
even if the algorithm is no longer viable, and that's the only thing =
that matters.&nbsp; I don't see the value in referring to an old policy =
since the position on an algorithm can change over time.&nbsp; Using =
your example, in my opinion, the only thing that matters to the =
verifier is what the current position is with regard to an =
algorithm.&nbsp; The fact that an algorithm's expected life span at the =
time a signature was generated was thought to be shorter than it turned =
out to be isn't important.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Annual publication makes sense and makes it easy to =
perform the accumulation.&nbsp; Someone verifying an evidence record =
will need to know when an algorithm stopped being suitable.&nbsp; It'd =
be nice if this information could be contained in one location instead =
of having to collect old policies, i.e., verifiers always use the =
current edition.&nbsp; My comment that there could be multiple policies =
was probably confusing.&nbsp; The idea there was that for apps that =
don't use any expired algorithm, there could be a very brief policy =
statement with just the currently viable algorithms.&nbsp; Having one =
full statement is probably easiest though.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C7E8C8.73F01C1A--

Date: Mon, 27 Aug 2007 16:10:57 +0200
From: Thomas Kunz <[email-masked]>
To: Carl Wallace <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-ltans-dssc-00 comments
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

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

Hello Carl,

sorry for the late answer.

Carl Wallace schrieb:
> Here are a few comments on DSSC.  I'll send an off list email with some 
> editorial comments.
> 
> - In section 4.1, the fifth element in the sequence should be named 
> SuitableAlgorithm to be consistent with the schema in Appendix B
> 
OK

> - The draft should provide some guidance regarding constraints.  For 
> example, should one define key size constraints per public key algorithm 
> or per each signature algorithm?  For policy brevity, the former would 
> be better.  Perhaps an alternative would be to bind constraints and 
> validity periods within SuitableAlgorithm.
> 
I would also prefer the definition of constraints per public key algorithm.

> - Section 5 should include processing for constraints. 
>
OK

> - The spec should prohibit including multiple instances of the same 
> algorithm identifier w/ the same constraints.
>
OK

> - If an ASN.1 version is to be produced, using an enveloping signature 
> would make the mapping to CMS easier.
>
OK. An ASN.1 version should come with the next version of the draft.

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

Best regards,
Thomas

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

--------------ms070309080407070303040809--

From: Carl Wallace <[email-masked]>
To: [email-masked]
Subject: draft-ietf-ltans-dssc-00 comments
Date: Mon, 20 Aug 2007 13:54:28 -0400
Sender: [email-masked]

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

------_=_NextPart_001_01C7E353.272F3FF0
Content-Type: text/plain

Here are a few comments on DSSC.  I'll send an off list email with some
editorial comments.

- In section 4.1, the fifth element in the sequence should be named
SuitableAlgorithm to be consistent with the schema in Appendix B

- The draft should provide some guidance regarding constraints.  For
example, should one define key size constraints per public key algorithm or
per each signature algorithm?  For policy brevity, the former would be
better.  Perhaps an alternative would be to bind constraints and validity
periods within SuitableAlgorithm.

- Section 5 should include processing for constraints.  

- The spec should prohibit including multiple instances of the same
algorithm identifier w/ the same constraints.

- If an ASN.1 version is to be produced, using an enveloping signature would
make the mapping to CMS easier.

- The assumption in Section 3.2 that one must find an old policy in order to
determine if an algorithm was valid at a point in the past is too
complicated.  Suitability definitions should accumulate in a single policy
definition.  An enterprise could maintain several policies.  For example,
one complete, one current and one past policy could be maintained.

------_=_NextPart_001_01C7E353.272F3FF0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>draft-ietf-ltans-dssc-00 comments</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Here are a few comments on DSSC.&nbsp; I'll send an =
off list email with some editorial comments.</FONT>
</P>

<P><FONT SIZE=3D2>- In section 4.1, the fifth element in the sequence =
should be named SuitableAlgorithm to be consistent with the schema in =
Appendix B</FONT></P>

<P><FONT SIZE=3D2>- The draft should provide some guidance regarding =
constraints.&nbsp; For example, should one define key size constraints =
per public key algorithm or per each signature algorithm?&nbsp; For =
policy brevity, the former would be better.&nbsp; Perhaps an =
alternative would be to bind constraints and validity periods within =
SuitableAlgorithm.</FONT></P>

<P><FONT SIZE=3D2>- Section 5 should include processing for =
constraints.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>- The spec should prohibit including multiple =
instances of the same algorithm identifier w/ the same =
constraints.</FONT>
</P>

<P><FONT SIZE=3D2>- If an ASN.1 version is to be produced, using an =
enveloping signature would make the mapping to CMS easier.</FONT>
</P>

<P><FONT SIZE=3D2>- The assumption in Section 3.2 that one must find an =
old policy in order to determine if an algorithm was valid at a point =
in the past is too complicated.&nbsp; Suitability definitions should =
accumulate in a single policy definition.&nbsp; An enterprise could =
maintain several policies.&nbsp; For example, one complete, one current =
and one past policy could be maintained.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C7E353.272F3FF0--

To: [email-masked], [email-masked]
Subject:  RFC 4998 on Evidence Record Syntax (ERS)
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 17 Aug 2007 16:42:01 -0700 (PDT)
Sender: [email-masked]

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

        RFC 4998

        Title:      Evidence Record Syntax (ERS) 
        Author:     T. Gondrom, R. Brandner,
                    U. Pordesch
        Status:     Standards Track
        Date:       August 2007
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      32
        Characters: 66888
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ltans-ers-15.txt

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

In many scenarios, users must be able prove the existence and
integrity of data, including digitally signed data, in a common and
reproducible way over a long and possibly undetermined period of
time.  This document specifies the syntax and processing of an
Evidence Record, a structure designed to support long-term
non-repudiation of existence of data.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

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

The RFC Editor Team
USC/Information Sciences Institute

...