- From: Thomas Roessler <tlr@w3.org>
- Date: Fri, 11 Jan 2008 22:39:22 +0100
- To: WSC WG <public-wsc-wg@w3.org>
Minutes from our meeting on 2007-12-19 were approved and are
available online here:
http://www.w3.org/2007/12/19-wsc-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
Web Security Context Working Group Teleconference
19 Dec 2007
[2]Agenda
See also: [3]IRC log
Attendees
Present
Marz Ellen Zurko, Phillip Hallam-Baker, Thomas Roessler, Tyler
Close, Rachna Dhamija, Luis Barriga, Bill Eburn, Jan Vidar Krey,
Hal Lockhart, Anil Saldhana, Stephen Farrell, Tim Hahn, Ian
Fette, Yngve Pettersen, Dan Schutzer
Regrets
Johnathan_N, Maritza_J, Bill_D, Dan_S, Serge_E
Chair
Mez
Scribe
tlr
Contents
* [4]Topics
1. [5]administrivia
2. [6]completed action items review
3. [7]open action items
4. [8]agenda bashing
5. [9]issue-119, non-interaction-certs
6. [10]issue-122, Safe Form Bar: CA practice assumptions
7. [11]wrap-up
* [12]Summary of Action Items
__________________________________________________________________
Administrivia
<Mez> [13]http://www.w3.org/2007/11/28-wsc-minutes
[14]http://www.w3.org/2007/12/12-wsc-minutes
RESOLUTION: both sets of minutes approved
completed action items review
mez: thanks to phb, yngve
... don't think any issues with considering these completed ...
open action items
mez:
[15]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!
agenda bashing
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
[16]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
[17]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
[18]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
[19]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> [20]http://www.w3.org/2006/WSC/track/issues/119
issue-119, non-interaction-certs
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
[21]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> [22]http://www.w3.org/2006/WSC/track/issues/122
<tlr> phb, "that horse" being?
<Mez>
[23]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0096.html
issue-122, Safe Form Bar: CA practice assumptions
[24]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#safebar-comparec
n
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>
[25]https://www.opends.org/wiki//page/ConfiguringTheLDAPAndLDAPSConnect
ionHandlers
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:
[26]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
[27]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:
[28]http://www.tripwiresecurity.com/products/enterprise/reports/unchang
ed_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
[29]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:
[30]https://www.opends.org/wiki//page/ConfiguringTheLDAPAndLDAPSConnect
ionHandlers
<ifette> tyler, wrong url
<ifette> yes
<ifette> pdf link
tlr: the PDF link has stuff about DC=, btw
<ifette> tripwiresecurity.com/blah
<stephenF>
[31]http://www.tripwiresecurity.com/products/enterprise/reports/unchang
ed_element/unchanged.pdf
mez: would like to get on top of Luis' issue
wrap-up
mez: anything else?
happy holidays!
-- adjourned ---
Summary of Action Items
[NEW] ACTION: eburn to review wsc-xit - due 2008-01-01 [recorded in
[32]http://www.w3.org/2007/12/19-wsc-minutes.html#action03]
[NEW] ACTION: ifette to provide comments for WSC-XIT review - due
2007-12-22 [recorded in
[33]http://www.w3.org/2007/12/19-wsc-minutes.html#action04]
[NEW] ACTION: pbaker to review wsc-xit - due 2008-01-01 [recorded in
[34]http://www.w3.org/2007/12/19-wsc-minutes.html#action01]
[NEW] ACTION: phb to review wsc-xit - due 2008-01-01 [recorded in
[35]http://www.w3.org/2007/12/19-wsc-minutes.html#action02]
[NEW] ACTION: tlr to remove non-interaction certs while merging
Stephen's rewrite - due 2008-02-06 [recorded in
[36]http://www.w3.org/2007/12/19-wsc-minutes.html#action05]
[NEW] 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
[37]http://www.w3.org/2007/12/19-wsc-minutes.html#action07]
[NEW] ACTION: tyler to propose subjAltName text for 7.1 [recorded in
[38]http://www.w3.org/2007/12/19-wsc-minutes.html#action06]
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [39]scribe.perl version 1.128
([40]CVS log)
$Date: 2008/01/11 21:37:29 $
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0094.html
3. http://www.w3.org/2007/12/19-wsc-irc
4. http://www.w3.org/2007/12/19-wsc-minutes.html#agenda
5. http://www.w3.org/2007/12/19-wsc-minutes.html#Administri
6. http://www.w3.org/2007/12/19-wsc-minutes.html#item01
7. http://www.w3.org/2007/12/19-wsc-minutes.html#item02
8. http://www.w3.org/2007/12/19-wsc-minutes.html#item03
9. http://www.w3.org/2007/12/19-wsc-minutes.html#item04
10. http://www.w3.org/2007/12/19-wsc-minutes.html#item05
11. http://www.w3.org/2007/12/19-wsc-minutes.html#item06
12. http://www.w3.org/2007/12/19-wsc-minutes.html#ActionSummary
13. http://www.w3.org/2007/11/28-wsc-minutes
14. http://www.w3.org/2007/12/12-wsc-minutes
15. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0059.html
16. http://www.w3.org/2007/12/19-wsc-minutes.html#action01
17. http://www.w3.org/2007/12/19-wsc-minutes.html#action02
18. http://www.w3.org/2007/12/19-wsc-minutes.html#action03
19. http://www.w3.org/2007/12/19-wsc-minutes.html#action04
20. http://www.w3.org/2006/WSC/track/issues/119
21. http://www.w3.org/2007/12/19-wsc-minutes.html#action05
22. http://www.w3.org/2006/WSC/track/issues/122
23. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0096.html
24. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#safebar-comparecn
25. https://www.opends.org/wiki//page/ConfiguringTheLDAPAndLDAPSConnectionHandlers
26. http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security6.html
27. http://www.w3.org/2007/12/19-wsc-minutes.html#action06
28. http://www.tripwiresecurity.com/products/enterprise/reports/unchanged_element/unchanged.pdf
29. http://www.w3.org/2007/12/19-wsc-minutes.html#action07
30. https://www.opends.org/wiki//page/ConfiguringTheLDAPAndLDAPSConnectionHandlers
31. http://www.tripwiresecurity.com/products/enterprise/reports/unchanged_element/unchanged.pdf
32. http://www.w3.org/2007/12/19-wsc-minutes.html#action03
33. http://www.w3.org/2007/12/19-wsc-minutes.html#action04
34. http://www.w3.org/2007/12/19-wsc-minutes.html#action01
35. http://www.w3.org/2007/12/19-wsc-minutes.html#action02
36. http://www.w3.org/2007/12/19-wsc-minutes.html#action05
37. http://www.w3.org/2007/12/19-wsc-minutes.html#action07
38. http://www.w3.org/2007/12/19-wsc-minutes.html#action06
39. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
40. http://dev.w3.org/cvsweb/2002/scribe/
--
Thomas Roessler, W3C <tlr@w3.org>
Received on Friday, 11 January 2008 21:39:41 UTC