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
This is the main goal. A policy and the information that are to be provided by an implementation follow oneAnother advantage of this approach would be that we will have only one XML schema, which doesn't need to be extended for future algorithms.
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>
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.The "name" attribute is optional and only for better readability and understandability of the policy. It should not be processed by a verifying entity.
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.
I think a contaraint language that can define value subsets is necssary and notThe "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.
very difficult.
Regards, Thomas Peter Sylvester schrieb:Not in the policy but in the information about what is actually implemented byI'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?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 displaytextuals 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 thanconstraints of a few values.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 partsin a policy one would only specify value constraints parameters for an actual algorithms,a kind of pattern which can always be checked, examplefirst 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).of the algorithm implementation to give 'its parameter 1 and 2'?Thomas
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature