[ca-tf] CA-TF meeting minutes, 20 March 2008

[Daniel Karrenberg <daniel.karrenberg@localhost]

Hi all,

Please find attached a draft of the minutes for the Certification  
Task Force meeting held last week in Amsterdam.
Please note that I've prepended some of the key points with "***".

Regards,
Chris Buckridge
Technical Writer, RIPE NCC


-------------------------------------------


Certification Task Force Meeting Minutes, 20 March 2008
Location: Sheraton Hotel, Amsterdam


ATTENDEES: Paul Rendek, Axel Pawlik, Andrew De La Haye, Ronald van  
der Pol, Peter Tavenier, Tim Bruijnzels, Serge Beaumont, Filiz  
Yilmas, Nigel Titley, Andrei Robachevsky, Vasily Dolmatov, Ruediger  
Volk, Chris Buckridge (scribe)
Andrew de la Haye outlined the agenda for the day's meeting, and  
passed on Gert Doering's apologies.
INTRODUCTION
Andrew discussed the background and drivers of the current status of  
certification in the RIPE community. He also noted the various areas  
already identified by the Task Force as key to the project: Policy,  
Services, Technical, RIR-wide and Applications. He noted that recent  
discussions with RIR colleagues showed that the work being done by  
the RIPE CA-TF is valuable globally.
He then outlined the programme for today's meeting, including  
demonstrations of the progress made by the RIPE NCC and Xebia (a  
software consulting firm employed by the RIPE NCC to assist in the  
development of a certification system).
Daniel asked whether there were any other items the TF would like to  
have on the agenda. There were none.
Serge Beaumont, a consultant from Xebia, outlined his role in the  
technical development process, and laid out the basic processes of  
certification. He also discussed the fundamental bases of the project:
 - Certificates are representations of the true situation
 - Certificates are not pre-requisites for transfers or proof of  
holdership
 - The only thing that certificates can prove is that the RIPE NCC  
has made that statement!
Certificates can enhance the existing RIPE Database and its role.

Filiz Yilmaz gave an introduction to the policy issues raised by the  
certification proposal. This includes the proposed phased  
introduction of certification, first to PA address holders (RIPE NCC  
members), then PI and ASN holders, and finally ERX holders. Except  
for PA holders, all of these will be affected by policy proposal  
2007-01, which would provide clarity on who are the holders of PI or  
ERX space.
The initial proposal is for PA holders, or RIPE NCC members, and will  
entail a one-time operation to issue certificates to all existing  
LIRs. Filiz clarified that LIRs will receive certificates whether  
they want it or not, however the RIPE NCC will be signing the  
certificates.
There was discussion about how secure this arrangement would be, but  
Serge noted that as long as there is a secure channel between the  
RIPE NCC and the member, then the member can ask NCC to hold the  
private key securely for them; otherwise the member can hold the key  
themselves – it depends how much key management the member wants.  
Daniel Karrenberg expressed some reservations about creating and  
keeping private keys without the explicit consent of the members  
concerned, and noted that this would create a considerable   
responsibility and associated liability for the RIPE NCC should these  
keys be compromised or just appear to have been compromised.
Ruediger Volk noted that a certificate only has operational value  
when someone holds and uses the private key, and that there is  
therefore only a risk if someone gets hold of the private key.
Vasily Dolmatov noted that it is important to detail the procedures  
required in a resource certification system. He stressed that it is  
not an "organisation" that holds the private key, but a single  
person, and that there need to be security procedures to identify the  
authorised person. He also noted that if the authorised person  
resigns, it is important that there be a procedure to transfer  
authority.
Daniel noted that we envisage the authorisation process occurring  
through the LIR Portal, in line with the current operational  
practice, and that the LIR Portal deals with personal accounts, each  
one associated with an organisation, at least in theory.
He also noted that when dealing with transfers, the actions available  
to users of the LIR portal will have more serious consequences than  
the current actions available within the portal. The RIPE NCC senior  
management has identified this and the RIPE NCC is reviewing both the  
authorisation and authentication methods used in the LIR Portal; a  
possible extension of the authorisation model would be to offer sign- 
off by more than one individual for certain actions.
*** The key question to be decided is whether to do a mass generation  
of certificates for all members/resources or to simply supply  
certificates on-demand. Daniel strongly advocated on-demand and   
Vasily and Ruediger agreed that there may be a negative value to be  
issuing certificates and keys to those who do not want them or know  
what to do with them.
Ruediger also noted that if authorisation is to be checked via the  
LIR Portal, there will need to be a review of the security  
requirements of certification and ability of the LIR Portal to meet  
those requirements. Daniel suggested that authentication and  
authorisation in the LIR portal
be reviewed at the same time.

*** [Action item on the RIPE NCC?]

Vasily calirified that LIR Portal authorisation is done through the  
MNTNER object, and that this is an impersonal object. Daniel  
suggested that it might also be useful to look at imposing a minimum  
LIR authorisation level for those wishing to use certificates.
*** It was agreed that the policy should include specific reference  
to using the LIR Portal (or some other agreed-on mechanism), though  
it is important not to lock the system into a mechanism that may  
become obsolete.
There was discussion of whether non-payment would mean the revocation  
of the certificate, and whether it would this also mean the  
reclamation of the resources. Vasily suggested a holding period (say  
a year, two years) before the resources are reclaimed. Ruediger noted  
that we need to make the proposal acceptable to the entire community,  
and that, based on other RIR experiences, procedures for upholding  
resources, even in cases of dispute, seem to be a political  
necessity. He also noted that even if we don't examine this  
explicitly, the issue will probably still be identified by someone  
else, and it will be important to have a strong answer for it. Vasily  
suggested that it might also be possible to re-issue a different  
certificate stating "unpaid", but also noted that the concept of  
revocation has no strong support in PKI infrastructure.
Ruediger suggested that there are already situations of closing down  
members and cleaning up their resources; this may offer a model.  
Andrei Robachevsky suggested that we remove the reference to  
reclaiming addresses, as this has nothing to do with certification,  
but we could still revoke certificates, as this is a service which  
are no longer providing. Andrei also noted that if the member ceases  
to pay, we have no idea who the "member" is anymore.
Ruediger suggested that ceasing to pay membership does not  
necessarily change the "relationship" between the certificate holder  
and the issuer. Andrei noted that the there is an option to allow  
certificates expire if there is non-payment, which Vasily is happier  
with. Ruediger warned against placing responsibilities on members  
that require some technical expertise and a certain amount of work  
(that is, more than in the past). He noted that increasing the  
requirements for paricipation in the industry is likely to break good  
will.
Daniel noted that we need to distinguish between the business PKI and  
the resource PKI – the resource PKI doesn't identify people. Daniel  
also noted that resource PK, and in particular secure routing  
protocols, create a lot of fear in ISPs, because the current model of  
routing gives ISPs considerable freedom to (mis-)configure their  
routing policies, and once valid certificates and ROAs are required  
for routing to function, they see single points of failure in the  
RIRs and potential limitations to their current freedom of  
configuration that they do not like.
There was general agreement that single certificates for multiple  
resources is a good idea.
*** There was discussion on who will propose the policy. Nigel Titley  
noted that it would be better that it come from the member side  
(rather than from the NCC). It was generally agreed that the Task  
Force itself would bring the proposal forward.
AUTOMATIC PROVISIONING
Daniel outlined the white paper on automatic provisioning. He noted  
that a major selling point for this is that the RPKI is global  
whereas the current allocation databases are regional and require  
verification in each of them separately rather than one global system  
(though Ruediger noted that having a global system would not  
necessarily require PKI infrastructure, to which Daniel replied that  
in practice we never succeeded in making it happen).
Serge took the group through a specific scenario, and Tim Bruijnzels  
demonstrated the system. Serge noted the importance of making the  
export facility easy for LIRs.
Serge noted that for the purposes of the demonstration system, the  
first level (relationship with RIPE NCC) is fixed – when rolling out  
the full version there would be the facility for LIRs to do their own  
sub-delegation. Ruediger suggested that for the purposes of selling  
the system, we need to demonstrate the whole thing in some form,  
including the full recursive model. Serge noted that the system will  
eventually allow for all possibilities – LIRs can have full control,  
or hand over all control to the RIPE NCC, or any mid-point between  
those extremes. Ruediger noted that the proposal will have to spell  
out which parts of the functionality are in the business and schedule  
plan. The simple demo should not show all the complicated cases but  
it is important to spell out a road map – how precisely do the more  
complex examples map with the simple demo? Andrew agreed that if  
present a demo at the RIPE Meeting, it will be important to provide  
some context.
Serge noted that since it is a recursive model, and that anything put  
into place by the RIPE NCC could be used by lower level users as  
well. This is why we are focusing on a single level, and getting that  
right.
Ruediger noted that the NCC would have to make a statement about  
whether the developed software would be made available for use by  
third parties, and that solid protocols would have to be published.  
Some of the LIRs that might offer services like this may already be  
running commercial CAs, and in those cases it might be difficult to  
incorporate with the NCC model. He noted that it might be difficult  
to get budget for developing this if a different section of the  
company already has an alternative model.
Andrew noted that communication around this is a priority.

Vasily noted that there are large commercial enterprises that have  
already developed their own systems for PKI – will the RIPE NCC  
system accept third party certificates? Serge noted that this should  
be possible, but that most people will rely on RIPE NCC, not on their  
own PKI systems, so this is more valuable in terms of RIPE NCC  
business model.
There was some discussion on whether signing an ROA actually provides  
proof of holdership.
SECURE ROUTING
Daniel outlined the possibilities for secure routing. This provides a  
companion to automatic provisioning, allowing the AS holder to say,  
"yes, I will route this prefix". Is it worth developing this?
Ruediger thinks it is valuable to have this proposal on the table,  
but that rolling out the rich model for provisioning and getting the  
ERX data done is more important. The work in these areas may be done  
by different groups, however, so the comparison may not be relevant.
Vasily noted that an object taken from the database should be signed  
twice to ensure that it cannot be changed in transit.
Serge noted that actual secure BGP, of whatever flavour, is still a  
long way off. He noted, however, that a significant obstacle is the  
absence of a PKI infrastructure, and certification rollout would go  
some way toward fixing this.
Vasily noted that this would be purely optional, so there would not  
be any policy implications.
RESOURCE TRANSFER
Daniel gave an outline of this subject, noting that when the IPv4  
free pool runs out, there will probably emerge a market for IPv4 and  
there will need to be mechanisms available for transferring resources  
between parties. Ruediger noted that policy will be required for any  
transfers – this is already being looked at and will be discussed  
later in this meeting.
Serge outlined a scenario and Tim presented the demo. This includes  
"overlapping validity", in which there occurs a brief period, during  
a transfer, when two parties both have "holdership" of a resource.  
There was discussion of how this would be administered, including the  
possibility of extending the RFC3779 resource extension to include  
"in transition" information. Andrew noted, however, that there was  
little support for this in the IETF, as there is concern that it  
could take the foundation out from the whole thing.
Ruediger noted that the process might be a little confusing for those  
with many resources, and that it might be better to have the resource  
in transit held under a separate certificate.
Daniel suggested that the user interface allow for the ROAs be listed  
by prefix rather than AS (or at least have the option to search ROA  
by prefix).
Ruediger noted that the discussion seemed to focus on one authority  
doing the whole thing, which is fine for many cases, but when the  
situation includes hierarchical delegation, it will be more difficult  
to prevent conflicts, and tools to do this will be of a very high  
practical importance.
Vasily noted that the procedures for conflict resolution should be  
clearly spelled out, and that the existing white paper seems to be  
based on the notion that all parties will have good will (in a  
commercial situation, this may not be the case).
Ruediger suggested that the demo include a back-up slide that  
discusses how things would happen in the case of multiple CAs (say,  
Megacorp has been running its own CA, but Minicorp wants to be served  
by a different CA). Serge reiterated that they have been working on  
getting the one level right, and that the recursive model should  
allow for development of these multiple CA scenarios. Daniel noted  
that in the up-down protocol, all the primitive elements are in  
place. But he agreed that we should define the different levels of  
complexity – it may be easier to transfer resources that are unused,  
and advise on issues like this would be useful, perhaps defining  
"beginner" versus "expert" levels.
*** Paul Rendek emphasised the need for clarity in any "external"  
demonstration (such as RIPE 56), and suggested investigating the use  
of multimedia.
Andrew noted that it seems clear that resource transfers will be an  
important area; the Task Force agreed. Ruediger emphasised that we  
need to be following and mapping the possibilities as resource  
transfers emerge.
Filiz discussed the policy matters related to resource transfers. She  
noted that there are already policy discussions in various RIRs about  
transfers (not necessarily related to certification). In the RIPE  
region, proposal 2007-08 is already being discussed, and is shifting  
the idea of transfers from acquisitions to a resource market. It also  
mentions resources being "signed", thereby implying some sort of  
certification system.
There was agreement that the issue of left-over blocks fitting the  
minimum allocation size needs to be discussed/considered.
It was also agreed that non-permanent transfers be treated as sub- 
allocations, though Ruediger noted that there needs to be a mechanism  
for these to be reflected in the certificates, and the owner of the  
lease needs a means of creating ROAs.
Filiz noted that ARIN has a very detailed proposal for transfers,  
though it is not closely tied to certification development. They have  
a large number of rules, including that the recipient still needs to  
prove their need to ARIN.
Paul noted that it would be good to get a round-up of what the other  
RIR transfer proposals are, and how they might fit with certification  
deployment. Daniel noted that we need to do the mechanics such that  
they can implement any policy that they want to (especially those we  
see looming on the horizon) – we don't want to be in a position where  
we are making policy to match systems. He also noted that the  
discussion of these other RIR policies should be in the Address  
Policy WG, and that the ARIN policy seems far more elaborate than any  
of the other RIR policies.
Daniel argued that so far we have avoided the issue of inter-RIR  
transfers, even though inter-RIR transfer has been a major selling  
point of certification. Ruediger suggested that the inter-RIR thing  
is not a pressing problem, and the number of organisations who will  
deal with collecting allocations from all regions would seem to be  
small, and if the market gets so tight that everyone is forced to  
seek inter-region allocations then there will be other issues anyway.  
Daniel noted that Randy Bush is already saying that he doesn't like  
ARIN policies and may transfer his resources to the RIPE NCC – this  
is therefore a scenario that we will need to address.
Ruediger suggested that there is no reason for "inter-RIR" transfers  
– the RIR responsible for a given resource block will remain  
responsible that block. Serge pointed out that it has been suggested  
that RIRs be each others' "subs". Filiz noted that the problem of  
having five RIRs with five different policies – in the ARIN policy,  
it is also required that address space must be used in the ARIN  
region. Ruediger noted that we need to plan for a situation where any  
block (of minimum size) might be on the move.
*** Filiz will come up with a table comparing transfer policies in  
the different regions, for both the CA-TF and Address Policy WG. She  
also noted that for PI space, we need to wait and see the outcome of  
2007-01.
The policy may need to specify a period during which a resource is  
"locked" during transfer, and it may be important to specify this  
period. There is also the question of whether the entire allocation  
be locked, or only the block which is to be transferred. Serge noted  
that there is a case for locking the whole allocation (to prevent  
quick, multiple transfers that might result in a fragmented remaining  
block). Ruediger noted that unless you wish to place major  
restrictions on large address space holders, you have to only block  
the block being transferred. Tim also noted that there was already a  
discussion of respecting the /21 bit boundary for remainder blocks,  
removing that justification for locking the entire allocation.
Filiz noted that in 2007-08 there is a requirement that resources not  
be transferred again within 24 months.
There was discussion of whether the RIPE NCC would allowing transfer  
of AS Numbers – it was noted that under current scenarios, transfers  
could only be conducted between LIRs, but it is not only LIRs who  
have ASNs. Filiz suggested that at some point it will be important to  
discuss this, probably in the Address Policy WG.  Daniel noted that  
it might well be reasonable to tell anyone who wants to transfer an  
ASN that they must become an LIR (if only because they would have to  
become an LIR to get a certificate). Andrei noted that we have to  
allow such transfers, if only to support mergers and acquisitions.
Filiz noted that these policies will need to be proposed at some  
point, but this can be discussed in more detail at a later date.
Ruediger noted that once a certification system is in place, it might  
be worth encouraging a number of large ERX address holders to get  
certificates over their prefixes. This may involve considerable work  
for the RIPE NCC, so some planning should be done for this. Daniel  
agreed, noting that it might be necessary to bring on some extra  
resources to handle the avalanche of requests that may eventuate, and  
possibly to solicit ERX holders.
Ruediger noted that there is a case that can be made to ERX holders  
("you don't want what happened to YouTube to happen to you, you  
should get your resources certified"), but there needs to be a  
feasible short-term way for the RIPE NCC to handle the extra  
workload. Daniel noted that the RIPE NCC is a flexible organisation  
and would be able to accommodate this.
PUBLISHING ROAs AS RPSL OBJECTS
Daniel outlined the idea, which is to turn ROAs into RPSL objects and  
publish them in the RIPE Routing Registry. He stressed that Ruediger  
came up with this good idea.
There was general agreement that it was a good idea, and that it's  
important to have a distinctive source (this is specified in the  
white paper). There would need to be some infrastructure put in place  
for this though. The update would be done twice a day, or daily.
Serge asked whether being real-time would be an issue, or is only the  
longest time an issue (ie. can you be too fast?). Ruediger noted that  
this shouldn't be an issue, and that for the most part it would not  
be close to real-time.
There was gneral agreement that the information would typically be  
queried about once every 24h. Daniel suggested that this means it  
would be sufficient to update it about every 12h.
It was generally agreed that this is a good idea and should be done.


CLOSING
Andrew outlined the coming steps, particularly in relation to RIPE  
56. This would include readying a "pre-production" version (for  
allocated PA), and forming a closed user group for testing. It would  
also involve presentations and demos at the meeting, and getting the  
policy discussions started. The CA-TF will have a short meeting on  
the first day of the RIPE Meeting.
Andrew also noted that the goal is to launch the first production  
service at RIPE 57 (with associated fanfare).
There was discussion of priorities for the project. Nigel suggested  
shifting secure routing down the list, because as presented in the  
white paper, we don't seem to get much more than we are currently  
getting out of the RIPE Database, while resource transfers may become  
an issue much sooner than we expect. Ruediger noted that supporting  
transfers will mean tracking holdership, and that preparing for that  
is very important – he noted that doing the transfers before we have  
the provisioning processes doesn't make sense. Inserting the  
immediate update of the quality of the current routing information  
would make sense as a high priority (while secure routing in a rigid  
sense is a long way off, and the RIPE NCC would not necessarily do  
the technical development of this anyway!). The important thing is  
preparing the database so that we can use it should we need to.
A final list of priorities was agreed on:

 1. Provisioning
 2. Automated provisioning
 3. Transfer
 4. ROAs as RPSL objects
 5. Distributed model

Ruediger noted that there has been discussion of getting standards  
for CPs into the IETF, and that some support will be needed to get  
potential LIR-signed CAs up to speed. IT would therefore be good to  
have an idea how and when things should be taken up when we meet in  
Berlin. Andrei noted that it's important that we know what sort of  
policies we want in this area, and that we need a single global  
policy for this, but the process for deciding this will probably not  
be the IETF process. But there is commitment from all RIRs to work on  
this document.
Tim noted that there had been concerns raised about the business PKI  
side of the project, and suggested that it might make sense to keep  
it simple for the moment. Andrew noted that we should make very clear  
what we expect of people in the test group. Vasily volunteered to  
assist with testing if necessary.