[15792] in Kerberos_V5_Development
Re: [kerberos-discuss] a suggestion for improving pkinit preauth
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue May 11 16:14:36 2010
From: Sam Hartman <hartmans@mit.edu>
To: kerberos-discuss <kerberos-discuss@opensolaris.org>
Date: Tue, 11 May 2010 16:14:32 -0400
In-Reply-To: <20100511193900.GC27726@sun.com> (Will Fiveash's message of "Tue,
11 May 2010 14:39:00 -0500")
Message-ID: <tslvdau6vrr.fsf@mit.edu>
MIME-Version: 1.0
Cc: MIT Kerberos Dev List <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>>>>> "Will" == Will Fiveash <will.fiveash@oracle.com> writes:
Will> On Tue, May 11, 2010 at 03:27:15PM -0400, Sam Hartman wrote:
>> >>>>> "Will" == Will Fiveash <will.fiveash@oracle.com> writes:
>>
Will> On Mon, May 10, 2010 at 07:57:50PM -0400, Sam Hartman wrote:
> >> I think slot/token ID is sufficient if you will try a specified
>> >> slot/token even if you were not able to examine its certs
>> because >> login would be required.
>>
Will> Just to be clear, what I'm suggesting is if the token to be
Will> used for PKINIT requires login to access the cert then only
Will> the slot-id and or token-label criteria in the PKCS11 URI in
Will> krb5.conf should be set to match that token and no cert
Will> matching criteria should be specified. In this scenario the
Will> algorithm I proposed would work like:
>>
>> What happens if multiple certs are present on such a token?
>>
>> I'm fine with "We don't support that"
Will> The way it works now > 1 cert in a token is not supported
Will> unless cert matching rules/criteria are specified. So my
Will> proposal would not support a token that required login to
Will> access certs and it contained > 1 cert.
As I said originally, I'm fine with this and agree it is a significant
step forward.
--Sam
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
