Subject: RE: CONSENSUS CALL: KDC certs part 1

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

We do need to describe "a" way how to implement this policy in the
security consideration section.

   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]; and 
   local policy SHOULD have a CA-to-realm mapping table that 
   specifies for which realms the CAs are allowed to issue KDC 
   certificates.

-- Larry

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

On Wednesday, August 31, 2005 08:04:19 PM -0700 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

> 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.

<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:42:46 -0500

> security consideration section.

Since all such ways, short of name constrainsts or directories, pretty
much amount to "local policy" I do think that "local policy" is enough,
though we could also include a model of local policy (kinda like
RFC2401bis has an ASN.1 model of the SPD).  While the latter would be
nice I don't think we have to do it (anymore than we have to specify
name constraints matching for KRB5Principal).