Subject: RE: New CONSENSUS CALL - KDC cert naming

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 9 Sep 2005 19:22:32 +0100

Yes, what you suggest is all you need to say.

In X.509 you MUST process all extensions you recognize regardless of
criticality. You can only ignore a non-critical extension if you don't
recognize it.

If you do recognize the EKU extension then the requirement to parse and
understand the Kreberos EKU is automatically enforced even if we don't
say anything specifically is.

This since when an EKU is present, you can only use the certificate for
the purposes matching the EKUs you understand. IF you don't understand
the Kerberos EKU, then you can't use the cert.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 
> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]]
> Sent: den 7 september 2005 14:23
> To: Sam Hartman
> Cc: Paul Leach; [email-masked]; Liqiang(Larry) Zhu; ietf-krb-
> [email-masked]; Stefan Santesson
> Subject: Re: New CONSENSUS CALL - KDC cert naming
> 
> 
> 
> On Wednesday, September 07, 2005 04:37:56 PM -0400 Sam Hartman
> <[email-masked]> wrote:
> 
> >>>>>> "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.
> 
> 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: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 10 Sep 2005 14:18:20 -0700

I am ok to add text in -28 to say "All PKINIT implementations using
X.509 certificates MUST understand the X.509 extension EKU [RFC3280]". 

This is stronger than what RFC3280 says. RFC3280 says you can ignore the
EKU extension if you do not understand the EKU extension at all and the
EKU extension is not marked as critical.

-- Larry

-----Original Message-----
From: Stefan Santesson 
Sent: Friday, September 09, 2005 11:23 AM
To: Jeffrey Hutzelman; Sam Hartman
Cc: Paul Leach; [email-masked]; Liqiang(Larry) Zhu;
[email-masked]
Subject: RE: New CONSENSUS CALL - KDC cert naming

Stefan Santesson
 
mean
basis
that
so.
but
I

---

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 12 Sep 2005 09:05:06 +0100

Jeff,

Can you be clear what you mean by "make id-pksan required-to-implement"

Do you mean that a) clients must implement support for parsing id-pksan
or b) that they always MUST be included in certificates?

I hope you mean a)

Stefan Santesson

> Sent: den 11 september 2005 22:19
> To: Sam Hartman
> [email-masked]; Stefan Santesson; Jeffrey Hutzelman
> 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

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 12 Sep 2005 10:40:46 -0700

Stefan, Paul, and I discussed this offline, here is what we settled down
in principal.

   In addition, implementations of this specification MUST be capable of
   processing the Extended Key Usage (EKU) extension and the Subject
   Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
   present.

Any comments?

-- Larry

-----Original Message-----
From: Stefan Santesson 
Sent: Monday, September 12, 2005 1:05 AM
To: Jeffrey Hutzelman; Sam Hartman
Cc: Paul Leach; [email-masked]; Liqiang(Larry) Zhu;
[email-masked]

Jeff,

I hope you mean a)

Stefan Santesson

policy)
be
use
I'm
already
fail

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 12 Sep 2005 10:57:37 -0700

Agreed. it was not my intention to leave out the id-pksan part.

Here again:

   In addition, implementations of this specification MUST be capable of
   processing the Extended Key Usage (EKU) extension and the id-pksan
   (as defined in Section 3.2.2) otherName of the Subject Alternative
   Name (SAN) extension in X.509 certificates [RFC3280], if present.

Any more corrections?

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Monday, September 12, 2005 10:52 AM
To: Stefan Santesson; Liqiang(Larry) Zhu; Sam Hartman
Cc: Paul Leach; [email-masked]; [email-masked]; Jeffrey
Hutzelman
Subject: RE: New CONSENSUS CALL - KDC cert naming

On Monday, September 12, 2005 18:46:24 +0100 Stefan Santesson 
<[email-masked]> wrote:

> I think you need to mention the id-pksan othername explicitly.
> Forcing an implementation to process the SAN extension does not mean
> that it will be capable of processing the content of any possible
> defined otherName.

<chair hat off>
I agree.  Requiring support for the extension without specifying which
name 
type(s) is/are required doesn't really accomplish much.

---

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 12 Sep 2005 21:31:06 +0100

Works for me too

Stefan Santesson

> Sent: den 12 september 2005 11:10
> To: Liqiang(Larry) Zhu; Stefan Santesson; Sam Hartman
Hutzelman
> On Monday, September 12, 2005 10:57:37 -0700 "Liqiang(Larry) Zhu"
> <[email-masked]> wrote:
> 
> Works for me