Subject: RE: PKINIT-26 changes: identifying the kdc certificates

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 23 May 2005 18:22:05 +0100

Nico

There seems to be a misunderstanding here.

You say:
> There must be at least one REQUIRED, practical method.

But Larry just explained that the previous drafts currently say: 
"Unless the client can otherwise prove that the public key used to
verify the KDC's signature is bound to the target KDC"

Which means that there is currently NO REQUIRED method.

If you want to propose a required method, then I agree that it should
not be SRV RR.

If there is NO required method, then SRV RR need not to be mentioned
(just implicitly allowed). 

So in no case does PKINIT explicitly need to mention SRV RR and no delay
is necessary.

/Stefan

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-krb-
> [email-masked]] On Behalf Of Nicolas Williams
> Sent: den 23 maj 2005 10:12
> To: Stefan Santesson
> Cc: Liqiang(Larry) Zhu; Sam Hartman; [email-masked]
> Subject: Re: PKINIT-26 changes: identifying the kdc certificates
> 
> On Mon, May 23, 2005 at 06:03:14PM +0100, Stefan Santesson wrote:
> > I would suggest that the following change would make the requirement
> > more clear and testable:
> >
> > Old text:
> >    Unless the client can otherwise
> >    prove that the public key used to verify the KDC's signature is
bound
> >    to the target KDC,  the KDC's X.509 certificate MUST satisfy at
least
> >    one of the following two requirements:
> >
> > Proposed new text:
> >    The client MUST determine that the public key used to verify the
> > KDC's
> >    signature is bound to the target KDC. As means of determining
this
>                                       ^^^
> 				      s/KDC/realm name/ or TGS
> name.
> 
> >    property the client MAY check that the KDC's X.509 certificate
> > satisfies
> >    one of the following conditions:
> >
> > ... and then provide the list of explicit examples.
> 
> There must be at least one REQUIRED, practical method.  The use of SRV
> RR othernames can't be part of this unless we wish to delay PKINIT,
and
> I don't.  Besides, will CAs will support SRV RR othernames soon?  If
> not, forget about it -- let the use of SRV RR othernames for this be
> specified in a separate document.
> 
> Nico
> --
>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 May 2005 12:27:20 -0500

> Which means that there is currently NO REQUIRED method.

This is one reason that PKINIT is still an Internet-Draft.  I can't see
how it would progress if this is not addressed.

What the I-D says at this moment has no force.

> If you want to propose a required method, then I agree that it should

We must have one REQUIRED method -- otherwise PKINIT will not progress.

> (just implicitly allowed). 

Sure, but it would be a serious misunderstanding of IETF process to
think that no method might be REQUIRED yet have the document progress to
Proposed Standard.  Not gonna happen.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 May 2005 15:27:45 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, May 23, 2005 at 06:22:05PM +0100, Stefan
    Nicolas> Santesson wrote:
    >> You say: > There must be at least one REQUIRED, practical
    >> method.
    >> 
    >> But Larry just explained that the previous drafts currently
    >> say: "Unless the client can otherwise prove that the public key
    >> used to verify the KDC's signature is bound to the target KDC"
    >> 

    Nicolas> This is one reason that PKINIT is still an
    Nicolas> Internet-Draft.  I can't see how it would progress if
    Nicolas> this is not addressed.

    Nicolas> What the I-D says at this moment has no force.

    >> If you want to propose a required method, then I agree that it
    >> should not be SRV RR.

    Nicolas> We must have one REQUIRED method -- otherwise PKINIT will
    Nicolas> not progress.

By this Nico means that we must have a method that clients are
required to implement.  IT is not required to work with all certs.  I
think the current text satisfies that because a client may not be able
to determine the mapping for an arbitrary cert, so it needs to support
the kerberos OtherName.