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 org trust
> another to assert and identity for a use
Phillip Hallam-Baker wrote:
>
> In practice most email that is sent encrypted is encrypted using TLS.
> If we had an infrastructure that allowed mail servers to know that
> their corresponding servers required use of TLS, the man in the middle
> downgrade attack could be defeated.
I'm sorry Phil
A very good point, this is also one of the reasons deploying smart card
authentication is difficult as well.
Today people use IP Phones, mobile phones, tablets, desktops, kiosks and
more; moving to a "require" solution for authentication requires one have a
solution for all of these devices or you
On Tue, Feb 7, 2012 at 5:25 PM, Stephen Kent wrote:
> I think there are multiple reasons why client certs have not taken off,
> based on 20+ years of experience in the area. We provided a client cert
> system for a financial firm in the early 90's. It was easy to use,
> bootstrapped from the pass
Forking thread as I fee compelled to discuss client certificates but I am
not sure its related to the original thread.
I also worked on some moderately successful client certificate solutions,
their success however was only possible because of the pain tolerance for
the communities they served; by
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
Kent commented on Kyle Hamilton's remarks...
#>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
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
wrt experiments, see for example..
Revocation checking and Chrome's CRL (AGL)
http://www.imperialviolet.org/2012/02/05/crlsets.html
[cryptography] Chrome to drop CRL checking
http://lists.randombit.net/pipermail/cryptography/2012-February/002236.html
=JeffH
___
Excellent summary Steve, thanks.
I'm up for a bar-BoF/side-meeting in Paris.
> There are specific (if not that well documented)
> proposals out there and I'd love to see their proponents
> arguing their relative merits in detail so's we
> could see if there are things that the IETF could/should
10 matches
Mail list logo
