Subject: RE: draft-ietf-ltans-dssc-00 comments
From: "Tobias Gondrom" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, "Thomas Kunz" <[email-masked]>
Cc: <[email-masked]>, "Susanne Okunick" <[email-masked]>
Date: Thu, 13 Sep 2007 14:58:12 +0200
List-Id: <ietf-ltans.imc.org>

Hello Peter and Thomas,

just a comment: I like the constraint mechanisms you propose and would like
to see them in the draft, but I do not think they are mandatory. So if this
is possible, please go ahead. If not, I believe a list of algorithms with
their parameters will do the job as well. Remember the parameters are
usually not continuously distributed values n of N, but usually use only a
certain limited sub-set of discrete values element of N. (e.g. discrete
values: 256, 512, 1024, 1280, 1536, 2048, 4096, ...) 

So we will be able to define lifetimes for all used key lengths for a
specific algorithm and not absolutely require the constraint rule. 

But as I said, if you find a solution with the constraints I'll be very
happy, just wanted to let you know I believe you also have other options
which would work as well. 

Just my 5cents, 

Tobias

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Peter Sylvester
> Sent: Thursday, September 13, 2007 1:54 PM
> To: Thomas Kunz
> Cc: [email-masked]; Susanne Okunick
> Subject: Re: draft-ietf-ltans-dssc-00 comments
> 
> Thomas Kunz wrote:
> > Hello Peter,
> >
> > yes, your proposal sounds quite good. In the next version of our
> > draft, we will propose a new XML structure for parameter constraints:
> >
> > <Parameter name="modulus">
> >    <Value>1024</Value>
> >    <Constraint>minimum value</Constraint>
> > </Parameter>
> >
> > I think, that's just about what you mean.
> Not exactly. See below
> >
> > Another advantage of this approach would be that we will have only one
> > XML schema, which doesn't need to be extended for future algorithms.
> This is the main goal. A policy and the information that are to be
> provided by an implementation follow one
> schema that does not need to be extended for any new algorithm.
> 
> IMO there are two things to cover:
> 
> 
> 1 - Information from an implementation that contains actual implemented
> values.
> 2 - a policy that contains constraints
> 
> A verifier tests whether the actual values match the constraints.
> 
> I am not whether there is a need to type the parameter, i.e. can
> we assume that all parameters can be represented always as integers
> in a convenient way, i.e. in a such a way that a constraint can be
> formulated nicely.
> 
> To take the example above:
> 
> For the information 1
> 
> <Parameter name="modulus" value="1024 "/>
> 
> and  for 2
> 
> <Parameter name="modulus">
> <Constraint notAfter=.. notbefore=... >
> <greater>1024</greater>
> <and>
> <smaller>4096</smaller>
> <Constraint>
> 
> 
> >
> > The "name" attribute is optional and only for better readability and
> > understandability of the policy. It should not be processed by a
> > verifying entity.
> It can be used in error message: "Parameter 'modulus' of algo  xxx'
> doesn't meet the
> its constraint. You have a similar thing in SNMP, a user friendly name
> of a parameter.
> 
> But you also need  this in oder to identify correspondance of 1 and 2. I
> wouldn't
> rely on the order, or  in other words, it may be that some parameter has
> no
> constraints but is part of the algorithm characteristics.
> >
> > The "Constraint" element defines how the parameter has to be processed
> > and evaluated. In the example above, "minimum value" would mean, that
> > all keys with a modulus greater then 1024 are also valid at least as
> > long as the 1024 modulus.
> > At this point, I'm not sure, if it's sufficient to give only a textual
> > value like "minimum value" or if it would be better to define
> > URIs/OIDs to express such processing constraints.
> I think a contaraint language that can define value subsets is necssary
> and not
> very difficult.
> >
> > Regards,
> > Thomas
> >
> >
> > Peter Sylvester schrieb:
> >>
> >>>>
> >>> I'm not sure whether I understand your suggestion.
> >>>
> >>> In your example above, you suggest to have simply a list of all
> >>> currently valid key lengths?
> >> Not in the policy but in the information about what is actually
> >> implemented by
> >> an algorithm. I was not quite clear here.
> >>
> >>> But where do you have the validity periods of the particular values
> >>> (key  lengths)?
> >> As part of the policy, you make constraints about values, e.g.
> >> parameter 1 may only have this
> >> or that etc. You can CHECK such statements without knowing the actual
> >> semantics.
> >>
> >>> A second problem I see is, that some algorithms are defined by more
> >>> than one parameter (e.g. DSA: 'p' and 'q'). So in the XML encoding,
> >>> you have to distinguish the different parameters (e.g. via its name).
> >> There is the point. You do not have to distinguish any semantics of
> >> what p q, or keys or else would mean.
> >> I think a verifying entity can be made of two compoents: A very
> >> generic one, which verifies the
> >> conformity of ALL alogorithms and, for each algorithm implementation,
> >> a specific module which,
> >> depending on the algorithm implementation can indicate how some
> >> values are filled. The verification
> >> module does not need to know anything about the actual semantics of a
> >> particular parameter.
> >>
> >> Compare this with SNMP: If you have some "box" with a mib, onlmy the
> >> box knows the semantics
> >> of the values, not the SNMP client and network supervision tools.
> >> They just can set value and display
> >> textuals labels defined by a mib.
> >>
> >> If one wants to define policies about certain values, then the
> >> network tool need to know the specific
> >> mibs, there is no way to make a generic policy for each kind of mib.
> >> But in our case, the potential
> >> number of algorithms is not extremely high, and in any way, the
> >> policy will say not say more than
> >> constraints of a few values.
> >>>
> >>>
> >>>> in a policy one would only specify value constraints parameters for
> >>>> an actual algorithms,
> >>>> a kind of pattern which can always be checked, example
> >>>>   first parameter must be greater than  1023, second less than 8192
> >>>> or whatever.
> >>> >
> >>> Do you mean to encode this pattern in XML? And for example such a
> >>> pattern would say: 'If a value of 1024 is valid, every value greater
> >>> than 1024 is also valid'?
> >>>
> >>> In principle I agree with you. We are also discussing the problem
> >>> which arises if new algorithms are added (see Susanne's mail which
> >>> also addresses this topic).
> >> Yes, the proble is how one assumes that an implementation would work.
> >> Who will check the policy?
> >> Is it part of the algorithm implementation, or part of a generic
> >> module that asks some parts
> >> of the algorithm implementation to give 'its parameter 1 and 2'?
> >>>
> >>> Thomas
> >>>
> >>