[09:47:56] --- eludom has joined
[09:47:56] --- eludom has left: Lost connection
[10:00:45] --- ggm has joined
[10:00:47] --- mjo has joined
[10:00:58] --- mjo has left
[10:01:26] --- kazuya has joined
[10:02:03] <ggm> meeting underway
[10:02:21] --- eludom has joined
[10:02:21] --- eludom has left: Lost connection
[10:03:42] --- mjo has joined
[10:03:49] --- eludom has joined
[10:04:01] --- ginny has joined
[10:04:08] <eludom> foo
[10:04:21] --- gih900 has joined
[10:04:30] --- uijterwaal has joined
[10:04:31] <ggm> http://www3.ietf.org/proceedings/07jul/agenda/sidr.txt
[10:04:33] --- carl-ietf has joined
[10:04:40] <eludom> reviewing aganda
[10:05:59] <eludom> discussion of need to do rsync as uri ... people don't want to bring to ietf...need volunteers
[10:07:02] <eludom> Steve Kent to the podium...
[10:08:00] --- dumdidum has joined
[10:08:08] <eludom> high level review of doc...mostly going over things that changed.
[10:08:32] <eludom> Added ERX (early reg. exchange)
[10:08:43] <eludom> Added manifests
[10:08:46] --- carl-ietf has left
[10:08:55] <eludom> Added local cache maint.
[10:12:42] <eludom> two different modles of trust anchors
[10:12:50] --- ryanczak has joined
[10:12:58] <eludom> needs WG discussion
[10:13:49] <eludom> RIR conventions for mapping to geographic regions need to be cosidered
[10:16:37] <eludom> repository: needs a separate document
[10:17:08] <eludom> need an author
[10:18:28] <eludom> manifests: purpose to allow a ca to sign a blob of bits that tells you want you should be able to find in the repository
[10:18:37] <eludom> you can then detect integrity violations
[10:18:47] <eludom> or older versions
[10:19:14] <eludom> could be separate, short doc, but probably not
[10:20:14] <eludom> local cache management: relying parties (ISPs) need to use system to acquire certs, CRLs, ROAs, need to validate
[10:20:21] --- aalain has joined
[10:20:52] <eludom> unlike most PKIs, every cert issued is of interest to every relying party
[10:21:12] <eludom> I want to have a local cache with everything in it, up to date.
[10:21:16] <eludom> First cut of algorithm.
[10:21:58] <eludom> operations: added discussion of when certs do NOT need to be issued
[10:22:52] <eludom> Still need to have top level discusion of CRL
[10:23:15] <eludom> will need protocol document
[10:24:07] <eludom> Questions?
[10:24:16] <eludom> ...
[10:25:30] <eludom> SM: what if you aggrigate two allocatoins, but CA of one part does not want you to advertise ?
[10:25:50] <eludom> SK: You as an ISP can not issue a single ROA that covers the aggrigate
[10:26:24] <eludom> SK: needs to be discussed
[10:26:37] <eludom> SK: 2 ROAs or 1 ?
[10:27:00] <eludom> Jeff H. Answer unsatisfying
[10:27:07] --- metricamerica has joined
[10:27:19] <eludom> s/Jeff/Geoff
[10:28:04] <eludom> GH: What you need is the ability to sign twice
[10:28:25] <eludom> SK: Original design allowed multiple signatures, asked to be removed
[10:28:33] <eludom> GH: who asked to remove ?
[10:28:37] <eludom> SK: Randy
[10:29:04] <eludom> GH: You can't issued that there be a one to one mapping
[10:29:23] --- lixia has joined
[10:29:52] <eludom> SK: Two possibilities ? Single ROA advertised /19 wtih 2 sigs, or two ROAs, relying parties are supposed to notice that they are agrigatable
[10:31:04] <eludom> GH: The roa the update should coincide
[10:31:04] --- eludom has left: Disconnected.
[10:32:58] <ggm> steve reviews CP/CPS document changes
[10:33:16] <ggm> few comments received, short preso.
[10:33:40] <ggm> one change, to all three. removed refs to cert acceptance by a subject
[10:34:48] --- eludom has joined
[10:34:49] <ggm> normal model is subj requests from CA, putting items in req, including proposed name. CA issues, sends back to subject, "do you want this" before publish. then ACK from subj, or timeout.
[10:35:03] <ggm> this PKI is different. certs are gen as side-effect to other underlying resource DB outcomes
[10:35:29] <ggm> felt to be inappropriate step for this model. requirement of acceptance not needed. goes away
[10:35:42] <ggm> dealt with OOB through normal revokation
[10:35:52] --- ruri has joined
[10:36:19] <ggm> in ref to sandys Q, it only applies to CPS: (which parts can be changed) and they are marked in a <you fill it in>
[10:36:37] <ggm> if not applicable, just go and plug it in, can use N/A type language
[10:36:55] <ggm> reason for suggesting do it this way, ppl done CPS, all follow this format from master docu, PKIX inf. RFC
[10:37:01] <ggm> kept section numbering 1:1
[10:37:12] <ggm> thus sections marked <omitted> permits comparison.
[10:37:19] --- jtest1a has joined
[10:37:30] --- jtest1a has left
[10:37:38] <ggm> unless everyone agreed 'nobody wants' and can label globally unapplicable, then, need a way to say '<n/a>'
[10:37:45] <ggm> so prefer not to remove them, delete sections, numbering.
[10:38:10] <ggm> Sandy: not my Q, was Paul Hoffmans Q.
[10:38:25] <ggm> Hoffman: find it adequate, suprised this was only Q
[10:38:37] <ggm> want to go back, got few comments. concern?
[10:38:44] <eludom> Paul hoffman: suprised that it was the only question. Very few comments
[10:39:18] <ggm> Hoffman: contentious parts? ok with this?
[10:39:26] <ggm> Steve 2 part answer.
[10:39:39] <ggm> for cps, not very concerned. so much is 'fill in the blanks' and just gives examples.
[10:40:05] <ggm> CP I am, not because its contentious, but because the way we got feedback was not because read, because was in a meeting and talking and ...
[10:40:20] <ggm> ie, was not review state, was side-effect of a conversation.
[10:41:20] <eludom> gmm: your comment is fair
[10:41:48] <eludom> gmm: APNIC is doing formal review of these docs against our policy/practices
[10:42:16] --- ayinhan has joined
[10:42:46] <ggm> hopefully feedback by Dec 2007
[10:42:53] <ggm> so no Q slide: not enough input to justify
[10:43:25] <eludom> gmm goes to podium
[10:44:21] <eludom> "I've never been in a spagetti western bordello, but if I am, I hope it looks like this" (gmm)
[10:45:42] <eludom> Resource Cert Profile
[10:45:59] <eludom> about right of use relationships
[10:46:13] <eludom> has to mirror allocations
[10:46:52] <eludom> 3779 extentions are CRITICAL
[10:47:03] <eludom> currently @ -07
[10:47:19] <eludom> lots of cleanup, consistency, etc. Skiped.
[10:47:30] <eludom> current suggestions
[10:47:44] <eludom> remove SubjctAltName
[10:47:59] <eludom> we dont see a need
[10:48:12] <eludom> PKCS#10 needs cleanup
[10:48:43] <eludom> GH: westarted with CRMF, found that SSL dosn't support it, left with 2 things
[10:49:02] <eludom> GH: probably going with PKCS10 required, negotiation others
[10:49:38] <eludom> RSYNC is a MUST for SIA and AIA
[10:49:42] <eludom> is MUST appropriate
[10:50:22] <eludom> Russ Housley: 3280 says you must have a subject or subject al name, why subject preferable
[10:50:59] <eludom> RH: you have to have subject (X.509 structure), more complex than subjectaltname
[10:51:10] <eludom> sk: not complecated in this setting
[10:51:26] <eludom> gmm: it's a restrcition of type
[10:51:54] <eludom> RH: null is explicitly prohibited
[10:52:53] <eludom> Paul Hoffman: the field only holds teletext string, you wont have interoperability unless you say hex or base 64
[10:53:49] <eludom> GH (at mike, not chair): issuer has to make sure subject names are unique for each cert
[10:54:15] <eludom> GH: subjectaltname is not in reuqest or profile, subject permissiable to be present but null,
[10:54:35] <eludom> GH: another implemention looking at blank requests
[10:54:50] <eludom> gmm: gett involved in above discsions
[10:55:33] <eludom> Section 3.9.1 added text to make it clear
[10:55:45] <eludom> 2.9.6 removed text about AIA
[10:55:52] <eludom> s/2/3
[10:56:09] <eludom> these slides are newer than whaats up
[10:56:14] <eludom> these slides will be up
[10:57:28] <eludom> l5.3 not looking for extra junk, but bare minimum info for key excange
[10:58:13] <eludom> next steps...
[10:58:24] <eludom> -08, moving towards last call
[10:58:40] <eludom> 8ish people have read doc
[10:58:56] <eludom> gmm done
[10:59:27] <eludom> matt lepinski
[10:59:32] <eludom> roa-format
[10:59:45] <eludom> slides not up to date given preceeding discssion
[11:00:35] <eludom> goal: enable IPSs to verifiy route originaltoin insertions in BGP updates
[11:01:19] <eludom> validityof route origination
[11:01:42] <eludom> three things need to be true: route avertizement needs to match roa, roa needs to mach cert, cert must be valid in PKI
[11:03:11] <eludom> roa: version #, one or more prefixes autorizing, flag semantics for BGP matching with ROA, AS # being authorized to originate prefix
[11:03:25] <eludom> CMS format used. Well supported in OSS
[11:04:48] <eludom> added exact match flag to ROA, to indication if authorizing specific prefix, or shorter prefix
[11:04:58] <eludom> imporant for multihoming
[11:05:38] <eludom> added section describing how a ROA is validated
[11:06:57] <eludom> matching ROA and EE
[11:07:18] --- dumdidum has left
[11:07:27] <eludom> ex: ROA +, EE: -
[11:07:55] <eludom> need to add text clairifying how to do compariisons
[11:08:15] <eludom> matching ROA to NLRI
[11:08:36] <eludom> suggestion: use same smenatics as RPSL
[11:08:55] <eludom> but...not possible
[11:09:30] <eludom> Looked at RIPE IRR
[11:09:45] <eludom> found match semantics widely used
[11:10:21] <eludom> current proposal: Keep exact match
[11:11:12] <eludom> gmm: a ROA is a signed object. There is nothing more complecated than what you've prosed. You don't need a flag.
[11:11:26] <eludom> ML: exact match, or -00 version ?
[11:11:36] <eludom> gmm: this flag. Don't make it more than boolean.
[11:11:49] --- onakayu has joined
[11:12:07] <eludom> RH: pushback on CMS. I think it will work.
[11:13:27] <eludom> ML: do you have a use case for ROAs where allowing specific prefixes is useful
[11:14:09] <eludom> ???: Cusotmers ask us to announce all of shorter prefix out of longer
[11:14:42] <eludom> ???: don't think putting syntax to express that is that hard. We may get large #s of objects.
[11:15:19] <eludom> GH: validity of route vs. confomrance to policy. Difficult to draw line.
[11:15:44] <eludom> GH: the prefix lenght worries me because it has implications in policy.
[11:16:24] <eludom> GH: Does RPSL cover additoinal things you're concerned about ? RPSL very expressive.
[11:18:02] <eludom> Rob Austine: I like the proposal as it stands. Don't make it more complecated. Allows you to have total control.
[11:18:18] <eludom> RA: do lots of little ROAs if you need to.
[11:19:31] <eludom> Private Address/AS space, Sandra Murphy
[11:19:41] <eludom> should be short.
[11:20:06] <eludom> There are 1918 addresses or 1930 ASes in use
[11:20:15] <eludom> what do you do if you're using them internally.
[11:20:29] <eludom> the other answer: local trust anchor, certs for that space.
[11:20:44] <eludom> ipv6, unique local address space issues
[11:21:01] <eludom> known prefix, randomly chosen "global id"
[11:21:14] <eludom> same two choices as for 1918
[11:21:46] <eludom> ipv6 gorup discussing registration of unique local addresses
[11:22:03] <eludom> would allow two organizations to do local, private routing
[11:22:39] <eludom> if all RIRs are choosing form the same space, might complicate cert path
[11:22:48] <eludom> not clear how it is going in v6 group
[11:22:56] <eludom> Q: do we want to add it to arch draft ?
[11:23:12] <eludom> one answer: dosn't handle 1918
[11:23:19] --- uijterwaal has left
[11:23:56] <eludom> GH: work so far has been generic enough to accomodate public an private addrs
[11:24:15] <eludom> GH: in public space, authorizors are derived
[11:24:26] <eludom> GH: in private space, this is a local assertion
[11:24:47] <eludom> GH: nothing in architecture precludes public/private
[11:25:10] <eludom> GH: relying parties would have to use me as a trust anchor (for 10. ,etc.)
[11:25:22] <eludom> GH: why discuss this when it's in the work
[11:26:10] <eludom> SM: I don't think there's any problem that needs to be addressed. Asking if there needs to be any mention of private address space.
[11:26:29] <eludom> PH: IANA has delegated private space to everyone simultaniously
[11:26:38] <eludom> PH: there is no issue here.
[11:26:50] <eludom> PH: what about leakage ?
[11:27:23] <eludom> SM: not a technical issue. Only asking if arch draft should not that same applies to private addrs.
[11:27:38] <eludom> GH: there has been discssion of IANA ceritfying net 10. Then things get ugly.
[11:28:06] <eludom> GH: then we have contridictory info. We should say that IANA MUST NOT certify 10 addrs.
[11:28:16] <eludom> RH: 0/0 becomes a problem.
[11:28:52] <eludom> RA: Similar to qustions in DNSSEC. Same answer. You want IANA to leave it as an unsigned delegetoin.
[11:29:50] <eludom> SK: You should be prepared to manage trust anchors to say who's version of 10 you accept.
[11:30:22] <eludom> SM: now, open discussion.
[11:30:27] <eludom> ...
[11:30:59] <eludom> SM: WG needs to decide if we want to take on 1 to 3 drafts.
[11:31:04] <eludom> repository
[11:31:06] <eludom> manifest
[11:31:18] <eludom> ??? critical.
[11:31:53] <eludom> SK: I think the repostory doc is absolutly required.
[11:32:46] <eludom> GH: (WG chair off): repository structure was very early draft, could possibly come back
[11:32:57] <eludom> GH: other drafts concerned with automating.
[11:33:35] <eludom> GH: not looking to standardize things that have limited applicability
[11:33:54] <eludom> GH: we will look at the repository
[11:34:02] <eludom> RH: who's "you" (who will look at draft)
[11:34:07] --- lixia has left
[11:34:22] <eludom> GH: Myself, and other original 2 authors
[11:34:54] --- michaelpeck has joined
[11:35:00] --- onakayu has left
[11:35:27] --- ayinhan has left
[11:36:03] --- kazuya has left
[11:36:15] <eludom> RA: DNSSEC has trust anchor statement. in practice, not hard to set up. Specify anchors for more speficic anchors.
[11:36:33] <eludom> RA: e.g. one for root, one for 10/8, etc.
[11:37:10] --- michaelpeck has left: Computer went to sleep
[11:37:28] <eludom> SK: BoF Friday on Trust Anchor Management;
[11:37:37] <eludom> SK: this is a perfect example.
[11:38:39] <eludom> SK: You want to impose conttraints on subtrees
[11:38:54] <eludom> SK: not well represented in products.
[11:39:40] <eludom> GH (at mic): you already have implicit scoping.
[11:40:12] <eludom> GH: Cert not 0/0, but "these addresses in v4 are part of the public space", implication, the rest arn't.
[11:41:08] <eludom> SK: I agree with Geoff.
[11:42:19] --- ruri has left
[11:43:05] <eludom> SK: we have two alternatives that work.
[11:43:12] <eludom> SM: We're done.
[11:43:29] --- ggm has left
[11:43:41] --- mjo has left
[11:45:45] --- gih900 has left
[11:53:34] --- ayinhan has joined
[12:09:06] --- ayinhan has left
[12:10:04] --- metricamerica has left
[12:17:33] --- ayinhan has joined
[12:26:39] --- eludom has left: Disconnected.
[12:29:29] --- ginny has left
[12:32:02] --- koji has joined
[12:32:33] --- koji has left
[12:43:54] --- gih900 has joined
[13:01:12] --- ayinhan has left
[13:28:14] --- gih900 has left
[13:34:29] --- aalain has left
[13:37:43] --- gih900 has joined
[13:52:34] --- eludom has joined
[13:52:34] --- eludom has left: Lost connection
[13:58:13] --- ayinhan has joined
[15:09:50] --- eludom has joined
[15:09:50] --- eludom has left: Logged out
[15:18:24] --- michaelpeck has joined
[15:24:37] --- michaelpeck has left
[15:41:54] --- ayinhan has left
[15:53:30] --- gih900 has left
[16:12:16] --- gih900 has joined
[17:18:54] --- gih900 has left
[21:56:54] --- gih900 has joined
[22:46:47] --- gih900 has left