incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: key signing
Date Wed, 10 Oct 2012 09:47:22 GMT
Can you clarify? I understand that being able to speak to someone face to
face, and seeing their mannerisms and expressions, allows you to understand
them better. Some deep rooted human thing. But how does this impact
security or trust, in the context of key signing?

On Wed, Oct 10, 2012 at 4:00 AM, Ted Dunning <ted.dunning@gmail.com> wrote:

> If you know the person, it adds something that you don't get.
>
> On Tue, Oct 9, 2012 at 3:40 PM, Noah Slater <nslater@tumbolia.org> wrote:
>
> > What, precisely, does a video call actually provide?
> >
> > The point of meeting in person is to verify photo IDs. Just talking to
> > somebody with a face doesn't prove anybody. I am fairly certain that YOU
> > have a face, and I have never even seen it. If all you're doing is
> having a
> > chit chat and swapping key IDs, you may as well do that via IRC or email.
> > Doing it with a video adds nothing, as far as I can see. It certainly
> does
> > not establish identity. Beyond "a person who says their name is Bob has a
> > face which looks like [this]." Is that useful? I don't think so.
> >
> > On Tue, Oct 9, 2012 at 11:01 PM, Marvin Humphrey <marvin@rectangular.com
> > >wrote:
> >
> > > On Mon, Oct 8, 2012 at 2:24 PM, Noah Slater <nslater@tumbolia.org>
> > wrote:
> > > >> 1. The key owner convinces the signer that the identity in the UID
> is
> > > >> indeed their own identity by whatever evidence the signer is willing
> > to
> > > >> accept as convincing. Usually this means the key owner must present
> a
> > > >> government issued ID with a picture and information that match up
> with
> > > the
> > > >> key owner. (Some signers know that government issued ID's are easily
> > > forged
> > > >> and that the trustability of the issuing authorities is often
> suspect
> > > and
> > > >> so they may require additional and/or alternative evidence of
> > identity).
> > > >
> > > >> 2. The key owner verifies that the fingerprint and the length of the
> > key
> > > >> about to be signed is indeed their own.
> > > >
> > > > How would you do this via Skype?
> > >
> > > Here's a rough draft for a protocol:
> > >
> > > Several podling committers convene in a Google Plus Hangout with
> > "Hangouts
> > > On
> > > Air" enabled (so that the video gets archived to YouTube).
> > >
> > > Everyone states their name and what they had for lunch, then reads
> their
> > > public key fingerprint aloud.  The lunch items are combined into a key
> > > phrase.
> > > Participants then commit to a text file under ASF version control,
> > > contributing a few lines containing their name, their public key
> > > fingerprint
> > > and the key phrase -- linking together face and voice, public key
> > > fingerprint,
> > > ASF credentials and by extension, an iCLA.
> > >
> > > Optionally, the project is then discussed by the participants for some
> > > arbitrary length of time; the discussion of shared experience adds
> > another
> > > layer of confidence that participants are who they say they are.
> > >
> > > Physical IDs are *not* shown during this session because the video is
> to
> > be
> > > archived in a public location, but participants are encouraged to
> request
> > > such
> > > ids via private channels later.
> > >
> > > After the session ends, the archival video link is submitted to the
> > > podling's
> > > dev list, giving people the opportunity to initiate contact via email,
> > > phone
> > > or other channels with the committers in question -- or better yet
> their
> > > associates and colleagues, pointing to the video link and requesting
> > > confirmation of identity.
> > >
> > > Once a potential key-signer believes that a high degree of certainty
> has
> > > been
> > > established for a given candidate (it may make sense to codify some
> "best
> > > practice" guidelines), they sign the key and report to the dev list,
> > > documenting both what key was signed and what criteria they used when
> > > deciding
> > > to sign.
> > >
> > > ...
> > >
> > > While this protocol does not rely heavily on validating
> government-issued
> > > IDs,
> > > the Debian guidelines quoted above point out that some people object to
> > > giving
> > > such IDs too much creedence:
> > >
> > >     (Some signers know that government issued ID's are easily forged
> and
> > > that
> > >     the trustability of the issuing authorities is often suspect and so
> > > they
> > >     may require additional and/or alternative evidence of identity).
> > >
> > > Instead, it relies on a layered approach a la multi-factor
> > authentication.
> > >
> > > > If we don't take this seriously, how can we expect other people to
> take
> > > our
> > > > keys seriously?
> > >
> > > Since the Incubator PMC consistently approves releases signed by keys
> > which
> > > are not connected to the web of trust, apparently we don't take the web
> > of
> > > trust very "seriously" right now.  ;)
> > >
> > > But "seriously"...
> > >
> > > I interpret "take this seriously" to mean that before signing the key,
> it
> > > is
> > > important to...
> > >
> > > 1.  Establish the identity of the key owner to a high degree of
> > certainty.
> > > 2.  Establish the link between the key and the key owner to a high
> degree
> > > of
> > >     certainty.
> > >
> > > The point is that the degree of certainty is independent of the means
> > used
> > > to
> > > obtain that certainty -- and the GnuPG docs say as much.  Face-to-face
> > > interaction is one good technique, but in my opiniion, the categorical
> > > dismissal of all other techniques hinders participation in the web of
> > > trust,
> > > thereby thinning our defense in depth against credential spoofing.
> > >
> > > Marvin Humphrey
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > NS
> >
>



-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message