[17:06:47] --- kseo has joined
[18:03:20] --- mjo has joined
[18:28:30] --- weiler has joined
[18:30:06] --- badra has joined
[18:30:20] --- badra has left
[18:30:40] --- jgs@jabber.org has joined
[18:30:45] --- gih900 has joined
[18:30:50] --- ggm has joined
[18:31:19] <ggm> agenda bash
[18:32:00] --- benno has joined
[18:32:02] <ggm> http://tools.ietf.org/wg/sidr/agenda?item=agenda70.html
[18:32:24] <ggm> Matt Lepinski does the architecture draft
[18:32:52] <ggm> http://www3.ietf.org/proceedings/07dec/slides/sidr-2.pdf
[18:33:19] <ggm> (before, touches on CP/CPS. no update, because no feedback. so no open issues. please read/review)
[18:33:49] <ggm> Sandy (chair) stevek asked for comments at last meeting. expect many people to use. push one more time.
[18:34:09] <ggm> now on arch draft. minor changes. 02 version issued before meeting.
[18:35:30] <ggm> rfc1918 signed by iana, then key destroyed. no ROAS. anyone can set up alternate TA to sign CA cert over RFC1918. no conflict
[18:35:40] <ggm> there will never be ROAs under the default (IANA) TA
[18:36:18] <ggm> discussion on list since meeting, scope restricted to IPv4/6 and not MPLS or other address architectures
[18:36:37] <ggm> finally, large re-write of Manifest section. will issue 03 with Manifest excised, because of new draft
[18:36:51] <ggm> 03 expected in next few weeks
[18:36:57] --- badra has joined
[18:37:31] <ggm> Geoff: why the IANA sign over 1918? Don't understand why this, rather than 'do nothing'
[18:37:40] <ggm> Steve K. certainly correct when fully deployed.
[18:38:52] <ggm> proir to this, circumstance where information, mixture of verifiyable under RPKI, and not. so possibility of private address space being seen, seen by s/w in mixed environment. want clear demonstrations to believe ROA over unsigned, unverified assertion. extend principle to private, gives way to thwart bad outcomes.
[18:39:13] --- hta has joined
[18:39:32] <ggm> Geoff. then, you would take exception to the description of validation in the resource proto draft, failure is a failure irrespective of its certification. you go beyond that.
[18:40:38] <ggm> Steve K. no, thats not the circumstance. I am saying not, that people have issued a cert/roa we can't validate, its that they get mixture of validated, and unvalidated assertions. when assertions are made about resources are validateable, should be trusted "more" than un-validatable. therefore making assertions about private address space that are verifyable, takes higher precedence than unverifyable
[18:41:01] <ggm> Matt: there is section in arch draft, how to validate NLRI. perhaps can be expanded in the light of partial deployment.
[18:41:30] <ggm> Sandy you spoke about private address space, geoff spoke about 1918. thats V4 version. V6 has ULA. when I read the section, it seemed to me the words were neutral, just want to confirm
[18:41:50] <ggm> Matt I was thinking of both when I wrote the words, open to wordsmithing.
[18:42:07] <ggm> Matt. ROA format draft
[18:42:15] --- RussMundy has joined
[18:42:17] <ggm> no changes since last meeting
[18:42:51] --- Joe Touch has joined
[18:43:07] <ggm> current version specifies exact match between addresses in ROA, addresses in cert.. but flag to clarify that the ROA can apply to exact match on NLRI, or more specific in NLRI
[18:43:42] <ggm> open issue: two certs that are adjuncts cannot be used to join and permit the covering prefix.
[18:43:48] <ggm> (aggregation)
[18:44:29] <ggm> possible resolutions. not a problem. if we want to aggregate, they should have the aggregate made by their parents.
[18:44:57] <ggm> or, change ROA format to allow multiple sigs on a single ROA. both CAs can sign over the ROA for the aggregate.
[18:45:11] <ggm> introduces additional complexity. in validators, users, and ROA themselves.
[18:45:29] <ggm> or, change mapping from ROA to route ads. to allow set of ROA to jointly auth an aggregate prefix.
[18:45:55] <ggm> algorithmic complexity significant for the large number of ROA which have to be found to cover. difficult to specify. rather not do it (Matt)
[18:46:11] <ggm> currently, de-facto going with the first choice: get the covering Cert fixed.
[18:47:03] <ggm> Geoff. I think the first choice is a dud. to insist on the clean distribution hierarchy, authority hierarchy that maps to aggregation is article of faith, not fact. next couple of years in V4, scenarios post exhaustion, movement of addresses. not clear (to geoff) will have extremely clear, aggregation-dense hierarchies
[18:47:14] <ggm> so, I think A is short minded. not good.
[18:47:17] <ggm> solutions B or C.
[18:47:34] <ggm> C. places burden on relying party. do jigsaw to find ROA which match aggregate. bizarre.
[18:47:53] <ggm> B works well. validation of sigs on ROA becomes an AND. clean. nothing else in ROA semantics change. minimal impact.
[18:48:07] <ggm> complexity, multiple signers on ROA is syntactic, not semantic. suggest solution B
[18:48:21] <ggm> Paull Hoffman. Q on B. what is the semantics of the multiple sig.?
[18:48:28] --- hta has left
[18:48:47] <ggm> (discussing against the slide example in net 10)
[18:49:30] <ggm> Matt. proposed solution. envisioning, a single ROA, still two EE certs, Two CA certs, but single ROA will have ref to both halves.
[18:49:49] <ggm> Paul but, how can the certifier for one half be confident the other half is valid? both sides have to agree
[18:49:58] <ggm> Geoff (see later)
[18:50:51] <ggm> Steve K. paul, the CA isn't signing, it issues the EE cert. CAs which have concerns about signing, in this case continue to sign as before. the EE has the role of deciding how/what to sign. positive spin is, I assert the PART in this ROA that comes from me, is ok. its an assertion both can make when they sign. thats my interpretation
[18:51:21] <ggm> RobA. disagree. still for A. "this isn't going to happen".
[18:51:26] <ggm> Find this interesting.
[18:51:40] <ggm> the likelihood of 2 address blocks which can aggregate goes down, not up.
[18:51:52] <ggm> so I don't understand the reasoning.
[18:52:13] <ggm> Paul H. expressed my concern. B is more complex than it looks. want exact description of B. the logic. so we can look at it.
[18:52:20] <ggm> Matt. happy to write up
[18:52:55] <ggm> 1) how it changes ROA syntax 2) how it changes semantics of ROA, when signed by particular EE cert, additional 3) what does Relying Party do?
[18:53:01] <ggm> RobA please explore all failure cases.
[18:53:17] <ggm> Matt will produce draft text. to ML asap. for concrete discussion
[18:53:27] <ggm> Geoff. Like to clarify semantics of mutliple signing.
[18:54:16] <ggm> single sign, its I, the signer give authority to originate prefix. so in this context, its going the other way. aggregate out there, I, for my little half, I give permission to aggregate and announce MY BIT. but, you dont want the ROA to be attacked by others. I also have to sign over others to prevent people doing things. it has to be seen to be joint.
[18:54:38] <ggm> have to get rid of the jigsaw puzzle hunt, have to find all the more specifics. thats tough. many ways of doing it
[18:54:51] <ggm> tim Christienson, ARIN. apologize if re-hash..
[18:56:00] <ggm> posted to list, some time ago, that ARIN has not issued contiguous space, but kept allocs separate. moving forward, we wouldn't expect to do the case seen here, but we are an RIR, want to preserve keeping blocks together. after processing this, come to some agreement with Geoff, where the model might go, in traded world. however, Q in my mind if it will happen enough to matter. not that it happens at all, but enough to continue running this road.
[18:56:31] <ggm> can say "we wouldn't do it" but can't say if registry X will, likelihood will happen, have to consider approach B/C. not sure understand trade-off values
[18:56:43] <ggm> Sandy came to line to speak to option C.
[18:58:30] <ggm> believe C would introduce trying to guess intent of someone issuing adv. if issued advertizement for agg, and there are two more specifics, guess they meant the aggregate, not adequate. should be precise statement. guessing not appropriate. but, want to say in response to Tim, saying registries would not issue 2 and keep the separate if aggregatable. thats not the issue, its if the certs that attest to the ranges will tie the cert generation to their customer accounts, know amounts, or tied to allocation act itself. if we guess they never need agg, always issue maximally aggregated, keep the certs separate, and we are wrong, we can't go back.
[18:58:44] <ggm> so if we keep as single sig on ROA and we need multiples its non backwards compat changes.
[18:58:51] <ggm> so list of 1 is at least workable.
[18:58:56] <ggm> Tim. respond.
[18:59:31] <ggm> believe you said if we need it, too late to change. Q in my mind, is, if need is important enough. whats the benefit of creating it now, for what need. and importance.
[19:00:06] <ggm> when we group customers, contracts, expiration around end of year. natural grouping is business behaviour
[19:00:54] <ggm> Matt is this a reasonable way forward?
[19:01:04] <ggm> Sandy before holidays? :-)
[19:01:32] <ggm> final request from Matt: CP/CPS need review. read before next meeting
[19:01:47] <ggm> Geoff does Cert Profile: http://www3.ietf.org/proceedings/07dec/slides/sidr-0.pdf
[19:02:26] <ggm> Quick update.
[19:02:51] <ggm> was at 2. last year. now at 9. going to 10.
[19:02:57] <ggm> added Manifests.
[19:03:26] <ggm> subuordinate party knows where it wants to publish, has to tell issuer where to put manifest in SIA.
[19:03:40] <ggm> had review. Rsync is the work of the devil, discussed, decided to keep the work of the devil
[19:04:09] <ggm> comments noted with gratitude.
[19:04:19] <ggm> dropped subject alternate name
[19:04:41] <ggm> Sandy. process Q. have to get URI registered?
[19:04:43] <ggm> Geoff no.
[19:05:02] <ggm> Next steps.
[19:05:25] <ggm> generate version 10, with complete manifest description in SIA. re-request WGLC. again
[19:05:56] <ggm> Geoff goes into Bad Ideas.
[19:06:38] <ggm> validation possibly too tight. demands complete match. "nested encompassing" requirement.
[19:07:58] <ggm> eg if parent certifies V4, but has an AS, even if you aren't validating against the AS, you MUST be valid for the AS.
[19:08:27] <ggm> Steve. True, except, docs, point out the hierarchy is not the same across resource classes
[19:09:08] <ggm> doesnt HAVE to unfold this way. you can separate certs if needed.
[19:09:49] <ggm> Geoff. irrespective, if the certificate in the middle of a validation chain, introduces unassociated resources, then the covering parents MUST cover them, even though they are not involved in the validation
[19:10:04] --- hta has joined
[19:12:17] <ggm> So, the bad idea. can we relax the Q, and say "is this particular resource valid" rather than the entirity of the chain
[19:12:33] <ggm> the resource extensions don't have to be totally encompassing, only encompassing for the end of the chain being validated.
[19:13:10] <ggm> the potential use is in private contexts, private spaces, party A certifying space, B certifiying space, and want to talk across a trustable set, (venn diagram) then
[19:13:18] <ggm> accept its the idea from hell. musing.
[19:13:51] <ggm> thinking about Schiller, web of trust, private spaces, from the BoF. came to this Question. can't do these things, the arbitrary space things,
[19:13:56] <ggm> under the current rules
[19:14:00] <ggm> RobA.
[19:14:13] <ggm> very pleased to see this met your description. horribly bad idea.
[19:14:25] <ggm> implemented 3779. don't do this to me.
[19:14:40] <ggm> current alg is straightforward. turtles all the way up. very simple to implement.
[19:14:46] <ggm> what I see is a pile of 'cool but..'
[19:14:51] <ggm> dont see the benefit
[19:14:53] <ggm> Steve Kent.
[19:15:09] --- badra has left
[19:15:12] <ggm> several observations. would use different terminology at a number of points.
[19:15:42] <ggm> it is possible to represent web-of-trust using current mechanisms, but with greater burden on relying parties. fundamental trade-off. not unique to this environment.
[19:16:19] <ggm> if you want to have relying parties use mechanisms, straightforward, capturing hierarchic schemes, names can be like this, any structure, then, when you want to say pick arbitrary trust points, pick, then.. you see what DNSSEC is dealing with. not new problem.
[19:17:23] <ggm> but, even though not literally same, DNSSEC has same fundamental subset property, accurately reflecting allocation scheme. can't have it both ways. both simple, (for everyone, both allocators, relying parties) with arbitrary graphs, either exactly match scheme, simple validation, or, more complex with more management for relying party, but can still do with underlying mechanisms
[19:21:32] <ggm> Rob K. can extend the idea. parent of end-entity cert, has more than stated V4
[19:21:41] <ggm> but definitionally this is unacceptable
[19:22:08] <ggm> GGM: but definitionally, if we relax, then can have transitively valid at the edge, even if intermediates have differences.
[19:22:33] <ggm> Steve: but, this needs POLA analysis, risk analysis. need to understand what the model assumes, what is good and bad, do proper analysis
[19:22:43] <ggm> RobK <missed>
[19:23:08] <ggm> Geoff: want us to explore use-cases entirely, be confident use-cases match what we need of this technology
[19:23:43] <ggm> RobA. have strict hierarchical model for a reason.
[19:24:15] <ggm> every time I see model with privates on both sides, ugly. prefer not to wander down path of doing public net validation
[19:24:28] <ggm> and cost to public net validation, of doing broken things
[19:25:06] <ggm> Geoff. AD in room. believe that public, private, both on-charter.
[19:25:07] --- Joe Touch has left
[19:25:33] <ggm> also believe that public nets, simple model is inherently nicer. but, want to understand, analyse private net properly.
[19:25:51] <ggm> See that this is a reasonable decision, will accept, and move on.
[19:26:17] <ggm> http://www3.ietf.org/proceedings/07dec/slides/sidr-3.pdf
[19:26:26] <ggm> Geoff now does Manifests draft
[19:27:00] <ggm> sorry Steve K now does Manifests
[19:27:19] --- rhe has joined
[19:27:26] <ggm> now big enough to merit its own document
[19:28:02] <ggm> Signed Object, placed in repository at publication point. a problem in other environments, good idea from Rob Austein. articulted and refined.
[19:28:40] <ggm> problem relying party has, when finding objects, know if modified, but can't know if older version, (valid sig, old problem). generally put validity intervals with CRLs.
[19:29:20] <ggm> also dealing with problem mostly not seen in other PKI models. missing certs
[19:30:01] --- jgs@jabber.org has left
[19:30:13] <ggm> which is mostly a non-issue: but in this context, matters more.
[19:30:56] <ggm> pending repository diagram/documentation, tree of publication points.
[19:31:56] <ggm> manifests catalog downwards.
[19:32:52] <ggm> manifest encompasses all the products. files, certificates, crls, ROAs. EE
[19:33:38] <ggm> manifest verification. digitally signed. EE cert. propose the cert is bound into the CMS envelope, dont need the cert listed separately.
[19:33:56] <ggm> for EE managed pubpoint, manifest verified by exactly one level up cert.
[19:34:24] <ggm> exploit CMS structure altready present. EE cert uses inherit bit
[19:35:07] <ggm> pubpoint for a Ca, the CA cert has persistent URI for the manifest.
[19:35:24] <ggm> and likewise the EE cert will have URI for its manifest
[19:35:47] <ggm> manifests have serials. allows detecting missing. copied from CRL v2
[19:35:56] <ggm> this/next update, also taken from CRLs
[19:36:40] <ggm> file/hash alg agility
[19:36:55] <ggm> same alg of all files in this manifest. sequence of file and hash
[19:37:26] <ggm> file hash permits detecting valid file (sig on file) but previous (won't match this hash)
[19:37:53] <ggm> CMS wrapper is signedData object. has EE cert. (as said before). NOT CA/CRL in this CMS signed data
[19:38:04] <ggm> manifest lifetimes.
[19:38:16] <ggm> simple way: one-shot EE cert.
[19:38:41] <ggm> or, persistent EE cert. cert validity spans multiple manifests
[19:39:54] <ggm> manifest validation.
[19:40:37] <ggm> syntax check. sig check. (EE cert attached). check time inside validity interval (both sides). cert conformance to profile. cert has to be valid. 3280bis validation
[19:40:55] <ggm> having done that. best case:
[19:41:17] <ggm> present, valid, 1:1 mapping. every file you find, is in the manifest. and everything named in manifest is at pubpoint
[19:41:50] <ggm> RobK: CA/CRL not in...
[19:42:00] <ggm> Steve Not in CMS Wrapper. still covered in Manifest scheme overall.
[19:42:09] <ggm> Manifest ok, but file problems.
[19:42:17] <ggm> files not in manifest, should ignore and warn
[19:42:24] <ggm> files where hash dont match, ignore and warn.
[19:42:51] <ggm> files missing: not at pubpoint, warn, but use extand, valid files. use instead. eg previous files
[19:43:40] <ggm> RobA. agree with 2nd, 3rd. 1st. agree with nuance. applies to people who build non-trees, joins, two collections using same directory, will get spurious warnings
[19:44:26] <ggm> Steve. appreciate comment
[19:44:55] <ggm> need to take into account. warnings, spurious warnings, operation issues.
[19:45:05] <ggm> Geoff. first is interesting. it does say IGNORE.
[19:45:24] <ggm> idea is M-I-T-M attacks. Manifests try to protect. say "should have got this, that, not anything else"
[19:45:47] <ggm> two forms of attack. replay old manifest, or, objects replayed at you.
[19:46:18] <ggm> the first bulletpoint assumes the objects are replayed. rely on manifest. thats consistent. but, opens the other attck. if can reply manifest, then, take otherwise valid, and throw out because not in manifest.
[19:46:25] <ggm> this is can't have cake and eat it.
[19:46:33] <ggm> choicepoint. want guidance.
[19:46:54] <ggm> happy to take this interpretation. when find manifest, assume its good and objects bad, vs alternative, manifest is attacked, objects are cool.
[19:47:06] <ggm> steve
[19:47:13] <ggm> caveat. in draft is fair.
[19:47:24] <ggm> unscheduled manifest issuance. if scheduled, then either current or not
[19:47:43] <ggm> Geoff operationally, manifest almost the same as directory in FS. every time make change in repos pub point HAVE to update at that point.
[19:48:06] <ggm> so unless pub party sticks to schedule, "wont publish until midnight even though accepted" -if allow on-demand change, manifests continually update before due-date.
[19:48:13] <ggm> steve requirement people have to decide about
[19:48:20] <ggm> same as CRL problem
[19:49:08] <ggm> can report compromised key, invalid, have to decide. interim CRL, not probative, can be seen not to appear, wont be fetched because not in-time, or shorten lifetime to issue CRLs, Manifests, and repeat issue same state?
[19:49:15] <ggm> need text. to guide, what it means. choices.
[19:49:37] <ggm> Geoff draft is going to have to come down one way or other.
[19:49:55] <ggm> draft willnote as caveat. objects replayed, manifests believed irrespective
[19:49:55] <ggm> Steve and explain why
[19:50:00] <ggm> Examples of what can go wrong.
[19:50:17] <ggm> expired EE cert but valid manifest otherwise. use, but warn.
[19:50:36] <ggm> cert revoked. ignore manifest. ca said "invalidating the manifest" by doing it
[19:50:49] <ggm> proceed as though manifest not present
[19:51:00] <ggm> missing manifest. prior, use, but warn.
[19:51:12] <ggm> no manifest, use files, live with it. warn
[19:51:42] <ggm> if no manifest, but CA said should be (SIA) then, want to know.
[19:52:19] <ggm> cant verify sig.
[19:52:26] <ggm> use prior, and warn.
[19:53:04] <ggm> manifest, but expired. warn, move on. revoked, but not expired, again, positively disavowed so should not use
[19:54:20] <ggm> RobK. seems like PKIX work item. more general than SIDR.
[19:54:26] <ggm> understand could be warnings.
[19:55:11] <ggm> Steve.
[19:55:15] <ggm> level-warning model
[19:55:36] <ggm> comment about 'this is general do in PKIX' -no, because the error cases represent trade-offs tied to this environment.
[19:56:19] <ggm> would not do, if all Certs, CRL. positive assertion, dealing with things, never use if not. but, we are willing to take old information in this regime, so its different. in 3280/bis this is left up to relying party without hints
[19:56:26] <ggm> not specified. local config decision
[19:57:19] --- weiler has left
[19:57:28] <ggm> Robk syntax more general. pkix relevant.
[19:57:31] --- weiler has joined
[19:57:41] <ggm> Steve yes, syntax may be applicable. but the error cases, are special to environment
[19:57:46] <ggm> RObA. with steve on this
[19:58:02] <ggm> basic manifest mech useful to others, but errorhandling very specific to this context. fail-useful not fail-safe
[19:58:52] <ggm> had 40,000 cert/ee model, how to walk, validate. learned lessons from experiment.
[19:58:59] <ggm> eg syslog not viable in this level of warning.
[19:59:17] <ggm> single HTML page matrix of status, failure cases
[19:59:37] <ggm> similarly, some kind of summary display best way to approach how to cope with the warns
[20:00:34] <ggm> Geoff will do http://www3.ietf.org/proceedings/07dec/slides/sidr-1.pdf
[20:00:50] <ggm> comments to Robks observation. PKI in BGP context
[20:01:11] <ggm> real problem, is validation framework, PKI, allowing anyone to say 'trust IANA, so, can validate information in BGP'
[20:01:26] <ggm> leads to 'how to distribute' -fair deal of work, can distribute in BGP, outside BGP. doesn't matter.
[20:01:35] <ggm> receiver needs validation information in, or out of router
[20:02:15] <ggm> so, huge amount of work around certs, validation, relying parties. fun with BGP comes later, if at all. but, to secure BGP, it boils down to PKIs.
[20:02:30] <ggm> now exploring bits, the provisioning mechanism
[20:02:55] --- weiler has left
[20:03:27] <ggm> from the PoV of a resource allocator, want to avoid people ringing to get certs. don't want to do this via human centric process. want automated process. accurately tracks, resource issuance
[20:03:46] <ggm> from POV of registry, normal core occupation was alloc/assign to holders.
[20:04:17] <ggm> what you would like, is to automate issuance process. every point in time, certs issued, in other persona as CA, accurately reflect what you issued as registry to same party
[20:04:22] <ggm> keep it "the same"
[20:04:49] <ggm> so this documents protocol, how certif issuer, subject can have regular conversation in a protocol framework, to always have a cert, accurately mirrors their number resources.
[20:05:46] <ggm> HTTPS wrapper, request/response in protected channel. client server protocol. client is subject of cert, server is issuer. or client is ISP, server is registry
[20:06:36] <ggm> inside HTTPS payload, CMS. gets signing time, signing cert over the wrapper. tight protection inside requests. allows registry to understand who is asking, using OOB process to make sure the CMS cert matches the entity who has the resources.
[20:06:52] <ggm> can't pretend to be sprint. have to have the business entity cert.
[20:07:13] <ggm> RobA observation. CMS msgs can be saved for audit. not HTTPS alone, because no trail of what happened. CMS can be kept
[20:07:21] <ggm> Geoff. CMS carries XML data objects.
[20:07:29] <ggm> not the best of all possible options, but what we went with
[20:07:43] <ggm> all messages common outer wrapping
[20:07:58] <ggm> 3 message types. Query, Issue, Revoke.
[20:09:29] <ggm> good to say, everyone with numbered resources gets one, encompassing everything. but, not doable. resources have been issued over many years. some from the dawn of time, have resources, trace back, have different histories. worked for company who had InterNIC resources, now see IANA entry for 'various' with administrative control from ARIN, then APNIC, then that company. but, more recent allocations go directly from IANA to APNIC to the company.
[20:09:45] <ggm> if certificate chain follows paperwork, APNIC can't issue the certificate for all.
[20:10:01] <ggm> so resource inheritance have to be done modelling 'classes'
[20:10:52] <ggm> if have certs, ask and will get the current cert. if no cert, will only get classes
[20:11:28] <ggm> issue asks for certificate, passing PKCS10 req. conforming to profile.
[20:12:19] <ggm> revoke. spent a lot of time worrying about what revoke means. you don't revoke the certificate, its the key. everything in the class, against the key, get rid of it. so its class, key related
[20:12:33] <ggm> allows clean keyrollover.
[20:12:46] <ggm> error response.
[20:12:55] --- benno has left
[20:13:18] <ggm> draft has been written as a WG document. will submit to editor if adopted
[20:14:01] <ggm> 2 impl in progress. third coming up. using CMS in XML over HTTPS
[20:14:06] <ggm> Steve would want in WG.
[20:14:13] <ggm> shiver at revoke key not certificate
[20:14:25] --- benno has joined
[20:14:25] <ggm> we revoke certificate. thats what happens.
[20:14:37] <ggm> Geoff. I'll try to be more precise.
[20:16:23] <ggm> the revoke operation takes key, class, so that all certificates which match can be revoked.
[20:16:51] <ggm> Steve. if want to say the form of message is to specify the certs to revoke by the subj pub key, but what goes on the CRL will be a cert.
[20:16:59] <ggm> so what is revoked IS the cert
[20:18:00] <ggm> Sandy: more comments?
[20:18:36] <ggm> 3 actions. ROA formats, syntax. multiple sig decision. last 2 presentations on Manifests, PRovisioning, to adopt as WG items.
[20:19:28] <ggm> Sandy drafts at potaroo.
[20:19:34] <ggm> if accepted, will send to ID mechanism
[20:20:06] <ggm> <done?>
[20:20:10] <ggm> <done!>
[20:20:15] --- ggm has left
[20:20:19] --- benno has left
[20:26:37] --- RussMundy has left
[20:28:02] --- hta has left
[20:29:26] --- gih900 has left
[21:02:52] --- gih900 has joined
[21:05:43] --- gih900 has left
[21:18:15] --- gih900 has joined
[21:19:05] --- hta has joined
[21:22:39] --- gih900 has left
[22:02:11] --- gih900 has joined
[22:07:56] --- gih900 has left
[22:09:47] --- gih900 has joined
[22:14:46] --- gih900 has left
[22:42:12] --- gih900 has joined
[22:45:08] --- mjo has left: Replaced by new connection
[22:45:24] --- hta has left
[22:57:52] --- hta has joined
[23:06:08] --- hta has left