Subject: Re: [therightkey] Will the real RPF please stand up?

From: Jon Callas <[email-masked]>
Date: Wed, 1 Feb 2012 00:28:25 -0800

On Jan 31, 2012, at 7:35 PM, Phillip Hallam-Baker wrote:

> I don't see the problem with defining the term 'trustworthy'
> 
> Risk = Cost imposed by likelihood of probable loss.
> Trust = Confidence with which risk is assessed.
> Trusted = An entity that is relied on to mitigate risk (whether
> trustworthy or not).
> Trustworthy = An entity that meets rational criteria for risk mitigation.
> 
> We could wordsmith the definitions, but I think we can probably agree
> on the general principles.
> 
> The problems stem from the fact that risk is a very complex function.
> It is not merely probability * probable loss since in a real world
> situation both are continuous functions, I might suffer  $100 loss
> with probability X, and a $1000 loss with probability Y and so on.
> 
> And it is not just the expected loss that is the issue but the cost
> that expected loss would impose on my business. My probability of a $1
> million loss might be 0.1% but the cost that potential imposes on my
> business might be much higher than $1000.
> 
> 
> I think we should also be able to come to agreement that even though
> we can define the terms, we can't expect to come to precise
> measurements, or even particularly satisfactory measurements. If we
> could do that we would be in the regular business of insurance.
> 
> In particular, insurance companies have always avoided writing
> policies on acts of war. The reason being that the probable losses
> simply do not follow a predictable pattern. Losses due to theft and
> even natural causes follow reasonably predictable patterns.
> 
> We are now dealing with politically motivated attacks and so we end up
> with probabilities that don't fit a mathematical model and losses that
> don't have a monetary value.

I don't buy it.

You're presuming that risk and trust exist in a vacuum and can be measured context-free.

Trust, you see, is transitive. Not transitive in the mathematical sense, but transitive in the grammatical sense -- it needs a direct object.

You might trust your mother, but do you trust your mother to set up your VPN? 

The flip side of this is risk, and indeed risk is colloquially just trust with the polarity inverted. Or perhaps risk is 1 - trust.

Most strictly speaking, risk is uncertainty, but we often think risk is danger. Under a strict definition of risk, jumping off the top of a skyscraper is isn't risky; in all likelihood, you'll end up dead. But jumping out of a second floor window is very risky because you might end up dead or you might tuck and roll with impunity.

Similarly, I trust you'll just be a splat from the skyscraper leap, but I can hardly use the word at all with the jump from the window. Things are riskiest when you might as well guess, it means that the probability is close to 1/2. Trust, in contrast is an approximation of certainty, and either end of the scale is trust.

And keys are just labels. I'm enough of an SPKI revanchist to say that keys are just names or labels. You can no more determine trustworthiness from a mere name than you can tell a book by its cover. To talk about trust, let alone trust*worththiness*, you're talking reputation. And what we mean by reputation is not merely certainty but certainty of a desirable outcome. Reputation and risk diverge when there's a low risk of a good outcome.

That's why we really shouldn't touch it, unless we're going to truly talk about the counterintuitiveness of a bad reputation being one that has low risk.

	Jon

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 1 Feb 2012 05:31:54 -0800 (Pacific Standard Time)

I do see a problem with defining the term 'trustworthy', because it's reinventing the wheel. It's already been defined in law as "fiduciary".  This is the kind of relationship you have with your doctor, your lawyer, your accountant, your bank, your insurance company, even your cemetary, every one of them regulated to a minimum standard of professional competence to protect your relationships with them from disclosure.

There's at least one US state (Nevada) which has laws which relate to Certification Authorities (NRS chapter 720).  Their implementing regulations (NAC 720) are very strong and well-designed, and focus on the things that should be focused on for CAs (including licenses).  The downside is that it's a $10k fee for the license, annually, and I have no idea how anyone could be expected to make any kind of profitable business in those conditions.

We're developing systems which need to work in the real world.  The real world already knows how to deal with paper, and the courts already know how to deal with paper.  What we need to do is figure out a means to bring crypto practice more in line with the kinds of due diligence and privacy already expected of paper.  In the US, it's a felony to tamper with or interfere with the delivery of paper mail (Postal Act).  It's also a felony to attempt to bypass a technological protection measure, such as encryption (DMCA).  It's not a felony to read unencrypted bits on the wire.  Shouldn't we be trying to create stronger protections for our users, instead of wrangling over poorly reinventing the brittle wheel?

-Kyle H

On Tue, Jan 31, 2012 at 7:35 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> On Tue, Jan 31, 2012 at 7:29 PM, Jon Callas <[email-masked]> wrote:
>>
>> On Jan 26, 2012, at 2:55 PM, Richard L. Barnes wrote:
>>
>>>>>> As security engineers, our role is to (a) reduce the number of
>>>>>> entities we trust; (b) reduce the extent to which we trust the
>>>>>> remaining trusted entities; and (c) determine the trustworthiness of
>>>>>> trusted entities.
>>>>>
>>>>> Really?
>>>>
>>>> Yep.
>>>
>>> +1
>>>
>>> One of the better definitions I've heard.  I would question whether (c) is even in scope; seems like a relying party function.
>>
>> We should run screaming from (c). Not only do there be dragons there, but there be dragons even in saying what "trustworthiness" means. Surely this is not a real-world reputation system.
>>
>>        Jon
>>
>>
>> _______________________________________________
>> therightkey mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/therightkey
>
>
>
> --
> Website: http://hallambaker.com/
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey

---

From: "Thomas Hardjono" <[email-masked]>
Date: Wed, 1 Feb 2012 11:35:32 -0500

> -----Original Message-----
> From: [email-masked] [mailto:therightkey-
> [email-masked]] On Behalf Of Jon Callas
> Sent: Wednesday, February 01, 2012 3:28 AM
> To: [email-masked]
> Subject: Re: [therightkey] Will the real RPF please stand up?
> 
> 
> > that expected loss would impose on my business. My probability of
a
> $1
> > We are now dealing with politically motivated attacks and so we
end
> up
> [cut]
> And keys are just labels. I'm enough of an SPKI revanchist to say
that
> keys are just names or labels. You can no more determine
> trustworthiness from a mere name than you can tell a book by its
cover.
> To talk about trust, let alone trust*worththiness*, you're talking
> reputation. And what we mean by reputation is not merely certainty
but
> certainty of a desirable outcome. Reputation and risk diverge when
> there's a low risk of a good outcome.
> 
> That's why we really shouldn't touch it, unless we're going to truly
> talk about the counterintuitiveness of a bad reputation being one
that
> has low risk.

Phil,

I read through of your PDF docs.

Jon brings-up a point related to trust and reputation.  What is not
shown (or simply assumed) in the Four Corners model is that a huge
amount of legal foundation (what I call "Social Trust") exists in the
banking world (where the four corners model exists).

The folks working on the "post-Liberty" (my term) identity protocols
and federation have learned over the last 10 years or so that a "Trust
Framework" (ala FICAM) is needed to being together Technical Trust and
Social Trust.  Otherwise the eco-system simply does not start working.
Bilateral contracts just don't scale.

Thus what I think is missing from this proposal is a recognition for
the need of a "Trust Framework" that will define the obligations of
all the participants in your ecosystem (eg. the CAs, DNS server
operators, ICANN, etc. etc.).  Developing a Trust Framework for the
next-generation internet infrastructure would be a great leap forward
for the IETF.  Otherwise, we just get stuck in the nuts-and-bolts of
yet more "technical trust" (yet another set of protocols to do XYZ).

/thomas/

__________________________________________
Thomas Hardjono
MIT Kerberos Consortium
email:  hardjono[at]mit.edu
desk:   +1 617-715-2451
__________________________________________

---

From: Jon Callas <[email-masked]>
Date: Wed, 1 Feb 2012 09:25:47 -0800

On Feb 1, 2012, at 5:31 AM, Kyle Hamilton wrote:

> * PGP - S/MIME Signed by an unverified key: 02/01/2012 at 05:31:54 AM
> 

I agree almost completely. It's fiduciary when you are dealing with money. It's whatever the equivalent is when you're dealing with information.

Money is wonderful because you can always back up a system with insurance (until you can't, as we saw with credit default swaps, etc). But information is different because if I lose a secret of yours, I can *never* pay you back. I cannot undo the transaction nor is it possible to repay for the damage with money. Yeah, it can be a fine, but it's not repayment. You can't unsink the ship that the loose lips sank.

	Jon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Feb 2012 13:43:19 -0500

That is a good point, and one that threatens to create a whole new chapter.

First, replying to Jon, what we are managing is not risk itself but
the cost imposed by the possibility of unintended outcomes. If the guy
is jumping out of a skyscraper and does not intend to make himself
into people pancake on the pavement, then he has a 100% probability of
realizing a major unintended outcome.

We could maybe come up with a precise term but the key point is that
the objective is to minimize the costs imposed by the unintended
outcomes. That is the way the system was originally designed and it is
still the right way to design the system.

What has changed is that a hundred million people now carry mobiles
with cameras and so suddenly the dwindling number of dictatorships are
discovering that they are now accountable for every atrocity their
security forces commit on camera.

So looking at the point Thomas raises, I think it makes the point
about costs quite clearly.

Alice is a patient
Bob is Alice's doctor
Carol is an outsource provider of patient records management systems.

Alice trusts Bob with her life (quite literally).
Bob has a professional duty to maintain Alice's confidentiality plus a
huge business incentive to do so.

As a consequence Carol has to do more than merely demonstrate to Bob
that she can maintain the records more securely than Bob could by
himself because Bob has to justify the situation to Alice (and
hundreds of other patients). If he has to talk to every patient and it
takes him 5 minutes, he has just lost a week of working time he could
have been making money in.

If that scheme is going to work at any level it is going to require
some sort of standard controls that Carol can be evaluated against

---

From: Paul Lambert <[email-masked]>
Date: Wed, 1 Feb 2012 17:20:48 -0800

Hi Martin,

I think we may all be looking at this elephant from several different angles.  We are having to write essays on our perspective to describe some broad generalizations that we are making.

>> >> One of the better definitions I've heard.  I would question whether
>> >(c) is even in scope; seems like a relying party function.
>> >
>> >We should run screaming from (c). Not only do there be dragons there,
>> >but there be dragons even in saying what "trustworthiness" means.
>> >Surely this is not a real-world reputation system.
>> >
>> >	Jon
>>
>> Yes! ... but, we can define "who we trust for what" ... who being a
>key, what being some Domain of Discourse with appropriate constraints.
>>
>> Trustworthiness as a probability or metric yields contradictory and
>nondeterministic evaluations.
>>
>> Paul
>
>Paul, is this necessarily bad?

I read "trustworthiness" as a potential metric - I'd rather see a formal framework that was close to first order logic rather than fuzzy logic.

That said, risk probabilities might be useful, but these seem better as an overlay than a foundational design element.

More of my point above was that we need to look at the bounds and constraints of the "trust" with a better model than we have in today's PKI.  For example not all top level keys should be able to make assertations about all possible domains - we need constrains.  We need a notion of domains of discourse to separate different usage of of cryptographic trust mechanisms.

>
>All three statements above are sort of correct IMHO. A slight
>modification:
>  "As security *protocol* engineers, we have to [...] and (c), give the
>users the capacity and ability to enforce their own trust-policies, for
>their own purposes, according to their own desires."
>
>Let's go deeper.
>
>I (still, thankfully!) have the ability to remove root CA's from my
>/etc/ssl/cert when I see fit to do so. And I do so.  But it's extremely
>cumbersome and obviously "does not scale".  Let's do better?
>Obviously, not all users on the planet can by decree of a small group be
>mandated to verify trust in the same manner, at least not very
>successfully. The choice of what you want to trust has always been
>there.
>
>From this I can't say that I either fully - or not at all - trust any CA
>in my root-cert store on an individual basis -- some are even there, not
>because I trust them indefinitely, but because of a combination of
> a) my browser becomes full of extra clicks without them,
> b) they do provide a varying-but-greater-than-zero % expectation that a
>TLS-connection that validates to them can be reasonably expected not to
>also be MITM:ed somewhere.

Yes ... PKI with lots of roots in browsers is broken.  

Individual points of trust (keys) should be able to be added and deleted by the owner of the system.  Each key should have specific limitations on it's domain of discourse with constrains possible within each domain (e.g. coding signing versus DNS)

>
>This doesn't mean *I* have 100% trust in any of them.  These are
>different things.
>
>Adding to that: having multiple inputs to your trust policy generation
>engine, as has been discussed here, can't possibly hurt the objective
>here?  Similarly, having an output from this trust resolution engine
>that motivates its calculation (according to your policy), can't hurt
>either?
>
>  configuration bar = list of various input sources;
>  trust_policy_compile(policy foo, configuration bar) ->
>trust_resolve_data[policy=foo]
>
>(Policy and configuration may actually just be one and the same.)
>
>Obviously, a computer program wouldn't work very well if a 67% trust
>implies that it should proceed with a computation in 67% of the
>instances:
>  The validation result through my trust verification engine using
>policy X ought to be that I either can (based on my policy!) proceed
>with the computation, or, that I have to abort it because of a lack of
>trust.
>
>  validate_with_policy(trust_resolve_data data, policy foo, certificate
>bar) -> (valid|invalid, {details})
>
>The policy can define things such as, a >X% fail-rate from
>convergence/observatory (using convergence/observatory-configuration
>foobar...) -> invalid cert verification, and list of root-CA's, etc.
>Note that this does not at all exclude putting multiple certificates in
>the handshake! That seems smart, for those who can afford the extra
>bytes transferred.

This is where I don't see how users will fully understand a % or analog metric.  I can
 see results of - Yes, No, can't tell/resolve, etc...

We need to step back a little to get a wider view.  A "trust" metric 
is not the end result.  WE are building systems to answer policy questions.
Like an oracle - the machinery we define needs to give an answer to
questions posed. Questions might be of the form: 
"Does *this_key have DNSaddress foo.com?

>
>So, perhaps having browser vendors and operating systems declare who The
>list of trustworthy entities according to their Process is, is not the
>best solution for all purposes?  Having defaults is fine, I guess, but
>for all I care this entire apparatus could (successfully, overall, I
>bet) be externalized to institutions dealing more solely with trust, and
>individual users would then get the option to choose between these. The
>feedback-loop this could provide is not without merit.
>  For example, there appears to me to be a natural place for someone to
>define these foo's, that users can use. And also [inputlist]
>configurations.

Feedback is a different matter ... metrics might be possible for more subjective observations about the behavior of a key's owner.  I think we have different underlying models.  Determination of the validity of the sssignment of attributes (like a name or capability) has a small enumerated set of results.

Aggregation of other attribute types (risk, rating, perceived value, reputation, etc) could be such a metric.  It might be possible to have a policy that used these type of attributes (e.g. eat at restaurant only if rating greater than x). Use or non-use of a name (per most of our discussed examples relating to TLS and DNS names) does not seem like a good place to have a metric (e.g there's a 88% chance that foo.com is the authorized DNS name for *this_key)

I may be looking at the back end of the elephant, but terms like "pinning" and such seem wrong.  With a "key centric" view, the DNS address or other information are attributes that can be assigned to a key versus a name centric perspective that has multiple keys per name and may need pinning.  

Paul

>
>Offline, people trust different things.  Would there be a
>protocol/standard/method to model this in a more scalable way online, so
>much better, I think.
>
>Best,
>Martin

---

From: Jon Callas <[email-masked]>
Date: Wed, 1 Feb 2012 17:45:46 -0800

> security forces commit on camera.

Phill, this is a great answer. I'll claim that it's just not the right question.

The Right Key has nothing to do with safe user experiences. Marginally, we could address the sort of question such as "what does the SSL lock *mean*?" but even that's pretty ill-defined. It also goes beyond whether trustworthiness (whatever it means) is within scope.

I still claim that we should not go near trustworthiness because I'd rather come up with one good solution than several vague ones. The PKI debates of fifteen years ago bit off more than they could chew, and that's part of why we're here. I think we need to do less before we do more.

	Jon

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 02 Feb 2012 10:23:46 -0500

> I may be looking at the back end of the elephant, but terms like "pinning" and such seem wrong.  With a "key centric" view, the DNS address or other information are attributes that can be assigned…

Maybe i'm misunderstanding what you're saying here, but the main "key
pinning" proposal seems name-centric to me, not key-centric.  It's a way
for a peer with a name you've already authenticated some other way to
make assertions about what keys it will use to identify itself in the
future.

So it's focused on the persistence of the peer's name, and keys are just
a mechanism to demonstrate that persistence.

I think that's a good thing.  Are you seeing it some other way?

	--dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 02 Feb 2012 14:44:42 -0500

> I still claim that we should not go near trustworthiness because I'd rather come up with one good solution than several vague ones. The PKI debates of fifteen years ago bit off more than they could…

I think there's an underlying tension in this discussion between two
ways of seeing what we're trying to do:

 0) we're trying to build one global mechanism for peer authentication
that will work automatically for everyone, without any per-user adjustment

 Vs.

 1) we're trying to build mechanisms for peer authentication that will
allow tools to reflect the decisions and perceptions of trustworthiness
made by their users

(0) seems kind of like the holy grail most folks would like to see, and
it would be very cool if things could Just Work like that.  But i think
it's a dangerous goal.

It's dangerous because (0) seems to imply that all users face the same
threats, have the same levels of acceptable risk, and share the same
interests.  This just isn't true in the real world, even in the limited
domain of verification of identity assertions.

If i'm an agent of the Central Council of Orgoreyn, i will be willing to
accept different assertions of identity than if i work for the Imperial
Court in Karhide.  I may even have special access to to some identity
certification material that my counterpart in Karhide does not (and vice
versa).  And if i'm an independent agent, unaligned (and potentially in
conflict) with both regimes, then my assessment of any particular claim
of identity will be different still.

Designing a system that assumes all users will be willing to accept a
single global identity authority (or set of identity authorities)
without any reflection of the user's particular circumstances is a
mistake.  In particular, it seems likely to make the system be
unreliable for people who are already marginalized, or for people who
are in opposition to powers who have some control over the global
identity authorities.

So that leaves us with option (1), which has the sticky issue of needing
to gather these personal/idiosyncratic requirements from users and
interpret them into some sort of coherent technical policy.  I know we
can't solve those UI issues on this list, but i'd hope that any proposed
solutions will at least consider the need to adjust for the user's
circumstances and propose some kind of reasonably coherent policy
approach to account for those circumstances.

	--dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Feb 2012 15:50:29 -0500

This is one of the main points I make in the papers: Trustworthiness
is always with respect to a specific set of risks. The risks faced by
an elderly grandmother surfing the Internet to buy knitting supplies
are very different to the risks faced by an opposition member in Iran.

We are never going to achieve perfect security for either our users or
ourselves.

---

From: Jon Callas <[email-masked]>
Date: Thu, 2 Feb 2012 13:25:47 -0800

> We are never going to achieve perfect security for either our users or

Which is why we should stick to mechanism over policy.

	Jon

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 02 Feb 2012 17:21:40 -0500

[quoting from two separate e-mails]

> Which is why we should stick to mechanism over policy.

I think i'm in agreement with you here, Jon, and i hope i haven't
confused the matter by my use of the word "policy" in the above
paragraph.  I'd appreciate clarification if you think i'm misunderstanding.

The mechanism(s) we build need to be capable of implementing the user's
policies, as expressed in some coherent (and hopefully comprehensible)
way.  But in designing these systems, we should not presume to set
policy for all users.

Choice of mechanism seems likely to affect the range of possible
supported policies, though (e.g. if presenting a single, standard X.509
certificate is the only mechanism a server has to introduce itself,
there's no way to express or implement a client's policy that requires
corroboration from independent parties).  So i don't think we can fully
avoid discussion of policy, if only to trot out example policies to see
if a proposed mechanism can support them.

Regards,

	--dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Feb 2012 18:00:45 -0500

I am not at all keen on languages for describing how to analyze policy either.

So I don't think we can hope to develop a system that allows the user
to define their own policy. Even trying to do that client side is
likely to fail. So I see two options. Either the user trusts the
browser provider to choose the right policy for them or they choose
some agent to act on their behalf.

The user can choose between trustycorp red label and trustycorp black
label security policies. But micromanaging when a cert is to be
accepted or not is not going to work.

The other side of security policy I can see working is when a site
makes a statement 'this is how our security configuration should
look'.

Now such a statement is not necessarily going to be an infalible
indicator that a policy violation is some sort of attack, see DKIM.
But just as DKIM records are useful to spam management companies,
security policy statements do have some use.

---

From: "Matt DeMoss" <[email-masked]>
Date: Sat, 04 Feb 2012 19:59:50 -0500

>>>>> remaining trusted entities; and (c) determine the trustworthiness of

A system with voting like Convergence (depending on configuration) has
the nice property that (b) shrinks as (a) grows, and we could
potentially care less about (c) except to provide some kind of
assurance that individual entities are in fact individual.

---

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 6 Feb 2012 21:25:55 -0800 (Pacific Standard Time)

> You might trust your mother, but do you trust your mother to set up 

Finally, someone talking some sense.

> And keys are just labels. I'm enough of an SPKI revanchist
> to say that keys are just names or labels. You can no more
> determine trustworthiness from a mere name than you can
> tell a book by its cover. To talk about trust, let alone
> trust*worththiness*, you're talking reputation.

Keys, or values derived from keys, are the only identities the computer can really comprehend.  Everything else, including certifications, is simply metadata.

Certifications are statements of reputation.  Reputation doesn't exist because we need to identify others, identifiers exist because we need reputation.  Identity certificates are convenient indexes into records, but we don't actually need them to contain everything that they contain.  All they really need to contain is a statement that the CA knows who enrolled the key, which is basically what an otherwise-unidentified certification is in any case.

Using the same key across multiple places may not seem to be something which has turned out to be a problem in practice, in that TLS sites use the same keys across every client.  However, it's a major reason why client-side authentication isn't accepted by the individual consumer.

The threat is that businesses will do anything to make a buck, so we must assume that they will be willing (no matter what they say their privacy policies are, because statistically at least one of them is lying) to perform back-end database matching.

This means that we can't rely on a single certified public key.  We can't even rely on knowing ahead of time how many keys we need to enroll.  We can't accept constant DNs.  We can't accept static keys.  We can't accept static certifications.

As a result, we need certifications to be API-enrollable.  The API must allow the user to able to specify what aspects of his certified identity are placed into the certificate.  Certifications should be a marginal cost item (a penny or two), because there is something of a queue for the certifier token service.  They should not be free, but they shouldn't be expensive either.

We should focus on providing as many chains of authority as are necessary to ensure security.  Perhaps enroll new keys using both a personal enrollment key and a device enrollment key, so that it's possible to identify which device was compromised?

-Kyle H

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Feb 2012 14:55:49 -0500

At 9:25 PM -0800 2/6/12, Kyle Hamilton wrote:
>...
>Keys, or values derived from keys, are the only identities the 
>computer can really comprehend.  Everything else, including 
>certifications, is simply metadata.

Keys are not really great identifiers; they change, they are not 
human meaningful (and thus there has to be another layer of mapping 
between key and human-readable IDs, which creates more 
vulnerabilities), etc.  We used to have a WG that pursued the notion 
of keys as IDs (SPKI) in certs, but it died.

>Certifications are statements of reputation.

if managed properly, public key certs can be assertions of identity, 
relative to a context. they need not be statements of reputation, but 
they can be links between entities and reputations. Reputations can 
be asserted separately, e.g., Good Housekeeping Seal of Approval, UL 
approval, WiFi Certifiied, ...

>   Reputation doesn't exist because we need to identify others, 
>identifiers exist because we need reputation.

an interesting perspective, but not one you'll tend to find in the 
secruity literature. in some contexts, reputation is a way for people 
to acquire additional inputs when making a decision to trust a person 
or org. in some contexts, and depending on how one defines 
reputation, reputation may represent authorization. but, there are 
contexts in which reputation and authorization are independent of 
identifiers, so ...

>   Identity certificates are convenient indexes into records, but we 
>don't actually need them to contain everything that they contain. 
>All they really need to contain is a statement that the CA knows who 
>enrolled the key, which is basically what an otherwise-unidentified 
>certification is in any case.

I don't know what "otherwise-unidentified certification" means. Also, 
I think there are a few useful additional fields in certs, e.g., 
validity interval.

>Using the same key across multiple places may not seem to be 
>something which has turned out to be a problem in practice, in that 
>TLS sites use the same keys across every client.  However, it's a 
>major reason why client-side authentication isn't accepted by the 
>individual consumer.

most folks believe that client certs are not widely used because of 
the added hassle to issue them, poor cert management tools for users 
who need to use the certs, and associated private keys, across 
multiple machines, and the inertia associated with moving away from 
passwords.

>The threat is that businesses will do anything to make a buck, so we 
>must assume that they will be willing (no matter what they say their 
>privacy policies are, because statistically at least one of them is 
>lying) to perform back-end database matching.

finally a statement which which I can agree.

>This means that we can't rely on a single certified public key.  We 
>can't even rely on knowing ahead of time how many keys we need to 
>enroll.  We can't accept constant DNs.  We can't accept static keys. 
>We can't accept static certifications.

I agree that users ought to have multiple keys/certs, and have done 
so in papers and talks since 1997. I don't see how this relates to 
constant names, static keys or static certification.

>As a result, we need certifications to be API-enrollable.  The API 
>must allow the user to able to specify what aspects of his certified 
>identity are placed into the certificate.  Certifications should be 
>a marginal cost item (a penny or two), because there is something of 
>a queue for the certifier token service.  They should not be free, 
>but they shouldn't be expensive either.

there are other models of cert issuance that might yield free certs, 
with limits on the context in which each cert is used. such limits 
help protect user privacy, because a user need not employ the same 
cert with a lot of different services. but, any model that requires 
user to have a number of certs must contend with the user interface 
problems to which I alluded above.

>We should focus on providing as many chains of authority as are 
>necessary to ensure security.  Perhaps enroll new keys using both a 
>personal enrollment key and a device enrollment key, so that it's 
>possible to identify which device was compromised?

we don't require the same level of security for all transactions. if 
we assume that the cost to issue a credential may be proportional to 
the assurance associated with its issuance (which may not be true in 
all cases), then we might have very cheap, maybe free credentials for 
many transactions, and better ones, perhaps more expensive ones, for 
a more limited set of transactions. One size need not fit all re 
issuance. But it is nice if one format can be used to reduce costs 
for CAs and RPs.

Steve

---

From: Bill Frantz <[email-masked]>
Date: Wed, 8 Feb 2012 14:40:13 -0800

On 2/7/12 at 11:55, [email-masked] (Stephen Kent) wrote:

>Keys are not really great identifiers; they change,

Keys don't change. People or programs may wish to change the 
keys they are using, but keys themselves are constant.

>they are not human meaningful (and thus there has to be another 
>layer of mapping between key and human-readable IDs, which 
>creates more vulnerabilities), etc.

It the key represents an authorization, it may not need to be 
human meaningful.

We get a lot of comments wanting to achieve some level of 
assurance about identification. For most uses, we are more 
interested in authorization than in identification. (If we need 
identification for auditing purposes, it can be included in the 
the authorization. For example:

  Authorization to deposit to account 123456 as Joe User.

There are any number of approaches to providing secure 
authorizations, some of which can be bookmarked in standard browsers.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | Airline peanut bag: "Produced  | Periwinkle
(408)356-8506      | in a facility that processes   | 16345 
Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, 
CA 95032

---

From: "Kyle Hamilton" <[email-masked]>
Date: Fri, 10 Feb 2012 18:12:19 -0800 (Pacific Standard Time)

On Thu, Feb 9, 2012 at 3:05 PM, Stephen Kent <[email-masked]> wrote:
> At 11:29 PM +0100 2/9/12, DIEGO LOPEZ GARCIA wrote:
>>  >...and I do agree with you in that whichever entity making such
>> assertion (X.509, SAML, JWTŠ) has to be authoritative for the identity
>> asserted if you want it to be usable.
> I think we are in agreement. CAs that are not authoritative for asserted
> identities are as bad as federated trust entities with similar properties.

What are these 'identities' that need to be asserted with authoritative backing?  I hope you're not just talking about state identities, even though state identity is an important part of it.  The current crop of authoritative information CAs are very good at two things: they know how to authenticate documents, and they know how to authenticate authority (defined as 'a state', or 'the government of a state').  They are probably, in that respect, even better than State Department employees.

US Federal don't want to get involved with providing a service to every citizen.  They would rather foster the development of a private authentication service industry, and accredit it.  No matter what we might believe is "correct" from a purely theoretical view, US Federal Bridge PKI has cross-certified Verisign, Verizon/Cybertrust, Operational Research Consultants Inc, and Entrust.  On top of this, aerospace contractors often have their own certifiers, who are delegated similar Authority.  Ironically, this Authority is currently not recognized by user software.

But the reason why I don't want to get hung up on state identities is because clubs need to have their own identities, too.  Virtual clubs and forums need to have theirs too, and it's common practice to fill out forum signup forms with bogus information because the forums typically don't actually need real identity information.  Trying to insist that the DN be matched solely from an authoritative CA violates this "principle of least privilege", which means that people can't use authoritative CAs if they want to protect their personal information from identity thieves and still communicate over the network.

-Kyle H

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 13 Feb 2012 01:06:41 +0100

> What are these 'identities' that need to be asserted with authoritative backing?  I hope you're not just talking about state identities, even though state identity is an important part of it.  The…

Authoritative in terms that they are the recognized source for whatever identity data asserted. As Steve already said in this same thread:

On 10 Feb 2012, at 01:22 , Stephen Kent wrote:
> A CA operated by a company is the right CA to identity individuals as
> employees of that company. if the company operates it's domain and
> manages mailboxes for its employees in that domain, then it is he
> right CA to issue certs with employee e-mail addresses.

If we are talking about identity data related to citizenship, then we'll need state authorities. Otherwise, the appropriate source shall be used: a company for its employees, a university for its students or faculty, and an association for its members...

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Feb 2012 18:11:47 -0500

At 6:12 PM -0800 2/10/12, Kyle Hamilton wrote:
>>>  >...and I do agree with you in that whichever entity making such
>>>assertion (X.509, SAML, JWT·) has to be authoritative for the identity
>What are these 'identities' that need to be 
>asserted with authoritative backing?  I hope 
>you're not just talking about state identities, 
>even though state identity is an important part 
>of it.  The current crop of authoritative 
>information CAs are very good at two things: 
>they know how to authenticate documents, and 
>they know how to authenticate authority (defined 
>as 'a state', or 'the government of a state'). 
>They are probably, in that respect, even better 
>than State Department employees.

I fear that you're not paying close attention to what I said, Kyle.

>US Federal don't want to get involved with 
>providing a service to every citizen.  They 
>would rather foster the development of a private 
>authentication service industry, and accredit 
>it.  No matter what we might believe is 
>"correct" from a purely theoretical view, US 
>Federal Bridge PKI has cross-certified Verisign, 
>Verizon/Cybertrust, Operational Research 
>Consultants Inc, and Entrust.  On top of this, 
>aerospace contractors often have their own 
>certifiers, who are delegated similar Authority. 
>Ironically, this Authority is currently not 
>recognized by user software.

yes, the Federal bridge CA is a bad idea, as implemented.

>But the reason why I don't want to get hung up 
>on state identities is because clubs need to 
>have their own identities, too.  Virtual clubs 
>and forums need to have theirs too, and it's 
>common practice to fill out forum signup forms 
>with bogus information because the forums 
>typically don't actually need real identity 
>information.  Trying to insist that the DN be 
>matched solely from an authoritative CA violates 
>this "principle of least privilege", which means 
>that people can't use authoritative CAs if they 
>want to protect their personal information from 
>identity thieves and still communicate over the 
>network.

I'm not talking about 'state" identities in most cases. Look at the IDs
associated with most of the credentials that you 
hold. They include your name and a number. Your 
name is not globally unique, but a name plus a 
number managed by the authority IS unique, 
relative to that authority. This applies to 
credit cards, driver's licenses, frequent 
traveller cards, and passports.

Steve

---

From: "Kyle Hamilton" <[email-masked]>
Date: Thu, 16 Feb 2012 19:50:30 -0800 (Pacific Standard Time)

> yes, the Federal bridge CA is a bad idea, as implemented.

Federal Bridge CA is a much better idea than what we have now.

Currently, we have large numbers of absolutely-trusted roots with no controls on them other than ultimate distrust.  Worse, we have no way to protect users from misbehaving ones other than software update pushes.  We have no actual way to determine negligence except in light of what other people raise to us, and the people who are supposed to raise things to us don't know what to look for, what to tell us, or where to tell us.  Negligence in private contracts is a fairly difficult thing to prove, and carries almost no penalty.

FBCA has an ongoing audit and accreditation system (with heightened detection of failures due to GAO oversight), has a working revocation system, and only cross-certifies CAs run by people with a contract in place with a Federal entity.  This makes the negligent violation of the terms of the Federal Common Certificate Policy a highly-detectable 10-20 year felony, with the ability to shut down the affected root without a software push.

This is a better situation than the current lack of contracts in place with (e.g.) Mozilla, and is a much better threat than what we've got right now ('go out of business', not 'go to prison') once it's discovered.

I don't understand.  How is FBCA "a bad idea, as implemented"?

> associated with most of the credentials that you hold. They include your
> name and a number. Your name is not globally unique, but a name plus a
> number managed by the authority IS unique, relative to that authority. This
> applies to credit cards, driver's licenses, frequent traveller cards, and
> passports.

I acknowledge your point.

Relative to local authorities (who are authoritative for their own realms of use and utility), the name is not an identifier at all.  The name is metadata associated with the locally-authoritative identifier, which is the unique assigned record number you refer to.

Local authorites aren't authoritative for legal names, but legal names appear in and on the credentials they issue.  This is why a strict binary interpretation of certificates fails: only individual components of the atomic certificate are what the local authority is authoritative for.  There is no single authority for everything.  Many authorities are authoritative for different parts of a person's gestalt identity.  Each individual authority needs to issue credentials that are useful to itself and its served users.   And, many times multiple authorities are necessary to really get the job done.

In addition, these credentials are often useful for other social things which don't involve the original local authority, like "has an American Express Black card" is often seen as a status symbol.

-Kyle H