Subject: RE: New CONSENSUS CALL - KDC cert naming

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 12 Sep 2005 18:46:24 +0100

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.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Liqiang(Larry) Zhu
> Sent: den 12 september 2005 10:41
> To: Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
> Cc: Paul Leach; [email-masked]; [email-masked]
> Subject: RE: New CONSENSUS CALL - KDC cert naming
> 
> 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; ietf-krb-
> [email-masked]
> Subject: RE: New CONSENSUS CALL - KDC cert naming
> 
> 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
> Program Manager, Standards Liaison
> Windows Security
> 
> 
> > -----Original Message-----
> > From: Jeffrey Hutzelman [mailto:[email-masked]]
> > Sent: den 11 september 2005 22:19
> > To: Sam Hartman
> > Cc: Paul Leach; [email-masked]; Liqiang(Larry) Zhu; ietf-krb-
> > [email-masked]; Stefan Santesson; Jeffrey Hutzelman
> > Subject: Re: New CONSENSUS CALL - KDC cert naming
> >
> > 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: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 12 Sep 2005 13:51:45 -0400

> that it will be capable of processing the content of any possible

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