On 19/12/08 05:57, Kyle Hamilton wrote:

Self-help chat message boards are a rather odd concern,


Not sure what you mean by "odd" ?  Social networking is all the rage.


and they're
actually where I want to try to put PKI.  The "problem" as far as it
goes is this: I want to put PKI there.  I DON'T want to put real names
there.

Those nyms are valid identifiers, and thus "names" as far as they go,
within those environments -- and as long as you're in that
environment, you don't need PKI, since the board software has an
online link to its authenticator.  Once you drop out of that
environment, there are two routes you can go:
1) The OpenID route (separate the identity-consumer from the
authenticator, with an online verification system)
2) The PKI route (separate the identity-consumer from the
authenticator, without an online verification system)


Um. What about "create the nym-authenticator online, without verification." ? This is the one that works, and the one that they use. Why not just add PK to that?


One of my favorite examples is "the bank manager who writes slashfic
while not at work".  (slashfic is, essentially, fan fiction that
explores the writer's concepts of relationships between the
characters.  Some of it's quite explicit, some of it is quite tame,
but it's all 'copyright infringement' unless the rightsholder has
explicitly granted fans the right to create derivative works, which
they usually[*] don't because then they have a hard time actually
selling the "derivative work" right to someone who might want to pay
for it.)  Suppose that one of her superiors at corporate -- or worse,
a customer -- looks up her name on Google.


OK. That's an example that is similar to mine. People need separations in their lives.

Linking the pen-name with legal/employment identity would be
deleterious, since courts have held that companies can reasonably
expect certain standards of behavior from their employees, even
without explicitly delineating those standards.  However, slashfic
writers often go to science fiction conventions, and when they do they
often want to be known by their pen-names.  The convention itself
needs to know the legal name, for its own protection -- but those
membership lists are generally not considered "freely accessible
information".


This is a constructed example, albeit one that is popular in USA perhaps and Britain. I've seen this sort of requirement in discussions in Britain, but there is a political element to it.

In other places, people would ask "why does the convention need to be able to link the two names?"

This could be where we get cultural differences again. The European perspective would be that data protection regimes give them that possibility anyway, and if not, there is a potential breach of law going on here. Whereas the American perspective would be that the marketing of the names is considered more a corporate right, and it is a trade for a cheaper price.


Now, suppose the bank manager/author takes a vacation, and goes to a
convention.  Then, suppose that (for whatever reason) she needs to
prove that she's the author of the stories that she wrote, even if
they were based in a world that she didn't have rights to use.  (Don't
knock this, it's occurred at least once that I'm aware of -- not with
a bank manager, but with a songwriter/lyricist.)  PKI could be
extended to cover this case, if we got away from the
overly-restrictive requirement that people seem to put into it that
require legal names in their identity certificates.


Having identified a linkability requirement, I think the answer is more complicated than either group would have it.

If you have to have linkability, then you also have to have control over linkability. That is, there would need to be some formal dispute resolution (legal perspective) and some data protection (Euro-style) in place. These would be requirements, which would then present a more elegant example of how threats should be modelled, requirements developed and security modelled.


It could also be used to allow for authentication of instant message
sessions.  (I'm currently looking at the OTR protocol, from
http://www.cypherpunks.ca/otr/, and trying to create a
certificate-authentication system that integrates at the point where
they currently use the Socialist Millionaire Protocol -- i.e., after
the session's been generated, and without using the keys in the
certificate to create any kind of signed/nonrepudiable record.)


Ah, OTR. There is at least one howler in OTR; starting with the premise expressed by the name: Off-the-record.

This is a classic case of how cryptographers completely misunderstood legal concepts of records.

That said, I'm sure the protocol itself is relatively elegant.


*this is slowly changing with such movements as the Creative Commons,
which can do BY-NC-SA licensing, but entertainment industry lawyers
haven't figured out what to do with that yet.


I doubt they will :)  most scenarios involve no jobs for them!

So, PKI is the precise wrong thing for them, because it identifies them and
tries (badly) to ensure that they are traceable.

It's only as "precisely wrong" as the identities that are embedded
into the certificate.


No, this is moulding the PKI to fit the apparent needs.

For those users, they don't want any linkability. At all. They don't trust any concept that says "trust me." In this application, they are deeply needing of trust, and what they need is to verify for themselves that no link exists. The requirement is that nobody knows who they are, and some faceless corporation promising to not reveal it is a non-starter.

(OK, so there are some obvious flaws here, such as IP# linkability ... despite this, social networking works, in a way that a formal PKI design is less likely to.)


A deeper more nuanced view would be that once we identify a thing that needs
protecting, then we still have to compare the costs of the threat with the
costs of the protection.  For example, MITM is in this camp; the protection
for MITM in say secure browsing is too expensive, given that only in the
last year or so (recent K case) have we seen any real evidence of attacks.
  Without a costs based analysis, any sense of "protect against X" lacks
foundation.

The case above is a case where an individual, not a corporation, has a
lot to lose by not doing it.  Loss of income, loss of job, loss of
reference, loss of career... corporations don't have to worry quite so
much, because they've GOT the controls in place.  Those controls are,
ironically, what the individual needs most to protect against.


Sure.


Yes, I realize that I'm describing a pathological case.  However, it's
a case where the existing tools (software and hardware) could work, if
the policy encoded and embedded in the common usage of those tools
were to be relaxed.


Ah. As you have seen, the policy for the employment of these tools is quite strongly embedded in a certain philosophy, and the incumbents won't relax it. The philosophy does not really extend out to protecting ordinary people; it is more oriented to the sales of security tools to corporations.

I admit I don't know where to go to change that. When I consider that some of the changes suggested will sell vastly more certificates, and they are still rejected out of hand because they breach some philosophy or other, it is hard to know where to turn to.

You see this occasionally in Verisign where they are big enough to employ marketing specialists who actually know what Marketing is. These folks come out and say "we'd like to employ standard marketing tool X ... doh!"

One of the key security and marketing tools is brand, which is employed by standard security designs since before the net existed (think ATMs). If you look at Firefox, the *security* side declines to use brand as a security tool, even with the new EV thing. One of the benefits of EV was that it finally presented the user with something to hang their risks & liability on -- a brandname -- and finally connected security end-to-end.

Yet, on the very next box to the right, google and other search engines are happily branding away. Is it any wonder that people trust search engines more than they trust CAs?


The other aspect that must be considered is that threat models and security
models are notoriously fickle and complicated, so even if you do them, you
could be wrong;  often it is more economic to forget the security modelling,
and run with what works well for now.  Fix up the bugs later.

You're viewing it from the POV of a corporation again.


Actually, no; users are the most frequent employers of "fix it later" security. E.g., they commonly sign up to reveal their innermost secrets on these social networking sites, and blithely make mistakes about identity and traceability all the time.


In my view, cryptography is useful for
MUCH more than just "protecting against potential attack".
Er, what else is there?

Let's see.  Microsoft uses cryptography (at least hashing)

Yes, hashes are the one part of crypto that easily escaped! I love hashes, I use them everywhere.

for its
Single Instance Storage mechanism (it consolidates all duplicate
copies of a file into a single copy, and creates hard links to that
file -- with copy-on-write semantics).


Ok!

Hashing is also used for rsync and all sorts of non-attack scenarios.

Other aspects of cryptography?  Probably not so much.

Ah. Look, I would interpret this differently, I would say that Software is using Cryptography to solve its problems where they are found. Software is best oriented towards reliability, and certain classes of problems need very reliable checksums, for which hashes fit admirably.

(Security is a subset of reliability.)

But, in this sense I fully agree, this is how crypto should be used (and is used in the best designs, even if I do say so myself).

http://iang.org/papers/fc7.html

Skip down a page to the colourful diagram :)


However, in the
PDF signature case the attack-protection is primarily a side-effect of
the timestamp, which is the most useful aspect for thwarting the
unwitting "attack" of human error.


I think we are agreed that the PDF signing case presented today isn't a good use of energy.


(It's not
like we're trying to protect secrets with national security
implications.  It's not like we're trying to protect a financial
instrument.  It's not even like we're trying to keep an affair
secret.)

I don't know about that;  sometimes we are, sometimes not.  In my work, the
second.  I've seen the third, and alluded to it above.  Protecting national
security:  no, that is pointless for us, let them do that.

I was referring specifically to the PDF signature issue as "not trying
to protect a financial instrument", actually, but in general you're
right.


Right.

Although, funny story:  the guy who deals with the CIA wiki presented
recently (I forget his name) and he said that one day, an IT department
programmer got annoyed at the standard browser which was out of date, so he
downloaded Firefox onto a local private server for programmers only.  It
quickly spread to other programmers ... and then out of the local
environment.  The security people raised hell, because it was unauthorised,
but by then it was too late, the Firefox virus was spreading throughout the
CIA.  Within one year, Firefox had taken over and forced the security people
to declare defeat and make it the official browser.  Regardless of any
analysis that they could do...

Sometimes users tell us stuff, but are we able to listen?

If the response that I've gotten on this list over the past three
years is any indication, evidently not.


There are no users on this list, as far as I know. This is a common complaint of mine: who speaks for the user in a security forum?

Well, ok, backpeddalling here, there is one other that takes the user perspective who occasionally posts, but too infrequently (hi David!).


These things that I'm bringing up (that the PKI would be much more
useful to everyone if the stringent requirement that only the Legal
Name be used in the Subject be dropped),


BTW, I don't believe this exists. In PKI, the documentation clearly permits a non-legal name (whatever that means) to be used, and even the European Union preserves that right. Mozilla does not have a policy pronouncement against this (please correct if I am wrong).

The problem is that it is essentially therefore up to each CA to deal with it, and for the CA, it clashes with the "certificate manufacturing" model which is so much in favour. The problem the CA would likely face is that the issuance of nyms brings the CA closer to the liability issue, and until that is sorted out, nyms are not worth the money.

<hobby> insert here reminder to think about liability problem! </horse>


I've been bringing up for a
long while.  This is the first time that a real discussion about the
concept has come up, and this is the first time that anyone other than
I has publicly recognized even a single case where a real name in a
certificate is counterproductive.


:) The world of people doing security stuff with nyms is about 100 times bigger than the PKI world. All social networking, all webmail, social forums, chat, gaming, ebay (its origins), for example.


As I've said before, I view cryptography as a means of associating a
policy with data.
Well.  You might want to consider a wider view like financial cryptography
:)

Even that's a means of associating a policy with data: The policy is
"this is financial information and must be treated as such, and if you
have the key to decrypt it, you understand this and agree."


Ah, I meant, really, it's a more holistic way to bring policy together with data, not just insert the two together in a sentance and hope that nobody notices. See the above link.


Two of my friends work for banks in the EU.  I met them in a
pseudonymous environment, and I didn't learn their legal names (or
even a tiny bit of information about where they work) for more than
six years... and I also met them in-person at science fiction
conventions several times in that time.  In fact, the only reason why
I learned one of their names is because he signed up for GoodReads,
which doesn't allow pseudonyms.  (Hence, the "confusion" aspect: I got
a mail from GoodReads, saying that some name I'd never heard of had
invited me to keep up with what he was reading.  I mentioned this in
the chatroom where we often hang out in the evenings, and one of them
PM'ed me with a "er, sorry... that's me".)


Right. It worked up until now, which is pretty stunning really. 6 years of protection, and then only a local breach. Good stuff.


The policy in this case would be: this is a
document version that someone working on behalf of Mozilla (currently
-- and with the tenacity and thoroughness she's exhibited, hopefully
for a LONG time -- Kathleen) prepared, it hasn't been corrupted, and
it's got a timestamp so that later revisions can be identified as
such.  Cryptography can give me a very good idea that these three
concepts can be relied upon.

Hopelessly unreliable, in my opinion.  Crypto will tell you that someone
with "Kathleen's key" made that PDF, but some time later we might discover
that Kathleen now works for Microsoft.  Nobody bothered to replace the key,
because it worked.  Working practices are better than halted practices,
don't break something that isn't broken!

Just because someone might work at Microsoft doesn't mean that they
can't contribute to Mozilla, as well.  Or at least that's my
impression from my acquaintances who worked there.


No, hold on, all I was doing was laying out how this would likely happen in a classical office situation; of course it was a specious example constructed to carry on the situation.

The point is, in offices, they do work. Where a system helps, they use it. Where it causes problems, they bypass it. People -- real users -- regularly bypass security systems where they slow the work down.

If you would like a theoretical foundation for this, have a look at Kerckhoffs' 6th principle. It is perhaps the most important principle in security. I don't know anything more important.

https://financialcryptography.com/mt/archives/000195.html


 (Granted,
Kathleen's a full-time Mozilla employee, but I assume that if she left
that Frank would inform us all.)


Actually, I assume not. What business is it of ours? Frank might do it out of politeness, but I certainly wouldn't expect it.


By the way, Frank?  Is there a pool for a Secretary's Day gift for her? :)


Is Kathleen a secretary?  :)


Why does it have to be any more complex than this?  Why does there
have to be any more "meaning" assigned to the act of digitally signing
something?
There always has to be a meaning.  Otherwise we wouldn't do it?  The problem
is, which meaning?

Usually, everyone who discusses a PKI expects that the "meaning"
always includes "financial" and "legal commitment".


Right. The problem is, everyone who discusses finance ignores people who don't understand finance, and everyone who discusses law likewise.

E.g., this is why banks run their own CAs when they get involved in PKI.

(This is the same the world around, it's not just unique to finance or law or PKI.)


If you build something for corporations and business, consumers won't
beat a path to your door -- but if you build something consumers can
use for fun, and your door happens to be right there, they'll come in.

Indeed.  If your worldview is that you build that way, sure...


As a side effect of this, without using it in their recreational
lives, non-cryptography-savvy employees need increased training
budgets from every business/organization that wants to use it.
Already, there's a generalized requirement that
knowledge-work/administrative employees know how to use a computer,
since the training budget is a bit too high and the value of the
knowledge gained is extremely portable.


Yes. So we see the flaw here: sellers of security like the use of high training budgets ... and miss the implication that the tool is not useable easily enough to survive. So security sales are pushed to becoming big up front investments that frequently fail once we get out of the classroom.

Meanwhile, Skype and Firefox breach the corporate security model with aplomb.


iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to