[Opendnssec-develop] kasp draft

[Matthijs Mekking]

On 07/15/2014 10:52 AM, Siôn Lloyd wrote:
> 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?

Similar. Yuri's point is if everything in a container is optional. I
think a KASP should always describe how to do a key rollover by the way.


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

I think we do want to define the algorithm: So that if the policy is
used in a different implementation, you can expect the same behavior.


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

Do not resalt.


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

Good point. Have to check. Added an issue for that:

    https://github.com/matje/dnsop-kasp/issues/7


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

If Repository can be anything else than a HSM, like Jerry said, then
this may affect the policy model. Thinking twice: probably not, because
in KASP we reference to a Repository identifier string.

Thanks for the comments!

Best regards,
  Matthijs


> 
> 
> 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
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
>