Re: dnssec: resolver - application communication

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Derek" == Derek Atkins <warlord@MIT.EDU> writes:
    Derek> Let me give an example.  Assume SSH starts deploying server
    Derek> keys in DNS to help solve the "first contact" problem.  The
    Derek> application could decide to provide different messages to the
    Derek> user based on whether the answer is secured.  An unsecured
    Derek> SSHKey record would have little additional trust than the
    Derek> first-contact assertion.  Whereas a signed record could be
    Derek> more trusted.  The App should be allowed to make the
    Derek> distinction. 

  Note, this means that the application *STILL* gets a result even if
signature(s) FAIL. Even if the ROOT DNS key fails.


for record in NS DS 
do
  for delegation in delegate-hierarchy
  do
    Derek> I also think the app should know the difference between:

    Derek> - signed, signature is good.
    Derek> - signed, but the signature expired.
    Derek> - signed, but the signature did not validate.
    Derek> - unsigned
    Derek> - unsigned, but should be signed
  done
done

    Derek> Am I missing cases here?

All of the above may occur for NS and DS above.

- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQJ/V0oqHRg3pndX9AQGwrgP/Zc/9EQVsCh5Fo5+E+DJZsUuZTcvJKsv3
64mpzL1RckdMN3ew2ApHn/O7qPp7pLIZVoXxDzB9qAA5T+2EIjdD1lxcMaBx8FCn
RRF39a4YSxZb6RutKxwEsqHrD8vcBzAHm0VlLPqIbIIEJmQgYz9usxQ1fLAzcxMe
WbpFr2r2/Nc=
=QfGk
-----END PGP SIGNATURE-----