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 inthe past istoo complicated. Suitability definitions should accumulate in a single policy definition. An enterprise could maintain several policies. For example, one complete, one current and onepast 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.
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.I wassuggesting that the current policy would contain the current position withregard 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 changeover 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 wasgenerated was thought to be shorter than it turned out to be isn't important.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