[Opendnssec-develop] OpenDNSSEC Requirements Updated

[Stephen.Morris at nominet.org.uk]

Jelte Jansen <jelte at NLnetLabs.nl> wrote on 05/05/2009 17:10:34:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen.Morris at nominet.org.uk wrote:
> > As a prelude for writing the test plan, I have updated the 
requirements 
> > for OpenDNSSEC - see 
> > http://www.opendnssec.se/wiki/ProjectPlan/Requirements
> > 
> > I have incorporated the original requirements, as well as requirements 

> > from Nominet and .SE.
> > 
> > Comments?
> > 
> 
> just a few at a quick glance;

> I'm seeing a few things that it currently does not do (signatures on 
first
> input, but i think i can add that without much trouble), or probably 
can't
> handle in any decent timerange (sorting might take a while for 
> millions of records)

This is a first draft of the formal requirements, so there might be things 
that are impractical or not needed, in which case they should be removed.



> RSA support is mentioned, but not RSAwithSHA1 and/or RSAwithMD5 (not
> that I know
> of anyone actually using that, but it might be good to at least make the
> distinction, and we will know where to put SHA2 if that draft ever 
reaches
> publication)

I'm replying to this email a bit late (sorry!), so I'm not certain what 
version you refer to.  However, the current version does state (2.3.1.3.d) 
that RSA/SHA-1 MUST be supported and that RSA/SHA-256 SHOULD be supported 
if introduced as an RFC.  Do we need to bother with RSA/MD5?



> I don't know in which category it would fall, but the SOA SERIAL that is 
used
> could be very important for some people, I've heard of at least one 
instance
> where they have the requirement that it is not changed by the 
> signer. This will
> have very serious consequences on when and how to do resigning 
operations (one
> would have to 'sneak' them into normal updates, which of course haveto 
happen
> regularly then, but i guess this is more appropriate for the second 
> version; so
> it could actually be an explicit non-requirement.

We could add a requirement to "2.3.2 Signing Process" stating that the 
user should have the choice of leaving the SOA serial number unchanged, or 
having the system set it to Unix time format (number of seconds since 
1-Jan-1970).  But:

a) are there any other serial number formats that should be considered?
b) is it worth worrying about leap-seconds (where, theoretically, the time 
could go back by a second)?
c) is the year 2038 problem too far away to worry about now? (Remember 
what they said about the Y2K problem back in the 1960s.)

Stephen