Re: Proposed Agenda items of Tallinn meeting

[Geoff Huston <gih@apnic.net>]

I've included the suggestions I've seen regarding the agenda, and the
result is as follows:


Draft Agenda - v2  26/4

1. The IR-ISP Protocol

  There have been some changes to this protocol in January and again in
  March and its not clear what is the definitive spec at this stage. It
  would be good to be able to reach closure on this spec so that we can
  implement against it, and we'd like to see if we can achieve that at
  this meeting.

  We'd like to propose taking the following spec:
  
http://mirin.apnic.net/resourcecerts/wiki/index.php/IR-ISP_Definition_%28RobL%27s_Fork%29

  and consider some simplifying assumptions that might be useful for
  implementation of version 1 of this protocol. The changes proposed
  attempt to conclude some of the current outstanding issues with the
  protocol and also proposing punting some issues relating to potential
  support for resource trading models that might rely on certificate
  behaviours to potential subsequent version of this protoco.

  The specific changes proposed are:

  a) promote the header attributes to be attributes of the <message />

  b) include a required "type" attribute of the <message />

  c) remove explicit enumeration of resources in the certificate issuance
  request for version=1 of this spec

  d) redefine the meaning the resource_set_* attributes of the class
  field of the resource class list response to be the complete set of
  resources that the issuer could certify for the subject at this point in
  time

  e) redefine the meaning the resource_set_* attributes of the cert
  field of the resource class list response to be the set of resources
  certified in this certificate

  f) include the certificates in the resource class list response

  g) remove the "terminology" section

  h) remove the Asynchronous (Off-line) Key Signing Operation section
 
     NOTE: This does not propose removing support for Asynchronous (Off-
     line) Key signing, just removing the text relating to considerations
     of key signing queue operations from the spec.

  i) we'd like to propose that there is no "auto-issue" explicit control
  and the normative behavior that the issuer will auto-issue certs
  in the event of resource shrinkage, resource allocation, and issuer key
  rollover.

  The cumulative result of applying these changes (a - i) has been 
drafted as:
  
http://mirin.apnic.net/resourcecerts/wiki/index.php/IR-ISP_Definition_v_0.9.0
 

  j) include "suggested_sia_head" in the resource class response in
  support of a publication protocol

2. The "Left-Right" Protocol

  Current status?

  APNIC Comment:
     As this is an internal protocol we'd like to propose that no common
     specification for this protocol is required, and the protocol used to
     communicate between the module of the certificate system and the
     associated databases are a matter for the implementation to determine.

3. Repository (Publication) Protocol

  Use Cases?
 
4. Repository Structure - need for signed manifest, etc.


5. Review of the Resource Certificate draft

  The document's authors (ggm, robl and gih) would  like to put this
  document forward in the IETF SIDR WG as finished, so there are a
  number of items we'd like to discuss to see if we are all ok with this:

    a) the subject name and subject alt name fields are a matter for the
       issuer to determine and the CPS to specify. In the context of the
       APNIC work we are looking at a CPS that specifies that the Subject
       name is a hex representation of a large number that is unique per
       customer and the Subject Alt Name is not present, but that does not
       necessarily bind other issuers to the same name policy.

    b) the SIA value is not necessarily unique and two or more CAs can
       specify the same SIA



6. Review of Work / Plans

  We have been undertaking some internal planning here and are happy to
  report on where we are up to and what we are looking at undertaking in
  terms of system development work in APNIC in the next 3 - 6 months.
 
  Henk will also report on the RIPE NCC's activities.