On Mon, 28 Nov 2005, Randy Bush wrote:
proof of identity
S(withRIRkey, AS_A_key, AS_A)
or
S(withwebofttrustkeys, AS_A_key, AS_A)
maybe Randy is saying this is two steps, not an OR
S(withRIRkey, someNonRIRidentity, asA)
Good idea. And this someNonRIRidentity may actually be
On 24 nov 2005, at 03.54, George Michaelson wrote:
If you want to see member-certificates which gate access to RIR/NIR
specific services common across all registries, I think you want to
get
that onto an RIR meeting agenda Randy.
We currently have no cross-certification activity in member
On 25 nov 2005, at 02.07, Sean Donelan wrote:
Although techincal folks may think its just about math,
unfortunately some
people think certificates and signatures mean more than just
mathmatical
formulas. I'm a bit confused why people think network service
providers
will be willing to
the rir attests to the delegation of the prefix and an asn to the
identified isp.
the isp signs, using their isp identity to
o originating from the asn
o originating that prefix (in sbgp, toward another isp)
Looks to me like:
proof of allocation:
S(withRIRkey, Prefix_p_key, prefix_p)
On Wed, 23 Nov 2005, Steven M. Bellovin wrote:
I think the problem is both easier and harder than painted. First, you
need a business agreement that you will accept each others' assertions
of member identities, aka certificates. Second, you have to agree on a
common format and meaning for
On Nov 22, 2005, at 2:59 PM, Randy Bush wrote:
[ you know all this, but i think it is worth going through the
exercise ]
That said, I think the problem is that we need an algebra of trust
that will let a program, not a human, decide whether or not to
trust a
certficate. You don't
not exactly. there are two trusts here. i have to accept that
asns as incompetent at configuration as i are attesting to prefixes
and paths or i won't be able to get to a large part of the net.
but this is orthogonal to my trust in their competence to attest to
the identity of other asns
On Nov 23, 2005, at 11:09 AM, Randy Bush wrote:
not exactly. there are two trusts here. i have to accept that
asns as incompetent at configuration as i are attesting to prefixes
and paths or i won't be able to get to a large part of the net.
but this is orthogonal to my trust in their
My issue is that if ISPs a) only announce networks that they know
(for different values of know - but hopefully based on some kind of
trust in the RIR's data) they are authorized to announce, and b) took
responsibility for the behavior of the paths or prefixes they
announce, and the
Rodney Joffe wrote:
As another thought: - Love 'em or hate 'em, the PSTN doesn't have this
problem.
Uh, PSTN does have this problem too. If you are part of SS7 you can totally
fake call origination information. This has been and still is abused for
criminal-malicous activities and
in operation, this means that there could be isp- (or ufo-)centric
isp identity certification (a la web of trust, for example) which
could have a very separate cert chain from that of address space
allocation, which, aside from the legacy issue, could come via the
rirs.
So when one receives an
My issue is that if ISPs a) only announce networks that they know
(for different values of know - but hopefully based on some kind of
trust in the RIR's data) they are authorized to announce, and b) took
responsibility for the behavior of the paths or prefixes they
announce, and the bits that
So when one receives an update, which part is it that you verify with
the certificate derived from the RIR chain and which part is it that you
verify with the certificate derived from the web-of-trust? I'm guessing
the answer in part is that there's a signature attesting to the
prefix
According to what I understand, there have to be two certificates per
entity:
one is the CA-bit enabled certificate, used to sign subsidiary
certificates about resources being given to other people to use.
the other is a self-signed NON-CA certificate, used to sign
In message [EMAIL PROTECTED], George Michaelson writes
:
According to what I understand, there have to be two certificates per
entity:
one is the CA-bit enabled certificate, used to sign subsidiary
certificates about resources being given to other people to use.
the other
On Thu, 24 Nov 2005, George Michaelson wrote:
According to what I understand, there have to be two certificates per
entity:
one is the CA-bit enabled certificate, used to sign subsidiary
certificates about resources being given to other people to use.
the other is a
On Wed, 23 Nov 2005 17:54:44 -0800 (PST)
william(at)elan.net [EMAIL PROTECTED] wrote:
On Thu, 24 Nov 2005, George Michaelson wrote:
According to what I understand, there have to be two certificates
per entity:
one is the CA-bit enabled certificate, used to sign
subsidiary
According to what I understand, there have to be two certificates per
entity:
one is the CA-bit enabled certificate, used to sign subsidiary
certificates about resources being given to other people to use.
the other is a self-signed NON-CA certificate, used to sign
On Wed, 23 Nov 2005 16:03:35 -1000
Randy Bush [EMAIL PROTECTED] wrote:
According to what I understand, there have to be two certificates
per entity:
one is the CA-bit enabled certificate, used to sign
subsidiary certificates about resources being given to other people
to use.
[0] - i'll want the business cert to have the ca bit if i am
large enough to have internal authorization process, and
thus want to create and manage different certs for dns,
billing, ...
We are discussing how we can do subsidiary certificate services like
this in APNIC
On Wed, 23 Nov 2005 16:39:11 -1000
Randy Bush [EMAIL PROTECTED] wrote:
[0] - i'll want the business cert to have the ca bit if i am
large enough to have internal authorization process, and
thus want to create and manage different certs for dns,
billing, ...
We are
We are discussing how we can do subsidiary certificate services like
this in APNIC but I think this goes outside of routing policy and
into registry business practices which are unlikely to be common
for all RIR and NIR in the ways that resource certificates *have*
to be.
if it is not
In message [EMAIL PROTECTED], George Michaelson writes
:
On Wed, 23 Nov 2005 17:54:44 -0800 (PST)
william(at)elan.net [EMAIL PROTECTED] wrote:
On Thu, 24 Nov 2005, George Michaelson wrote:
According to what I understand, there have to be two certificates
per entity:
one is the
In message [EMAIL PROTECTED], Randy Bush writes:
We are discussing how we can do subsidiary certificate services like
this in APNIC but I think this goes outside of routing policy and
into registry business practices which are unlikely to be common
for all RIR and NIR in the ways that
We need prefix ownership certs; these need a special field identifying the
prefix owned. (See RFC 3779, which also describes AS certificates). We
need the latter in CA form, for delegation.
sorry to complicate, by iana allocates as ranges which are then
subbed to rirs. so the ca bit could
On Wed, 23 Nov 2005 17:42:21 -1000
Randy Bush [EMAIL PROTECTED] wrote:
We need prefix ownership certs; these need a special field
identifying the prefix owned. (See RFC 3779, which also describes
AS certificates). We need the latter in CA form, for delegation.
yes. the resource certs we
In message [EMAIL PROTECTED], Randy Bush writes:
We need prefix ownership certs; these need a special field identifying the
prefix owned. (See RFC 3779, which also describes AS certificates). We
need the latter in CA form, for delegation.
sorry to complicate, by iana allocates as ranges
Hierarchical relationships breed reptiles because of the inherent
asymmetric business relationship that results.
...
Frankly, I am quite impressed with the address registries.
How would you feel about having the registries serve as the root of
a hierarchical certificate system?
So an
I believe a web of trust can be operationally feasible only if the web
is more like a forest - if there are several well known examples of
tops to the web. Otherwise, you have to be storing a plethora of
different signers' certificates to be able to validate all the
institution's
In message [EMAIL PROTECTED], Randy Bush writes:
I believe a web of trust can be operationally feasible only if the web
is more like a forest - if there are several well known examples of
tops to the web. Otherwise, you have to be storing a plethora of
different signers' certificates to be
Otherwise, you have to be storing a plethora of
different signers' certificates to be able to validate all the
institution's certificates that come in.
you need those certs to verify the live data anyway
Yes, the reason why you want to validate the institution's certificates
is so you can
I believe a web of trust can be operationally feasible only if the web
is more like a forest - if there are several well known examples of
tops to the web. Otherwise, you have to be storing a plethora of
different signers' certificates to be able to validate all the
institution's
In message [EMAIL PROTECTED], Randy Bush writes:
I believe a web of trust can be operationally feasible only if the web
is more like a forest - if there are several well known examples of
tops to the web. Otherwise, you have to be storing a plethora of
different signers' certificates to be
[ you know all this, but i think it is worth going through the
exercise ]
That said, I think the problem is that we need an algebra of trust
that will let a program, not a human, decide whether or not to trust a
certficate. You don't want to accept something if it's a twisty loop
of
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Steven M. Bellovin
Sent: Tuesday, November 22, 2005 12:54 PM
To: Randy Bush
Cc: [EMAIL PROTECTED]
Subject: Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
..
Furthermore, given
Randy:
for how many years have i been asking you and your evil-minded cert
designing friends for a pgp-like web of trust cert that could be
used for just this application?
Steven B:
of subsidiaries or allied evil ASs vouching for each other. OTOH,
there are some situations where we
On Tue, 22 Nov 2005, Bora Akyol wrote:
Furthermore, given that a trust algebra may yield a trust
value, rather than a simple 0/1, is it reasonable to use that
assessment as a BGP preference selector? That would tie the
security very deeply -- too deeply? -- into BGP's guts.
If you take the
On Tue, 22 Nov 2005, Randy Bush wrote:
[ before you say it, i have suggested that a pseudo-rir be created
for legacy asns and prefixes ]
I also seem to remember Bill Woodcock suggesting this at some ARIN
meeting in 2001 or 2002. If I recall he proposed that this be somewhat
like a
On Tue, 22 Nov 2005, william(at)elan.net wrote:
I also seem to remember Bill Woodcock suggesting this at some ARIN
meeting in 2001 or 2002. If I recall he proposed that this be somewhat
like a document trust with no operations (beyond providing NS service)
and when
the idea is that the *end-user* is supposed to know what's legit
and what isn't.
no. all asn admins, including tier 1 through tier 42 and leaf
asns.
users are not involved in routing, except of course when the
ivtf is desperate to shim up v6.
randy
On Tue, 22 Nov 2005, Randy Bush wrote:
the idea is that the *end-user* is supposed to know what's legit
and what isn't.
no. all asn admins, including tier 1 through tier 42 and leaf
asns.
Bah. Forgive my stupidity, please. We got into the discussion of PKI and
PGP-style trust models
Oh, I am quite aware of the BGP RP-Sec work and many people have heard
my opinion on this topic, including some on this mailing list. But I'll
re-iterate.
Hierarchical relationships breed reptiles because of the inherent
asymmetric business relationship that results. The leaves *must* do
42 matches
Mail list logo
