Re: CA Server (Re: prc)

2009-06-17 Thread Tetsuya Kitahata

> > VeriSign Class 2 is 700USD/page per year IIRC.
> >
> > All the members to have Class2 *for free* would be reasonable.
> > Plus, "donated" committers (e.g. 100USD) to have Class2
> > would be reasonable as well.
> 
> Tetsuya,
> 
> So can I clarify. Do you expect the ASF to pay for some 300 Class 2
> certificates from Verisign?
> Then some further 1800 or more committer certificates?
> 
> That is a staggeringly expensive project to even consider.  Even if
> they were donated to the ASF, that would be another component of an
> already bustling infrastructure metropolis, we are just not geared up
> for that yet.  That's not to say we couldn't be, but at the moment we
> are not.

There could be one way:
Members and committers: by the request, they can get
(Members: free / Committers: 100 - 200 USD/yr)

The best way would be -- as needless to say -- recruiting
VeriSign as a Plutinum Sponsor :-)


WDYT


-- Tetsuya Kitahata 




-
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org



Re: CA Server (Re: prc)

2009-06-15 Thread Tony Stevenson


On 11 Jun 2009, at 00:53, Tetsuya Kitahata wrote:


Plus,

I personally think that all the committers post to
anno...@apache.org etc. to use S/MIME.

I am no longer an individual sponsor (by
svn commit: r779649), so this is just IMHO:

# By the way, why there could be no "emertus sponsor"
# list? I donated to Python Software Foundation 4yrs ago
# and still remain my name listed on the web. I think it
# is rather Normal. Really Strange...

VeriSign Class 2 is 700USD/page per year IIRC.

All the members to have Class2 *for free* would be reasonable.
Plus, "donated" committers (e.g. 100USD) to have Class2
would be reasonable as well.


Tetsuya,

So can I clarify. Do you expect the ASF to pay for some 300 Class 2
certificates from Verisign?
Then some further 1800 or more committer certificates?

That is a staggeringly expensive project to even consider.  Even if
they were donated to the ASF, that would be another component of an
already bustling infrastructure metropolis, we are just not geared up
for that yet.  That's not to say we couldn't be, but at the moment we
are not.


Cheers,
Tony




Cheers,
Tony



Tony Stevenson

t...@pc-tony.com - pct...@apache.org
pct...@freenode.net - t...@caret.cam.ac.uk

http://blog.pc-tony.com

1024D/51047D66 ECAF DC55 C608 5E82 0B5E
3359 C9C7 924E 5104 7D66







-
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org



Re: CA Server (Re: prc)

2009-06-10 Thread Tetsuya Kitahata
Plus,

I personally think that all the committers post to
anno...@apache.org etc. to use S/MIME.

I am no longer an individual sponsor (by
svn commit: r779649), so this is just IMHO:

# By the way, why there could be no "emertus sponsor"
# list? I donated to Python Software Foundation 4yrs ago
# and still remain my name listed on the web. I think it
# is rather Normal. Really Strange...

VeriSign Class 2 is 700USD/page per year IIRC.

All the members to have Class2 *for free* would be reasonable.
Plus, "donated" committers (e.g. 100USD) to have Class2
would be reasonable as well. 

WDYT?

Tetsuya



> Tetsuya Kitahata wrote:
> > Seems that no response ... But don't care.
> > 
> > MY Practical Proposal:
> >  Establishing CA Server in @apache.org 
> > (For S/MINE, PGP etc.)
> > 
> > The Apache Software Foundation has numerous "fax"es or "paper"s from all
> > of the committers at least, and they would be reliable. It's good idea for 
> > me (and YOU)
> > to establish CA Center (Server) in apache.
> 
> AIUI the main problem is that there aren't (or weren't) any CA servers
> which did exactly what apache wanted.
> 
> in general, apache tends to be use distributed trust models to avoid
> single points of failure. so, a CA would need to be secure and embody
> some of the same qualities.
> 
> IIRC some folks started coding up a suitable application but i'm not
> sure why it never made it into use. a major use case was going to be
> managing client side certification for subversion access.
> 
> AIUI infrastructure has been working hard implementing LDAP but that's
> just about completed. now might be a good time to ask them about the CA
> project.
> 
> - - robert

-
Tetsuya Kitahata --  Terra-International, Inc. - President - 
E-mail: kitah...@99.alumni.u-tokyo.ac.jp  http://www.terra-intl.com/
Apache News Online  http://www.apachenews.org/
1555 Doolittle.Dr Suite170 #200 San Leandro, CA, 94577
FAX: +1-4083512810 (USA) / +81-345209534 (Japan)/+44-2033182683(UK)
Skype: tkitahata / ai.kojima


-
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org



Re: CA Server (Re: prc)

2009-05-26 Thread Robert Burrell Donkin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tetsuya Kitahata wrote:
> Seems that no response ... But don't care.
> 
> MY Practical Proposal:
>  Establishing CA Server in @apache.org 
> (For S/MINE, PGP etc.)
> 
> The Apache Software Foundation has numerous "fax"es or "paper"s from all
> of the committers at least, and they would be reliable. It's good idea for me 
> (and YOU)
> to establish CA Center (Server) in apache.

AIUI the main problem is that there aren't (or weren't) any CA servers
which did exactly what apache wanted.

in general, apache tends to be use distributed trust models to avoid
single points of failure. so, a CA would need to be secure and embody
some of the same qualities.

IIRC some folks started coding up a suitable application but i'm not
sure why it never made it into use. a major use case was going to be
managing client side certification for subversion access.

AIUI infrastructure has been working hard implementing LDAP but that's
just about completed. now might be a good time to ask them about the CA
project.

- - robert
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoc3GQACgkQQ617goCdfgNhpACg42tDtu6Uq8JIuy3mvZk22sGY
+7AAoNs3TFkpWoBeMvoVrZ4hOxzk6rfK
=ddsP
-END PGP SIGNATURE-


-
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org



CA Server (Re: prc)

2009-05-24 Thread Tetsuya Kitahata
Seems that no response ... But don't care.

MY Practical Proposal:
 Establishing CA Server in @apache.org 
(For S/MINE, PGP etc.)

The Apache Software Foundation has numerous "fax"es or "paper"s from all
of the committers at least, and they would be reliable. It's good idea for me 
(and YOU)
to establish CA Center (Server) in apache.

Please use my (sponsorship) money for it.

Any thoughts?

Thanks

Tetsuya Kitahata  


-


> Dear ASF PRC Members
> 
> 
> #CC: commun...@a.o.
> 
> 
> Message From Tetsuya Kitahata wearing #Sponsor HAT#
> 
> I am celebrating the 10th anniversary of the ASF and the success of
> ApacheCon EU. I am sorry to respond late because of the additional
> (personal) sponsorship things etc.
> 
> About the doap things, any kinds of progress at ApacheCon EU 2009??
> Seemed that I could not see any progress... right?
> 
> As for doaps, attached file (doaps.tar.gz) contains some "missing"
> doaps, so please use appropriately.
> (Includes recent news item projects -- Zookeeper, Mailet Base,
> CXF, PyLucene, Buildr, CouchDB etc. -- enhance, edit plz.
> I am afraid I could not describe correctly)
> I think that "evangelizing" this project (DOAP project) is ought to
> be more efficient. People (developers) can not find right project
> for their products etc. in apache.org now. Please take it seriously.
> 
> 
> 
> By the way, I have a translation website of projects.apache.org
> at http://projects.terra-intl.com/ (Japanese)
> If possible, linking from http://projects.apache.org would be very
> impressive for japanese apache lovers. Plz add.
> 
> # Maintained completely by doaps.
> 
> 
> Obrigado,
> 
> 
> -- Tetsuya Kitahata 
> 
> 
> 
> 
> > Tetsuya - thanks for the note.  I'm sending this just to prc@ since both 
> > Jim and I are on that list.
> > 
> > Tetsuya Kitahata wrote:
> > > As usual, corporate sponsor won't speak to PRC
> > > directly as a sponsor. Of course, I know that Apache
> > > should not be a slave of sponsors. What I would like to
> > > talk is not such a kind of thing. Please understand.
> > 
> > Yes, I agree that the ASF should not be influenced or controlled by 
> > sponsors ("slave").  However we (the ASF, and in particular the PRC) do 
> > want to be responsive and open to hearing what our sponsors are 
> > interested in and thinking about.  So please do email prc@ with your 
> > thoughts when wearing your #sponsor hat#!
> > 
> > > 1. Congratulations on PRC & Fundraising Committee. Both working
> > > together would be beneficial to the foundation I believe.
> > > Plus, personally I think that this Committee also have "Communication"
> > > Committee. -- For example, jobs@, community@, woman@ management etc.
> > > and evolved to "Public Relations, Communications and Fundraising 
> > > Committee".
> > > (If "Communications" means internal and exrternal, "Public Relations" 
> > > would
> > >  be needless, maybe)
> > 
> > Yes, the PRC (Public Relations Committee) is basically in charge of most 
> > of those areas on the broad scale.  Overall communication with the 
> > public should be what the PRC manages, however we may not have always 
> > formally taken charge of the various email lists and other topics.  The 
> > areas that the PRC clearly owns, and how the PRC sets policy and goes 
> > about using then is still being defined over time.
> > 
> > Several other PRC members and ASF members have been thinking about how 
> > we do "outreach" - how we, as an open source and software organization, 
> > can more actively attract developers and educate the public and 
> > businesses about open source best practices.  Here on prc@ is probably 
> > the best place to work on those kinds of subjects.
> > 
> > 
> > > 2. Please encourage the doap files to be created more. Plus, I
> > > suppose doap files should not be maintained by each PMC,
> > > rather in one repository they should be put, I hope. Simple reason.
> > > When I find error in doap, I must put the opinions on each dev list,
> > > it is very painful for each other. 
> > > (Sometimes it happened in the past: see attached file for example)
> > > #DOAP# repository would be OK. (all committers can edit) -- and
> > > current ones (in svn repositories in each projects) to be batch renewed
> > > daily or hourly.
> > 
> > One of the things I hoped to do over ApacheCon next week is to create 
> > and update more project's DOAP files to ensure we have complete 
> > coverage.  In many cases if we send a patch to the dev@ list for a 
> > project, I expect they'll check it in for us.
> > 
> > I disagree that the DOAP files should be in a central repository.  The 
> > best place to create and store these is in the individual project 
> > repositories, since the individual projects really need to be 
> > responsible to keep them updated.  Part of the problem with poor 
> > maintenance of the DOAP files is that projects don't realize how much of 
> > a strategic value to the ASF overall they can be.
> > 
> > > 3. I had thou