Re: From whence we came...

["James Seng/Personal" <jseng@pobox.org.sg>]

>   * Historically, Verisign has faced greater scrutiny and been forced
to
> make more compromises in the DNS area than in the PKI area.

Historically, Verisign (or Network Solution) have been fairly successful
to fences off any such attempt. There might be some small-step victory
but the winners always get the last laugh. (Anyone remember the 1999
ICANN-NSI agreement?)

There is nothing that can stand between a determined well-funded large
corporation and a big pot of gold on the other side.

>   * Technically, Verisign can't issue you a KEY record and make you
not
> sign sub-keys (or fingerprints of sub-keys, as in the NAPTR idea I've
> been advocating) with it, as they can (in practice) with certificates.
> So, once I do get a KEY record from Verisign, I don't have to transact
> with them again for each ssh key or each user.

Yes. But it is fairly easy to justify say a jump from $6/domain to
$600/signed-domain based on the operational cost to resign their zone.
(Hmm, 600 may not cover their lost in revenue..perhaps
6000/signed-domain and it comes with a fully functional sub-CA
practices, secure offline signing etc).

Coming back to cert or keys, after sleeping on it on keys or cert, here
are some thoughts.

My first thought is to have a flag in the KEY to specify whether the KEY
is a raw-key or a cert. But it seem pretty redundant since the cert may
contain the key. It is possible for the apps to extract the key from the
cert and ignore that the cert is self-signed. It is entirely up to the
apps (IPsec, SSH etc) to trust DNSSEC answer or choose to have
additional verification.

To move back to the topic of requirements, the list say keydist so I
presume one of our requirements is a secure method for keys/cert
distribution.

Whether the requirements include the trust model of these cert/keys is
one we can debate.

-James Seng