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 para
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 op
David,
Major issue:
This draft contains more than just a threat model.
agreed.
It also contains
a high level security analysis of the security architecture/approach
that applies the RPKI to secure use of BGP.
yes. we didn't create a threat model doc for the RPKI, and this seemed
like a goo
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
The tech report cited in Eric's message is not a critique of the SIDR
algorithm agility
document that is the subject if this last call. The tech report is a
critique of the overall
SIDR repository system and object retrieval paradigm, with an emphasis
on the speed with which
relying parties (pri
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
st
The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'The RPKI/Router Protocol'
as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive co
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 consumer
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 th
At 7:48 AM -0400 5/4/11, Sam Hartman wrote:
>>>>> "Stephen" == Stephen Kent 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
At 6:07 PM -0400 5/3/11, Sam Hartman wrote:
>>>>> "Stephen" == Stephen Kent 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
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
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 t
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 abov
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 pa
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: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 that
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
extens
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
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 t
At 5:08 PM -0800 3/8/11, Eric Rescorla wrote:
On Tue, Mar 8, 2011 at 3:55 PM, Peter Gutmann
wrote:
Martin Rex writes:
Truncating HMACs and PRFs may have become first popular in the IETF within
IPSEC.
It wasn't any "may have become first popular", there was only room
for 96 bits
of MA
...
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.
Ste
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 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 that
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&#x
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, and
...
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 alg
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
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 wo
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 cr
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 s
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 Certico
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
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,
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 candi
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
At 10:41 AM +1000 6/11/09, Mark Andrews wrote:
In message , 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 just need
to get copy of the root
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 for
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 are
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 sepa
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 b
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 impl
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 muc
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 sess
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, th
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 li
At 7:34 PM +0100 12/4/07, Martin Rex wrote:
The document
- 'Memorandum for multi-domain Public Key Infrastructure
Interoperability'
> as an Informational RFC
creates the impression that "trust anchors" must always be
self-signed CA certificates.
What is a trust anchor MUST remain c
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), beca
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 pr
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 certai
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 doc
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 exclusiv
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 relation
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 tr
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 Eng
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 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.
T
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 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
secur
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
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
https://www1.ietf.org/mailman/lis
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 k
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 at
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 whe
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 adve
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 resta
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 d
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 s
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.
Stev
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
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 S
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 2:51 -0800 2/21/04, chintan sheth wrote:
Hi,
Is there anything called TCP over IPSec ESP? I believe
it should be IPSec ESP over TCP. Please clarify. Also,
point me to the relevant RFC #.
Thanks,
Chintan
TCP can be encapsulated by ESP.
The correct spelling for the protocol is IPsec, not IPSec.
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?
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
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
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 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 are
At 19:03 -0700 8/23/03, Karl Auerbach wrote:
On Sat, 23 Aug 2003, Dean Anderson wrote:
H.323 and ASN.1 eventually surpass ...
Ummm, based on my own direct experience with ASN.1 since the mid 1980's
(X.400, SNMP, CMIP...), I disagree.
It has been my experience that ASN.1, no matter which encoding
At 3:10 PM -0700 5/30/03, Einar Stefferud wrote:
Pity the poor Zealot; who, when he loses sight of his objective,
simply redoubles his efforts.
For sure, do not let any new ideas leak into the IETF!
Cheers...\Stef
Pity the poor fellow who ventures outside his realm of knowledge and
then recomme
At 1:36 AM -0700 5/29/03, Einar Stefferud wrote:
I suggest that those who wish to more fully understand all this
trust stuff might find it useful to look at http://mcg.org.br/.
Cheers...\Stef
I would recommend this web site only to folks who want to see a very
narrow view of what trust and cer
At 9:27 AM +1200 3/13/03, Franck Martin wrote:
I think the trouble with this attachment is that the whole e-mail is
encrypted "in clear" (anybody can decrypt) to save space when you send the
e-mail (SSL/TLS includes compression).
It's not encrypted, it's encoded in a form (base 64) that is unlikely
Mr. Baptista,
In reading your message re the history of security and the Internet I
my attention was drawn to the following paragraph:
DARPA planners unfortunately were short sighted and did not
anticipate the technology would become an international standard for
communications. The
At 11:58 AM -0400 6/25/02, Keith Moore wrote:
> > We seem to agree that the DNS could be sued to distribute certs, so
>> the question is what should the certs attest to and who should issue
>> them. I argue that we need certs that support validation of DNS
>> bindings, and that the only autho
At 5:25 PM -0700 6/20/02, Ed Gerck wrote:
>Stephen Kent wrote:
>
>> Your example does not require cross-certification. It only
>>requires that the relying parties be members of, or have access to
>>the (CA) credentials for, the communities to which the indi
At 11:03 AM -0500 6/18/02, Alex Audu wrote:
>Ed,
>
>You made some interesting points which leads me to wonder if
>we can define Trust in such a way that its parameters are verifiable,
>then we can verify that it is transitive. In other words, if Jon gets
>a dollar from Mike, and Jon can verify the
Stef,
>Hi Steve -- Now we are beginning to connect with the real meta issue.
>
>I am talking about "Trust Transitivity" in general.
>We agree that the DNS offers no trust functions, useful or otherwise.
>So, my focus is not on PKI as related to DNS, which is what you
>addressed here.
>
>It the f
At 11:30 AM -0700 6/14/02, Ed Gerck wrote:
>Stephen Kent wrote:
>
>>
>> Could you elaborate, perhaps privately, with why you believe a "true
>> PKI" needs multiple roots?
>>
>>
>> My view is that too many
>> folks have tried to get
At 2:05 PM -0400 6/14/02, John Stracke wrote:
> >In a system
>>like DNS which makes clear who is authoritative for which names, I
>>don't think the term "trust" is applicable, and that is the crux of
>>our disagreement.
>
>The problem is that, although the owner of the domain is authoritative
>fo
Stef,
>Thank You Steve for clarifying your simple little error and
>correcting the record on what I did or did not say. I admit that
>the error was small in commission but you must admit that it was
>huge in affect, so it is good for you to corrected the record.
>
>I will assume that it was n
Ed,
>Stephen Kent wrote:
>
>> Ed,
>>
>>
>> I think your sample CPS, while more than a little tongue in cheek, is
>> a good example of what a CA may assert. But, in the DNS context, many
>> of the issues you note are much less serious concerns th
At 11:30 PM -0700 6/13/02, Einar Stefferud wrote:
>[EMAIL PROTECTED] said:
>
>>On Fri, 14 Jun 2002 10:52:47 +1200, Franck Martin <[EMAIL PROTECTED]> said:
>>
>> > Ideally, we should rate each CA in our applications and the application
>> > should give us a level of risk...
>>>
>>>Hey.. it's the
Ed,
>Keith Moore wrote:
>
>> > A PKI modeled on the DNS would parallel
>> > the existing hierarchy and merely codify the relationships expressed
>> > by it in the form of public key certs.
>>
>> so what you're saying is that the cert would mean something like:
>
>;-) actually, to a lawyer, a
At 2:54 PM -0700 6/13/02, Einar Stefferud wrote:
>At 2:15 PM -0400 6/13/02, Stephen Kent wrote:
>
>[snip]... [snip]... [snip]... [snip]... [snip]... [snip]...
>[snip]... [snip]...
>>
>>You are the one who keeps saying that trust is transitive. I'm the
>>one s
At 2:47 PM -0400 6/13/02, Keith Moore wrote:
> > A modest, realistic ambition for a DNS-based PKI would be to improve
>> the security of the binding between DNS entries and the associated
>> machines
>
>yes, I think this is right. it eliminates some kinds of threats. but
>it still doesn't guar
At 3:32 PM -0400 6/13/02, Harald Koch wrote:
>Of all the gin joints in all the towns in all the world, Stephen Kent
>had to walk into mine and say:
>>
>> Why does everyone keep thinking that explicit trust is an essential
>> element of every PKI?
>
>If the reaso
1 - 100 of 124 matches
Mail list logo
