UI terminology for calculated validities

William Hay wish at dumain.com
Sat May 3 20:56:55 CEST 2014

Hash: SHA512

On Sat, 3 May 2014 17:28:56 +0100
MFPA <2014-667rhzu3dc-lists-groups at riseup.net> wrote:
> > Letters of
> > introduction are not something one encounters much in
> > the modern world one but tying the process to a
> > physical analogue might make things easier to
> > understand. One could recycle old costume dramas to
> > make tutorials.
> That is an interesting thought. I wonder how what proportion of the
> population would know what it meant, unless it appeared in a book they
> studied at school or a film/TV programme they saw last week.

It's a descriptive term so it shouldn't be all that hard to guess the
meaning. In any case I think people would get it straight away if one
showed them a video clip of someone requesting,receiving and then using
a paper letter of introduction. That would make it easier to explain the
digital equivalent.  Pity D'Artagnan lost his.
> > In normal usage one needs the answer to two questions:
> > Can I send private messages to this person? Did this
> > message/file come from the person in question?
> I would propose a third question: Was the message/file altered in
> transit?

In most cases this would have the opposite answer to the second
question.  It might make things simpler to combine them in practice:

Is this an unaltered message/file from the purported sender?   
> > It gets a bit more complicated when managing/signing
> > keys  but with a GUI one could just present statements
> > about a key for the user to assent (or not to) without
> > any need to classify the statement itself.
> > I (will not say whether|do not know whether|am quite
> > confident that|am very confident that) this key belongs
> > to <userid>.
> Why ask the certification level? What is this information used for?
> Unless it actually has a real use, the user should not be asked to
> spend time considering it, it should not be recorded, and certainly
> should not be published. If somebody thinks they need this, and knows
> why, they should be able to find it in an "expert" mode.
You're right.  If we're not issuing certs/letters of introduction then
there is no need.  If we are then for compatibility with the existing
WoT I don't think we can avoid asking.

> The basic user (and in my opinion, most users) should just have one
> question but need to answer it in respect of each UID, something
> like:-
> "I accept this key for communication with <userid1>. Yes/No"
>                                       aka <userid2>. Yes/No"
>                                       aka <userid3>. Yes/No"

Presumably if implementing with the existing gnupg infrastructure this
would be a non-exportable generic certification? 

> > Issue letter of introduction: Yes/no?
> I think this should also be in an "expert" mode, or at least absent
> from a "basic" mode.

I'd prefer to keep things like trust signatures and granting ultimate
trust a little more fenced off than ordinary keysigning/letters of
introduction so perhaps an intermediate mode.

> And I would prefer something more like "I hereby publicly state that
> this key belongs to <userid>. Yes/No" With a Yes/No selector for each
> of the UIDs on the key.

Once you start doing things publicly one would need to pick a
certification level in order to inter-operate with the existing WoT.
It isn't clear to me that there is a good default.

My original phrasing was intended to fit in with the letter of
introduction metaphor.  While in the long run I may have to kill my
darlings for now I'll stick to trying to make my pet metaphor work. In
that context I think leading off the whole thing with "To whom it may
concern," might work better than a separate public declaration for each

> > Accept introductions made via this key: (No,In concert
> > with X others,Yes).
> Another I think should possibly not be in the "basic" mode. Does an
> absolute beginner really need to be able to nominate trusted
> introducers?

Another one for an intermediate mode I think.


Version: GnuPG v1.4.12 (GNU/Linux)


More information about the Gnupg-users mailing list