Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com
 designates 209.85.146.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=jFncvyDtleQw2OzILBR7Ou/14+ovGb6nJH2sZHtN3B2fEpfb9l7oamor19F3ZX4AqBqz65cbPvJLyAfAbQTNI7nHfOG6xzOI105mdYOOeA0M6A38TdrQwj9QEftYHhuyuhLwAqivGm6f6zdI0/2Ggbdr4VXZ+/Fwh4d375FilJE=
Message-ID: <a32f6b020709222111x6faad3f2ycf593532a7525914@mail.gmail.com>
Date: Sun, 23 Sep 2007 00:11:53 -0400
From: "Alex Karasulu" <akarasulu@apache.org>
Sender: akarasulu@gmail.com
To: "Apache Directory Developers List" <dev@directory.apache.org>,
	erodriguez@apache.org
Subject: Re: [Kerberos] PKINIT support
In-Reply-To: <568753d90709221747l57bf206g73b15a298d94376@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_35915_2942075.1190520713400"
References: <568753d90709221747l57bf206g73b15a298d94376@mail.gmail.com>

------=_Part_35915_2942075.1190520713400
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

IMO if you have some time you might want to start work on some developer
documentation
on DNS as well as a user's guide so we can attract more committers while
answering user
questions around DNS.

Just this week someone asked about this on the users list and all they heard
were crickets.
Emmanuel had to sit there and tell the guy that we cannot support him and
its an embarrassment
for us.  He had to apologize for your actions. That's not cool.

Although I want to see you make strides on adding new features to Kerberos I
think it's a bit irresponsible
for you to get back into new features without documenting others that you
added in the past.
You just can't do that while you leave the DNS situation in a poor state.
Do you understand
the point I'm trying to make here?  Do you see some merit in what I am
saying from a community
perspective? I'm trying to get you to understand where we're coming from and
not think this is
at all any means to lessen your value.  We really like the technical things
you do but a community
is not just about the code.

It's antithetical to OS culture to just drop code or features into some
project and leave.  You have
to take care of the users, the developers that come after you so the project
is alive rather than being
an inanimate piece of code.  By suggesting this new feature addition before
taking care of your
inherent responsibilities to the community clearly shows that you're not
thinking about these aspects.
This is why I'm going to just say no for now.

Secondly with respect to technical matters how does this impact what we have
in Triplesec
with HOTP?  Is this another SAM type for the kerberos server which uses the
class loading
scheme we already have in place for verifiers?

Alex


On 9/22/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
>
> Hi, Directory developers,
>
> I have a window with no major deadlines for the next few weeks, so I
> looked into adding 1 new Kerberos feature for the next release.  After
> doing some "due diligence," ie reading the relevant specs and
> reviewing what support I need from the JDK and various libraries, I am
> highly confident I can add PKINIT support for 1.5.2.
>
> PKINIT is a pre-authentication type for Kerberos (detailed in RFC
> 4556).  For those not familiar, PKINIT can be quickly summarized as
> "smartcard authentication for Kerberos, replacing the
> username/password."  PKINIT can also work with a local keypair, so
> there isn't a requirement for hardware like an actual smartcard,
> though that is the intended deployment scenario.
>
> Since this is only a new pre-authentication verifier, I would rather
> not branch and instead develop this, at first, in my sandbox.  I have
> time starting this weekend, so I'd like to start to get code
> committed, to back the code up.
>
> Enrique
>

------=_Part_35915_2942075.1190520713400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

IMO if you have some time you might want to start work on some developer documentation <br>on DNS as well as a user&#39;s guide so we can attract more committers while answering user<br>questions around DNS.&nbsp; <br><br>Just this week someone asked about this on the users list and all they heard were crickets.
<br>Emmanuel had to sit there and tell the guy that we cannot support him and its an embarrassment<br>for us.&nbsp; He had to apologize for your actions. That&#39;s not cool.<br><br>Although I want to see you make strides on adding new features to Kerberos I think it&#39;s a bit irresponsible
<br>for you to get back into new features without documenting others that you added in the past.<br>You just can&#39;t do that while you leave the DNS situation in a poor state.&nbsp; Do you understand <br>the point I&#39;m trying to make here?&nbsp; Do you see some merit in what I am saying from a community
<br>perspective? I&#39;m trying to get you to understand where we&#39;re coming from and not think this is<br>at all any means to lessen your value.&nbsp; We really like the technical things you do but a community<br>is not just about the code.
<br><br>It&#39;s antithetical to OS culture to just drop code or features into some project and leave.&nbsp; You have <br>to take care of the users, the developers that come after you so the project is alive rather than being<br>
an inanimate piece of code.&nbsp; By suggesting this new feature addition before taking care of your <br>inherent responsibilities to the community clearly shows that you&#39;re not thinking about these aspects.<br>This is why I&#39;m going to just say no for now. 
<br><br>Secondly with respect to technical matters how does this impact what we have in Triplesec <br>with HOTP?&nbsp; Is this another SAM type for the kerberos server which uses the class loading <br>scheme we already have in place for verifiers?
<br><br>Alex<br><br><br><div><span class="gmail_quote">On 9/22/07, <b class="gmail_sendername">Enrique Rodriguez</b> &lt;<a href="mailto:enriquer9@gmail.com">enriquer9@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi, Directory developers,<br><br>I have a window with no major deadlines for the next few weeks, so I<br>looked into adding 1 new Kerberos feature for the next release.&nbsp;&nbsp;After<br>doing some &quot;due diligence,&quot; ie reading the relevant specs and
<br>reviewing what support I need from the JDK and various libraries, I am<br>highly confident I can add PKINIT support for 1.5.2.<br><br>PKINIT is a pre-authentication type for Kerberos (detailed in RFC<br>4556).&nbsp;&nbsp;For those not familiar, PKINIT can be quickly summarized as
<br>&quot;smartcard authentication for Kerberos, replacing the<br>username/password.&quot;&nbsp;&nbsp;PKINIT can also work with a local keypair, so<br>there isn&#39;t a requirement for hardware like an actual smartcard,<br>though that is the intended deployment scenario.
<br><br>Since this is only a new pre-authentication verifier, I would rather<br>not branch and instead develop this, at first, in my sandbox.&nbsp;&nbsp;I have<br>time starting this weekend, so I&#39;d like to start to get code<br>
committed, to back the code up.<br><br>Enrique<br></blockquote></div><br>

------=_Part_35915_2942075.1190520713400--