[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-ltans-dssc-00 comments
Tobias - good response. As it happens, I want to disagree with parts of the post and document why I disagree, so that's inline below... 

Todd
----- Original Message ----- From: "Tobias Gondrom" <tgondrom@xxxxxxxxxxxx> To: "todd glassey" <tglassey@xxxxxxxxxxxxx>; "Thomas Kunz" <thomas.kunz@xxxxxxxxxxxxxxxxx>; "Carl Wallace" <CWallace@xxxxxxxxxxxx> 
Cc: <ietf-ltans@xxxxxxx>
Sent: Thursday, September 06, 2007 9:04 AM
Subject: RE: draft-ietf-ltans-dssc-00 comments


Hi Thomas, Susanne, Todd, Carl and all,

Maybe a few thoughts about the discussed items:

Starting with the simple things:
I agree with Carls assessment that for the verification the critical
information is the policy stating which algorithms had been valid from
date a to date b. Period.
TSG: OK... we need to document whether this is a single system or a distributed one, so POLICY and its Expiry can be managed properly. If its a single system and there is no need to communicate legacy policy status, then that's cool. If its a stand-alone trust model where the document carries everything needed to process it and validate it under the LTANS framework, then its an issue. 

I understand your idea of providing older policies to support the fact
that an archive service did operate correctly, but this is not the main
reason for the policy in the verification process.
TSG: It may not from a technical standpoint be needed at all, but this is about LAW AND THE RULE OF LAW, and the technology MUST (and I do mean "MUST" in caps) meet those needs or its use will be banned... or just ignored meaning that this work is for naught either way unless we are real clear what LTANS use requires and what it provides at the individual document level.
TSG: That said the use model is key to this whole bigger picture. And if the use model template is such that 'any document must be verifable forever with what it carries internally to it from the LTANS framework, then LTANS MUST also carry the legal policy for review as well. Especially in any document's where the original signing policy is changed or expired. This is simple Evidence 101... and while its offensive to many of us as being technologically 'wasted overhead', it satisfies real world law and process models that exist today.
TSG: As to why we need to understand the Law requirements behind long-term document storage is somewhat based in numerous attempts in previous technologoies from this very IETF to force social changes to existing processes by claiming that technology wont support those specific use models.
TSG: In continuing down that rat hole, the argument that we as technologists can change the world by lying to people about 'what is and is not technologically possible' is a black-eye on the Technology Industries since so many know its pure hog-wash and that anything - any process or ceremony in the real world, can be directly reduced to "a dance that is performed between parties across a network" - i.e. some protocol.
TSG: That said LTANS should directly also meet legal framework use models 100% from the gate and not be 'yet another disappointing' IETF effort which intentionally seeks to 'force change' into the World, rather than just implementing the processes as they are committed in the real-world today. 

The main use for the policy is that any verification party can use it
and check an ERS or other signatures whether any of the used algorithms
had been broken before they were renewed. (this is a precise
mathematical test, and does not automatically imply careless handling of
the archive system).
TSG: FWIW - The verifying party would actually be the "relying party" in most instances. As to the precision of the test, I agree its binary but it may not be relevant to that document if I can show that the document was unaltered from the time it was initially stored or 'timestamped'. 

For the verification party only this hard facts count: Has the signature
been renewed in time or not, defined by the current policy.
TSG: Uhhhh - no. In any commercial process which is constrained under a 'standard of care', that standard of care is the test. So the actual breaking of MD5 for instance is irrelevant in the bigger picture of whether my internal-only MD5 hashes are valid or not. The same is true for many other crypto functions. 

(the old policies may indicate a wrong-doing of the archive system or
justify its actions but they must not influence the evaluation of
"valid"/"not-valid".
TSG: In order for that to work, there also needs to be a periodic process which scans all documents indexed in the system to determine whether their signature is still valid and for how long. 

(comment: and if it happens that the policy issuing authority
retrospectively shortens the timespan of an algorithm, this will be for
a reason which should not be ignored.)
TSG: One perhaps like 'that the Underwriter's commercial coverage of that document's content' has expired or has been set aside for some reason? 


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


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

A signature must be valid in the country where it is presented to the
court.
Which includes the renewal done with ERS must be so as well.
TSG: You may want to read Judge Grimm's ruling from Lorraine v Markel then from May 4th 2007... since it directly effects this WG's operations since it now constrains the types of Digital Content the US District Court's can accept as evidence of anything. 

In court the judge will call upon the guidance of the countries security
authority (in case of US this would be NIST) to decide whether
algorithms are secure or have been broken and when.
TSG: Uh no they wont... And this is one of the key things that we choked on. The Court's have already set standards and the Industry has forensic audit models in place as well (as an Auditor I assure you this is auditing commentary is 100% accurate). What the Court's will rule on in Evidentiary hearings is whether the five key tests under the Federal Rules of Evidence were met. The laboratory or National Crypto Authority isnt likely to ever say anything in Court unless they themselves are sued or prosecuted. 


If these authorities
publish this statement in the form of a signed policy, this would be a
clear and reliable statement. (today they publish this in unsigned pdf
and on paper)
TSG: I propose the change of the term 'would' for 'should' since it is the individual judges until national standards are set who make these decisions. 

Dito in other countries.
(obviously as these judgements of algorithms can vary between countries,
an archiving service would have the duty to watch carefully for
algorithm lifetime announcements the local national bodies corresponding
to its stored documents make)
TSG: Where in this requirement documented in any of the LTANS papers to date? 

Best regards, Tobias





-----Original Message-----
From: owner-ietf-ltans@xxxxxxxxxxxx

[mailto:owner-ietf-ltans@xxxxxxxxxxxx]

On Behalf Of todd glassey
Sent: Tuesday, September 04, 2007 5:11 PM
To: Thomas Kunz; Carl Wallace
Cc: ietf-ltans@xxxxxxx
Subject: Re: draft-ietf-ltans-dssc-00 comments


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

The reality of the matter is that a full chain-of-management headers

MUST

be
included with each document showing any changes in the policies or

keys

used
to demonstrate the integrity of the document controlled with LTANS...

More below.

----- Original Message -----
From: "Thomas Kunz" <thomas.kunz@xxxxxxxxxxxxxxxxx>
To: "Carl Wallace" <CWallace@xxxxxxxxxxxx>
Cc: <ietf-ltans@xxxxxxx>
Sent: Monday, September 03, 2007 4:18 PM
Subject: Re: draft-ietf-ltans-dssc-00 comments


> Carl Wallace schrieb:
>> <snip>
>>>> - The assumption in Section 3.2 that one must find an old policy

in

>>>> order to determine if an algorithm was valid at a point in
>>> the past is
>>>> too complicated.  Suitability definitions should accumulate in a
single
>>>> policy definition.  An enterprise could maintain several

policies.

For
>>>> example, one complete, one current and one
>>> past policy could be maintained.
>>> In our notion, the policies are published by specific institutions
(e.g.
>>> annually) and one policy represents the evaluations based on

current

>>> knowledge (e.g. on current findings, RSA with 1024 bit key length
could
>>> be valid until end of 2007, but next year a new policy could be
>>> published which states that RSA 1024 is valid until end of 2008).
>>> To expect, that a policy also contains all past evaluations of an
>>> algorithms could be error-prone.
>>> In our opinion, the question, if the evaluation of an algorithm in

an

>>> old policy is different from that in the current policy is

primarily

>>> important in law cases. And there you cannot trust, that the

current

>>> policy correctly quotes past evaluations, instead you will have to
look
>>> in the old policy.
>>
>> I wasn't suggesting that a policy contain all past evaluations.

I Was - the policy header needs to for legal reasons track the

document

and
its original content/signing as well as any changes made to that

document

allong the way including any instances where policies changed or just
expired. All of these MUST be a part of the Long Term Management
structures
that any and all documents are controlled by or a full chain of

custody

will
not be demonsterable and the outcome of the LTANS system will be

'hear-

say'
based on the Federal Rules of Evidence, the Federal Rules of Civil
Procedure, and a ruling of the District Court of Maryland in the US
Federal
District Courts called Lorraine v Markel from May 4th 2007.

>> I was
>> suggesting that the current policy would contain the current

position

>> with
>> regard to an algorithm's life span, even if the algorithm is no

longer

>> viable, and that's the only thing that matters.  I don't see the

value

in
>> referring to an old policy since the position on an algorithm can
change
>> over time.  Using your example, in my opinion, the only thing that
>> matters
>> to the verifier is what the current position is with regard to an
>> algorithm.
>> The fact that an algorithm's expected life span at the time a

signature

>> was
>> generated was thought to be shorter than it turned out to be isn't
>> important.
> OK, I agree. Since our data structures allow this anyway, we will
> recommend for an easy policy handling that a policy should also

contain

> the evaluations of all algorithms which are no longer valid. But

it's up

> to the publisher to decide to do so.
>
> But never the less, in our opinion there is at least one case for
> consulting old policies:

You mean the period's around "the time when all instances of

old-policy

reliance are flushed out"... i.e. that period of overlap when due to

other

policies, the relying parties do not refresh their operating integrity
entitlement....

I dont think that this is a valid use. Its possible if a number of

other

policies are broken but the LTANS operator must be ready to address

that

certain signatures or policies may become invalid based on their
technologies being cracked at a level which creates a real and

palpable

risk
or they just expire based on their exceeding their timebase lives.

> Assume the current (2007) policy states that RSA 1024 is valid until

end

> of 2008. Because of this policy, an archive service today doesn't

renew

> signatures created with RSA 1024.

Uh - then the Operator has a problem I think and their integrity of
operations model is broken based on the first instance when something

that

they relied on was made retroactively invalid. LTANS must have a
restamping
process built into it to address changes in document policy and access
controls as well as regeneration events around accessing the document

or

demonstrating its integrity.

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


This is a SEVERE problem. NO policy control model should have a hole

this

big in it. There is NO reason to 'after the fact' re-stamp documents

as no

longer being valid after a certain time frame unless there was a
technological hack and there is a very good probability (not just a
possibility) that those documents are either altered or are fakes.

Remeber that these are documents stored for historical purposes and

that

in
the instance of a policy or a key, that the object isnt good anymore

is

irrelevant to whether the key was good when the document was stored,

and

to
whether functionally is capable of being used whether its valid or not
based
on some time-specific expiry.

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

in

> 2007.

Mechanically yes, but in reality no... those signatures are controlled

by

a
number of external and internal processes which (while possible) will

make

it very very unlikely that those signatures were forged.

> Now in 2008 the archive service must attest that he acted correctly

and

> that he fulfilled his duty to take care although he has not timely
renewed
> the RSA 1024 signatures.

The failure of the timely renewall of the RSA 1024 Bit signatures FOR

ANY

REASON invalidates that operator's status as being a competent

operator

one
would think.

> And therefore he needs the old (2007) policy which says that

according

to
> the knowledge at that time, the algorithm was valid and he acted
> correctly. He cannot use the current (2008) policy because this

policy

> states that the algorithm has only been valid until mid 2007.

So this isnt an issue about policy expiry, its a use model issue...

this

is
WHY a formal set of use models MUST be drafted for this type of thing.

It

also might help to have someone with any real-world audit

responsibility

on
this panel because its pretty clear that this is a panel of

technologists

building what they through public argument are negotiating that the
Auditor's need and its yet another instance where the IETF built
technology
for solving a problem it wasnt on-track "as to what the actual problem
is".

See what I mean?

T


>
>
> Regards
> Thomas
>
>
>