[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pkinit_require_eku
- To: Love Hörnquist Åstrand <lha@kth.se>
- Subject: Re: pkinit_require_eku
- From: Michael Ströder <michael@stroeder.com>
- Date: Fri, 01 Dec 2006 12:27:55 +0100
- Cc: heimdal-discuss@sics.se
- In-Reply-To: <BBBD6989-6428-47CF-BC99-4C59FA50DE6F@kth.se>
- References: <456DC0A0.6000203@lnf.infn.it> <BBBD6989-6428-47CF-BC99-4C59FA50DE6F@kth.se>
- Sender: owner-heimdal-discuss@sics.se
- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417
Love Hörnquist Åstrand wrote:
>
>> And is it a necessary requirement to have eku field in the
>> certificates ?
>
> Its required to have the PK-INIT EKU in the KDC's certificate by
> the RFC specifying PK-INIT.
Looking at RFC 4556 (PKINIT) I see the OIDs and data structures differs
from what is needed for smartcard logon with MS AD at the moment. Is
that right?
I'm currently designing certificate profiles for client authentication
certs and server certs. Should I add these OIDs to EKU extension for
future PKINIT implementations? I wonder where this all is heading...
Ciao, Michael.
------------------------------------------------------------------------
RFC 4556 section 3.2.2 for client certs:
id-pkinit-san OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
x509SanAN (2) }
RFC 4556 in section 3.2.2 for client certs:
Unless the client knows by some other means that the KDC certificate
is intended for a Kerberos KDC, the client MUST require that the KDC
certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
id-pkinit-KPKdc OBJECT IDENTIFIER ::=
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
pkinit(3) keyPurposeKdc(5) }
-- Signing KDC responses.
-- Key usage bits that MUST be consistent:
-- digitalSignature.