|
|
 |
Re: [ca-tf] Certification Proposal
-
To: Filiz Yilmaz filiz@localhost
-
From: Robert Kisteleki robert@localhost
-
Date: Mon, 07 Jul 2008 11:22:57 +0200
-
Organization: RIPE NCC
Hi,
Please allow me to propose a few enhancements:
10. Policy text New
The RIPE NCC issues certificates upon request.
The requester must be a RIPE NCC member LIR holding Provider Aggregatable
(PA) address space allocations.
This excludes other RIRs. It seems likely that they can ask for certificates
too - for resources that have been transferred to them from RIPE NCC.
When the RIPE NCC receives a certification request, they may ask for
further details to ensure that the requester is the legitimate holder of
the resource.
The certificate will be issued via a secure channel that the RIPE NCC
maintains for its members (at the time of this proposal this is LIR
Portal).
I suggest we say "including, but not limited to, the LIR Portal." The reason
is that the draft IETF standards include another method (see SIDR
"provisioning protocol"), which will be the "official" protocol for
retrieving certificates form an IR. Actually, that is going to be the only
standard method - everything else is region-specific.
Maintenance and renewal of certificates will be tied to membership status
of the LIR. In cases of continuing non-payment, cessation of membership
and/or closing of the LIR, existing certificates will be revoked by the
RIPE NCC.
"revoked and/or not renewed" is a bit more general. Most of the time it's
enough not to issue new certificates - the old ones will expire anyway.
The RIPE NCC will issue a resource certificate covering all PA
allocations held by the LIR at the time of the request. When there is a
change in the PA allocations held by the LIR, the RIPE NCC will ensure
that there is a single, up-to-date certificate reflecting the LIR's total
PA address holdings.
Note that on the longer run, LIRs will get the chance to ask for
certificates with only partial coverage. There can be a number of reasons
for this: preparation for key-rollover, splits and transfers too.
This leads me to the question: is the policy going to be updated later on,
as new services / enhancements are made, or is it better to add wording for
things we foresee already?
Cheers,
Robert
|
|
|
|
