[Opendnssec-develop] kasp draft

Siôn Lloyd sion at nominet.org.uk
Tue Jul 15 08:52:22 UTC 2014


2.1.1.
"a policy MUST have the containers Signatures, Denial, Keys, Zone and
Parent."

This is only true for a policy that can control a key rollover; If all I
want is to describe the signing part then "Parent" becomes optional. I
guess this is the same as Yuri's comment?

2.1.1.1
Jitter - I'm not sure that there is a need to define the jitter
algorithm... I can have jitter that only increases signature lifetimes
(i.e. r * j) and it is still just as valid. The algorithm could be given
as an example.

2.1.1.2
Can Resalt be PT0S? If so what does this mean?
Can SaltLength be 0?

(In general by integer you mean positive integer; possibly including
zero? This is all explicit in the current kasp.rnc)

2.1.1.3
Does Repository need to be mandatory? Is this only the case if the
signer uses PKCS11 (I'm not sure of the answer to this; but e.g. "keys
on disc" would need a path instead).


Sion


On 04/07/14 14:23, Matthijs Mekking wrote:
> On 07/04/2014 03:15 PM, Yuri Schaeffer wrote:
>>> We would like to hear your opinions about this and get your
>>> feedback.
>> 1) 2.1.1.2
>> 	(...)
>>    The choice and case modeling types are not included in the actual
>>    data tree.  In the case that NSEC is used, the XML example would be:
>>
>>    <Denial>
>>        <NSEC/>
>>    </Denial>
>>
>> I don't understand what 'choice and case modeling types' are.
> Its YANG language (RFC 6020). Basically you specify in your model that
> you have a choice: Either the schema contains <this> or the schema
> contains <that>. You cannot have both <this> and <that> at the same
> time. A case modeling type is a choice option so to say.
>
>
>> 2) 2.1.1.4.  Zone
>>
>>    3.  Serial - The format of the serial number in the signed zone.
>>        This is one of: "counter", datecounter, unixtime, keep.
>>
>> Perhaps Serial should not be defined as a string but rather a type
>> that has one of the above values.
> I was thinking of that too. I'll add that as an issue to be resolved.
>
>
>> 3) 2.1.1.4
>> It is unclear which values in the Zone>SOA container are optional.
> Ok, I'll take a look.
>
>
>> 4) If everything in the parent container is optional, why MUST we have
>> a parent container?
> This can probably be a MAY. We started with kasp.rnc with this document
> and then relaxed some rules.
>
>
> I created issues for these in github:
> https://github.com/matje/dnsop-kasp/issues.
>
> Thanks Yuri!
>
> Best regards,
>   Matthijs
>
>> _______________________________________________
>> Opendnssec-develop mailing list
>> Opendnssec-develop at lists.opendnssec.org
>> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
>>
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop




More information about the Opendnssec-develop mailing list