On Mon, 15 Dec 2003 07:37:23 +0100
"Anthony G. Atkielski" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> > Linux could at least stand on the claim that it was implementing
> > the RFCs as written, and that the interoperability problem was
> > due to the other end failing to implement
Mark Smith writes:
> So what purpose do RFCs serve if they aren't specific enough to be
> complied with ?
They can easily be complied with and yet still be general. It's just
that there may be argument as to what constitutes perfect compliance or
lack thereof, and it isn't generally possible to
On Mon, 15 Dec 2003 07:37:23 +0100, "Anthony G. Atkielski" <[EMAIL PROTECTED]> said:
> Microsoft knows better; apparently Linux developers and/or supporters do
> not.
Microsoft knows better than the RFC?
or
Microsoft knows better than to implement RFCs so everybody can benefit?
I'm not sure t
[EMAIL PROTECTED] writes:
> Microsoft knows better than the RFC?
No.
> Microsoft knows better than to implement RFCs so everybody can benefit?
No.
> I'm not sure that either parsing is what you want to be claiming.
Good.
I was saying that Microsoft knows better than to make claims such as yo
On Mon, 15 Dec 2003 08:19:15 +0100
"Anthony G. Atkielski" <[EMAIL PROTECTED]> wrote:
> Mark Smith writes:
>
> > So what purpose do RFCs serve if they aren't specific enough to be
> > complied with ?
>
> They can easily be complied with and yet still be general. It's just
> that there may be arg
Mark Smith writes:
> Are you aware of the reason why certain words are capitalised in RFCs ?
Yes. I don't see the relevance of that here.
> Implementations can be measured against the capitalised words in RFCs.
But there are many many ambiguous directives in RFCs, both with and
without upperca
[EMAIL PROTECTED] wrote:
I'd put this a different way. Until PKIs are able to represent the
rich diversity of trust relationships that exist in the real world,
they are mere curiosities with marginal practical value.
That's a true statement whether it's the PKI's fault or not.
I think Kei
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| I think Keith has mixed up authentication with authorization. It is
| true that I will only trust certain people in certain ways. But whether
| those certain people are who they are, and whether a message from is in
| fact from them, is something
On Sun, 2003-12-14 at 23:34, Anthony G. Atkielski wrote:
> jamal writes:
>
> > So the Linux decision was infact a very good one. An award of some form
> > is in order.
>
> Maybe Microsoft will be inspired to do things the same way: it can
> change its implementations in order to break 10% of all
On Fri, Dec 12, 2003 at 08:15:57AM +0100, Anthony G. Atkielski wrote:
> [EMAIL PROTECTED] writes:
>
> > Nonsense. I'm running Linux, several versions. I can
> > get to the ISOC site from all of them.
>
> Then what is preventing others from doing so?
Apparently nothing.
--
Kent Crispin
- Original Message -
From: "jamal" <[EMAIL PROTECTED]>
To: "Anthony G. Atkielski" <[EMAIL PROTECTED]>
Cc: "IETF Discussion" <[EMAIL PROTECTED]>
Sent: Monday, December 15, 2003 6:12 AM
Subject: Re: Re[4]: www.isoc.org unreachable when ECN is used
> On Sun, 2003-12-14 at 23:34, Anthony G.
On Mon, 15 Dec 2003 10:22:24 +0100, "Anthony G. Atkielski" <[EMAIL PROTECTED]> said:
> "If a host has received an ECN-setup SYN packet, then it MAY send
> an ECN-setup SYN-ACK packet. If a host has not received an ECN-setup
> SYN packet, then it MUST NOT send an ECN-setup SYN-ACK packet."
> From: Paul Hoffman / IMC <[EMAIL PROTECTED]>
> At 2:14 PM -0500 12/14/03, Keith Moore wrote:
>> if you can show me a tool that will translate statements like the
>> above (or other statements that ordinary humans can understand) into
>> data structures that existing PKI-base
On 15-dec-03, at 14:03, Spencer Dawkins wrote:
Your definition of broken is a little off. I would think the broken
implementation is the one that misunderstood the definition.
"reserved" as i have been enlightened privately has been clearly
defined at IETF as:
a) Must be set to zero on transmis
Franck Martin;
>>That you can construct a PK structure to represent a set of trust
>>relationships for some purpose does not mean that there is some
>>general purpose PKI.
>>
>>There isn't.
>>
>>That is, that you must construct a PK structure for every different
>>purpose is not a software issue b
PKIs, if any, is no useful for authentication on consumable
credential. The only merit of PK with CA over shared key with
KDC is that no communication with CAs is necessary for every
transaction. However, it means that there is no entity to check
the amount o
Having worked in the "PKI" field for a lggg time now, there are a
couple of points I'd like to make:
- any system which relies on one entity to be globally "trusted" by
everybody for everything (or alternatively, one entity to be authoritative
for everything) is doomed to failure.
For PKIs in general, there's always an "out of band" transfer of a public
key that you elect to "trust" before secure communications/transactions can
occur. Often, this is the transfer of a "root key", which is then relied on
to certify other public keys you get in the course of doing business. T
Keith,
I've authored several papers that capture what I see as the essence
of your characterizations, in a simple form. The central notion is
that most of these relationships are NOT about trust, but rather
about authority. if one views them in this fashion, then it becomes
apparent that the
Al Arsenault;
Having worked in the "PKI" field for a lggg time now,
Where can I find an authoritative reference on what "PKI", by
your definition, means?
- unfortunately, many people when hearing the phrase "public key
infrastructure" thinks that that is what is meant/required, eve
Stephen Kent;
I've authored several papers that capture what I see as the essence of
your characterizations, in a simple form. The central notion is that
most of these relationships are NOT about trust, but rather about
authority. if one views them in this fashion, then it becomes apparent
th
At 4:31 +0900 12/16/03, Masataka Ohta wrote:
Stephen Kent;
I've authored several papers that capture what I see as the essence
of your characterizations, in a simple form. The central notion is
that most of these relationships are NOT about trust, but rather
about authority. if one views them i
Paul Hoffman / IMC wrote:
> At 4:29 PM -0500 12/14/03, [EMAIL PROTECTED] wrote:
> >On Sun, 14 Dec 2003 12:09:37 PST, Paul Hoffman / IMC said:
> >
> >> All of that is describable, and many vendors have such products.
> >> There are no standards (or none that are significantly followed) for
> >> s
The term "PKI" is surely hyped and overloaded with meaning. But as
many people are pointing out, the use of public key technology
supported by tools and infrastructures attuned to the needs of
user communities has its place, both now and in the future.
If you have great ideas in this area, or if
Neal McBurnett;
> The term "PKI" is surely hyped and overloaded with meaning.
Can you clarify *YOUR* definition of PKI?
> But as
> many people are pointing out, the use of public key technology
> supported by tools and infrastructures attuned to the needs of
> user communities has its place, bot
Stephen Kent;
I'm having a feeling that you call a set of software/hardware
to handle certs a PKI.
The problem for such PKI is that, if we have certs based on
existing trust (e.g. I trust some organization have an authority
to issue passports) relationships, we can exchange shared secret
using the
Comments in-line, prefaced by my initials "AWA".
Al Arsenault
> -Original Message-
> From: Masataka Ohta [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 15, 2003 2:15 PM
> To: Al Arsenault
> Cc: Franck Martin; Paul Hoffman / IMC; Keith Moore; [EMAIL PROTECTED]
> Subjec
At 6:08 +0900 12/16/03, Masataka Ohta wrote:
Stephen Kent;
I'm having a feeling that you call a set of software/hardware
to handle certs a PKI.
no, there is a lot more to a PKI than hardware and software.
The problem for such PKI is that, if we have certs based on
existing trust (e.g. I trust so
> > This has nearly nothing to do with the technical part of the PKI,
> > and everything to do with the humans.
>
> Hence my original comment that the politicians need to broker the
> trust relationships.
that's about like saying that Microsoft needs to provide diversity in
the marketplace.
Al Arsenault;
AWA: See, for example
http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-09.txt
From Section 1.2:
Public Key Infrastructure (PKI) - The set of hardware, software,
people, policies and procedures needed to create, manage, store,
distribute, and revoke PKCs
Stephen Kent;
I'm having a feeling that you call a set of software/hardware
to handle certs a PKI.
no, there is a lot more to a PKI than hardware and software.
Mmmm, OK.
not to mention the existence of a lot of software that can make use
of certs and public keys.
I'm afraid you are saying we s
On Tue, Dec 16, 2003 at 06:17:26AM +0900, Masataka Ohta wrote:
> Neal McBurnett wrote:
> > The term "PKI" is surely hyped and overloaded with meaning.
>
> Can you clarify *YOUR* definition of PKI?
At our PKI workshops there have always been people from a wide variety
of perspectives. PKI is a bu
On Mon, Dec 15, 2003 at 12:05:50PM -0800, Tony Hain wrote:
> Hence my original comment that the politicians need to broker the trust
> relationships. There will clearly be multiple technical relationships, with
> very different characteristics, just as there are for inter-personal trust
> relations
33 matches
Mail list logo
