Monday, 5 November 2012< ^ >
Room Configuration

[17:42:13] yoav.nir joins the room
[17:42:18] <yoav.nir> Testing
[19:46:35] yoav.nir leaves the room
[20:09:24] hillbrad joins the room
[20:10:17] hillbrad has set the subject to:
[20:11:50] yoav.nir joins the room
[20:13:27] Melinda joins the room
[20:14:56] <hillbrad>
[20:17:36] hillbrad has set the subject to:
[20:18:55] SM joins the room
[20:20:51] hillbrad has set the subject to:
[20:21:19] <hillbrad> Tim Moses and Steve Hanna chairing
[20:21:37] <hillbrad> first two slides of:
[20:21:43] <hillbrad> note well
[20:21:53] <hillbrad>
[20:22:12] <hillbrad> Tim Moses: subject matter is PKI and how it is practiced in the web today
[20:22:23] <hillbrad> ... have been some issues in how it is practiced "on the ground"
[20:22:30] <hillbrad> ... first step in a journey to correct some of those things
[20:22:38] <hillbrad> ... talking about PKI is practiced today
[20:22:49] <hillbrad> ... not about new ways it should be practiced
[20:23:02] <hillbrad> next slide
[20:23:15] <hillbrad> agenda
[20:23:30] Dowon Kim joins the room
[20:23:44] <hillbrad> presentations from Jeff Hodges, Ben Wilson, questions, comments and wrap-up
[20:24:02] <hillbrad> we will hold comments and questions until after both presentations and lots of time will be left
[20:24:32] Sean Turner joins the room
[20:24:54] <hillbrad> during item 4 and probably item 5 on agenda, time to talk about problem statement and proposed draft charter that has been circulated
[20:25:05] <hillbrad> will be presented on the screen and considered
[20:25:20] <hillbrad> will take a minute to wrap up before time expires and ensure all outstanding items addressed
[20:25:45] sftcd joins the room
[20:25:56] <hillbrad> next slide: problem statement
[20:26:11] <Melinda> Many thanks to hillbrad - this is great.
[20:26:30] <hillbrad> "Correct operation of the Web PKI depends upon
coordination in the implementation, configuration,
and deployment of its components (servers, clients,
and certification authorities). These components are
commonly developed and operated by unrelated
organizations, yet important aspects of their
functionality are not publicly well specified. This
frequently leads to problems for the Web PKI's
participants (application owners, infrastructure
providers, and equipment vendors). Documenting
these problems and their causes is required in order to
have a basis for overcoming them."
[20:27:15] <hillbrad> please keep this problem statement in mind as we go through the next hours and whether what we are doing is appropriate to addressing this problem
[20:27:19] <hillbrad> next slide: document editors
[20:27:33] Andrew Chi joins the room
[20:27:49] <hillbrad> generally four documents so far proposed, 7 volunteers
[20:27:51] <hillbrad> Trust model - Iñigo Barreira, Bruce Morton
Certificate, CRL, and OCSP field and extension
processing - Ben Wilson, Robin Alden
Revocation - Phillip Hallam-Baker, Gary Gapinski
TLS stack operation - Adam Langley
[20:28:43] =JeffH joins the room
[20:28:55] <hillbrad> don't feel excluded, if anyone else feels this is a role they'd like to take, can be paired with these editors
[20:29:13] <hillbrad> and will be calls later for expressions of interest and participation in review
[20:29:22] hillbrad has set the subject to:
[20:29:31] <hillbrad> <end> Tim Moses
[20:29:36] <hillbrad> now up, Jeff Hodges
[20:29:52] <hillbrad> Web PKI: Background and Issues
[20:30:31] yngve_n_pettersen joins the room
[20:30:31] <hillbrad> JeffH: What Ben Wilson and I have crafted is a little different than just from our own perspectives
[20:30:42] <hillbrad> ... survey of general set of issues and our perspective
[20:30:48] <hillbrad> next slide: what is web pki?
[20:31:22] <hillbrad> The Public Key Infrastructure (PKI) that is
–Embedded in various software packages/components..
•HTTPS clients
–Notably Web Browsers
–Operating Systems, Mobile Apps
–OpenSSL, curl, wget, Java, Ruby, Python
•Web Servers
•Certification Authorities
–Deployed pervasively across the Internet
–Highly user visible
–Depends upon a particular (complex) object shared amongst participating software: Public Key Certificates
[20:31:30] joins the room
[20:31:41] <hillbrad> next slide: The Players
[20:31:48] <hillbrad> End users
–“Are there any issues with my present use of this web app? Is it secured?”
•Certificate Holders
–AKA “web application providers”
•Hardware & Software Providers
–E.g. Browser vendors, web server vendors, TLS/SSL Concentrators etc.
•Certificate Issuers
–AKA certificate authorities (CAs)
[20:31:55] <hillbrad> next slide
[20:32:04] <hillbrad> Web PKI Issues
•There are issues with the presently-deployed Web PKI affecting all the players:
•Web PKI is specified in IETF PKIX specs
–Which profile ITU-T X.509 specs
–Originally concocted in mid-1990’s (pushing 20yrs)
–All these specs have evolved
–Complicated; many “options”
–Prone to interpretation by implementers in various places
[20:32:16] JcK joins the room
[20:32:22] Satoru Kanno joins the room
[20:32:39] <hillbrad> next slide
[20:32:45] <hillbrad> Web PKI Issues [2]
•WebPKI-encompassing software packages/components have:
–Evolved over time
–Individual interpretations of PKIX specs
•Yields user-visible inconsistent behavior
[20:33:01] <hillbrad> next slide
[20:33:03] garygapinski joins the room
[20:33:10] <hillbrad> Web PKI Issues [3]
•Certificate holders (Web App Providers)
–Uncertainty regarding user agent behavior relative to:
•Web App’s presented certificate & cert chain
•CA’s OCSP/CRL services
–Can result in..
•different user experiences between UAs
•some users not being able to use web app
•Security vulnerabilities
[20:33:50] <hillbrad> next slide: Web PKI Issues [4]
•Certificate Issuers (CAs) challenges regarding:
–Certificate complexities
•accurate/correct AIA info
•Subject naming conventions
–CRL and OCSP content/operational complexities
•Which clients accept what spec interpretations?
•E.g., necessary to include nonce in OCSP response?
•Client cert chain processing peculiarities?
[20:34:22] <hillbrad> Ben can talk about this some more
[20:34:25] <hillbrad> next slide: Web PKI Issues [5]
•End users
–Inconsistency across browsers in terms of
•Behavior given cert contents, cert chain, and cert status checking
•Security indicators
–Web apps “breaking” due to impedance mismatch between
•presented cert(s) + revocation infrastructure ..and..
•browser implementations
[20:34:37] Karen O'Donoghue joins the room
[20:34:38] dseomn joins the room
[20:35:00] <hillbrad> next slide: Web PKI Issues [6]
[20:35:09] <hillbrad> Multi-stakeholder
–Revocation checking and performance
•As a cert holder, what is your CA doing?
•How does that really affect performance for your clients?
•GET vs. POST, cache-ability of responses
•Impact of / requirements for Stapling
•Different versions
•Complex chain of rules/validation between registrars, CAs, certification validation code and URL bar display rules
[20:35:35] Stefans joins the room
[20:36:22] <hillbrad> whole pile of applications for new TLDs, many of which are internationalized, this is only going to get worse
[20:36:29] <hillbrad> Ben will talk more aboud detailed things to survey
[20:36:31] <hillbrad> next slide:
[20:36:38] <hillbrad> Example Issues to Survey
•Criticality of the nameConstraints extension
•Use of the OCSP "good" certStatus value
•Behavior of IRIs, IDNA 2003 vs. 2008, Unicode restriction profiles
[20:37:02] <hillbrad> up next, Ben Wilson, DigiCert
[20:37:13] hillbrad has set the subject to:
[20:37:43] <hillbrad> Ben Wilson: Here to present CA perspective on web PKI
[20:37:45] <hillbrad> next slide
[20:37:47] <hillbrad> Background
• Web PKI has been evolving for 15+ years
• Web PKI environment is global and open
(www=wild, wild west) – “Neither CAs nor browsers
have market incentives to compete on the basis of security.”
• Many legacy and new implementations do not
conform to the RFCs promulgated by PKIX.
• A survey of PKI on the web will inform us on
functionalities and an evolution strategy.
[20:38:12] <hillbrad> focusing on HTTPS and browser environment primarily
[20:39:06] <hillbrad> sometimes PKIX RFCs are hard to understand what supposed to and not supposed to do
[20:39:10] Gabriel Montenegro joins the room
[20:39:19] <hillbrad> next slide: Scope
• Practical, real‐world observations and
implications re: the behavior of clients,
servers, proxies, etc.
• Not the user interface (area for W3C or browsers)
• Mobile devices and apps included in scope
• Problems identified with certificate processing
(i.e., there is a natural tendency toward disorder and chaos,
with its resulting corollary‐“if anything can go wrong, it will.”)
[20:39:39] <hillbrad> ... my view of the scope, we will address this explicitly in the charter and problem statement
[20:40:00] <hillbrad> ... all the compnents, hardware and software that deal with X.509 certificates
[20:40:12] <hillbrad> ... not user interface, perhaps a topic for W3C
[20:40:23] <hillbrad> ... not considering addressing client authentication w/ X.509
[20:40:34] <hillbrad> ... do want to consider mobile devices in scope, often the hardest to understand
[20:40:55] <hillbrad> next slide: Behaviors to Survey
• Criticality of Name Constraints Extension
(Mozilla new subCA Policy vs. Apple’s implementation)
• Effects of revocation on access to content
("upon transmission or receipt of a fatal alert message, both
parties immediately close the connection”)
• CRL‐fed OCSP responses vs. direct OCSP (RFC
2560 discussion of “good” responses)
• RFC 2818 (2000) – use of CNs deprecated in
favor of SANs (but what devices choke on certs w/o CNs?)
[20:41:11] <hillbrad> ... to recap criticality of name constraints
[20:41:28] <hillbrad> ... after DigiNotar experience, Mozilla wanted to force constraints on external subordinate CAs
[20:41:38] <hillbrad> ... talking about name constraints, standard specifies this as a critical extension
[20:41:48] <hillbrad> ... causes app failure if not understood
[20:42:10] <hillbrad> ... OS X and Apple doesn't understand, so CA setting this extension according to PKIX strict rules
[20:42:24] <hillbrad> ... would work on some browser platform and not others
[20:43:19] <hillbrad> ... if I am wrong on any of this, I apologize, I am not a full expert and looking to learn by conducting this survey
[20:43:31] <hillbrad> EKR at mic, fatal alert confused with OCSP here
[20:43:38] metricamerica joins the room
[20:43:49] <hillbrad> AGL: agreed, not sure why fatal alert is there
[20:44:14] <hillbrad> Ben Wilson: understood
[20:44:22] leifj joins the room
[20:44:46] <hillbrad> Ben Wilson: what apps still fail 12 years after CNs deprecated in RFC 2818 if CN is not present
[20:44:49] <hillbrad> ... next slide
[20:44:59] <hillbrad> Behaviors to Survey (cont)
• RFC 5280 dNSName processing
• RFC 5280 certificate chain variables (name
encoding, policy OIDs, superfluous certs, signature algorithms,
revocation checking methods, AIA chasing, etc.)
• Cache/store behaviors (CRLs, OCSP, roots, chains, etc.)
• OCSP GET vs. POST and Nonce (CDN‐friendly)
• Key strength and algorithm support (SHA256, etc.)
• OCSP Stapling support
[20:45:22] <hillbrad> ... to get into all nuances and experiences and personal knowledge these slides could be much longer
[20:46:22] <hillbrad> ... 5280 chain building variables - what capabilities to applications really have, especially in face of missing elements
[20:46:28] <hillbrad> ... how are policy OIDs handled
[20:47:12] <hillbrad> ... revocation checking, requirements on consistency of revocation mechanisms through the certificate chain
[20:47:21] <hillbrad> ... caching and storing behaviors
[20:47:32] fenton joins the room
[20:48:10] <hillbrad> ... to browsers and applications respect CA declared lifespans of revocation responses or use their own
[20:48:51] <hillbrad> ... CDN-friendly OCSP requires GET without nonce, vs. older POST behavior requiring fresh response
[20:49:07] <hillbrad> ... poor availability and performance characteristics
[20:49:32] <hillbrad> ... how do you identify what is vulnerable and how do you replace algorithms declared insecure
[20:49:44] <hillbrad> next slide: Goals
• Identify the current landscape and document
the relevant maturity model
• Develop a roadmap to address legacy systems,
pinpoint status of adoption and progression
• Guide the evolution and migration of WebPKI
• Provide guidance for developers for present
use and to plan for future developments
• Encourage the harmonization of behaviors
[20:51:11] <hillbrad> ... why would a CA want to care about consistent implementation if apps processing certificate are each going to do something different. a 2-way street on consistency
[20:51:19] <hillbrad> <end> Ben Wilson
[20:51:28] <hillbrad> Tim Moses: close to opening floor for question
[20:51:36] <hillbrad> Paul Hoffman: question for the chair
[20:51:46] <hillbrad> ... some conflicting things for UI as in scope or out of scope
[20:52:04] <hillbrad> ... may be hot button issue, can you elucidate, are we are or not talking about that?
[20:52:14] <hillbrad> JeffH: browser chrome or chrome the browser?
[20:52:21] <hillbrad> Paul Hoffman: browser chrome in general
[20:52:33] <hillbrad> Ben Wilson: to respond, examples of the problems, but not what this group is going to try to solve
[20:52:45] <hillbrad> ... just examples of current state of affairs, not going to say anything about it
[20:52:51] <hillbrad> Paul Hoffman: asking the chairs
[20:53:02] <hillbrad> Tim Moses: if charter is not clear, it should be, anything to do with browser UI is out of scope
[20:53:15] <hillbrad> ... we will look at charter shortly, and can enhance it if this is not clear
[20:53:28] <hillbrad> ... before we take questions, clarify one thing, problem statement is back on display
[20:53:46] <hillbrad> ... have presentations raised questionns about this problem statement that we should put to bed
[20:53:59] <hillbrad> Phil Hallam-Baker: we are in danger of shooting ourselves in the head before we even start
[20:54:09] <hillbrad> ... part of purpose of web PKI is to communicate informatoin to end user
[20:54:30] <hillbrad> ... if charter says you shall not do that, will generate process objections to any mention of user
[20:54:45] <hillbrad> ... precice manner in which it is presented to user may not be to in scope
[20:54:54] <hillbrad> ... the fact you are going to talk to the user has to be in scope
[20:55:00] <hillbrad> ... talking security without talking users is talking nonsense
[20:55:07] linuxwolf joins the room
[20:55:22] <hillbrad> John Clemson: if the way whatever you do here is impelmented with a pop up that says "gibberish" "OK", you have failed
[20:55:39] <hillbrad> Tim Moses: if behavior of user agent is to give notice, that will be recorded, details of how notice is given is not in scope
[20:56:27] <hillbrad> John Klensen: don't have to specify presentation, but part of thing I belive from conversations is screw ups come fro mnot having right information available to present to user in way that makes sense
[20:56:59] lef.jpn joins the room
[20:57:02] <hillbrad> Paul Hoffman: what you have proposed, Tim, is insufficient, if info to be presented to user w/o discussion of how it is presented - e.g. if a connection fails, that is a presentation to a user
[20:57:15] <hillbrad> ... if fails with some information to user, that is different than without that information
[20:57:21] <hillbrad> ... what extra info from browser might be
[20:57:43] <hillbrad> ... already down the slippery slope, I believe you need to be there, has to be part of discussion
[20:58:08] <hillbrad> Eric Rescorla: find this baffling. the idea was to address confusion about how PKI actually usedon web, document that rather than 5280
[20:58:22] <hillbrad> ... now documenting what red box shown to user? that is nuts
[20:58:37] <hillbrad> Adam Langley: when we write these documents, do we use names? do we way firefox up to version X, etc?
[20:58:57] <hillbrad> Eric Rescorla: depends- if it is a large number of names, we wouldn't
[20:59:10] <hillbrad> Adam Langley: if in a table in an RFC, might be reasonable
[20:59:15] <hillbrad> Area Directors nods
[20:59:25] <hillbrad> EKR: 500 page document resulting probably didnt' work out well
[20:59:37] <hillbrad> Yoav Nir: documentation of existing practice could include or not existing UI
[20:59:47] <hillbrad> ... not a research paper, but input for future activity that will make things bettr
[20:59:59] <hillbrad> ... cant make better without fixing UI, so we need to have UI documented as it is now
[21:00:09] <hillbrad> ... really is different among browsers, but converging in recent years
[21:00:25] TV joins the room
[21:00:29] <hillbrad> Steve Hanna: hearing rough consensus in room that some aspects of UI, not the details of buttons, pictures
[21:00:40] <hillbrad> ... but functional aspects of what is shown needs to be included and in scope
[21:00:43] <hillbrad> EKR: Really?
[21:00:59] <hillbrad> AGL: When describing current behavior, describe ui, but do not PRO-scribe UI
[21:01:16] <hillbrad> Steve Hanna: documentation at a high level of what information is shown to user in failure cases
[21:01:34] <hillbrad> AGL: agree as far as documentation goes, hesitate that chagnes happen much faster than RFCs update
[21:01:52] <hillbrad> Evan? Williams: if we are surveying UIs, document if UI is causing some problems
[21:02:04] <hillbrad> ... if causes security related issues, document the problems rather tha correct behavior is a good thing
[21:02:20] <yngve_n_pettersen> Channel: regarding documentation of UI and current practices, and some improvements, see W3C Web Security Context UI: <>
[21:02:21] <hillbrad> ... not value in documenting good use cases, but documenting UIs that cause security problems a good thing
[21:02:34] cw joins the room
[21:02:49] <hillbrad> PHB: documenting really bad practices a good thing: either tell user too much information they can't act on, can't understand
[21:03:09] <hillbrad> ... another problem is when user not told enough. a balance, cant' say ignore user
[21:03:20] <hillbrad> Tim Moses: strikes me as problematic to include user in technical documentation
[21:04:20] <hillbrad> EKR: back to first principles here: allow browsers to know how CAs behave, if a new client, to know how others behave, to CAs know how to behave how browser makers like
[21:04:26] hildjj joins the room
[21:04:41] john.levine joins the room
[21:04:51] <hillbrad> ... reasonable scope of work, but things that will be driven from that - will documenting UI enhance those goals or be a waste?
[21:05:11] <hillbrad> Yngve Pettersen's comments in channel being voiced at mic.
[21:05:22] richard.barnes joins the room
[21:05:30] <richard.barnes> test
[21:05:36] JimGalvin joins the room
[21:05:37] <hillbrad> Leif Johannson: didn't we already have a charter discussion on this already?
[21:05:54] richard.barnes leaves the room
[21:05:56] <hillbrad> Tim Moses: yes, but understanding was that IETF does not deal with user interfaces, execpt in abstract way
[21:06:05] <hillbrad> ... would be going beyond to talk about impact and response of users
[21:06:06] richard.barnes joins the room
[21:06:28] <hillbrad> Hannes Tschofenig: sometimes too strict on UI restrictions: if it makes sense, we should talk about them
[21:06:36] <hillbrad> ... more at the conceptual level than details of how UI should look like
[21:06:48] <hillbrad> ... i18n as an example or groups that require interaction with user, e.g. policy languages
[21:07:03] <hillbrad> ... what is reasonable for user to understand, how would he create those, something to think about
[21:07:12] <hillbrad> ... still makes sense to talk about UI without standardizing details
[21:07:21] <hillbrad> Steve Hanna: drawing a line under this topic, adequately discussed
[21:07:34] <hillbrad> Tim Moses: try to discern the consensus of group on how deep into UI to go at some point
[21:07:44] richard.barnes leaves the room
[21:07:50] <hillbrad> ... at this point, throw up set of questions we should be addressing today
[21:07:54] <hillbrad> ... don't need to go through in order
[21:08:11] <TV > We don't need to get very deep into UI. But we can't do anything useful if we decide we are not going to talk about it at all.
[21:08:12] hillbrad has set the subject to:
[21:08:21] <hillbrad> Questions
1) Is the problem clear, well-scoped, solvable, and urgent?
2) Do we believe that product vendors will take notice?
3) Is the proposed charter (Draft 4) suitable?
4) Are there others willing to serve as editors?
5) Who is willing to review documents and/or comment on the
mailing list?
6) Who feels that a working group should not be formed?
7) Who feels that a working group should be formed?
[21:08:25] <TV > Why am I TV here?
[21:08:32] <JcK> We've moved on (or maybe not), but I want to stress that the issue is not the appearance of the UI, but making sure that we identify the key information that must be available to the UI and how/why we think that information should be handled (or must be handled for the user to make whatever decisions the user should make). Indeed, identifying what the user has to make decisions about and what can be done automagically is part of the question. The particular presentation of that information in/from a UI is reasonably out of scope (and has almost always been treated as out of scope in the IETF).
[21:08:39] <hillbrad> Leif Johannson: bullet 2, does it matter whether vendors take notice?
[21:08:54] <hillbrad> Tim Moses: value generated would be imparied if didn't lead to improvements in future versions of products
[21:09:05] <hillbrad> Tim Moses: a record of how things done in 2012, value is questionable
[21:09:12] <TV > +1 JcK
[21:09:22] <=JeffH> jck = John Klensin
[21:09:27] <hillbrad> Scott Cantor: comment, not a rathole: not clear on what security end goal model in mind for practices being documented is
[21:09:36] richard.barnes joins the room
[21:10:04] <hillbrad> ... documenting current practices without making clear what the model should be, hand-wavey security vs. really trying to strongly authenticate parties on the web
[21:10:19] <hillbrad> ... what is end state to reach with practices documented with an aim towards improvement
[21:10:28] <hillbrad> Tim Moses: we don't want hand-wavey security
[21:10:31] coopdanger joins the room
[21:10:31] <TV > Test
[21:10:38] <TV > agh still a robot
[21:10:39] richard.barnes51227 joins the room
[21:10:39] richard.barnes51227 leaves the room
[21:10:39] richard.barnes51729 joins the room
[21:10:39] richard.barnes51729 leaves the room
[21:10:39] richard.barnes90403 joins the room
[21:10:40] richard.barnes90403 leaves the room
[21:10:40] richard.barnes20460 joins the room
[21:10:50] TV leaves the room
[21:10:51] richard.barnes leaves the room
[21:10:54] <hillbrad> ... in wake of several incidents, notably DigiNotar, browsers had to issue new versions of products to revoke impacted keys
[21:10:56] TV joins the room
[21:11:03] <hillbrad> ... clearly revocation doesn't work
[21:11:05] <TV > test
[21:11:11] TV leaves the room
[21:11:16] <hillbrad> ... understanding why, would be a helpful outcome, hope would lead to improvements
[21:11:41] <hillbrad> Scott Cantor: idea to have a sliding scale of capabilities that people can tap into - lock down creates pushback
[21:11:53] <hillbrad> Tim Moses: not trying to proscribe how things should work in this effort
[21:12:03] <hillbrad> Tim Moses: hope it will lead to improvement, but not today's problem
[21:12:11] <yoav.nir> I'm trying to figure out what the purpose of this work is. Is the output document meant for the next company/person who wants to implement a browser? or is it input for the next working group that will try to make PK better? Or is it documenting best practice in the hope of getting the CAs aligned?
[21:12:16] <hillbrad> AGL: disagree on point 2, documentation is extremely valuable in itself
[21:12:20] PHB joins the room
[21:12:37] <hillbrad> ... as an implementer, lots of things to do not documented in any RFC, avoid breaking users
[21:13:04] <hillbrad> ... lots of bugs filed, we know what we need to do, but in many other aspects we don't know what we need to do
[21:13:21] <hillbrad> ... stuck up against other constraints where this WG cannot produce work (social, etc. constraints)
[21:13:32] <hillbrad> Steve Hanna: a bunch of MUSTS and SHOULDS not the goal of this WG
[21:13:50] <hillbrad> Paul Hoffman: charter: future activities may attempt to say how the web SHOULD work
[21:13:58] <hillbrad> ... after we have surveyed, then we will proscribe
[21:14:19] <hillbrad> ... if intent is not to proscribe, charter is way off, most people thought intent was to proscribe, just later
[21:14:41] <hillbrad> ... might proscribe if closed connection, might say you SHOULD follow with info to user
[21:14:58] <hillbrad> Tim Moses: I read future activities MAY proscribe
[21:15:07] <hillbrad> Paul Hoffman: future activites not of the WG?
[21:15:10] <hillbrad> Tim Moses: yes
[21:15:38] <hillbrad> Steve Farrell: as I understand charter, this WG not having any SHOULDS but might have us chartering something some later time
[21:15:56] <hillbrad> PaulHoffman: read as an aim
[21:16:23] <hillbrad> Ryan Sleevi: disagree w AGL regards point 2. big issues of concern has been mistaken set of assumptions
[21:16:35] <hillbrad> between browsers, CAs and operators in how the others will practice
[21:17:06] <hillbrad> ... doc effort with no form of prescription, description serves a value to understand what may not be implemented or impl incorrectly by various parties
[21:17:27] <hillbrad> PHB: two problems with PKI: 1) big garden full of weeds, need to clear out to see what is there.
[21:17:47] <hillbrad> ... won't have a garden by removing weeds, need to plant something, create new specs in security area, not ops area
[21:17:58] <hillbrad> ... doc that says this is how it works today, this way will work, other ways won't
[21:18:13] <hillbrad> ... whether MUST, SHOULD or MAY, looks like a spec
[21:18:46] john.levine leaves the room
[21:18:53] <hillbrad> Dan Druta: will surface limitations in whole ecosystem... we are talking about web apps packaged and installed on mobile devices, that is a change in how that ecosystem is set up
[21:19:28] <hillbrad> ... web app developers are not just web sites, for some cost of acquiring certs is prohibitive and revocation doesnt' work well in mobile to remove device rather than whole chain
[21:20:11] <hillbrad> Bas Hardiger: break science projects into three phases, collect data, analyze data, then can make a proper recommendation. put off recommendations for future charter recommendation
[21:20:15] Gabriel Montenegro leaves the room
[21:20:24] <richard.barnes20460> s/Bas Hardiger/Wes Hardaker/
[21:20:27] <hillbrad> ... very hard to do surveys and get accurate information. ca world is quite large, very difficult to do
[21:21:08] <hillbrad> ... nanogs etc. not easy to come with a short set of questions and get data. need to ask after every question, "If Not, Why?" reasons will be critical: speed, unreliable network, etc.
[21:21:20] <hillbrad> ... need that to come to helpful conclusions
[21:21:45] hillbrad thanks richard and others for name help
[21:22:06] <hillbrad> Tim Moses: some confusion on boundaries of scope.. is that clearer in everybody's mind?
[21:22:39] <hillbrad> Tim Moses: we will not be proscriptive, we will not talk about specifics of presentation
[21:22:49] <=JeffH> s/Bas Hardiger/Wes Hardacre/
[21:23:25] <hillbrad> Steve Hanna: would like to propose a consensus chat: some aspects of user experience, from a functional standpoint should be included - what information does the user get regarding PKI
[21:23:31] <hillbrad> ... any comments on that?
[21:23:38] <hillbrad> EKR: I'm really confused
[21:23:40] <garygapinski> Not "what the user sees", but what message is conveyed to the user
[21:24:01] <hillbrad> Steve Hanna: a description of what informatoin the user gets wrt PKI
[21:24:11] Melinda leaves the room: Computer went to sleep
[21:24:12] <hillbrad> EKR: confused, could say chrome does soft fail, other does hard fail
[21:24:26] <hillbrad> ... chrome doesn't say when ocsp doesn't work, other puts up a flag
[21:24:36] <hillbrad> ... want to know how much work we are thinking of taking on
[21:25:08] <hillbrad> AGL: your examples of what browsers do hard/soft fail could be in scope, later example are a waste of words, hope we will avoid it
[21:25:45] <hillbrad> Steve Hanna: consensus check: that we include functional aspects of what is displayed to the user in the survey
[21:25:51] <garygapinski> semantic aspects
[21:25:57] <hillbrad> Richard Barnes: confused by survey thing, not actually appear in charter
[21:26:29] <hillbrad> Tim Moses: you are right, idea was that there are editors responsible for compiling documents, may choose whichever way they wish, survey vendors, set up a test lab, not telling editors how to achieve objective
[21:27:10] <hillbrad> Jeff Hodges: Ben used the term survey in the sense of writing documents that people are not distributing surveys but rather surveying the landscape
[21:27:26] <hillbrad> AGL: nitpick, not just info displayed to user, but what user allowed to do, e.g. bypass warning
[21:27:36] <hillbrad> Steve Hanna: still functional, good plan
[21:28:02] <hillbrad> Dan Druta: not just browsers, user agents more than just browsers, full systems, cars with browsers embedded
[21:28:12] <hillbrad> ... user interface agonistic but aware of what needs to happen
[21:28:35] <hillbrad> Steve Hanna: functional doc of info provided to user on PKI and what user can do in response
[21:28:37] coopdanger leaves the room
[21:28:45] <hillbrad> ... can we have a hum: such info should be in scope
[21:28:49] <hillbrad> hmmmm.......
[21:28:53] <hillbrad> those not:
[21:28:56] <hillbrad> *crickets*
[21:29:19] <hillbrad> Tim Moses: improved clarity on boundaries of scope, any remaining questions?
[21:29:44] coopdanger joins the room
[21:29:44] <hillbrad> Steve Hanna: question 1 answered, question 2 discussed
[21:29:53] <hillbrad> Tim Moses: have we put #2 to bed?
[21:30:06] <hillbrad> Steve Hanna: 3 is about charter
[21:30:33] <hillbrad> Tim Moses: interest in sentence by sentence review of charter?
[21:30:42] <hillbrad> *no interest*
[21:30:56] <hillbrad> Paul Hoffman: just added a new topic not in the charter
[21:31:10] <hillbrad> Steve Hanna: being UI? would expect included in existing deliverables
[21:31:14] <hillbrad> Tim Moses: yes
[21:31:30] <hillbrad> Paul Hoffman: don't see where examples agreed to fit into the four deliverables in charter
[21:31:46] <hillbrad> ... soft fail vs. hard fail example doesn't fit anywhere
[21:32:08] <hillbrad> AGL: those are in context of revocation, trust model, etc. so fit in the model
[21:32:23] <garygapinski> "user experience" is a bit vague - I would prefer user communication (i.e., itemizing messages delivered to user)
[21:32:24] <hillbrad> Tim Moses: charter should be explicit
[21:32:42] <garygapinski> in other words, presentation is semiotics rather than semantics
[21:32:46] <hillbrad> Brian Smith: classification problem, becomes clearer that we can fit into existing deliverables
[21:33:14] <garygapinski> however, survey would benefit from itemization of presentation methods
[21:33:25] <hillbrad> ... what each client does for each bucket is less clear, but what we say for hard vs. soft failure,
[21:33:33] hillbrad got lost on that one...
[21:33:46] <yoav.nir> "user experience" is the term usually used. "The page remains blank" is definitely experience, but not really communications
[21:33:52] <garygapinski> as such are elicited by messages considered useful to the user
[21:34:14] <hillbrad> Tim Moses: anyone in audience planning to read drafts (question 5)?
[21:34:20] <hillbrad> about 20 hands
[21:34:33] danyork joins the room
[21:34:41] <hillbrad> John Klensin: two topics, understand what is happening, and how to fix it
[21:34:58] <hillbrad> ... may be useful to talk about serializing it or asking seperately about two topics for better responses
[21:35:15] <hillbrad> Tim Moses: fixing not part of ops groups mandata
[21:35:34] <hillbrad> John Klensin: reference to long tirade about putting procedural boundaries ahead of good sense
[21:35:45] <hillbrad> Steve Hanna: we are going to figure out what is happening today
[21:36:16] <hillbrad> PHB: really need discussion driven by problems rather than "a series of good ideas" to solve one problem in a elegant and sophisticated way
[21:36:48] <hillbrad> Tim Moses: question 4: editors, any additional volunteers to serve in editor role?
[21:36:59] <hillbrad> ... or approach chairs later
[21:37:21] <hillbrad> ... on to question 6: Hum: Who feels that a working group should not be formed?
[21:37:39] <hillbrad> correction...
[21:37:50] <hillbrad> Steve Hanna: hum for those who think should be formed
[21:37:54] <hillbrad> loud hum
[21:38:06] <hillbrad> Hum for why it should not be formed
[21:38:06] <hillbrad> one hum
[21:38:18] <hillbrad> Steve Hanna: lone objector, please get up and tell us why?
[21:38:24] <hillbrad> not volunteered
[21:38:30] <hillbrad> AD in the back gives us a thumbs up
[21:38:36] =JeffH leaves the room: Logged out
[21:38:38] cw leaves the room
[21:38:41] <hillbrad> Steve Hanna: thank you everyone, we have accomplished our goal.
[21:38:42] Karen O'Donoghue leaves the room
[21:38:44] SM leaves the room
[21:38:49] metricamerica leaves the room
[21:38:52] hildjj leaves the room
[21:39:03] linuxwolf leaves the room: Disconnected: connection closed
[21:39:07] JcK leaves the room
[21:39:08] yoav.nir leaves the room
[21:39:26] JimGalvin leaves the room
[21:39:28] Dowon Kim leaves the room
[21:39:38] dseomn leaves the room
[21:39:45] leaves the room
[21:39:51] lef.jpn leaves the room
[21:40:04] PHB leaves the room
[21:40:27] richard.barnes20460 leaves the room
[21:40:52] hillbrad leaves the room
[21:41:06] yngve_n_pettersen leaves the room
[21:41:52] Andrew Chi leaves the room
[21:42:07] Sean Turner leaves the room
[21:42:59] garygapinski leaves the room
[21:44:56] Dowon Kim joins the room
[21:46:59] fenton leaves the room
[21:47:59] Dowon Kim leaves the room
[21:48:07] sftcd leaves the room
[21:52:54] Karen O'Donoghue joins the room
[22:00:35] leifj leaves the room
[22:01:26] danyork leaves the room
[22:03:03] Stefans leaves the room
[22:03:58] dseomn joins the room
[22:05:38] Satoru Kanno leaves the room
[22:07:20] Satoru Kanno joins the room
[22:10:14] Karen O'Donoghue leaves the room
[22:14:03] Andrew Chi joins the room
[22:14:20] Karen O'Donoghue joins the room
[22:14:35] Andrew Chi leaves the room
[22:19:46] coopdanger leaves the room
[22:22:22] Stefans joins the room
[22:23:05] Karen O'Donoghue leaves the room
[22:24:40] hildjj joins the room
[22:25:38] Satoru Kanno leaves the room
[22:26:23] linuxwolf joins the room
[22:28:33] leifj joins the room
[22:31:08] dseomn leaves the room
[22:32:49] sftcd joins the room
[22:33:21] leifj leaves the room
[22:37:29] richard.barnes joins the room
[22:37:58] Sean Turner joins the room
[22:38:05] Sean Turner leaves the room
[22:38:22] richard.barnes45524 joins the room
[22:38:22] richard.barnes45524 leaves the room
[22:38:22] richard.barnes12058 joins the room
[22:38:22] richard.barnes12058 leaves the room
[22:38:22] richard.barnes57969 joins the room
[22:38:22] richard.barnes57969 leaves the room
[22:38:22] richard.barnes89538 joins the room
[22:38:25] richard.barnes89538 leaves the room
[22:38:34] richard.barnes leaves the room
[22:38:46] dseomn joins the room
[22:40:51] hillbrad joins the room
[22:40:54] dseomn leaves the room
[22:41:41] linuxwolf leaves the room
[22:41:42] sftcd leaves the room
[22:43:12] lef.jpn joins the room
[22:46:35] hillbrad leaves the room
[22:54:22] hildjj leaves the room
[23:09:49] Karen O'Donoghue joins the room
[23:22:13] Karen O'Donoghue leaves the room
[23:43:00] Karen O'Donoghue joins the room
[23:56:21] Karen O'Donoghue leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!