Kyle,
In a previous message you said
"...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
At 11:02 PM -0800 2/9/12, Kyle Hamilton wrote:
On Wed, Feb 8, 2012 at 9:06 AM, Stephen Kent wrote:
So, I don't agree that the distinction between the user and a machine
operated by a user is really significant, in the end. (Yes, I am ware of
the many security problems that arise becaus
At 6:12 PM -0800 2/10/12, Kyle Hamilton wrote:
On Thu, Feb 9, 2012 at 3:05 PM, Stephen Kent 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 ident
At 3:14 PM -0800 2/9/12, Joe St Sauver wrote:
Steve commented:
#I think we are in agreement. CAs that are not authoritative for asserted
#identities are as bad as federated trust entities with similar properties.
I tend to be a concrete thinker, so I hope you'll indulge me for a minute
in a con
At 11:29 PM +0100 2/9/12, DIEGO LOPEZ GARCIA wrote:
On 8 Feb 2012, at 20:30 , Stephen Kent 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
At 8:22 PM -0500 2/8/12, Phillip Hallam-Baker wrote:
Alice has three mobile phones and six laptops.
Using embedded keys in those devices for authorization is no problem
since each device can have a separate private key and the
authentication server tracks the fact that there are nine devices tha
At 2:40 PM -0800 2/8/12, Bill Frantz wrote:
On 2/7/12 at 11:55, k...@bbn.com (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.
Touche! You
At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote:
But authentication works in that scenario because the protocols can
allow each user to have as many keys as they need. The key is not
shared across devices, the protocols allow for multiple cards per
end user
Sorry, I don't understand you
At 7:56 PM +0100 2/8/12, DIEGO LOPEZ GARCIA wrote:
On 8 Feb 2012, at 17:36 , Stephen Kent wrote:
In the physical world we recognize that certain
entities are authoritative for identifying people
or orgs. These entities issue credentials to
people and orgs, and these credentials are
At 6:52 PM -0500 2/7/12, Phillip Hallam-Baker wrote:
...
The reason I no longer believe in end-to-end solutions is that the
endpoint for a public key is always a machine and the desired endpoint
is a person.
yes, the machine is the endpoint, but machines are always in the loop
for the sorts
Ryan,
That's a good list of additional problems associated with widespread
use of client certs.
Note that re the "branding" issue, there is a cert extension that
allows for logos to be embedded in certs, although the focus for this
is really server vs. client certs.
Steve
_
At 8:52 AM +0100 2/8/12, DIEGO LOPEZ GARCIA wrote:
On 7 Feb 2012, at 23:25 , Stephen Kent wrote:
federated authentication systems using certs generally seem to be
motivated because folks can make cross-certification work properly.
other federated auth systems seem to be based on having one
At 12:05 PM -0800 2/7/12, Joe St Sauver wrote:
...
This is actually a fascinating question, and one where the answer you
get for "Why don't people deploy client certs?" varies from person to
person. I attempt to capture a little of that in a talk I did a week
or so ago at Internet2/ESNet Joint T
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*worththi
...
Compromise (n): Any reduction in the utility of a public key to the
holder of its private key, including but not limited to expiration
of a certification, revocation of a certification, private key
duplication detection, key disclosure, or loss of private key
material.
cert expiration
15 matches
Mail list logo
