RE: draft-ietf-ltans-dssc-00 comments

["Tobias Gondrom" <tgondrom@xxxxxxxxxxxx>]

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. 
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. 
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). 
For the verification party only this hard facts count: Has the signature
been renewed in time or not, defined by the current policy. 
(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". 

(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.)


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. 
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. 
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. 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)

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)

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