At 9:25 PM -0800 2/6/12, Kyle Hamilton wrote:
...
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.
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
_______________________________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey
