RFD: comp.security.public-key-infra
Anamika
unmoderated group comp.security.public-key-infra
This is a formal Request For Discussion (RFD) for the creation of the
world-wide unmoderated Usenet newsgroup comp.security.public-key-infra.
This is not a Call for Votes (CFV); you cannot vote at this
time. Procedural details are below.
Newsgroup line:
comp.security.public-key-infra Discussion group for Public Key Infrastructure.
RATIONALE: comp.security.public-key-infra
Currently there exists no single newsgroup which exclusively is
devoted to the discussion of Public Key Infrastructure. Discussion of
PKI and related aspects are done in groups like sci.crypt,
alt.computer.security, *.crypto, sci.crypt.research etc., In order to
create more awareness of PKI, its uses, implementation, end-user
problems, solutions and all other related aspects there is a
requirement to have a newsgroup devoted to PKI.
CHARTER: comp.security.public-key-infra
This group will focus on discussions about PKI, deployment,
application of PKI in government, private and public sectors,
advantages and disadvantages, solution to end-user problems of PKI and
all other PKI-related aspects. This newsgroup will serve as a forum to
bring to focus PKI strengths and weaknesses and allow the general
public to voice their opinion on all PKI related matters.
END CHARTER.
PROCEDURE:
This is a request for discussion, not a call for votes. In this phase
of the process, any potential problems with the proposed newsgroups
should be raised and resolved. The discussion period will continue
for a minimum of 21 days (starting from when the first RFD for this
proposal is posted to news.announce.newgroups), after which a Call For
Votes (CFV) may be posted by a neutral vote taker if the discussion
warrants it. Please do not attempt to vote until this happens.
All discussion of this proposal should be posted to news.groups.
This RFD attempts to comply fully with the Usenet newsgroup creation
guidelines outlined in "How to Create a New Usenet Newsgroup" and "How
to Format and Submit a New Group Proposal". Please refer to these
documents (available in news.announce.newgroups) if you have any
questions about the process.
DISTRIBUTION:
This RFD has been posted to the following newsgroups:
news.announce.newgroups
news.groups
sci.crypt
comp.security.announce
comp.security.pgp.announce
Proponent: Niranjan Rajaghatta <hem...@yahoo.com>
ru.ig...@usask.ca
> REQUEST FOR DISCUSSION (RFD)
> unmoderated group comp.security.public-key-infra
>Newsgroup line:
>comp.security.public-key-infra Discussion group for Public Key Infrastructure.
Kind of an awkward looking name ("infra"), but you certainly want
to avoid a name that might suggest it is for listing public keys
(a la c.s.public-key or c.s.public-keys). Any alternatives?
>RATIONALE: comp.security.public-key-infra
>Currently there exists no single newsgroup which exclusively is
>devoted to the discussion of Public Key Infrastructure.
The above is kind of redundant. You shouldn't be proposing
a group for a topic that already has one. It really shouldn't
be the first line of the rationale, regardless.
>Discussion of
>PKI and related aspects are done in groups like sci.crypt,
>alt.computer.security, *.crypto, sci.crypt.research etc.,
Is that comma supposed to be there at the end of that line?
Define "PKI".
>In order to
>create more awareness of PKI, its uses, implementation, end-user
>problems, solutions and all other related aspects there is a
>requirement to have a newsgroup devoted to PKI.
Big-8 newsgroups really shouldn't be touted as a means of
increasing awareness, especially since you need to have enough
people aware already in order to get enough votes. You need
at least 110 YES votes to pass, and that usually means a few
hundred to thousands of willing readers ready to go right now.
So, assuming that this part of your rationale is inadequate,
you need to concentrate more on what is going on in the other
newsgroups. Why is this state of affairs unsatisfactory?
What are the problems the proposed group will solve, and how?
Why do you think there are enough people that would read
the new group that it would be created? What sets the proposed
group apart from the other groups, or how distinct is the
subject or discussions in the other groups compared to in
the proposed group? How will this group not just become
"yet another group that PK is discussed" rather than the
main one?
>CHARTER: comp.security.public-key-infra
The usual first line goes something like:
Comp.security.public-key-infra is an unmoderated news group
for discussions relating to Public Key Infrastructures (PKI).
And then I suggest you describe what PKI is in one or two sentences.
>This group will focus on discussions about PKI, deployment,
>application of PKI in government, private and public sectors,
>advantages and disadvantages, solution to end-user problems of PKI and
>all other PKI-related aspects. This newsgroup will serve as a forum to
>bring to focus PKI strengths and weaknesses and allow the general
>public to voice their opinion on all PKI related matters.
This sounds a bit like an advocacy group. And it doesn't read
all that friendly to novices in the use of PK.
Will there be an issue regarding posting of binaries?
Will there be an issue regarding commercial postings? Spam?
>END CHARTER.
ru
--
My (updated) standard proposals rant:
Quality, usefulness, merit, or non-newsgroups popularity of a topic
is more or less irrelevant in creating a new Big-8 newsgroup.
Usenet popularity is the primary consideration.
Henrietta K. Thomas
in news.groups:
>In news.groups Anamika <hem...@yahoo.com> wrote:
>> REQUEST FOR DISCUSSION (RFD)
>> unmoderated group comp.security.public-key-infra
>
>>Newsgroup line:
>>comp.security.public-key-infra Discussion group for Public Key Infrastructure.
>
>Kind of an awkward looking name ("infra"), but you certainly want
>to avoid a name that might suggest it is for listing public keys
>(a la c.s.public-key or c.s.public-keys). Any alternatives?
Well, he -could- spell the word out.
comp.security.public-key-infrastructure
or use a different word, such as
comp.security.public-key-system
or maybe just say
comp.security.public-keys
But then people might think it's a place for posting their
public keys. so I think the second one might work.
I have no other comments to make. The comp. hierarchy
is beyond my level of expertise.
Henrietta K. Thomas
Chicago, Illinois
hk...@earthlink.net
Joe Bernstein
a very good line-by-line on this RFD, to which I just want to add random
comments:
> In news.groups Anamika <hem...@yahoo.com> wrote:
> > REQUEST FOR DISCUSSION (RFD)
> > unmoderated group comp.security.public-key-infra
>
> >Newsgroup line:
> >comp.security.public-key-infra Discussion group for Public Key Infrastructure.
>
> Kind of an awkward looking name ("infra"), but you certainly want
> to avoid a name that might suggest it is for listing public keys
> (a la c.s.public-key or c.s.public-keys). Any alternatives?
"Discussion group" in the description is a tad unnecessary, I think.
If there are any shorter names for what the proponent refers to as
Public Key Infrastructure, I think it might be worth using one of
those in the name, and P... K.. I... in the description?
"public-key-infra" means nothing to me, and I don't like it at all.
I wonder if an orphan hierarchy is appropriate here:
comp.security.infrastructure.public-key
strikes me as the most obvious possibility, but maybe that's because
(despite having been mildly enthusiastic about public key
*cryptography* ever since it was first discovered) I've never heard
before of PKI and so don't know what it Really Means. Regardless,
I think some sort of orphan sub-hierarchy is the answer here, and
there's enough space in the newsgroup line if you get "Discussion
group" out of the description.
Please note that my unawareness of PKI means I am *not* the sort of person
you would want in your group [1], but your group name did not tell me so.
This is a definite failing in your group's name.
> >RATIONALE: comp.security.public-key-infra
>
> >Currently there exists no single newsgroup which exclusively is
> >devoted to the discussion of Public Key Infrastructure.
>
> The above is kind of redundant. You shouldn't be proposing
> a group for a topic that already has one. It really shouldn't
> be the first line of the rationale, regardless.
Um, I'm not convinced that it's redundant; sometimes people propose
groups for *different* discussion of topics that already have
groups. (You may not approve of groups moving from alt.* to the
Big 8, but it's allowed. For example.)
> >Discussion of
> >PKI
> Define "PKI".
Hear hear. Define it repeatedly and at lengths greater than three
words, please. If I don't know what it is, Joe User doesn't know what
it is, that's for sure; and Joe User has the right to vote on your
proposal.
> So, assuming that this part of your rationale is inadequate,
> you need to concentrate more on what is going on in the other
> newsgroups. Why is this state of affairs unsatisfactory?
> What are the problems the proposed group will solve, and how?
> Why do you think there are enough people that would read
> the new group that it would be created? What sets the proposed
> group apart from the other groups, or how distinct is the
> subject or discussions in the other groups compared to in
> the proposed group? How will this group not just become
> "yet another group that PK is discussed" rather than the
> main one?
In general, I think Ru Igarashi's line-by-lines have too often
focused on the Rationale, a fairly disposable piece of text, as
against the Charter. But this set of questions is a *superb*
summation of what's wrong with this Rationale, and if the proponent
answers them in a 2nd RFD or a CFV, the proposal will be greatly
improved thereby.
> >CHARTER: comp.security.public-key-infra
> >This group will focus on discussions
Personal pet peeve: Charters should be in the present tense, so that
they can be quoted after the group is created.
More general comment: This is slightly overconfident wording. As
Ru Igarashi wrote, and I snipped, your Charter should state a general
notion of what the group is about, but after that, trying to specify
what the group *will* "focus on" is dubious. Sample topics work
better than broad brush sketches like the following, I think:
> >about PKI, deployment,
> >application of PKI in government, private and public sectors,
> >advantages and disadvantages, solution to end-user problems of PKI and
> >all other PKI-related aspects. This newsgroup will serve as a forum to
> >bring to focus PKI strengths and weaknesses and allow the general
> >public to voice their opinion on all PKI related matters.
Note that sample topics also work as a Rationale-enhancer: "Here
are things for which this is the logical home". If they're already
discussed on Usenet, they're evidence of traffic and potential votes;
if they aren't, they're evidence that there's a hole in topic space
that your group could help fill.
Preferably, you'll have examples of both kinds.
> This sounds a bit like an advocacy group. And it doesn't read
> all that friendly to novices in the use of PK.
I'm not convinced by either of these comments. I think maybe you're
reading too much into "strengths and weaknesses"; what I'm seeing
there is something like "well, the most interesting stuff to talk
about is probably going to be problems that people have, and ways
to solve those problems, or maybe situations where PKI works well
versus situations where it doesn't", while maybe what you're seeing
there is "PKI Roolz!" "PKI Sux!"
I agree that the existing Charter text is novice-hostile, but that's
just because it's reader-hostile period. If it's unpacked, I don't
think the list of topics described is at all novice-hostile; in fact,
by my reading, it's likely to demand novices as sources of new
"strengths and weaknesses" to talk about.
It's always unnerving to me when the first comment on an RFD is
from a news.groups regular, and my adding a second isn't helping.
I hope when I get done posting this and see the list of posts again,
I see three other people commenting who are interested in using
the group. But in any event, I may post a comment directly on the
Distribution section of the RFD.
I have the impression that if I knew what this group was about, I'd
approve of the idea of creating it, if it could get enough YES votes.
(This does not mean I'd vote YES for it myself, since I won't read
it; this does mean I'd try to make sure it got its best shot at
being created.) It would be nice, however, to be sure.
A thoroughly rewritten RFD should probably be posted as a 2nd RFD,
especially if anyone can suggest additional targets for the
Distribution, but I'm not entirely sure it would be impossible to
go from this inferior RFD to a perfectly good CFV, in one step.
Joe Bernstein
[1] To expand on the last several paragraphs, and on my comment
about my not being the sort of person wanted: It's quite clear
that the intended audience for this group is some sort of
combination of server or software administrators, maybe software
authors, like that. People responsible for implementing public
key systems on scales larger than PGP. I presume that any such
person will have previously heard of this PKI acronym, even though
I haven't. Since I've never actually done *anything* practical re
public key, even implementing PGP for my own use, it's perfectly
obvious to me that I'm not properly a member of this group's
intended audience, even though the group name does *not* tell me
so. But this *doesn't* mean I buy the idea that it's a novice-
hostile advocacy group; with an adequate name, description, and
charter, it could be a very useful group to novice administrators
of servers that handle public key, or whoever exactly the group is
supposed to reach.
--
Joe Bernstein, writer and clerk j...@sfbooks.com
<http://these-survive.postilion.org/>
Joe Bernstein
which actually conveys exactly what the post is about.
In article <10322923...@isc.org>, Anamika <hem...@yahoo.com> wrote:
> REQUEST FOR DISCUSSION (RFD)
> unmoderated group comp.security.public-key-infra
on which bad name I've already commented, so let's get on to the
other thing I want to address...
> DISTRIBUTION:
>
> This RFD has been posted to the following newsgroups:
>
> news.announce.newgroups
> news.groups
> sci.crypt
> comp.security.announce
> comp.security.pgp.announce
I don't know how active these groups are, nor how many interested
regulars they have, but I have the impression that this is a very
light distribution. If half a dozen of these groups' readers show
up in the next few hours saying I'm wrong, well, wonderful, but if
not, I would *strongly* recommend doing a 2nd RFD with wider
distribution. It's alarming when several of the groups mentioned
in the Rationale as having relevant traffic (alt.crypto,
sci.crypt.research, at least) are *not* in the distribution.
And it's surprising, though not totally unexpected, to see no
mailing lists mentioned at all. (Nor web sites?)
It's highly desirable to limit specific postings of RFDs to five
groups in order to deal with brain-dead servers that reject wider
cross-posts. The inevitable, if regrettable, solution to this is
to multi-post RFDs. (And CFVs, and so on.) Look at the RFD for
the misc.kids.* reorganisation to see the way this works. Don't
let the stupidity of various news-admins force your group to fail
its vote.
Joe Bernstein
Russ Allbery
> "public-key-infra" means nothing to me, and I don't like it at all.
> I wonder if an orphan hierarchy is appropriate here:
> comp.security.infrastructure.public-key
> strikes me as the most obvious possibility, but maybe that's because
> (despite having been mildly enthusiastic about public key
> *cryptography* ever since it was first discovered) I've never heard
> before of PKI and so don't know what it Really Means.
If anything, it's the other way around:
comp.security.public-key.infrastructure
PKI is basically the discussion of systematic ways of using public key
cryptography to build a security infrastructure. These days, the most
noticable visible PKI is SSL certs.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Russ Allbery
> It's highly desirable to limit specific postings of RFDs to five groups
> in order to deal with brain-dead servers that reject wider cross-posts.
> The inevitable, if regrettable, solution to this is to multi-post RFDs.
> (And CFVs, and so on.) Look at the RFD for the misc.kids.*
> reorganisation to see the way this works. Don't let the stupidity of
> various news-admins force your group to fail its vote.
You can multipost it right now; you don't need a 2nd RFD to do this.
(Just to clarify.)
Russ Allbery
> Well, he -could- spell the word out.
> comp.security.public-key-infrastructure
1234567890123456789012345
Unfortunately, we're still limiting name components to 20 characters.
One alternative would be to just use the PKI acronym, as it's very
commonly known within the security community. But it's rather more
obscure outside that community. (Similar situation to rec.aviation.ifr.)
ru.ig...@usask.ca
>In article <am87i3$gek$1...@tribune.usask.ca>, <ru.ig...@usask.ca> wrote
>a very good line-by-line on this RFD, to which I just want to add random
>comments:
>> In news.groups Anamika <hem...@yahoo.com> wrote:
>> This sounds a bit like an advocacy group. And it doesn't read
>> all that friendly to novices in the use of PK.
>I'm not convinced by either of these comments. I think maybe you're
>reading too much into "strengths and weaknesses"; what I'm seeing
>there is something like "well, the most interesting stuff to talk
>about is probably going to be problems that people have, and ways
>to solve those problems, or maybe situations where PKI works well
>versus situations where it doesn't", while maybe what you're seeing
>there is "PKI Roolz!" "PKI Sux!"
>I agree that the existing Charter text is novice-hostile, but that's
Yeah, that'w what I'm saying. I'm not saying the group looks like
it, just that it reads like it.
>just because it's reader-hostile period. If it's unpacked, I don't
>think the list of topics described is at all novice-hostile; in fact,
>by my reading, it's likely to demand novices as sources of new
>"strengths and weaknesses" to talk about.
Well, one of the reasons it looked novice hostile was that there
wasn't much (there was a little bit) there that suggested that
"what is?" or "help!" type questions would be supported for, say,
a user setting up keys for SSH. There was a heavy emphasis
on more technical aspects. I just got to wondering if this was
intentional.
[snip]
>But this *doesn't* mean I buy the idea that it's a novice-
>hostile advocacy group; with an adequate name, description, and
>charter, it could be a very useful group to novice administrators
>of servers that handle public key, or whoever exactly the group is
>supposed to reach.
The thing is, PK isn't something only adminstrators deal with.
There's user software (e.g. SSH) that can be user configured, and
SSL or browser security questions at conceptual levels that folks
might consider the proposed group appropriate for. The question
is, are those appropriate for the proposed group?
Jeffrey M. Vinocur
Russ Allbery <r...@stanford.edu> wrote:
>Henrietta K Thomas <hk...@earthlink.net> writes:
>
>> comp.security.public-key-infrastructure
> 1234567890123456789012345
>
>Unfortunately, we're still limiting name components to 20 characters.
Hmm. Would comp.security.key-infrastructure be unacceptable? I
mean, there's surely not much of interest in the non-public kind,
but that accordingly means that perhaps "public" in the term is
redundant.
(Not that I'd suggest this, except for the issue above.
Personally, I think I like comp.security.pki the best, but the
above has some potential.)
--
Jeffrey M. Vinocur
je...@litech.org
Dan Riley
> The thing is, PK isn't something only adminstrators deal with.
> There's user software (e.g. SSH) that can be user configured, and
> SSL or browser security questions at conceptual levels that folks
> might consider the proposed group appropriate for. The question
> is, are those appropriate for the proposed group?
I would think ssh would be completetly off-topic--while it can use
public keys, there is no "infrastructure" involved. PKI generally
refers to the infrastructure involved in having keys signed by trusted
third parties, and ssh doesn't use any of that stuff. PGP might be
on-topic, as an alternate form of infrastructure.
wrt the proposal, I'd want to see a *lot* of evidence that there would
be sufficient traffic to justify the group. My impression is that PKI
is mostly dead--the only widely used deployment is https, and the use
there is so casual that complete and utter breaks of https security
(such as the older certs that don't have CA set to false in the basic
constraints, or the *widely* deployed browsers that don't check basic
constraints in the certificate chain) cause barely a ripple.
--
"about 15 percent of the people are screwballs, lightweights and boobs
and you would not want those people unrepresented in Congress."
-Alan Simpson, former US Senator (R, Wyoming)
Neil Crellin
unmoderated group comp.security.public-key-infra
This CFV is to be distributed only by the votetaker. It is not to be
posted to newsgroups, or mailed to mailing lists or individuals, except by
the votetaker. Ballots or CFVs provided by anyone else will be invalid.
Newsgroups line:
comp.security.public-key-infra Discussion group for public key infrastructure.
Votes must be received by 23:59:59 UTC, 19 Nov 2002.
This vote is being conducted by a neutral third party. Questions
about the proposed group should be directed to the proponent.
Proponent: Niranjan Rajaghatta <hem...@yahoo.com>
Votetaker: Neil Crellin <ne...@wallaby.cc>
RATIONALE: comp.security.public-key-infra
Currently there exists no single newsgroup which exclusively is
devoted to the discussion of Public Key Infrastructure. Discussion of
PKI and related aspects are done in groups like sci.crypt,
alt.computer.security, *.crypto, sci.crypt.research etc., In order to
create more awareness of PKI, its uses, implementation, end-user
problems, solutions and all other related aspects there is a
requirement to have a newsgroup devoted to PKI.
CHARTER: comp.security.public-key-infra
This group will focus on discussions about PKI, deployment,
application of PKI in government, private and public sectors,
advantages and disadvantages, solution to end-user problems of PKI and
all other PKI-related aspects. This newsgroup will serve as a forum to
bring to focus PKI strengths and weaknesses and allow the general
public to voice their opinion on all PKI related matters.
END CHARTER.
IMPORTANT VOTING PROCEDURE NOTES: READ THIS BEFORE VOTING
The purpose of a Usenet vote is to determine the genuine interest in
reading the proposed newsgroup, and soliciting votes from uninterested
parties defeats this purpose. Do *not* distribute this CFV; instead,
direct people to the official CFV as posted to news.announce.newgroups.
Distributing specific voting instructions or pre-marked copies of
this CFV is considered vote fraud.
This is a public vote: All email addresses, names and votes will be
listed in the final RESULT post. The name used may be either a real
name or an established Usenet handle.
At most one vote is allowed per person or per account. Duplicate
votes will be resolved in favor of the most recent valid vote.
Voters must mail their ballots directly to the votetaker. Anonymous,
forwarded, or proxy votes are not valid, nor are votes mailed from
WWW/HTML/CGI forms (which should not exist). Votes from nonexistent
accounts or with munged, spam-blocked, or undeliverable addresses are
invalid and will NOT be counted.
Please direct any questions to the votetaker at <ne...@wallaby.cc>
HOW TO VOTE:
Extract the ballot from the CFV by deleting everything before and after
the "BEGINNING OF BALLOT" and "END OF BALLOT" lines. Don't worry about
the spacing of the columns or any quote characters (">") that your
reply inserts. Please, DO NOT send the entire CFV back to me!
Fill in the ballot as shown below. Please provide your real name
(or established Usenet handle) and indicate your desired vote in the
appropriate locations inside the ballot.
Examples of how to properly indicate your vote:
[ YES ] example.yes.vote
[ NO ] example.no.vote
[ ABSTAIN ] example.abstention
[ CANCEL ] example.cancellation
DO NOT modify, alter or delete any information in this ballot!
If you do, the voting software will probably reject your ballot.
When finished, MAIL the ballot to: < vot...@uvv.wallaby.cc >
Just "replying" to this message should work, but check the "To:" line.
If you do not receive an acknowledgment of your vote within three
days contact the votetaker about the problem. You are responsible
for reading your ack and making sure your vote is registered correctly.
If these instructions are unclear, please consult the Introduction to
Usenet Voting or the Usenet Voting FAQ at http://www.stanford.edu/~neilc/uvv.
======== BEGINNING OF BALLOT: Delete everything before this line =======
.-----------------------------------------------------------------------
| 1ST CALL FOR VOTES: comp.security.public-key-infra
| Official Usenet Voting Ballot <CSP-0001> (Do not remove this line!)
|-----------------------------------------------------------------------
| Please provide your real name, or your vote may be rejected. Established
| Usenet handles are also acceptable. Place ONLY your name (ie. do NOT
| include your e-mail address or any other information; ONLY your name)
| after the colon on the following line:
Voter name:
| Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each
| newsgroup listed below (do not delete the newsgroup name):
Your Vote Newsgroup
--------- -----------------------------------------------------------
[ ] comp.security.public-key-infra
======== END OF BALLOT: Delete everything after this line ==============
This CFV was created with uvpq 1.0 (Feb 6 1999).
PQ datestamp: 980322
--
Voting address: vot...@uvv.wallaby.cc
Neil Crellin
unmoderated group comp.security.public-key-infra
[ Note: This 2nd CFV was posted without the usual "Ack Bounce List" because
the assigned votetaker was unexpectedly called away on an emergency. If
you have voted and did NOT receive an acknowledgement from the votetaker's
software, it is recommended that you cast another ballot. If you have
received an acknowledgement, no further action is required on your part.
You do not need to vote again.
-- Bill Aten, UVV Coordinator ]
RATIONALE: comp.security.public-key-infra
CHARTER: comp.security.public-key-infra
END CHARTER.
HOW TO VOTE:
| 2ND CALL FOR VOTES: comp.security.public-key-infra
| Official Usenet Voting Ballot <CSP-0002> (Do not remove this line!)
Neil Crellin
unmoderated group comp.security.public-key-infra fails 70:14
There were 70 YES votes and 14 NO votes, for a total of 84 valid
votes. There were 4 abstentions.
For a group to pass, YES votes must be at least 2/3 of all valid
(YES and NO) votes. There must also be at least 100 more YES votes
than NO votes.
A five day discussion period follows this announcement. Unless
serious allegations of voting irregularities are raised, the group
may not be voted on again for six months.
Newsgroups line:
comp.security.public-key-infra Discussion group for public key infrastructure.
The voting period closed at 23:59:59 UTC, 19 Nov 2002.
This vote was conducted by a neutral third party. Questions
about the proposed group should be directed to the proponent.
Proponent: Niranjan Rajaghatta <hem...@yahoo.com>
Votetaker: Neil Crellin <ne...@wallaby.cc>
RATIONALE: comp.security.public-key-infra
Currently there exists no single newsgroup which exclusively is
devoted to the discussion of Public Key Infrastructure. Discussion of
PKI and related aspects are done in groups like sci.crypt,
alt.computer.security, *.crypto, sci.crypt.research etc., In order to
create more awareness of PKI, its uses, implementation, end-user
problems, solutions and all other related aspects there is a
requirement to have a newsgroup devoted to PKI.
CHARTER: comp.security.public-key-infra
This group will focus on discussions about PKI, deployment,
application of PKI in government, private and public sectors,
advantages and disadvantages, solution to end-user problems of PKI and
all other PKI-related aspects. This newsgroup will serve as a forum to
bring to focus PKI strengths and weaknesses and allow the general
public to voice their opinion on all PKI related matters.
END CHARTER.
comp.security.public-key-infra Final Voter list
NOTE: This is not [to be used as] a mailing list. The email addresses
are posted only to help verify the interest poll. Thank you.
Voted YES
------------------------------------------------------------------------------
cmeerw_vote [at] fastrun.at Christof Meerwald
toivo [at] ucs.uwa.edu.au Toivo Pedaste
chris [at] stallion.oz.au Christopher Biggs
malek.bechlaghem [at] belgacom.be BECHLAGHEM Malek
devegili [at] ulbra-to.br Augusto Jun Devegili
gary.k.mcdonald [at] sympatico.ca Gary K McDonald
reid [at] astro.utoronto.ca Rob Reid
markwhite28 [at] attbi.com Robert Mark White
dball [at] bnb-lp.com David Ball
acarratala [at] certisur.com =?iso-8859-1?Q?Armando_Carratal=E1?=
chris.gilbert [at] consignia.com Chris Gilbert
efeustel [at] erols.com Edward A. Feustel
julesd [at] erols.com Jules Dubois
smlucas [at] famvid.com Steven Lucas
MikeR [at] geotrust.com Michael J. Rowan
franck.t [at] netcourrier.com Franck T
kamrutesh [at] netnumber.com karthik amrutesh
dc [at] panix.com David W. Crawford
starryband [at] rogers.com Starry Band Communications
JBrainard [at] rsasecurity.com John Brainard
HamrickM [at] STARS-SMI.com Matthew S. Hamrick
hannigan [at] world.std.com Martin Hannigan
pan [at] syix.com Pan
oelmaier [at] sytrust.com Florian Oelmaier
eggert [at] twinsun.com Paul Eggert
Peter.Gietz [at] daasi.de Peter Gietz
ingmar [at] aurora.in-berlin.de Ingmar Camphausen
thomas.schwarz [at] is-energy.de Thomas Schwarz
brauckmann [at] trustcenter.de Juergen Brauckmann
martelli [at] trustcenter.de Bettina Martelli
Ekkehard [at] Uthke.de Ekkehard Uthke
bouvin [at] daimi.au.dk Niels Olof Bouvin
harder [at] ifa.au.dk Jesper Harder
fungus [at] OCF.Berkeley.EDU Hank Fung
rra [at] stanford.edu Russ Allbery
rick [at] bcm.tmc.edu Richard Miller
alansz [at] uic.edu Alan Schwartz
jpatokal [at] cc.hut.fi Jani Patokallio
mikael.segercrantz [at] pp.inet.fi Mikael Segercrantz
franck.leroy [at] pk7.fr Franck Leroy
de5-dated-1037635486.c74d09 [at] sws5.ornl.gov Dave Sill
bogart [at] upnet.gr Artemios G. Voyiatzis
zglozik [at] iolfree.ie Zoltan Glozik
dfrost [at] maths.tcd.ie Dermot Frost
alfredo.esposito [at] infocamere.it Alfredo Esposito
RussellBJ [at] i-mef.usmc.mil </FONT>
thor [at] anta.net Thor Kottelin
Mitchell_Gonzales [at] worldnet.att.net Mitchell A Gonzales
jspence31 [at] comcast.net Jim Spence
psmyth [at] gmx.net Peter Smyth
madwolf [at] hackmasters.net Massimiliano Pala
van.ette [at] inter.nl.net Robert-Jan van Ette
ellis [at] spinics.net Rick Ellis
thomas [at] widmann.uklinux.net Thomas Widmann
Peter-Lawrence.Montgomery [at] cwi.nl Peter L. Montgomery
erik [at] flits102-126.flits.rug.nl Erik Warmelink
trh [at] xs4all.nl Tom Hageman
pgut001 [at] cs.auckland.ac.nz Peter Gutmann
sbfaulds [at] ihug.co.nz Stuart
rossde [at] acm.org David E. Ross
Ed [at] Bertsch.org edward bertsch
shrdlu [at] deaddrop.org Etaoin Shrdlu
iarenaza [at] escomposlinux.org Ignacio Arenaza
JMKing [at] ipro.org MyNameIsMonkey
tskirvin [at] killfile.org Tim Skirvin
irina [at] souiki.org =
jpc [at] suespammers.org J. Porter Clark
philb [at] soc.plym.ac.uk Phil Brooke
kevin [at] fairbruk.demon.co.uk Kevin Blackburn
jdg [at] diogenes.sacramento.ca.us John David Galt
Voted NO
------------------------------------------------------------------------------
ru.igarashi [at] usask.ca ru igarashi
Usdlaw2l [at] aol.com Jack Hanna<BR>
stainles [at] bga.com Dwight Brown
216-5888 [at] mcimail.com Arthur L. Rubin
gprrspw [at] mindspring.com G.P. Ryan
phr-n2002b [at] nightsong.com Paul Rubin
phil [at] panix.com Phil Gustafson
dsr [at] mail.lns.cornell.edu Dan Riley
vote-comp.security.public-key-infra [at] newton.digitalspace.net Philip Newton
bard [at] dmcom.net bard
mmontcha [at] OregonVOS.net Matthew Montchalin
zimnyzenon [at] interia.pl Zenobiusz Zimny
chriseb [at] ukshells.co.uk Chris Ebenezer
ijackson [at] chiark.greenend.org.uk Ian Jackson
Abstained
------------------------------------------------------------------------------
mmrosa [at] bigpond.net.au Michal Rosa
wiz [at] verinet.com Wiz
p.texier [at] genindre.org Patrick Texier
jeff [at] puck.litech.org Jeffrey M. Vinocur
--
Neil Crellin, UVV <ne...@wallaby.cc>
Tom St Denis
"Neil Crellin" <ne...@wallaby.cc> wrote in message
news:1037906...@isc.org...
> RussellBJ [at] i-mef.usmc.mil
</FONT>
Good thing our metatags are hard at work.
> irina [at] souiki.org
=
='s?
hehehehehe.
Tom
ba...@dmcom.net
>
> RESULT
> unmoderated group comp.security.public-key-infra fails 70:14
>
*sighes* another vote that could not get over 100 voting on any side of
the proposal.
--
news:alt.pagan FAQ at http://www.dmcom.net/bard/altpag.txt
news:alt.religion.wicca FAQ at http://www.dmcom.net/bard/arwfaq2.txt
news:news.groups FAQ at http://www.dmcom.net/bard/ngfaq.txt
Want a new group FAQs http://web.presby.edu/~nnqadmin/nnq/ncreate.html
Russ Allbery
> Neil Crellin wrote:
>> RESULT
>> unmoderated group comp.security.public-key-infra fails 70:14
> *sighes* another vote that could not get over 100 voting on any side of
> the proposal.
It wasn't anywhere near well enough publicized. This is one that I think
would have passed if it would have gotten in front of more eyes. It was a
good idea for a newsgroup that would have been useful, IMO (I would have
read it, certainly).
It didn't help that both comp.security.announce and
comp.security.pgp.announce are apparently dead groups.
ba...@dmcom.net
>
> It didn't help that both comp.security.announce and
> comp.security.pgp.announce are apparently dead groups.
>
I take it moderator(s) MIA ?
Martin Hannigan
Russ Allbery <r...@stanford.edu> wrote:
>bard <ba...@dmcom.net> writes:
>> Neil Crellin wrote:
>
>>> RESULT
>>> unmoderated group comp.security.public-key-infra fails 70:14
>
>> *sighes* another vote that could not get over 100 voting on any side of
>> the proposal.
>
>It wasn't anywhere near well enough publicized. This is one that I think
>would have passed if it would have gotten in front of more eyes. It was a
>good idea for a newsgroup that would have been useful, IMO (I would have
>read it, certainly).
Definately. These are big issues. They should've caused a massive
flame war and a massive vote.
-M
--
HAY! Don't forget to review the CFV for rec.skiing.alping.moderated being
held in news.group -- DONT FORGET TO VOTE! AND DON'T FORGET TO VOTE
FReAkIn YES! And now, a word from our sponsor:
Is the RFD process driving you roy BATTY? Try Thorazine[tm]
Brand N.G. Relaxant. Works Grrrrrrrrreatt!! [ droul splat ]
Russ Allbery
> Russ Allbery wrote:
>> It didn't help that both comp.security.announce and
>> comp.security.pgp.announce are apparently dead groups.
> I take it moderator(s) MIA ?
Looks that way at least for comp.security.pgp.announce. I don't really
understand what the charter of comp.security.announce is and haven't done
research into it. Right now, it only gets (self-approved) CERT advisories
and nothing else.
Dan Riley
> Neil Crellin wrote:
> > RESULT
> > unmoderated group comp.security.public-key-infra fails 70:14
>
> *sighes* another vote that could not get over 100 voting on any side of
> the proposal.
I'm surprised it got 70 yes votes (and somewhat surprised at who voted
yes). I thought it was poorly named, the charter didn't match the
name, and the proponent was completely absent during the discussion
period (the CFV was identical to the first RFD, despite a number of
questions raised and never answered).
Arthur L. Rubin
> Voted YES
...
> RussellBJ [at] i-mef.usmc.mil </FONT>
No Name
...
> irina [at] souiki.org =
No Name
...
> Voted NO
...
> vote-comp.security.public-key-infra [at] newton.digitalspace.net Philip Newton
Account created to vote?
As the total number of votes received is 88, it doesn't matter.
--
Arthur L. Rubin 216-...@mcimail.com
WWFiv (Wally Farley)
<216-...@mcimail.com> wrote:
>Neil Crellin wrote:
>
<snip>
>> Voted NO
>...
>> vote-comp.security.public-key-infra [at] newton.digitalspace.net Philip Newton
>Account created to vote?
Why is that a problem? He gave his real name. It's an effective
anti-spam.
ba...@dmcom.net
> >Account created to vote?
> Why is that a problem? He gave his real name. It's an effective
> anti-spam.
What can raise concern is that the account was only created for the
vote. As for a real name . . . It certainly appears to be a real name
and could very well be one for somebody (prehaps the voter or perhaps
someone that does not know Usenet exists at all).
At least one of the regs of this group has what appears to be a real
name to many. In this case it does not matter if it was a real name
vote, it often does not matter if a few questionable votes occur in the
results. I can well inderstand the desire for throw away email
addresses as a counter spam tatic. This however leaves open the chances
of abusing the Voting process.
It would be nice if there was a way of not posting those that voted to
remove the counter spam tatics that some voters used. However to work
out such a scheme is very hard to do. Secert ballot would be nice,
however that makes imposible to detect voter fraud that might change the
Results. A few ideas have been discussed as posible ways to change the
scheme to get more users to vote. Alas most of them have more bugs then
the existing system.
UVV until recently (real time, not Usenet time) did allow munged
addresses that could be easy for the votetaker to despam. This however
had to be discarded because of one Result where 5 votes was not included
because of spam blocking and one vote could have effected the outcome.
There was a bit of discussion aboyt how each of us would despam those 5
emails (not easily, just despam) and we could not all agree on which
ones were despamable to the voters real address.
Erik Max Francis
> > vote-comp.security.public-key-infra [at] newton.digitalspace.net
> > Philip Newton
>
> Account created to vote?
This may be (and probably is) a red herring. Just because someone has a
customized email address for some service or task doesn't mean it's
fake; for instance, if I sign up for a Web site called SkunkWorks, I
usually give them the email address max-sku...@alcyone.com, merely
for tracking (so if I start getting mail to that address, I know where
it ultimately came from).
Plenty of people have domains where any and all email send to the domain
goes directly to them, so it's just a more encompassing case.
Besides, as another poster pointed out, he gave his real name.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The little I know, I owe to my ignorance.
\__/ Sacha Guitry
Bosskey.net: Counter-Strike / http://www.bosskey.net/cs/
A personal guide to Counter-Strike.
Erik Max Francis
> What can raise concern is that the account was only created for the
> vote. As for a real name . . . It certainly appears to be a real
> name
> and could very well be one for somebody (prehaps the voter or perhaps
> someone that does not know Usenet exists at all).
But you can't tell from the address alone that there actually is a
unique account associated with it, created expressly for the vote. It
could be (and probably is) that all email to *@his.domain.name gets
routed to him, so he just uses a user name in the email address that is
instructive for backtracking where unsolicited mail comes from.
That doesn't mean that he _didn't_ create a specific account for it or
that something untoward isn't going on, but it hardly necessarily
implies it.
John David Galt
> It didn't help that both comp.security.announce and
> comp.security.pgp.announce are apparently dead groups.
I get about a message a week in c.s.a. If you don't, there's something
wrong with your feed (or your filters).
However, this vote wasn't announced in c.s.a, AFAICT.
Kathy Cole
<216-...@mcimail.com> wrote:
> from the RESULT:
> > vote-comp.security.public-key-infra [at] newton.digitalspace.net Philip Newton
> Account created to vote?
What made you think that was not permitted?
Bill Cole
"Arthur L. Rubin" <216-...@mcimail.com> wrote:
>> vote-comp.security.public-key-infra [at] newton.digitalspace.net Philip
>> Newton
>Account created to vote?
Or at least an address created to vote, it appears.
I don't see an intrinsic problem with that. An increasing number of
people have worked out ways to create new addresses that deliver to the
same polace eventiually, both as a spam-control tactic and as a mail
management tactic. This is not new at all, and is not at all different
from the older tactic of '+' address tagging. I would guess from the
domain part of that address that Mr. Newton has some control over every
address with that domain part, so that he can define a new address ad
hoc much as many users behind sendmail have been able to define
'username+tag@domain" type addresses for years. There is no practical
difference.
--
The answer is that no one has a right to press even 'good' ideas on an
unwilling recipient. -- Chief Justice Berger, SCotUS
Bill Cole bi...@scconsult.com