Re: [Sks-devel] new keyserver online

[C.J. Adams-Collier KF7BMP]

On Sun, 2010-08-22 at 11:04 -0400, Robert J. Hansen wrote:
> On 8/22/2010 10:54 AM, C.J. Adams-Collier KF7BMP wrote:
> > Because none of the information provided indicates in any way that the
> > private key corresponding with the public key provided is under Chris'
> > control. 
>
> If Christoph were himself making assurances about certificates, this
> would be relevant.  As he is not, I don't see how it is.  The assurances
> are made by the individual signers on the certificates he distributes.
> I don't imagine you're going to demand each and every certificate holder
> contact you to verify their private keys -- so why do you expect
> Christoph to do so?  Perhaps there's a good reason for it, but so far
> I'm not seeing it.

As the administrator of the database, I expect Christoph to ensure that the database:

(d) Contains no significant amount of information that is known or likely to be untrue, inaccurate, or not reasonably reliable;

I understand that keyserver administrators cannot do much to this end, since they are not issuing the certs themselves.  However, I do want to make at least rudimentary identity checks with folks who will be trading messages with my servers on a regular basis.

> > (1) The secretary must recognize one or more repositories, after finding
> > that a repository to be recognized:
> > ... (d) Contains no significant amount of information that is known or
> > likely to be untrue, inaccurate, or not reasonably reliable;
>
> I am not a lawyer, obviously.  However, it seems to me that if you
> consider Christoph's private certificate to be a significant amount of
> information, even though it has absolutely no influence on the public
> certificates he distributes, you must also consider the individual
> signatures on those certificates to be significant amounts of
> information, since those do influence the public certificates.
>
> (This doesn't even get into the 45 keys on the keyservers marked as
> "whitehouse.gov", or the ones in the names of various celebrities, and
> so forth.  There is a significant amount of information in the
> certificate pool which is likely to be untrue, inaccurate, or not
> reasonably reliable.)

I see.  Perhaps I need to re-think things in light of this information.

> > All of this is correct.  However, the advice is generally applicable to
> > signing- and trust-related activities.
>
> It is generally applicable within your security model.  I am skeptical
> that your advice is applicable within mine.

Good point.  Maybe I should take Christoph's advice and think a time or two before I post.

signature.asc
Description: This is a digitally signed message part