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: owner-ietf-ltans@xxxxxxxxxxxx [mailto:owner-ietf-ltans@xxxxxxxxxxxx] > On Behalf Of Peter Sylvester > Sent: Thursday, September 13, 2007 1:54 PM > To: Thomas Kunz > Cc: ietf-ltans@xxxxxxx; 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 > >>> > >>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature