Subject: [openpgp] New encryption formats for messaging

From: David Leon Gil <[email-masked]>
Date: Fri, 13 Mar 2015 17:41:18 -0700

Some desiderata, generally:

A0. Be as secure as possible by default. Do not offer options to
fallback to doing unsafe things. "Experienced" users often think they
want them; there are usually better solutions for their use-cases.

A1. Only specify a single asymmetric encryption scheme and a single
asymmetric signature scheme. This is critical: This is the second most
dangerous and buggy code in any crypto scheme.

A2. Clearly separate handling of various message and key metadata from
the underlying encryption scheme. This is critical: Parsing code is
the most dangerous and buggy code in any crypto scheme.

A3. Do not specify things which are infeasible to thoroughly test.
This implies avoiding combinatorial complexity, which the OpenPGPv4
spec doesn't.

A4. All messages, including signed but unencrypted messages, should be
indistinguishable from random to an adversary who does not know the
public key of the signer. (This is, essentially, a Tor-style security
requirement.)

Some desiderata for symmetric primitive choices:

B1. Only modern hash functions that provide a significant security
margin against cryptanalysis. Let's not repeat the MD-5/SHA-1
disaster. (We only need two hash functions at most.)

B2. Only block and stream ciphers that offer a significant margin of
safety against cryptanalysis. (Or that, when composed, offer a
significant margin of safety against cryptanalysis.)

B3.. A single AEAD mode that is maximally misuse-resistant, in the
sense of https://eprint.iacr.org/2014/793. (But probably not AEZ, or
any other CAESAR competitor for that matter. I would prefer a scheme
that uses generic composition of well-studied primitives.)

Thus, what any proposal should specify, at the crypto level:

C1. A single curve providing security above the 192-bit-equivalent
level. (This is because the *tightest* security reductions for any
concrete instantiation of EC primitives result in a security level of
~ 120-bits for a 384-bit curve.)

C2. A single message format intended for use with signed and encrypted
messages of length >> 128 bytes and << 2^24 bytes. (That is, something
appropriate for email. I would consider encryption of large files and
very short messages out of scope at this time.) I am agnostic as to
whether encrypted-then-signed or signed-then-encrypted is preferable.
I am curious if anyone else has strong views on this?

C3. A single message format intended for detached signatures. This
should target, specifically, the common use-case of OpenPGP signatures
for code-signing.

C4. Specify a mechanism for encapsulating a signature over the body of
an HTML email in a way that is compatible with HTML email as commonly
used. This signature should be indifferentiable from random for anyone
who does not know the public key of the sender.

(This last should be easy. A concrete proposal: If a
"data-openpgp-sig" attribute is present on a tag, it contains a
base64urlsafe-encoded signature over the contents of that tag, with no
special normalization rules applied. This can be made more precise by
reference to the HTML5 spec.)

And what a proposal should specify, for various key and message metadata:

D1. A standard format for encapsulating arbitrary key and message metadata.

D2. Mappings from OpenPGPv3 metadata to that format, as appropriate.

--

Final comment:

I am, quite frankly, agnostic as to whether an IETF WG or another
forum is the most appropriate place to specify something.

The IETF lately has not seemed to be so much about canonizing "de
facto" standards (which it was good at) as design-by-committee (which
it isn't). And recent revelations have shown that design-by-committee
is -- besides being irritating for implementors -- a boon to
intelligence agencies.

So: I would encourage anyone interested in seeing something
standardized to make a complete proposal a la Hugo Krawycz's OP-TLS
proposal for TLS1.3. But implement the proposal first. Working code
&c.

Taking a scattershot approach will lead to a shoddy, messy, unsafe
result. Yahoo will not support a specification that, by sloppiness or
untestability, makes our users unsafe.

David Leon Gil
Senior Paranoid
Yahoo!

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 19 Mar 2015 00:38:02 +0100

> want them; there are usually better solutions for their use-cases.
Yes and no.

Looking at the context you come from (Yahoo) I must note, that the big
players seem to have discovered security recently ... o.O
And part of their marketing strategy seems to be "security must be
easy" (i.e. a totally unaware person should be able to be "secure").
This is basically the same what some people around the heise Verlag seem
to campaign for recently.

While this sounds like a great goal it's completely unrealistic.
Someone who doesn't at least know some basic concepts will never be
secure, because he'll believe any social engineering and the first mail
telling him to just fetch the "unknown key from website X or keyserver
Y" will be followed.
Many of my less crypto-aware friends use nowadays things like
TextSecure/etc. on their mobiles, believing they're secure.
Well first it's Android (so failed) and second, none of them knows about
the basic principle that one *is not* secure if not some form of mutual
authentication hasn't taken place via some secure path (i.e. not
first-come-is-trusted like key pinning).

To be honest, Yahoo, doesn't have the best security record, and in
general I wouldn't trust any web-based crypto app regardless of who it
wrote.

That being said, I agree that it shouldn't be easy to make a well
designed crypto system insecure by settings - but not if this means that
one takes away valid functionality from the more experienced users.
And definitely not for marketing reasons.

> dangerous and buggy code in any crypto scheme.
Why?

a) What's the problem a with symmetric scheme as we have it now?

b) Why should there be only one?
I think its a wrong assumption that code will become more secure by
supporting less algos/systems.
If a project cannot develop/maintain more of them securely it's rather a
sign for lack of funding/manpower.

The past has shown that sooner or later every algorithm (except for OTP
of course ;) ) has its flaws and is needed to be replaced.
Quite often recently, people waited far too long till that replacement
started (just look at the issues in SSL/TLS).
Since the experience has shown that standardisation of something new
takes quite a while (see the discussions about Curve25519 at the CFRG) I
would feel much better if a cryptosystem has several algorithms
(ciphers, signature schemes, hash algos, etc.) ready in place.
Implementations can still strongly suggest only a small subset to be
actually used - but *if* some problem is found in these, it wouldn't
take ages to get rid of them (like RC4, basically all the old CBC and
non-EtM algos in SSH, TLS,... hell we still have systems in the wild
which use MD5 for security purposes)

> the most dangerous and buggy code in any crypto scheme.
It's a bit unclear to me, what exactly you mean here.

> This implies avoiding combinatorial complexity, which the OpenPGPv4
As above, I doubt you can really check every combination, and I wouldn't
want to sacrifice too much, just for being able to do so - especially
not diversity of algorithms.

> public key of the signer. (This is, essentially, a Tor-style security
By "messages" you mean "OpenPGP Messages" i.e. also they keys?

> disaster. (We only need two hash functions at most.)
Disagreeing with the "We only need two hash functions at most.".

Diversity is good (of course we should only include secure algos),
especially when one expects that each algo sooner or later sees
weaknesses.

> ~ 120-bits for a 384-bit curve.)
Same as above for all the "single foo" demands. 

> I am curious if anyone else has strong views on this?
You're aware that OpenPGP isn't just for mail respectively what Yahoo
want's to do with it?

> should target, specifically, the common use-case of OpenPGP signatures
No strong opinions here.
The only thing important is that we warn implementors about the typical
issues (see the InRelease hacks within Debian, or the problems with the
--verify option in GnuPG with detached sigs but only one argument)

> who does not know the public key of the sender.
Not the task of OpenPGP - we're not a mail standard only.

> reference to the HTML5 spec.)
Isn't that also out of the scope of an OpenPGP standard?

> is -- besides being irritating for implementors -- a boon to
Well it doesn't seem to me as if IETF would make bad work here and I'd
see no reason to pull the standardisation to some other body.

And "not helping the NSA comments" from a US company?! ;-)

> proposal for TLS1.3. But implement the proposal first. Working code
off topic: That approach is IMHO much more problematic with respect to
potentially evil orgsanisations/people, since those who do the code,
spread it in the wild before it was discussed by experts make quite some
pressure to have their ideas being used (see e.g. SPDY).

> Yahoo will not support a specification that, by sloppiness or
Apart from the fact that this sentence makes me smile (just searching
through the heise archive for security issues at Yahoo ^^):

I guess someone else has already mentioned that it's really not
appropriate that someone of the "big players" (even though I wouldn't
call any of Google/Yahoo/MS big players for people who want *real*
security ;) ) try to make any kinds of pressure here.

Cheers,
Chris.

---

From: ianG <[email-masked]>
Date: Mon, 23 Mar 2015 18:12:26 +0000

> players seem to have discovered security recently ... o.O

Hmmm... so our technique is to punish people for wanting to improve. 
Grand...

> to campaign for recently.

New to some, but it has a long history:  Kerckhoffs' 6th principle:

"6. Finally, it is necessary, given the circumstances that command its 
application, that the system be easy to use, requiring neither mental 
strain nor the knowledge of a long series of rules to observe."

Writing about cryptography communications systems in 1883.

http://www.financialcryptography.com/mt/archives/000195.html

> first-come-is-trusted like key pinning).

I think this is simply wrong.  This is no principle.  TOFU has proved 
itself.  If you don't want to use it, that's fine, but the notion that 
it's "not secure" is simply rubbish because security is a relative risks 
thing, not an absolute thing, and it is extremely unlikely in almost all 
cases that anyone's going to watch and dive like that.  Security is 
statistical, it is risk.

Empirically, I just today got my first 419 hit on Skype, which was set 
up to let others see my name - their mistake on default install.  After 
about a decade of usage?

Even including the notion that Microsoft now copies it all to the NSA, 
that's still only 4 parties with capability to connect to me:  Me, my 
friends, Microsoft and NSA.

> one takes away valid functionality from the more experienced users.

Why do you prioritise "experienced users" above the lesser experienced? 
  Do they pay more money?  Is this the Church Of BOFHs?  Do they pay 
their dues by helping others?  From your writings it seems unlikely...

> And definitely not for marketing reasons.

No such group exists in most places.  In SSL there is a myth that 
sysadms can understand how to configure the apache config files, so 
consequently choice is good.  None do, to a very high statistical 
confidence - most copy files back and forth, and a few read guides like 
bettercrypto.org.  And I can tell you that the BetterCrypto guys are 
always having arguments about what is right, best, etc.  If the <1% 
can't agree the 99% is screwed.

> a) What's the problem a with symmetric scheme as we have it now?

It's all old stuff.  We've moved on.

> sign for lack of funding/manpower.

Ah.  So you see that handling more algorithms is a cost for big 
companies to meet and therefore a barrier to entry which makes for less 
choice and eventual balkanisation.  What about opportunity cost - time 
spent managing and debugging algorithms that are rarely if ever used - 
could be better spent on getting more usability?

> started (just look at the issues in SSL/TLS).

Fully agreed.  Now, here?

> which use MD5 for security purposes)

That argument didn't work.  Basically when ever a problem was found, it 
couldn't be solved by an algorithm switch, 9 times out of 10.  The one 
time that a problem was found, it was solved by ... a switch *backwards* 
to RC4.  Not exactly a happy result.

Secondly, *there is no plan to switch*.  There is a switch, but no plan, 
no methodology nor siren nor alert.

Algorithm agility is all standards body sophistry, not real life.  It's 
another paper invention thrown over the wall, and when it's actually 
needed, it doesn't deliver.

> It's a bit unclear to me, what exactly you mean here.

layering.

> not diversity of algorithms.

When has diversity of algorithms ever bought user advantage?

I can think of (been told) one case:  the "Russians GOST" requirements. 
  Frankly, I'm not that keen to let them do that.  If *every* government 
did it, then we'd be in a pickle, and we'd not be talking to any of them 
at all.  So why do we care about the Russians?

Why are we actually preparing a perfect argument for USA Congress to 
turn around and mandate a USA weak key suite?

> especially when one expects that each algo sooner or later sees

Well, sure, on paper.  But if you had a process to switch then you could 
also ... use that process to switch!  Why not just roll out v+1 ?

>> that uses generic composition of well-studied primitives.)

Here's my take on this.  Pick the most experienced guy in the room, tell 
him to come back next month with a recommendation.  Done.

iang

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 23 Mar 2015 20:59:48 +0100

> Hmmm... so our technique is to punish people for wanting to improve. 
Where did I "punish" someone and/or where is my observation wrong?

> itself.
Then we can probably abolish fingerprints verification in the next
versions of OpenPGP implementations altogether,... if TOFU works, why
should anyone bother to check their keys o.O

> If you don't want to use it, that's fine, but the notion that 
> thing, not an absolute thing, and it is extremely unlikely
I kinda amused every time security based on such assumptions.
Some 5 years ago, the masses still thought that they're not victims of
mass surveillance and that their emails and data would be safe.
Nowadays people think that TOFU would provide high security and that NSA
and friends would never dare to abuse that...

> up to let others see my name - their mistake on default install.  After 
Well, NSA and friends probably don't bother to attack systems like Skype
on the crypto level, one can be quite sure that they have other means
for these =)

> friends, Microsoft and NSA.
uhm... great? o.O

> their dues by helping others?  From your writings it seems unlikely...
Actually I don't. I just don't prioritise lesser experienced users over
experienced ones.
What I prioritise is the intention of crypto, which is security.

> could be better spent on getting more usability?
The biggest "usability" problem we likely have nowadays in crypto is
that people would need to understand what they do and mutually
authenticate each other.
Apart from that we have quite nice UIs at all levels, don't we?
gnupg is actually quite nice for people who want to use command line, we
have fine tools like enigmail.

I somehow have the feeling, that for many people "usability" means not
noticing crypto at all, but I guess that just won't work.

> to RC4.  Not exactly a happy result.
So problems in the alogs themselves don't count for you? I.e. we could
still use MD5 since problems in it aren't solved by e.g. SHA2?
Or we should still use DES, since an algorithm switch couldn't solve
it's problems?

> When has diversity of algorithms ever bought user advantage?
Nothing in that his screen becomes more colourful or that his
"experience" would be more like 4K than just HD.

*If* someone does crypto, than probably because he wants to be secure.
So if diversity enhances security or at least allows one to switch more
easily in case it gets necessary (which of course you disputed above),
then it benefits the user by helping with his original goal (being
secure).

> at all.  So why do we care about the Russians?
Agreed. But hopefully the whole crypto standardisation would go anyway
rather into community hands now.

> also ... use that process to switch!  Why not just roll out v+1 ?
How long does it usually take us to roll out v+1? Take SSL/TLS, how many
years have SSL still been used while it should have not? The same for
MD5, the same for RC4, and so on.

Cheers,
Chris.

---

From: ianG <[email-masked]>
Date: Tue, 24 Mar 2015 01:03:11 +0000

> Where did I "punish" someone and/or where is my observation wrong?

Yahoo and google are at the forefront of secure email delivery.  They 
are trying something nobody else has got anywhere near - so I don't see 
how they can be called laggards.

(Assuming that is we debunk the joke of security known as S/MIME... 
which was deployed but was crippled by committee-design.)

> should anyone bother to check their keys o.O

The essence of TOFU is that it works in default mode, and gives you 
tools to do better if you so desire.  Now, of course, the concept works 
so well that one never bothers to check for the most part, so 
fingerprint verification could be dropped and would still provide more 
security than not using it.  Which is the goal.  So what you suggest is 
not incompatible with the goal.

But the PGP community came from a different age, so they do often check. 
  Add, they have turned it into a ceremony, one that binds the community 
at least for the time of the 'party'.  So I doubt we'll get rid of it 
just because it's only adding one more 9 to the 99.909% good enough.

> I kinda amused every time security based on such assumptions.

What other basis is there for security other than risk?

> mass surveillance and that their emails and data would be safe.

Yup, and the vendors figured that the masses aren't important enough to 
provide security.  Go figure.  As you point out, Yahoo is late to the 
game.  But Mozilla and Microsoft have always been emotionally contorted 
over it, and google has only recently started being serious, before 
there mantra was "all your data base belong to us'.  The only player 
that was ever serious about *the user* was Apple.

And they *all* promote the security-barrier called PKI/x.509, which 
delivers to compliance customers, and distracts from overall security by 
selling a tired old cold war military model as something to protect 
banks from phishing.  Go figure.

> and friends would never dare to abuse that...

Bring it on.  The point of improving security is to get from here to 
there, and actually improve the result.  Those who push the old 'perfect 
security models' mantra typically end up with an extremely narrow set of 
compliance customers, or nothing.  E.g., SSL.

Here in the PGP community we are *not interested in compliance* so much 
as actual ordinary users.

(Which isn't to say we don't come into connection with the compliance 
world;  we do because business models force us there from time to time. 
  But hearts and minds here are about real security delivered, not paper 
calculations.)

> on the crypto level, one can be quite sure that they have other means

Well, we know they now have direct access.  No need to speculate.

But the fact remains:  Skype has other than yesterday never directly 
harmed me.  Can't say the same for email, browsing, ...

>> friends, Microsoft and NSA.

So, what's my risk?  Microsoft (yawn).  NSA could get narked at my 
repeated jabs at their Stasi behaviour, and stop me at the border.  Grab 
my skype records and accuse me of naughty behaviour.  OK, I'll take that 
risk.

Meanwhile:  I've actually lost non-trivial fortunes because my 
counterparties turned around and attacked me.  I'm bombarded every day 
with spam.  I have to train my family in phishing because the browser 
vendors don't react or when they react, they PKI-me-harder rather than 
looking at the information being rendered to my mother.

Granted, if I worked at a Belgian ISP or SWIFT or my payments biz took 
off in a bad-ass way, I'd be terrified of NSA.

> What I prioritise is the intention of crypto, which is security.

Security is only measured by delivered results.  Let's say you improve 
the lot of the experts by offering them cipher suites to choose from. 
Hypothetically that improves the 0.1%, those that actually know what 
those words mean.  OK, 1 billion browser users, that would say about 1 
million know what a cipher suite is.  Exaggerated, but let's see where 
this goes.

Let's say we double their utility.

But, putting in vanity ciphers as we used to call them causes 
complexity.  A lot of problems in SSL would sweep away if we cut that 
crap out.  E.g., Heartbleed and somewhere it was claimed $500m costs... 
  So, let's say this all costs 1% for the masses.

Result:

Security = 1,000,000 * 2 + 1,000,000,000 * 0.99

Guess what?  Only the security delivered to the masses matters.

Which is why Skype worked and everything else fell in a hole.  Simple maths.

> that people would need to understand what they do and mutually

Well, right.  Systems that try and "authenticate" each other are 
typically usability nightmares.  Change the paradigm.

> have fine tools like enigmail.

Not for the masses, sorry, not of any interest.

> noticing crypto at all, but I guess that just won't work.

Skype.

(Sad to say, it got rolled before it was sold to Microsoft, and the NSA 
got their dream entre.  Oh well -- like we say, there's no such thing as 
a complete security model ... there's always a way around.)

But in an elegant way, that provded the K6 hypothesis.  Skype was so 
darn successful that the NSA had to 'buy' its way in, breach the company.

GSM - killed the serious risk dead, which was the paparazzi listening in 
to the famous doing sex talk.  And nobody noticed!

> So problems in the alogs themselves don't count for you?

Of course they count.  But, they are pretty much down the bottom of the 
list.  Check it out, do some historical research.  If you're worried 
about a crypt algo breaking, you ain't in the security game, you're in 
the cryptography game.

> I.e. we could

MD5 was deprecated in 1995 by SHA0.  Then 3 months later SHA0 was 
deprecated by SHA1.  I know, coz we cursed and changed.

SHA1 was deprecated in favour of SHA2 sometime early 2000s.

If anyone is using MD5 they're negligent.  If they're using SHA1, then 
they'd better be sure it ain't a collision risk (I do and it isn't) and 
if goes full belly up they still won't be in trouble.

> Or we should still use DES, since an algorithm switch couldn't solve

to channel Santayana, those who don't study their deprecation history 
are doomed to have their systems deprecated?

> "experience" would be more like 4K than just HD.

So, marketing.  Getting an upgrade to earn the fee.  OK.

> *If* someone does crypto, than probably because he wants to be secure.

Not really.  Vendors choose crypto because of their mastery of the 
security model (I'm being sarcastic here, anyone who uses SSL has no 
clue as to the security model) and that fits into the holistic business 
approach.

Very few users - the masses - rush out and say "I wanna six-pack o' 
crypto and 3 jars of authentication with some random side orders..."

It is *myth* perpetuated by the x.509/PKI tribe that "choosing crypto" 
means "wanting security".  This is part of the careful marketing edifice 
that was used to sell certs to an blase public.  Because they didn't 
want it, some elements were forced into being embarrassed to use it, and 
the rest is compliance history.  Also, it's part of the marketing 
against self-signed certificates;  if users "choose" certificates it is 
because they "want" security which is not allowed to include MITM 
possibilities so we have to deny self-signed certs.  Or some such sophistry.

Sorry 'bout dat!

> then it benefits the user by helping with his original goal (being

Yeah, sure.  Just doesn't work in practice, and doesn't work in theory, 
if we actually think about how it is supposed to work.

> MD5, the same for RC4, and so on.

I measured a 3.5 years OODA cycle for the first big SSL oops.  I haven't 
been following the others but I have a feeling they've got a lot faster.

Point is however, it's still all ad hoc.  We don't actually know what 
we're going to be switching, and pretty much each time it is a download 
/ reinstall.

So why not have a v+1 waiting in the wings?  Each new generation is 
substantially better and is far more likely to cover anything uncovered.

My point isn't that is what should be done.  But that right now we've go 
no plan.  So *anything* would do better than what we had right now.

iang

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Tue, 24 Mar 2015 04:36:29 +0100

> how they can be called laggards.
Uhm? Forefront? All these technologies were implemented long before by
others...
I remember that not so long ago Yahoo was even criticised every now and
then since they didn't even offer https to their webmail.

And what can they do better/more than what we already do?
If they implement e2e crypto within their webinterfaces, one cannot
really trust it - not because they're evil per se, but because *if* some
bored NSA agent sends them a national security letter they'll have to
comply, and when there's a gag order they couldn't even tell.
If they "secure" the TOFU step it's the same,...

> the joke of security known as S/MIME... 
I can't say anything against that :D

> tools to do better if you so desire.
And exactly this is also the point where it fails in practise:
None of the masses typically do so ever.

Worse, since the products/programs are now marketed as being secure,
everyone is even convinced that he'd be secure so doing more work (i.e.
real mutual authentication), which people were already reluctant to do
before, is now totally out of motivation.

And even worse, many applications/program actually stop giving you the
tools to do better - since nowadays it's enough to say "we do e2e crypto
with super-duper-algo XZY".

Take the current hype apps like TextSecure, which some campaigners
(heise and friends) advertise as the "good" tools (and as "usable"
instead of gnupg/PGP):
The mutual authentication step is basically completely hidden from the
user, much more than it used to be with most OTR implementations where
you got at least some dialogue that told you to do something.
But even if you know about that, you cannot do proper mutual
authentication - well it shows you the keys, but you cannot mark your
peers as trusted or not, which makes it useless when you have more than
a hand full of them.

>   Now, of course, the concept works 
If at a certain point, everyone would believe in TOFU, what would
prevent NSA&Co. from simply MitM every single communication?
There'd be not mutual authentication, so they could be Mallory.
And technically they're definitely capable, even today. We know they sit
at all big internet exchanges, undersea cables, satellites and probably
even at the big players (Google, Cogent, and so on) whether they know
and are part of this or not.

Even if you assume, that *something* would happen, if they're caught by
MitM attacking connections, when someone finally actually does the
mutual authentication.
What do you think would happen? We found already out that they do mass
surveillance, hack devices, routers and break into our computers... and
did anything happen?

> But Mozilla
Which distributes clearly untrustworthy CAs (and this is not the only
outrageous security issue, when you look at many issues in their BTS).

>  and Microsoft have always been emotionally contorted 
In the end, all of these would need to comply with their intelligence
agencies, and it's no so unlikely that they actually do.
Even security companies like RSA were caught.

> Those who push the old 'perfect 
> compliance customers, or nothing.
I wouldn't say "nothing" ... it's simply the set of users who
*seriously* care about their security.
And yes, the set of e.g. OpenPGP users is probably small,... so what?

> harmed me.
Neither has me the NSA or the GHCQ, nevertheless I wouldn't want to
share my secret world domination plans with them ;)

>   Can't say the same for email, browsing, ...
Well I guess you can't really compare these.
Skype is a singly system completely in the hand of one company with only
little numbers of users compare to mail or web.
Of course it's much easier to "secure" that.

> my skype records and accuse me of naughty behaviour.  OK, I'll take that 
If you feel like you want to share your stuff with them it's of course
okay,... but others might not want to.

> Guess what?  Only the security delivered to the masses matters.
That's IMHO quite some weird argumentation...
- First it again prioritises one group over other, i.e. the minority of
  people who could be really secure don't count - just the masses who
  anyway reach just a certain security level.
- With the same argumentation you could also drop OpenPGP,... in
  practise X.509 is enough for the masses.
  Yes I know it's broken, and yes fraud happens, but not to an extent
  that it would really bother anyone (neither from the point of loosing
  confidentiality or authenticity, nor from financial reasons).
  Or do you see the masses demonstrating against X.509? Do you see many
  people from big banks sitting around in our IETF WGs demanding for
  security systems for their online banking?
  No.
- Actually even more, you could completely drop ALL encryption (not to
  confuse with authenticity/integrity protection).
  As you said yourself, the NSA probably never did anything very evil to
  the masses that they really effectively noticed (i.e. they didn't rob
  our bank accounts, or stole our private pictures).
  The same for online criminals,... integrity protection/authenticity
  would be largely enough do to secure shopping and online banking.
  What else could they do the masses? Okay stealing all private kinds of
  data, nude pictures transferred to the cloud or the secret diary.
  But if one sends such stuff to the iCloud,... well *owned*.
- Or you could project this to other areas,... take
  Linux/Unix/OpenSource.
  The masses were just happy with there Windoze boxes. Thus, by your
  argumentation, experts/others don't count, thus they have to use
  proprietary cr** as well.

This analogously works for the typical argumentation of opposing people
which typically say "it's useless to secure XZY, because there's still
the weaker element ABC of the chain".
Well there always is a weaker element in the chain, if you focus on that
you could never secure anything else.

Long story short:
I don't think that OpenPGP was ever the system of the masses, and
perhaps it even shouldn't be.
It's mostly used in areas and by people where TOFU isn't enough, or at
least I wouldn't want to get my signed Debian packages just by good luck
authentic.

All this doesn't mean that one should intentionally try to lock out the
masses by making things overly complex. It just means
- we shouldn't weaken the security/functionality of those who can
  actually use it, just for another group of people wo even doesn't care
  so much
- we shouldn't give people the wrong impression that security is for
  free, just by activating the "i-want-to-be-secure" switch.

> Which is why Skype worked and everything else fell in a hole.  Simple maths.
I don't think this WG's or standard's intent should be to strive for the
highest popularity, market share or for making big money.

This is the path e.g. Mozilla chose at a certain point and that's why
the nowadays sell the interests/security/freedom of their users by
making all kinds of questionable choices.

OpenPGP already has a user base who likes its current philosophy. If we
can improve things so that we get more users, great, but not at the
expense of the current user base.

> typically usability nightmares.
I don't even think there's a usability problem from the software side.
The point is simply: people don't want to do the verification step,
regardless of how nicely the software assists that process.

>   Change the paradigm.
Well, if you have a crypto system which is secure and doesn't need
mutual authentication or some exchange of data on a secure path... just
tell us.
Apart from that, if you change the paradigm you rather end up at
something like X.509 where the responsibility for the trust is delegated
to some other party (which usually gives a sh** about that).

> Not for the masses, sorry, not of any interest.
Just speak for yourself... =)

> MD5 was deprecated in 1995
and is still used even in security critical fields...

> If they're using SHA1, then 
git

> crypto and 3 jars of authentication with some random side orders..."
But why then prioritising those who don't even care? 

> if we actually think about how it is supposed to work.
Any proofs for this claims?
We have e.g. OpenPGP which uses multiple algos and that works quite
well.

> been following the others but I have a feeling they've got a lot faster.
You think? I kinda remember that when the first papers came out about
the CBC issues or the compression oracles, the responsible engineers
said this was just theoretical.
Then we saw BEAST.

Or we had CRIME, and after it was fixed for SPDY, not really much
happened immediately (even though the authors already warned that this
would also work in general)... and... surprise... BREACH.

> we're going to be switching, and pretty much each time it is a download 
Well the download/reinstall is the least of the problems.
It's rather the standardisation/development.
And if we follow the original paradigm that was claimed here, and around
which all our discussion is motivated, and implement just single
security paradigms/alogs, it won't for sure get easier to exchange
something once necessary.

Cheers,
Chris.

---

From: ianG <[email-masked]>
Date: Wed, 25 Mar 2015 00:17:06 +0000

> perhaps it even shouldn't be.

OK!  Now that's the beginnings of a manifesto.  It's a position, plain 
and simple.

I think differently - I think a system that doesn't target the masses is 
doomed.

What do others think?

This is no light question, it could decide who participates, what the 
security model is, how 'hard' it is, where the compromises are found ... 
and decide its ultimate success.

iang

ps; this was taken from the other thread, plenty of actual argumentation 
in that too, but I know most will not read for length.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 25 Mar 2015 01:30:51 +0100

> I think differently - I think a system that doesn't target the masses is 
Any proofs for this?
OpenPGP (probably not targeted for the masses)
        => still okay and secure
X.509 (absolutely targeted for the masses)
        => inherently broken (unless of course one trusts the Mozilla
           CAs, e.g. turktrust and CNNIC O:-) )

XMPP (*intended* for the masses, but basically failed (actually, mostly
     thanks to the big players and greedy companies like wotzapp)
     => well, at least people have their freedom
Skype,Hangouts,Wotzapp (targeted for the masses, backed as such by the
                        big players)
                       => people completely surrender to the vendors and
                          their conditions (and don't these typically
                          even include that the vendor may do basically
                          anything he likes with the data, including
                          selling it?)

Cheers,
Chris.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 24 Mar 2015 23:06:38 -0500

The Internet is for Everyone.

7.125 billion or go home.

On Tue, Mar 24, 2015 at 7:17 PM, ianG <[email-masked]> wrote:
> OK!  Now that's the beginnings of a manifesto.  It's a position, plain and
> simple.
>
> security model is, how 'hard' it is, where the compromises are found ... and
> decide its ultimate success.
>
>
>
> iang
>
>
>
> ps; this was taken from the other thread, plenty of actual argumentation in
> that too, but I know most will not read for length.
>
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

---

From: Falcon Darkstar Momot <[email-masked]>
Date: Wed, 25 Mar 2015 01:04:29 -0700

In all seriousness, attempts to create useability for any target
audience by committee are probably doomed (even though what we have now
is balked at even by a lot of security professionals).  PoC something first.

--Falcon Darkstar Momot
--Shadytel

---

From: Werner Koch <[email-masked]>
Date: Wed, 25 Mar 2015 09:25:31 +0100

Hi!

FWIW: When I kicked of this thread I was not thinking of a "new OpenPGP"
but of long planned extensions and updates to an existing protocol.
Throwing everything over board and start from scratch should not be done
under the label of OpenPGP; there are already a couple of other projects
working on re-doing everything from scratch.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Stephen Paul Weber <[email-masked]>
Date: Wed, 25 Mar 2015 08:00:39 -0500

>I think differently - I think a system that doesn't target the masses is 

OpenPGP does not specify a UI.  "Target the masses" implies some kind of UI 
or use case or *something*.  OpenPGP is a format for packing bits together 
and specifying how some of them were encrypted/signed.  You can build any 
kind of PKI I've ever seen on top of OpenPGP, because it's just a format and 
doesn't specify such details.  This is as it should be.

-- 
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

---

From: Stephen Paul Weber <[email-masked]>
Date: Wed, 25 Mar 2015 08:02:53 -0500

>under the label of OpenPGP;

I very much agree.  To be "OpenPGP" is to be at least *able* to be backwards 
compatible with the current OpenPGP.  Otherwise you are something new and 
other.

---

From: Wyllys Ingersoll <[email-masked]>
Date: Wed, 25 Mar 2015 13:41:30 +0000

Compatibility with existing implementations should be a consideration when
making any updates to the spec.  Creating a "V5" key format is certainly
within scope.  Radically changing the packet structure or data encoding
scheme in a way that breaks all existing implementations or forces the
implementors to have 2 very different code bases to support old vs "new"
formats should be strongly discouraged.

One of the (many) problems with todays OpenPGP is that it is impossible to
update older keys to a newer format, which leads to many users continuing
to rely on old keys and implementors end up having to support the older
formats.  We could encourage users to "modernize" their keys if new formats
were designed with some thought to having an upgrade path from V4.
Revoking old keys and re-issuing your public key to your "circle of trust"
is tedious and semi complicated and most people just give up and create new
keys or stop using PGP altogether.  Certainly, weak keys should be revoked
and replaced, but "reasonable" keys that are just in an older format should
be easily updated to newer formats if possible.

IMO, the goals of an OpenPGP update should be:
1. Remove any outdated and/or insecure ciphers and hashes
2. Specify profiles for new ciphers, modes, and hashes with an eye towards
simplification.  Keep the "MUST" list short and the optional list brief but
extensible.
3. Upgrade path from V4 keys to V5 and beyond.
4. Don't fix what ain't broke.  ASCII Armor, for example.

If whatever results from this effort requires a complete rewrite of
existing OpenPGP parsing engines and reengineering existing apps from the
ground up, then it will be a complete failure and should be renamed
something else and taken to a new WG.

-Wyllys
@ipgmail

---

From: Clint Adams <[email-masked]>
Date: Wed, 25 Mar 2015 14:54:27 +0000

> working on re-doing everything from scratch.

Could you list them?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Mar 2015 05:16:14 -1000

> is balked at even by a lot of security professionals).  PoC something first.

Take a look at the work on http://prismproof.org/

I have done security usability in the past and the bit with the
testing lab and one way mirrors. After a while I realized that I
didn't need any of it. All that we need to do to achieve usable email
security is to make using the secure mail exactly as easy as using
insecure.

Think that is impossible? I have running code on SourceForge that
works with existing mail clients with no plug ins. It is based on
S/MIME of course because that is the message format that the clients
support. The trust model I am using is actually PGP fingerprints.

The configuration tool essentially has only one option, whether to
select a CA or not and if so the DNS name of the CA. (Right now the CA
registration code is incomplete due to the ACME situation).

Regardless of what the user chooses, the tool creates a personal PKI
for the user, complete with a self signed root, intermediate, split
encryption/decryption keys and a device key for use in key rollovers.
This is the CostCo strategy, instead of selling 20 different models
with different features, CostCo tells the vendor to provide all the
features of the top of the line model at the base model price.

Giving every user a 'standard' trust environment allows us to get to a
pretty good compromise between security and convenience from the
start. Expert users can always enroll supplemental keys which make
different security tradeoffs, not escrowing the key provides some
protection against a subpoena but introduces a real risk of data loss.

To send mail, users just send and receive as normal. The only time a
user has to be aware of the encryption is if they want to require the
message to be encrypted.

As I said, right now the code only supports S/MIME. But I have always
planned to add OpenPGP support so I can make use of the PGP keys as
well.

The key bit of technology is basically taking a bit of design for the web

"Take all the information you need to establish a connection and pack
it into one identifier that can be cut and pasted".

aed9ef23-12393764-64931237?[email-masked]

---

From: ianG <[email-masked]>
Date: Wed, 25 Mar 2015 17:32:39 +0000

>> I think differently - I think a system that doesn't target the masses is

Yup.

> OpenPGP (probably not targeted for the masses)

PGP - pretty good privacy - was targetted at the command line masses of 
the pre-web Internet of 1992.  Still ok, still secure, but ...

The definition of the masses has moved on.  OpenPGP no longer targets 
the masses.  And, in my view, unless something good comes out of the 
current Yahoo-google-friends partnership, will slowly fade.

>             CAs, e.g. turktrust and CNNIC O:-) )

No.  It never targetted the masses.  They only tell you in their 
marketing that it's "for the masses" so as to appease the browsers which 
have users as clients.  You bought that because they kept saying it so 
many times they believe it themselves.  But no.  x.509/PKI/CAs are for 
the corporates.

x.509 is irrelevant for privacy, expecially of the PGP variety.  And in 
the pre-web telco 1980s days the fixed-line masses, it was never 
intended to be a privacy system, but an anti-privacy system.  It was 
intended to map the world's population for the exploitation and control 
by the world's telcos, being national champions and in bed with 
governments and intel.

>       => well, at least people have their freedom

Hmmm, I don't know why it failed.  It didn't fail because of the *zapp 
companies, they simply did a better job.  Yes, I agree that the players 
wrote things like OTR as privacy, but I would agree that essentially 
they failed, it's another lesson.  Let's learn from it.

> Skype,Hangouts,Wotzapp (targeted for the masses, backed as such by the

Yup.

>                            anything he likes with the data, including

Right.  So let's take google mail.  google's meta is data data data. 
All your data are belong us.  Which meant that google had conflicted 
inventives, which got sliced open by NSA.  Hence today's story.  Hence, 
I have difficulty in saying that google are PGP people in the sense of 
pretty good privacy - who we are on this list are about.

Skype I would say were much more our sort of people, until they sold to 
ebay.  Then their new masters had ... different ideas, but that story 
has never been told in public, so let's not get distracted.

But back to your question:  do we need to target the masses to survive? 
  Yes.  Skype, google, Whatsapp, snapchat, Facebook, Apple iMessage, etc 
are still all in business and are providing revenues, and they provided 
what privacy they did as a secondary to delivering a revenue-generating 
service to the masses.  Absolutely.

Whereas the PGP community took the old 1992 model of privacy absolutism, 
and found that their brief spurt of success in building a community 
around key signing parties and so forth ... was steamrollered by the 
wider onslaught of the open web.

iang

---

From: ianG <[email-masked]>
Date: Wed, 25 Mar 2015 17:35:54 +0000

> but of long planned extensions and updates to an existing protocol.

Good point.

> working on re-doing everything from scratch.

What do people think?  I certainly wouldn't stand in the way of a group 
that wanted to do that.

But OpenPGP is more than an RFC - it's a shared vision, community, and a 
history.

We've learnt a lot since 1992.  If, in the act of tapping that learning, 
we tell the experience to go away and think up another name, I fear 
that's not productive, not efficient.

iang

---

From: Tim Bray <[email-masked]>
Date: Thu, 26 Mar 2015 13:44:34 +1300

You guys are taking it as axiomatic that a high-quality UX can't be
provided for users of OpenPGP.  Used OpenKeychain recently? Not quite there
yet, but I think your axiom is looking a little shaky.
On Mar 26, 2015 12:34 PM, "ianG" <[email-masked]> wrote:

> The definition of the masses has moved on.  OpenPGP no longer targets the
> masses.  And, in my view, unless something good comes out of the current
> Yahoo-google-friends partnership, will slowly fade.
>
>
> No.  It never targetted the masses.  They only tell you in their marketing
> that it's "for the masses" so as to appease the browsers which have users
> as clients.  You bought that because they kept saying it so many times they
> believe it themselves.  But no.  x.509/PKI/CAs are for the corporates.
>
> the pre-web telco 1980s days the fixed-line masses, it was never intended
> to be a privacy system, but an anti-privacy system.  It was intended to map
> the world's population for the exploitation and control by the world's
> telcos, being national champions and in bed with governments and intel.
>
>
> wrote things like OTR as privacy, but I would agree that essentially they
> failed, it's another lesson.  Let's learn from it.
>
>
>
> Right.  So let's take google mail.  google's meta is data data data. All
> your data are belong us.  Which meant that google had conflicted
> inventives, which got sliced open by NSA.  Hence today's story.  Hence, I
> have difficulty in saying that google are PGP people in the sense of pretty
> good privacy - who we are on this list are about.
>
> ebay.  Then their new masters had ... different ideas, but that story has
> never been told in public, so let's not get distracted.
>
>
>
> Yes.  Skype, google, Whatsapp, snapchat, Facebook, Apple iMessage, etc are
> still all in business and are providing revenues, and they provided what
> privacy they did as a secondary to delivering a revenue-generating service
> to the masses.  Absolutely.
>
> and found that their brief spurt of success in building a community around
> key signing parties and so forth ... was steamrollered by the wider
> onslaught of the open web.
>
>
>
> iang
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Mar 2015 22:56:18 -0500

On Wed, Mar 25, 2015 at 7:44 PM, Tim Bray <[email-masked]> wrote:
> You guys are taking it as axiomatic that a high-quality UX can't be provided
> for users of OpenPGP.  Used OpenKeychain recently? Not quite there yet, but
> I think your axiom is looking a little shaky.

Certainly not me.

PrismProof email makes S/MIME completely frictionless in use by
essentially grafting the PGP fingerprint trust model onto S/MIME.

I think the idea that we are going to get anywhere by pointing to the
faults in opposing systems is also flawed.

S/MIME and PGP have both suffered from lousy usability because the
original trust models simply don't work. X.509 is fine as a
certificate format, but there is no key discovery infrastructure until
deployment of X.500 is complete. Web of Trust is a fine academic
theory but it is not how OpenPGP is really used in the real world.

The lesson here that I draw is to look at how people are actually
using OpenPGP in practice and work out ways to apply the same approach
to other similar problems.

I do use one trick I borrowed from TimBL, take all the information you
need to establish a connection and smoosh it together in one
identifier:

AB7LRE-3EKR7K-ECT2KV2-7ATCFH-DXB?[email-masked]

But more recently, I have been playing about with games similar to .onion:

[email-masked]
http://example.com._AB7LRE-3EKR7K-ECT2KV2-7ATCFH-DXB/

OK, so what is going on here? Well we have a fingerprint as the
rightmost (i.e. most important) item in the DNS identifier. Which
means 'require a signed security policy describing how to interact
with the identifier to the left.'

So if you want to send email to [email-masked], do so under a
security policy that is signed under a key with the fingerprint
AB7LRE-3EKR7K-ECT2KV2-7ATCFH-DXB.

That security policy could say something like 'use PGP encryption to this key'.

One of the things OpenPGP proves is that we can quite easily build an
infrastructure that maps from a fingerprint to a security policy. But
one of the major changes since BaL and David and co put the MIT PGP
server together, the Harber-Stornetta patents have expired and we now
have better options like TRANS (or the BitCoin blockchain without the
need to wade through treacle).

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 26 Mar 2015 05:25:48 +0100

On Wed, 2015-03-25 at 22:56 -0500, Phillip Hallam-Baker wrote: 
> Web of Trust is a fine academic
Lol?
How else do you use it? 

> to other similar problems.
Well if your goal is to drop the WoT respectively simply let people
download stuff from a (secured or not) keyserver believing whatever
comes and hoping the best,... then better call it something else
(InsecurePGP?) and leave OpenPGP as is.

Cheers.

---

From: John Kreznar <[email-masked]>
Date: Wed, 25 Mar 2015 23:42:36 -0700

>> theory but it is not how OpenPGP is really used in the real world.

Speaking as a PGP user of over 20 years, I can say that I've NEVER used
the web of trust.  The way I really use it is to exchange keys with a
correspondent in plain text and confirm fingerprints out of band.

- -- 
OpenPGP key: http://ininx.com
 John E. Kreznar [email-masked] 9F1148454619A5F08550 705961A47CC541AFEF13

---

From: Werner Koch <[email-masked]>
Date: Thu, 26 Mar 2015 11:12:06 +0100

> Well if your goal is to drop the WoT respectively simply let people

The OpenPGP protocol does not specify any trust model.  It provides just
the features to build a PKI.  Some use the WoT, others build a X.509
alike system, some do not care at all, or use an ssh like non-PKI.

Shalom-Salam,

   Werner

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Mar 2015 03:32:26 -1000

>> theory but it is not how OpenPGP is really used in the real world.

I see people using fingerprints directly mostly. Some download them
from key servers.

By Web of Trust I mean actually following a chain to check a key.

> (InsecurePGP?) and leave OpenPGP as is.

No, I think there are quite a few things that we can do today that
change the WoT game. People carry smart phones with near field
communication, barcode, cameras. So signing can be made a lot simpler.

Another very important and useful development is Certificate
transparency which has the effect of making the work factor for
spoofing a key a suddenly go to practically infinity.

Another resource to bring to bear is social networking

And yet another is CA issued. If you want to know that someone is
sending a message from the US gvot or a company that is organized in
hierarchical fashion, a hierarchical PKI makes sense.

I describe a hybrid approach in some detail with a mechanism for
comparing trust models in terms of a 'social work factor' here:

http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-01

---

From: Brian Sniffen <[email-masked]>
Date: Thu, 26 Mar 2015 14:46:17 -0500

> By Web of Trust I mean actually following a chain to check a key.

I walked a colleague through doing that today: she needs to send me a
secret, and I can't take time to call her and read a fingerprint.
Fortunately, my key had been signed by many other colleagues, and she
had trusted keys from a few of them.  It worked exactly as designed.

It's similarly helpful for new peole joining that group---new staff, in
that case.  This is just an anecdote, of course, but so is "I have
never...".  I expect there are little cells of WoT usage scattered
around, and little cells of blind trust, and little cells of
read-the-fingerprint---when strangers meet.

> communication, barcode, cameras. So signing can be made a lot simpler.

I would be interested to see a tag on keysignatures.  That would let me
play with automatic signatures and such without polluting the WoT.  I
don't directly see how to do this---is this what "Key Endorsements" are
for in
<http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-01>?

Thanks,
Brian

-- 
Brian Sniffen
"I reserve the right to evolve my views, and state that views I previously
 expressed may have been somewhere along the spectrum from insufficiently
 nuanced through ill-informed to dead wrong."

---

From: Bill Frantz <[email-masked]>
Date: Thu, 26 Mar 2015 13:54:49 -0700

>correspondent in plain text and confirm fingerprints out of band.

I used the WoT once to validate a key. The key I validated was 
my own. I was at work, and my key was at home and on a key 
server. I wanted to send some company confidential data home, so 
I down loaded my key from the key server. My key had been signed 
by Carl Ellison, and I had a copy of Carl's business card with 
his key fingerprint. I check the fingerprint against Carl's 
signature, and had enough faith in my own key to use it.

Life does bring up some strange uses.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said 
users haven't
www.pwpconsult.com | learned anything about security?" -- Bruce Schneier

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Mar 2015 15:58:57 -0500

> had trusted keys from a few of them.  It worked exactly as designed.

Hey, S/MIME works fine with the 'call a friend' option as well :-)

If we could get PGP up to critical mass then the web of trust is
potentially a 'viral marketing' feature. Until we reach critical mass,
viral marketing means 'chicken and egg'.

As far as OpenPGPvnext goes, I would focus first on getting the
message and fingerprint formats revised and seeing what we can do to
eliminate 'needless' variation between S/MIME and OpenPGP.

Back when I was working on the Web at CERN I told Tim Berners-Lee that
we should kill the SGML bit and write our own document format
language. At that point we had about a million users. Tim replied that
the reason he adopted SGML was because he wanted to get buy in from
the publishing industry and they were committed to SGML. So I should
implement X.509(!)

At this point we can tolerate two message formats. But remember that
any mail encryption scheme that can emit CMS can send an encrypted
message to 1 billion email users using their existing clients. So even
though I despise ASN.1, I will write code that will do just that. And
come to that it seems most OpenPGP implementations have as well.

> read-the-fingerprint---when strangers meet.

The draft I mentioned earlier describes an approach to joining those
cells up together.

> <http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-01>?

Yep, I don't actually rate a keysignature as being worth anything
until it is enrolled in a TRANS like log.

There are some really fun things we could do in future on the trust
model side. But I think we need to decruft the base OpenPGP first.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Fri, 27 Mar 2015 00:58:23 +0100

> alike system, some do not care at all, or use an ssh like non-PKI.
Sure, I primarily meant, "if the goal is to modify OpenPGP such way,
that what we can do now is no longer possible" :)

Cheers,
Chris.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Fri, 27 Mar 2015 01:04:42 +0100

> By Web of Trust I mean actually following a chain to check a key.
Okay, probably we were using different understandings of "Web of Trust".
Admittedly I used it a bit wrong either, typically I mean a fully
meshable relation system, which allows basically anything what the user
want's to do:
- from the classic WoT, where trust is achieved indirectly (which I
still think is important, e.g. in communities like Open Source projects,
or for people who'd have gazillions of contact partners (Linus))
- the direct mutual signing, for best security/trust
- something more similar to X.509, e.g. via trust sigs.

> communication, barcode, cameras. So signing can be made a lot simpler.
Well I guess that should be free to the user what he actually wants to
do.
I personally wouldn't really trust anything a smartphone did. ;)
But this seems to be anyway pretty much out of the scope of the
standard?!

Cheers,
Chris.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 28 Mar 2015 11:56:11 -0400

> until it is enrolled in a TRANS like log.

I think this perspective is dangerous to privacy, if we want to be able
to support non-public certifications.

I often certify people's keys publicly (or i make OpenPGP certifications
and send them to the subject and let them decide whether to publish them
or not).  But i also think it's important to be able to make a
non-logged, non-public "letter of introduction", to be handed off when
needed.  OpenPGPv4 already supports this in the form of non-exportable
signatures.  The UI/UX for this is abysmal in most clients today (anyone
with UI/UX cycles to spare who wants some brainstorming ideas about how
to improve this, please talk to me), but it would be a real shame to
change the protocol in such a way to rule this technique out completely.

Parties who are globally relied-upon (e.g. the X.509 CAs that everyone
implicitly "trusts") should definitely be publicly logged.

But not everyone who certifies is in (or should be in) that position;
some of these relationships are private, and we should not force people
to publish them.

        --dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 28 Mar 2015 15:24:38 -0400

> some of these relationships are private, and we should not force people

By that I mean fixed in time. I agree that it does not need to be
public. Only the hash needs to be enrolled.