Re: Proposed Agenda items of Tallinn meeting

[Rob Austein <sra@hactrn.net>]

At Mon, 23 Apr 2007 06:51:19 +1000, Geoff Huston wrote:
> 
> So we'd like to propose the following agenda items:
> 
> 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.

Worthwhile goal.

>     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 />

Good.

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

No objection.

>     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

Assuming I understand these three, agreed.  I believe these are
changes that came out of the Prague meeting and were already in the
"RobL's Fork" version.

>     f) add a new request / response where the ISP requests a copy of the
>     certificate issued to this ISP identified by the previously 
>     supplied url in the resouce class list response.

Am not convinced, but we can discuss it.

>     g) remove the "terminology" section

Does not change the protocol. :)

>     h) remove the Asynchronous (Off-line) Key Signing Operation section

I don't care whether the description is in this document.  I do care
whether the sneakernet capability is in the protocol.  Please clarify
which you propose to remove.

>     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.

That should be a fun discussion, but I agree that we should have it.

> 2. The Left-Right Protocol
> 
>     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.

I agree that it the system could work without a common protocol here,
but if there's to be any hope of a shared implementation, I think it's
important for the people who understand how the rest of the system
works to debug this protocol and make sure it can support what
everybody needs.

Of course, if you really want to go it alone, I can't stop you.

> 3. Review of the Resource Certificate draft
> 
>     We'd like to put this document forward 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.

I think I'm ok with this.

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

I don't like this one at all, as it increases the amount of useless
work that has to be done by each relying party, which seems like a
very bad tradeoff.

I have some review notes on this draft which I have not yet posted, I
should clean them up and do so.

> 4. 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.

Sounds useful.

> What other topics should we be talking about that should be included on the
> agenda for this meeting?

I still want the "suggested_sia_head" attribute in the resource class
response to support the publication protocol as I envision it; I
realize that this may be controversial, but we should discuss it, as I
have yet to find any of the proposed alternatives either simpler or
convincing.

I agree with RobK's proposed additions to the agenda.  I suspect it
would help for somebody (RobK?) to do at least a first pass on his use
cases in advance if we can rather than in real time in Tallinn.