Proposal: krb5_get_init_creds_opt_set_change_password_prompt

[Jeffrey Altman]

Kevin Coffman wrote:
> On 12/7/06, Douglas E. Engert <deengert at anl.gov> wrote:
>> If you take out the pa_type, then you would have the
>> -pp option I was talking about, and  I would suspect get
>> around Sam's objections about OpenSSL/pkinit specifics.
>> I suspose the -pp could have the pa_data type too.
> 
> Agreed.  I thought it was looking for trouble to assume we could get
> all current and future preauth types (and implementations) to agree
> what attribute "foo" means.  To me, it seems ambitious enough to get
> all pkinit implementations to agree.  But maybe I'm just being
> pessimistic.

Unless I am mistaken, the concern that Sam has with a _pkinit
specific function is that unless you have an implementation of pkinit
that function cannot be implemented except as a stub and as long as
the only open source implementation of a pkinit module is built using
OpenSSL that results in a licensing conflict with the GPL.

If the function that is being defined is not pkinit specific and is
general enough to apply to any pre-auth type and there is an
implementation of a non-pkinit pre-auth type that the framework can
use that is not in conflict with the GPL, then there is no licensing
issue associated with the API and the API can be added to MIT Kerberos.

Sam will correct me if I am wrong.

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20061207/6712ad36/attachment.bin