Subject: RE: New CONSENSUS CALL - KDC cert naming

From: "Stefan Santesson" <[email-masked]>
Date: Sun, 11 Sep 2005 08:26:24 +0100

Larry,

I agree. But I think we should avoid the term "understand" since it is
not clear what that means in a technical context.

I would rather say. "Implementations of this standard MUST process any
present EKU extension [RFC3280] in X.509 certificates."

Alternatively, if this only is a requirement for clients relative to KDC
certificates we could say:

"Conformant clients MUST process any present EKU extension [RFC3280] in
KDC certificates."

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Liqiang(Larry) Zhu
> Sent: den 10 september 2005 14:18
> To: Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
> Cc: Paul Leach; [email-masked]; [email-masked]
> Subject: RE: New CONSENSUS CALL - KDC cert naming
> 
> 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; ietf-krb-
> [email-masked]
> Subject: RE: New CONSENSUS CALL - KDC cert naming
> 
> 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: Sun, 11 Sep 2005 01:31:02 -0700

Excellent. I prefer the former, since the client certificates can also contain an EKU.

"Implementations of this standard MUST process any present EKU extension [RFC3280] in X.509 certificates."
 
I just put this in -28 now.
 
-- Larry

________________________________

From: Stefan Santesson
Sent: Sun 9/11/2005 12:26 AM
To: Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: Paul Leach; [email-masked]; [email-masked]
Subject: RE: New CONSENSUS CALL - KDC cert naming

Larry, 

I agree. But I think we should avoid the term "understand" since it is not clear what that means in a technical context.

I would rather say. "Implementations of this standard MUST process any present EKU extension [RFC3280] in X.509 certificates."

Alternatively, if this only is a requirement for clients relative to KDC certificates we could say: 

"Conformant clients MUST process any present EKU extension [RFC3280] in KDC certificates." 

Stefan Santesson 

> I am ok to add text in -28 to say "All PKINIT implementations using X.509 
> 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 
> 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 
> 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 
> > >     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> recognize it.  If you mean something else, please say so. 
> > > 
> > > I.E. pkinit clients MUST NOT ignore a non-critical EKU because there 
> > 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:06:51 -0400

> I just put this in -28 now.

OK; having heard no objections to this requirement since the issue was 
raised, I'm assuming the decision is made.

Similarly for the question of whether we need to call out that the EKU is 
not required when id-pksan is used (the answer is yes).

I've updated RT to reflect these decisions, and Larry has added the needed 
text to PKINIT-28.  If people still want to object to these, they can do so 
during last call.

-- Jeff