Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP

On 16/04/2015 11:31 pm, ianG wrote:
> So, the OpenPGP world has always separated policy from tech.  It has in
> effect kicked policy upstairs to the people.  Hence the key signing
> parties and the discordance between signing meaning "I saw a passport"
> versus "I saw a person".  This we all agreed was the smart thing to do.
>
> However, Jon's revelation of yesterday really changed everything for me
> at least:
>
>
>   > When 2440 started, there was an agreement with the Security
>   > Area that OpenPGP would not be a "PKI" (whatever the heck
>   > that means), because there was already a PKI, namely PKIX.
>
>
> This thread (below) is about PGP as "a PKI" in a world where we are used
> to (up against) "the PKI" or incumbent x.509/CA.  Now that we're
> watching the slow burning sunset of "the PKI," and, now that we're
> looking at a whole new generation of usage for PGP (*), it may become
> more clear that we might have to revisit this.
I think part of the reason this keeps coming back to whether or not
trust definitions, signing policies and security policies keep coming
back is because of the lack of clarity, even amongst geeks.

I agree with the previous stance taken by most; we should not dictate
policy to end users, they're the ones in the best position to
determine how they use whichever implementation of the protocol
they'll use.  We should stick to specifying the tech involved.

The problem, however, is that current key management functions don't
really seem to address all the relevant components of different policy
types.  For example, I can sign a key locally, normally at certain
levels or assign a trust signature to indicate I trust the owner so
much they can make trust metric decisions for me (kind of).  Okay, but
why can't I include a specific notation value with my signature to tie
back to a published key policy on my site.  Then people could see
there's a signature and check a reference which indicates something
like "I met this guy, seemed honest, saw a license, but they can be
forged in this country, I'd readily encrypt to him, I'm pretty sure
he's legit, but I wouldn't bet my childrens' lives on that."

The real world is more complicated than the few options presently
available and if utilisation of trust metrics and relevant security
policies are to be effectively maintained then the end users need the
tools to put the scenarios they encounter into effect.  Some
additional functionality in that respect now would be good.  The same
goes for the totally arbitrary trust settings.  Presently I disable
the thing entirely because I have too many keys to locally sign
everyone I might encrypt to (everyone if I had my way).  Why can't I
say, "always trust when encrypting, but use the trustdb in relation to
signatures and determining authenticity of signed data."

There's also a lack of any way to indicate trust in the consistency of
a perceived entity being the same person, even without having
identities confirmed.  This could be useful for those establishing a
long term, consistent pseudonymous identity for whatever reason.

These are all functional, practical aspects of a trust system which
the specification should consider as a technical response to a lack in
the current standard.  Deciding on key usage policies would still be
entirely in the hands of end users as, indeed, it should be.  But
those users should have the resources to be more specific about how
their policies affect the usage of every component and application of
their keys within the context of their communications.

I am, of course, also aware that there is very often a fundamental
lack of understanding on where the lines are on things like that out
there, but as with cryptography itself, that is simply a matter of
education and familiarity.  There is, I will admit, a significant lack
of documentation in how to formulate a security or signing policy in
relation to OpenPGP, at least by comparison to sites with guides to
making keys and checking email.  That's another little beast entirely
and probably well beyond the scope of this WG.

It shouldn't be lost on anyone here, though, that the only crypto
users with specific key policies are those with a professional
requirement to do so or are interested in those aspects of information
security which make it relevant to them.  Everyone else coming to the
party tends toplay it by ear or ignore the entire thing.  This sort of
thing, however, deals with a great many things which go far beyond
just OpenPGP and it's definitely not something for the WG to handle.
Presumably someone will write something to help everyone else along
with it eventually ... by which I mean, once I've finished the outline
I've got in another buffer, I'll actually have to flesh it out.  ;)


Regards,
Ben

signature.asc
Description: OpenPGP digital signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp