[address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call

Malcolm wrote:
> I am afraid I don't believe this policy should be adopted at this time.

I agree with that.

> This is not a minor, administrative policy. It is (even if not intended
> as such) the first step in a process the end result of which would be a
> major change to the Internet architecture. I am afraid that the ultimate
> outcome could be that the Internet becomes more fragile as a
> consequence. True, it's only the first step. But if it's a step in the
> wrong direction, let's not do it.

I'd like to add to the ones argueing that you are not forced to implement
a policy based on the rpki:
What point does this have if noone implements that? None, right, so
all arguing in favour of this policy are convinced that one will imlement
something based on that. So concider that:
Once a serious amount of ASes (and exspecially carriers) have implemented
policies based on RPKI, we will never get rid of that, at least not
easyly. Just look at how good IPv6 is beeing adapted and how good 
we are getting rid of v4.  ;)

So before we push that huge responsability that comes along with that
RPKI certificates (and especially with the power of revocation either 
by not renewing an expired certificate or by CRL  or something like that)
into the RIRs, we should double and tripple think wether we are 
really willing to do that and wether the RIRs are stable and resistable
enough to the political preassure that no matter will fall upon them
really soon after gouvernments (and lobby groups, ...) notice.

[stuff where I pretty much agree with Malcolm deleted]

> iii) Even if the problem is serious enough, whether alternative means to
> address it could be found that would mitigate these risks [2]. (For
> example, if the problem could be 80% solved using a model that does not
> give RIRs a power to revoke and expire certificates "needed" for
> routing, is the residual 20% of the problem really serious enough to
> warrant creating the risks I describe).

In order to respond to [2] here (and following a short discussion i had
with Geoff after his talk yesterday): as the ressources are given out 
by the by IANA and the RIRs and the LIRs, so introducing an hirarchial
approach that shadows the real assigning is a logical and the only
usefull approach IMO. In general, both approaches works poorly to say
the least and giving away the power to some "trusted third partys" get
us the mess we today have with traditional ssl certificates (where
we have a system that is seriously broken beyond all repair). However,
I'd like to take Randys point from his talk that the validatity of 
certificates should be long, but would even say that thay should not
be only two to five years, but instead at least 20 years and 
no possible revocation in order to protect the RIRs from being smashed 
by political preassure.

From the security point of view, lang validity times are indeed just
a question of chosing reasonable security parameters and there is a
good consenseous about that in the security and crypto research about
what that should be and these are (with a large safety margin) available
in various recommendadiots (for example by NIST[1]). 

[even more stuff from Malcolm where i generally agree deleted] 

regards,

Immo

[1] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf
    Page 66

I'd just keep Malcolms [2] here
> [2] For example, could we creates "webs of trust" rather than a single
> hierarchy? Would that be "good enough" or is a hierarchy essential?
> Could a PKI for address allocations work sufficiently well without
> investing the hierarchy with authority to revoke certificates? Should we
> consider an architecture with a distributed issuer/revoker, spread
> across multiple jurisdictions? What other models exist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20110503/8f78d9b1/attachment.sig>