[13:17:35] stefan.santesson joins the room [13:20:15] stefan.santesson leaves the room [13:56:10] PHB joins the room [13:56:34] PHB gets to meeting early [14:15:35] stefan.santesson joins the room [14:28:58] mrex joins the room [14:32:20] mrex has set the subject to: PKIX-WG @ IETF-74, 23-Mar-2009, 09:00-11:30 (GMT+7), Audiocast: http://feed.verilan.com:8000/franciscan_a.m3u [14:40:32] yangqinqin09 joins the room [14:50:19] PHB leaves the room [15:00:40] stefan.santesson leaves the room [15:03:02] carl-ietf joins the room [15:03:02] mrex leaves the room [15:03:20] carl-ietf leaves the room [15:10:15] yangqinqin09 leaves the room [15:10:37] yangqinqin09 joins the room [15:23:15] Samuel.Ashmore joins the room [15:42:56] PHB joins the room [15:43:09] PHB leaves the room [15:43:10] PHB joins the room [15:48:07] jimsch1 joins the room [15:49:52] spturner joins the room [15:52:03] ggm joins the room [15:53:15] spturner leaves the room: Replaced by new connection [15:53:15] spturner joins the room [15:56:30] Melinda joins the room [15:56:41] David Cooper joins the room [15:58:47] SharonB joins the room [15:59:39] stefan.santesson joins the room [16:01:16] agenda is http://www.ietf.org/proceedings/09mar/agenda/pkix.txt [16:02:04] mattlarson joins the room [16:02:08] mattlarson leaves the room [16:03:39] doing status since last meeting [16:03:57] no docs in IESG, 12 drafts [16:04:12] gih joins the room [16:04:18] 3 trust anchor drafts live. 4th not meant to be there [16:04:48] PRQP being discussed [16:05:44] http://www.ietf.org/proceedings/09mar/agenda/v6ops.html [16:05:58] sorry http://tools.ietf.org/html/draft-ietf-pkix-prqp-02 [16:06:02] (cut and paste mistake) [16:07:04] changes: -IANA reqts for registry/types. [16:07:26] no new data structures, no new OID, positive feedback from DHC people [16:08:22] carl-ietf joins the room [16:08:57] mrex joins the room [16:08:58] process issues with document status affect registry allocations of option codes. [16:09:06] The audio streams has an echo [16:09:36] semery joins the room [16:09:46] stephan got the spkr to change his mike habits. any better? [16:10:27] lellel joins the room [16:10:42] added DNS SRV text. also positive feedback [16:10:58] schnizlein@jabber.isoc.org joins the room [16:11:27] Paul Hoffman: DHCP ppl unhappy with request for numbers from IANA because doc is experimental? [16:11:32] schnizlein@jabber.isoc.org leaves the room [16:11:35] stefan.santesson leaves the room [16:12:09] [16:12:17] Paul: ok so this doesn't matter [16:12:31] doc status won't finally affect registry alloc of codes. [16:12:45] stefan.santesson joins the room [16:12:55] 50+ certification authorities deployment TACAR. previously reported on [16:13:15] shirleyhm joins the room [16:13:17] Dartmouth to act as Trusted RQA. delays on project [16:14:27] deployment for FBCA. 15+ CAs. bridge environment. plus a large commercial interested. [16:14:45] SharonB leaves the room [16:15:00] OpenCA integration coming [16:15:53] conclusion: doc stable, 03 for IANA changes, WGLC (?) and on to standards track (?) [16:16:31] echo on the audio stream has apparently been fixed [16:17:23] Kent: if adopted, then shows ideal rationale for experimental -> stds track. good. persistance pays off [16:18:00] Tim Polk/AD. timeline Questions. pressure to get DHCP option nums assigned early. wonder, what timeline for experiments [16:18:03] making release date? [16:18:31] Massimiliano later on can be a problem. thats the only concern (mismatch numbers) [16:18:44] April first deploy. Asked a month ago, but will [16:19:05] Tim: can request early assignment as soon as we do WGLC. reasonable. this is not controversial. willing to do, to help experiment get rolling [16:19:05] PHB leaves the room [16:20:09] now on Traceable Anonymous Certificates - SangHwan Park http://tools.ietf.org/html/draft-ietf-pkix-tac-02 [16:20:41] extensive comments to 02 draft from David Cooper [16:21:11] see ML for more details [16:22:08] major changes from 02. [16:22:30] ContentInfo wrapper in place of CMS ContentInfo object [16:22:43] SharonB joins the room [16:22:44] distinct ContentType OID for each msg [16:23:12] version 03 will use CRLS/OCSP for revokation status. not SCVP [16:23:48] clarifications of the request formats. [16:24:29] checks for duplicate requests/freshness (replay) [16:24:54] unixonline joins the room [16:25:10] remove refs to DSA based splot signing proto [16:25:59] Responses [16:26:12] language issues around anonymous/pseudonymous [16:27:33] I-D references 2001 paper, but differs. [16:27:57] Stefan: is there such a word? (room: yes) [16:28:58] refer to DSA based blind sigs, use of threshold split signing [16:29:33] unixonline leaves the room [16:30:03] David Cooper: heard couple of times, threshold/blind sigs. never heard explanation of why. don't see in protocol [16:30:48] Steve: responded, will say again. for a CA of this sort, use of split key signing, blinded sigs, makes it easier to get procedural security. maintain separation between AI, BI parts [16:30:50] David: how? [16:31:17] Steve: if doing in that fashion procedurally. organizationally one entity has chinese walls, one enforces this by procedures, this is a tech procedure, can be audited [16:31:44] wont expose identity of user, abuse complaints, meet CPS [16:31:50] David. token, I can understand. [16:32:07] blinding/threshold, forces RA/CA to work more closely together, not separation [16:32:10] Steve as opposed to... [16:32:19] David: get token from RA, take to CA, get certificate [16:32:36] Steve. if you take that approach, then the checks are there to avoid redundant issuance, right entries in DB etc [16:32:59] sftcd joins the room [16:33:33] David. grant, if you have threshold sig, can't issue any more certs than tokens issued. doesn't force more separation, doesnt guarantee traceability. auditor comes in, makes sure token is associated with every certificate, don't see whats accomplished [16:33:44] Steve agree to disagree? [16:33:56] go speak to auditors, its about process. [16:34:35] Park think this can help [16:34:44] Tim Polk. (AD) part of why this is experimental [16:34:47] unixonline joins the room [16:35:00] see if added complexity does add value. looks like it should, learn from experiment [16:35:17] coordination between players needed anyway [16:35:57] Steve as for PRQP: if successful, then see adoption, then provide base for future accreditation [16:36:11] experimental doc, before transition would have feedback [16:36:27] David McGrew. only ref provided in the draft on threshold sigs, pvt key gen, is to conf paper. [16:36:58] there are significant system security aspects. specify, for interop, security. appropriate to have std in the area, or draft. am I missing? already detailed spec to processes? [16:37:18] Steve. don't know there are good references. often notoriously short on citations for assurance [16:37:39] FIPS 140-3? references? have done threshold in FIPS. done one. [16:38:14] Ptrs, or stuff crypto research group should do for future, worthwhile. lots of examples of stds using crypto but with no difinitive normative assurance stds referenced [16:38:21] Paul Hoffman. Q on experimental status. [16:39:11] going back to Davids question. hard to determine if succeeded. whole other way of doing it, not mentioned. draft doesn't have two ways. experiment success/fail on auditor responses can't compare. some auditors will like, but, some will not deal. won't be able to evaluate. not saying don't do, but will confuse [16:39:42] Steve. didn't mean to say what i think you understood. [16:40:53] Tim Polk. if stds track document, need stronger references around crypto/security. as experimental, these can be "have to be addressed" [16:41:43] clatze joins the room [16:42:00] Paul. not security considerations. process considerations [16:42:11] Tim. important to think about systems security pieces surrounding, added complexity [16:42:35] that we don't cover, provide refs, no well documented, then if come back to stds track, ommission will have to be addressed. [16:42:40] Paul: not in security considerations [16:42:47] Russ; don't argue about where. just have to have [16:43:01] Paul: in introduction maybe. "we thought about it" [16:43:07] Stefan. done. [16:43:19] Trust Anchor Management (TAM), Carl Wallace [16:44:02] http://tools.ietf.org/id/draft-ietf-pkix-ta [16:44:16] did complete WGLC against draft 2. comments from stefan addressed in 03 [16:44:32] holding on ta format, WGLC coming [16:44:38] TAMP spec submitted a few weeks ago [16:44:55] one draft taken out as pkik, now back as individual submission [16:45:05] so now 3 drafts in PKIX [16:45:20] TA mgt reqts will stay as draft while other 3 wrap up [16:45:39] TAM scope has been limited, as per stefan, to push protocols [16:45:53] text moved to security considerations. [16:46:10] Tim asked, do indiv. submit on usage of constraints. text is WIP. will submit soon. short doc [16:46:43] TA format changes (dense slide) [16:46:52] not large but significant. [16:47:11] removed some fields, can appear as extensions. [16:47:16] ASN editing [16:47:57] oer stefan, TrustAnchorList with a CHOICE of certs [16:48:22] removed refs to TAMP, fully independent. [16:48:35] TAMP changes. (also dense slide) [16:48:42] wordsmithing [16:49:00] unrelated to other doc change, did some work on sequence number handling [16:49:47] shpark joins the room [16:49:50] ASN errors fixed [16:50:56] changes to align with SIDR TA format [16:51:03] Steve: yes converging [16:51:10] CCC changes. [16:51:21] misnamed, indiv. submit [16:51:34] subordination processing taken from TAMP. [16:51:45] extension Absence meaning changed. 'avoid law of unintended consequences' [16:51:57] inheritence from prior CA hierarchies behaviours not implied [16:52:05] moving forward, aim for WGLC. [16:52:44] draft on constraints in path validation, submit shortly. [16:52:52] TAMP spec hasn't had enough comments, good to progress asap [16:53:33] JGersch joins the room [16:53:34] Stefan. Euro standard "TSL" [16:53:48] dives directly into field, application of this work. just raising for awareness [16:53:58] harmonization would be good. don't suggest using their (XML) format. [16:54:07] mix of human, machine information. ugly [16:54:37] practical use is to ignore all human consumption, only as import and other info. look at, avoid two standards on market [16:54:44] Q? generally available? [16:54:49] Paul: found on google so yes. [16:54:58] agree, zoom through, too many uses of word OPTIONAL [16:55:14] Steve: way to disseminate, choose to use, as opposed to mgt protocol, I manage store, here it is [16:55:16] fair? [16:55:20] Stefan long story [16:55:35] if enough people think its relevant, and set policy, then problems. [16:55:51] Tim: XML based format [16:55:55] Paul with pseudo ASN1.. [16:56:04] Stefan PSEUDOnomyous? [16:56:22] Tim shouldn't be impediment for format going forward. addressing different market. good to have URLs go to list [16:56:42] "what did they include we might have forgotten" stuff [16:57:28] Stefan. new activity in EU, ETSI will meet in may in london, under action plan. maybe we make ETSI aware of this work, achieve harmonisation [16:57:59] carl-ietf leaves the room [16:58:16] Tim: throw liaison statement over the wall. [16:58:33] Paul: WGLC looks good. [16:58:40] OCSP Algorithm Agility, Phil Hallam-Baker [16:58:49] Stefan to do, unless somebody else from Verisign. [16:58:58] http://tools.ietf.org/id/draft-ietf-pkix-ocspagility-00.txt [16:59:05] On behalf of Phil. [16:59:34] unixonline leaves the room [17:00:08] default client/alg selection, based on current protocol. add optional mechanism for algs, for cases not covered by the default. [17:00:42] also relevant to 'lightweight' OCSP. with precomputed stuff [17:00:48] http cacheing issue [17:01:22] need unique URLs, cacheing won't work as intended in some cases [17:01:26] issues: [17:01:32] alexmcmahon joins the room [17:02:06] use of SHA1, hardwired. to make cert ID. agreed on list, discussions in OCSP agility not security issue, doesn't need to be updated. but hear more and more, 'wherever sha1 found needs to be updated' [17:02:22] but will change protocol. worries me. unless need, I (stefan) feel reluctant. personal comment [17:02:39] according to phil has to be fixed before goes STD. [17:02:54] security remains dependent on cert sig alg. could be issue for archive apps [17:03:09] proposed extension to allow known-good hash to be maintained. [17:03:56] Russ need to deal with this problem. in terms of getting support for other functions argued against. [17:04:03] want OCSP to be widely available to many communities [17:04:20] seeing beginnings of gov stopping sha1, only support sha256 and sha2 family. [17:04:46] because ok in one case, doesnt raise issues, but, people buying NEED to meet checkboxes 'there is no sha1' otherwise there is a much harder discussion [17:05:06] did some analysis where this did not have to change, but need to think about selling concepts [17:05:13] agree no security reason, but need to discuss. [17:05:22] Paul Hoffman. agree with Russ need to deal with issue. [17:05:27] don't agree with how done in this draft. [17:05:37] like to talk about negotiation, sounds polite. [17:05:49] in a situation like this, its not negotiate, its a list of things, and a demand. [17:06:01] another way is to have separate protos with separate hash functions. if not in prot A then go prot B [17:06:09] that way, no negotiation. no options. trivial to implement. [17:06:34] cache that you missed on first, went second, all these worries go away. [17:06:46] believe we want to look at that as a way, not jam agility into every protocl [17:07:02] stefan sympathetic to this thought. suspect we need another basic response [17:07:21] afraid of consequences for deployed OCSP if we make another response type. [17:07:30] think this is an argument larger than this document. [17:08:06] discussed on SAAG. erik talked about nonsecure hash [17:08:17] Tim have mixed feelings. understand where Russ is coming from [17:08:42] want to make sure protocols will be used. faced with same thing in sha1 HMACs secure for what they do, until long after I retire. [17:09:02] want agility, vendor to make choice, move forward. not sure want to deprecate use of sha1 if use is secure. but need agility [17:09:19] carl-ietf joins the room [17:09:46] not clear to me absolutely has to be done to move 2560 foreward [17:10:19] Max -from what I hear is reasons which are not technical, and technical [17:10:34] good reason to define extensions, not change bits on wire, protocols, but allow. [17:10:46] Stefan. sha1 use as identifier is buried in core of protocol [17:11:03] Max no security reason to change, add other identifier, as extension, other alg, if don't udnerstand then not invalidated [17:11:33] Stefan. old client, allowed to ignore extension, problem? [17:11:37] [17:11:43] Stefan thanks for clarification [17:11:59] Time-Stamp Protocol update - 3161bis, someone OBO Denis Pinkas [17:12:37] http://tools.ietf.org/id/draft-ietf-pkix-rfc3161bis-01.txt [17:12:49] primary reason: new ESS cert ID. [17:13:30] identify signer certificate. so time stamping auth, with more than one valid cert, can tell which one to use to validate sig of particular timestamp. not among millions, or valid/invalid. distinguishing among a few with a good hash [17:13:48] stefan. can't see security threats. but, this is defined, and the sha1-is-evil thing means need agility. this is the way to do it. [17:13:53] major change of terminology in doc. [17:13:54] polk.tim joins the room [17:14:10] ETSI had timestamp policy work, rubberstamped into rfc2638 [17:14:28] felt neccessary to distinguish different tokens, cases for timestamping, and related to name structure in certificate [17:14:45] now all spelt out in protocol doc. [17:14:53] more ASN1. [17:14:56] normative [17:15:03] JGersch leaves the room [17:15:05] stefan.santesson leaves the room [17:15:12] ISO informative reference [17:15:48] Stefan commented. nobody says there is a threat requiring the update. only using to do location of good things. hard to see collision risk. [17:16:19] however, I concur, lets do this update to doc. [17:16:33] Denis proposes Stefan to write security considerations text. [17:16:44] was in ETSI when policy doc made, did not object [17:17:21] difference between TSA/TSU/TSS [17:17:32] Exodus joins the room [17:17:44] not well understood. [17:17:44] Exodus leaves the room [17:17:47] Progress. [17:17:49] two ways. [17:18:02] current path: complete replacement doc, deprecate old RFC. [17:18:54] or, make update doc, how to add. in discussions with Denis, as said here, could have nformational annexe in update doc, explaining why terminology is different.P [17:19:10] Paul Hoffman. additional ways forward, or pick. need to know about informational annexe [17:19:22] too much IPR, I'm ignoring this. looking at meta. [17:19:53] If no bits on wire, but additions, then we could, we know ahead of time, terminology mess is informative then we can use one of these two. but, if need, a third way, is to pull new terminology to new document. need to know beforehand. [17:20:28] Because 3161 is on std track, deployed for years, and now adding in new terminology, is high risk, aggrevating [17:21:23] Stefan agree. [17:21:33] discussion about terminology as informational is easier [17:21:57] any other comments to security issues? [17:22:15] Advance RFC 5280 to Draft Standard, David A. Cooper [17:22:23] David. [17:23:25] brief update on process [17:23:41] alexmcmahon leaves the room: Replaced by new connection [17:23:54] stefan.santesson joins the room [17:24:13] 300 features [17:24:49] firstly, note normative 'down' references. (ran through the nits engine) [17:24:58] refs to PS from DS [17:25:17] list points to i8n [17:26:40] slide on authorityInfoAccess [17:27:18] MIME type and file extension issues [17:27:49] slide on User Notice policy qualifier. [17:28:03] certs with a qualifier. they use 'VisibleString' encoding. [17:28:24] 5280 says 'should UTF-8 but can use IA5' [17:28:36] if thats what everyone is using, (visiblestring) then we should permit. [17:29:04] Stefan: x509 says? [17:29:18] David/Russ: nothing: its our stuff. [17:29:46] Stefan could be 'be liberal.../...conservative' ? driver? [17:29:55] Russ no, its a different tag, we have to say if its legal [17:30:15] David doesn't forbid clients from accepting [17:30:49] Tim. but if we say 'conforming CAs must not..' [17:32:05] Paul. Implementor reading the ASN1 would not know this, would be valid by ASN1 [17:32:23] Russ if you read only the syntax of the proto you will screw it up [17:33:24] PHB joins the room [17:33:35] (missed thread sorry) [17:33:41] David. VisibleString is what I'm seeing [17:34:13] some features specified, but cannot find implementations. [17:35:14] mostly relating to AIA/SIA/CDP, in certs, crls [17:35:59] Steve, understand obs. being made, but our requirements are on s/w generally not what people are seen to do. [17:36:59] PaulH. have to be two interoperable implementations [17:37:26] large disagreement in SMIME wg about 2 issuers, consumers. aim low, wait for objects. [17:37:55] Steve we have CA and will volunteer time from my group to help [17:37:59] (to see if can help) [17:38:38] Tim. steve is right. have to have evidence beyond webpage, hard to claim interop otherwise [17:38:50] might want to decide to pull the plug on name constraints on X400 names [17:38:59] Melinda leaves the room [17:39:02] stefan.santesson leaves the room [17:39:18] David, need to know what counts as feature and what is a compliance issue [17:39:44] stefan.santesson joins the room [17:39:48] Tim might be opportunity to slim 5280 down [17:39:55] Stefan continue [17:40:32] David notAfter with 9999xx dates (embedded) [17:40:40] (floor) can provide pointers to implementations [17:41:12] there are still implementations around that will not support validity dates > 2038 (the 32-bit time_t wrap) [17:41:16] X.400 name constraints and IP addresses [17:41:26] do you need that said to the floor or are you here? [17:41:29] (mrex) [17:41:59] Stefan has spoken to the meeting [17:42:13] .. so they don't conform. [17:42:51] Not yet tested: [17:43:18] i8n, X400 name constraints. SIA/AIA use for path discovery [17:43:26] Paul Hoffman I can help with some of the i8n stuff [17:45:26] Tim. level of detail admirable, but more than absolutely required. [17:45:28] cmadson-ietf joins the room [17:45:43] you're stretching on some things, we can sit down, see if we need to explore. eg x.400 [17:45:47] not feature of our spec [17:46:24] David VisibleString might be a case we want to change. Other things, its for whoever is responsible. [17:47:16] Tim. lets go forward. [17:47:59] Stefan moving on [17:48:00] New ASN.1 for PKIX, Jim Schaad [17:48:26] http://tools.ietf.org/id/draft-ietf-pkix-new-asn1-03.txt [17:48:32] alexmcmahon joins the room [17:48:48] Tim before move on, having workshop in IETF on moving docs to DS. input appreciated sooner rather than later [17:48:59] Back to new ASN.1 [17:49:15] responses to comments. mostly minor changes [17:49:48] some said 'yes but no' [17:49:59] some bugs found. [17:50:52] doc status: no consensus emerging [17:51:29] Tim. observation. [17:51:38] WG makes recommendation, AD can decide to go different direction [17:51:47] even if you ask for it to be informational can put stds, or vice versa [17:52:02] Russ: you 'da man. (laughter) [17:52:14] Tim: don't make this a reason not to move forward. [17:52:21] Stefan key Q, does it update other stds or not? [17:52:33] because if it does, it can't be anything BUT stds [17:53:08] Tim but I heard Jim say 'straw poll but 50:50' [17:53:19] then I think we can work with that, not let slow us down too much [17:53:41] Steve wasn't a poll, two groups of ppl some not wanting the old version replaced even with no bits on wire changing [17:53:56] Steve should we DO a poll to give you advice, so it can go into WGLC cleanly? [17:54:04] Tim if wg has strong consensus won't override [17:54:58] Algorithms and Identifiers for DSA and ECDSA, Quynh Dang http://tools.ietf.org/id/draft-ietf-pkix-sha2-dsa-ecdsa-06.txt [17:55:11] Quynh. [17:55:34] long time wg item. held up because of alg approval in FIPS [17:55:40] recently done [17:56:02] not many changes since 05. [17:56:16] shirleyhm leaves the room [17:56:38] useful comments [17:57:13] proposed change sec3, para 2, 2nd sentence [17:57:22] words around certs, CRL alg. [17:57:31] section 5, last para, last sentence [17:57:51] security considerations. use digsig at least as good as the sig in the certificate [17:58:28] section 5, para 6, last sentence [17:58:29] cmadson-ietf leaves the room [17:59:04] clarify text [17:59:40] PHB leaves the room [17:59:48] shirleyhm joins the room [18:00:05] would we consider changes during WGLC, or do we make new draft and WGLC later? [18:00:10] Steve? [18:00:19] Steve happy to go ahead and WGLC with it sitting here on this [18:00:54] Stefan [18:01:01] finished with WG items, now related work [18:01:13] NSA's "Suite B Certificate and CRL Profile", Lydia Zieglar http://tools.ietf.org/id/draft-solinas-suiteb-cert-profile-01.txt [18:01:25] Sam Ashmore presents on behalf [18:01:39] informational draft. [18:02:01] profile of 5280, using 5480 ECC. [18:02:17] examples of different encoding [18:02:24] cover self, non-self and ee certs [18:02:28] looking for comments to revise [18:02:31] spturner leaves the room [18:02:45] Stefan [18:02:46] Visual representation of certificate based eID, Stefan Santesson [18:03:47] clatze leaves the room: Replaced by new connection [18:04:02] karen.s.seo joins the room [18:04:18] make certificates more visually friendly [18:04:23] clatze joins the room [18:04:53] basic problem: humans need to know who dealing with [18:05:39] the displays of certs are not intelligable [18:06:37] id cards, its clear. can distinguish which is contextually relevant [18:06:54] no common visual design. no common attributes, lack of semantics, labels, i8n [18:07:42] country: of residence, establishment, citizenship? [18:07:47] serialnumber.. used for lots of things [18:08:23] SharonB leaves the room [18:08:32] bottom line: insufficient data for general application, for user to make decisions [18:08:56] where do we have an "Authentication by visual inspection on the part of the user" which acutally works? [18:08:56] 3709 logotypes, adds images, but no graphical design, no semantics or labels [18:09:07] Do you wish this said to a mike Mrex? [18:09:28] discussing with developers [18:09:49] discussing stylesheet to name labels to go with display [18:09:55] no common format/standard for that [18:10:08] RFC3709 is extensible. can define new logotypes, graphical elements [18:10:26] what if we use , to turn eID into one combined image? [18:11:04] possible solution, since 2008 July 1 PDF is ISO standard. [18:11:12] capable of turning scaleable images/prints [18:11:34] sign hash [18:12:10] chocies: keep 2709 intact, go with new OID. define MIME media type [18:12:19] another choice: update 3709 [18:12:24] or third, define new extension. [18:12:49] not possible, is embed into cert, [18:12:56] Q: can embed hash of the content A: yes [18:13:01] thats in 3709 [18:13:49] looks easy task in other ways [18:14:06] useCase: BankID, eID in .SE. 1.5m users [18:14:16] 300 services, supported by national legislation [18:14:27] customized apps for trust, session, ui. [18:14:34] cert image could enhance [18:15:58] controversial issues [18:16:13] conflict in image: jane doe photo but john doe name [18:16:29] What is proposed sounds like a mechanism to create something to result in a "warm and fuzzy feeling" for the UI, while not providing any security enhancement whatsoever, since it is entirely under control of the issuing CA. If we want to increase the security, we should (a) require the clients to limit themselves to a VERY low number of acceptable CAs and (b) require that CA to make better use of usage constraints in order to allow more automatic verification of the server certs (instead of asking to the users to do what the CAs failed to do). Having a "secure" directory that indicates which CA is acceptable for issuing server certificates of a certain vendor/business would also help big time over the current situation [18:17:37] [again I ask: mrex... do you want this SAID TO MIKE -ggm] [18:18:31] stefan shows slide of UI policy, applications able to turn cert into meaningful display [18:18:39] path forwad: seeking interest [18:18:57] vistual eID project: http://AAA-sec.com/visualeid/ [18:19:01] stefan@AAA-sec.com [18:19:35] Samuel.Ashmore leaves the room [18:19:37] Samuel.Ashmore joins the room [18:20:09] Massimilio. feel more comfortable with different approach, not an image [18:20:18] but, something, different from content [18:20:40] XML, rules, sheets, so that if I use a device, with display capable of doing transformation, b&w screen, greyscreens, hidef [18:21:43] (at mike q) [18:23:10] response from Stefan: not security feature, usibility feature, happy to discuss on list [18:23:21] Paul Hoffman, start as experimental even though 3709 is on stds track [18:23:52] more than chrome [18:23:57] yangqinqin09 leaves the room [18:24:16] specifically 3709 allowing indirect grabbing, in unsecure channel, very hesitant, [18:24:24] automatically update no. [18:24:31] Stefan. easiest way, not even update. do extra extension [18:24:54] yangqinqin09 joins the room [18:25:00] karen.s.seo leaves the room [18:25:55] (unknown) interesting approach. but, discussions in past, browsers hesitent to adopt logotypes. vetting before inclusion. will only increase problem. back covering/liability [18:26:14] yangqinqin09 leaves the room [18:26:19] Stefan have to talk about that. extended validation eg. perhaps helps [18:26:44] 3minutes [18:27:33] Wes problem with UI improvements, people always go to the flashy objects [18:27:50] This "visual improvement" provides plenty of room for social engineering. So it has a serious potential to impair security. I'm also worried about inflating raw bit size of X.509 certificates. [18:27:53] if we allow the end object, to define the graphs ppl see, nothing prevents looser from generating image identical to elite CA to spoof [18:28:04] yangqinqin09 joins the room [18:28:13] problem with images, never protect the image is 'the only one' [18:28:52] Jim its not about hash collisions its about fooling the user [18:29:21] users will look at graphic, as opposed to the name [18:29:34] Steve. need to separate misbehaving CAs, they can do that with naming today. [18:29:58] Charlie Kaufmann Microsoft. if cert is trusted to assert then do something. when would a cert NOT be trusted to provide an image [18:30:02] The visual update is only to help CAs business models, it will not improve, but rather impair the bottom line security [18:30:03] Stefan comparable to extended validation [18:30:22] not a red bar, but not a green bar [18:30:37] Charlie local policy? [18:30:43] Stefan allow display when beyond level [18:31:55] Chen Shing, comments on this spec. promising application ubiquitous computing. cellphone, pda, facebook etc. another application, ISA cecurity working with wash gov enhanced driver license with rfid. looks like in general, carrier of such cert is important. design spec should we concern limitations of carriers, physical devices. make it popular, get used, concerns of platform h/w and s/w [18:32:05] lellel leaves the room [18:32:11] Tim. one final comment. important to discuss usability. [18:32:26] involve applications people [18:32:35] jimsch1 leaves the room [18:32:56] Stefan Agree. [18:33:01] Blue sheet check and we're done. [18:33:14] ggm leaves the room [18:33:31] David Cooper leaves the room [18:33:33] stefan.santesson leaves the room [18:33:33] semery leaves the room: Disconnected [18:33:34] shpark leaves the room [18:34:03] carl-ietf leaves the room [18:34:14] Samuel.Ashmore leaves the room [18:35:29] PHB joins the room [18:35:39] gih leaves the room [18:37:05] polk.tim leaves the room [18:37:30] clatze leaves the room [18:49:51] sftcd leaves the room [18:58:00] alexmcmahon leaves the room [19:09:25] SharonB joins the room [19:09:36] SharonB leaves the room [19:35:56] PHB leaves the room [20:04:34] PHB joins the room [20:19:18] shirleyhm leaves the room [20:24:08] ggm joins the room [20:24:16] ggm leaves the room [20:34:45] HASIB3CD1A020 joins the room [20:34:55] HASIB3CD1A020 leaves the room [20:42:41] gih joins the room [20:45:31] gih leaves the room [21:04:37] PHB leaves the room [21:04:45] PHB joins the room [21:07:11] gih joins the room [21:11:03] gih leaves the room [21:19:14] PHB leaves the room [21:28:04] gih joins the room [21:29:48] gih leaves the room [22:39:18] gih joins the room [22:45:24] gih leaves the room [23:51:49] mrex leaves the room