[ca-tf] Certification Proposal

Dear all,

I am working on this internally at the moment and I will get back to  
you soon.
In the meanwhile if others have opinions on these points please let  
us know on the list :).

Thanks,
Filiz

On 17 Aug 2008, at 22:16, Ruediger Volk, Deutsche Telekom T-Com -  
TE141-P1 wrote:

> Dear Filiz, dear fellow task force members,
>
> this is my comment to Filiz message of July 24 with an updated
> draft policy proposal and comments on the concerns I raised in my
> previous message.
>
> I do not see my concerns resolved.
> If allocation status is not yet well defined for RIPE NCC
> resolving this has to be taken up as a very important issue.
> (While it's outside of the scope for discussing this policy proposal
> questions about activety plan, road map etc. have to be raised to  
> senior management and board.)
> Defining allocation status and all required rules for status changes
> certainly raises some challenges; it may take considerable time and  
> effort
> to do it right - and it MUST be done right.
> Thus it would be a bad idea to try to quickly "fix" allocation status
> as a small supporting act within the policy development for  
> introducing RPKI. However sweeping "allocation status" under the  
> rug and only
> referencing "membership status" as a substitute looks like actually
> doing exactly such a "quick fix" - in a worse way!
>
> BTW also Filiz's proposed language with "grace period" seems to me  
> like
> being quite unspecific and NOT providing clear rules for NCC staff
> to act on and for members to clearly understand what they have to  
> expect.
>
> Please find below my suggestion for policy elements that could be used
> to establish clear rules, avoiding to sweep "allocation status" under
> the rug, but reference what I hope to be clearly defined currently  
> available criteria (i.e. membership) to be used until process and
> policy to deal with withdrawal of allocations have been properly  
> defined.
>
> My suggestion:
>
> RIPE NCC member LIRs may request certificates for their PA space
> as allocated by the RIPE NCC. (+add other types of certificates...)
>
> Certificates will be issued with a validity period of NN months
> (e.g. consider 18 months - that would seem to clearly define a  
> sufficient
> grace period, but needs to be discussed in comparison to the defined
> schedule of the NCC business process).
> Certificates will be revoked (only) when allocation of the resource is
> returned or withdrawn (withdrawn - under policy/process to be defined
> properly on separate track!), on request of the resource holder  
> (e.g. to facilitate some kind of transfer), or for handling of  
> compromised security in context with reissuing certificates as needed.
>
> Renewal of certificates when membership is confirmed for a new year
> (by receipt of payment of membership fee).
> 	is renewal automatic? (if so, then do it after receipt of payment)
> 	or does renewal require explicit request?
> 	(if only on request, obviously payment status can be checked)
> Will renewals be done on request anytime?
>
>
> Further remarks:
>
> - Filiz comments that she wants to keep certificates as a SERVICES  
> policy;
> but in the form under 6. "Address Policy" is listed as the  
> suggested WG;
> I'd agree with "Services"
>
> - first sentence under "10. Policy text" mentions only certificates
> for PA address space (and "9. summary" similarly); this can be read as
> defining much more limited service than I was expecting.
> Please comment/clarify:
> 	Existing text remains silent on certificates for AS - is that
> 	intentional or do we fix it be explicit mentioning.
> 	(AS do NOT look critical or particularly interesting at this time.)
> 	A more interesting question is:
> 	is the policy considered to cover also provisioning of ROAs?
> 	That's actually the application that I consider of highest
> 	practical interest - and support of (only?) hosted provisioning
> 	of ROAs indeed seems to require specific language
> 	(hosted certificates for subdelegations might be another
> 	extra item)
>
> - I think it would be a good idea to actually mention RPKI and hint at
> the global context under "6. Summary"
>
> Let me also mention that my understanding of requirements for creating
> a technically and legally correct system there is a need for having
> Certificate Policy for the RPKI (open proposal: draft-ietf-sidr- 
> cp-03.txt)
> (global binding agreement!) and for the RIPE NCC as registry running
> an RPKI CA a Certificate Practices Statement (CPS - draft template see
> draft-ietf-sidr-cps-irs-03.txt); the later probably is not sufficient
> to cover hosted operation fully.
>
> Best regards,
>   Ruediger
>
>
> Ruediger Volk
>
> Deutsche Telekom AG -- Internet Backbone Engineering
>
> E-Mail:  rv at NIC.DTAG.DE