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 S
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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 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.
T
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 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 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: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 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
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: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
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
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
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
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
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 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
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 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
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 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 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 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
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
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 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 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.
Paul,
I object to the characterization of my comments as "propagating FUD."
One might equally well suggest that 2267 constitutes a naive model of
how to prevent IP spoofing, but I was polite enough not to say that
:-).
From a security perspective, it is never desirable to rely on a
mechanis
Paul,
>
>>When one suggests that a first tier ISP would not need to filter
>>traffic from down stream providers, because IF they do the filtering,
>>then the problem will not arise via those links, one is suggesting
>>precisely this sort of model.
>
>You're approaching this from the wrong perspec
Dan,
I'll suggest one course of action, but I keep emphasizing the issue
is not one of alternates, but of recognizing the limitations of
proposals now on the table and considering approaches that may work
irrespective of whether everyone performs filtering.
With regard to a wide range of DoS
Eliot,
Some of the DoS attacks we saw last week were good, old-fashioned SYN
floods. Hosts do have a responsibility here, more than ISPs, since
it is quite feasible to tie up a host's pool of TCBs with a small
number of packets, even if the attack tool does not use spoofed
sourced addresses
Steve,
The AT&T experiences might be different, but at GTE-I, a SYN flood
was the primary attack mechanism for one major web site that we host.
Also, it is not at all clear that our network had a problem handling
the other flooded traffic (ICMP Echo Reply and UDP traffic) that was
sent to 3 o
Keith,
Without comments on other aspects of the technology in question, I
would like to make some observations about the security aspects of
the processing you cite as violating IP.
By now we all should know that it is a bad idea to rely on an
unauthenticated IP address as a basis for determi
Keith,
Applications can gain a lot of security by building on top of a lower
layer secure communication substrate, such as that provided by IPsec
or TLS. Such substrates allow the application developer to make
assumptions about the security of the basic communication path, and
have these ass
Leslie,
I understand your point, but we leave ourselves open to many forms of
attacks, or errors, by assuming that "what you receive is what was
sent" in this era of the Internet. Security is not black and white,
but the gray area we're discussing does bother me. If one cares
about knowing
In my 20+ years of security experience in the Internet community, it
has often been the arguments for the need to make do with existing
features or to adopt quick fix solutions that have retarded the
deployment of better security technology. In retrospect, this
approach has not served us well
Keith,
>Stephen,
>
>perhaps the reason that the tools are not used is that they are not
>adequate for the task. but it certainly does not follow that "if
>one doesn't use the tools, then one does not care very much".
or perhaps, one does not care enough ...
Steve
Paul,
>I have a time machine.
>
>I just went back 20 years in time, convinced everybody that it
>was always more important to implement proper security than to
>make do with existing features and quick fix solutions. Having
>thus changed the future, I went back forward in time.
>Guess what---th
Christian,
>Suppose, rhetorically, that we were to encrypt every IP packet using IPSEC.
>What happens if a box takes your packet and deliver it to the "wrong"
>address, for example to an ISP controlled cache? Well, the cache cannot do
>anything with it, except drop it to the floor. We are thus
Keith,
>
>or perhaps, that building tools that actually solve these problems
>as opposed to chipping away at the edges is (a) fundamentally difficult
>(b) requires many kinds of expertise, most of them scarce, (c) has
>been frustrated by governments and patent holders who were bent
>on trying to c
Adrian,
>Just to confirm that I too have problems with the standard which I'm
>prepared to express at some length.
>
>Technically, it'll sure it'll fly but I'm really, really worried
>about the evidential rigour. Ultimately, the TSA will have to
>testify in a court and it has got to work - for
I want to second Bob Braden's pithy observation re I-Ds. If they
make it through the process and become RFCs (including informational
RFCs) then they clearly merit retention and they achieve it, since
RFcs are archival. However, many I-Ds do not make it through the
process and to archive them
Pete,
>Stephen Kent wrote:
> >
> > I want to second Bob Braden's pithy observation re I-Ds. If they
> > make it through the process and become RFCs (including informational
> > RFCs) then they clearly merit retention and they achieve it, since
> > RF
Tim,
The April fool's day RFCs aside, I agree that not all I-Ds that fail
to make the cut as an RFC are inferior. However, there are many other
venues for publishing technical material, many of which subject the
material to review. An I-D that contains good material but fails to
become an RFC
For a number of years I have joking referred to VPNs without
encryption as "virtually private networks" as opposed to "virtual
private networks," to emphasize the difference. But, I agree, the
historical use of the acronym VPN did not imply crypto security, just
"private" management.
Steve
As someone who was around when the notion of an I-D was created, let
me disagree somewhat. There was a very definite intent to cause I-Ds
to "officially" disappear after a limited time frame.
Steve
Ed,
>
>
>Perhaps we agree that DNS names depend on IP numbers as part of their trusted
>context, but IP numbers do not depend on DNS names.
>
>However, certain design choices in the evolution of the DNS,
>since long ago, have made users fully dependent on the DNS for
>certain critical Internet se
>The IETF may be still alive, but, what does it accomplish ?
>
>As an example, the infiniband Trade Association will be likely
>better suited to handle protocol developments.
>http://www.infinibandta.org
>
>
>Jim Fleming
>http://www.RepliGate.net
>
If you feel that the IETF is irrelevant, please
At 1:15 PM -0400 6/12/02, Keith Moore wrote:
> > > I don't want to discount the importance of cert discovery, but I do
>> > think it's a stretch to believe that you're going to be willing to trust
>> > all of the certs that you discover in a chain of significant length, for
>> > a significant
At 10:42 PM -0700 6/12/02, Einar Stefferud wrote:
>May I suggest that someone do a little work on proving the trust is
>transitive, as that is what this is really all about, and if it
>turns out that trust in not transitive, then what was the point?
>
>Maybe if you ask Google about trust transit
At 12:51 PM -0700 6/13/02, Christian Huitema 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 somethi
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
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 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
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
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
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
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
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
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
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: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
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: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
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
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
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 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 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
...
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 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
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 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
extens
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
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
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 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
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 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 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 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 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
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
1 - 100 of 124 matches
Mail list logo
