See also: IRC log
<Mez> http://www.w3.org/2007/11/28-wsc-minutes
http://www.w3.org/2007/12/12-wsc-minutes
RESOLUTION: both sets of minutes approved
mez: thanks to phb, yngve
... don't think any issues with considering these completed
...
mez:
http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0059.html
... any issues? ...
- silence -
mez: also, nothing closed due to inactivity; modest amount of threats
pbaker: 20% decrease in threat activity!
mez: yay!
... decrease in threatening MEZ is a good thing for everyone!
...
<PHB2> Threat condition is downgraded from Orange to Yellow!
mez: [ agenda review ]
... next meeting Jan 9
... holiday time and rest for everybody ...
... when we last talked about reviewing wsc-xit, people sounded
as though they wanted to get to it by yesterday ...
... might not have materialized ...
... where are those who are on the call today?
... plans in terms of reviewing xit?
<stephenF> I plan to review xit by end of the month
mez: pbaker?
<rachna> I can review by the end of the week or weekend
phb: end of the month...
<hal> will post comments today
<scribe> ACTION: pbaker to review wsc-xit - due 2008-01-01 [recorded in http://www.w3.org/2007/12/19-wsc-minutes.html#action01]
<trackbot-ng> Sorry, couldn't find user - pbaker
<tyler> end of the week
<scribe> ACTION: phb to review wsc-xit - due 2008-01-01 [recorded in http://www.w3.org/2007/12/19-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-361 - review wsc-xit [on Phillip Hallam-Baker - due 2008-01-01].
luis: looking forward to review; waiting for consistency of trust anchors to be included
mez: what's the issue?
... i.e., issue number? ...
... where we are ...
s/...where we are...//
tlr: is there something out of sycnh here with my editing actions?
luis: discussion dropped off
tlr: ah, sounds like stuff is in synch
bill: can review it
... please get me an action item ...
<scribe> ACTION: eburn to review wsc-xit - due 2008-01-01 [recorded in http://www.w3.org/2007/12/19-wsc-minutes.html#action03]
<trackbot-ng> Created ACTION-362 - review wsc-xit [on William Eburn - due 2008-01-01].
hal: will post comments by end of day
<ifette> ACTION: ifette to provide comments for WSC-XIT review - due 2007-12-22 [recorded in http://www.w3.org/2007/12/19-wsc-minutes.html#action04]
<trackbot-ng> Created ACTION-363 - provide comments for WSC-XIT review [on Ian Fette - due 2007-12-22].
<tjh> you're welcome
ifette: see action listed above
mez: yay, great
<ifette> link?
<Mez> http://www.w3.org/2006/WSC/track/issues/119
mez: stephen, your text seemed to
drop these certs. I heard support for that last week ..
... haven't heard "this should be kept" ...
... trouble might be that they are notional, not far enough
along to make it in there at ths time ...
... anybody want to clarify?
... dissent?
RESOLUTION: non-interaction certs exit the spec
tlr: want to merge that rewrite at this point?
mez: not making assumptions,
don't know any better
... don't know whether it raises any hackles ...
<PHB2> Since I have my Home Server now and it has an SSL cert built in that horse is now out of the barn....
<scribe> ACTION: tlr to remove non-interaction certs while merging Stephen's rewrite - due 2008-02-06 [recorded in http://www.w3.org/2007/12/19-wsc-minutes.html#action05]
<trackbot-ng> Created ACTION-364 - remove non-interaction certs while merging Stephen's rewrite [on Thomas Roessler - due 2008-02-06].
<PHB2> Several million of those boxes are going to be produced and every one comes with an SSL cert...
<Mez> http://www.w3.org/2006/WSC/track/issues/122
<tlr> phb, "that horse" being?
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0096.html
http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#safebar-comparecn
mez: this is about the matching
algorithm ...
... [reading spec language]
phb: not too excited about
this
... we know that organizations change their common names
...
... the problem is that the circumstances under which they
change CN ...
... tend to be such that you can't create hard and fast rules
as a CA ...
... for what the continuity of business is ...
... in some cases, there is continuity of business, in some it
doesn't exist ...
... seeing a lot of this stuff currently ...
... if you significantly change the common name in a cert,
you'll change the domain name ...
... unless domain name refers to product ...
... CN is changing anyway ...
... as a CA you only check right to use a name ...
... relationship between names isn't something we infer
...
... you can make inferences from continuity of key material
...
<stephenF> +1 to PHB's concern about the problems with these checks
phb: but I don't see us actually reissuing certs with different CN, but same key ...
tyler: ... so, based on thomas's
e-mail and response so far, nobody seems to understand the
checks
... they don't require new activity ...
... if company moves head office, updates cert info upon next
renewal ...
... would require cert from same CA and same host name
...
... "server is not using address" ...
... maybe using new CA, same key ...
<PHB2> Another point is that the only set of industry criteria we have for validating CNs is EV.. I am not going to go to CABForum and try to explain continuity criteria here.
tyler: there is no new check to be done ...
<PHB2> I don't think that they can be described\
tyler: no new requirements on the
CA ...
... when I first proposed this thing ...
... got some feedback from one of the buys on the banking
committee ...
... asking whether changing address information would be
supported ...
... put this in specifically in response to that concern
...
... took that as evidence that there are businesses to whom
it's important ..
... more flexible protocol ...
... maintain user's relationship with target site for as long
as this makes sense to do ...
... more robust that way ...
tlr: would like to understand
whether current processes would actually have these invariants
...
... if no such processes exist, then we're introducing
complexity that's useless ...
tyler: would enable switch to
competitor, no new product needed to roll this out
... if my users have been using my site, have set up form
filling history, use that kind of form filler ...
... switching CAs and not having a link, that would mean users
lose form filling history ...
stephenF: +1 to thomas, phill
...
... any algorithm that does less than exact match of
certificate with the one in the history ...
... would raise security issues that would need to be analyzed
..
... CNs being identical assumes commensurate policies from CAs
...
... agree on switching cost, but security cost to just using CN
...
... services and apps might hard-code common name ...
... any such rule would create issues that we'd have to go
through to greater degree than done here ...
tyler: like to point out that
algo has been in public document and discussed in group for
half year ...
... I haven't actually seen an attack ...
... tell me what the problem is ...
... find that a hard thing to work with ...
yngve: have to agree with steven
abt possible problems ..
... of too wide matching ...
tyler: example?
yngve: not paranoid enough to come up with example
tyler: which of the steps is too loose?
yngve: unsure
... should have investigated more closely ...
hal: two minds on this
issue
... think what was being said by Thomas and others ...
... we're asking the browsers to implement new algo ...
... if we don't justify that algorithm, might cause push-back
...
<stephenF> https://www.opends.org/wiki//page/ConfiguringTheLDAPAndLDAPSConnectionHandlers
hal: "benefits down the road" might be hard to sell
<stephenF> that URL has an example DN with a fixed looking CN
hal: for the certificates in this trust chain, is it plausible (or not) to provide own key and do proof of possession? ...
phb: not question of what CA lets
you do ...
... question of what web server software lets you do ...
<stephenF> actually a whole bunch of them
phb: quite a lot of them have the
notion that when you ask for cert request to be generated
...
... a lot of them will regenerate key ...
hal: so talking about requester or CA side?
phb: requester
hal: from CA pov, do honor request that includes public key, but people might not be able to generate them?
<stephenF> another one: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security6.html
phb: can take existing cert and
manipulate database and push out cert with any data we
like
... what we can't do is provide that info to a competitor
...
... migration from Verisign to Thawte would need new cert
req
... have to generate CSR for that particular key ...
... best crytpo practice is to regenerate key when generating
new CSR ..
[tlr - it's definitely possible to generate such a request with OpenSSL ]
phb: we're assuming here that CN
name has real-world meaning
... in domain validated certs, the CN might not have real-world
meaning
... can be random data controlled by applicant and/or CA
...
... certificates not comparable ...
... if you use the domain name as CN which is common in
domain-validated certs ...
... could have situation in which attacker gains control of
DNS, applies for cert from CA ...
... get access to reliant data ...
... problem is that we have security assumptions as to how CAs
operate ...
... these assumptions are not spelled out ..
... they might not hold ...
tyler: such as?
pbaker: assumption that CN is authenticated
tyler: talking about DN?
hal: ??
tyler: that's not being assumed
<stephenF> what tyler just said isn't clear to me from reading the text
tyler: we're assuming that if one CA says "character string is owned by someone", they won't issue a cert with the same CN to another party ...
phb: that's not true
... CAs rent roots from each other ...
... subordinate CAs ...
... there are certificates for that issued independently by RSA
and enTrust
... their CA centers don't collaborate, nor is there a
requirement for that ...
... subordinate CAs have shorter life than identity
certificates ...
... intermediate CAs rolled out every six months or so
...
... life time as long as certs issued under them ...
... those are continuously issued and rolled over ...
... if you try to pin it to the end entity cert, can't
guarantee uniqueness ...
... if you look at intermediate certs, don't know how stable
they are ...
tyler: do you content that verisign could issue certs to two independent parties with exact same DN?
pbaker: not saying that verisign
could do that ...
... we have roots in the browser that we control exclusively
and that have never been rented ...
... there may be some other CAs in that position ...
... but that is *not* the ...
... most CAs use roots from other parties ...
... they are rented and traded ...
... would be surprising if there were capabilities to sort out
duplicates ...
... the only dependency you can make on DNs ...
... is in the case of EV validated certs ...
... once you are on that level, logistics are complicated,
don't want to go there ...
... would have to define what continuity means ...
mez: I'm presume phill answered hal's question ...
phb: I think I said what I wanted to
<Zakim> stephenF, you wanted to say what that URL is about
stephen: two things ...
... want to check I'm talking about right thing ...
... 7.1, #safebar-comparecn
... tyler was asking fair question ...
... examples ...
... searched for CN=LDAP or CN=J2EE ...
... see URL far above ...
... where either software or documentation is telling people to
use those values ...
tyler: Same CA, same CN?
<scribe> ACTION: tyler to propose subjAltName text for 7.1 [recorded in http://www.w3.org/2007/12/19-wsc-minutes.html#action06]
<trackbot-ng> Created ACTION-365 - Propose subjAltName text for 7.1 [on Tyler Close - due 2007-12-26].
stephen: can have multiple CN
attributes in same DN, there can be identical CNs in different
certs ...
... subjAltName might be there, so I think we could get there
...
... also, DC=... part of distinguished name in order to encode
domain name ...
... any mechanism like this is tricky to get right ...
<tjh> comment there - it's not clear that Stephen's examples are applicable to CA-signed DNs contained within certificates they issue.
stephen: getting back to Thomas'
point about complexity ...
... current text is not correct ...
... the part about O, L, ST, C attributes would have similar
problems ...
... if you wanted to use this algorithm to get the effect
you're after ...
... you can't do simple comparison, as there's whole bunch of
stuff ...
... there might be mismatch where it's the same name ...
tyler: one of the things is ...
<tjh> does anyone have a suggestion for a comparison to allow for CA change but same entity?
tyler: same entity is renewing
cert ...
... want algorithm that recognizes "it's just the same entity"
...
... I hear stephen say it's not possible to do that ...
stephen: do it carefully
... I think you want to be the full X.509 name to be the same,
all subjAltName attributes to be same ...
<hal> there is much less of a problem if you get a false mismatch than a false match
tyler: requiring taht all subjAltNames are the same, does that mean you can't add one?
<Mez> security
<Mez> but usability?
stephen: on the fly, would have
to think about it
... you can have IP addresses in subjAltNames ...
... renumbering ...
... could be that there isn't any useful algorithm ...
tyler: no algorithm to make the comparison upon renewal?
stephenF: CA might have changed CPS
tyler: what?
stephen: Certificate Practice
Statement
... in general there's probably no such algorithm ...
<Mez> "in general" is not the same as "absolutely"
stephen: could probably find an
80% algorithm ...
... do some testing, find out what the remaining 20% do ...
tyler: haven't run into problems with petname tool ...
stephen: want to see evidence
<ifette> 1 person not hitting any problems is not the same as 4 billion people not hitting any problems
tyler: install petname, try it
stephen: don't think browsing a few websites is useful evidence
<ifette> They're not saying it's impossible, they're saying it's impossible to do so in a guaranteed secure manner...
tyler: dumbfounded that I hear
there are no changes to certificates
... and correlation is happening ...
tyler, you want to correct this
(my notes above)
mez: things that are ok to do to user make people worried when put into an algorithm
yngve: changing from CN to DN
...
... a bit earlier ...
... was there significance to that?
hal: stop, terminology
... issuer, subject are fields ...
... distinguished name is the data type of these ...
... has multiple attributes, one of them being commonName
yngve: web site administrator
submitting same information in different cert requests
... not so sure whether people will remember what they filled
in 1/2/3 years before ...
tyler: just using standard tools
...
... despite what bill said, it's simple to type in same command
for cert signing request ...
<stephenF> those tools change, the REC doc won't
yngve: brand new server without
the old data?
... might, after all, be different software ...
tyler: lost key pair?
yngve: possibly
tyler: then you're toast
... one scenario is cert expires, generate new key pair, switch
CAs ...
<scribe> ... new CSR with old key pair to new CA
UNKNOWN_SPEAKER: simpler operation ...
yngve: depends
<stephenF> so tyler's algorithm requires CLI rules for servers
tlr: isn't this a tangent?
tyler: tool sets...
<stephenF> useful feature also for bad guys
<Zakim> Thomas, you wanted to note that tyler's evidence is consistent with zero cert changes
hal: an algorithm that does not ever spuriously match, but that does match same site despite change (but correctly) in significant number of cases, might be useful feature.
tlr: evidence about personal
surfing is consistent with not having encountered the use case
in question.
... so ...
ifette: step back. We want to
associate information with particular company, not ...
... reuse across multiple entities ...
... so, we're now carving out an exception for cases that
actually might mean a real-life chagne ...
... that seems strange to me, given that we're actually
proposing to not share form data across different sites ...
tyler: let's consider that one
...
... purchasing company might have received all the files
...
tlr: sorry, this is going out on a limb -- don't make assumptions about privacy governance for m&as
ifette: there is a huge assumption we're making here!
phb: response to point about
continuity in SSL user interface ...
... fact is that UI provides only one bit of info ...
... "chains to embedded root or not" ...
... only criteria for getting padlock is meeting padlock
criteria ...
... there is no implied continuity ..
... there is nothing in the current UI that I see as indicating
contiuity ...
... we have surprisingly little protection against downgrade
attacks ...
... there is no continuity implied here ...
tyler: disagree
<stephenF> more DNs that include fixed CN components: http://www.tripwiresecurity.com/products/enterprise/reports/unchanged_element/unchanged.pdf
tyler: if user has bookmark, they trust to get to the same place ...
<janvidar> Zakim: aacc is janvidar
dans: agree with a lot of the
comments ...
... way back, we talked about adequacies / inadequacies of cues
that we have ...
... padlock and all that ...
... we observed much of what phill said ...
... ignored for many of the usual reasons ...
... you got an encrypted session, that's all ..
... there is a desire to have some confidence that you're
talking to the intended site ...
... might not be passwords ...
... other sensitive info ...
... not trying to argue pros and cons of how this works
technically ...
... cue "I'm at the same site" is valuable ...
... useful to talk about exceptional situations, m&a,
etc
... that is unusual information, breakage and concerns going on
in best of circumstances ...
... chase & jp morgan merge, and it all changes ...
... dramatic ...
... don't know any totally good ways around that ...
<tyler> q
<Zakim> stephenF, you wanted to ask how often users want to maintain that state informatin sufficiently long that a cert change occurs
stephenF: a piece of useful
information would be -- how often would users run into cert
updae problem?
... many certs lasting for quite a long time ...
... how often does the problem occur? ...
... also, why does writing the algorithm make people more
worried? ...
... can be read by the bad guys as well; higher bar when
writing a recommendation ...
tyler: re m&a concern -- one of the reasons for specifying this algorithm is to give a means to assert different (or equal) treatment
<stephenF> forgot to say: I suspect a secure algorithm here reqiures new protocol or new server operational rules (e.g. maintaining a cookie)
s/that's maybe best covered by specific attribute//
tyler: re how often does it happen -- every time cert renewed
mez: way back I heard there are
some issues around matching algorithm that tyler should
fix
... content in terms of net steps with tyler's action from
today
... reopening queue only to take proposals for next steps
...
stephenF: need to include DC=
attribute
... effectively, have a good read of RFC 3280 ...
... including looking down at the ASN.1 module ...
mez: would be good to have something that responds to other parts of certificates
tyler: want actions to be more specific
stephenF: uri, altname, ip
address, can probably ignore edi party name
... point is, if writing an algorithm like this, I'd rather
look all these attributes ...
... DC is common ...
tyler: URL?
stephenF: look above
mez: tyler to review attributes listed above, URLs from STehpen here
<tjh> could Stephen and Tyler collaborate on a new algorithm?
stephenF: one of the possibilities might be "if DC, then mismatch" -- mismatch rules are important too
<tjh> (outside of this call)?
tyler: default is fail
stephenF: if the DC mismatches,
you can match in the current algorithm; that's bad
... and btw, the URL above is a page *about* certificates with
these kinds of attributes
<Mez> tyler to explicitly address the attributes called out here in terms of the matching algorithm, and work offline with stephenf for his clarification on dc= (and anything else)
<scribe> ACTION: tyler to explicitly address the attributes called out here in terms of the matching algorithm, and work offline with stephenf for his clarification on dc= (and anything else) [recorded in http://www.w3.org/2007/12/19-wsc-minutes.html#action07]
<trackbot-ng> Created ACTION-366 - Explicitly address the attributes called out here in terms of the matching algorithm, and work offline with stephenf for his clarification on dc= (and anything else) [on Tyler Close - due 2007-12-26].
mez: trackbot-ng is cute, great! wonderful!
<ifette> I found a ton of DC= in that page
<tyler> I'm looking at: https://www.opends.org/wiki//page/ConfiguringTheLDAPAndLDAPSConnectionHandlers
<ifette> tyler, wrong url
<ifette> yes
<ifette> pdf link
tlr: the PDF link has stuff about DC=, btw
<ifette> tripwiresecurity.com/blah
<stephenF> http://www.tripwiresecurity.com/products/enterprise/reports/unchanged_element/unchanged.pdf
mez: would like to get on top of Luis' issue
mez: anything else?
happy holidays!
-- adjourned ---