Subject: RE: CONSENSUS CALL: KDC certs part 1

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 31 Aug 2005 20:04:19 -0700

I think instead this RPC should describe useful mechanisms to authorize
the CA for issuing KDC certificates. Stefan pointed out name constraints
are not the solution for this problem; I tended to agree with him on
that.

Given the working group has already decided not to define name
constraints for id-pksan otherName with PKINIT ID. I support Nico's
proposal to remove any references to name constraints completely.

Putting all together, here is the text I would propose.

   How to validate this authorization is a matter of local policy.
   However, absent careful consideration of alternatives that provide
   such validation, implementations SHOULD support configuration of
   specific sets of intermediate CAs and trust anchors, one of which
   must be on the KDC certificate's certification path [RFC3280].  In
   addition, a CA SHOULD be constrained for which realm it is allowed 
   to issue KDC certificates, for example by using a local CA-to-realm 
   mapping table.

-- Larry

-----Original Message-----
From: Paul Leach 
Sent: Wednesday, August 31, 2005 6:30 PM
To: Nicolas Williams; Jeffrey Hutzelman
Cc: Liqiang(Larry) Zhu; Stefan Santesson; Sam Hartman;
[email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

I think it should be incumbent on an RFC which defines a new name form,
for which it would be useful to have name constraints, to also define
the name constraint matching rules.

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Wednesday, August 31, 2005 6:22 PM
> To: Jeffrey Hutzelman
> Cc: Liqiang(Larry) Zhu; Stefan Santesson; Paul Leach; Sam Hartman;
> [email-masked]; [email-masked]
> Subject: Re: CONSENSUS CALL: KDC certs part 1
> 
> On Wed, Aug 31, 2005 at 05:02:09PM -0400, Jeffrey Hutzelman wrote:
> > - Stefan's original text suggested that CA's MAY use name
constraints in
> >  the certs they issue.  As I said before, this is true whether we
say it
> >  or not.  The only reason to say it is to suggest that they actually
do
> >  so.  We can do that or not, but <wg chair hat off> since there is
not
> >  yet a name constraint form defined for KRB5PrincipalName, it seems
like
> >  a not-very-useful suggestion at this time. <wg chair hat on>
> 
> If we won't define name constraints for KRB5PrincipalName (even though
> it seems like all it would take is a sentence or two, just like
RFC3280
> does for various SANs) then I think that suggestion needs to go.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 31 Aug 2005 23:11:11 -0400

>    to issue KDC certificates, for example by using a local CA-to-realm

<wg chair hat off>

I think that last statement is far too strong.  MUST and SHOULD are for 
implementors; here you're trying to apply a SHOULD to policy.  You might 
instead say something like

"PKINIT client implementations MUST/SHOULD provide a facility for limiting 
trust in a CA to a specific realm or set of realms".

This turns the requirement into one that applies to implementors rather 
than to policy-makers.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Aug 2005 22:15:53 -0500

> are not the solution for this problem; I tended to agree with him on

Did he?  He pointed out that we can just say "apply name constraints."

> proposal to remove any references to name constraints completely.

For me it's an either or :)

>    to issue KDC certificates, for example by using a local CA-to-realm 

A mapping table?  Surely you mean local policy :)