-------------------------------------------------------------------
CSI WG meeting minutes 
MONDAY, November 9, 2009
1520-1720 Afternoon Session II
-------------------------------------------------------------------

- State of work
Chairs - 10 min

Good shape, closing on cert work hopefully today.
 
Just adopted DHCP interaction document, WG LC soon.
 
weakness in WG progress: PK agility, to discuss further today
 
- Certificate profile 
draft-ietf-csi-send-cert-01 
Roque - 15 min. 

x.509 profile details missing in RFC3971
EKU value
2 new msgs for cert revocation: CRS and CRA
 
new deployment models
old:
one trust anchor: centralized
more than one: decentralized
new:
all available locally within your domain, ISP, enteprise: local
some certs to be fetched outside administrative boundary: public
	* need a way to identity this trust anchor
	* currently only "subject name" etc which is not guaranteed to
	  be unique across organizations
 
in "local" scenario one could use ::/0 TA (all IPv6 address range) 
but this only works in local scenario
 
OCSP not adopted nor supported. Instead went with SIDR which must 
support CRLs so will add these new msgs in next version:
	* CRS
	* CRA
 
Marcelo: not sure these new messages have been adopted. 
Not necessarily need to define those messages in this document.
 
Roque: agree, we just need to acknowledge that we must handle CRLs.
 
Stephen Kent explained why OCSP support is not something RPKI would 
consider enabling for us (CRLs won't be fetched that often and they 
will be short anyways).
 
 
- New name type registry
draft-rgaglian-csi-send-name-type-registry-00 
Roque - 5 min
 
subject names and FQDNs are not guaranteed to be unique across CAs
 
so need a new nametag: SKI (subject key identifier) defined as in the 
cert profile for RPKI as a hash of the PK (160-bit SHA-1)
 
Omission in RFC3971 to define this new namespace
	* first two entries as defined in 3971
	* new third entry is this hash
 
Gab: why SHA-1?
 
Roque: good question, we may want to add not just one but two entries, 
one for 160 sha-1 and one for sha-2 as well. Will double-check.
 
 
- PK agility
draft-cheneau-csi-send-sig-agility-00.txt
update to 3971
draft-cheneau-csi-cga-pk-agility-00.txt
 
draft-cheneau-csi-ecc-sig-agility-00.txt
Tony - 20 min
 
Marcelo: either we get energy and participation or we don't pursue this 
work further. 
 
Gab: agree that without much more energy from experts it would not be 
responsible on our part.
 
- DHCP-CGA interaction
draft-ietf-csi-dhcpv6-cga-ps-00
Sheng - 10 min
 
Marcelo: just analysis is what we're chartered to do.
 
Stephen Kent: centralizing the generation at the DHCP server has 
privacy implications which are not addressed.
CGA to improve the security of DHCP? Doesn't provide this.
Security claims currently in the doc are not accurate. RFC3972 does 
have privacy considerations, so this waters it down.
 
Suresh and Tony: one *could* also use an EKU for DHCP server 
authorization, but that's not this document.
 
Ralph: should get input from DHC
 
Marcelo: yes, we should issue a joint LC with them
 
- DHC&CGA solution document
draft-xia-dhc-host-gen-id-02.txt 
Frank - 10 min

- CGA SEND implementation report
Wendong - 10 min
 
Implemented RFC3971, 3972 and 3779 (x509 extensions for IP 
addresses and AS identifiers)
 
ECDSA as an alternative to RSA
 
CRL verification

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

Summary of action points and outcome:

draft-ietf-csi-hash-threat will be shipped to the IESG

draft-ietf-csi-proxy-send: we will issue the WGLC right away

draft-ietf-csi-send-cert will be updated and the message format 
for getting the CRL information will be removed, only the default 
URI based method will be kept in the document. The WG can discuss 
separatelly whether we want to define the send messages to obtain 
CRL information.

draft-rgaglian-csi-send-name-type-registry-01 will be adopted as WG 
document, so authors should submit this as draft-ietf-csi-...

draft-ietf-csi-dhcpv6-cga-ps needs to address S. Kent comments about 
the security achieved by using CGGAs to authorize the DHCP server 
(i.e. relies on haivingt he dhcp address configured and not very 
different from having a shared  secret configured, and describe the 
leap of faith approach as well. In addition, should cover the privacy 
issues with storing the CGA information in a central repository)

In addition, we need to continue the discussion on PK agility support 
in SeND.

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