Subject: Re: New CONSENSUS CALL - KDC cert naming

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Sep 2005 09:31:56 -0400

I think your statements look OK.  However I'd like to know whether we
plan to require supports for the EKU in clients.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Sep 2005 13:17:46 -0400

> plan to require supports for the EKU in clients.

Argh; I failed to address that in my last message.

I assume that by "REQUIRE support for the EKU", you mean that a client MUST 
NOT reject a certificate on the basis of an EKU extension which contains 
our KeyPurposeID; that is, if our KeyPurposeID is there, the client MUST 
recognize it.  If you mean something else, please say so.

<chair hat off>
I see no reason not to make this requirement.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Sep 2005 16:37:56 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Wednesday, September 07, 2005 09:31:56 -0400 Sam
    Jeffrey> Hartman
    Jeffrey> <[email-masked]> wrote:

    >> I think your statements look OK.  However I'd like to know
    >> whether we plan to require supports for the EKU in clients.

    Jeffrey> Argh; I failed to address that in my last message.

    Jeffrey> I assume that by "REQUIRE support for the EKU", you mean
    Jeffrey> that a client MUST NOT reject a certificate on the basis
    Jeffrey> of an EKU extension which contains our KeyPurposeID; that
    Jeffrey> is, if our KeyPurposeID is there, the client MUST
    Jeffrey> recognize it.  If you mean something else, please say so.

I was actually thinking of requiring that clients support EKU.
I.E. pkinit clients MUST NOT ignore a non-critical EKU because there
are cases where they need to examine the EKU.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Sep 2005 17:22:40 -0400

> are cases where they need to examine the EKU.

Ah, I see.  Well, I had thought that EKU was REQUIRED to be critical, but a 
quick check of RFC3280 shows that not to be the case.  In which case, I 
have no objection to requiring that clients support the EKU extension.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 12 Sep 2005 01:18:58 -0400

On Monday, August 29, 2005 20:04:21 -0400 Jeffrey Hutzelman <[email-masked]> 
wrote:

> I believe the following are true:
>
> - The sense of the WG is that tests 2a (id-pksan) and 2e (local policy)
> are
>   sufficient, and that PKINIT not need explicitly specify any other tests
>   of the KDC's identity.
>
> - The sense of the WG is that support for test 2a (id-pksan) should be
>   REQUIRED, such that all clients will support certificates which use
>   this name type to identify a KDC.
>
> I would like comments from members of the working group indicating
> whether they agree with these two statements.

Based on comments received and statements made during the last IETF, I'm 
declaring consensus on this.  The current version of the document already 
reflects this decision, with the exception of Paul's comment that we fail 
to actually make id-pksan required-to-implement (see #1133).

I'm updating RT (#837) to reflect this.

-- Jeff