Note that the definition isn't all that complicated, but does cover the
essential issue that discussions of privacy usually entail, specifically
control
over disclosure. Also note that that is quite a useful distinction from
confidentiality and its usual embodiment of encryption.
+1
My
Jari,
It is important to understand the limitations of technology in this
discussion. We can improve communications security, and in some cases
reduce the amount information communicated. But we cannot help a
situation where you are communicating with a party that you cannot
entirely trust with
I confess that I am confused by much of this discussion. As I understand
it, PRISM is not a signals intelligence activity; it only addresses that
data at rest within those organisations who have partnered with the NSA.
As such, improving protocol security will achieve nothing against PRISM;
it is
Though of course an underlying problem is that no vendor wants to sell
hardware that will obsolete itself, unless of course it obsoletes itself
by requiring the customer to purchase even more expensive hardware than
it replaces.It's hard to see how IETF could fight against vendors who
were
Personally I would characterise this as a demand-side problem, not
supply-side: most users plainly aren't willing to pay for Internet
transparency.
I don't think that's the problem; I think the problem is that most users
don't realize how much lack of transparency is harming them.
Sure,
Section 3.2 of draft-wierenga-ietf-eduroam describes the issues presented
by EAP's spartan support for error condition handling. Although these are
described in the context of a particular roaming operator's experiences, I
believe this is also likely to be true for other non-trivial deployments.
OK, pardon the cheap shot, but I don¹t think SDOs that have some sort of
stewardship relationship to the Internet should ever play any part
whatsoever in the facilitation of DRM.
So it's ok to define protocols that manage access to services (e.g., TLS,
GSS, SASL, etc), but not to the content
Legislation exists for some jurisdictions, such as the EU eSignatures
Directive, that controls the legal effect of a qualified digital signature.
Does anyone know of any analyses of the implications of such legislation and
DNSSEC?
Josh.
JANET(UK) is a trading name of The JNT Association, a
(I sent this yesterday as a response in some other thread, but as a result I've
had reports that it has been overlooked. I'm sending it again more explicitly
to solicit more responses).
As someone who is involved in eduroam, I'm curious how many people found the
availability of eduroam at IETF
As someone who is involved in eduroam, I'm curious how many people found the
availability of eduroam at IETF 78 useful.
If you believe that you are eligible to use eduroam - irrespective of whether
you tried it at IETF 78 - please consider completing the form at the following
URL (it's only
Since we expect a reasonable attendance at IETF from
eduroam-connected sites, IETF participants with an eduroam account
configured, should get connected to the wireless network right away
with their usual credentials.
And it's working flawlessly on my laptop and phone. Thank you to everyone
Sam wrote:
We plan to discuss the general problem and a proposed
solution at the bar BOF. I've already prepared a feasibility
analysis for JaNet(UK)'s solution; the analysis does discuss
the problem some, gives an outline of the solution and
discusses technical issues and required
Eliot,
Klaas Wierenga, Hank Mauldin, Hannes Tschofenig, and I have
submitted several drafts for consideration in the context of
SASL, and we will be presenting a short version of them at
the APPS Area meeting and perhaps something longer in SASL in
advance of consideration of a charter
Hi Hannes,
Hans wrote:
Josh wrote:
Hans wrote:
Josh wrote:
I have a long list of applications, collected from within this
community, with which they would like to use SAML-based
authorisation;
Interesting. Any interest to share it with us?
I'm in the process of trying
Hi Hannes,
My fear about SAML in TLS was a history like the following one:
* Hmmm. SAML becomes popular. We should put it in every protocol.
* There isn't an extension for TLS defined yet. Let's do it.
* Now, let's search for the problems it could solve.
If the argument that you're
Hi Hans,
Hannes wrote:
Melinda wrote:
and that there are
some non-trivial advantages to carrying authorizations in-band.
Namely...
I don't wish to speak for Melinda, but this is a view shared by many
within my own community.
I have a long list of applications, collected
Sam Hartman wrote:
The Kerberos community has many years of experience that
within an infrastructure, carrying authorizations in-band has
been useful and has reduced the effort required to fit an
application into a larger infrastructure.
Just a quick plug, following Sam's comments:
Hannes wrote:
Melinda wrote:
and that there are
some non-trivial advantages to carrying authorizations in-band.
Namely...
I don't wish to speak for Melinda, but this is a view shared by many
within my own community.
I have a long list of applications, collected from within this
I support publication of this document.
josh.
-Original Message-
From: ietf-announce-boun...@ietf.org
[mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG
Sent: 14 January 2009 16:18
To: IETF-Announce
Subject: Fourth Last Call: draft-housley-tls-authz-extns
On June
gestation).
FWIW I've personally never understood what niche(s) PANA was
expecting to fill, but I assumed it was me being dim.
josh.
Josh Howlett, Networking Specialist, University of Bristol.
email: [EMAIL PROTECTED] | phone: +44 (0)7867 907076 |
interal: 7850
20 matches
Mail list logo
