Re: [ca-tf] Certification Proposal

["Ruediger Volk, Deutsche Telekom T-Com - TE141-P1" rv@localhost]

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@localhost