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
> 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)
i.e. the rir attests that the entity whose identity is externally
certified has been issued
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 "ce
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 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 fo
>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)
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 r
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 c
> 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 coul
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 th
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 en
>>> 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.
>>
>
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, ...
>> [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
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
>
> 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 sig
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
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 s
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.
>
>
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
> 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 o
>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 tha
>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
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 'billin
> 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
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 compe
>> 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
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 want
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 m
> 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, 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 so
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 document
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
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
> -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 (w
[ 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 su
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' c
>>> 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
>>> institut
>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 c
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' certifi
> 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 cert
>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 inst
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
busi
43 matches
Mail list logo