David,
Steve,
I think the modified introduction text suffices to connect the PATHSEC
and BGPsec terms, but I don't think that referring to the SIDR WG
charter for the PATHSEC goals is reasonable -- an RFC is an archive
document, whereas a WG charter is not.
The revised intro text now
David,
Since this doc logically precedes the BGPsec design, I still think it's
appropriate to
use PATHSEC here. But, we can add a sentence to connect the terms. I
propose this modified text for the introduction:
*This document describes the security context in which PATHSEC is
intended to
David,
I agree with Sam here. The key table is analogous to the SPD in 4301,
but not
the PAD.
Another doc being developed in the KARP WG does have a Routing
Authentication Policy
Database (RAPD) that incorporates aspects of the PAD from 4301, as well
as some
SPD fields.
Steve
during IETF LC.
Steve Kent (on behalf of Roque Gagliano and Sean Turner)
Joe
You're right, I did miss your point, quite thoroughly :-)
I am guessing that the answer is that there's no corresponding facility in
DNSSEC to for a policy identifier to be published with a DNSKEY RR, but I say
that largely ignorant of X.509 and attendant CA policy and hence perhaps am
The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'The RPKI/Router Protocol'
draft-ietf-sidr-rpki-rtr-19.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
I support this doc, and concur with Stewart's comments.
Contrary to what some have suggested, we sometimes (ofttimes?) have more than
one standard for no good technical reason. Sometimes very large,
competing companies back different standards for parochial reasons,
to the detriment of
At 6:07 PM -0400 5/3/11, Sam Hartman wrote:
Stephen == Stephen Kent k...@bbn.com writes:
I guess the only question I'd have remaining is whether ROAs or
other signed objects are intended to be used in other protocols
besides simply living in the SIDR repository
At 7:48 AM -0400 5/4/11, Sam Hartman wrote:
Stephen == Stephen Kent k...@bbn.com writes:
Stephen The BGPSEC protocol being defined does not pass around ROAs
Stephen or other RPKI repository objects. It defines two new,
Stephen signed objects that are passed in UPDATE messages
At 10:32 AM -0400 5/4/11, Sam Hartman wrote:
...
Let me see if I can summarize where we are:
You've describe an upgrade strategey for the origin validation in the
current set of docs. It depends on the ability to store multiple certs,
ROAs and other objects in the repository.
requirements
At 12:02 PM -0400 4/25/11, Sam Hartman wrote:
...
However, when I look at section 2.1.4 in the signed-object document ,
the signer can only include one certificate.
How does that work during phase 2 when some of the RPs support the new
format and some only support the old format?
Your text
At 9:27 AM -0400 4/17/11, John C Klensin wrote:
Steve,
Two things:
(1) Given the variable amount of time it takes to get RFCs
issued/ published after IESG signoff, are you and the WG sure
that you want to tie the phases of the phase-in procedure to RFC
publication?
It probably would help if
At 11:05 AM -0400 5/3/11, Sam Hartman wrote:
Let me make sure I'm understanding what you're saying. I can have
multiple ROAs for the same set of prefixes in the repository and valid
at the same time: one signed by a new certificate and one signed by a
previous certificate? If so, I think I now
Sam,
In response to your comments on the res-certs draft, re the
restrictive nature of the relying party checks in certs, we have
prepare the following text that will be included as a new section in
the document.
Steve
-
Operational Considerations
This profile requires that relying
At 6:03 PM +0100 3/11/11, Martin Rex wrote:
Phillip Hallam-Baker wrote:
1) WPA/WPA2 is not an end to end protocol by any stretch of imagination.
It is link layer security.
It is a 100% end-to-end security protocol.
Because the IETF deals in Internet protocols (for the most part) e-t-e
Jeff
Steve noted a desire to limit the liability of entities acting as CAs in
the RPKI. I agree that goal is desirable, and restrictions on what
certificates issued by those CAs can contain help to do that (provided
the CAs actually comply). However, requiring compliant RPs to treat all
At 5:58 AM +0100 3/11/11, Martin Rex wrote:
Stephen Kent wrote:
n to act as CAs , and we want to limit their liability.
One way to do this is to restrict the fields and extensions in
resource certs to make then not very useful for other applications.
A CA should never sign extensions
At 8:20 AM +0100 3/11/11, Nikos Mavrogiannopoulos wrote:
...
What Peter probably meant to say was that IPsec chose to truncate the
HMAC value to 96 bits because that preserved IPv4 and IPv6
byte-alignment for the payload. Also, as others have noted, the hash
function used here is part of
At 5:08 PM -0800 3/8/11, Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 3:55 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
Martin Rex m...@sap.com writes:
Truncating HMACs and PRFs may have become first popular in the IETF within
IPSEC.
It wasn't any may have become first popular,
Sam,
The cert profile is intentionally very restrictive, as you noted. A
primary rationale is that we are asking folks who manage address (and
AS#) allocation to act as CAs , and we want to limit their liability.
One way to do this is to restrict the fields and extensions in
resource certs
...
Curious; RFC2402 says
Flags -- This field is excluded since an intermediate router might
set the DF bit, even if the source did not select it.
which is a licence to set the bit but I had not thought to reset the bit.
RFC791, RFC1122 and RFC1812 would appear to be
At 1:47 AM -0400 6/2/10, Suresh Krishnan wrote:
...
Hmm. The ETA certificate itself does not need to have the RFC3779
extension in it, but the relying party needs to fetch an RTA
certificate which will contain a RFC3779 extension.
more precisely the ETA MUST NOT have such an extension.
At 9:15 PM -0500 3/13/10, Phillip Hallam-Baker wrote:
So what has me annoyed about the IAB advice is that they gave advice
about a particular means where they should have instead specified a
requirement.
Phil,
I am not commenting on your proposal, but I do want to make a few
observations
At 2:17 PM -0400 3/18/10, Phillip Hallam-Baker wrote:
Before declaring victory, lets see if anyone actually uses it to
validate any data.
fair enough. anything else is speculation by both of us, so lets
table the discussion for a year or so.
Steve
At 2:18 PM -0500 2/12/10, Edward Lewis wrote:
At 10:57 -0500 2/12/10, Stephen Kent wrote:
If we look at what the CP developed in the SIDR WG for the RPKI says, the
answer is the IESG (going forward, after an initial set of algs are adopted
based on the SIDR WG process). In the IPSEC, TLS
At 8:50 AM -0800 2/12/10, David Conrad wrote:
On Feb 12, 2010, at 7:57 AM, Stephen Kent wrote:
Who gets to decide on what algorithms get first class status and
based on what criteria?
If we look at what the CP developed in the SIDR WG for the RPKI
says, the answer is the IESG
So, they're
...
As a document shepeard I have made note that this is desired, but at
the same time this is a topic that was outside the scope of the working
group.
This is on the other hand a topic that belongs in the IETF review.
So my questions to the IETF (paraphrashing George Orwell)
Are all crypto
I recommend that the document not be approved by the IESG in its
current form. Section 6.1 states:
6.1. Support for GOST signatures
DNSSEC aware implementations SHOULD be able to support RRSIG and
DNSKEY resource records created with the GOST algorithms as
defined in this document.
At 1:11 AM -0700 10/13/09, SM wrote:
Hi Steve,
At 12:18 12-10-2009, Stephen Kent wrote:
When the site closed, do you believe that all of the material
published there will become inaccessible, not archived anywhere? I
doubt that.
I am not sure whether all the material will be available
At 10:29 AM -0700 10/9/09, SM wrote:
...
Section 1.1 of the draft mentions that:
The IESG may provide an IESG note to an Independent Submission or
IRTF Stream document to explain the specific relationship, if any, to
IETF work.
That's a may. From what you said, I deduce that you would
Dave,
I'd like to address some of the points you made in your message to
Russ re 3932bis:
...
The first assumption is that there is a real problem to solve here. Given 40
years of RFC publication, without any mandate that the RFC Editor
must include a
note from the IESG, and without any
Joel,
I agree that IESG notes should be rare, but primarily because
independent stream submissions should be rare :-).
Long ago, when I served on the IAB, we grappled with this problem,
and failed to find a good solution. Despite what we say about RFC
status and origin markings, the public
At 10:05 AM -0400 8/5/09, Dean Anderson wrote:
Ned and Stephen,
If you mean the recent message traffic about the 'intention to remove'
extractor from a list of patented documents, that hasn't happened so far
and an 'intention to remove' doesn't mean it isn't patented. It is
possible that
I too support publication of this document as a Standards Track RFC,
in light of the salient message traffic of late.
Steve
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
At 10:32 PM -0400 6/11/09, David Conrad wrote:
Hi,
On Jun 11, 2009, at 8:35 PM, Stephen Kent wrote:
But, in a DNSSEC environment, IANA performs two roles:
- it coordinates the info from the gTLDs and ccTLDs and constructs
the authoritative root zone file
- it signs
At 10:41 AM +1000 6/11/09, Mark Andrews wrote:
In message p06240803c65430cf6...@[10.10.10.117], Stephen Kent writes:
Joe,
You have argued that DNSSEC is not viable because it requires that
everyone adopt IANA as the common root.
Which isn't even a requirement. Alternate root providers
At 10:51 AM +0200 6/11/09, Lars Eggert wrote:
Content-Type: multipart/signed; boundary=Apple-Mail-5-115115602;
micalg=sha1; protocol=application/pkcs7-signature
I agree with Sam and Jari. This is a good and overdue change.
Lars
I also agree with this proposal, based on several experiences
Joe,
Having served on NOMCOM more than once, and having been solicited for
inputs every year, I much prefer publishing the names of folks have
consented to be considered for IAB and IESG positions. The addition
of ringers to lists that are sent out (to hide the identities of
the true
Phil,
The examples you give about backed-in trust anchors are valid, but
they point to decisions by vendors to simplify their designs at the
cost of secruity and functionality. I've been told that it is very
hard, if not impossible, to permanently remove some vendor-supplied
TAs in a popular
Joe,
You have argued that DNSSEC is not viable because it requires that
everyone adopt IANA as the common root. I agree that under the
current IANA management situation many folks may be uncomfortable
with IANA as the root. However, in practice, the world has lived
with IANA as the root
At 7:06 PM -0800 2/20/09, Dave CROCKER wrote:
Stephen Kent wrote:
At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote:
Just as a matter of observation, ...
...
I have not read the doc in
question,...
Hey guys. As someone who is frequently faced with trying to parse
out what
At 9:00 PM -0800 2/19/09, Hallam-Baker, Phillip wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary=_=_NextPart_001_01C99318.3582B8D8
Just as a matter of observation, there is not and never has been a
security requirement to rigidly
Alex,
The conclusion I draw from this experience differs from yours. If the
individuals who sent the messages in question choose to become
involved constructively, then there can be some benefit. But, the act
of sending the messages in question has generated ill will, so it was
a bad way to
; in light of
all
this I'm going to have to rethink that decision. For a server, the
combination of enabling ipv6 and using this particular anti-spam technique
may drastically increase the number of false positives -- especially as ipv6
gets more widely deployed.
Best Regards
Kent
, and in my experience, most
people would rather deal with some spam than lose important email.
Kent
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
be a whole
lot of boxes in this situation.
Kent
PS -- I'm not sure this will actually make it to the ietf list :-) ...
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Chad,
Your message of 4/8 ended with a list of changes needed to IPv6
implementations to implement RNET. Changes to processing logic are
just as serious as change to the format.
Steve
---
The following changes need be made to the IP Version 6 Protocol Logic, in
routers, in order to
Mike,
I have to disagree with your characterization of the proper role of
the IAB with regard to the NOMCOM process.
I have been on three NOMCOMs, including the one prior to this, so I
too have some experience in the process.
My feeling is that the IAB may have been trying to assert too
that, we could also do away with the entire next line
debate by prohibiting even CRLF and requiring the use of LS
LS would be a bad idea. See my other email (sent at approx. the
same time as this one). You would get (to you) unexpected effects
from bidi processing.
/Kent Karlsson
to
beginning of line). If it were not for that, I would agree
that VT is not very interesting (though it does provide for
a hack to distinguish line separation from paragraph separation
by ignoring the tabulation aspect of VT, also for pure 8-bit
character encodings).
/Kent Karlsson
At 6:00 PM -0600 1/11/08, Nicolas Williams wrote:
...
Finally, multi-user systems may need to authenticate individual users to
other entities, in which case IPsec is inapplicable[*]. (I cannot find
a mention of this in the I-D, not after a quick skim.)
[*] At least to my reading of RFC4301,
At 2:06 PM -0600 1/14/08, Nicolas Williams wrote:
...
Ipsec does support
^
You're slipping :) :)
oh my!
per-user authentication if protocol ID and port pairs can be used to
distinguish the
on page 4) for NFC in Net-UTF-8 applies.
The reciever cannot be sure that NFC has been applied. Nor can it be
sure that conversion of all line endings to CR+LF (there-by loosing
information about their differences) has been applied.
/kent k
___
Ietf
.
/kent k
This interpretation was also, I believe,
incorporated by Jon Postel in the rules for NVT and for RFC
formatting.
I can't believe I am reopening this old topic... ;-(
Bob Braden
___
Ietf mailing list
Ietf@ietf.org
https://www1
Comment on draft-klensin-net-utf8-07.txt:
--
Network Virtual Terminal (NVT) occurs first in Appendix A.
The explanation of the abbreviation should (also) be given at
the first occurence of NVT in the document.
--
Section 2, point 2,
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
At 7:34 PM +0100 12/4/07, Martin Rex wrote:
The document
- 'Memorandum for multi-domain Public Key Infrastructure
Interoperability'
draft-shimaoka-multidomain-pki-11.txt as an Informational RFC
creates the impression that trust anchors must always be
self-signed CA certificates.
Sam Hartman identified an issue with one name type (URI) that may
appear in the Subject/Issuer alternative names, when applying the
Name Constrains extension to such names. The issue arises when the
URI does not contain an authority component (a host name in a DNS
name or e-mail address),
Joe,
This discussion seems to have moved from a discussion of crypto use
on home/office computers, to use in routers. There is no good
motivation for other than edge (CPE?) routers to make use of IPsec
for subscriber traffic. We know, from discussions with operators,
that use of IPsec to
Joe,
I disagree with your suggestion The software performance of security
protocols has been the more substantial issue, and is likely to
continue to be for the forseeable future.
I suspect that most desktop users do not need hardware crypto for
performance. Irarely if ever drive my GiGE
At 11:23 AM -0700 8/23/07, Hallam-Baker, Phillip wrote:
If we can meet the needs of 80% of Internet users with some form of
shared access there will be more addresses left for the 20% with
greater needs.
I suspect that the actual percentages are more like 95% and 5%.
My Internet use is
Henning,
Some WGs issue Informational RFCs that represent WG consensus, but
which are not viewed as suitable Standards track documents, for
various reasons. For example, RFC 3647 is one of the most widely
cited of the PKIX RFCs, yet it is Informational because its a policy
and procedures
At 9:32 AM -0400 8/9/07, David Harrington wrote:
Hi,
The issue was raised during ISMS WGLC that there is a difference
between our use of the word authenticate and the glossary in RFC2828.
Since ISMS extends SNMPv3, ISMS is using terminology consistent with
the SNMPv3 standard, which reflects
At 6:35 AM -0700 8/9/07, Bill Manning wrote:
...
The RIRs are working to enable clean transfer of address space
holdings, using X.509 certs. While one could do what what Harald
suggested, the new address space holder would have to worry about HP
revoking the cert it issued to effect the
At 9:03 AM -0700 8/9/07, Bill Manning wrote:
...
The RIRs are recognized as neutral, primary address space allocators
who have contractual relationships with the folks to whom they
allocate addresses. I think it might be more attractive to the new
holder of address space to have a
At 11:40 AM -0700 8/9/07, Bill Manning wrote:
O...
ICANN is also a legal entity, with the same vulnerabilities
as all other companies including RIR's... which was my point.
Special is reserved for governments... :)
The U.S. Dept. of Commerce recognizes ICANN
At 4:36 PM +0200 8/8/07, Iljitsch van Beijnum wrote:
On 8-aug-2007, at 12:07, Harald Alvestrand wrote:
Routing certificates are simple. If HP sells (lends, leases,
gifts, insert-favourite-transaction-type-here) address space to
someone, HP issues a certificate (or set of certificates) saying
At 10:54 AM +0900 7/10/07, Masataka Ohta wrote:
...
Stephen Kent wrote:
The notion of CA compromise and ISP comprise are not completely
comparable, which makes your comparison suspect.
As I already mentioned, social attacks on employees of CAs and
ISPs are equally easy and readily
At 1:13 PM -0700 7/10/07, Douglas Otis wrote:
On Jul 8, 2007, at 10:34 PM, Eliot Lear wrote:
This can be said of any technology that is poorly managed.
So, you merely believe that the infrastructure of PKI is well managed.
In all but a single instance I have no evidence to the contrary.
At 6:36 PM +0900 7/7/07, Masataka Ohta wrote:
Keith Moore wrote:
Also from the draft:
At least for the strong security requirement of BCP 61 [RFC3365], the
Security Area, with the support of the IESG, has insisted that all
specifications include at least one mandatory-to-implement strong
At 12:29 AM -0700 6/13/07, Lakshminath Dondeti wrote:
Folks,
One person has voiced concerns on my taking a strong public
position in the Should I* opinions be afforded a special status?
thread while serving as the chair of the 2007-8 nomcom. Perhaps
there are others with similar concerns.
On Wed, Apr 11, 2007 at 01:54:53PM +0200, Brian E Carpenter wrote:
Ted,
Well, if IPR owners don't actually care, why are they asking people to
send a postcard? It would seem to be an unnecessary administrative
burden for the IPR owners, yes?
My assumption is that they care if the party
-drive, cli client I wrote and it doesn't
retransmit at all (perhaps not the best UI experience). I'll check with
the other implementers to see what they did. But you are right, guidance
needs to be given, especially if these things get embedded into automated
scripts.
s/if/when/
--
Kent
Russ,
I concur with Pasi's observations. I don't recall seeing a similar
structure in an RFC, where a part is informative, in what is
otherwise a standards track document.
Steve
___
Ietf mailing list
Ietf@ietf.org
At 10:16 AM -0400 5/18/06, Russ Housley wrote:
I received this note from Angelos Keromytis regarding the
draft-housley-tls-authz-extns document. I plan to accommodate this
request unless someone raises an objection.
Russ
OK, I'll object :-).
KeyNote has no IETF status, to the best of my
to believe themselves smart.
Would that things were so simple.
--
Kent Crispin
[EMAIL PROTECTED]p: +1 310 823 9358 f: +1 310 823 8649
[EMAIL PROTECTED] SIP: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman
case.
Kent
--
Kent Crispin
[EMAIL PROTECTED]p: +1 310 823 9358 f: +1 310 823 8649
[EMAIL PROTECTED] SIP: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
currently
available.
The clearest methods currently available might include visio diagrams or
powerpoint slides -- at least according to some people.
--
Kent Crispin
[EMAIL PROTECTED]p: +1 310 823 9358 f: +1 310 823 8649
[EMAIL PROTECTED] SIP: [EMAIL PROTECTED
it happen many times.
--
Kent Crispin
[EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
system than just human sentiment. There
is heavy duty infrastructure, both human and physical, involved.
--
Kent Crispin
[EMAIL PROTECTED]p: +1 310 823 9358 f: +1 310 823 8649
[EMAIL PROTECTED] SIP: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf
At 3:08 PM -0700 8/11/05, Ned Freed wrote:
I thought that what Russ asked for was not a threat analysis for
DKIM, but a threat analysis for Internet e-mail, the system that DKIM
proposes to protect. The idea is that only if we start with a
characterization of how and why we believe adversaries
Folks,
I thought that what Russ asked for was not a threat analysis for
DKIM, but a threat analysis for Internet e-mail, the system that DKIM
proposes to protect. The idea is that only if we start with a
characterization of how and why we believe adversaries attack e-mail,
can we evaluate
Dave Michael,
In the DoD environment, a threat analysis for a system identifies the
classes of adversaries that the author believes are of concern, and
describes their capabilities and motivations. Russ's three questions
are a concise way of stating this:
- The bad actors are
Phil,
...
Boy are you in for a shock when you try to connect to an ethernet with
802.1x.
I have yet to do so. I do have the facility on my Mac, but I've never
had to turn it on.
Authentication is being built into the NIC cards. At some point in the
future it will not be possible for any
Phil,
layered defenses are a good notion, but mostly when the layers are
under the same administrative control. all too often people forget
that relying on the security provided by someone else is a risky
proposition, as in your example of ISPs providing ingress filtering.
I would
At 2:35 PM -0700 7/19/05, Hallam-Baker, Phillip wrote:
Host and application security are not the job of the network.
They are the job of the network interfaces. The gateway between a
network and the internetwork should be closely controlled and guarded.
Nobody is really proposing embedding
Yakov,
Ultimately the marketplace will decide, but when a WG provides
multiple solutions to the same problem it has the potential to
confuse the marketplace, retard adoption of any solution, interfere
with interoperability, etc.
Standards ought to avoid confusion, not contribute to it.
of this thread is vacuous.
--
Kent Crispin
[EMAIL PROTECTED]p: +1 310 823 9358 f: +1 310 823 8649
[EMAIL PROTECTED] SIP: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Harald,
You are right that the scheme I proposed inn 1422 did not succeed,
and today I would not suggest it. But, the reason I would not suggest
it today is because I have come to believe that one should adopt CAs
that are authoritative for the certs they issue, not trusted third
parties. The
Thius is a note for all of the folks who flew on UA 893 on Friday,
2/27, with the unexpected 24 hour delay via Seattle.
I just got off the phone with UA Customer Service (not Mileage Plus).
They offered a 5K mile good will compensation for our
inconvenience. These miles will not count toward
At 12:40 -0500 3/5/04, John C Klensin wrote:
--On Friday, March 05, 2004 11:26 -0500 Stephen Kent
[EMAIL PROTECTED] wrote:
Thius is a note for all of the folks who flew on UA 893 on
Friday, 2/27, with the unexpected 24 hour delay via Seattle.
I just got off the phone with UA Customer Service
.
ESP is not generaly run over TCP.
RFC 2402 describes the use of ESP.
Steve Kent
author of 2401, 2402, 2406, ...
-dresden.de/1.php
http://www.micronuke.net/1.php
http://www.stadthagen.org/1.php
etc
--
Kent Crispin
[EMAIL PROTECTED]p: +1 310 823 9358 f: +1 310 823 8649
[EMAIL PROTECTED] SIP: [EMAIL PROTECTED]
At 11:34 -0500 12/30/03, Ken Hornstein wrote:
From my reading of the Korean Embassy web page, it seems that US residents
will require a visa to attend the Seoul IETF. I'm wondering if anyone
has gotten a visa to enter South Korea before, and if so, can they provide
any tips on the visa process?
be lost in the
normal noise of ietf processes.
Regards
Kent
On Dec 18, 2003, at 3:01 PM, Vernon Schryver wrote:
1. on-topic messages from subscribers
2. on-topic messages from non-subscribers
3. noise from subscribers
4. noise from non-subscribers
5. pure spam such as advertisements
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
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
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
On Fri, Dec 12, 2003 at 06:23:48AM +0100, Anthony G. Atkielski wrote:
But since ISOC's firewalls have not been updated, you won't be able to
get to their site from Linux.
Nonsense. I'm running Linux, several versions. I can get to the ISOC
site from all of them.
--
Kent Crispin
At 8:39 -0800 12/12/03, Tony Hain wrote:
vinton g. cerf wrote:
...
Unfortunately, the discussion has tended to center on ICANN as the only
really visible example of an organization attempting to develop policy
(which is being treated as synonymous with governance
To further your point, an area
1 - 100 of 140 matches
Mail list logo
