Subject: RE: CONSENSUS CALL: KDC certs part 1

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 26 Aug 2005 12:38:39 -0700

what matters most here is that which CA can issue KDC certificates for
*which realm*.  Because the keyword "realm" did not appear in your text,
I made the clarifications.

Stefan Santesson wrote:

> The point that I was trying to make is that checking "id-pksan SAN
and/or the presence of the id-pkkdcekuoid EKU as described in Section
3.2.4" ONLY provides you with > any useful information IF you first has
determined that the KDC certificate is issued by an authorized CA.

By RFC 3280, the CA has to be authorized, without clearly spelling out
the Kerberos realm in the text, I failed to see the value added by your
text.

> A client MUST determine that any KDC certificate it accepts is issued
by a CA that is authorized to issue KDC certificates for the intended
purpose.

The keyword "MUST" is less than accurate, because if the KDC certificate
is pre-shared, the client does not need do this.

That said, please tell me a bit more about why my text is not accurate,
or modify your text to address my concerns above.

-- Larry

________________________________

From: Stefan Santesson 
Sent: Friday, August 26, 2005 12:18 PM
To: Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: Paul Leach; [email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

Larry,

I'm afraid your text is not a correct description of the issue at hand.

The point that I was trying to make is that checking "id-pksan SAN
and/or the presence of the id-pkkdcekuoid EKU as described in Section
3.2.4" ONLY provides you with any useful information IF you first has
determined that the KDC certificate is issued by an authorized CA.

The reverse is also true, that is, once you have determined that the
certificate is issued by an appropriate CA you may not have to check
anything else (referred to as local policy). That could be the case e.g.
if you only recognize and accept just one specific authorized CA which
sole purpose to issue a certificate to the KDC.

Stefan Santesson 
Program Manager, Standards Liaison 
Windows Security 

________________________________

From: Liqiang(Larry) Zhu 
Sent: den 26 augusti 2005 20:24
To: Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
Cc: Paul Leach; [email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

I suggest to limit the scope and spell out the consequence in plain
english. This issue is not applicable to preshared KDC certificates.

s/determine/verify/

s/purpose/realm/

"If a client accepts a certificate as a KDC certificate of the target
realm without a priori knowledge, for example by using id-pksan SAN
and/or the presence of the id-pkkdcekuoid EKU as described in Section
3.2.4, it MUST verify  that the KDC certificate's CA is authorized to
issue KDC certificates for the target realm. Otherwise, the binding
between the KDC certificate and the KDC of the target realm is not
established. The means how to authenticate and authorize a CA for such
purpose is outside the scope of this specification."

I propose to add this text into the security consideration section.

-- Larry

________________________________

From: Stefan Santesson
Sent: Fri 8/26/2005 9:25 AM
To: Jeffrey Hutzelman; Sam Hartman
Cc: Paul Leach; [email-masked]; Liqiang(Larry) Zhu;
[email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

Jeff, 

I recall that I was requested to suggest some wording on the need to
determine/limit the number of CAs trusted to issue kdc certificates,
which is a fundamental assumption for this protocol.

A first try at this would be: 

"A client MUST determine that any KDC certificate it accepts is issued
by a CA that is authorized to issue KDC certificates for the intended
purpose. The means to implement and enforce such policy is outside the
scope of this standard but all mechanisms of this standard depend on the
condition that this has been done appropriately."

I'm not sure whether such statement is best suited in the security
considerations section or in the body of the standard.

Stefan Santesson 
Program Manager, Standards Liaison 
Windows Security 

> -----Original Message----- 
> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: den 10 augusti 2005 19:18 
> To: Sam Hartman 
> Cc: Paul Leach; [email-masked]; Liqiang(Larry) Zhu; ietf-krb- 
> [email-masked]; Stefan Santesson 
> Subject: CONSENSUS CALL: KDC certs part 1 
> 
> 
> 
> On Monday, August 01, 2005 15:53:36 +0200 Jeffrey Hutzelman 
> <[email-masked]> 
> wrote: 
> 
> >>> 1) Is this cert appropriate to use as a pkinit cert 
> >>> 
> >>> 2) Does this cert refer to the KDC who I as a client want to talk
to. 
> >> 
> >> Here are some possible tests for question (1): 
> >> (a) Correct TGS principal name in id-pksan(*) 
> >> (b) Presence of id-pkkdcekuoid 
> >> (c) Local policy 
> >> 
> >> Here are some possible tests for question (2): 
> >> (a) Correct TGS principal name in id-pksan 
> >> (b) Realm name in dnsName SAN 
> >> (c) Stefan's SRV RR SAN 
> >> (d) Realm name in CN 
> >> (e) Local policy 
> 
> 
> > The sense of the room was that my statement of the problem was
correct, 
> > as was my interpretation of the language in PKINIT-26 (and now,
-27). 
> > 
> > No one proposed adding any tests which are not already described in
-27. 
> > And, no one disagreed that the 1a/2a test combination should be
REQUIRED 
> > for clients to implement. 
> 
> This means that for question 2, the only specified tests are and will 
> continue to be 2a and 2e.  For question 1, test 1a is clearly
permitted; 
> resolution of which of tests 1b and 1c to permit in what circumstances
is 
> unresolved.  The REQUIRED tests are 1a and 2a. 
> 
> This is a consensus call to validate the above decisions as made
during 
> the 
> working group meeting.  Please comment on whether you agree or
disagree 
> with the above decisions.  Note that the EKU issue is still
outstanding 
> and 
> will be handled separately. 
> 
> -- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 26 Aug 2005 13:14:53 -0700

The word "for example" is used to allude that the same text is
applicable when Stefan's DNS SRV x.509 name form is used, aka, it is not
limited to the existing id-pksan TGS name form.

-- Larry

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

> I'm afraid your text is not a correct description of the issue at
hand.

Actually, I think Larry's text does correctly describe the problem; it's

just not as clear as yours.  Remove the "for example..." and I think
you'll 
see what I mean.

<wg chair hat off>

I think I prefer your text, but with the two one-word changes Larry 
suggested (s/determine/verify/ and s/purpose/realm/).  I don't object to

adding the "without a priori knowledge" exception, which basically
covers a 
pre-shared KDC certificate, but I also don't object to leaving it out.

-- Jeff

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 26 Aug 2005 16:07:24 -0700

_____  

From: Stefan Santesson 

Larry,

[Paul Leach] You mean "trusted" here, don't you? I.e, that the chain
validates to a trusted root?

[Paul Leach] That is a form of local policy, isn't it?

Stefan Santesson 

  _____  

From: Liqiang(Larry) Zhu 

s/determine/verify/

s/purpose/realm/

-- Larry

  _____  

From: Stefan Santesson

Jeff, 

Stefan Santesson 

to. 
correct, 
-27). 
-27. 
REQUIRED 
permitted; 
is 
during 
disagree 
outstanding

---

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 27 Aug 2005 00:10:34 +0100

Inline;

Stefan Santesson 

From: Paul Leach 
Sent: den 27 augusti 2005 01:07
To: Stefan Santesson; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: [email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

From: Stefan Santesson 

Larry,

[Stefan] Not necessarily. A client can in principle also configure the
trust on a lower level than on the root level. Otherwise I think my
wording is equivalent to the concept of trust.

[Stefan] Yes

Stefan Santesson 

From: Liqiang(Larry) Zhu 

s/determine/verify/

s/purpose/realm/

-- Larry

From: Stefan Santesson

Jeff, 

Stefan Santesson 

to. 
correct, 
-27). 
-27. 
REQUIRED 
permitted; 
is 
during 
disagree 
outstanding

---

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 27 Aug 2005 00:29:38 +0100

The problem is that I may not understand what problem you mean to solve
and therefore my text may solve the wrong problem.

As PKI expert and not as Kerberos expert, I can't really follow the
logic in Larry's text.

>"If a client accepts a certificate as a KDC certificate of the target
realm
>without a priori knowledge,

What is "prior knowledge"? This is not clear to me.

>for example by using id-pksan SAN and/or the presence of the
id-pkkdcekuoid
>EKU as described in Section 3.2.4, 

This indicates that the so called "prior knowledge" can be obtained by
examining data in the certificate, but this does not make me understand
what "prior knowledge" means.

>it MUST verify  that the KDC certificate's CA is authorized to issue
KDC
>certificates for the target realm.

This is my main problem. The text at this stage indicates and order of
events where you only need to determine that the CA is authorized "IF"
the "prior knowledge" condition has failed. In practice you must ALLWAYS
determine if the CA is duly authorized/trusted for the purpose you are
using it. This can be done in many ways (such as just chaining to an
appropriate root certificate) but it MUST be done first.

>Otherwise, the binding between the KDC certificate and the KDC of the
>target realm is not established. The means how to authenticate and
>authorize a CA for such purpose is outside the scope of this
>specification."

Minor comment: I don't understand "This means" in the last sentence. It
indicates that the text before explains why it is out of scope while it
doesn't. I agree though that it should be out of scope.

If anyone can better explain what the problem is that we try to solve,
then maybe I can better help crafting some words.

Stefan Santesson

> Sent: den 26 augusti 2005 22:15
> To: Jeffrey Hutzelman; Stefan Santesson; Sam Hartman
applicable
> when Stefan's DNS SRV x.509 name form is used, aka, it is not limited
to
> the existing id-pksan TGS name form.
> 
> -- Larry
> 
> From: [email-masked] [mailto:owner-ietf-krb-
> [email-masked]] On Behalf Of Jeffrey Hutzelman
covers
> a

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 26 Aug 2005 17:25:30 -0700

If the following text is to go into the security considerations section,
then I don't buy the last line:

The security considerations section needs to point out ways in which it
is possible to insecurely use a protocol.

Some things that people SHOULD do to make sure that KDC are authentic
include:

1. Local policy should specify which CAs are allowed to issue KDC certs,
and for each one name constraints should define for which realms it is
allowed to issue them

2. Keep a list of trust anchors (which may be specific to KDC cert
issuance) and validate that the KDC's leaf cert chains up to a trust
anchor.

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 26 Aug 2005 17:41:00 -0700

> Sent: Friday, August 26, 2005 4:30 PM
logic
> in Larry's text.
[Paul Leach] It wasn't exactly clear to me, either.
> 
> >for example by using id-pksan SAN and/or the presence of the id-
> pkkdcekuoid
[Paul Leach] Actually, the opposite -- it is prior knowledge when one
does NOT need to examine the data in the certificate to know that it is
valid for use as a KDC's certificate. Examples of such prior knowledge
would be a configuration setting that had (realm-name, certificate)
pairs, or (realm-name, public-key) pairs, or (realm-name, cert-hash)
pairs.

KDC
the
> "prior knowledge" condition has failed. In practice you must ALLWAYS
> > when Stefan's DNS SRV x.509 name form is used, aka, it is not
limited to

---

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 27 Aug 2005 01:49:59 +0100

Paul,

I agree. If "prior knowledge" means that you already know that the
certificate you hold is appropriate, then you have already done what I
say you need to do first and you are good.

The example in the text does however not by itself provide such prior
knowledge.

Stefan Santesson

> Sent: den 27 augusti 2005 02:41
does
> NOT need to examine the data in the certificate to know that it is
valid
> for use as a KDC's certificate. Examples of such prior knowledge would
be
> a configuration setting that had (realm-name, certificate) pairs, or
> (realm-name, public-key) pairs, or (realm-name, cert-hash) pairs.
> 
> >
limited
> > > > I'm afraid your text is not a correct description of the issue
at
> > hand.
> > >
> > > Actually, I think Larry's text does correctly describe the
problem;
> it's
> > > suggested (s/determine/verify/ and s/purpose/realm/).  I don't
object

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 26 Aug 2005 18:03:44 -0700

s/prior/a priori/

the later assumes the knowledge is proven/secure.

-----Original Message-----
From: Stefan Santesson 
Sent: Friday, August 26, 2005 5:50 PM
To: Paul Leach; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: [email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

Paul,

Stefan Santesson

does
valid
be
limited
at
problem;
object

---

From: "Paul Leach" <[email-masked]>
Date: Fri, 26 Aug 2005 18:14:55 -0700

> certificate you hold is appropriate, then you have already done what I
say
> you need to do first and you are good.
[Paul Leach] Prior knowledge can include out-of-band communication --
the certificate contents may not really have been examined at all -- it
was just given to you by someone you trust (like a domain
administrator).

> The example in the text does however not by itself provide such prior
[Paul Leach] As far as I can tell, it wasn't intended to be so. It was
intended to be an example of a case where the authenticity of the CA
needed to be verified.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 26 Aug 2005 18:15:31 -0700

Updated with Paul and Stefan's suggestion:

===================================
If the KDC certificate is certified by a CA as a KDC certificate for the target ream (for example, the CA can indicate the certificate is a KDC certificate of a Kerberos realm by asserting the TGS name of that Kerberos realm as id-pksan SAN and/or restricting the certificate usage by using the id-pkkdcekuoid EKU, as described in Section 3.2.4), the KDC certificate's CA MUST be authorized to issue KDC certificates for that target realm. Otherwise, the binding between the KDC certificate and the KDC of the target realm is not established. The means by which the client authorizes a CA for such purpose can be one of the following:

1. Local policy can specify which CAs are allowed to issue KDC certificates, and for each one name constraints should define for which realms it is allowed to issue them.

2. The client can keep a list of trust anchors for each Kerberos realm it can contact (this list may be specific to KDC certificate issuance) and validate that the KDC's leaf certificate is path validated [RFC3280] to a trust anchor in the trust anchor list for the target realm.

===================================
Comments?

-- Larry

________________________________________
From: Paul Leach 
Sent: Friday, August 26, 2005 5:26 PM
To: Stefan Santesson; Liqiang(Larry) Zhu; Jeffrey Hutzelman; Sam Hartman
Cc: [email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

If the following text is to go into the security considerations section, then I don't buy the last line:

"If a client accepts a certificate as a KDC certificate of the target realm without a priori knowledge, for example by using id-pksan SAN and/or the presence of the id-pkkdcekuoid EKU as described in Section 3.2.4, it MUST verify  that the KDC certificate's CA is authorized to issue KDC certificates for the target realm. Otherwise, the binding between the KDC certificate and the KDC of the target realm is not established. The means how to authenticate and authorize a CA for such purpose is outside the scope of this specification."

The security considerations section needs to point out ways in which it is possible to insecurely use a protocol.

Some things that people SHOULD do to make sure that KDC are authentic include:
1. Local policy should specify which CAs are allowed to issue KDC certs, and for each one name constraints should define for which realms it is allowed to issue them
2. Keep a list of trust anchors (which may be specific to KDC cert issuance) and validate that the KDC's leaf cert chains up to a trust anchor.

---

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 27 Aug 2005 10:50:54 +0100

This is definitely an improvement, but I'm still not satisfied :)

We should not be specific about any requirements on how to configure trust in a particular CA since it can be done in many valid ways.

You definitely do NOT have to have specific trust anchors for KDC certificates and you not have to apply name constraints. And if you apply name constraints it is never applied by all CAs in the path.

A perfectly valid example is if you have the KDC certificate chaining to a more generic root/TA while clients are configured to require a certain KDC specific intermediary CA (under that root/TA) to be present in the path.

I suggest some hopefully minor changes to the text:

"In order to trust a KDC certificate that is certified by a CA as a KDC certificate for a target ream (for example, by asserting the TGS name of that Kerberos realm as an id-pksan SAN and/or restricting the certificate usage by using the id-pkkdcekuoid EKU, as described in Section 3.2.4), the client MUST determine that the KDC certificate's issuing CA is authorized to issue KDC certificates for that target realm.  Otherwise, the binding between the KDC certificate and the KDC of the target realm is not established.

How to validate this authorization is a matter of local policy. Typical ways to achieve this is includes configuration of specific sets of trust anchors and intermediary CAs, possibly supported by name constraints, which have to be utilized in the certificate validation process according to RFC 3280."

Stefan Santesson

> Sent: den 27 augusti 2005 04:58
> To: Paul Leach; Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
> Paul suggested the following text after consolidating approach 1 and
> approach 2.
> 
> ------------------
>    If the KDC's certificate is certified by a CA as a KDC certificate
>    for a target ream (for example, by asserting the TGS name of that
>    Kerberos realm as an id-pksan SAN and/or restricting the certificate
>    usage by using the id-pkkdcekuoid EKU, as described in
>    Section 3.2.4), the KDC certificate's CA MUST be authorized to issue
>    KDC certificates for that target realm.  Otherwise, the binding
>    established.
>    To achieve this, local policy should specify a set of
>    trust anchors for KDC certificates, and the client must verify that
>    the KDC's leaf certificate is path validated [RFC3280] to an anchor
>    in this set.  Each CA in the certification path between the KDC
>    certificate and the trust anchor should have name constraints applied
>    to it that specify for which realms it is allowed to issue KDC
>    certificates.
> 
> ------------------
> 
> Please comment.
> 
> Thanks,
> 
> -- Larry
> 
> 
> [email-masked]] On Behalf Of Liqiang(Larry) Zhu
> Sent: Friday, August 26, 2005 6:16 PM
> To: Paul Leach; Stefan Santesson; Jeffrey Hutzelman; Sam Hartman
> If the KDC certificate is certified by a CA as a KDC certificate for the
> target ream (for example, the CA can indicate the certificate is a KDC
> certificate of a Kerberos realm by asserting the TGS name of that Kerberos
> realm as id-pksan SAN and/or restricting the certificate usage by using
> the id-pkkdcekuoid EKU, as described in Section 3.2.4), the KDC
> certificate's CA MUST be authorized to issue KDC certificates for that
> target realm. Otherwise, the binding between the KDC certificate and the
> KDC of the target realm is not established. The means by which the client
> authorizes a CA for such purpose can be one of the following:
> 
> 1. Local policy can specify which CAs are allowed to issue KDC
> certificates, and for each one name constraints should define for which
> realms it is allowed to issue them.
> 
> 2. The client can keep a list of trust anchors for each Kerberos realm it
> can contact (this list may be specific to KDC certificate issuance) and
> validate that the KDC's leaf certificate is path validated [RFC3280] to a
> trust anchor in the trust anchor list for the target realm.
> 
> realm without a priori knowledge, for example by using id-pksan SAN and/or
> the presence of the id-pkkdcekuoid EKU as described in Section
> issue KDC certificates for the target realm. Otherwise, the
> binding between the KDC certificate and the KDC of the target realm is
> not established. The means how to authenticate and authorize a CA for such

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 27 Aug 2005 11:22:45 -0700

s/determine/verify/

I also would like to make this understandable by Kerberos developers, not just target at PKI experts.

----------------------

"In order to trust a KDC certificate that is certified by a CA as a KDC certificate for a target ream (for example, by asserting the TGS name of that Kerberos realm as an id-pksan SAN and/or restricting the certificate usage by using the id-pkkdcekuoid EKU, as described in Section 3.2.4), the client MUST verify that the KDC certificate's issuing CA is authorized to issue KDC certificates for that target realm.  Otherwise, the binding between the KDC certificate and the KDC of the target realm is not established.

How to validate this authorization is a matter of local policy. Typical ways to achieve this is includes configuration of specific sets of intermediary CAs and trust anchors, one of which must be on KDC certificate's certification path [RFC 3280]. In addition, name constraints [RFC 3280] may be applied that specify for which realms a CA is allowed to issue KDC certificates."

--------------------

This text is very explicit and plain about what is the requirements; can you help to verify if I have fixed all inaccuracies you pointed out below?

Thanks,

-- larry

-----Original Message-----
From: Stefan Santesson 
Sent: Saturday, August 27, 2005 2:51 AM
To: Liqiang(Larry) Zhu; Paul Leach; Jeffrey Hutzelman; Sam Hartman
Cc: [email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

Stefan Santesson

---

From: "Paul Leach" <[email-masked]>
Date: Mon, 29 Aug 2005 18:01:24 -0700

I'm a little concerned about the vagueness of the second paragraph. As
Stefan correctly points out, there are lots of ways to configure trust
securely in a PKI environment. Unfortunately, very few people know even
_one_ way.

One purpose of a security considerations section is to help people avoid
common security errors in implementation and deployment. Hence, while I
agree that we should allow leeway for people who know what they are
doing, we should also be more prescriptive for those who don't.

I would propose this:

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 [RFC 3280], and SHOULD use name
constraints  [RFC 3280] to constrain for which realms a CA is
allowed to issue KDC certificates.

> Sent: Monday, August 29, 2005 5:09 PM
> To: Liqiang(Larry) Zhu; Stefan Santesson; Paul Leach; Sam Hartman
> On Saturday, August 27, 2005 04:52:26 PM -0700 "Liqiang(Larry) Zhu"
> <[email-masked]> wrote:
> 
> > I agree. thanks Stefan.
> >
> > Put everything together, here is what we have now:
> > ------------------------------------
> >
> >  "In order to trust a KDC certificate that is certified by a CA as a
KDC
> > certificate for a target ream (for example, by asserting the TGS
name of
> > that Kerberos realm as an id-pksan SAN and/or restricting the
> certificate
> > usage by using the id-pkkdcekuoid EKU, as described in Section
3.2.4),
> > the  client MUST verify that the KDC certificate's issuing CA is
> > authorized to  issue KDC certificates for that target realm.
Otherwise,
> > the binding  between the KDC certificate and the KDC of the target
realm
> > is not  established.
> >
> > How to validate this authorization is a matter of local policy.
Typical
> > ways to achieve this is includes configuration of specific sets of
> > intermediary CAs and trust anchors, one of which must be on the KDC
> > certificate's certification path [RFC 3280]. In addition, name
> > constraints  [RFC 3280] may be applied to constrain for which realms
a
> CA
> > is
> > allowed to issue KDC certificates"
> > ----------------------------
> >
> > comments please?
> 
> <wg chair hat off>
> 
> I've been following this discussion somewhat, and the above looks fine
to
> me (except s/ream/realm/, which I already mentioned to Larry
off-list).  I
> agree the issue is an important one, and this seems to resolve it.
> 
> 
> <wg chair hat on>
> 
> Now, I've seen lots of discussion from Larry and Stefan, with an
> occasional
> comment by Love and Paul Leach.  I'd like to see comments from other
WG
> members either indicating support for this text, or calling out any
> remaining problems.
> 
> -- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 29 Aug 2005 18:06:53 -0700

I support this text.

-- larry

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

I would propose this:

KDC
name of
3.2.4),
Otherwise,
realm
Typical
a
to
off-list).  I
WG

---

From: "Paul Leach" <[email-masked]>
Date: Tue, 30 Aug 2005 10:07:39 -0700

-----Original Message-----
From: Stefan Santesson 
Sent: Tuesday, August 30, 2005 3:32 AM
To: Liqiang(Larry) Zhu; Paul Leach; Jeffrey Hutzelman; Sam Hartman
Cc: [email-masked]; [email-masked]
Subject: RE: CONSENSUS CALL: KDC certs part 1

I have no problem with this approach in principle.

However, I have a little problem with "SHOULD use name constraints"

Name constraints is a protective measure by a CA and not by a client.
The client MUST "use" any name constraints present in the validated
path. A CA however only applies name constraints when it is relevant
(When it does not fully control or trust cross certified CAs)

[Paul Leach] Is there a standardized way for the relying party to
associate local policy with a CA, specifying which names a CA is
authorized to certify?

[Paul Leach] Why wouldn't a CA that has child CAs want to apply name
constraints to them, if the purpose of having them was to partition the
namespace it certifies and hand responsibility for different partitions
to different children? The "principle of least privilege" would argue
for that approach.

Name constraints in the context of constraining on realm is really only
useful when constraining dNSName SubjAlt name. But use of this SAN isn't
directly specified or recommended in the document. Name constraints is
not a reasonable thing to recommend for most otherName forms such as
KRB5PrincipalName SAN or an SRV_RR SAN.

The reason is that a path validation process must reject a certificate
with a critical name constraints (this extension MUST be critical)
unless it knows how to process matching rules for all constrained name
forms that appears in subsequent certificates. So any path validation
software that does not have explicit name constraints matching rules for
these name forms will have to fail the validation.

[Paul Leach] That doesn't mean we can't recommend it. An implementer in
an environment that doesn't have software to handle them is free not to
use them -- that's a "good reason" for which "SHOULD" can be ignored.

I'm a big fan of name constraints, but in the context of this
specification, I would either leave it out or limit to the original
sentence: 

"In addition, name constraints  [RFC 3280] may be applied to constrain
for which realms a CA is allowed to issue KDC certificates"

[Paul Leach] I think that name constraints should be used whenever there
is more than one CA trusted to issue KDC certs, and they are not all
fully under control of a single authority. That includes when trusting
CAs from other organizations via cross-certification, and when creating
multiple CAs within a single organization that are controlled by
different parts of that organization. Conversely, when there's only one
CA used to issue KDC certs, name constraints are needed.

Stefan Santesson

> Sent: den 30 augusti 2005 03:07
> To: Paul Leach; Jeffrey Hutzelman; Stefan Santesson; Sam Hartman
However,

---

From: "Paul Leach" <[email-masked]>
Date: Wed, 31 Aug 2005 02:04:26 -0700

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

The problem here is much simpler than folks are making it out to be. 
Stefan's original text suggests that a CA MAY wish to use name
constraints 
when issuing certificates to intermediates which certify PKINIT KDC's. 
Larry's version makes it sound like this is something for the client to 
decide, which it is not.  The use of name constraints is solely at the 
descretion of the issuer of an intermediate CA certificate; if they are 
present they MUST be checked, and if not, well, there's nothing to
check.

[Paul Leach] IMO, the security considerations section needs to make 2
recommendations: how the PKI should be configured, and how the client
should be configured. I agree that Larry's text (for which I will accept
some guilt) confuses those two. We're working on clarifications.

---

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

I want to suggest a way how to implement this. For that I do want to say
it is a "table" that contains CAs and realms, not just local policy.

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

On Wed, Aug 31, 2005 at 08:04:19PM -0700, Liqiang(Larry) Zhu 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.

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

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

For me it's an either or :)

> Putting all together, here is the text I would propose.
> 
> 
>    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.

A mapping table?  Surely you mean local policy :)